Re: Portable Software

Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:
>Often I had
>the impression that the author wanted the program not for use on Windows
>machines. Kind of "source open for specific OS only" :-(


Whatever we want, it's also a question of what the OS vendor wants.


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.


It's no surprise to me that other developers don't jump through these
hoops; maybe if someone payed them for it, but why should they do it
on their own time?


As a recent example of another OS, Apple has intentionally reduced the
functionality of mmap() on MacOS on Apple silicon compared to MacOS on
Intel. As a result, the development version of Gforth does not work
on MacOS on Apple Silicon (it works fine on Linux on Apple Silicon).
I spent a day last summer on the MacOS laptop of a friend (an
extremely unpleasant experience) trying to find the problem and fix
it, and I found the problem, but time ran out before I had a working
fix (it did not help that I had to spend a lot of time on working
around things that I missed in MacOS). Since then this problem has
not reached the top of my ToDo list; and when it does, I will go for
the minimal fix, with the result that Gforth on MacOS will run without
dynamic native-code generation, i.e., slower than on Linux.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

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