On Tue, 15 Apr 2003, Dimitrie O. Paun wrote: [...]
But the big thing is that we'll have better binary compatibility than glibc had, a programming API known to *many* people, and a large set of apps aldready written.
I don't understand. In another email you are arguing that only toolkits (Gtk, Qt, Gnome, KDE, wxWindows) should be using Win32 and that Unix applications should use these toolkits. So applications would still be subject to the whims of these toolkits, to that breaking source level or binary level compatibility. And familiarity with Win32 buys you nothing if you are going to code to these toolkits anyway. So Win32 buys applications and application developpers nothing in that scenario.
For applications to benefit from the stability of the Win32 API, they would have to use it directly, or maybe use it via a stable toolkit like the MFC (urgh). IOW, people should write Windows applications and that strikes me as a not so good solution for Unix applications!
There is another issue to consider which has not been raised until now: compatibility with non-x86 platforms. Unix applications *must* work on non-x86 platforms (in my view if they don't they're no good). Winelib is portable... in theory. But in practice the Win32 API has all sorts of portability issues (endianness of resources, endianness of DIBs, often passes pointers via ints, etc.). IMO Win32 is not a mature cross-platform API and that is enough to disqualify it as an API to be used for building Unix applications.
So I would rather put efforts into making sure Gtk, Gnome, KDE and QT are suitable solutions. (or more precisely, have other people put efforts into that ;-)
Look at SF, you'll see that the top downloads are by a huge margin apps that run on Windows.
No problem. Let's run them in Wine on a Gnome/KDE desktop (or fvwm if you're like me). I see nothing that would prevent them from nicely integrating with the desktop environment (be that menus or systray for instance). And any problems there currently are (e.g. z-order of unmanaged windows) should be solved in that environment. Yes they will not have the exact same look as other applications, but it is no worse than Mozilla not having the same look as Emacs, Konqueror or OpenOffice or gkrellm.
I see no need for WIND/WIDE to take advantage of these Windows applications.
(oups, stirring trouble, sorry, just had to add my grain of salt)