Re: Portable Software (Anton Ertl)
Wed, 05 Apr 2023 16:30:31 GMT

          From comp.compilers

Related articles
[2 earlier articles]
Re: fledgling assembler programmer (George Neuner) (2023-03-25)
Portable Software (was: fledgling assembler programmer) (Hans-Peter Diettrich) (2023-03-28)
Re: Portable Software (was: fledgling assembler programmer) (2023-03-28)
Re: Portable Software (Hans-Peter Diettrich) (2023-03-31)
Re: Portable Software (2023-04-02)
Re: Portable Software (Hans-Peter Diettrich) (2023-04-05)
Re: Portable Software (2023-04-05)
Re: Portable Software (Kaz Kylheku) (2023-04-06)
Re: Portable Software (Hans-Peter Diettrich) (2023-04-07)
Re: Portable Software (Thomas Koenig) (2023-04-08)
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: Wed, 05 Apr 2023 16:30:31 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 23-03-001 23-03-017 23-03-022 23-03-029 23-03-032 23-03-042 23-04-005 23-04-006
Injection-Info:; posting-host=""; logging-data="16273"; mail-complaints-to=""
Keywords: design, standards
Posted-Date: 06 Apr 2023 03:09:22 EDT

Hans-Peter Diettrich <> writes:
>On 4/2/23 12:04 PM, Anton Ertl wrote:
>> For a Unix, there were a few hoops we had to jump through to make
>> Gforth work: e.g., IRIX 6.5 had a bug in sigaltstack, so we put in a
>> workaround for that; HP/UX's make dealt with files with the same mtime
>> differently from other makes, so we put in a workaround for that.
>> Windows, even with Cygwin, puts up many more hoops to jump through;
>> Bernd Paysan actually jumped through them for Gforth, but a Windows
>> build is still quite a bit of work, so he does that only occasionally.
>Too bad that not all existing OS are POSIX compatible? ;-)

Like many standards, POSIX is a subset of the functionality that
programs use. Windows NT used to have a POSIX subsystem in order to
make WNT comply with FIPS 151-2 needed to make WNT eligible for
certain USA government purchases. From what I read, it was useful for
that, but not much else.

>So my impression still is: have a language (plus library) and an
>interpreter (VM, browser, compiler...) on each target system. Then
>adaptations to a target system have to be made only once, for each
>target, not for every single program.

You mean: Write your program in Java, Python, Gforth, or the like?
Sure, they deal with compatibility problems for you, but you may want
to do things (or have performance) that they do not offer, or only
offer through a C interface (and in the latter case you run into the
C-level compatibility again).

>Even for programs with extreme speed requirements the development can be
>done from the general implementation, for tests etc., and a version
>tweaked for a very specific target system, instead of the single target
>version in the first place and problematic ports to many other platforms.

Well, if you go that route, the result can easily be that your program
does not run on Windows. Especially for GNU programs: The primary
goal is that they run on GNU. Any effort spent on a Windows port is
extra effort that not everybody has time for.

>(G)FORTH IMO is a special case because it's (also) a development system.
>Building (bootstrapping) a new FORTH system written in FORTH is quite
>complicated, in contrast to languages with stand alone tools like
>compiler, linker etc.

Not really. Most self-respecting languages have their compiler(s)
implemented in the language itself, resulting in having to bootstrap.
AFAIK the problem Gforth has with Windows is not the bootstrapping;
packaging and installation are different than for Unix.

- anton
M. Anton Ertl

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.