Mail Archives: djgpp/2001/05/26/03:01:41
> From: "Alex Oleynikov" <alex AT compuweigh DOT com>
> Date: Fri, 25 May 2001 15:59:23 -0400
>
> >You don't check the return values of these three function calls.
>
> Actually, I do, but for the simplicity of the code snippet I just stripped
> all extra stuff.
It is usually best not to remove parts of your code when posting it.
> >something _is_ wrong with the selector you got from
> >__dpmi_allocate_ldt_descriptors: it seems to be a selector for code,
> >not for data (bit 3 of the selector is 0 instead of 1).
>
> I am a little bit confused here. DJGPP help says, that bit #3 of a
> descriptor has to be set for code segments and cleared for data segments.
You are right.
> (BTW, how do you know whether it is code or data segment just by looking at
> the selector's value? Isn't this information available only from the
> descriptor to which this selector points in the LDT?).
The selector itself (c7) looked to me like a code selector. Charles,
did I miss something?
> What _is_ amazing, when I upgraded to CWSDPMI r5 after your suggestion and
> used "near" pointer access to the SRAM memory:
>
> if( __djgpp_nearptr_enable() )
>
> Window_Base=(char *)(mapping.address + __djgpp_conventional_base);
>
> everything began to work fine! Before the upgrade this code was also
> breaking down with SIGSEGV exception.
As Charles explained, this particular example hits the bug in r4 which
was corrected in r5. So upgrading is the right solution.
- Raw text -