none
Exiting a 16-bit application that uses .NET RRS feed

 , 
 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    (First, sorry for duplicates)

    Message:
    Hi,

     

    Our company still has to support legacy products written in 16-bit (MSVC 1.52).  We "thunk" from 16 to 32-bit very often without any issue.

    Recently, I have felt the need to use the nice features/classes offered by .NET and so I would load and unload (via LoadLibrary and FreeLibrary) a VC++ CLR enabled dll that will make use of .NET classes .  All works nice except when I exit my 16-bit application "hosted" under ntvdm, the 32-bit CLR dll that made use of .NET seemingly stays in memory and I cannot rename the folder from which my 16-bit app was running from as a result.

    The function FreeLibrary does return true and no matter how simplistic my usage of .NET classes may be, I cannot get it to release my folder.  If I choose to make my 16-bit app to run in a separate memory space (shortcut option) then I am able to rename my folder but I want to know if there is a different solution than this workaround.

     

    Thanks.

    ---

    More:

    As previously suggested by another user, I tried to use VS2010 and .NET 4.0 instead of VS2008 with .NET 3.5 but it did not solve my problem unfortunately.  The issue arises as soon as I make this 32-bit DLL "/CLR" to reference even basic System assembly.

    I would appreciate either a solution or an official statement that there is no solution for this.

    Thanks again.


    • Edited by Luu Danh Thursday, October 20, 2011 5:30 PM more appropriate wordings
    Thursday, October 20, 2011 5:25 PM
    |

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Recently, I have felt the need to use the nice features/classes offered by .NET ...

    The voice of experience should have spoken up at this point telling you to resist this temptation. You are mixing a 16-bit application with a technology which didn't come out decades later. Despite Microsoft's tremendous accomplishment in supporting 16-bit applications in a 32-bit world, one can expect difficulties with this issue. It's not that this is problem that is not solvable, it's just that you probably tried to take a short-cut which has actually created a needless problem which is now embarrassing to you (since it now introduces a bug).

    Using Sysinternal's Process Monitor, monitor your application and the loaded DLL's and see what happens when you shut down the program. Something is getting stuck in memory, and that something may be holding onto the .NET runtime. My gut tells me that it could be the WOW VDM system that is still running, and perhaps your efforts could be directed at somehow closing it down. Or better yet, get rid of the .NET dependence. In the long run, I suspect the latter will be the better choice.


    • Edited by Brian Muth Thursday, October 20, 2011 9:00 PM
    • Marked as answer by Rob Pan Friday, October 28, 2011 8:47 AM
    Thursday, October 20, 2011 8:59 PM
    |