In many ways, the Windows environment operates quite differently from other environments. Included in these differences are interfaces to other languages, file extensions, and hardware error messages. Some of these could affect the way your programs execute.
As an example, this section highlights important differences between the operational characteristics of the MS-DOS runtime and the Windows runtime.
1. The "SYSTEM" library routine operates differently. You may use it to initiate both MS-DOS programs and other Windows programs. When initiating MS-DOS programs, this routine brings up a DOS prompt "window" (DOS box). When initiating a Windows program, the program runs in its own window.
While it's running, the window containing the calling program will not accept input from the user.
To execute MS-DOS operating system commands via SYSTEM, you must pass the name COMMAND.COM, as well as the operating system command. Use the syntax shown in this example that executes the DIR command:
CALL "SYSTEM" USING "COMMAND.COM /C DIR"
When CALL "SYSTEM" is used to initiate a program, it looks only for files with a ".EXE" extension. If you want to call a ".COM" or ".BAT" file, you must explicitly add that extension in your code. For example:
CALL "SYSTEM" USING "COMMAND.COM /C MYBATCH.BAT"
2. When the program executes the ACCEPT FROM SYSTEM-INFO verb while running under an MS Windows operating system, the runtime returns the literal "WINDOWS". This allows you to easily code Windows-specific sections in your programs.
3. Because of differences in memory management and program structure, you may not load assembly language routines dynamically in the Windows environment. To link assembly routines into the runtime, change your assembly program to emulate the calling sequence used for C routines.
4. Hardware errors returned by Windows are different from those returned by MS-DOS. This causes the secondary codes given by error "30" to be different under Windows and MS-DOS.
For example, "Out of paper" is error "9" under MS-DOS; under Windows it's error "28".
The hardware errors used under MS-DOS are version 2.0 MS-DOS errors, while the errors used under Windows are the extended error codes introduced with version 3.0 MS-DOS. For a complete list of errors, see MS-DOS function 59h in any MS-DOS programming text. As a helpful hint, MS-DOS errors "0" through "12" correspond to Windows errors "19" through "31".
5. The Windows version of C$CHAIN has a side-effect that you should be aware of. Windows does not provide a mechanism for "chaining" programs. Instead, we initiate the chained-to program as an independent program and then halt the chained-from program.
Although this has the correct effect, Windows causes the "active" program to shift from the chained-to program to some other program when the chained-from program halts. It is impossible for the runtime to determine which program will be selected by Windows as the "active" one.
The net effect is that the chained-to program pops up, but then becomes inactive and must be reactivated with either the mouse or the keyboard in order for the user to enter data. Windows does not provide any mechanism for suggesting which program to activate when a program halts.
6. The runtime options "-o/+o" and "-i" for redirecting data to a file work only in UNIX and DOS systems, not in Windows environments. For Windows users, the "-k" option can be used instead of "-i". The "-k" option is portable to all platforms.