32bit files being installed into system32 instead of into sysWOW64

[risa...@gmail.com]

I am trying to switch from the old (old) VB6 Package and Deployment Wizard because some update to Windows 10 in February 2020 has resulted in setup.exe faulting on one of my Windows 10 systems.  (But not any other; however, if it faults on one system, it may fault on others, and so I can't trust it for general deployment).  

I am using Inno Setup Compiler version 6.0.3 (u).  I generated a template .iss file using "Inno Setup Toolbar Advanced for Visual Basic 6.0", but then modified it to meet the various recommendations for installing/registering dlls and ocx files.

My target OS is 64bit Windows 10; I don't care about any others.

This is the relevant part of my "Files" section:

Source: "ltdlg11n.ocx"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\ltdlg11n.ocx'));
Source: "ltocx11n.ocx"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\ltocx11n.ocx'));
Source: "MSBIND.DLL";   DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\MSBIND.DLL'));
Source: "MSStdFmt.Dll"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\MSStdFmt.Dll'));
Source: "DBLIST32.OCX"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\DBLIST32.OCX'));
Source: "MSADODC.OCX";  DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\MSADODC.OCX'));
Source: "MSDATLST.OCX"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\MSDATLST.OCX'));
Source: "MSDATGRD.OCX"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\MSDATGRD.OCX'));
Source: "MSMASK32.OCX"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\MSMASK32.OCX'));
Source: "COMDLG32.OCX"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\COMDLG32.OCX'));

The files starting in "lt" are part of an ancient distribution of leadtools.  FWIW, using the setup produced by PandD, on most of my systems and in my VMs, all the files install into sysWOW64, register correctly, and the program I'm installing runs.

When I run my Innosetup setup, the files other than the lt... files seem to install into system32 (which is not correct), but the do register.  Although the log says the lt.. files are copied, they do not appear to be.  Naturally, the regserver command then fails when it attempts to register the files.

The following is excerpted from the log file:

2020-03-07 13:10:28.568   Log opened. (Time zone: UTC-07:00)
2020-03-07 13:10:28.568   Setup version: Inno Setup version 6.0.3 (u)
2020-03-07 13:10:28.568   Original Setup EXE: C:\Setup Files\CRIL\Innosetup\eDigit\mysetup.exe
2020-03-07 13:10:28.568   Setup command line: /SL5="$50432,9568669,721408,C:\Setup Files\CRIL\Innosetup\eDigit\mysetup.exe" /SPAWNWND=$110332 /NOTIFYWND=$F0474
2020-03-07 13:10:28.568   Compatibility mode: Yes (Installer)
2020-03-07 13:10:28.568   Windows version: 10.0.10240  (NT platform: Yes)
2020-03-07 13:10:28.568   64-bit Windows: Yes
2020-03-07 13:10:28.568   Processor architecture: x64
2020-03-07 13:10:28.568   User privileges: Administrative
2020-03-07 13:10:28.568   Administrative install mode: Yes

...

2020-03-07 13:10:35.349   -- File entry --
2020-03-07 13:10:35.349   Dest filename: C:\Windows\system32\ltdlg11n.ocx
2020-03-07 13:10:35.349   Time stamp of our file: 2000-04-20 12:50:14.000
2020-03-07 13:10:35.349   Installing the file.
2020-03-07 13:10:35.365   Successfully installed the file.
2020-03-07 13:10:35.365   Will register the file (a DLL/OCX) later.
2020-03-07 13:10:35.365   Incrementing shared file count (32-bit).
2020-03-07 13:10:35.365   -- File entry --
2020-03-07 13:10:35.365   Dest filename: C:\Windows\system32\ltocx11n.ocx
2020-03-07 13:10:35.365   Time stamp of our file: 2000-04-19 16:55:06.000
2020-03-07 13:10:35.365   Installing the file.
2020-03-07 13:10:35.380   Successfully installed the file.
2020-03-07 13:10:35.380   Will register the file (a DLL/OCX) later.
2020-03-07 13:10:35.380   Incrementing shared file count (32-bit).

...

2020-03-07 13:10:35.787   Registering 32-bit DLL/OCX: C:\Windows\system32\ltdlg11n.ocx
2020-03-07 13:10:35.787   Spawning 32-bit RegSvr32: "C:\Windows\system32\regsvr32.exe" /s "C:\Windows\system32\ltdlg11n.ocx"
2020-03-07 13:10:35.833   Registration failed:
                          RegSvr32 failed with exit code 0x3.
2020-03-07 13:10:35.833   Message box (Abort/Retry/Ignore):
                          C:\Windows\system32\ltdlg11n.ocx
                          Unable to register the DLL/OCX: RegSvr32 failed with exit code 0x3.
2020-03-07 13:10:43.699   User chose Ignore.
2020-03-07 13:10:43.699   Registering 32-bit DLL/OCX: C:\Windows\system32\ltocx11n.ocx
2020-03-07 13:10:43.699   Spawning 32-bit RegSvr32: "C:\Windows\system32\regsvr32.exe" /s "C:\Windows\system32\ltocx11n.ocx"
2020-03-07 13:10:43.762   Registration failed:
                          RegSvr32 failed with exit code 0x3.
2020-03-07 13:10:43.762   Message box (Abort/Retry/Ignore):
                          C:\Windows\system32\ltocx11n.ocx
                          Unable to register the DLL/OCX: RegSvr32 failed with exit code 0x3.
2020-03-07 13:10:45.308   User chose Ignore.

If I hardcode the destination for the lt... files to by syswow64, it does put them there - but then regsvr32 is sill looking ins sytem32, so the registration still fails.  And, besides, there are numerous injunctions against hardcoding the destination to be syswow64.

What obvious detail am I completely missing?

Thanks,

Risa

[Jernej Simončič]

On Saturday, March 7, 2020, 21:28:36, risa...@gmail.com wrote:

> This is the relevant part of my "Files" section:

First, do you have ArchitecturesInstallIn64BitMode in the [Setup]
section?

> Source: "ltdlg11n.ocx"; DestDir: {sys}; Flags: sharedfile restartreplace regserver 32bit; Check: FileNotFound(ExpandConstant('{sys}\ltdlg11n.ocx'));

This looks fine, but get rid of the Check - it's useless, as Inno
won't replace files that are same or newer version by default; you
also don't need 32bit flag unless you have non-empty
ArchitecturesInstallIn64BitMode.

> When I run my Innosetup setup, the files other than the lt... files seem to
> install into system32 (which is not correct), but the do register.
> Although the log says the lt.. files are copied, they do not appear to be.

By default, Inno runs in 32-bit mode, which means that System32
directory is really SysWoW64 on disk - the log file will tell you that
the file was installed to System32, but in reality Windows will
silently redirect the file to SysWoW64; this is the correct behaviour,
and it's also what you want since you're using the sharedfile flag
(32-bit shared files must be registered with 32-bit path to work
properly).

If the files don't appear in SysWoW64 when you look for them with a
64-bit file manager, something is wrong.

> Naturally, the regserver command then fails when it attempts to register
> the files.

> 2020-03-07 13:10:35.833 Message box (Abort/Retry/Ignore):
> C:\Windows\system32\ltdlg11n.ocx
> Unable to register the DLL/OCX: RegSvr32 failed with exit code 0x3.

0x3 seems to mean that a dependency is missing - are you sure that
those .ocx files don't need any other libraries to be present on the
system?

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

Old age is always fifteen years older than I am.
-- Baruch's Rule for Determining Old Age

[Risa Baumrind]

I do not have ArchitecturesInstallIn64BitMode in the Setup.  I did try adding  ArchitecturesInstallIn64BitMode=64 in Setup, but it didn't change anything.  It is entirely possible that there is some other dependency missing; I will start by going back to the SETUP.LST produced by P&D and try to verify that I have all the correct dependencies.  And/or see if I can find a working copy of depends.exe on any of my systems!

[Setup]

AppName=eDigit
AppVerName=eDigit 2.1.31
AppPublisher=CRIL/UOP
CreateAppDir=yes
DefaultDirName=C:\CRIL\bin\eDigit
DefaultGroupName=CRIL\eDigit
SetupLogging=Yes
Compression=lzma
SolidCompression=yes
PrivilegesRequired=admin

The joys of trying to support 25 year old code that you didn't write yourself, in programming languages that you've never programmed in...

Where were you able to find the return codes from RegSvr32?  Google was not my friend in this case!

Thank you,

Risa

[Jernej Simončič]

On Saturday, March 7, 2020, 22:08:58, Risa Baumrind wrote:

> I do not have ArchitecturesInstallIn64BitMode in the Setup. I did try
> adding ArchitecturesInstallIn64BitMode=64 in Setup, but it didn't change
> anything.

Don't - your program is 32-bit, so you don't want that.

> Where were you able to find the return codes from RegSvr32? Google was not
> my friend in this case!

Nothing concrete, just what the Google results implied.

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

If it happens, it must be possible.
-- Unnamed Law

[István Szabó]

Hi!

The help file contains the following:

64-bit Installation Limitations

Because Inno Setup is a 32-bit application, there are some limitations to be aware of when utilizing its 64-bit installation features:

• The System32 path returned by the {sys} constant does not always map to the 64-bit System directory. When Setup/Uninstall is running in 64-bit install mode, it maps to the 64-bit System directory when used in the [Dirs], [Files], [InstallDelete], [Run], [UninstallDelete], and [UninstallRun] sections because Setup temporarily disables WOW64 file system redirection when files/directories are accessed by those sections. Elsewhere, System32 and {sys} map to the 32-bit System directory, as is normal in a 32-bit process.

• In the [Code] section, when Setup/Uninstall is running in 64-bit install mode, functions that access files disable WOW64 file system redirection (unless overridden by a call to EnableFsRedirection). However, there are exceptions, listed below. These functions never disable file system redirection, meaning you cannot pass them (or get back) the name of a file located in the 64-bit System directory:

  *Ini*	(all of the functions that manipulate .INI files)
  BrowseForFolder
  CreateShellLink
  GetOpenFileName
  LoadDLL	(see following point)
  ModifyPifFile
  SetCurrentDir
  ShellExec	(use Exec instead)
  UnregisterFont

  Additionally, no VCL classes are capable of disabling file system redirection. For example, you cannot call the LoadFromFile method of TBitmap to load a bitmap file from the 64-bit System directory.

• You cannot load/use 64-bit DLLs in the [Code] section, because Windows does not allow 32-bit processes to load 64-bit DLLs (and vice versa). A 32-bit process can, however, launch 64-bit EXEs. Use the Exec function or the [Run] section to do that.

See further in the file "64-bit installations".

[Risa Baumrind]

Thank you both for your help.

Istvan, I'd already seen what you posted from the help files, but I think I didn't fully understand it.  Thank you for reminding me about that section.

Jernej, you were correct in positing that there were missing dependencies.  I modified the script to copy in the rest of the dlls for LeadTools and the installer ran without error and registered the ocx files (or whatever the correct terminology is).  I have yet to fully test the program, but at least the I am no longer getting an error on install and the program does start.  Thank you for pointing me in the right direction.

Now, to convert the other 3 install scripts and test the installed programs.