Wine, WIDE & Unix (was: Support for pkgconfig)

[Dimitrie O. Paun]

On April 27, 2003 12:47 am, Francois Gouget wrote:

> Only as far as commercial companies are concerned. Under the GPL
> license, anyone can fork QT.

And you think this is any way acceptable? I am sorry, but an OS
that puts commercial development at such a tremendous disadvantage
(that is, subject to the monopolistic whims of one company) is
not a platform. So all the portability issues you listed don't
even start to apply.

> So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT
> and instead develop using Win32+OLE+COM?

No! Unfortunately, KDE/QT is in a difficult situation due to the
licensing problem. It is the desktop of choice for most people,
I use it, but I can't see what we can do about it.

> I'm not criticizing, I'm trying
> to clarify because in one of your previous email I had the impression
> that you advocated development against a Win32-based Gtk API.

Gtk is already ported to Win32. App wouldn't even know what Gdk backend
is used, they would be just the same.

> What about graphical applications? In the Windows world most
> applications don't use Win32 directly for the GUI. Should we provide an
> LGPL implementation of MFC?  Implement a replacement for Visual Basic? A
> binary compatible one?

I am mainly referring to graphical apps. And no, commercial apps
provide their own framework just like they do now. It'd be nice to
have efforts toward a free MFC implementation, but it's besides the
point. It's an orthogonal issue.

> What API would open-source developpers use for WIDE applications?

They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot
of free apps (see the top SF downloads for examples) that use the
Win32 API, so it's not something new I'm suggesting? Do you think
it's more moral/ethical to treat these apps as second class citizens
in Linux?

> Yes it would be very cool. I am far from being an expert on OLE/DCOM but
> I have been told that it may be feasible. Probably a heck of a lot of
> work though.

I'm not saying it would be easy. But given that Bonobo was so deeply
inspired by OLE, I'm hoping it can map easily onto an OLE backend,
and maybe that leads to an easier path to integration.

> But AFAICS what's needed is much smaller in scope from what you propose
> with WIDE.

Hm, it seems I have problems communicating. In fact, it seems to me
we have most of the pieces for Wide already.

> Other questions so I better understand:
>  * are you proposing source-level compatibility or binary level
> compatibility?

Both. We get both with Wine, we should be able to keep that.

>  * if it is source level, does it mean modifying gcc to support the
> Visual C++ COM extensions?

It would be nice to have gcc support for those, but this is independent
of the Wide effort. Just like we have support for other stuff that
was added through the MinGW project.

>  * how do you propose to handle the issue of drive letters?

What we do in Wine is just fine. I'm only concerned with GUI apps,
and there I see drive letters as just shorthands to a bunch of
dirs. If you like that, go nuts. I see it as mainly a UI thing,
other than that we'd try to pass Unix paths around as much as
possible.

-- 
Dimi.