Date: Tue, 27 May 1997 10:10:50 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Samuli =?iso-8859-1?Q?J=E4rvel=E4?= <samppa AT writeme DOT com>
cc: djgpp AT delorie DOT com
Subject: Re: Re: FP_SEG and FP_OFF in DJGPP
In-Reply-To: <3.0.32.19970526164326.0068bc78@mbnet.fi>
Message-ID: <Pine.SUN.3.91.970527100940.10847F-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


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.