Distributing multiple Qt applications?

[gfunk]

(Under Windows) Normally when I distribute a Qt application, I distribute all the necessary Qt dll's along with the exe.

Suppose I distribute multiple Qt applications - it seems like I will have to distribute multiple copies of the dll's... unless all the application exe's are installed to the same folder. Except I can't guarantee that the user will want to install each app in the same folder... wondering if there's an alternative.

[marcel]

Yes. Copy all dependencies to %SYSTEM_ROOT%\system32( meaning c:\windows\system32 on most systems).

Regards

[Eldritch]

Ewww! I really despise treating system32 as the universal dumping ground for DLLs.

There are other problems with this, too. Say some other application decides to do the same thing, and puts a different version of the DLLs (say, 4.2.1, or 4.4, someday). It's possible your application is broken then.

The easiest way is to do side-by-side, which, yes, means multiple copies of the Qt DLLs -- one for each application.

Another is to use static libraries and statically link in Qt.

A third option is to get fancy with your build in Windows and use the delayload option along with the helper function you can implement. That way, you could specify your own location for Qt DLLs for your apps, and have your helper function figure out where to look. Not sure if Qt / Trolltech already offer something to assist with that.

Check here (http://msdn2.microsoft.com/en-us/library/151kt790(VS.80).aspx) for more info on that.

[gfunk]

Yeah, I could do static linking, but it would still leave about the same size footprint.

I agree on the system32 thing, it could cause nasty interactions with other Qt apps. Especially since it uses the same QtCore4.dll, QtGui4.dll, etc., for all Qt 4 versions (Qt4.1, Qt4.2, Qt4.3, etc) Kind of a shame there's no system in place to handle the possibiility of all these versions coexisting.

I wonder if Qt could do something like how Sun's Java keeps multiple versions of the JRE on the computer... but I don't really know enough about how that works - that's probably a whole different mechanism/system entirely.

I can't seem to figure out if delayload can actually load the DLL you want it to at runtime... will have to look into it more.

[Eldritch]

The key to the magic of delayload is to customize the helper function mentioned in that page. Rather than YOU needing to call LoadLibrary and GetProcAddress for every Qt class / method your code uses (ugh!), the delayload feature does it for you. It uses the standard DLL search rules to locate the DLL being delay loaded.

That's where the helper function comes in. You can use it to customize where to look for delay loaded DLLs. So you could create a /gfunkSharedFiles/ directory containing the version of Qt you support, and use the helper function to point the delay loader to your directory for locating Qt DLLs.

As to footprint / static linking... The impact on footprint all depends. Statically linking should result in only what your app actually uses being linked in, contributing to your footprint. But if you don't use large chunks of the Qt DLLs, but distribute them anyway, you're effectively wasting footprint, too.

It's all just tradeoffs between speed / size / ease-of-distribution, and it's up to you to choose your pain. :D

[Brandybuck]

Dumping every DLL in system32 is what leads to "DLL hell". However, that is the way things are done for system libraries. You could create your own Qt runtime directory (C:\gfunksoft\qt) and use a manifest for your application.