Retro video games delivered to your door every month!
Click above to get retro games delivered to your door ever month!
X-Hacker.org- CA-Clipper/ExoSpace 1.0g - <b>chapter 1: introduction</b> http://www.X-Hacker.org [<<Previous Entry] [^^Up^^] [Next Entry>>] [Menu] [About The Guide]
 Chapter 1: Introduction
------------------------------------------------------------------------------

     Welcome to CA-Clipper/ExoSpace, the DOS extender for CA-Clipper.
     CA-Clipper/ExoSpace allows your CA-Clipper applications to run in
     protected mode, thereby eliminating the DOS 640 KB barrier and allowing
     CA-Clipper applications to access extended memory directly.

     In protected mode, extended memory is directly available without
     requiring swapping of any kind.  This in itself would be exciting
     enough, but it also has a number of other important implications.

 Say Good-bye to Load Size

     Load size concerns are a thing of the past.  CA-Clipper/ExoSpace
     applications can be loaded in as little as 256 KB (or less) of low DOS
     memory.  As long as enough extended memory is available, your
     application will run fine.  You will have no problems even if available
     DOS memory is being squeezed by network drivers and the like.  Now, you
     can even link and run your CA-Clipper applications while shelled out
     from another CA-Clipper application or a memory-hungry editor!

 No Overlaying Worries

     Similarly, overlaying of code is no longer an issue.  You do not need to
     worry at all about which code to overlay or not to overlay--just specify
     all your .OBJs and .LIBs, and link! Overlaying of code does, in fact,
     occur automatically when your application is running--but it is
     completely automatic and transparent, and you never need to worry about
     it.

     Although overlaying occurs automatically if necessary, if you have
     enough Random Access Memory (RAM), your .EXE will be loaded into memory-
     -as it is used--until the entire .EXE is resident in RAM.  Previously,
     overlaid code had to be swapped in and out of a relatively small overlay
     area as it was needed, so a large application could never be completely
     resident in RAM.  This has obvious performance implications.

 Industry Standard Virtual Memory

     CA-Clipper/ExoSpace replaces CA-Clipper's real-mode DOS/Expanded Memory
     Specification (EMS)-based Virtual Memory Manager with a robust,
     transparent, protected-mode virtual memory engine developed by Rational
     Systems, a leader in protected-mode technology.  This same technology is
     currently used by Lotus, IBM, Quarterdeck, Borland, Symantec, Watcom,
     and hundreds of others, and has shipped millions of copies of commercial
     applications, since 1987.

 Improved Performance

     Without all the swapping that CA-Clipper was forced to do within the
     640 KB DOS limit, the performance of many applications will improve
     visibly and substantially, depending on processor and memory
     configurations.

 Resurrect Your286 PCs

     CA-Clipper/ExoSpace breathes new life into 80286-based machines.  With
     2 MB or more of RAM, many 286 machines will now run CA-Clipper
     applications faster than ever before, and will be able to run
     applications that they may not have been able to run before because of
     restricted DOS memory.

 What About 386 and 486 Machines?

     Applications running on 386 and 486 machines also benefit, of course.
     Instead of continually having to swap data from EMS or having to load
     overlaid code from disk, applications can now use all of a machine's
     memory directly.  Swapping only occurs when all available memory is
     exhausted, instead of when the first 640 KB is full.  In effect,
     CA-Clipper/ExoSpace raises the 640 KB RAM ceiling to include all
     available memory.  This will benefit almost any application on any
     supported machine.

 Protected Mode = Protected Code!

     Protected mode, as its name implies, provides a greater level of
     protection to your applications.  C or Assembler code that has not yet
     been fully debugged, whether it is in a third-party library or your own,
     will usually generate an exception error, detected directly by the CPU,
     as soon as it does something wrong, rather than corrupting memory and
     leading to mysterious and difficult-to-trace problems later on.  This
     makes it easier to find the source of the problem, and if a third-party
     library is the source of a problem, it will usually be clear which
     library is at fault.


Online resources provided by: http://www.X-Hacker.org --- NG 2 HTML conversion by Dave Pearson