Mail Archives: djgpp/1997/03/10/12:24:43
>> #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 -