Mail Archives: djgpp/2008/02/25/02:00:26
DJ Delorie wrote:
>> does gcc handle a 64-bit int in 2.03? if so, what type is it called?
>
> "long long"
>
>> I was hoping to see if I could rewrite the existing biosdisk library
>> with the new int13h extensions (as of 1995).
>
> Go ahead. Whether it gets into the djgpp master sources depends, of
> course, on the quality of your code (readability, maintainability,
> backwards compatibility, etc).
>
> Even so, you can always publish your new code and let people download
> it as an extension.
it would be a replacement for BIOSDISK.C. instead of using 1 function
for everything, I am using a number of functions, and I am including
#defines for bits used, masks, error codes, and the like.
I am going to have to do some rewriting - apparently the 64-bit linear
address extensions are not enabled on all machines...
and the standard I was going to use was now based on 2002 draft standard
which includes 64-bit linear address extensions (64-bit memory pointers
or segment-offset addressing, your pick if your system supports 64bit).
http://www.t10.org/t13/docs2002/d1484r3.pdf
The 1998 document also includes 64-bit extensions.
how do I publish the code?
before I can even publish, Is it possible to have 2 separate chunks of
DOS memory allocated and worked with separately using __tb or an
alternative? and if so, how? It looks as if there is only 1 address
I can work with, rather than a separate address for each DOS chunk,
or do I need to capture __tb right after allocation? what type is it
(that go32 long name thing it refers to)?
If I need to capture it, then it lends itself well to a class.
I am trying to understand how __tb relates to the whole DOS memory thing.
I need to allocate a disk buffer in DOS memory, and at the same time I
need to allocate a Disk Address Packet (struct) in DOS memory which
references the disk buffer. Everything revolves around the Disk Address
Packet. It is the Disk Address Packet which allows access to today's
large hard drives (compared to the older motherboards which could not
access very much).
It would be nice if I could encapsulate each of these into a class, but
from the looks of things, dealing with the class is not going to be very
clean-cut. I was hoping to avoid forcing people to poke around inside
the class to get their jobs done, but the current DOS memory access
model seems to be forcing me to. Maybe I'll think of something.
--
Jim Michaels
for email, edit the address
- Raw text -