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, 03.07.2021, 14:02

> And saw that it called ReadProcessMemory (just
> as an example). I did a search and that is a
> standard Windows API.
>
> If you can call Windows APIs (which are defined
> in C, right?),

We can call most procedural interfaces and define them. The only limitation that I'm aware of is that you can't declare variable argument number functions in a C compatible way (iow pass it back as callback), you can call such functions in C though (like scan/printf). This is a deliberate decision because that functionality is swamp, specially on systems with still evolving ABIs.

But there if you can't interpret headers, one is not better in principle than the other.

And win32 api is better than the VS api for several reasons. Chiefly because incompatible fucnctions are given another name (typicall -Ex or -2), also when only the data type changes. Also it gets the changes first.

Moreover there is generally less problems and more options (think accidentally escaping, size limits in filenames etc).

There are no real benefits to calling msvcrt. In the past (with Turbo Pascal string type) it even mismatched with stringtypes( zero-terminated pointer vs length+pointer)

And fat chance that if you start compile larger FPC codebases, that they'll start to use functions of the windows unit (and thus potentially also win32) too.

> > then what difference does it make
> whether you call CreateFile() in kernel32 or
> fopen() in msvcrt?
For your own dedicated port it wouldn't matter. Our windows ports won't change, period.

> BTW, this Pascal stuff made me realize that I
> should be able to create my own cygwin1.dll
> that simply calls functions in msvcrt.dll and
> stubs the rest out.
In theory yes, the problem however is that msys and cygwin1 can't deal with proper windows paths with volumes names/driveletters. Also some might require exclusively forward slashes. There are more such issues, I also expect funkiness with signal handling etc.

My guestimate is that for the effort you can port a lot of programs to msvcrt manually.

> Specifically I want to find out if I can make that
> code call fwrite() instead of WriteFile() which I
> presume it is currently calling.
Yes, it uses WriteFile()

> I'm not sure I understand this. mingw produces
> executables that are only dependent on msvcrt.dll,
> as far as I know.
There is a certain mingw/msys division. Many binaries only
exist as msys. But it hsa been a while since I have looked at it,
I changed to Visual Studio Community edition for my limited
C++/C needs(mostly wrapping C++ dlls in C)

> Not sure why you are referencing the C compiler
> too. I'm talking about any application, not just
> a C compiler that happens to be written in C.
The point was that we don't have any C library like structures inside the codebase. IOW it is not just a mismatch, it is simply not there, at least on Windows.

And even on e.g. Linux we perform our own syscalls, and don't like to glibc by default. (though that has other reasons, mostly to do with cross-distribution compatibility)

> > I don't think there is a significant technical barrier for your own
> port.
> > For our use it is an absolute nono, since afaik msvcrt has several
> > limitations (e.g. not allowing full length pathnames etc), potential
> > escaping issues, requiring zero terminating (not all our strings are
> zero
> > terminated) etc.
>
> The Amiga etc probably doesn't have all these
> things either.
No. And the Zx Spectrum has even less. But because we support ZX Spectrum, we don't dumb all targets down to its level. Moreover, there is simply no benefit.

> > Moreover, there is zero experience with it, we always
> > used the core windows api.
>
> A "generic C90" target would target a lot more
> than just msvcrt.dll.
There is no such thing like a generic "C90" if you can't interpret the headers in an automated fashion. Then it is just another procedural API, and it doesn't matter if the header is C90 compliant and not. And each requires hand
porting.

I've maintained Free Pascal's *nix ports (Linux, *BSD, bit of OS X) for years. I've it all, and heard the arguments all hundred times.

Keep in mind that standards like C90 and Posix usually don't really fixate much (like how FILE* is internally), but rather specify like things that should be there, and a minimal size for them. I consider these standards to be vastly overrated.

Post reply
 

Complete thread:

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