Multitasking
*network applications* in Windows 3.1 works fine, just because in Windows 3.1 you can only use the "SmolNet" also known as the "Slow Net". Heavy web pages with 500 KB of constantly-running JavaScript are NOT going to happen no matter what - firstly, because the web browsers available for WIndows 3.1 don't have any modem JavaScript Engine to allow for that, and then because the memory model of Windows 3.1 would crash to a hard reboot even before the problem of scheduling such heavy web applications would be a consideration at all. Also, my Windows 3.1 install is running it's ethernet at 10 Mbps (16 bit PCMCIA NIC), so the bottleneck for network apps would be the bandwidth before the CPU.
In Windows 3.1, I can browse the gopher-sphere in Netscape Navigator while doing IRC and simultaneously having a PuTTY/SSH/Telnet session active, and even run a (slow) big FTP download in the background, no problem at all - because none of those operation are CPU-intensive, nor are they memory-hungry.
However, the CPU scheduling indeed is lacklustre in Window 3.1 when
*CPU-intensive apps* are fighting for that resource, which becomes even more noticeable considering that Windows 3.1 is usually run on weak/vintage CPUs (by today's standards).
For example, when in Windows 3.1 I launch PuTTY to connect to a SSH server, the initial cryto negotiation (*before* even the login prompt appears on PuTTY's window) takes 1 minute and 12 seconds (measured with a stopwatch in hand) - although once the SSH connection is established PuTTY works smoothly. During that time doing the crypto negotiation, this Intel Pentium 75 MHz CPU is maxxed out.
Now, let's consider that this Pentium 75 CPU *cannot* play a stereo 192 kbps MP3 file of size 2.20 MB without stuttering and producing crackling sounds, using the official WinPlay3 v2.3 application for Win16 from the Fraunhofer Institute. However, if I configure that MP3 player's options to use "Frequency: Half", then that MP3 file plays nicely without any audible defects (at least, without any defects audible through the laptop's integrated stereo speakers). So we can assume that the reproduction of that MP3 file was also maxxing the CPU.
And then, if I play that MP3 file in the background while I launch a new SSH session in PuTTY, I see this happen: sound stops playing completely after 10 seconds of PuTTY running, and it's totally silent until second 41, when it is heard up until second 49, and then goes totally silent again until the 1 minute and 25 seconds mark, when PuTTY has finalized the crypto negotiation and is displaying the login prompt, and from that point on the MP3 sound is heard normally in the background while I work in the PuTTY's SSH session.
A fair CPU scheduler would have made the PuTTY negotiation in that scenario take much longer while allowing more CPU time to the MP3 player. But notice how here the PuTTY crypto negotiation only took 13 seconds longer than usual while the MP3 was playing-close-to-maxxing-the-CPU in the background. Clearly, the CPU scheduler in Windows 3.1 is NOT preemptive multitasking, and that is indeed
*felt* with CPU-bound apps when the CPU is maxxed out.
Obligatory screenshot:
