One of the goals when designing Common Vision Blox for Win64 was to make it as similar to the Win32 version as reasonably possible.
Therefore, the %CVB% folder generated by the Win64 setup looks very similar to that on an x86 machine, and you will recognize many items you might know from the 32bit version of Common Vision Blox in their familiar locations. However, there are a few differences:
•Of course the binaries installed on the Win64 machine have either been compiled for the AMD64/EMT64 architecture or (in case of .Net assemblies) for the “Any CPU” platform that adapts to the CPU architecture during runtime.
To make identification of the platform for which our native binaries have been compiled easier, we did add this piece of information to the binary’s version resource:
•Several Tool DLLs and ActiveX controls are missing on the Win64 platform.
•A new folder, Wow6432, has been added under %CVB%, containing several ActiveX controls and DLLs and source code files. The contents of this folder help us bridge the gap between the 64bit world and Visual Studio (which - like Delphi XE2 - is currently still a 32bit application). A detailed description of the purpose of these files will follow.
•In the %CVB%\Lib directory only the header/wrapper files for C++, Delphi and .Net persist on the Win64 platform. The header files for VB6 have been left out because this language will definitely not support the generation of native 64 bit binaries. The .Net languages are supposed to use the wrapper files located in %CVB%\Lib\Net.
The Wow6432 Folder
When developing for Win64 with Visual Studio or Delphi XE2 one has to keep in mind that the entire Development Environment is still a 32 bit process.
This has consequences for development as well as debugging, as 32 bit binaries and 64 bit binaries generally cannot be mixed in the same process.
To work around this 32/64 bit boundary during debugging Microsoft and Embarcadero have effectively implemented the debugging of 64 bit binaries as remote debugging, i.e. the process that is being debugged and the debugger itself are being kept in separate processes.
For development the 32/64 bit boundary becomes important when working with components that are being used in the GUI designers of Visual Studio, namely ActiveX controls or User Controls, that are dependent on 64 bit binaries.
This is the case with the CVB ActiveX controls: The .ocx files have been compiled for Win64 and therefore cannot be used directly in Visual Studio.
The workaround in this case consists of providing these components in two versions: One that has been compiled for Win32 (that will be visible and available in Visual Studio and Delphi XE2) and one that has been compiled for Win64 that will be used when running the application.
With CVB, of course the Win64 versions of our ActiveX controls are located in the %CVB% folder of your installation, while the folder %CVB%\Wow6432 folder contains their 32 bit counter parts and the dependencies required to instantiate them.
So, whenever a CVB ActiveX control is dropped onto a form in the Visual Studio or Delphi GUI designer, the control that is instantiated actually comes from the folder %CVB%\Wow6432.
It is important to note that the ActiveX controls in this folder are not identical to those installed on Win32!
Their type library has been modified to resemble that of the 64bit builds in order to accommodate cross platform development (refer also this section and the chapter on portable code) and is different from that of our Win32 ActiveX controls.
To emphasize this, a _wow64 has been appended to the file name.
The ActiveX controls thus marked are only intended to be used at design time and are not suitable to run a 32 bit binary on a Win64 operating system properly!
In addition to the aforementioned ActiveX controls, the Wow6432 folder also contains a sub folder named Visual C++ OCX Wrappers.
This sub folder contains C++ wrappers for all the ActiveX controls that ship with the Win64 version of CVB.
Those files are by and large almost identical to the wrapper files that Visual Studio generates when adding an ActiveX control to a MFC application and generating a member variable for it.
However, the Visual Studio wizard responsible for the generation of these files does not generate proper IDispatch callers for properties or functions that use 64 bit numerical types.
Therefore all the wrapper files generated by the “Add member variable” wizard will either need to be modified accordingly or be replaced by the files located in the Visual C++ OCX Wrappers folder.
The chapter on portable code shows the modifications in more detail.