Re: corel linux demo
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@example.com> 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
> > 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
> > whatever wrappers are required to run them under
> 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
> 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'.
> > 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 <firstname.lastname@example.org>
Amateur Radio, when all else fails!
Debian Gnu Linux, Live Free or .....
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com