Installing CVB 64-bit and 32-bit side by side on Windows

General Questions
1

Hello,
we have integrated CVB into an existing software of ours.
This software is available in 32 and 64 bit.
I tried to install the 32 bit version of the full installer after installing the 64 bit version.
The Installer refuses to install, telling me to remove the 64 bit install before attempting to install the 32 bit version.
However I need both 32 and 64 bit libs/dlls to build my application in both flavors.
How can I get the necessary files onto the same computer?

Best regards
Tobias Weigt

2

Hi @t.weigt

unfortunately there is right now no way to get a 32 bit and 64 bit build of :cvb: installed on the same machine - at least if you are not after a working installation.

Click here if you are interested in the reasons...

There are basically two reasons for the mutual exclusivity of the 32 and the 64 bit installation of :cvb:

  1. Environment Variables
    There are a few environment variables that :cvb: is setting and that need to point to different locations for 32 bits and for 64 bits. This is not a very hard limit - we could certainly figure out how to rearrange them and publish a new version with a different layout. This would probably be a behavior-breaking change and we try to avoid these, but the benefit would be big enough to pursue this.

  2. ActiveX controls
    :cvb: ships with a number of ActiveX controls, and as you’d expect these differ between 32 and 64 bit. This would in itself not be a problem - but there are actually three sets of ActiveX controls involved here:

    • First there are the 32 bit builds of the ActiveX controls as they are shipped in the 32 bit installer of :cvb:. No problem here.
    • Then there are the 64 bit builds of the ActiveX controls that ship with the 64 bit installer of :cvb:. These are basically fine as well, but there is a subtle different between those and their 32 bit build counterparts: The public API of the ActiveX controls contain pointers/handles that have been mapped to integers (most prominently the Image property, but there are others as well). For these, the API uses the type long in the 32 bit build and int64 in the 64 bit build.
      At runtime this would still work without issues, but problems arise during development: Today still most development environments are still 32 bit processes. That means that if you instantiate an ActiveX control e. g. by putting it onto a form in your development environment’s form designer, your development environment will actually instantiate the 32 bit version of the ActiveX control, not the 64 bit version. This also means that the development environment will generate the language-specific ActiveX wrappers to match the API of the 32 bit ActiveX control - which will cause problems at runtime.
    • Therefore a third set of ActiveX controls is around: A 32 bit build with a 64 bit API.
      These chimeras are located in the %CVB%\Wow6432 folder and have an infix _wow64 in their filename. Those controls make sure that when working with the 64 bit version of :cvb: the ActiveX wrappers will match the actual ActiveX control’s API. They are not really good for anything else…

As we cannot simultaneously install three sets of ActiveX controls we remain limited as long as the ActiveX controls are around. The silver lining: The days of the ActiveX controls are numbered and within about 1 or 2 years’ time a fully functional hybrid installer is within reach.

However, if a working installation is not your primary objective (e. g. because you are setting up a build node) then there might be options and recommendations I can give you. But before doing so I’d need to understand your scenario better:

  • what programming language are you working with
  • I assume that we are talking about Windows here
  • Are you using any of the ActiveX controls of :cvb:?
1 Like
3

Hello @illusive,
thank you for getting back to me and the insights on why it is not so easy to do this.

My primary objective right now is to get the dependencies for building.

  • We are using the C++ API.
  • We are building on Windows for Windows.
  • We are not using any ActiveX controls.

I debated installing the 32 and 64 bit SDKs after each other and just copying all the required files, but I wanted to see if there was a less involved way.

Is it possible to bundle newer releases of CVB with our software that links to an older version of the libs/dlls? What versions would be compatible?

I am on holiday for the next three weeks, so I can not answer again any time soon.

Thank you for your help so far!

Best Regards

4

Hello @illusive,

I am back from my holyday.
Any news?

Best Regards

5

Hi @t.weigt - and sorry for the delayed reply, I just returned from vacation this week. Also thanks for summing up your environment!

I have in fact dabbled in this some seven years ago and can give you some pointers - but before doing so I need to point out that this is not an officially supported scenario (and definitely the people behind de.support@stemmer-imaging.com will not be able to help you with), so we’re basically on our own here.

There are (probably not surprising) some limitations when mixing 32 and 64 bit installations beyond this not being an officially supported setup:

  • Most notably, it is unlikely that the GenICam.vin (and the GenICam infrastructure) will work without issues in a 32-bit application with GigE Vision or USB3 Vision cameras. I only expect the 64-bit driver to work as it should.
  • There are two tools - Color and Manto - that are only available for the 32 bit Windows platform; but as you are using the CVB++ API you will most likely not be using those anyway.
  • Patch installers will not be able to update your fileset easily - whenever you want to update what you are about to create you’ll need to do that manually for the Win32 side.
  • The start menu entries created by the installers will of course only be pointing to either 32 or 64 bit binaries; when following the hints further down, they will point to the 64 bit binaries.

Step-by-Step Instruction

1. Obtain Common Vision Blox Win32 Fileset

First of all, you’ll need the file set of the Win32 version of Common Vision Blox. For this it is necessary to run the Win32 Runtime Setup (“CommonVisionBlox xx.xx.xxx (Win32).exe”). It does not matter much into which directory Common Vision Blox gets installed at this stage, but things are simpler when doing it e. g. to C:\CVB\Win32 or something similar.

After the installation has finished, the following files need to be copied to a temporary directory:

  • The complete content of the directory %CVB%, including all sub-directories (keeping the directory structure intact!)
  • From C:\windows\SysWOW64 the files borlndmm.dll and vcl60.bpl.

Also export the entire registry key (including sub keys) HKEY_LOCAL_MACHINE\Software\Wow6432Node\Common Vision Blox into a file. This file can be re-imported without any changes later.

Once all copies have been gathered, the Win32 version of the Installation will not be needed any longer and should be uninstalled.

2. Installation of Common Vision Blox x64

Now the x64 version of the Common Vision Blox setup (“CommonVisionBlox xx.xx.xxx (x64).exe”) can be executed on the target system. The destination directory may be freely chosen - I recommend using something along the lines of C:\CVB\x64.

3. Add the Win32 File Set

Now the file set that has been copied into a temporary folder earlier in step 1 should be copied into a suitable target directory like C:\CVB\Win32. Those files that have been copied from C:\Windows\System32 or C:\Windows\SysWOW64 (borlndmm.dll and vcl60.bpl) need to be copied to C:\Windows\SysWOW64 again.

4. Adapt Environment Variables

The following environment variables should now be adapted or added:

  • GENICAM_GENTL32_PATH has to be added. It should point to the sub-directory “GenICam\bin\win32_i86\TLIs” of the Win32 file set (e. g. C:\CVB\Win32\GenICam\bin\win32_i86\TLIs).
  • A reference to the base folder of the Win32 file set must be added to the PATH variable.

5. Modify Registry

At this point, the registry only contains those entries that have been added by the x64 installer. Some components, however rely on the correct entries for the Win32 part to work correctly. The easiest way to just reimport the file exported in step 1.

Final Remarks

When doing the installation like described above, the two different installations of :cvb: will end up in C:\CVB\Win32 and C:\CVB\x64. Both directories will have been put into the PATH variable, so a binary using :cvb: will find the respective dependencies easily (and the Windows DLL loader will automatically select the correct DLL). What’s more difficult are the dynamically loaded (i. e. via LoadLibrary) DLLs like e. g. GenICam.vin because LoadLibrary will actually load a DLL even if the architecture does not match. So it is possible to open the “wrong” GenICam.vin (i. e. the 32 bit one in a 64 bit application and vice versa) - but I expect a nasty crash to happen shortly after…

Special attention should be paid to the CVB environment variable: As a matter of principle this can only point to one of the two architectures (and if you followed the description this will be C:\CVB\x64). Therefore, if you access anything through %CVB% (or $(CVB) in Visual Studio…) you should always make sure that what you do is actually platform agnostic (for example: Including the CVB++ headers through $(CVB) or %CVB% won’t do harm, because they are identical for 32 and 64 bit, but linking the CV*.lib files will tie things down to the x64 platform because %CVB%\Lib\C contains only the 64 bit *.lib files…

1 Like