OCX Files and Inno

[MartinLiss]

I used to use the P&D Wizard to create my setup packages and when I did I never had to worry about OCX files because the Wizard handled them automatically. Recently however I created a setup package using Inno and a Vista user reported that he got a "Component 'Richtx32.ocx' or one of its dependencies not correctly registered: a file is missing or invalid" error message. What do I need to do in Inno to correct that?

[dilettante]

I'm not an Inno fan, so I can't give you specific pointers.

One thing I'm seeing people do though is run installers that rely on the self-registration entrypoints of libraries and ending up registering them per-user. When a different user runs the program these libraries fail since the user sees them as not registered.

This is easily avoided in a Microsoft Installer package (MSI) by setting the ALLUSERS Property (http://msdn.microsoft.com/en-us/library/aa367559(VS.85).aspx) in the Properties table. This allows different kinds of installs to be done depending on the value set and the target OS.

I have no idea how the Inno tools deal with installation context. Perhaps they need to have their setups run elevated and then hope for legacy appcompat behavior? I'm pretty sure PDW setups face the same limitations.


Component registration changed back around Win2K, but I think so many users ran as admin all day long that they never realized anything new was going on. The user context in effect at the time gives legacy programs a virtualized view of the registry hives to simulate Win9x/NT 4.0 behavior.

Per-User COM Registrations and Elevated Processes with UAC on Windows Vista (http://blogs.msdn.com/cjacks/archive/2007/02/21/per-user-com-registrations-and-elevated-processes-with-uac-on-windows-vista.aspx) expounds on this a little.

[jcis]

By reading the DEP file (RICHTX32.DEP, it's in Windows System folder)..

; Default Dependencies ----------------------------------------------

[RichTx32.ocx]
Dest=$(WinSysPath)
Register=$(DLLSelfRegister)
Version=6.0.88.4
Uses1=RichEd32.dll
Uses2=ComCat.dll
Uses3=
CABFileName=RichTx32.cab
CABDefaultURL=http://activex.microsoft.com/controls/vb6
CABINFFile=RichTx32.inf

[ComCat.dll]
Dest=$(WinSysPathSysFile)
Register=$(DLLSelfRegister)
Uses1=

[RichEd32.dll]
Dest=$(WinSysPathSysFile)
...

ComCat.dll is a VB Runtime file, it's present in all installers, but the one you need here is RichEd32.dll, so in INNO SETUP I think it should be:

; RichTextBox Control
Source: YourRedistFolder\RichEd32.dll; DestDir: {sys}; Flags: sharedfile
Source: YourRedistFolder\Richtx32.ocx; DestDir: {sys}; Flags: sharedfile regserver restartreplace

[MartinLiss]

So do I need to do something similar for the comdlg32.ocx?

[jcis]

So do I need to do something similar for the comdlg32.ocx? The same, this is how I've always deployed CommmonDialog:
;Microsoft Common Dialog Control
Source: redist\cmdlges.dll; DestDir: {sys}; Flags: sharedfile
Source: redist\comdlg32.ocx; DestDir: {sys}; Flags: regserver restartreplace sharedfile

[dilettante]

:rolleyes: You cannot blindly use information from 1998. To do so can lead to woes for either you or your users. Luckily newer versions of Windows have added layers of self-protection from such faulty setup packages.

.DEP files, like the PDW's VB6DEP.INI file, are supposed to be maintained by the developer over time. Microsoft does not issue updates to these VB6 files even in VB6 Service Packs. You need to read the MS KB articles and create your own updated files. Note that you might need several different VB6DEP.INI files depending on which OSs you are targeting.

Of course that assume you plan to use the PDW.

If you are using an alternative packaging tool you're expected to observe the same warnings about libraries which have become (1.) issued in OS-tailored versions, (2.) made a protected part of the OS, or (3.) otherwise rendered "not redistributable" for one reason or another.


"Out of the box" (a fresh VB6 install) the RICHTX32.DEP is only accurate for Win 9x and NT 3.5x systems. See INFO: Distribution Issues with Riched32.dll (http://support.microsoft.com/kb/197580):

Also, keep the following in mind when distributing Riched32.dll using third-party setup programs:

If the target computer is running NT 4.0, your setup program should not replace Riched32.dll.
Riched32.dll is a part of the operation system installation of Windows 2000. Setup programs installing to Windows 2000 should not install Riched32.dll.
And yes, this applies to all versions of NT since Win2K as well: Windows XP, 2003 Server, Vista, 2008 Server, 7, etc.

[dilettante]

Er, that's a long-winded way of saying:

Don't deploy Riched32.dll. If you must deploy to Win9x, deploy the copy that came with VB6 which is found in:
C:\Program Files\Microsoft Visual Studio\VB98\Wizards\PDWizard\Redist

However ideally you will have replaced this original version off the VB6 CDs with a corrected one:

MS00-005: Default RTF File Viewer Interrupts Normal Program Processing (http://support.microsoft.com/default.aspx?scid=kb;en-us;249973&sd=tech)

This is what the PDW's Redist folder is for: it looks here first when packaging a component library, and avoids taking the "live" one from your development system. Your "live" version may not work on other versions of Windows, especially downlevel versions of Windows.