[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: corel linux demo

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 <mackay@rice.edu>

Reply to: