It's because business was the primary market for PCs and Windows 3.11 added a network stack and changed everything. Networking was no longer an arcane science that required 3rd party software. Office networks became almost trivial to set up. The impact of this on the world is impossible to overstate. Everybody who used Windows in this era used Win 3.1(1).
No, it became what some of us called "plug and pray". You plug it in, and it's supposed to work. You install the driver, reboot, uninstall the driver, reboot, clear some temporary files, re-install the driver, try a slightly different driver on the same disk, uninstall the driver, reboot, re-install the driver, and it suddenly works! Then you reboot it and it stops working again.
The reason I always remember 3.1 is that 3.0 was a "big" upgrade, but it was a dog, so they released a vastly-improved 3.1 pretty quickly, so many people got that as the default, and the upgrade was pretty widespread.
This was over maybe a 4-year period in the mid-90s. My memory may be hazy, and I was a university student, so my exposure may have been limited, but myself and my friends never really reference 3.11 because it wasn't used/needed, and indeed most of us used Trumpet Winsock as a TCP/IP stack (3rd party) until the release of Windows 95.
> Despite this capability being mentioned in countless reviews of the success story of Windows, the actual functionality of it is almost entirely undocumented online.
Much of this was already documented online in 2020. https://devblogs.microsoft.com/oldnewthing/20111107-00/?p=91... and https://retrocomputing.stackexchange.com/q/791/278 are examples. (https://devblogs.microsoft.com/oldnewthing/20211129-00/?p=10... came after this article was written, but is worth reading too.)
> while you can probably tell me the name of the OS installed on Macs in 1985, and you can definitely name the most popular way to run multiple DOS programs on the PC in 1995, you almost certainly can't name a DOS task switcher or multitasking environment offhand.
DoubleDOS. And I've never used it: I know it by reputation alone.
Maybe it doesn't fall into the same category and works more like an actual os with a kernel? Like I said, never used it so idk.
There was a time when none of this stuff was settled and a lot of folks threw their hat into the ring.
I used to love the writeups as a bbs operator, lol!
The result of programming getting more accessible obviously leads to a decrease in average quality/skill.
Coming from a 25MHz 486SX with 1MB of RAM to now, it’s disheartening that as a profession we’ve prioritized developer convenience over user experience. That system ran Netscape, Word, Paint Shop Pro, Doom, could play video, music (wav, midi, CD), and more.
Yes and no. An average programmer today does not know nor care about size, speed, compatibility, portability, IRQ interrupts.. we needed to know how to manage all the things. However, back then there were no security bugs other than bypassing passwords and copy protection.
Anyway it was a very interesting read. I don't think I ever used Windows to run DOS applications. I used to start Windows 3.x now and then to run some Windows application, but then I exited out to COMMAND.COM again where I spent most of my time. And then when Microsoft tried to get everyone to switch to Windows 95 I installed Linux instead.
It was a bit limited because you were still restricted to the usual 640kB memory space, and the original program remained in memory, so you typically didn't have a lot to work with. You could do things like file management while still connected to a remote BBS though.
I'm writing a game and it would be nice to load resources for the next level in the background.
Edit: then you effectively have your main loop doing IO and such, while your game loop is a co-routine in modern parlance. The game loop can write a global variable which the main code takes as a hint to start loading file data.
- maintain a, say, ring buffer :) for I/O commands (operation, file handle, offset, buffer address, callback address)
- add requests to the buffer from the game loop
- timer wakes up periodically, splits requests into palatable chunks, completes a portion of the requested work, when it reaches the end it either sets a flag on the request to signal its completion and/or jumps to its callback address
- game loop can periodically check and empty the request buffer or set the requests to self-destruct on completion
Presumably and perhaps more compatibly can also call the DOS function with interrupts disabled but with an interrupt line active (e.g. a timer) and handle it.
