Actually I hadn't thought of the fact that you could link a windows program agains winelib to create a native linux executable, but it makes perfect sense. Corel might still need a few ifdef's to work around known problems in wine's implementation of the win32 api, but it would be quite do-able.
--- Anderson MacKay <[EMAIL PROTECTED]> wrote: > Ech, I'm a bit behind on my -devel reading. I hope > this question hasn't > been answered down in another thread. :) > > On Thu, Sep 30, 1999 at 06:49:15AM -0700, Kenneth > Scharf wrote: > > I understood wine as being a library that > intercepted > > win32 calls and redirected those calls into the > > correct X or linux libraries for handling. Corel > > intends (as I understand it) to ship the actual > > windows binaries (.exes) and maybe even .dll's > with > > whatever wrappers are required to run them under > Wine. > > Wine is two things: it's a library for linking > Win32-source programs > under most *nixes, and it's a call interceptor for > ABI compatibility > under x86-based *nixes. The plan (as outlined by > Corel on the Wine > mailing list so long ago :) was to use Winelib to > ease porting the Win32 > sources of Draw, WordPerfect, Quattro, and Paradox > (maybe others...). > The guy in charge of it all on the Corel end is > Gavriel State, who is the > same fellow who headed up the port of CorelDraw! to > the Mac ... they > apparently did something similar to Wine and wrote a > source-translation > library for that port as well. Anyway, I'm pretty > sure the shipped > applications will be native Linux applications, > although they'll be > dynamically linked to Winelib ... very little > difference from how gtk+ > applications link to libgtk, etc. > > > There will probably even be a Wine based program > > launcher that will trigger of an icon for the > > installed program on the desktop or 'K bar'. > Wine's > > ultimate result is to make the win32 API become a > > linux api as well. It would stand beside gtk++ > and QT > > in that regard. Also means that the "setup.exe" > > Exactly ... but I think you're confusing the issue a > bit by bringing > native Windows .exe files into the equation. Were I > Corel (and I'm not, > obviously :), I would ship native Linux binaries ... > the issues involved > are so much less complicated in that case. It's > pretty difficult to do > QA in a binary-emulation environment, if you ask me. > Consider that few > effective debugging tools are going to work at all, > as an example. Wine > includes a debugger, yes, but the purpose of that > debugger is to debug > Wine ... and it doesn't do convenient things like > talk to Emacs, talk to > ddd, etc. Source-compatibility will be much less of > a hassle. > > Just as a status report -- I don't know the current > status, but I do know > that back in mid-spring of this year, Corel (well, > Gav State, actually) > claimed to have Quattro Pro running with very few > glitches when compiled > against Winelib. I'm sure they've come a long way > since then, so expect > to see good things. > > -- > Anderson MacKay <[EMAIL PROTECTED]> > ===== Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or ..... __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com