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

[Kean Johnston <kean johnston gmail com>]

> 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.

Kean