17.8 Windows 64-bit Support

It is recommended that you only enable 64-bit support if installing a Build machine and it is mandatory that the application is required to be 64-bit. For example, if it's a required corporate standard. Some drawbacks of enabling 64-bit support are:

• Compiles take twice as long as both 32-bit and 64-bit DLLs are always built.

• Functions which use DISPLAY, REQUEST or POPUP commands will fail to compile; even 32-bit DLLs.

• You must obtain your own 64-bit compiler.

LANSA Features that do not function or have no support

• Graphics Server is not supported. There are many modern alternatives that will work on both 32 bit and 64 bit. Use them. This maps to the primitive: PRIM_GRPH.

• Explorer Component AutoRefresh Property does not function.

• ZIP BIFs are not supported.

• DISPLAY, REQUEST and POPUP commands are not supported in 64-bit applications.

• Web Functions are not supported.

• Specialized LANSA Built In Functions (BIFs) are not supported in 64-bit. This is because the development environment is 32-bit and thus they are not compatible.

Installation Considerations

• It is presumed that a developer does NOT enable 64-bit support. The intention is that it's only the Build Machine that has 64-bit support enabled. So it is not possible to ONLY have 64-bit support. Some noticeable consequences of this mean that when 64-bit support is enabled:

• Both the 32-bit and 64-bit compiles are performed, which takes longer and thus may not be appropriate on a developer's machine.

• Both 32-bit and 64-bit Windows Installer MSI packages are built.

• Visual Studio 2010 Professional (or later) or Visual Studio 2012 Express for Desktop (or later) are required to support 64-bit compiling. The compiler shipped with the Visual LANSA install does not support 64-bit compiles.

• If Visual Studio is installed before LANSA then it will be detected and will be the compiler used by LANSA.

• If a supported compiler is not installed, the LANSA-shipped compiler will be installed and enabled. To enable 64-bit compiling, install one of the compilers that supports 64-bit compiling and then change this registry entry to disable the LANSA-shipped compiler:
  HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LANSA\MicrosoftCompiler\2010\Enabled to 0.
  On a 32-bit PC it is: HKEY_LOCAL_MACHINE\SOFTWARE\LANSA\MicrosoftCompiler\2010\Enabled.

• If the latest version of Visual Studio installed is not one that supports 64-bit compiling, just install one that does. LANSA will detect it when it is next started.

• If you compile a Function which contains DISPLAY, REQUEST and POPUP commands (which are not supported) it will fail to compile at all - even the 32-bit compile. This is another reason why it is better not to enable 64-bit support on Developer's machines. If a Developer needs to work on both RDML Functions and 64-bit applications then two systems may be installed on their machine which use the same repository.

Programming Considerations

• There are no increases in the maximum size of any LANSA feature. For example, the maximum size of an RDMLX List is still 2 billion rows, with each entry being 2 billion bytes long. That is, existing limits are considered sufficient. This also means there is greater compatibility between 32-bit and 64-bit applications. For example, the Built In Functions SND_TO_DATA_QUEUE and RCV_FROM_DATA_QUEUE may be used interchangeably. Job Queue Emulation can use either a 32-bit or 64-bit Job Queue Monitor and jobs may be submitted from either 32-bit or 64-bit. Note that the 64-bit Job Queue Monitor will execute the submitted job as 64-bit, no matter which platform submitted the job.

• Imported tables which are loaded using a 32-bit ODBC driver will need to create a 64-bit DSN with the same name as that used to load the file or use CONNECT_SERVER when deployed to re-direct IO to a 64-bit driver.

• To put an ActiveX in LANSA RDML there must be a registered 32-bit version of the ActiveX. To EXECUTE the ActiveX, a version must be registered which is of the same processor architecture as the LANSA runtime. That is, if the LANSA runtime is 64-bit then the 64-bit ActiveX must be registered on the deployed PC.

32-bit and 64-bit applications accessing the same database

Considerations when both a 32-bit application and a 64-bit application are accessing the same database, particularly when deploying an application into a production system:

• LANSA recommends using either 32-bit or 64-bit applications. It makes it far simpler. For example, when using SuperServer, only use a 64-bit server if you use both 32-bit and 64-bit clients. As the clients are not directly accessing the database, there is no complication. It is better to choose to exclusively use one or the other.

• Assign relative record numbers using auto-generation. If relative record numbers are assigned using external files, duplicates will occur unless the RPTH parameter is assigned to the same path for both 32-bit and 64-bit applications. A file that is currently using external files may be changed to auto-generation using the Upgrade tool feature Convert Files to Use Identity Column.

• Table upgrades are identified by comparing the previous CTD file to the new CTD file being installed. Thus only the first system upgraded should upgrade the database. This is why database upgrade defaults to OFF during an MSI install and why per-user installs disable database upgrade.
  If an existing OAM does not exist for 64-bit but exists for 32-bit, and vice versa - which is the latest OAM? This needs to be controlled by the user. If 32-bit is the first environment to be installed, continue that way for all Upgrades and Patches. Once the 64-bit environment is at the same level, there is the choice that the Upgrade/Patch database change machine can be switched, but it is inadvisable. Be consistent and use one machine from the beginning.

Notable Environmental Differences

• The system directory for 32-bit applications is of the form x_win95\x_lansa. For 64-bit applications it is x_win64\x_lansa. Therefore, system variables like *SYS_DIR return a different value.

• Visual LANSA is a 32-bit application. Hence interaction between Visual LANSA and 64-bit generated DLLs cannot occur.

• 32-bit OAMs are always built and will always be built, as Visual LANSA requires the 32-bit OAM to unload and load the data from the table. The 64-bit build command always skips the SQL table build, presuming that 32-bit has already done it.

• Windows Installer has a known defect which converts the Target directory in a Shortcut from c:\program files to c:\program files (x86). Nonetheless the shortcut still works correctly as if it was c:\program files. Even if the 32 bit version of the Application is installed in c:\program files (x86), it does not get executed, it is still the 64-bit version. See this web link 32bit MSI on 64bit OS: Converting shortcut target path of 64bit app to 32 bit Path.

• A similar situation occurs with Windows\system 32. The shortcut looks OK but it does not find the object. It is not valid to create a shortcut that points to this directory.