delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/03/10/12:24:43

From: Andrew Crabtree <andrewc AT typhoon DOT rose DOT hp DOT com>
Message-Id: <199703101709.AA266983767@typhoon.rose.hp.com>
Subject: Re: RMCB Help
To: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date: Mon, 10 Mar 1997 9:09:26 PST
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SUN.3.91.970310173846.29057J-100000@is>; from "Eli Zaretskii" at Mar 10, 97 5:47 pm

>> #include <crt0.h>
>> int _crt0_startup_flags = _CRT0_FLAG_LOCK_MEMORY
>>
>> did lock memory.  Are you saying I need to explicitly call lock for the
>> functions and variables?
>
>No, if you included the above setting, all memory is locked.  But you
>should make sure that it is indeed locked, since the startup code
>currently doesn't.  It shouldn't be a problem with small programs and
>machines which aren't too tight on RAM, though.

I'm not sure what you mean by the "make sure it is indeed locked" (I can't
find reference to it in the FAQ).  It shouldn't be a problem as my program 
is under 300K anyway.

> > Originally I was using the go-32 functions, but after reading from the 
> > faq and some of Eli's posts I decided the the dpmi ones were preferred
> > for djgpp v2.x.
> 
> IMHO, this is a wrong decision.  The FAQ suggest to use the `_go32' 
> functions first, in particular if your handler is written in C, until you 
> have a working version.  Only then it advises to migrate your handler 
> into assembly and use `__dpmi' functions.

Whoops - I guess it was just for go32_simulate_int where it caused a 
problem with SS and Flags that _dpmi_int was easier to use.

> 
> > I couldn't get the go-32 functions working either.
> 
> You should have debugged the `_go32' version before switching to `__dpmi' 
> variant.
> 

I would have liked to but I never was able to get my function called when
using go32 which made debugging somewhat difficult.  Maybe since everything
else is working I'll go back and try it first instead of adding an
inline iret.  

BTW - Is the lack of an IRET causing the crash that I see?  Since I 
am breaking at entry to my function I assume it shouldn't affect it 
at that point.

Thanks

Andrew  


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019