CompuServe Thread

Joseph, <<The documentation for the flic routines says that they will work with the Watcom and Phar Lap. It also makes reference to using other dos extenders and that it should work. We have a lot of animations already done with 3D Studio and Animator Pro and I have been a big supporter of Autodesk. I sincerely appreciate your help in determining the answer to this.>> I can't determine if the environment that you are creating complies with the following: The FlicLib code has been developed and tested using the Watcom C/386 (v8.0) compiler and the Phar Lap DOS extender. It has also been tested with the Intel CodeBuilder DOS extender. It is quite likely to be compatible with other compilers and extenders, but this has not been tested. The following paragraphs contain notes that can help you port FlicLib to other environments. For compatibility with CodeBuilder, FlicLib assumes parameters are passed on the stack rather than in registers. A new version of the library supports clients using the Watcom -3r calling standard (parameters in registers), but internally the -3s convention is still used. A set of Watcom #pragma statements are used in the pj*.h header files to inform the -3r client code that the FlicLib functions must be called with the -3s parameter conventions. There is no practical way to convert the FlicLib to use register parameter passing internally, short of recoding all the assembler routines at the deepest level of library internals. The assembler source code assumes Watcom -3s conventions: -The compiler does not prepend an underbar to global data item names. -Any routine can modify the EAX, ECX, and EDX registers, but must preserve other registers (including all segment registers). -The caller cleans up stacked parameters. -Values are returned via the EAX register. -The processor direction flag is assumed to be cleared at entry and exit of any routine (i.e., CLD is always in effect.) Compatibility with DOS extenders other than Phar Lap should be relatively easy to achieve. The existing Phar Lap libraries should already be compatible with the Ergo DOS extender, but this is untested. The target extender's environment must meet some conditions before you consider a port to it: -The DS, ES and SS registers always contain the same value (i.e., flat model addressing). -The GS segment register is used extensively within FlicLib. The extender must place no restrictions on use of this register, and other code must preserve this register if using it. -The extender must provide a segment descriptor that maps the first megabyte of real memory (DOS memory) as a linear address space. The mapping must include the video and hardware address range (i.e., address 0x000a0000 points to the VGA video page, 0x000c0000 to the video BIOS, etc.). Whenever FlicLib needs access to DOS memory or the hardware address range, it uses the value in the GS register. This allows fast access to the BIOS clock, the video hardware, and so on. The library routine pj_set_gs loads the GS register. The video driver and clock initialization routines call this function to ensure that GS is set up with the right value for DOS memory access. They expect that the value in GS never changes throughout the run of the program. As implemented in the Phar Lap versions of the library, GS is loaded with the value from DS, and then the value 20h is added to it. Under both Phar Lap and Ergo, this process results in a segment descriptor that maps the first megabyte as a linear address space. In the CodeBuilder version of the library, the value from the DS register is copied directly and unmodified into GS. CodeBuilder's DS descriptor already maps the first megabyte of memory directly. The pj_set_gs function is in LIBSRC\GLUE_xx\setgs.asm. This is the only place in FlicLib that makes a direct reference to an extender-specific memory descriptor. To port FlicLib to another extender, re-code the functions in setgs.asm as appropriate to the target extender. (Comments in setgs.asm provide more details.) There are three modules within the FlicLib source that make calls to extender-specific functions: -LIBSRC\UTIL\doserr.asm -LIBSRC\VESA\xxralloc.asm -LIBSRC\VESA\xxint10.asm The pj_doserr_install and remove_handler functions are in doserr.asm; if you don't explicitly call these functions from your code, you won't need to modify them. The VESA driver uses several extender-specific calls to communicate with the VESA BIOS, which runs in real mode. You have to do some rewriting in these modules if you want to use the VESA video driver with another DOS extender. Comments in the existing modules give more details on this. ============ You may be able to get answers about compatibility to the above requirements from tech support of the dos-extender. jonas[adesk]

In a world where Watcomm gives away a free DOS extender, how does Phar Lap survive with such large royalty payments for extenders?