Message-ID: <324EDEAA.23AF@cs.com> Date: Sun, 29 Sep 1996 13:40:10 -0700 From: "John M. Aldrich" Reply-To: fighteer AT cs DOT com Organization: Three pounds of chaos and a pinch of salt MIME-Version: 1.0 To: Eli Zaretskii CC: Charles Sandmann , DJGPP Workers Mailing List Subject: Stub error messages (Was: Re: 'Cannot open') References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit [DJVERIFY progress report: I have altered the stub to emit error codes for various failures, and written a batch file to interpret these. The program itself is now capable of running in all three modes and dumping a bug report. I am working on test program compilation right now. I still need information on how to verify the system memory configuration.] Eli Zaretskii wrote: > > On Thu, 26 Sep 1996, John M. Aldrich wrote: > > > Is it a good idea to mention this problem in the batch file's report, or > > can I assume that it will be corrected in a later DJGPP version? > > IMHO, you should mention it, for those who have `djverify' but still work > with binaries from DJGPP releases where the stub still had this bug. Remember, my batch file will only work if the stub has been altered to emit the right error codes. Since only _my_ custom stub will do this, using the batch file on any other program is doomed to failure. I would write a program to interpret the error messages themselves, but such a program would, obviously, have to be written with a compiler other than DJGPP, all of which I discarded when I obtained the latter. :) If someone would like to undertake such a task, I'd welcome their support. If you like, I can post the batch file on djgpp-workers to show you what I've done, along with the diffs for stub.asm. > > Alternatively, should I wait to release djverify until Charles releases > > the corrected stub, and use that instead of the v2.0 one? > > It's a simple one-liner to correct it, so you might as well correct it > now on your machine. I tried putting in the line that Charles recommended, but oddly it didn't seem to make a difference. I tested stubs both with and without the modification after removing my PATH variable, and both seemed to exhibit the same behavior. Do I have to do a PATH-less boot to make the problem show up, or is it sufficient to just type SET PATH= from DOS and try it then? Also, does it make a difference if the stub is by itself or attached to an actual image? As I said, I haven't done extensive testing of this; I'll try more later. :) Finally, since this is going to Charles, I have another question. I have implemented error codes for each of the ten possible errors that the stub code can possibly emit. However, I do not fully understand the possible causes of three of those errors: Load error: can't switch modes. Load error: no DPMI selectors. Load error: no DPMI memory. While I more or less understand what those messages mean, I don't know exactly what could bring them about, or how to solve the problem. As it is, I just have a message saying essentially, "Your system is screwed up - contact the newsgroup." :) Also, what is the error that is supposed to be triggered by having a pre-386 CPU? I recall a flap a while ago that said that there is an bug in the stub that causes it to crash instead of emit an error for this case, but I don't know what the original error message was supposed to be. Is that what "can't switch modes" means? Thanks for all your help! -- --------------------------------------------------------------------- | John M. Aldrich, aka Fighteer I | fighteer AT cs DOT com | | Plan: To find ANYONE willing to | http://www.cs.com/fighteer | | play Descent 2 on DWANGO! | Tagline: | ---------------------------------------------------------------------