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, 02.07.2021, 16:02

> > But yeah, doing a native port to your own api seems the most prudent
> > direction. You could go for either dos or windows, but the dos port
> > is more simple.
>
> When you say "my own API" - what do you mean?
> I support a subset of standard Win95 kernel32.dll
> and a subset of standard Win95 msvcrt.dll.
We don't use msvcrt.dll anywhere, as we are not a C compiler.

There is work being done to shift the FPC runtime to a DLL to share amongst programs too.

> If by "my own API" you mean my vision of 32-bit
> MSDOS, I don't see a reason to tie myself down
> to that when I can pick up Win95 for free.
Both need work. The win32-as-basis need deNTification, the dos as basic needs deGO32ification to seamlessly operate with your offerings.

But the size and complexity of the go32v2 port is much less. In the end it is your preference and what you are willing to work for.

> If you mean that the MSDOS API is much nicer,
> I agree with that too, if you wrap the INT 21H
> calls with something like PosOpenFile() that
> does an INT 21H (16-bit or 32-bit), but you can
> equally well make PosOpenFile() simply call
> Windows CreateFile().
Yes. It is now just TP dos like, doing interrupt calls by loading a record with register values and then calling the extender's INT routine.

See https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/go32v2/sysfile.inc?view=markup

There are some runtime checks though, like switch betweeen ah=$7xxx style dos LFN calls and normal $3C00 dos open calls. This is toggable with a global "LFNSUPPORT" variable, also there is some more work to replace / with \.


> > Compiler is less of a problem. Linker more likely.
>
> The compiler is designed to read some text files
> and output a binary file.
That's not the problem, it generates mostly djgpp or mingw compatible files.

> The linker is designed to read some binary files
> and output a binary file.
"a" binary file. But not all binary files are exactly the same. There are NT only features in the PE format, and since the internal linker emerged when winXP was already dominant It is simply a subject that is a magnitude more complicated than the RTL work, so that's why I warned.

You can maybe use a mingw's LD linker, but you may lose smartlinking that way (and a lot of speed)

FPC install: run "fp" and see what happens :)


> C:\devel\develop>objdump -p world.exe | grep -i dll
> DllCharacteristics 00000000
> vma: Hint Time Forward DLL First
> DLL Name: kernel32.dll
> DLL Name: oleaut32.dll
> DLL Name: user32.dll
 >

user32 is generally speaking core windows api. Our base Windows headers are winuser/wintypes.h etc translations, and afaik mix user32 kernel32, so I don't know exactly how much it is used.

In the system unit I only see a reference to messageboxa (for a exception popup in GUI applications), and charupperbufferw to uppercase a 16-bit character string.

Oleaut32 is used for the COM compatible string type, and less important, fairly easy to turn off or not.

> I don't support those last 2 DLLs on PDOS/386,
> but it is good to see that there is no equivalent
> of cygwin.dll in there.
We originate in Turbo Pascal, so there is no C or C library usage within the project.

> And I suspect that those two DLLs that I don't
> support could be filled with stubs and my
> "hello world" won't exercise them.
Yes. That is matter of compiling a few non trivial programs and looking with dependency walker what is exactly used.

> But ultimately I'd rather see just msvcrt.dll
> showing up.
I understand why you want that (since that means that the relevant C compiler has been turned from cygwin/mingw to use msvcrt runtime). But we don't use _any_ C runtime, also no own static abstraction internally.

Our origin and compatibility goal is Turbo Pascal/Delphi. Some experience with those would serve you well here.

> What is the quickest technical path to changing
> those 3 DLLs into a single msvcrt.dll? With the
> goal of just running that world.pas program
> above. Or is there a technical barrier?

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.

Moreover, there is zero experience with it, we always used the core windows api. (

> I doubt
> that there is a technical barrier to that when
> there is no technical barrier to the Amiga.
It is all a matter of magnitude. RTL(library) work is relatively simple and can be done by a wider audience.

Note that the last version supporting win9x (afaik) is still online:
ftp://ftp.freepascal.org/pub/fpc/dist/2.6.4/i386-win32/fpc-2.6.4.i386-win32.exe

sources: ftp://ftp.freepascal.org/pub/fpc/dist/2.6.4/source/fpc-2.6.4.source.zip

Post reply
 

Complete thread:

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