I have an installer that contains merge modules for some libraries, that I don't think are needed to be distributed.
OLEAUT32.msm: for Windows NT and Windows 95
GDIPlus.msm: GDI+ library redistributables
MSCOMCTL.msm: Microsoft Windows Common Controls
Maybe it made sense many years ago (product is old, same the installer), but as far as I know all these are part of the operating system now. We don't support anything older than Windows XP. The only reference I found to them was on the InstallShield page. I don't know if they were official Microsoft merge modules or just built by InstallShield. But don't think they are needed. Especially there are no references to them any more, neither for 32-bit or 64-bit.
Well... Install Shield is helping us to include these merge modules, may be if these modules are missing in any machines (which is very very rare) then, installer will take care of having these modules installed.
Even in my application installations, I can see all the 4 merge module are getting included. I guess it is a good idea to try creating setup without including these merge modules, and see how setup behaves.
Please let us know, if you try by omitting these modules
Since XP, we have Common Controls V6. If your app is manifested for V6, then distributing the dll isn't even possible anymore since ComCtl V6 is no longer redistributable.
If you run with ComCtl V5, then depending on what feature set you want to support and what OS versions you want to support those features on, an updated version may be needed.
You're saying XP is your lowest target. Since XP has the latest version of the V5 common controls, you don't need to install this anymore.
COMCAT (whew, this is an oldie ) is the Component Category Manager Library, it's part of the early ActiveX support dll's. You needed this if you also wanted to install/use ActiveX components.
IIRC, you'll need this on 95/98/ME and 2K assuming you have merge modules (activeX) that are dependant on this. Off the top of my head:
- old versions of opengl (and the opengl utility lib)
- Older versions of VB and FoxPro required this (because of heavy reliance on activeXfor forms etc).
I would say it's rare though not impossible that you need this in a C++ project. If you do need it, it's more likely because of non C++ code in the project (VB/FoxPro... parts) or third party libs/components depending on it.
If XP if your lowest target, then you shouldn't need this anymore, unless you have really old components that hard-link into ComCat rather than doing it the "proper" way.
Last edited by OReubens; November 17th, 2010 at 10:03 AM.
Well then you don't need to ship the comctl merge module anymore. The best you could do to anyone is update their V5 or V4 controls (depending on which comctl it is), and then end up using V6 anyway. But since you say you only target XP and up, they'll already have a more recent version of that so the merge module is pointless.
COMCAT is harder to single out. The merge module shouldn't be needed on XP and up (there's a preinstalled one), but I know for a fact that an old version of opengl hard linked to it. And we also had some 3rd party components that copied that hard link approach (another case of bad code samples perpetuating).
So unless this is a very recent msm that might update the comcat that comes with XP and up (I'm not aware of any upgrades to this), it's fairly safe to skip this one also.
MSCOMCTL.msm. The common controls funtionality in this package added list and tree view support OS's plus quite a few other enhancements.
I thought list and tree controls were available in Win9x and NT4 and definitely included the updated common controls in an app I built that ran on these OS's, but I forget the exact details. Certainly by Win98SE and Win2K, this was no longer required.
In my app, I used the 40comupd.exe installer package.
I found an 1998 MSJ article that talks a bit about it: