Mail Archives: djgpp/1997/05/27/03:11:23
On Mon, 26 May 1997, Samuli =?iso-8859-1?Q?J=E4rvel=E4?= wrote:
> I tried it with int86x like this:
This is the wrong way. The FAQ explains (section 18.2) that you
should only use `int86x' for a limited list of services it supports,
and the CD-ROM services aren't part of them.
> When compiling it DJGPP prompted: "storage size of 'regs' isn't
> known".
You need to #include <dos.h> where union REGS is declared (but as I
said, using `int86' is the wrong way).
> I also tried it with _go32_info_block.linear_address_of_transfer_buffer,
> but it goes beyond my comprehension. I tried it like this:
I tried to explain how this needs to be done in the FAQ (section
18.2). I would appreciate if you told me what exactly is beyond
comprehension there, so I could make the explanation more helpful.
> __dpmi_regs r;
> r.x.cx = CD_Drive;
> r.x.bx = _go32_info_block.linear_address_of_transfer_buffer & 0x0f;
> r.x.ax = (_go32_info_block.linear_address_of_transfer_buffer >> 4)& 0xffff;
> r.x.es = r.x.ax;
> r.x.ax = 0x1510;
> __dpmi_int(0x2f,&r);
This is the correct way (except that you don't need to move the value
through .ax member before you put it into .es member: this isn't
assembly, you just fill a structure and it is later copied into the
registers by `__dpmi_int').
> But of course it won't work like this so I think I should copy the contents
> of RequestBlock to this info block, but when trying to copy it with
>
> memcpy(_go32_info_block.linear_address_of_transfer_buffer,&RequestBlock,size
> of(RequestBlock))
>
> it complains "warning: passing arg 1 of `memcpy' makes pointer from integer
> without a cast".
Why `memcpy'? Use `dosmemput' as explained in section 18.4 of the
FAQ. The transfer buffer is in conventional memory (since real-mode
Int 2Fh cannot access data above 1MB mark), which is outside your
program's data space, so you cannot use ANSI C functions to access the
transfer buffer.
- Raw text -