How to correctly ship mscomct2.ocx for Win XP and 10 using NSIS

[OldClock]

Hey

When testing my app and installer on a clean Windows XP SP3 32-bit, it complained about missing mscomct2.ocx. There will be a few other missing files added to the list as I test.
When using wine in Linux I need to install the following: vb6run wsh57 comctl32ocx comdlg32ocx richtx32 mdac28.

What is the correct way to provide mscomct2.ocx (and other files) with my NSIS installer?

[OldClock]

P.S. I read that one should not use regsvr32, and I read that one should not ship files from one's own system, so what should I use and where should I get them from? In the case of the VB6 runtimes its easy because vbrun60sp6.exe has them, but what about the other files such as richtx32 etc?

[Elroy]

Personally, I've used the Side-by-Side (SxS) technology for well over a decade, so I know nothing about installers. Also, all of my installations are strictly limited to Windows machines. So, I'm probably not much help at all.

However, currently, I use these five OCX files:

• mscomct2.ocx
• mscomctl.ocx
• msflxgrd.ocx
• richtx32.ocx
• tabctl32.ocx

Yeah, I know ... I should probably use one of the others for msflxgrd, but I don't fix what isn't broken.

OldClock, because my executable (and DLLs as well) are all setup with the SxS technology, I just distribute the files and keep them in a special folder that nobody else uses. On Windows machines, this makes my application entirely portable (i.e., no installation needed).

Not sure if that's a consideration for you or not.

[dilettante]

I don't think Microsoft has provided redist libraries for VB6 except as merge modules for a very long time.

Merge Modules for Service Pack 6 for Visual Basic 6.0 and Visual C++ 6.0

The presumption seems to have been that once mainstream support for VB6 stopped there was nothing to be gained by supporting legacy scripted installers any more. After all, the PDW had been replaced for most purposes in 1999 and the remaining use was creating IE packages which were already on the way out.

With some effort you can still extract the raw files from the merge modules to get proper redist versions. But doesn't NSIS work with merge modules directly though anyway?

Oops! I guess not, it seems to be some 3rd party legacy scripted setup maker.

[Elroy]

Interestingly, richtx32.ocx isn't in the list of covered modules in the Merge Modules kit. The others that I use are.

[dilettante]

That's always been an annoyance as far as I can recall. For the RichTextBox control I use the one extracted from the VB6 SP6 package. The idea is that these should be "base versions" that run on any version of Windows supporting 32-bit programs. If the target PC already has a newer version you should leave it alone and use that.


But it isn't as easy as it used to be. Windows Update only "looks at" a subset of these that were commonly used with Office Developer in the old days. Well, that and I suppose any that have had really critical security flaws uncovered.

For a lot of updates they seem to throw it back onto developers to download update packages and then repackage and redistribute applications.


These days it can get pretty chaotic because a lot of time and versions have passed by, and a lot of legacy setups don't check versions and just slam whatever they have in their package to disk. So a newer version can easily get downgraded when some rogue setup is run by an unsuspecting user.

We get a lot of weird questions about individual OCXs here and that might be the root cause.

[Elroy]

https://en.wikipedia.org/wiki/Dependency_hell

[OldClock]

Hey

@Elroy I read your guide "Using OCX Files with SxS Technology". This is an approach I am considering. However, I am still unclear as to where I'm supposed to get the OCX files my project uses -- you, dilettante or Mitch wrote in some other thread (I read this a few days ago, so I don't remember exactly who or where) that one should not ship files from C:\windows\system32 (nor C:\windows\SysWow64) because those are specific to my system. Since I am developing on WinXP SP3 running in VirtualBox, and my program is to function on all Windows version from WinXP SP3 to Win10 (and Linux, but let's not worry about that for now), this could be a problem.
Where do I get safe-to-ship OCX files from? Let's ignore potential licencing issues for now.

@dilettante I've been trying to make sense of these "Merge Modules" for a few days now, and I still don't really know what they are, when they should be used, what they replace and whether I need them. I'm using NSIS, not Windows Installer. I'm under the impression that they replace vbrun60sp6.exe, but I have no need for installing vbrun60sp6.exe on target machines (only on my development machine), so I suppose we can skip these Merge Modules. When installing in Linux using winetricks, "./winetricks vb6run wsh57 comctl32ocx comdlg32ocx richtx32 mdac28" installs what's needed and it works correctly.
The issues with Merge Modules you described here further contribute to my reluctance to use them.

For the RichTextBox control I use the one extracted from the VB6 SP6 package. The idea is that these should be "base versions" that run on any version of Windows supporting 32-bit programs. If the target PC already has a newer version you should leave it alone and use that.

I will try that. NSIS has some library version-checking routines.

Attempting to make a list of all possible dependencies (only a few of these will actually need to be shipped), I looked for dependencies needed by my program in several places:

• PDWincl = PDW "Include Files" window from "standard setup package" package type.
• PDWdep = PDW "Dependency File" package type.
• Declare = grep source code looking for "Declare" statements.

                PDWincl PDWdep  Declare
advapi32.dll                    y
ASYCFILT.DLL            y       
avicap32.dll                    y
COMCAT.DLL              y       
COMDLG32.OCX    y       y       
msado15.dll             y       
MSCAL.OCX       y       y       
MSCHRT20.OCX    y       y       
MSCOMCT2.OCX    y       y       
MSCOMCTL.OCX    y       y       
MSDBRPTR.DLL    y       y       
msstdfmt.dll    y               
msvbvm60.dll            y       
odbc32.dll              y       
OLEAUT32.DLL            y       
OLEPRO32.DLL            y       y
RICHTX32.OCX    y       y       
STDOLE2.TLB             y       
vb6stkit.dll    y               
winhttp.dll     y               
winmm.dll                       y

[OldClock]

For reference, I found the thread I mentioned which cautions against shipping certain libraries or using the ones from one's own development system:
http://www.vbforums.com/showthread.p...=1#post5054913

[Elroy]

Hi OldClock,

The OCX files in your C:\windows\system32 (or C:\windows\SysWow64) aren't unique to your machine. They're probably registered on your machine, but that doesn't change anything about the OCX file itself. Nothing does (or, at least, nothing should).

The only thing I'd recommend is to try and find each OCX file with the latest version you can. To find out the version, find the OCX file, right-click it, select "Properties", select the "Details" tab, and then look at the "File version" property (or the "Product version" property).

In my case, I actually don't distribute the latest version. My primary application is actually older than the latest OCX versions, and I have an attitude of "if it's not broke, don't fix it". But you're in a different situation.

To find the latest version of OCX files, I'd start by looking at what comes with VB6 SP6 service pack. And then, I'd possibly compare those with what comes with the Merge Modules pack.

Also, you've got no licensing issues if it's an OCX that came with either SP6 or the Merge Modules pack.

Best of Luck,
Elroy

EDIT1: As another thought, before wrapping up your OCX files for distribution, it might be a good idea to scan them with some virus scanner, just to make sure.

EDIT2: And, by the way, unless you've manifested your VB6.exe program, the version of the OCX files found in either C:\windows\system32 or C:\windows\SysWow64 is what you're using when you test in the IDE. So, you should know that those files do what you want. Just saying.

[OldClock]

Thank you Elroy, much appreciated.

I scan all files using https://www.virustotal.com/

I used Msms2Libs 2.zip, dilettante's tool for extracting DLL/OCX files from the Merge Modules, and am busy experimenting with installing them using the currently-recommended NSIS method...

For reference, the currently recommended method of installing libraries through NSIS seems to be using InstallLib, e.g.:

!insertmacro InstallLib REGDLL $il_shared_lib NOREBOOT_NOTPROTECTED "deps\libs\mscomctl.ocx" $SYSDIR\mscomctl.ocx $SYSDIR

https://nsis.sourceforge.io/Docs/App...ibrary_install

[dilettante]

I only brought up merge modules because that seems to be the only form Microsoft still offers these libraries in.

Ignoring those you'd have to fall back on either the redist folder of your original VS/VB CDs or else spin that wheel of fortune and copy live versions off your development PC and hope for the best. Service Packs have never updated the redist folder which normally doesn't even have any OCXs, and NSIS probably doesn't even know about this folder:

C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

Programmers are supposed to be populating that and keeping it up to date as patches come out... after testing the patched versions. When you package you should draw from there, not the live system files already installed.

But the only packaging utilities that look there are the PDW and VSI 1.1 when you use its VB6 Wizard.


So...

You are breaking all the rules and don't even know the rules. Fair enough in these last Mad Max days of VB6 but you have to expect issues you'll have to work around.

In your case you may as well just grab the live versions from your development PC and hold your breath. The worst you can do is break a million other applications by jamming a version they have problems with onto other peoples' PCs.

I used to wonder why we got .Net, but not so much any more.

[dilettante]

Trying to get more focused here:

What is the correct way to provide mscomct2.ocx (and other files) with my NSIS installer?

Why would we know how some 3rd party product is used? Have you tried its product support forums?

From a quick glance at the site this is a legacy scripted setup making utility. So you probably have to write a packaging script that creates the setup, including a setup script you'll also have to write.

You seem to already have these, but they need changes. What changes? That's not a VB programming question.

[OldClock]

@dilettante so far I'm grabbing what I can from the unpacked Merge Modules, and supplementing missing files such as richtx32.ocx by looking inside the winetricks script, which grabs those files from Microsoft servers.

> Programmers are supposed to be populating that and keeping it up to date as patches come out... after testing the patched versions.

> You are breaking all the rules and don't even know the rules.

This Microsoft Madness feels broken by design. But hey, it's 90s problems.

I hope the NSIS macro will Do the Right Thing and not overwrite versions it shouldn't overwrite.

> Why would we know how some 3rd party product is used? Have you tried its product support forums?

My question is not about NSIS, and by mentioning it I'm just pointing out that that is what I'm using, and not PDW, WiX or InnoSetup.

> From a quick glance at the site this is a legacy scripted setup making utility

PDW is buggy and lacks features, so I finally decided to invest time in switching. There are two old and actively maintained open-source installers: InnoSetup and NSIS. NSIS supports the logic I need. Is there some other installer you're suggesting which doesn't 'break the rules' and still works in XP?

[qvb6]

You only need to install the ones in bold. Anything else is a bad idea. Windows 2000 to 10 include the VB6 runtime and ADO 2.5+. The one in red is not part of VB6(Probably MS Office), so you need to require the end user to have MS Office 32-Bit installed in order to use your program. The list of files you can redistribute is located here:

C:\Program Files\Microsoft Visual Studio\REDIST.TXT

                PDWincl PDWdep  Declare
advapi32.dll                    y
ASYCFILT.DLL            y       
avicap32.dll                    y
COMCAT.DLL              y       
COMDLG32.OCX    y       y       
msado15.dll             y       
MSCAL.OCX       y       y       
MSCHRT20.OCX    y       y       
MSCOMCT2.OCX    y       y       
MSCOMCTL.OCX    y       y       
MSDBRPTR.DLL    y       y       
msstdfmt.dll    y               
msvbvm60.dll            y       
odbc32.dll              y       
OLEAUT32.DLL            y       
OLEPRO32.DLL            y       y
RICHTX32.OCX    y       y       
STDOLE2.TLB             y       
vb6stkit.dll    y               
winhttp.dll     y               
winmm.dll                       y

[qvb6]

Is there some other installer you're suggesting which doesn't 'break the rules' and still works in XP?

Windows Installer, but you probably have to update the existing one, which requires a restart before installing your app. https://en.wikipedia.org/wiki/Window...aller#Versions

[OldClock]

@qvb6 thank you. I worked my way down to the required dependencies by testing one by one in a clean environment, and my final list is exactly the same as yours. How did you know it was those files - just experience, or a technique?

[qvb6]

@qvb6 thank you. I worked my way down to the required dependencies by testing one by one in a clean environment, and my final list is exactly the same as yours. How did you know it was those files - just experience, or a technique?

Two sources: REDIST.TXT and file list here(Files under "Runtime files supported and shipping in Windows" are included with the OS and should not be shipped, they will probably come with Windows "forever", at least until they decide to drop 32-Bit support, which isn't happening any time soon).

[Elroy]

at least until they decide to drop 32-Bit support

Frighteningly, Microsoft already provides options to not have the WoW64 installed on certain Server versions of Windows.

------

Also, it sounds like OldClock might be targeting Linux (and other non-Windows) OSs. In these cases, I'm guessing that there's no guarantee that the VB6 runtime files are there.