Date: Sun, 9 Jan 2000 09:21:37 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc: DJGPP <djgpp AT delorie DOT com>
Subject: Re: The endless int31 hooking debugging continued
In-Reply-To: <200001061735.SAA06841@father.ludd.luth.se>
Message-ID: <Pine.SUN.3.91.1000109092032.23866J-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
Errors-To: dj-admin AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Thu, 6 Jan 100, Martin Str|mberg wrote:

> > It should be easy to throw together a function that copies the string 
> > into a static buffer (together with any attribute byte, to make its tand 
> > out), then blits it all to video RAM.  If you write this in assembly, you 
> > can forget about the stack.
> 
> Well, that's far over my head. I just want to be able to hook INT31
> and be able to get out some debug info (so I can see where the real
> code goes wrong).

How about using _farpokeb, then?  It's inline assembly, and doesn't
use the stack.  You could write the characters with it one by one.
Clumsy, but works.

Actually, you could even use the assembly instructions from _farpokeb
inlined in your code.

Or, simply remove the call to cputs and see if the crashes stop.  If
they do, you know that this is the culprit.  If they don't, it's
probably a good idea to find and correct the other problem(s) before
you actually do something useful with the hook.