Too many 16-bit programs



  • My main OS at work is Windows 7 Professional 64-bit. As most of you probably know, 64-bit Windows cannot execute 16-bit programs; if you need 16-bit application support you need to use 32-bit Windows.

    Which makes this error message very unlikely and unusual...

    I simply clicked OK and went on with life, and never saw it again.



  • Is config.sys even around anymore?


  • FoxDev

    @hungrier said:

    Is config.sys even around anymore?

    Not that I'm aware of…



  • Quick! Forward this to Raymond Chen!



  • increase the value of the FILES command in your Config.sys file.

    So if my Config.sys contains:

    FILES=40
    

    then I probably want to change it to something like:

    GILES=40
    

    because GILES is higher value than FILES, right? That's what they mean, right?



  • Filed under: $string++



  • FILET=40?<no


  • Discourse touched me in a no-no place

    Forty of these? That's… awesome and expensive and way more than I can eat in a reasonable amount of time.



  • So, I posted the error message as a comment on The Old New Thing, and a couple of lurking commenters there came out of the shadows with explanations:

    that message is string 0x2103 from shell32.dll.mui. A quick scan of shell32!_ExecErrorMsgBox shows this is displayed when one of the arguments is 4 (ERROR_TOO_MANY_OPEN_FILES). That function also displays "Windows cannot run this program because it is not in a valid format." when that argument is 11 (ERROR_BAD_FORMAT), so my guess is that for some reason ShellExecute is returning ERROR_TOO_MANY_OPEN_FILES, and the shell's message for that situation hasn't been updated in a long time.
    The number of handles in a Win32 process is limited to about 16.7 million (very nearly 2^24 - 1). That's due to handles being 32-bit values with 8 bits reserved for a handle re-use count. (This is the current architecture: 64-bit code should never assume that the upper 32 bits are unused.) The actual handle tables are allocated from paged pool. The machine in question either has some Explorer plug-in installed which is leaking handles, or something is leaking paged pool. In normal use, the likelihood of running out of handles is so low that I'm not surprised that the message hasn't been updated. This all assumes that it isn't some rogue plug-in changing the last error code before Explorer itself actually sees it. Information from [blogs.technet.com/.../3283844.aspx](http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx)
    yeah, I assumed that this would be a plugin, given the improbability of running out of handles and Explorer not dying shortly afterwards. A quick look at some of the custom columns in task manager would be a worthwhile sanity check, though.


  • The only Explorer plug-ins I know I have are Notepad++ and TortoiseSVN, which register some stuff in context menus.



  • So TRWTF is Windows code not properly maintained


Log in to reply