Click above to get retro games delivered to your door ever month!

 Converting your code
------------------------------------------------------------------------------
 As a general rule, the higher level the language, the easier it is to
 convert your code. High level languages such as CA-Clipper require no code
 changes whatsoever as the code actually executing is contained in the
 CLIPPER.LIB file itself. Medium level languages such as C, PASCAL, FORTRAN,
 etc. in their pure form also require no code changes. Almost the only time
 changes are needed is when the programmer has hard coded direct access to
 system resources, such as using an absolute pointer to a video buffer.

 This type of code needs to be adapted slightly to store and use the pointer
 in a variable which is set up at the beginning of the program. For example,
 in the case of video writes, a system call would be made at start up to set
 up a pointer to the video buffer. This would either be an absolute pointer
 if the program is in real mode, or a selector if the program is in protected
 mode. From then on, all video memory accesses are made using the same
 pointer, regardless of the processor mode, so there is no further overhead
 in code or execution time.

 Assembly code is the most likely to require conversion, as it provides
 direct access to system resources which may not be available in protected
 mode. The code requiring conversion is similar in nature to that previously
 described, it is simply more likely to be prevalent in assembly code.
 A final construct requiring conversion relates to segment addresses. In
 protected mode, segments are not allocated sequentially and are not
 contiguous, thus comparison of segment addresses is invalid. For example,
 sequential allocation of segments from the DOS extender will at best produce
 selectors separated by an increment of 8, and at worst produce them in a
 seemingly random sequence. This is because the selectors are simply pointers
 into an array known as a descriptor table, and the low three bits of the
 selector are used to store control information. For more details see the
 DosGetHugeShift() function in the online help.

 To put this conversion process in perspective, in case it sounds an enormous
 task, when we converted Blinker to run in dual mode, it consisted of
 approximately 80,000 lines (5 Mb) of pure assembly code, which is the worst
 kind of code to convert. The whole conversion to run in dual mode, i.e.
 normal DOS mode OR protected mode under our own extender, took one
 programmer less than a day. The code is now totally compatible with both
 modes with no conditionally compiled code, and the extra overhead is less
 than 100 lines called at various initialisation points at the beginning of
 the program.

 Debugging under protected mode makes the detection of code to convert
 relatively simple, just run the code and see where it stops with a
 protection exception. Typically an error message will be displayed
 indicating the location and type of the error, and the program will return
 to DOS. When running under Windows or OS/2 this can be done many times
 without requiring a reboot of the machine.