Mail Archives: djgpp/2001/06/30/04:30:09
"Charles Sandmann" <sandmann AT clio DOT rice DOT edu> wrote in message
news:3b3d0f21 DOT sandmann AT clio DOT rice DOT edu...
> > As for cwsdpmi, prior to my original post I attempted mapping A000:0000
> > through the following code (My code actually checks return values, but I
> > figured it was best to keep the post shorter):
> > __dpmi_meminfo info;
> > info.address = 0;
> > info.size = (320 * 200);
> > __dpmi_allocate_linear_memory(&info);
> > __dpmi_map_conventional_memory_in_memory_block(&info, 0xA0000);
> >
> > The first call failed with error code 1284 (504h). I looked in the DPMI
spec
> > for function ax=504h and this is not listed as an error code. The DPMI
> > server doesn't set an error code, but it sets the carry flag indicating
an
> > error. I made absolutely sure of this by attempting the same call using
> > int386.
> > I don't see what I'm doing wrong, if this is supposed to work?
>
> First, don't use the allocate_linear_memory call. It's not supported. I
> would suggest malloc'ing a buffer (add an extra 4095 bytes), align it to
> be 4K aligned with a mask, add __djgpp_base_address to correct for the
> selector base. Then pass this address and truncated size to the
> map conventional memory call. I don't have an example handy.
Well *sigh* I am exasperated. I spent a day or two working on that, and
after I took out the __dpmi_allocate_linear_memory call as you suggested, it
worked. Thank you.
...and now my little rant
I can't figure out why DPMI will not support the allocate_linear_memory
call, especially when the implementation is so trivial. It might even be
acceptable for cwsdpmi to not support this, but the DPMI server in Win9x
doesn't support this call when the OS makes it available to Win32 apps via
VirtualAlloc. (?!!?!)
...Go figure.
Annoyed at DPMI, but Grateful for the Assistance
-Matt
- Raw text -