press@venice.SEDD.TRW.COM (Barry Press) (01/12/91)
Iv'e been trying to move my windows application development from DOS, with win3 sessions for testing, to a completely win3 (enhanced mode), but something must be escaping me, because there are some problems ... 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. Has any one else seen this? I've tried compressing the heap with heapwalk, and it didn't "forget". Thanks. -- Barry Press Internet: press@venice.sedd.trw.com
risto@tuura.UUCP (Risto Lankinen) (01/14/91)
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 ***************************************
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (01/16/91)
In article <953@venice.SEDD.TRW.COM> press@venice.sedd.trw.com (Barry Press) writes: >Iv'e been trying to move my windows application development from DOS, with >win3 sessions for testing, to a completely win3 (enhanced mode), but something Good move...much faster, unless your app locks the machine, or is a device driver. >must be escaping me, because there are some problems ... > >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. I have never seen this problem you are having. I believe it is more likely that you are not running DOS 4.01 share, and are compiling over top of the executable that is currently running. You then shut down the app, during or after the compile, and try running the "new" version. This can have serious side effects because windows may need to load a code segment from disk in the shutdown of the application. If the exe file has changed, boy howdy!!! (can you say lockaroonie?) >Has any one else seen this? I've tried compressing the heap with heapwalk, >and it didn't "forget". Thanks. Yea Heapwalk's a great app ain't it...(in joke). Seriously, never seen it. >-- >Barry Press Internet: press@venice.sedd.trw.com -- Co-Op Scum "Bo doesn't know software" - George Brett "The galaxial hearth steams the sea as the sky blood red embrasses darkness" -John Constantine (HellBlazer) Glenn Steffler
tdp@stiatl.UUCP (Tim Porter) (01/24/91)
In article <953@venice.SEDD.TRW.COM> press@venice.sedd.trw.com (Barry Press) writes: >Iv'e been trying to move my windows application development from DOS, with >win3 sessions for testing, to a completely win3 (enhanced mode), but something >must be escaping me, because there are some problems ... > >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. > >Has any one else seen this? I've tried compressing the heap with heapwalk, >and it didn't "forget". Thanks. >-- >Barry Press Internet: press@venice.sedd.trw.com I have just begun to learn how to program in Windows, so I can't promise you that my 2 cents will be worth even that much. But I have run into this problem before, so I'll tell you the 2 things that I was doing wrong that you might check for... 1) Make sure you are catching the WM_DESTROY message in your main window procedure and are calling PostQuitMessage() to terminate the main message loop. Catching the WM_CLOSE message and doing a DestroyWindow() is not good enough. It will NOT terminate the main message loop, which means that even though the window has be nuked, to Windows that instance of the executable is still running. 2) Make sure you don't have an iconized version of the program running. (dumb I know, but I did do this) Hope this helps. -- /***************************************************************************\ | Tim Porter emory!stiatl!tdp | | Sales Technologies, Inc Atlanta, GA (404) 841-4000 | \***************************************************************************/