mcdonald@uxe.cso.uiuc.edu (08/29/88)
>/* ---------- "Mysteries of Microsoft Windows and" ---------- */ I definately like the heading..... > First, I would like to know if anyone has experienced that lack of memory >has ever caused programs to terminate inexplicably. Yes. Most certainly. > It seems that the >memory can easily contain both applications. If the spawnlp kills it's >parent, should the resources of the parent be automatically freed ? And if >not, why not ? Just what does a spawnlp that kills it's parent do and >are there dangerous side effects ? The resources should be freed, of course. I have no idea how it works, but all memory management in Windows is dangerous. >Second, the second application terminates properly and spawnlps the >first application, but the window manager behaves strangely at this >point (menus popup that are whited out, information displayed at the >border of the window is garbage, etc), has anyone experienced this >due to a lack of memory, errors in window management, interrupts, >etc. Those are the symptoms of low memory: it even says so in the documentation - even the USER (not PROGRAMMER) documentation! > Third, is it possible to use Codeview to debug these applications >without significantly affecting the bugs produced (if these are produced >by lack of memory, then Codeview is bound to affect them, correct ?). >What are the net's experiences using Codeview to debug Window applications >written in Microsoft C ? Codeview does not currently work with Windows at all. They are promising that it will - but say (unusual for a software company) that it won't be "real soon now". > Fourth, is the Microsoft window programming environment a stable >environment ? Is it reliable ? What are the best tools and methods >of tackling strange errors ? E.g. > Using codeview, > Going into Window source (is this possible ?) > Debugging at assembly level, > Setting some obscure debug flags on ? >We seem to think we know where the error is, but the consequences of the >error (or errors) is so random, and the conditions that cause it so >random, we are not sure. Any suggestions ? I think that it is "stable" in the sense that it doesn't change often. It seems to be reliable under certain conditions: plenty of memory, few programs, no bugs in the programs. That is, I don't use it regularly, in fact I only use it to test a program I was contracted to write. Doing certain things work fine, but other things consisently bomb. I eventually got my program so that it never died, and ran with lots of small programs (from Petzold's book), but it often dies in Windows Write, and VERY often dies trying to run plain DOS programs. The best advice is to make all your segments FIXED in memory, despite what the documentation suggests. At least start out that way. (My program NEVER ran with movable segments - but then, it executes code in the data segment.) Certainly, there are many useful debugging methods: White magic, Black magic, Voodoo, Sacrificing your first born son ........ other than those, I don't know of any. Doug McDonald
jack@csccat.UUCP (Jack Hudler) (08/31/88)
In article <68600013@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > >>/* ---------- "Mysteries of Microsoft Windows and" ---------- */ >I definately like the heading..... > The best advice is to make all your segments FIXED in memory, >despite what the documentation suggests. At least start out that way. >(My program NEVER ran with movable segments - but then, it executes >code in the data segment.) Don't start out that way! Let me know what program you sell using this advice so I don't make the mistake of buying it. Anyone who can't make proper use of LOCK and UNLOCK should not write windows applications. Why sould I buy something written like a DOS program that eats up memory so no other application can run! -- See above (214)661-8960