Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Actually, Windows 3.1 could run in a 286. I believe with windows 3.1 they dropped 8086 support though(I know windows 3.0 could run on that)
when running windows3.1 on a 286, you are not actually running 3.1, but rather 3.0 with a couple extensions (like truetype support)
win3.1 is 32 bit, supports 32bit drivers (shipped with both 32 and 16 bit versions of all drivers), 32bit applications, 4GB virtual address space, makes extensive use of paging, and VMode (all of these things are 386+ only) -- however it did only support 16MB of physical memory
and im fairly certain windows 3.0 did not support 8086/8088 (iirc 8088/8086 support was dropped starting with windows2) but i could be wrong about that
Gigasoft wrote:No, each process has its own address space, made by switching out parts of the page directory. 32-bit programs use flat addressing, with CS, DS and ES both having a base of 0 and a limit of 0ffffffffh. Only 16-bit code uses different segments starting at various addresses. Each 16-bit module has its own set of segments, and they may be shared across processes.
Do you mean 16-bit protected mode code??
If this is true, then this might explain why Windows 98 uses a lot of different selector for CS.
(I already excluded the VM86 mode code from my observation)
Gigasoft wrote:No, each process has its own address space, made by switching out parts of the page directory. 32-bit programs use flat addressing, with CS, DS and ES both having a base of 0 and a limit of 0ffffffffh.
I watched again, and see that whenever Win98 switches to ring 3, it uses a CS segment of only *2K* bytes in size!
And ring 0 code either uses a segment of 4GB in size, or few other segments of 64KB in size.
It is very weird! Now my assumption is:
- Win98 mostly runs code in ring 0, but not ring 3! (So no userspace code?????)
- Some kernel drivers in Ring 0 code use small segments of 64KB.
It is getting harder to understand why it works that way.
I don't know what those 64K ring 0 segments are, but when it switches to ring 3, it returns to the code that it interrupted or which called it. It could be either 16-bit or 32-bit code. Anyway, when user mode code invokes system code, it uses an area containing a bunch of INT 30h's, and each of them corresponds to a system service.
JAAman wrote:when running windows3.1 on a 286, you are not actually running 3.1, but rather 3.0 with a couple extensions (like truetype support)
win3.1 is 32 bit, supports 32bit drivers (shipped with both 32 and 16 bit versions of all drivers), 32bit applications, 4GB virtual address space, makes extensive use of paging, and VMode (all of these things are 386+ only) -- however it did only support 16MB of physical memory
and im fairly certain windows 3.0 did not support 8086/8088 (iirc 8088/8086 support was dropped starting with windows2) but i could be wrong about that
You are not only wrong about that (it supported the 8086/88 just fine), but also wrong about almost everything else you wrote. Windows 3.1 is not 32 bit, did not support 32 bit drivers, and definitely did not ship with two version of all drivers. It did also not have 32 bit applications. It did use 32 bit addressing though.
Windows 3.0 came in three flavours: real mode (for the 8086/88), standard mode (16-bit 80286 protected mode) and 386 enhanced mode (80386 and up). Windows 3.1 was the first version to drop 8086/88 support. It wasn't until Windows 3.11 and Win32s that applications were allowed to run in 32-bit protected mode (not counting Windows NT).
The truth is, as often, somewhere in the middle. Windows for Workgroups 3.11 supported "32-bits file access" and "32-bits disk access" bypassing DOS and the BIOS. Applications ran in in a 16-bits segmented memory model. They could use the DOS int 21H API through a DOS Extender (DOSX.EXE) so in a way they were DOS executables.
Back to topic: maybe this explains why Windows 98 is so funny. Backward compatibility and the use of original 3.11 code may explain these many different descriptors.
The Win32s subsystem in Windows 3.11 could run some 32-bit applications such as the game FreeCell. But threads and many other things were lacking. When I got an application I had made to run on Windows 3.11, I had to do my own version of the function DialogBoxParamA because the built-in function didn't work.
Hobbes wrote:The truth is, as often, somewhere in the middle. Windows for Workgroups 3.11 supported "32-bits file access" and "32-bits disk access" bypassing DOS and the BIOS. Applications ran in in a 16-bits segmented memory model. They could use the DOS int 21H API through a DOS Extender (DOSX.EXE) so in a way they were DOS executables.
Hobbes wrote:Applications ran in in a 16-bits segmented memory model. They could use the DOS int 21H API through a DOS Extender (DOSX.EXE) so in a way they were DOS executables.
So the kernel is mostly 32 bit, but userspace is 16 bit?
By "16-bits segmented memory model", you mean 16-bits protected mode, or 16-bits real mode??
Junkoi,
Windows 3.x had three operating modes: Real, Standard and 386 Enhanced mode, and applications had to be able to run in all three of them.
In Real mode all applications ran in, well, real mode. Support for Real mode was dropped with Windows 3.1.
In Standard mode applications ran in 16-bits protected mode. Support for Standard mode was dropped with Windows for Workgroups 3.11.
In 386 Enhanced mode applications still ran in 16-bits protected mode. The OS used some features of the 80386. I don't know to what extend, but I'm sure it used V86 mode to run DOS applications.
Note that it is possible to run the same code in all three operating modes, with only few restrictions (privileged instructions, selectors/segment addresses).
Gigasoft wrote:The Win32s subsystem in Windows 3.11 could run some 32-bit applications such as the game FreeCell. But threads and many other things were lacking. When I got an application I had made to run on Windows 3.11, I had to do my own version of the function DialogBoxParamA because the built-in function didn't work.
Win32s only supported functions that the Win16 API supported already. I think the only thing Win32s did, was calling the original Win16 API functions.
