OS/2 Related

The OS/2 compiler version 1.0.x and before is based on EMX, therefore it should work both on OS/2 and on vanilla DOS systems. In version 1.9.x and above this functionality is preserved in newly added target EMX, whereas binaries for target OS2 can only run under real OS/2. The following notes apply to OS2 target in 1.0.x and EMX in 1.9.x and above:

• All applications generated for the OS/2 (EMX) target require the EMX 0.9d (or later) runtime files to run. These files should be redistributed with your software. All the files which should be redistributed are included in emxrt.zip.
• Under OS/2, LIBPATH should be modified to add the EMX DLL paths. Otherwise, programs will not run and will abort with an error ‘Cannot find EMX.dll’.
• Stack can grow up to 256K bytes by default. This can be changed by the user or developer using the emxstack or emxbind utilities.

The GNU debugger v4.16 (EMX port) has been tested (including its PM add-on, pmgdb.exe) and generally works as it should. Because the GNU debugger is C oriented, some pascal types might not be represented correctly.

Even though this operating system permits the creation and usage of shared libraries (also called dynamic link libraries), the compiler currently only permits importing routines from dynamic libraries (creation of dynamic libraries is unsupported).

Profiling is currently not supported for this platform.

It has been reported that some DOS (GO32V2) applications (including the DOS compiler itself) generated by the compiler fail on some OS/2 installations. This is due to problems in the OS/2 DPMI server.

You should use native OS/2 applications under OS/2 (including the native OS/2 compiler) or try installing a new OS/2 fixpack to see if it solves the problem.

You are most probably using an older version of OS/2 (like OS/2 Warp 3.0) and do not have TZ variable in your environment. The easiest solution is to add “SET TZ=…” (e.g. SET TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600 for most of western and central Europe) line to your CONFIG.SYS, and restart OS/2. The proper setting for you can be found e.g. using the TZCALC tool from TIME868 package.

You are most probably using an older version of OS/2 (like OS/2 Warp 3.0) and do not have TZ variable in your environment. The easiest solution is to add “SET TZ=…” (e.g. SET TZ=CET-1CEST,3,-1,0,7200,10,-1,0,10800,3600 for most of western and central Europe) line to your CONFIG.SYS, and restart OS/2. The proper setting for you can be found e.g. using the TZCALC tool from TIME868 package.

An updated version of GNU assembler (as.exe) is packaged with release 1.9.6 (newer version was necessary to get support for features of modern CPUs). This version of the GNU tool was created with Innotek port of GNU C and relies on its libc. This results in higher limitations regarding supported configurations, because this libc needs recent version of OS/2 Unicode support libraries (LIBUNI.DLL and UCONV.DLL) not available in base OS/2 Warp 3.0 and OS/2 Warp 4.0.

The updated versions were distributed by IBM in corrective packages (fixpaks) - see e.g. WarpUpdates site for information about OS/2 fixpaks and links for downloading them. This issue isn’t valid for WarpServer for e-Business, MCP and eComStation - these already have the correct version.

Apart from the point mentioned above, there is at least one more potential reason for issues with executing the assembler and resulting in error message “Can’t call the assembler, error 2 switching to external assembling”.

This error may be result of the OS/2 system not being able to find DLLs required for the assembler. Make sure that you installed FPC completely (these DLLs are part of file asldos2.zip) and that you have set LIBPATH according to instructions in README.TXT (and restarted afterwards). If in doubts, running the assembler directly from the command line (e.g. “as –version” to show the installed as.exe version) may be helpful to see name of the missing dynamic library or other details about the problem.