2

Some days ago, I felt a bit nostalgic and grabbed the good old Microsoft Entertainment Pack from some site. The package has some cool games that were designed for Windows 3.1 and they are 16-bit programs. They didn't run on my new laptop with a 64-bit OS, (well, obviously). So I ran them on my old machine that has a 32-bit Windows XP.

Now I can play with these games. But the problem is, my machine overheats while running them. I closed all other programs and monitored the resources and realized that apparently, these games consume 100 percent of the CPU whenever I run them.

Since the games are simple with primitive graphics and don't seem to be that resource-hungry, I think the problem arises from the fact that they are 16-bit programs running on a 32-bit system. So, why does this happen?

polfosol
  • 121
  • 3
  • 2
    I'm not entirely sure, hence this is a comment, not an answer. But I do know that on a 32-bit system, the 16-bit subsystem is fully emulated. Because emulation is a factor here, CPU usage will always be higher than normal. – LPChip Jun 19 '19 at 12:28
  • 2
    Still sounds like a bug in the emulation layer though. – u1686_grawity Jun 19 '19 at 12:30
  • 2
    Sounds like a bug in the application. Plenty of 16-bit applications work perfectly normal on 32-but Windows. – Ramhound Jun 19 '19 at 12:48
  • 4
    I think programs back then weren't very well designed to share cpu resource with other applications even in cooperative multitasking. (DOS for instance did not have an idle process - although you can install one in DOS VMs nowadays). CPUs just used to run at full whack all the time, there was no throttling or stepping. If these programs were written back then it's possible they just use any cpu resource available ? Can you run them in a win 3.1 compatibility mode or anything? (I can't remember if such an option existed in WinXP) – Smock Jun 19 '19 at 12:49
  • 3
    My first guess is that they use a busy loop to poll for user input. Back then, polling wasn't seen as a bad thing like it is today, and even ignoring that, it's dead simple compared to handling the events asynchronously. – Austin Hemmelgarn Jun 19 '19 at 18:55

0 Answers0