What does the ntvdm error message "The Win 16 Subsystem has insufficent resources to continue running. Click on OK, close your applications, and restart your machine." mean, and how can it be prevented?
(Interestingly, but presumably unrelated to the problem, the dialog box displaying the message is actually owned by the session's csrss.exe process.)
2 Answers
According to , this error messages occurs when GDI returns a handle higher than 16383 for a call made on behalf of a 16-bit Windows program. The handles could go up to 65535, but evidently they get right-left-shifted by 2 bits before being returned to the 16-bit app for some reason (presumably compatibility with something).
Before Windows XP, this couldn't happen, as only 16384 GDI objects were allowed to exist in any given session, but with XP the limit was increased to 65536 GDI objects. Since GDI evidently only allocates a new handle number when all lower handle numbers are in use, this can only actually occur if over 16384 GDI objects ever exist at the same time in the session.
Rebooting would generally remedy this situation, assuming that automatically-started programs don't eat through the first 16384 handles right off the bat.
If "fast user switching" is enabled, another option would be to log out, log some other account (e.g. "guest") in, and log in again. (The important thing here is to end up with a fresh "session"; if you weren't running in "session 0" to start with, the "log some other account" step is irrelevant.)
The linked page also offers a patch to remove the shifts from wow32.dll. Be warned, though: as the page says, applying this patch might be illegal; furthermore, it might be dangerous, and would certainly break whatever app(s) the shift was added for in the first place.
Ever since computers went from being 16bit computers to 32bit computers people have started seeing this error message. As stated by SamB - there are some ways in which you can coach the program in to running but ultimately - you will see this message again and again. The real problem is, as SamB talks about, that there are now so many other programs that run in the background that the 16K limitation is exceeded just by bringing up your computer. Under a 32bit OS this problem doesn't appear because you have so many more handles that can be worked with. BUT! Your 16bit application can not handle that. It was written to run under a 16bit OS. That means it was meant to run under either Windows v3.1 or Windows v95. Windows v98(se) or Windows vME both are 32bit OSs so even there you would run into this problem.
My solution is - download either Virtual PC from Microsoft (it is free) or download virtual Box from Oracle (it is free too) and install a copy of Windows v3.1 or Windows v95 and run the program under the OS it was meant to be run under.
Now, unfortunately, if you did not keep your Windows v3.1 or Windows v95 diskettes (or CD in Windows v95's case) then you will have to find and buy them. Or you can petition Microsoft for a copy but I do not believe they either kept them or will release them. (Unlike Apple Computer Inc. which has released, for free, DOS 3.3, ProDos, ProDos for the //gs, and Mac OSs up to version 9.x)
So this is my suggestion/answer. For Windows v3.1 and Windows v95 I would lean more towards Virtual PC as it runs under Windows XP really nicely and it also goes all the way back to just using DOS, DR DOS, and even IBM PC DOS or BDOS.
Update: 1/27/2016
To better answer SamB's question about incompatibility (which I did not say). Let's take a look at an 8bit OS. The 8bit OS expected all of the various stacks (call stack, handles, whatever) to be a certain size and to not exceed that size. When you exceeded it - you would get a blue screen of death or maybe your system would just reboot. When 16bit OSs came along the 8bit programs all acted still as if they were running on an 8bit OS system. This meant that if they exceeded the 8bit allocation size they probably would still give you a blue screen of death or your system would still just reboot. MANY companies never cared about whether or not they were crashing computers so long as the customers didn't complain about it. (Commonly called the squeaky wheel syndrome.) Microsoft tried to alleviate these problems by testing as many programs as they could for each OS but the thing is - some programs just would not work under a newer OS. My suspicion (and NOT FACT) is that some of these early stacks were jamb up against another stack so if you overflowed one stack it could adversely affect a different stack. Remember that memory was not cheap like it is today so you tried to cram as much into memory as possible. I, myself, managed many times to crash my Apple ][+ as well as my IBM PC XT simply because I caused the stack to overflow. One of the other problems is (as I said) that there were a lot of bad programmers out there who did not care one bit about cleaning up their programs. So they would allocate memory, stack memory, handles, and all sorts of other things and not release them. Your only hint that this was happening is that your computer would start to run slower and slower until you rebooted it. Rebooting would clear everything out of memory, give all of that back to your OS, and you OS would then run faster again. As I said - it is similar to how TSR or Terminate and Stay Resident programs would work. In today's OSs - many times processes are isolated from other processes and the OS itself takes care of releasing memory back to the pool (as well as clearing the stack or even allocating a new stack to each process so that each process can muck around its own stack but not the OS's stack). The problem though - is older programs from like the 16bit OS era were statically oriented. So the libraries et al were included in to the program. This means it might attempt to override what the current OS is saying it can do. So a 16bit program might say "write to location XYZ" but "XYZ" is a part of the newer OS. So then you've overwritten who knows what and your system can hang or crash because of it. If you also have admin privileges - you REALLY can muck things up. Thus my suggestion to use Virtual PC, re-install the earlier OS - and run the program under the OS it was meant to run under. First - you stand a better chance to be able to run the program there and second - if it crashes all you lose is the virtual system and not your entire computer system.
But it isn't "incompatible" as much as it is "archaic". To really, really simplify you can think of it like this: 8bits = 8K stacks, 16bit = 16K stacks, 32bit = 32K stacks, and so forth. It isn't accurate but it does get across that the different OSs used different sizes for everything. Which is why you have problems when you take something from one OS to another.
Does that make sense?
10
