Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com X-Envelope-To: cygwin AT sourceware DOT cygnus DOT com Message-ID: <36F7CD6F.3E96F28B@hotmail.com> Date: Tue, 23 Mar 1999 18:20:47 +0100 From: John Mullee Organization: Ex Machina Interactive Architects X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Serguei DACHIAN CC: cygwin AT sourceware DOT cygnus DOT com Subject: Re: Again about physical disks. References: <1 DOT 5 DOT 4 DOT 32 DOT 19990323164244 DOT 0067f22c AT lola DOT univ-lemans DOT fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Serguei DACHIAN wrote: > > This is a known 'feature' of w95; > > the article "PRB: DeviceIoControl Int 13h Does Not Support Hard Disks" > > It's *ugly* - you have to use 'flat thunks'. > > So, if I understand well, the workaround is to make a 16bit DLL for disk IO, > and then call it from 32bit code using so caled "thunk"s. yes... > this feasible under CygWin??? That is, can I compile 16bit DLL using > cygwin???!!! I don't think so! The binary image format is all different; maybe you could cannabilize some older GPL'd 16-bit linker, but I don't imagine this would be rewarding. Why not get NT 8) ( - or - Linux?!?!) > And even if I compile the dll elsewhere (say under MSVC or Borland), will it > be possible later to use this 16bit DLL in cygwin program??? Well, yes, if you wrap it up in a 32bit dll and make it cygwin-friendly > Or, finally, the only solution is to made both a 16bit DLL and a 32bit DLL > (using the 16bit one via thunks) under MSVC and then use the 32bit one from > CygWin??? Basically, yes. > disk will finally NOT REALLY be done under CygWin, and so both the short and Well, not directly to the OS from cygwin functions; no.. Though of course you could always do the necessary hocus-pocus with assembler and god-knows-what to make it 'werk'. In fact, this is what the MS thunking tools do, under the covers. But cygwin has no concept if 16-bit environments (AFAIK) so it's somewhat awkward. To put it Mildly. (americans: this is Irony.) You could cheat with some kind of IPC mechanism - for example, TCP/UDP between a borland-turbo-c 8/16-bit process and a cygwin process. In fact, this would be a _lot_ easier... Remember, also, that the MS development tools themselves have not supported 16-bits for several (3? 4?) years. As for the nuts and bolts of how a 16-bit library could possibly be loaded by a 32-bit process, - sorry, can't remember. look it up! Personally, I think you're barking mad to even consider it. How about setting up a lan and mounting the drive from linux via NFS? This _is_ the nineties, after all... john -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com