appiah4 wrote on 2022-04-03, 12:53:
Is it though? How was it going to work considering 286s can't really execute EMM386? Asking genuinely because I know jackshit about the whole thing.
Hi there! I'll try to explain, but please take what I say with a grain of salt.
It's late and I'm sleepy, so I may do make some mistakes here.
Windows 3.x was using three different kernals, one for each processor generation or platform (XT/AT/AT386), if you will.
On an 80286, it uses dosx.exe (16-Bit Protected-Mode Extender) and krnl286.exe (the 80286 Windows kernal).
Memory is still segmented (64KB blocks). No V86 mode is used.
In Windows 3.1, I vaguely remember, the extender also knows VCPI and can use it,
if an memory manager for DOS provides it anyway (the Windows extender is a VCPI client).
Otherwise, XMS is used (himem.sys).
Note: If Windows 3.1 (not 3.0) is run on a 386 or later system, Standard-Mode (Win /S) will not use dosx/krnl286 anymore for some reasons I can only speculate about.
It rather will use a pseudo Standard-Mode through krnl386, but without virtual memory and virtual device driver support (.386 files are early VXDs).
That's also the reason as to why some people got Standard-Mode to work on WfW 3.11.
But once you remove krnl386.exe, that Standard-Mode is gone. However, it's possible to force 286 Standard-Mode on a 386.
To do so, DOSX in SYSTEM directory must be executed manually. But from within Windows directory.
On a 8086, Windows 3.0 uses its Real-Mode kernal, kernel.exe.
It can use existing EMS, if it's provided through an EMS manager that's been loaded before Windows (LIM4, EEMS compliant).
It's entirely up to that manager to provide memory. Can be an EMS board, the chipset, a swapfile on a HDD, a 386 CPU in V86 mode..
The special thing, however, is this: Windows 3.x in Real-Mode provides that EMS memory that it gets through the ordinary Windows API.
That's right, for the first time, Windows 1/2/3 programs can ask for as much memory they want to (as much as that's available).
Just like as we are used to from the Windows 3.1 days. This was groundbreaking, because Windows/386 didn't allow it.
Windows/386 ran Windows in a tiny 640KB DOS VM, after all.
In those days, in theory, Windows programs needed to access EMS directly like an ordinary DOS program.
On a 80386, Windows 3.x uses krnl386.exe and its own DPMI enabled 32-Bit Protected-Mode Extender,
which also provides memory for DOS programs (it's a DPMI host).
- That PM extender in turn gets its memory from the XMS manager (Himem.sys).
Simply said and in terms of functionality only, that 32-Bit PM extender has some sort of EMM386 counterpart built-in.
A little bit like Windows/386 (which really just was a glorified memory manager with Windows 2.x imprisoned in a wimpy DOS VM provided by V86).
That EMM386 counterpart may also take over the duties of EMM386 once Windows 3.x is loaded, I assume. Or both do work hand in hand, at least.
They were developed for each others, after all.
In OS/2, this was turned around. Win-OS/2 never uses XMS/Himem.sys.
Rather, it now is a DPMI client (a DPMI customer) and OS/2 is its master (DPMI host).
The 386 Enhanced-Mode kernal uses V86 mode and uses 4KB blocks
(the usual 64KB blocks that Win16 programs use are sliced into pieces silently behind the curtain; they still think in 64KB blocks).
Windows 3.x in Enhanced Mode uses flat-memory, almost like Windows 95 or DOS4GW games on DOS.
The MMU is configured to work with one big 4GB segment, which effectively disables the old segmentation unit
known from the 80286 processor (its active, but has nothing to do). That way, all memory address are directly addressable.
With Win32s, some 32-Bit programs from Win95 can be run, too.
Provided, they contain relocation tables - because, these tables allow Win32 programs to run in a shared memory (Windows 3.1 uses shared memory in all modes).
That's because ordinary Win32 programs (by todays standards) do start at a fixed default address, at 4MB.
Early Win32 programs had relocation tables included by default, by the way.
(Before Win32s existed, Win16 programs could also already had used WinMem32 API or the Pharlap extenders.
But technically, these were still programs with a Win16/NE header.)
That works this way, because Windows 95 provides virtual addresses to every Win32 EXE (through its heart, the Virtual Machine Manager VMM) .
So each of them can start at 4MB no problem. In RAM, they are at different locations, of course. But they don't know that.
Merely Win16 programs still use cooperative multitasking and shared memory on Windows 95.
That's a special scenario, also.: Only on Win32s platform, both Win32 and Win16 programs could technically
see and talk directly to each others (with a bit of thunking), due to the common memory space.
Timing is also a special case. Win32s uses cooperative multitasking through Windows 3.1, which can be quicker in certain situations.
Ok, that's enough. Maybe way way too much talking of me.
I just hope the owner of this thread is okay with it. I do love to discuss 16-Bit Windows, but not to spam other people's threads. 🙁
More about this can be read here: Windows 3.1 on a 386 with 640K RAM - Possible?
Edit: J know that the writing is horrible, my bad. I was writing from a smartphone. Please bear with me.
It's just meant to give an idea how things roughly work. Some details aren't exactly right/complete, I'm afraid. 😔
Edit: Edited. Typos fixed.
Edit: Reformatted (on PC).
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
//My video channel//