Linked by Thom Holwerda on Mon 5th Feb 2018 23:08 UTC
Windows

In November last year I wrote about the forgotten and obscure feature of early Windows 95 builds that lets you run Windows 3.1 in a window on Windows 95. Since then I was wondering if this would still work on the final build (950) of Windows 95, considering so much has changed since build 58s.

I won't spoil it.

Thread beginning with comment 653703
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Reminds me of OS/2 2.0
by Drumhellar on Fri 9th Feb 2018 18:34 UTC in reply to "RE[3]: Reminds me of OS/2 2.0"
Drumhellar
Member since:
2005-07-12

What makes an operating system an operating system rather then an application, especially in the (MS-)DOS days?


At the most basic, probably the interrupt handler. When an interrupt is generated by a piece of hardware, the OS is what handles it. When a piece of software generates an interrupt, it is to notify the OS that there is work to be done.

When Windows loads, it nukes the DOS interrupt handler and replaces it with its own. Windows (not DOS) handles both hardware and software interrupts. The hardware is interacting with Windows directly, not DOS.

Reply Parent Score: 2

RE[5]: Reminds me of OS/2 2.0
by leech on Fri 9th Feb 2018 20:29 in reply to "RE[4]: Reminds me of OS/2 2.0"
leech Member since:
2006-01-10

I could be completely wrong about this (first version of Windows I ran extensively was 95, I only did troubleshooting for 3.1) but wasn't 3.1 a 16bit only operating system, and indeed was just a Shell on top of DOS? It wasn't until '95 that Fat32 was introduced (in it's buggy form). There were a few different DOS shells out at the time prior to Windows 3.x becoming more popular.

Edit: Yup, at least according to Wikipedia; https://en.wikipedia.org/wiki/Windows_3.1x

Edited 2018-02-09 20:30 UTC

Reply Parent Score: 2

RE[6]: Reminds me of OS/2 2.0
by ssokolow on Sat 10th Feb 2018 03:22 in reply to "RE[5]: Reminds me of OS/2 2.0"
ssokolow Member since:
2010-01-21

While it exposed a 16-bit, cooperatively multitasked API originally developed for an earlier version of Windows, Windows 3.1x pioneered many of the backwards-compatibility hacks that Windows 9x perfected.

In addition to having its own EXE format separate from DOS and introducing The Registry, Windows 3.1x had protected mode drivers and various 32-bit subsystems, but it used DOS as its bootloader and legacy driver API.

(That's why Windows 95 has CONFIG.SYS and AUTOEXEC.BAT. Because "anyone who doesn't care about legacy hardware support will buy Windows NT", Windows 9x did some startup hackery where it would take over from things like HIMEM.SYS while booting and then perform surgery to transfer any hacks applied to them into itself so that any drivers for things like backup services which had hooked the DOS infrastructure would get monkey-patched into the Windows 9x operations.)

One example of that is how Windows 95 would slow to a crawl while performing floppy disk I/O, because it had to go through BIOS routines that might have been hooked by 3rd-party software.

(Source: The Old New Thing)

Also, trust me on this. Windows 3.x is a LOT more than a desktop shell. The memory management implementation alone bears much more resemblance to classic MacOS.

(Source: I have a big pile of books on Windows 3.x APIs and internals that I bought for retro-hobby programming with OpenWatcom C/C++.)

Edited 2018-02-10 03:28 UTC

Reply Parent Score: 2

RE[6]: Reminds me of OS/2 2.0
by Andre on Sat 10th Feb 2018 21:56 in reply to "RE[5]: Reminds me of OS/2 2.0"
Andre Member since:
2005-07-06

FAT32 was introduced in Windows 95 OSR2 (version 4.00.950B) and it's accompanying MS-DOS version 7.1

My experience with the Windows 3 series was Windows for Workgroups 3.11. This version of Windows only has the "386 Enhanced" mode, where 3.1 also had a "Standard" mode, and 3.0 even included the "Real" mode.

This "386 Enhanced" mode uses the Protected Mode to run Windows applications and the V86 mode to run MS-DOS applications. The Windows applications it supports are 16 bit Windows applications, however, one can install WIN32S to add some limited support for 32-bit Windows applications.

So, technically, Windows 3.1 is not 16-bit only.

Reply Parent Score: 1

RE[5]: Reminds me of OS/2 2.0
by Andre on Sat 10th Feb 2018 21:47 in reply to "RE[4]: Reminds me of OS/2 2.0"
Andre Member since:
2005-07-06

But any software that uses for example a sound card running on (MS-)DOS, has to handle the interrupts created by the sound card. That's the point, MS-DOS and compatibles are so basic in nature, that almost any hardware related stuff has to be done by the application itself.

Nowadays we are used to operating systems with drivers that handles all hardware, but MS-DOS was barely doing anything more then provide access to the file system and load applications.

Reply Parent Score: 1

Drumhellar Member since:
2005-07-12

While that's largely true for sound cards, it isn't true for printers, network cards, disk controllers, serial ports, or parallel ports.

And, it isn't even universally true about sound cards, which later on often had TSRs to emulate a SB16 interface for DOS apps.

And, even then, if (and, for non-sound card devices, is a big IF) DOS's interrupt handling wasn't more complex than "Let the program do it," it was still replaced by the Windows interrupt handler.

Reply Parent Score: 2

Drumhellar Member since:
2005-07-12

[qbut MS-DOS was barely doing anything more then provide access to the file system and load applications. [/q]

Windows 3.x used a new 32-bit protected mode driver for handling filesystem access, which allowed multiple windows apps and multiple DOS virtual machines to access the underlying fulesyete concurrently.

I have a feeling Windows handled loading of Windows apps.

If that's all DOS did, then once Windows was launched, it's was no longer doing it

Reply Parent Score: 2