Re: Portable Software

On 2023-04-05, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Hans-Peter Diettrich <DrDiettrich1@netscape.net> 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.


The best POSIX subsystem for Windows is arguably Cygwin. It has
quite a rich POSIX functionality. Not only that, but ANSI terminal
functionality: its I/O system contains a layer which translates
ANSI escape sequences into Windows Console API calls.


Yuo can take a program written on Linux which uses termios to put the
TTY in raw mode, and ANSI escapes to control the screen, and it will
work on Cygwin.


One of its downsides downside is that Cygwin has poor performance
(mainly in the area of file access).


The other downside of Cygwin is that it implements certain conventions
that are at odds with "native" Windows.


In 2016 I started a small project called Cygnal (Cygwin Native
Application Library) to fix problems in this second category,
creating a fork of the Cygwin DLL.


https://www.kylheku.com/cygnal


>>(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.


You can avoid the chicken-and-egg problem that requires boostrapping by
using a host language to implement an interpreter for the target
language. That interpreter can then directly execute the compiler, which
can compile itself and other parts of the run-time, as needed.


It's still a kind of boostrapping, but at no point do you need a
pre-built binary of the target language compiler to build that compiler;
you just need an implementation of a host language.


This works quite well when the host language is good for writing
interpreters, and the target one for compiler work, and also when it's
useful to have an interpreter even when compilation is available.


--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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