X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f NNTP-Posting-Date: Mon, 25 Feb 2008 00:58:39 -0600 Date: Sun, 24 Feb 2008 22:58:37 -0800 From: Jim Michaels User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: 64-bit int? segment-offset pointers? and biosdisk.c References: <4a-dnX9djZFzTSLanZ2dnUVZ_rmjnZ2d AT comcast DOT com> <200802250229 DOT m1P2TK93027736 AT envy DOT delorie DOT com> In-Reply-To: <200802250229.m1P2TK93027736@envy.delorie.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <8bWdnXIf3r-C-l_anZ2dnUVZ_sqinZ2d@comcast.com> Lines: 58 X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 24.20.110.103 X-Trace: sv3-21qOOXg06shBDFSZ2vMzo2ci/GRCjonh7ECpWPWZaMocpCTbByxVJ0vpFIzk+X1J7J/f03IvZiJjEXd!iIDNbb970kgCT/ISHx5wkiWHKIEJY6AsFvj5YUllydvrQvjNuW1JjpCiiX6thuaAm7qgZfgB94I2!BcbPOHnqEk0FfBchf38OPVlOmq8I4w== X-Complaints-To: abuse AT comcast DOT net X-DMCA-Complaints-To: dmca AT comcast DOT net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.37 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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