# Multiplatform Programming Guidelines

LabWindows/CVI is portable because it uses ANSI C program files, LabWindows/CVI User Interface Resource files, and National Instruments libraries.

You must segregate any platform-dependent code in your source code using conditional preprocessor directives. You can use the built-in macros, such as _NI_mswin32_, _NI_mswin16_, _NI_mswin_, _NI_unix_, and _NI_linux_.

## Library Issues

Avoid using Windows 32-bit SDK functions unless you intend your LabWindows/CVI application to run only under Windows 2000/XP.

The sopen and fdopen functions are available only under Windows. Avoid using them unless you intend your LabWindows/CVI application to run only under Windows.

Avoid using Linux host system library calls such as ioctl, fcntl, and so on, unless you intend the LabWindows/CVI application to run only under Linux.

Under Linux, the low-level I/O functions open, close, read, write, lseek, and eof are available in the system library. These functions are portable to Windows if you include lowlvlio.h in your Windows application.

In general, the ANSI C, User Interface, Advanced Analysis, Formatting and I/O, Utility, GPIB, VXI, RS-232, TCP Support, and Internet libraries are portable across platforms. However, a few functions are not multiplatform. The majority of these functions are in the Utility Library. The documentation and function panels for the non-portable functions contain notes that list the platforms to which they apply.

The following libraries are not supported across platforms: ActiveX, DDE Support, DataSocket, DIAdem Connectivity, .NET, Data Acquisition, and Easy I/O for DAQ libraries.

Although LabWindows/CVI provides the TCP Library on all platforms, you must ensure that the system has hardware and software support for the TCP server.

Various processor architectures store integers and floating point numbers in different byte order. To circumvent these inconsistencies, use the [o] modifier in the Formatting and I/O Library functions to describe the byte ordering of device data. In a Fmt/Scan function, use the [o] modifier to describe the byte ordering for the buffer that contains the raw device data. Do not use the [o] modifier on the buffer that holds the data in the byte ordering of the host processor. For example, if you use a GPIB instrument that sends two-byte binary data in Intel byte order, use the following code:

short instr_buf[100];
short prog_buf[100];
status = ibrd (ud, instr_buf, 200);
Scan (instr_buf, "%100d[b2o01]>%100d[b2]", prog_buf);

If you use a GPIB instrument that sends two-byte binary data in Motorola byte order, use Scan as shown in the fo llowing example:

Scan (instr_buf, "%100d[b2o10]>%100d[b2]", prog_buf);

In either case, use the [o] modifier only on the buffer that contains the raw data from the instrument (instr_buf). LabWindows/CVI ensures that the program buffer (prog_buf) uses the proper byte order for the host processor. For a full description of the [o] modifier, refer to Chapter 2, Formatting and I/O Library, of the LabWindows/CVI Standard Libraries Reference Manual.

## Externally Compiled Modules

Although you can use externally compiled modules in LabWindows/CVI, the best medium for application portability is ANSI C source code. Object modules are not directly portable from one platform to another because the object file formats on the various platforms differ.

To use an externally compiled module across platforms, you must recompile the source code for the module with a compiler for the target system.