Redistributing some Windows DLLs

Hi,

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
• COMCAT.msm
• 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.

Any ideas?
Thank you.

You are right that those dlls must not be redristibuted. You'll find them on any Windows Version since W2K or even before.

VC applications before .NET compilers (First was VC7 in VS2003) normally do need dll redistribution only for custum controls (e. g. date picker) or third party libraries.

After .NET the target machine must have (at least) a .NET runtime. That also applies for unmanaged C++ code in most cases cause the C++ runtime dlls also have .NET components.

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 :D

Thanks,
dwurity

OLEAUT32.msm and GDIPlus.msm are not necessary on Win2K and above. In the case of my app, I'm not 100% sure about the other too.

Interesting!
I use Wise installer since a decade and I never see any .msm file in any of prepared setup packets... :confused:
Well, we never supported Win 95/NT, only 98SE/2000 and above...

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 :p) 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.

Yes, my app is manifested for V6 of common controls. And yes, the app I'm talking about is quite old, yet improved every year. :)

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.

opengl is not on our libraries list. And the version we have is pre WinXP. So as you said it might not be any problem in removing it.

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:

http://www.microsoft.com/msj/0598/c0598.aspx

It's all coming back to me now... (well, not really)