On at 2024-07-01 20:12 +0000, tsiegel--- via Freedos-user wrote:
On 7/1/2024 7:56 PM, Eric Auer via Freedos-user wrote:
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?
Actually, DRDos has always supported windows.
Correct about MSWindows v3.
There was a big hoopla around that when windows came out, because
microsoft claimed it would only work on MSdos, and not on other versions
of dos. Windows would give an error, saying that this version of dos
didn't support windows, and it would exit.
Digital Research then showed DRDos running windows just fine after they
loaded something like a 260-byte TSR that lied to windows about the
version of dos it was running on, which kind of left Microsoft in a bit
of a corner, since it proved that windows did indeed run on versions of
dos that weren't Microsoft in origin.
I'm sure some searching on google will bring up suitable references.
What you describe sounds like the story of WinGlue and WinBolt. That's
what happened to MSWindows v4 (aka 95, 98, Me). The DR-DOS folks at the
time first came up with a TSR, called WinGlue. (If I recall this was
based on the german word der Scheibenkleister.) Later they integrated
its features into a kernel, called WinBolt. Unfortunately, no binary nor
source releases of either seem to have ever found their ways into the
wild nor any archives.
The other hoopla around MSWindows support was with MSWindows v3, which
was supported by DR-DOS but Microsoft added some detection code in a
beta release that warned DR-DOS users about a supposed incompatibility.
This is known as "the AARD code", and is documented on Wikipedia and
elsewhere: https://en.wikipedia.org/wiki/AARD_code
On Geoff Chappell's site, more details are given:
https://www.geoffchappell.com/notes/windows/archive/aard/research.htm
I attached a device driver that prepares an FCB-SFT block at a non-zero offset and I noted that “This condition triggers a message in HIMEM about contacting Windows 3.1 beta support.”
See that its need for the FCB-SFT block either to be missing or to be
paragraph-aligned and canonically addressed is the whole of the code’s
encrypted testing as built into HIMEM.
Regards,
ecm
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
