As of MIL 9.0, MIL supports 64-bit operating systems. For more details about supported operating systems, refer to the Requirements to run MIL section of Chapter 1: Introduction.
When porting an application to MIL 64-bit, there are certain modifications that must be made to your application's code. This section explains these changes and the circumstances under which they are required.
In the 64-bit version of MIL, there are actually two versions of the following functions:
The two versions of these functions differ in the expected data types of their parameters: one version has a Double suffix, and one version has an Int64 suffix (for example, MblobControlDouble() and MblobControlInt64()). The Double version of these functions should be used when the relevant parameter (typically the ControlValue parameter) requires a MIL_DOUBLE value and the Int64 version should be used when a MIL_INT value is required.
In C++ (*.cpp), the original functions are available as inline functions which will automatically call the appropriate version of the function depending on the type of parameter received. No change to your source code should be required if you are compiling your 64-bit MIL application in C++.
In C (*.c), the original functions are actually macros that call the most typically required version of the function. This means that if you are compiling your MIL application in C, only minor modifications to your code will be necessary. Compiler warnings will be produced if you pass a function a double value where an integer is expected; in this case, you will need to explicitly change this function call to the proper version of the function.
Advanced users might want to retrieve a pointer to one of the modified functions. In this case, only the Double or Int64 version should be used, since the original function is actually a macro or an overloaded function. For example, you must retrieve a pointer to MmetSetPositionDouble() or MmetSetPositionInt64(), and not MmetSetPosition().
Note that when retrieving pointers to functions, the following are also affected: MimArith(), MimArithMultiple(), and MimStat(). For these functions, a Double version also exists; you must use it instead of the original.
Most MIL functions have parameters of a fixed data type. However, there are some functions, predominantly M...Inquire() and M...GetResult() functions, where one (or more) of their parameters is a void pointer. The expected data type for these void pointer parameters is determined in one of two ways:
The data type is intrinsically determined by the setting of another parameter.
For example, consider the MbufInquire() function. When the InquireType parameter of this function is set to M_ALLOCATION_OVERSCAN_SIZE, a MIL_INT value is returned, and, therefore, the UserVarPtr parameter expects the address of a variable of type MIL_INT. However, when the InquireType parameter is set to M_ANCESTOR_ID, the UserVarPtr parameter expects the address of a variable of type MIL_ID.
// Two calls to the same function where different data types are expected.
//
// Value1 should point to a MIL_INT
/*Pointer for last parameter of MbufInquire should reference a MIL_INT*/
MIL_INT Value1 = 0;
MbufInquire(BufId, M_ALLOCATION_OVERSCAN_SIZE, &Value1);
//
/*Pointer for last parameter of MbufInquire should reference a MIL_ID*/
MIL_ID Value2 = 0;
MbufInquire(BufId, M_ANCESTOR_ID, &Value2);
The data type is determined by a modifier (for example, M_TYPE_MIL_DOUBLE) added to the setting of another parameter.
For example, consider the MblobInquire() function. The InquireType parameter specifies the blob feature about which to inquire. The UserVarPtr parameter specifies the address at which to write the returned value. The UserVarPtr parameter is a void pointer, and by default requires that you pass it the address of a MIL_INT value. However, if M_TYPE_MIL_DOUBLE is added to the setting of InquireType, the UserVarPtr parameter expects the address of a variable of type MIL_DOUBLE.
// Two calls to the same function where different data types are expected.
//
/*Pointer for last parameter of MgraInquire should reference a MIL_INT*/
MIL_INT Value3 = 0;
MgraInquire(ContextGraId, M_DRAW_OFFSET_X, &Value3);
//
/*Pointer for last parameter of MgraInquire should reference a MIL_DOUBLE*/
MIL_DOUBLE Value4 = 0;
MgraInquire(ContextGraId, M_DRAW_OFFSET_X+M_TYPE_DOUBLE, &Value4);
In these cases, for the 64-bit version of MIL, you will have to use the required custom data types documented as of MIL 9.0. For example, the following code for the 32-bit version of MIL:
long SizeX;
MbufInquire(BufId, M_SIZE_X, &SizeX);
Should be changed for the 64-bit version of MIL as follows:
MIL_INT SizeX;
MbufInquire(BufId, M_SIZE_X, &SizeX);
When using void pointers, it is possible to make a mistake and pass a value with the wrong data type. These errors can cause unexpected behavior such as: stack corruption, array overflow, uninitialized returned data, and segmentation faults. To ease the transition from 32-bit to 64-bit, use the MIL M_MIL_USE_SAFE_TYPE extension. It will help you find calls to functions whose prototypes have been modified. By default, the M_MIL_USE_SAFE_TYPE extension is enabled when compiling in debug mode.
For more information about the M_MIL_USE_SAFE_TYPE extension, see the MIL custom data types, extensions, and portability functions section earlier in this chapter.
Note that this extension is not supported under Linux.
When porting an application to MIL 64-bit, you must verify that your project processor definitions (PPDs) include WIN64 and _AMD64 (these PPDs appear in the Properties page of your application). Your application will not compile if it is missing WIN64 and _AMD64.
Not supported under Linux.