Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!fuug!tuura!risto
From: risto@tuura.UUCP (Risto Lankinen)
Newsgroups: comp.windows.ms
Subject: Re: WinApp Development Under Win3
Keywords: WinApp, Development, Win3
Message-ID: <927@tuura.UUCP>
Date: 14 Jan 91 08:20:58 GMT
References: <953@venice.SEDD.TRW.COM>
Organization: Nokia Data Systems Oy
Lines: 49

press@venice.SEDD.TRW.COM (Barry Press) writes:

>{text abt developing pgms for Win within Win itself}

>When you execute an application and then close it, windows has not
>necessarily "forgotten" about the instance.  This manifests itself in that
>the passed hPrevInstance may be non-zero even if that instance was closed.  
>Because of this, if you recompile an application and try to run it, it won't
>run.

Hi!

Here are a few hints to try:
   - Make sure that any previous compiled executables are ended before
     trying a newly compiled 'version' of the program.  If not so, the
     Windows' program loader will reuse the code of the older version that
     already is loaded in memory.  Or in worst case, either copy of the
     program runs into a point where access to a discarded segment is made,
     in which case almost certainly garbage is loaded from a point in the
     new *.EXE , where that segment was located in the old one.
   - Make sure the 'NAME' in the program's *.DEF file matches the name of
     the corresponding *.EXE .  Windows seems to be using an awkward comb-
     ination of those two to decide whether to reload or not.
   - If you're using DLL's, make sure you provide an exported WEP in order
     to release it from memory after the last application has finished using
     it.  I've also had problems with DLL's compiled with SDK version 2.X ,
     which seem not be unloaded even after the last access to them.  (Also,
     using DLL's compiled with SDK 3.0 with Excel, that seems to be compiled
     with SDK 2.0, are not properly released from memory, ie. LibMain() is
     not called upon subsequent invocations of Excel & the macro sheet using
     that DLL ).
   - See, how the program's behaviour changes, if UnregisterClass() is used
     before the program exits.
   - If nothing else helps, try the HeapWalker's GlobalAlloc(-1) between run-
     ning the instances.  If you still have this problem, there's a really
     good chance that your program is forgetting to release some resource it
     is using (that Windows has your app's name tagged into).

     (A Wild Thought:  Could the 'previous instance' of the executable file
     be the in-memory image produced by the compiler?  Is Windows clever
     enough to see, that other program's [compiler's] data file is actually
     an other program's executable image???)

Terveisin: Risto Lankinen
-- 
Risto Lankinen / product specialist ***************************************
Nokia Data Systems, Technology Dept *  2                              2   *
THIS SPACE INTENTIONALLY LEFT BLANK * 2 -1 is PRIME!  Now working on 2 +1 *
replies: risto@yj.data.nokia.fi     ***************************************