On at 2024-07-01 21:56 +0200, Eric Auer via Freedos-user wrote:
Hi ECM,
thanks for the explanations! If I understand
https://github.com/FDOS/kernel/issues/50
correctly, Windows 386enh support is not part of the
automated builds yet because there originally were
limitations regarding which compilers are supported,
which have since been resolved?
It's not my call whether the enhanced MSWindows support is included in
the default build or not.
The second half of the thread sounds like it still is
non-trivial to get Windows to work smoothly, but at
least it does work to some degree, so I would suggest
to already enable all Windows support by default :-)
Regarding GPT support: The history.txt says a bit does
exist. I have not checked whether source code does...
If you do find it, do tell!
The WIN31SUPPORT define is still not enabled/defined by default I
believe. Some discussion in [7]. At some point I manually built a
kernel including it. I also contributed a workaround to allow the gcc
build to succeed with WIN31SUPPORT defined on 2024-02-04 [8]. However,
I did not test this nor compare it to Enhanced DR-DOS's support of the
same APIs, it just builds now with gcc ia16 as opposed to failing at
build time.
So EDR-DOS also has improved Windows support now? How
stable is the Windows support there compared to FreeDOS?
DR-DOS has supported MSWindows v3 for a long time already. Presumably
LBA, large cluster size, FAT32, and FAT+ support will make it less
compatible than MS-DOS v5 but other than that it is probably at least as
good as the FreeDOS kernel.
Interesting [8] diff! The GNU C implementation seems to
handle 3 segments plus the way to tell where instance
data ends differently from the implementations for the
other compilers?
One of the "winseg" variables is actually not a segment (it is
initialised using the FP_OFF macro) but yes, basically.
And there is something about the lol
pointer in win.h, not affecting other patched places?
The "DATASTART" variable is used to initialise "winseg2".
Maybe that just meant that GNU C wanted things to be
done properly while other compilers accepted somewhat
less elegant ways? Or to put it in a different way:
Could it be useful to use your patch for all other
compilers, without #if defined __GNUC__ condition?
I don't think so. From what I recall the other way worked perfectly fine
for the OpenWatcom build, but NASM's elf output format doesn't have the
WRT or SEG keyword directives yet.
Other than that I'm not sure that "dw seg _DATASTART, 0" is correct
because it appears it puts the segment first, then the offset. I wanted
to compare that to EDR-DOS's corresponding structure but didn't get
around to do that yet.
As I have replied before, I do not care much for running MSWindows.
Regards,
ecm
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
