Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

That's a really bad idea for several reasons. First, we don't have the
resources to test ABI compatibility on windows, there has been cases where
some versions have crashed windows apps.
Are you talking about ABI compatibility between varying GTK releases or between various Windows releases? If the latter, that has almost never been an issue. Windows is remarkably good with backwards compatibility. If the former, that is trivially solved with better library naming (see my other post in this thread on the topic).

Second, Windows is not as good at managing shared .dlls as Linux is. It can
become a nightmare. You need to either wire up the Side by Side plumbing or
mess with %PATH% to get things right, and both approaches have their own
set of problems.
*cough* ldconfig *cough*. Windows is no worse than other environments in this regard. You have to have a way to inform programs where their "stuff" is, whether its manipulating the PATH, or /etc/ld.conf (which is mainly glibc based systems, other UNIX variants have yet other mechanisms) or whatever. In fact Windows may even be slightly better because you can do it in only ONE place: the registry, whereas on UNIX there are multiple ways (if you are talking about UNIX in the broader sense and not as an alias for Linux).

In the Qt world and other toolkits, most people just bundle their
dependencies. That's the standard and the right thing to do on Windows.
Application developers are in charge of delivering a Gtk+ (and other deps)
version that works for their app.
I highly question the "and right thing to do" part of that. Its the expedient thing to do, its the lazy thing to do, but right? I disagree. A large part of the entire purpose of DLL's is to make them accessible to more than one bit of code. If your view of "bit of code" is as narrow as your application then your statement holds true: you can have 10 .exe's in your application all link against your own private copy of the DLL's and you've saved some space. But there is a much broader scope and intention: making them shared components that ALL applications can use. Like the .Net framework or the various systems-provided DLL's. There is absolutely no reason that GTK can't be treated exactly the same way, and it is my goal to achieve exactly that.

Third, and the most important. Windows has no package manager. You should
not delegate on users the responsibility of making sure that a working copy
of GTK is installed. This is annoying enough with Java.
That's completely irrelevant. While Windows may not have a single command that operates on identically formatted files (and even that is not true - think .MSI) it most certainly DOES have a package manager. It knows exactly what has been installed and where, provides an API for querying that and a central mechanism for various packages to communicate information with each other. Just as Microsoft creates "redistributables" that install specific versions of the runtime or .Net framework or a number of other things that your application can bundle and install if required, so can we provide a "GTK redistributable" that is a single .msi or .exe that application authors can bundle with their application and install as part of their installation to ensure that the GTK they care about is present. That's for end users. For developers, they can use the same redistributable to get the runtime portion, and unzip an extra "development" bundle that has the headers and import libraries.


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