This is the mail archive of the email@example.com
mailing list for the Cygwin project. See the Cygwin
home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]
Re: Again about physical disks.
- To: Serguei DACHIAN <Serguei.Dachian@univ-lemans.fr>
- Subject: Re: Again about physical disks.
- From: John Mullee <firstname.lastname@example.org>
- Date: Tue, 23 Mar 1999 18:20:47 +0100
- CC: email@example.com
- Delivered-To: firstname.lastname@example.org
- Delivered-To: mailing list email@example.com
- Mailing-List: contact firstname.lastname@example.org; run by ezmlm
- Organization: <http://www.exmachina.net/> Ex Machina Interactive Architects
- References: <email@example.com>
- Sender: firstname.lastname@example.org
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.
> this feasible under CygWin??? That is, can I compile 16bit DLL using
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
> 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...
Want to unsubscribe from this list?
Send a message to email@example.com