Re-compiling and linking to support Oasis montaj 9.0

A recompile of and C/C++ dlls and .Net assemblies that uses the GX API will be necessary in all cases. The retargeting instructions below applies to both.

Retargeting

The following steps show how to do this in Visual Studio:

Step 1 (in toolbar):

Step 2:

Step 3:

The AnyCPU, Win32 and x86 platforms can be deleted using the Configuration Manager for the solution and any projects it contains.

C/C++

In addition to the retargeting .a C/C++ project should be changed so that the geodist and geogx libs that are linked to as well as the include paths are from the Geosoft GX Developer 9.0 BETA.

Any other changes necessary will depend on the complexity of the code involved as well as the extent of third party libraries utilized. Since Visual Studion 2013 (and especially with Visual Studioo 2015) the Microsoft C/C++ compiler helps with this process with new warnings and error messages wherever 64-bit unsafe code is found. For this reason compiling the code and perusing any warnings and errors is a good first step.

See the Suggested Reading below for more information.

.Net

In addition to the retargeting .Net solutions should be changed so that any Geosoft assembly references point to the ones from the Geosoft GX Developer 9.0 BETA.

Changes to GX.Net class constructors are necessary since we used a 32-bit int for the GX handle in previous releases. This was actually a pointer to an internal structure and the correct .Net platform independent type that should have been used is IntPtr. Example:

public MapGX(int iGeo) : base (iGeo)
{
}

Should change to:

public MapGX(IntPtr pGeo) : base (pGeo)
{
}

MSDN states: "If you have 100% type safe managed code then you really can just copy it to the 64-bit platform and run it successfully under the 64-bit CLR." If this is the case one should not need any other changes. If not the last link in the Suggested Reading is a good starting point.

Known Issues:

~~C example callfunc2.gx calling callfunc.dll fails~~ — Fixed. The build was linking to the Unicode geogx_u.lib while the project was targeting Multibyte Character Set. The correct lib to link to is just geogx.lib in this case.
~~MFC example GeoXTool sendgenmessage.gx doesn’t do anything~~ — Worked for me. Note that you need to launch the MFC tool first withrungeoxtool.gx. sendgenmessage.gx then sends some sample text to display in the Area heading in the tool.
~~NET example GoogleMapsTools has .NET references to geonet and geoxnet that don’t exist~~. — Fixed the build. Considered removing the sample as it does not quite work out of the box. It needs a server to host the maps.html and the code might need to be updated to the latest Google Maps Javascript API, but I think it is useful to show how to embed a webpage in an XTool with a map control that uses one of these services (Google Maps, Bing etc.) and responds to area changes on the current map.
The 8.5 Python API for GX Developer is not supported, and will change significantly for Oasis montaj 9.1.