Question on an old 16-bit application RRS feed

  • Question

  • We have a legacy 16-bit application that we still support.  It was originally designed for Windows 3.1 (remember that?) and its architecture requires a "feature" of 16-bit DLLs where different applications could share the memory space of a common DLL.  In the example, the central admin.dll stores the state of the logged in user to the application.  Other "modules" can then call that DLL and read and update the state.  This has worked all the way up to Windows XP.

    As we know, in the 32-bit world, and the more secure world of application programming, we wouldn't want to allow different applications to "borrow" the memory space of a DLL, so each application gets its own instance of the DLL, but it seems there was an exception made for 16-bit DLLs, probably for compatibility's sake.

    Can anyone confirm if Vista has now prevented shared memory space of 16-bit DLLs?  It appears so, because this legacy application now refuses to run correctly.  On the surface it appears that they are no longer able to get the shared state from a single common DLL and are instead getting their own copies.

    My questions to those in the know are:

    1) Has the support of shared memory of 16-bit DLLs changed in Vista?

    2) Is there any workaround to enable it for a specific set of executables and shared DLLs?

    Friday, February 16, 2007 5:10 PM


All replies

  • 16-bit isn't supported on 64bit Vista

    But for 32 bit it is. Correct me if I'm wrong but the shared memory set by going to the properties of the exe/dll right? I think these properties still show up, but to modify them safemode works and some other trick. I think there is a posting in this forum on this somewhere.
    Saturday, February 17, 2007 7:29 PM
  • I would recommend reading the following article.



    Monday, February 19, 2007 9:20 PM
  • I forgot to clarify that we are unable to modify this 16-bit application, so we're hoping there are some file settings or registry settings that can make it work for these DLLs...
    Tuesday, February 20, 2007 6:46 PM
  • I've currently got some developers looking into this issue, thanks for your patience.
    Wednesday, February 21, 2007 1:04 AM
  • Hi Blaine

    I am glad this issue is still alive, I have posted similar details and a raft of tests of I have previously done to another post about running win16 apps and sharding data via a win16 dll (have a look at the last entry).


    Sunday, February 25, 2007 9:56 PM
  • Hi


    Is this issue still alive ?



    Wednesday, May 16, 2007 3:27 AM
  • Apparently not... we are just having to tell our customers that they shouldn't upgrade to Vista if they want to keep using the program.  So far, that has been okay with them.  But if IT groups start slowly adopting Vista, then our application is out of luck.


    I would like to know if anyone has found a solution...

    Wednesday, May 16, 2007 6:09 PM
  • Thanks Blaine


    We are taking the same position regarding using Vista at this stage.


    Wednesday, May 16, 2007 8:32 PM
  • Hi Blaine


    I have just worked out how to get this working.

    I wrote a win16 app called runapp.exe and used winexec to start the other win16apps.

    They will then all run together.

    I have verified operation with my main win32 app, there is quite a bit going on transfering data back and forth between win16 and win32 and all works as expected.


    The only funny thing to note is that when runapp has started the other win16 apps, then Task Manager Processes tab does not show the other win16 apps. Perhaps this is just because runapp just starts the apps and then exits without creating a window.




    Wednesday, May 16, 2007 9:45 PM