kehyoe@umn-cs.cs.umn.edu (Ong Keh Yoe) (08/29/88)
Hello, I am currently debugging a package written for Microsoft Windows written in Microsoft C. And I would like to know some information about applications for Windows. First, some information about the application that I am working on. The application calls a second application using a spawnlp. The spawnlp kills the parent using an option for spawnlp. The first application provides a graphical menu-driven environment. The second application on termination then spawnlps the first application. Information to be shared are written by each application to two designated files. Each file created by one of the two applications and destroyed by the second. So fileA is create by applicationOne but destroyed by applicationTwo. And fileB created by applicationTwo but destroyed by applicationOne. First, I would like to know if anyone has experienced that lack of memory has ever caused programs to terminate inexplicably. 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 ? 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. Any information or experience on this is appreciated. Or is the problem the application itself, e.g. writing in memory reserved for the operating system ? Sometimes, the second application terminates properly and spawnlps the first application, but the system crashes (you have to do switch off/ switch on to restart). 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 ? 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 ? Lastly, we used a batch file to run the two applications. First it runs one. When that terminates, it checks for the presence of a file and runs the second and vice versa. It stops when the specified file is not created. But, this also seems to bomb. Yet, when both applications are running independently, there is no problem. Any explanations ? I appreciate any response to the above queries. My net address presently is 'kehyoe@umn-cs.cs.umn.edu'. Or post any of the solutions to the net if you cannot contact me. I wonder how many of you netters I have bored to death already. I hope this topic interests enough people. Thanks Keh Yoe (the happy hacker)
greggy@infmx.UUCP (greg yachuk) (08/30/88)
In article <7050@umn-cs.cs.umn.edu> kehyoe@umn-cs.cs.umn.edu (Ong Keh Yoe) writes: > [ bunch of info about spawning and killing processes and files (yech) ] Sorry, can't help you out on that stuff. >What are the net's experiences using Codeview to debug Window applications >written in Microsoft C ? You cannot use Codeview to debug a Windows program (something about competing for the screen was the pseudo-explanation that I got from MS). You must use SYMDEB, with either a second monitor, or with a terminal hanging from the COM1 port. The documentation for Windows 1.04 gives an example of using COM2, but this hangs the system. I don't know if they corrected it for 2.0x. You MUST use COM1. > 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, See above > Going into Window source (is this possible ?) Not available (as far as I know) > Debugging at assembly level, SYMDEB has a source (e.g. C) level mode > Setting some obscure debug flags on ? You can use the Debugging version of the Windows Kernel. It gives stack tracebacks when things blow up, but I don't REALLY find it to be that much use. > Keh Yoe > (the happy hacker) Greg Yachuk Informix Software Inc., Menlo Park, CA (415) 322-4100 {uunet,pyramid}!infmx!greggy why yes, I DID choose that login myself
rossh@umd5.umd.edu (Hollis Ross Jr.) (08/31/88)
In article <7050@umn-cs.cs.umn.edu> kehyoe@umn-cs.cs.umn.edu (Ong Keh Yoe) writes: > >Hello, > > I am currently debugging a package written for Microsoft Windows written >The application calls a second application using a spawnlp. The spawnlp ^^^^^^^ This seems to be a bad idea, from what I know about windows. As I understand it, windows grabs up all of the memory from the system, and then "distributes" it to the Applications that need it as they request it (Global Alloc, Local Alloc, ect..) Spawnlp would probably erase alot of the resources that windows has loaded. >kills the parent using an option for spawnlp. The first application provides >a graphical menu-driven environment. The second application on termination >then spawnlps the first application. Information to be shared are written >by each application to two designated files. Each file created by one >of the two applications and destroyed by the second. So fileA is create >by applicationOne but destroyed by applicationTwo. And fileB created by >applicationTwo but destroyed by applicationOne. > > First, I would like to know if anyone has experienced that lack of memory >has ever caused programs to terminate inexplicably. 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 ? Memory MAnagment > Third, is it possible to use Codeview to debug these applications Supposedly CodeView is out for Microsoft Windows. I haven't seen it yet. > Fourth, is the Microsoft window programming environment a stable >environment ? Is it reliable ? What are the best tools and methods At times it seems to be not too stable, making you (the programmer) a little unstable, but if you stick with it, you'll pick it up. >of tackling strange errors ? E.g. > Using codeview, > Going into Window source (is this possible ?) If you use Symdeb, you can step thru your code at the C or Assembly code level, get a dump of the stack, print out the value of Globally decalred variables, and even change their values. All of this debugging is done on a terminal attached to com port 1. > Setting some obscure debug flags on ? You can set break points at module entry points, or at specific C statements in Symdeb. > > Keh Yoe > (the happy hacker) Hollis Ross ================================================================================ "Gozer the Gozarian, as a duly appointed represenative | rossh@umd5.umd.edu of the, State, County and City of New York, I do hereby | Bitnet: rossh@umdd command you to cease all paranormal activity and return |--------------------- forthwit to your place of origin, or the nearest | Bill the cat says convient parallel dimension" - Ghostbusters | "Just say Ack!" ================================================================================
brent@well.UUCP (Brent Southard) (08/31/88)
In article <7050@umn-cs.cs.umn.edu> kehyoe@umn-cs.cs.umn.edu (Ong Keh Yoe) writes: > First, I would like to know if anyone has experienced that lack of memory >has ever caused programs to terminate inexplicably. Yes, most certainly. I haven't played with task spawning within Windows, but the very thought gives me the willies. > Third, is it possible to use Codeview to debug these applications... Not yet, but Codeview for Windows (CVW) is coming soon... I don't think it will make things much easier than Symdeb does now, and you'll still need a second monitor or terminal. > Fourth, is the Microsoft window programming environment a stable >environment ? Is it reliable ? What are the best tools and methods >of tackling strange errors ? Yes, it is, but I wouldn't have said that 6 months ago. That's not because MS has cleaned it up so much, but because I've learned much more about the complexities of Windows. Windows is a very well-designed system -- much better than anything I ever expected to see on a MS-DOS machine. As far as tools and methods go: (1) Learn everything you can about Symdeb. Use it. (2) Use only the Windows-supplied memory management functions, and use them carefully. (3) Restrict yourself to the small or medium memory models, and DO NOT fix segments for long lengths of time -- this is perhaps the biggest no-no of them all. No matter what you think, you can fit your program into medium model. Large model programs work to a point, but we started experiencing weird memory overlays at some invisible point with our code. Besides, Windows can't reliably manage multiple applications when there are fixed memory sandbars lying about. (4) See #1, above. (5) Allow for a learning curve, no matter what environment you come from. > Thanks > Keh Yoe > (the happy hacker) Good luck, brent Brent Southard | Everybody's trying to be a friend of mine, Usenet: ...well!brent | Even a dog can shake hands. - W. Zevon CIS: 76657,415 | We fell into love, love's a very deep hole. GEnie: b.southard | - Loudon Wainwright III -- Brent Southard | Everybody's trying to be a friend of mine, Usenet: ...well!brent | Even a dog can shake hands. - W. Zevon CIS: 76657,415 | We fell into love, love's a very deep hole. GEnie: b.southard | - Loudon Wainwright III
cramer@optilink.UUCP (Clayton Cramer) (09/01/88)
In article <390@infmx.UUCP>, greggy@infmx.UUCP (greg yachuk) writes: > In article <7050@umn-cs.cs.umn.edu> kehyoe@umn-cs.cs.umn.edu (Ong Keh Yoe) writes: > You cannot use Codeview to debug a Windows program (something about > competing for the screen was the pseudo-explanation that I got from MS). > You must use SYMDEB, with either a second monitor, or with a terminal > hanging from the COM1 port. The documentation for Windows 1.04 gives > an example of using COM2, but this hangs the system. I don't know if > they corrected it for 2.0x. You MUST use COM1. Time marches on. The most recent issue of MSJ mentions that a special version of CodeView is now (or soon) available to debug Windows apps. I haven't used it, so I don't know how good a job it does. Clayton E. Cramer