Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #43189 > unrolled thread

The portability sacred cow

Back to article view | Back to comp.lang.c

Contents

  The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-20 23:14 +0200
    Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-20 23:34 +0200
      Re: The portability sacred cow Geoff <geoff@invalid.invalid> - 2014-04-20 21:20 -0700
        Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-21 04:35 +0000
        Re: The portability sacred cow Kaz Kylheku <kaz@kylheku.com> - 2014-04-21 05:10 +0000
          Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-21 05:31 +0000
          Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-20 23:50 -0700
    Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-20 23:39 +0200
    Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-20 23:37 -0700
      Re: The portability sacred cow Ian Collins <ian-news@hotmail.com> - 2014-04-21 20:25 +1200
    Re: The portability sacred cow glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-21 07:10 +0000
    Re: The portability sacred cow Ian Collins <ian-news@hotmail.com> - 2014-04-21 20:32 +1200
    Re: The portability sacred cow David Brown <david.brown@hesbynett.no> - 2014-04-21 16:46 +0200
      Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-21 10:04 -0700
        Re: The portability sacred cow David Brown <david.brown@hesbynett.no> - 2014-04-21 21:02 +0200
    Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 02:52 -0700
      Re: The portability sacred cow Ian Collins <ian-news@hotmail.com> - 2014-04-22 23:18 +1200
        Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-22 11:49 +0000
      Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 14:48 +0200
      Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-22 14:58 +0100
        Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 07:37 -0700
      Re: The portability sacred cow luser droog <luser.droog@gmail.com> - 2014-04-22 21:52 -0700
    Re: The portability sacred cow Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-04-22 16:58 +0200
      Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 17:24 +0200
        Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 17:25 +0200
      Re: The portability sacred cow Gareth Owen <gwowen@gmail.com> - 2014-04-22 19:11 +0100
    Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 21:59 +0200
      Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 14:02 -0700
        Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-23 01:04 +0200
          Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-22 17:52 -0700
            Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-22 19:15 -0700
        Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-23 01:10 +0200
        Re: The portability sacred cow Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-23 09:53 +0200
          Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-25 02:21 +0000
            Re: The portability sacred cow JohnF <john@please.see.sig.for.email.com> - 2014-04-25 06:36 +0000
              Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-25 14:02 +0200
              Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-25 18:17 +0000
                Re: The portability sacred cow Kaz Kylheku <kaz@kylheku.com> - 2014-04-25 18:27 +0000
                  Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-25 21:57 -0700
                    Re: The portability sacred cow Stephen Sprunk <stephen@sprunk.org> - 2014-04-26 00:02 -0500
                    Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-26 11:35 +0200
                  Re: The portability sacred cow JohnF <john@please.see.sig.for.email.com> - 2014-04-26 06:04 +0000
                Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-25 23:08 +0200
                  Re: The portability sacred cow glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-25 21:52 +0000
            Re: The portability sacred cow Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-25 11:27 +0200
              Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-25 14:03 +0200
                Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-25 18:18 +0000
                Re: The portability sacred cow "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-26 20:04 -0400
              Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-25 06:05 -0700
                Re: The portability sacred cow Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-25 17:43 +0200
                  Re: The portability sacred cow Keith Thompson <kst-u@mib.org> - 2014-04-25 10:48 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#43292

On Tuesday, April 22, 2014 2:58:10 PM UTC+1, Richard wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> 
> > Any code that is interesting in a computer science, mathematical, logical, artistic or other sense
> > will be bit shuffling code. That should be written portably, there's no reason to use any non-
> > portable constructs, there's no reason to be interested in what type of processor you're running
> > on. 
>  
> And there's also no reason whatsoever to think for one minute it needs
> to be portable.
> 
> You do go on.
>
It's of fundamental importance, and, as comments show, something that many people haven't 
understood. 
There are various thing you might want to do. You might want to decide the best move in a chess
game. You might want to find the roots of a quintic equation. You might want to rotate an image
without creating any new pixel values. None of these things entirely trivial to do. You will probably
have target hardware, operating system, etc that you want the program to run on immediately. But 
it's foolish to write any of these things in a platform-specific way. They're bit-shuffling operations. 
Then only reason for not writing portably is because you have hardware acceleration, like a dedicated
chess position checking chip. But that's unusual.
>
> And IO is applicable to any "Computer Science" if not more so.
> 
Not really. 

[toc] | [prev] | [next] | [standalone]

#43403

On Tuesday, April 22, 2014 4:52:50 AM UTC-5, Malcolm McLean wrote:
> On Sunday, April 20, 2014 10:14:27 PM UTC+1, jacob navia wrote:
> 
> > If there is a common sacred cow in this newsgroup it is the
> > "portability" sacred cow.
> > 
> > Portability should be weighted with USABILITY and STABILITY, two things 
> > that we never discuss since they tend to be non portable :-)
> > 
> > In my opinion, portability comes AFTER STABILITY and USABILITY, well 
> > after those.
> > 
> My view is that you need to separate programs into the bit-shuffling section and the the IO section.
> Some parts of the program rearrange bits in memory, other parts manipulate output devices.
> 
> Any code that is interesting in a computer science, mathematical, logical, artistic or other sense
> will be bit shuffling code. That should be written portably, there's no reason to use any non-portable
> constructs, there's no reason to be interested in what type of processor you're running on. (OK,
> I haven't addressed parallellisation and other forms of hardware acceleration, it's a general scheme).
> 
> The code that does IO is essentially a job for a hacker. It's not necessarily easy to write, but the 
> difficulties aren't of a fundamental order. It's a case of one human understanding a system designed
> by another human and knowing how to interact with it. A lot of it isn't portable, and portability means
> something else. It means devising common interfaces, not agreeing on a common language for
> specifying algorithms. 
> 
> Now what do we need to specify an algorithm? Essentially a human-usable Turing complete system.
> A way of getting an arbitrary-sized memory buffer, a way of reading and writing to it, conditional
> jumps, and, to make things usable, arithmetical and logical operations on scalars and a way of
> dividing up code into human-meaningful units or modules . But that's it. Just a thin layer of syntax > 
> over these.

This. (but your paragraphs are too wide.)

Using this methodology, I've been able to implement my postscript
interpreter portably for Ms Windows or Unix+X11 by treating a window
as an RGB device that needs event handling support. 

http://code.google.com/p/xpost

(It also helped a lot to have an Autotools guru actively contributing.)

[toc] | [prev] | [next] | [standalone]

#43295

On 20.04.2014 23:14, jacob navia wrote:

> For instance, OpenBSD has a function free() that is security conscious
> and erases the freed memory before reuse. This would have stopped the
> heartbleed bug in OpenSSL but it wasn't used.

Why do you spread such drivel?

OpenBSD's allocator is so slow that OpenSSL has its own memory
allocator. OpenSSL only allocates one huge chunk of memory from the OS
and then does its own memory management. A free() that is security
conscious would have helped exactly NOTHING because of the constraints.

If you want to spread lies, at least choose lies that aren't immediately
recognized.

Regards,
Johannes

-- 
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
 - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

[toc] | [prev] | [next] | [standalone]

#43296

Le 22/04/2014 16:58, Johannes Bauer a écrit :
> On 20.04.2014 23:14, jacob navia wrote:
>
>> For instance, OpenBSD has a function free() that is security conscious
>> and erases the freed memory before reuse. This would have stopped the
>> heartbleed bug in OpenSSL but it wasn't used.
>
> Why do you spread such drivel?
>

Because I have the sources of my information. They are trustworthy.

> OpenBSD's allocator is so slow that OpenSSL has its own memory
> allocator. OpenSSL only allocates one huge chunk of memory from the OS
> and then does its own memory management. A free() that is security
> conscious would have helped exactly NOTHING because of the constraints.
>

You are wrong.
1) It wasn't OpenBSD's allocator that was slow. It was another system.
2) Well, it would have exposed the bug long ago. Here is the mail from 
Theo de Raat, the main developer of OpenBSD about this issue:

<begin quote>
So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed.  Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too.  To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS
  /* On some platforms, malloc() performance is bad enough that you 
can't just

OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective.  On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.

So then a bug shows up which leaks the content of memory mishandled by
that layer.  If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.

OpenSSL is not developed by a responsible team.
<end quote>

You see now?

> If you want to spread lies, at least choose lies that aren't immediately
> recognized.
>

I am not spreading lies. I will hope that you are just not informed of 
what is happening.

[toc] | [prev] | [next] | [standalone]

#43297

PS I forgot the URL of that email:
http://article.gmane.org/gmane.os.openbsd.misc/211963

[toc] | [prev] | [next] | [standalone]

#43321

Johannes Bauer <dfnsonfsduifb@gmx.de> writes:

> On 20.04.2014 23:14, jacob navia wrote:
>
>> For instance, OpenBSD has a function free() that is security conscious
>> and erases the freed memory before reuse. This would have stopped the
>> heartbleed bug in OpenSSL but it wasn't used.
>
> Why do you spread such drivel?

He's right.

> OpenBSD's allocator is so slow 

No, it's not.

> that OpenSSL has its own memory allocator. 

OpenBSD is not the reason for OpenSSL's own allocator.

> OpenSSL only allocates one huge chunk of memory from the OS and then
> does its own memory management. A free() that is security conscious
> would have helped exactly NOTHING because of the constraints.

You have spectacularly missed the point.

[toc] | [prev] | [next] | [standalone]

#43344

Le 20/04/2014 23:14, jacob navia a écrit :

[snip]

I forgot to say that in the name of portability, C99 was "off limits" 
for this newsgroup between 2000 and around 2009? (when Heathfield left)

All the times I would bring an example of C99 code I was reminded that 
it "wasn't portable", and that "portable code should stay with C89"

Now, it seems that the same people changed their attitude (a bit), maybe 
because a new standard is out who knows, they never explained their change.

That is why I speak about "portability crazyness", because it was that. 
Everything was sacrified in the name of "portable code" even when it 
meant less features, and reinventing old wheels again.

[toc] | [prev] | [next] | [standalone]

#43352

On Tuesday, April 22, 2014 8:59:34 PM UTC+1, jacob navia wrote:
> 
> All the times I would bring an example of C99 code I was reminded that 
> it "wasn't portable", and that "portable code should stay with C89"
> 
> Now, it seems that the same people changed their attitude (a bit), maybe 
> because a new standard is out who knows, they never explained their change.
> 
> That is why I speak about "portability crazyness", because it was that. 
> Everything was sacrified in the name of "portable code" even when it 
> meant less features, and reinventing old wheels again.
>
Microsoft didn't support C99. Windows was such an important platform that
effectively we had to say that C99 was only for single platform code.

For people like myself, portability is extremely important. I don't really 
know what system my code will be required to run on in the future. That has
the effect of squeezing out language experiments. Which isn't a good thing
in itself. I don't hold that C89 was perfect and the last word in language
design. But it is a pretty good abstraction of von Neumann architecture.
No C dialects offer a clear and unambiguous improvement over C89.

[toc] | [prev] | [next] | [standalone]

#43391

Le 22/04/2014 23:02, Malcolm McLean a écrit :
> Microsoft didn't support C99. Windows was such an important platform that
> effectively we had to say that C99 was only for single platform code.

Microsoft doesn't support C99 even today, 15 years after the standard 
publication... I am sure it will never will. As they said in their 
blogs, there is no  "customer demand" for C99.

Microsoft doesn't support C any more in many of its system interfaces...

So what?

Why should be that a problem for you?

[toc] | [prev] | [next] | [standalone]

#43398

jacob navia <jacob@spamsink.net> wrote:
> Le 22/04/2014 23:02, Malcolm McLean a écrit :
>> Microsoft didn't support C99. Windows was such an important platform that
>> effectively we had to say that C99 was only for single platform code.
> 
> Microsoft doesn't support C99 even today, 15 years after the standard 
> publication... I am sure it will never will. As they said in their 
> blogs, there is no  "customer demand" for C99.
> 

Microsoft did an about-face. See

http://msdn.microsoft.com/en-us/library/hh409293.aspx

and

http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx

Visual Studio 2013 adds substantial C99 language and library support, and
it's implied that more is to common. The only conspicuous language feature
missing is variable length arrays.

Note that the additions are merely the intersection of C++11 and C99. Things
like compound literals and designated initializers, which are supported in
VS2013, aren't in any C++ standard.

[toc] | [prev] | [next] | [standalone]

#43400

william@wilbur.25thandclement.com wrote:
<snip>
> Visual Studio 2013 adds substantial C99 language and library support, and
> it's implied that more is to common. The only conspicuous language feature
> missing is variable length arrays.
> 
> Note that the additions are merely the intersection of C++11 and C99. Things
> like compound literals and designated initializers, which are supported in
> VS2013, aren't in any C++ standard.

are NOT merely, I meant.

[toc] | [prev] | [next] | [standalone]

#43394

Le 22/04/2014 23:02, Malcolm McLean a écrit :
> For people like myself, portability is extremely important. I don't really
> know what system my code will be required to run on in the future. That has
> the effect of squeezing out language experiments. Which isn't a good thing
> in itself.

Agree with that. It is not a good thing.

And it has a cost, a cost that means that users of your code in more 
advanced systems can't have all the simplifications that modern 
languages offer. It means that you are bound to rewrite snprintf, if you 
need it, for instance.

http://www.tedunangst.com/flak/post/worst-common-denominator-programming
<quote>
The real snprintf returns the number of characters it wanted to print, 
regardless of buffer size. The imitation BIO_snprintf returns the number 
of characters printed, unless truncation occurs, in which case it 
returns -1. So they’re mostly the same, except in those situations where 
bad things like overflow are happening, in which case normal C 
programmers need to remember that OpenSSL C is not normal.

if (BIO_snprintf(buf,sizeof buf,"%s_default",v->name) >= (int)sizeof(buf))
That’s how one checks real snprintf for truncation, but not 
BIO_snprintf! Ironically, the code would have worked even so, because -1 
implicitly converted to size_t is going to be quite large, but then 
somebody went full retard and cast sizeof to int. Never do this. (The 
cast would be mostly harmless with real snprintf. Only the combination 
of wrapper and cast cause the error. The planets must have been in 
alignment. Still, don’t cast sizeof.)
<end quote>

snprintf is a real improvement... Why should you abandon it or rewrite it?

I do not want to question your choices, I am just saying that they have 
a cost.

[toc] | [prev] | [next] | [standalone]

#43406

On 04/22/14 23:02, Malcolm McLean wrote:
> Microsoft didn't support C99. Windows was such an important platform that
> effectively we had to say that C99 was only for single platform code.

The Intel compiler does support C99 on Windows very well. It's just a question
of buying the compiler that has the features you want. With Microsoft's C
compiler I wouldn't know which that would be, but there's your choice.

Thomas

[toc] | [prev] | [next] | [standalone]

#43538

In article <lj7ri7$143h$1@gwdu112.gwdg.de>,
Thomas Jahns  <jahns@idontlikespam.dkrz.de> wrote:
>On 04/22/14 23:02, Malcolm McLean wrote:
>> Microsoft didn't support C99. Windows was such an important platform that
>> effectively we had to say that C99 was only for single platform code.
>
>The Intel compiler does support C99 on Windows very well. It's just a question
>of buying the compiler that has the features you want. With Microsoft's C
>compiler I wouldn't know which that would be, but there's your choice.
>
>Thomas
>

It doesn't matter.  Nobody (Yes, this is hyperbole) uses the Intel
compiler.

Like it or not, MS's compilers are like the 800 pound gorilla.  What they
do (or don't do) matters.  A lot.  It's what people follow.

-- 
This is the GOP's problem.  When you're at the beginning of the year
and you've got nine Democrats running for the nomination, maybe one or
two of them are Dennis Kucinich.  When you have nine Republicans, seven
or eight of them are Michelle Bachmann.

[toc] | [prev] | [next] | [standalone]

#43545

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> MS's compilers are like the 800 pound gorilla.
> It's what people follow.

Off-topic, but what are the pluses/minuses of
the mingw compiler
  http://www.mingw.org/
for C programs under windows?
And, while you're at it, also compare and contrast
the dos djgpp if you're familiar with it
  http://www.delorie.com/djgpp/
And any other similar compiler.

I try to mostly work under linux, but can't ignore windows,
and use mingw for that platform. Seems fine for my purposes
so far, but I assume there must be some drawbacks/differences
vis-a-vis ms compilers.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#43549

JohnF <john@please.see.sig.for.email.com> writes:

> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> MS's compilers are like the 800 pound gorilla.
>> It's what people follow.
>
> Off-topic, but what are the pluses/minuses of
> the mingw compiler

Totally on topic.


>   http://www.mingw.org/
> for C programs under windows?
> And, while you're at it, also compare and contrast
> the dos djgpp if you're familiar with it
>   http://www.delorie.com/djgpp/
> And any other similar compiler.
>
> I try to mostly work under linux, but can't ignore windows,
> and use mingw for that platform. Seems fine for my purposes
> so far, but I assume there must be some drawbacks/differences
> vis-a-vis ms compilers.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#43575

In article <ljcvom$mb4$1@reader1.panix.com>,
JohnF  <john@please.see.sig.for.email.com> wrote:
>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> MS's compilers are like the 800 pound gorilla.
>> It's what people follow.
>
>Off-topic, but what are the pluses/minuses of
>the mingw compiler
>  http://www.mingw.org/
>for C programs under windows?
>And, while you're at it, also compare and contrast
>the dos djgpp if you're familiar with it
>  http://www.delorie.com/djgpp/
>And any other similar compiler.

Those compilers are good if you've developed your code with Unix/Linux/gcc
and just want a quick port to Windows.  Like, for example, when they want
to produce Windows versions of things like AWK, GAWK, Perl, etc.  Or things
like cut, join, paste, wc, etc, etc.

But most people are not like us (so it says in The Great Gatsby).  They are
coming at it from the other side - they are developing for, by, and on
Windows, so they want a compiler with Windows sensibilities.  The MS
compilers are therefore their first (and basically only) choice.

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[toc] | [prev] | [next] | [standalone]

#43577

On 2014-04-25, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <ljcvom$mb4$1@reader1.panix.com>,
> JohnF  <john@please.see.sig.for.email.com> wrote:
>>Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> MS's compilers are like the 800 pound gorilla.
>>> It's what people follow.
>>
>>Off-topic, but what are the pluses/minuses of
>>the mingw compiler
>>  http://www.mingw.org/
>>for C programs under windows?
>>And, while you're at it, also compare and contrast
>>the dos djgpp if you're familiar with it
>>  http://www.delorie.com/djgpp/
>>And any other similar compiler.
>
> Those compilers are good if you've developed your code with Unix/Linux/gcc
> and just want a quick port to Windows.  Like, for example, when they want
> to produce Windows versions of things like AWK, GAWK, Perl, etc.  Or things
> like cut, join, paste, wc, etc, etc.
>
> But most people are not like us (so it says in The Great Gatsby).  They are
> coming at it from the other side - they are developing for, by, and on
> Windows, so they want a compiler with Windows sensibilities.  The MS
> compilers are therefore their first (and basically only) choice.

You can call Windows API's when developing with MinGW.

The C library that is used is Microsoft's; you can make programs that can ship
as nothing but a single .exe file, and run on people's Windows boxes.

What is lacking is a resource compiler for defining dialogs and strings.
Or is it?

Googling slightly: http://www.mingw.org/wiki/MS_resource_compiler

[toc] | [prev] | [next] | [standalone]

#43587

On Friday, April 25, 2014 7:27:53 PM UTC+1, Kaz Kylheku wrote:
> On 2014-04-25, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> 
> You can call Windows API's when developing with MinGW.
> 
> The C library that is used is Microsoft's; you can make programs that can ship
> as nothing but a single .exe file, and run on people's Windows boxes.
> 
> What is lacking is a resource compiler for defining dialogs and strings.
> Or is it?
>
> Googling slightly: http://www.mingw.org/wiki/MS_resource_compiler
>
One of the features of programming is that most programming tools,
applications, interfaces etc have a core functionality which is interesting
from a computer science perspective, and easy enough for someone to program
up in their spare time. That then gets attached to some sort of user 
interface, to create something which, in a formal sense, offers a lot
of functionality.

However the soft problems are easily underestimated. If you've got to
download something from the internet, install to a specific directory,
set a path in some sort of configuration file, only to receive a message
that some bit somewhere is misconfigured, then it can easily take all
day to install the tool, and it's not usable in a commercial or consumer
setting (academic programmers and hobbyists can still use it, but even 
then, only if particularly committed).

It's hard to make software really nice to use, integrated with the
environment but not falling over when something about that environment is
not as expected, flexible but not getting into a confusing state when
options are set, making it difficult for the user to make mistakes but
not fighting with the user when he really wants to do something
the program disapproves of. Then you've got the standards problem. If
the Evil Corporation is going to respond to your tool by deliberately
making it so that Evil Corporation products break it, then it can be hard 
to get enough momentum for the tool to stop them.

[toc] | [prev] | [next] | [standalone]

#43588

On 25-Apr-14 23:57, Malcolm McLean wrote:
> If the Evil Corporation is going to respond to your tool by deliberately
> making it so that Evil Corporation products break it, then it can be hard 
> to get enough momentum for the tool to stop them.

"DOS isn't done until Lotus won't run."

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web