Laserfiche WebLink
and on RTi's RS/6000 workstation to make sure that the code will compile on both platforms and <br />will run similarly on both platforms. If the code is portable, then minimal effort will have to be <br />spent recompiling code on non-SGI machines. Performing this check will ensure that code does not <br />depend on non-standard SGI compiler extensions. This approach will not work in situations where a <br />third-party library is being used (e.g., the INFORMIX Embedded Standard Query Language (ESQL) <br />library). However, short "dummy" library routines could be developed to comment on the <br />proprietary library routines so that the code can at least be compiled on different platforms. The <br />level of effort for such evaluations will be considered for each piece of code. <br />Another portability issue is file system limitations. For example, UNIX uses the / character to <br />delimit directories in a path. DOS uses the \ character for the same purpose. Additionally, DOS <br />limits the names of files and directories to eight characters, a period, and a three letter extension (8.3) <br />while most versions of UNIX now allow filenames to have very long names (e.g., 256 characters), <br />and multiple periods can be used in filenames (e.g., myfile.30Jun94.copy1). Consequently, any file <br />structure that may possibly be migrated from UNIX to DOS should use directory and file names that <br />will work on a DOS-based system (including Microsoft Windows). Additionally, software that will <br />run on both UNIX and DOS-based systems should have provisions for using the appropriate <br />directory delimiter character. <br />RTi proposes that configuration files be used to specify filenames wherever possible rather than <br />hard-coding directories and filenames in source code (see Task Memorandum 1.05-23). RTi also <br />proposes that the directory delimiter character be set to include files based on the operating system, <br />and be treated as a variable in code that works with directory names. <br />Graphics Portability <br />Graphics systems are invariably non-portable because they often rely on complex software that may <br />be proprietary in nature. The public domain X Window System and the Open Software Foundation's <br />Motif provide a graphics-based windowing system that is widely used. However, this software is so <br />complex that it is generally only implemented by hardware vendors. Most workstations use the X <br />Window System and Motif as the user interface to the operating system. Developers can write <br />graphics-based programs to use this system by using libraries supplied by the hardware company <br />(often standard issue). <br />PCs and Macintosh computers each have their own graphics-based windowing systems which are not <br />directly compatible with the X Window System. The only way to develop platform-independent <br />screen graphics is to insert a layer of generic graphics code between the application and the <br />hardware-specific graphics system. Task Memorandum 1.05-15 discusses this issue. X Window <br />System graphics can be displayed on PCs and Macintosh computers if those machines are installed <br />with X Window System emulation software. In this configuration, a program actually runs on a <br />workstation, but displays results on a PC or Macintosh. This is a viable alternative (to running the <br />application on a PC or Macintosh) because large applications are often difficult to port to smaller <br />machines like PCs. <br />Hard-copy graphics are generally created in one of three formats: <br />(1)PostScript <br />(2)Hewlett-Packard PCL <br />3 <br />A275 05.10.94 1.05-28 Malers <br />