From: Mitch Randall Newsgroups: comp.os.msdos.djgpp Subject: Re: Lauching ASPI from DJGPP Date: Thu, 25 Sep 1997 09:13:47 -0600 Organization: National Center for Atmospheric Research Lines: 35 Message-ID: <342A7FAB.5554@ncar.ucar.edu> References: NNTP-Posting-Host: mitch.atd.ucar.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk > Eli Zaretskii wrote: > > I cannot be sure without seeing the original Watcom code, but I think > the following is the source of your trouble: > > > /* point real mode data structure to real mode entry point */ > > regs.x.cs = aspientry >> 16; > > regs.x.ip = aspientry & 0xFFFF; > > It should say instead this, I think: > > regs.x.cs = aspientry >> 4; > regs.x.ip = aspientry & 0xF; > > Real-mode addresses are formed by segment*16+offset. Multiplication > by 16 is equivalent to a shift by 4 bits, not 16. I noticed that myself when I dug up the watcom code after not having seen it for a couple years. However, the variable aspientry comes from an IOCTL call: handle = _open("SCSIMGR$",0); numbytes = ioctl(handle,DOS_RCVDATA,4,(int)&aspientry); the integer aspientry is just a convenient place to put the 16 bit segment and 16 bit offset which is returned by the SCSIMGR$. The code would have been more readable if I had passed the address of an array of two shorts. However, I've verified that the contents of the dpmi structure (cs and ip) are identicle in the working watcom version and the non-workiing DJGPP version. I've also just printed aspientry in both versions and compared; they are identicle. Any other suggestions? Mitch Randall