Date: Thu, 25 Apr 1996 00:50:43 -0800 (GMT) From: "Rafael R. Sevilla" To: mdruiter AT cs DOT vu DOT nl, DJGPP newsgroup mail Subject: Re: djgpp compiling in 4 megs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The only thing I can think of that causes that (print-screens in unexpected places) is a very odd instruction which Intel introduced with the 80186, namely BOUND. Officially, what this instruction does is check array bounds with its two arguments an index and a pointer to the start of the array (which should begin with the array's limits), and if the index happens to be outside the array bounds, it issues an INT 5, which, quite unfortunately, IBM appropriated back in '81 for its BIOS printscreen interrupt. This didn't cause problems for the original PC and XT, which both used the 8088 and consequently didn't recognize the BOUND instruction. But come the 80286 and the AT, and subsequent more advanced processors, this caused some fairly serious problems. A bug that caused a jump to a byte that contained 0x62 (the BOUND opcode), will probably cause the "bound exception," as its two arguments will hit some random spot in memory, and the success or failure depends on what's in the next few bytes... And what's worse, the CS:EIP pushed by the exception interrupt will be the address of the errant instruction, and once PrtSc returns it will of course fail again, print the screen again... DISASTER! I don't think BOUND gets a lot of use, as C/C++ code doesn't need it (does the C standard say anything about checking array bounds?), and that probably excempts all the programs you've mentioned, *provided they were written correctly*. Now if there were a bug in some program you're using that did that fatal jump to a BOUND opcode, now we're getting somewhere. Blame Big Blue and their BIOS. Intel warned us that it reserved INT 00-1F for its own internal use, but Big Blue just *had* to use Int 5! And btw, I'm also using djgpp under 4MB, and on a 386 to boot! But then again, I've never used GRX20, nor cc1plus. Almost all my work is confined to C, and I haven't had any serious problems. Yet :) ------------------------------------------------------------------------- University of the Philippines Rafael R. Sevilla PABX/OVCA: Diliman Networking Project rsevilla AT sauron DOT upd DOT edu DOT ph -------------------------------------------------------------------------