was chicago always truly 32-bit?

[InsertGoodNameHere]

hey all,

just been reading up on windows 95 for the past few days, specifically its architecture and dos dependency. random question though, as of the leaked builds we have, was it always a hybrid 16-32 bit os or early on was it likewise to 3.1? and as such, was it still just a gui for dos?

thanks

[LangsamSpieler]

Chicago did Begun with Cougar for 32-bits, but with Windows NT 3.1 was a real 32-bit Windows because of NTFS. But the 32-Bit Kernel on DOS and Windows Chicago was really long unstable because double so many Letters in a Program. With Chicago 122 the 32-Bit Kernel was Beginn to be more stable.

[Overdoze]

Based on the info from anti-trust documents, it started out from Cougar - essentially Windows for Workgroups 3.1 (3.11 was in development at the same time as Chicago) running on top of DOS. I imagine once they got the kernel to 32-bits and integrated DOS into it, they moved onto the features. One such thing was the new 32-bit API, which was a special subset of NT's Win32 API called Win32c. Lots of apps remained 16-bit well into development, before they were ported to 32-bits.

The documents mention a small ISV release in March 1993 which still had the old shell. And we have footage of the usability testing builds from January 1993 with the new shell. In terms of leaked builds, 58s still has a 16-bit file cabinet (proto-Explorer) and some other apps, which were later ported to 32-bits.

[jimmsta]

Seeing as even Windows 3.1 eventually had Win32s, before Chicago was released, we know that some effort was being made in the user-space portion of DOS-based Windows for 32-bit functionality. I would assume (and thus make an ass of myself) that the Chicago kernel (VMM32) was always 32-bit -- Chicago (as well as 98 and ME) ran on top of a 32-bit virtual machine, which had a few similarities to NT's services/drivers architecture, without introducing the full NT kernel to DOS.

The entire project allowed Microsoft to extend DOS's feature-set for a couple more years, without incurring huge research and development costs, like those incurred on providing backward compatibility on NT5+.

[xelloss]

hey all,

just been reading up on windows 95 for the past few days, specifically its architecture and dos dependency. random question though, as of the leaked builds we have, was it always a hybrid 16-32 bit os or early on was it likewise to 3.1? and as such, was it still just a gui for dos?

thanks

The 32 bit kernel of Windows, the virtual machine manager (VMM), existed since Windows/386 (2.x). With successive versions of Windows, the VMM was enriched with numerous virtual device drivers implementing operating system services directly rather than passing them to the underlying DOS and BIOS. Even though marketing stated that Windows 95 was not based on DOS, this is as true (or as false) as saying that Windows for Workgroups 3.11 was not based on DOS.

[johnlemon647]

Windows 95 is hybrid between Win16 and Win32. That why Windows 95 is not 32 bit true Operation System like Windows NT. The Book name Undocumented Windows talk about Windows 95 virtual machine manager descended from Windows/386 2.01 in 1987.

[InsertGoodNameHere]

Even though marketing stated that Windows 95 was not based on DOS, this is as true (or as false) as saying that Windows for Workgroups 3.11 was not based on DOS.

as proven here: https://blogs.msdn.microsoft.com/oldnew ... 0/?p=24063

interesting read. tl;dr dos worked as a boot loader and 16 bit compatibility layer; IFSMGR.SYS and the 32-bit file manager work to run 16-bit dos stuff in 32-bit mode

thanks for the replies guys

[os2fan2]

Even something like Netware, a 32-bit network server, boots from a DOS partition. In essence, once DOS is booted, anything could take over various functions of DOS, and run it themselves. As long as they always handled this, you really don't get crashes. In 'Undocumented DOS', by Schulmann, even something like QEMM or emm386 makes DOS into something different.

You can have a GPF under DOS or OS/2 as well as windows. This is a hardware thing, where two virtual machines access the same memory. It is a ram equivalent of cross-linked files. It is just that Windows is better at recovering from these.

Windows in enhanced mode, runs on a 32-bit DOS. The standard-mode version runs on a DOS32 extender, which is different. There are various experiments in 'Undocumented Windows 95', which allows you to run anything as the vmm32.vxd, even command.com. This means that what is loaded before vmm32 is the 32-bit DOS, and vmm32 is simply the shell.

The default action for vmm32.vxd is to load kernel, user and gdi. Note that the standard windows calls lie in kernel/user/gdi, and not further down the chain. This is why the file further down can be variously renamed.

Once windows is up and running, even pure win32 programs in windows 95, calls down to DOS. Windows has move the file system into protected mode (ie handled by some .vxd), but there are still things left in DOS management. Likewise, DOS running in Windows, is running under a windows program called 'winoldap', and this handles much of the DOS console sessions under windows.

So DOS and windows programs go through the same structures to get to things like file management (windows), pid (DOS), and any other service. Under Windows, you can pipe a file with a long file name to a older style DOS program, for example.

[Battler]

The standard-mode version runs on a DOS32 extender, which is different.

No, it runs on a DOS16 extender that uses the 286 protected mode. A DOS32 extender would be 32-bit and would not run on a 286 at all, for which Standard Mode is designed.

There are various experiments in 'Undocumented Windows 95', which allows you to run anything as the vmm32.vxd, even command.com. This means that what is loaded before vmm32 is the 32-bit DOS, and vmm32 is simply the shell.

No, you rename COMMAND.COM to KRNL386.EXE and VMM32.VXD will load it. VMM32.VXD is the 32-bit DOS, not the shell.

[Hyoenmadan86]

Windows in enhanced mode, runs on a 32-bit DOS. The standard-mode version runs on a DOS32 extender, which is different. There are various experiments in 'Undocumented Windows 95', which allows you to run anything as the vmm32.vxd, even command.com. This means that what is loaded before vmm32 is the 32-bit DOS, and vmm32 is simply the shell.

Again... No. VMM32 provides DOS32 services via DOSMGR. It doesn't run on top of these DOS32 services. And your quoting on that experiment is wrong... You rename COMMAND as KRNL386 to make it work, not VMM32. If you rename COMMAND as VMM32, the whole thing fails. COMMAND actually can use any DOS32 services provided by any DPMI host, given they provide the right calls and services. You can get similar effects with DPMIONE and 386MAX from Qualitas, which implement many of the features of MS DPMI32 implementation (well, HX extender too, but that's a whole different matter, as HX aims specifically to replace complete Win32 services with their own implementation, unlike the mentioned ones).

-----
VMM32 is, from a tech point perspective, a very strange and special thing. Is a System kernel in its own right, but not the normal one you find in other standard OSs. It is more like a sort of ancient baremetal hypervisor manager, as how ESXi and Xen are now. Is 32bit completely, along with all its modules and VxD drivers, and this has been true since Windows/386 days. It has the capability of running "alien" code as VM tasks. DOS VM and the Win32 VM (KRNL386, USER and GDI, with its respective VWIN32.vxd helper driver) are examples of the code can run inside VMs created by VMM32 "hypervisor". DOSMGR, and extra VxDs in the stack as BIOSXLAT and parts of the V86MMGR allow the system to use the DOS VM as a big VxD driver for any tasks which require it. VMM32 even allows you to run a whole alien Kernel in a VM and use it as system driver, as how it happens with NTKERN, which provides Win98 and ME with the NT WDM driver model and services.

No... VMM32 doesn't run on top of anything. All the Win4x architecture runs on top of it.

[os2fan2]

Yes, you are indeed right about vmm32. It is the replacement for win286 and win386, in essence, the dos386 of the various machines.

See eg http://www.matem.unam.mx/~micho/ripl6.html for a minimal setup.

dos32 draws its configuration from system.ini[386enh]. This consists of a lot of 'device=*mouse.vxd' (which is loaded from inside dos32), and 'device=c:\windows\system\vxd\ntkern.vxd', which is exterior to the config. In this way, it is similar to DOS, where config.sys loads extra drivers, but the default drivers live in msdos.sys (in win95, io.sys, part 2). VMM32 begins with a DOS program w3, the function is to load and start vxd programs. w3 is the bootstrap of windows 9x.

NTKERN is simply a .vxd, loaded in system.ini. It allows you to load NT device drivers. Of course, it is essentially an emulation layer, like DOSKRNL in OS/2, which is loaded to run DOS programs. No new kernel is loaded. It runs in the same 32-bit space that W3 creates.

Of course, there is nothing special about vmm32. In MS-DOS the same role is done by msdos.sys, in PC-DOS, it's ibmdos.com. These are simply the default drivers loaded where there is no configuration file. vmm32 may provide access to any of the services of the vxd files, but that's all it does. It is kernel.exe that exposes the various functions, such as to create an additional v86 machine. Command.com does not have the coding to run a second v86 machine. You need a task manager to run multiple vmm shells.

Being a DPMI server, it can only run one program: kernel.exe. Kernel then loads user and gdi, to provide the interface between the vxd layer and the win32 layer. The signal to create a new application starts with explorer or the alternate shell. This gets passed down to kernel, which translates the call into vxd calls (which vary from version to version). It is only in the win32 layer that you can get multitasking.

vmm32 runs with dos, and windows runs on top of the dos386 layer. Some calls are routed to io.sys, but since windows is a system on a system, the underlying OS talks to the bare metal.

DOS vm's need extra code, not provided by DOS or DOSMGR. This is handled by winoldap.mod. Winoldap interacts with the various interrupts to prevent the dos session leaking into or out of the window. In other words, winoldap is the address to the virtual dos machine, is a dos32 app.

Being a DPMI server, it is intended to run just one program in this environment: kernel.exe

[Hyoenmadan86]

VMM32 begins with a DOS program w3, the function is to load and start vxd programs. w3 is the bootstrap of windows 9x.

Never said the contrary. And not only VMM32, but every critical system VxD or software utility VxDs which also have a DOS TSR, as VCACHE(SmartDrv), V86MMGR(EMM386), 386MAX(386MAX), etc. The real-mode initialization segment is a 16-bit code and data segment of the VxD defined by the VxD_REAL_MODE_INIT_SEG macro and is called during VMM's startup. This allows a VxD to communicate with TSRs or other real-mode procedures to gather and then pass vital information to the VxD's protected mode initialization routines or to fail the load of the VxD or VMM prior to entering protected mode.
The term "real-mode initialization" is relative. If you have installed an EMM emulator (EMM386, 386Max, or QEMM), it is likely that the real-mode initialization procedures are invoked in V86 mode and are subject to trapped I/O or other virtualization occurring under these systems. In other words, during real-mode initialization, VMM does not switch the processor to real mode and then call these procedures. Instead, it executes the 16-bit code in the mode configured prior to the startup of VMM (such as invoking WlN.COM).

This real mode code segment is used only once during initialization, and is completely discarded as soon as machine control is transferred to VMM32 in protected mode.

NTKERN is simply a .vxd, loaded in system.ini. It allows you to load NT device drivers. Of course, it is essentially an emulation layer, like DOSKRNL in OS/2, which is loaded to run DOS programs. No new kernel is loaded. It runs in the same 32-bit space that W3 creates.

It has a MiniNT Executive and a MiniHAL. The symbols indicate there are source files from the NT tree inside it. Dunno if it actually creates a proper VM for its code or not... But as far as the Resource Kit and the DDK say, it behaves as an actual full fledged NT Kernel for the WDM drivers. But yeah, rloew would have more information about WDM core in Win9x than me.

Of course, there is nothing special about vmm32. In MS-DOS the same role is done by msdos.sys, in PC-DOS, it's ibmdos.com. These are simply the default drivers loaded where there is no configuration file. vmm32 may provide access to any of the services of the vxd files, but that's all it does.

I would like to know your sources, and how you came to such conclusion... What i'm saying here comes from Andrew Schulman books, the Resource Kit and the DDKs. MSDOS.sys is nothing similar to VMM32... AT ALL.

It is kernel.exe that exposes the various functions, such as to create an additional v86 machine. Command.com does not have the coding to run a second v86 machine. You need a task manager to run multiple vmm shells.

What "Kernel.exe"? I don't see any file with such name. And is WINOLDAP the one who manage opening and closing the DOS VMs... Even you said it.

Being a DPMI server, it can only run one program: kernel.exe. Kernel then loads user and gdi, to provide the interface between the vxd layer and the win32 layer. The signal to create a new application starts with explorer or the alternate shell. This gets passed down to kernel, which translates the call into vxd calls (which vary from version to version). It is only in the win32 layer that you can get multitasking.

Ok... Is "Kernel.exe" the core? Or isn't?
KRNL386.exe is a DPMI client app, and also is the core of the Win9x Win32"c" subsystem... Just like in NT is SMSS, CRSSS, BASESRV, WINSRV and WIN32K, being SMSS and CSRSS "native" NT apps.

vmm32 runs with dos, and windows runs on top of the dos386 layer. Some calls are routed to io.sys, but since windows is a system on a system, the underlying OS talks to the bare metal.

Again... VMM32 is the CORE. You can see it in the MEM list of the loaded modules. VMM32 does run and maintains the DOS copy was available at initialization time in a VM, and can call it when is needed with the help of DOSMGR and V86MMGR using things like V86MMGR_Xlat_API. Interesting enough, calls for Disk I/O in "DOS compatibility mode" don't get routed to the DOS VM, but they are routed directly to machine BIOS INT13H handlers directly with the help of BIOSXLAT.VxD, which uses Xlat_API_Exec_Int to execute that BIOS segment in V86 mode. Both DOSMGR and BIOSXLAT use V86MMGR Begin_Nest_V86_Exec and End_Nest_Exec to execute code in V86 mode... Aka, Windows never leaves protected 32bit mode during execution.

It comes straight from Andrew Schulman Undocumented DOS and the following links:
https://www-user.tu-chemnitz.de/~heha/vxd/vxd_fra.htm
http://www.drdobbs.com/windows/undocume ... /184409170

A small unmodified quote form these links... "Windows Enhanced Mode is a preemptive multitasking operating system that runs one or more separate tasks. Each task believes it has sole access to the CPU and peripherals (keyboard, display, mouse, printer, and so on)."

They never mention anything about a "Kernel.exe", a DOS shell or anything similar.

DOS vm's need extra code, not provided by DOS or DOSMGR. This is handled by winoldap.mod. Winoldap interacts with the various interrupts to prevent the dos session leaking into or out of the window. In other words, winoldap is the address to the virtual dos machine, is a dos32 app.

WINOLDAP is just the DOS VM "frontend" which allows user to interact with DOS and old Win1x and Win2x app VMs, nothing more and nothing less. And it is a normal Win16 NE executable. In fact, you can see the resources of the DOS box window on it if you open it with some Win16 resource viewer as Borland Workshop.

There's also an interesting effect when you kill WINOLDAP without closing the running DOS VM first... It keeps running in background, but you can't connect with it again from other WINOLDAP session. This effect is similar to what happens in VMware Workstation when you forcefully close VMware.exe. The VMs keep running in each opened VMware-VMX.exe process. In earlier versions you also couldn't connect to these processes anymore, but in newer version you can.

[Battler]

I think by KERNEL.EXE she meant KRNL386.EXE, whose module name is KERNEL. In Windows 3.0 (and early 3.1 builds), there's three flavors of it - KERNEL.EXE for Real Mode, KRNL286.EXE for Standard Mode, and KRNL386.EXE for 386 Enhanced Mode. By Windows 9x, only KRNL386.EXE is left.