Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

32-bit MSDOS (Announce)

posted by marcov, 04.07.2021, 22:57

> By targeting msvcrt.dll, or in fact, just any C
> library, my code should work on native Linux/BSD
> too.
The first Linux port dates for 1995, you are bit late here:-)

There already is fairly advanced code for that in the Unix ports (linux/*bsd/OSX/AIX/Solaris/BeOS and friends). And I wrote most of it.

As said linux/*bsd programs default don't link to libc, but they can with a ifdef.

Do you really think you are the first one to propose this (there are FAQs about it e.g. https://wiki.freepascal.org/libc_unit and http://www.stack.nl/~marcov/unixrtl.pdf), some problems with this approach (just from the top of my head)

- Mostly it is structs and macros that still need to be translated. So basically you only gain a few function calls that are pretty much trivial on most systems anyway. But in general you move to a system that is more likely to break (change in C compiler-> have to debug/fix pascal equivalent header, and deal with versioning, while C users might not even notice it)

- iirc passing 64-bit integers (mmap/ftruncate/lseek etc) on 32-bit systemswill be possible problems, as that is calling conventions dependent. I expect the problems more between Linux/FreeBSD and the rest though, and on x64. Linux vs freebsd on x86 might be ok.

- checking the existence, readonly status of a file requires handling stat, which must be translated manually, and also uses macros (is_dir etc)

- traversing files might require DIR* etc.

- Some constants differ, but mostly in termio parts, not in basic I/O, but some of these are used to check if stdin is redirected or not (e.g. to disable colouring of output when redirecting).

- truename() functionality (expanding a partial path to a whole) needs statfs

- Disabling ctrl-C, sockets and textmode mouse need sigset and fdset handling which vary considerably between Windows and *nix, and slightly within *nix.

You can of course dumb it all down again, and say it is only for some minimal work on your own OS, but if that were true, you wouldn't need to drag all this "other OS and hundred C compilers" into this.

Maybe for an extremely limited subset it doesn't matter much either way, but it is a dead end that will only hurt going beyond the most minimal subset.

> Rather than tying myself down to the Win32 API.
>
> In fact, if I can figure out how to replace the
> assembler "glue" file with a FPC Pascal file,
> this solution will work everywhere that both
> FPC and a C compiler exists.
>
> So the next question of course is - does FPC
> support S/370?
We support POWER processors, and there was somebody external working on it, but afaik it stalled. https://wiki.lazarus.freepascal.org/ZSeries

I wouldn't expect too much from it.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 401 users online (1 registered, 400 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum