Path: utzoo!attcan!uunet!husc6!uwvax!vanvleck!uwmcsd1!ig!agate!ucbvax!pro-colony.UUCP!crash
From: crash@pro-colony.UUCP (John Stephen III)
Newsgroups: comp.sys.apple
Subject: Appleworks
Message-ID: <8806200716.AA09840@crash.cts.com>
Date: 20 Jun 88 02:42:20 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: pnet01!pro-simasd!pro-colony!crash@nosc.mil
Organization: The Internet
Lines: 20

In response to Sean Kamaths recent letter regarding Appleworks:

The pre-loading that Appleworks does is done through ProDOS but any accesses
to those loaded segments thereafter are handled by Appleworks and its own
memory management.  In fact the code segments are handled internally in
exactly the same fasion as the data (meaning that it is not simply 'loaded
into a ram-disk').

As far as I know the print buffering that 'captain Albatross' (sorry if I
misspelled that, Cap'n!) is referring to is unique to the Applied Engineering
expander software.  It works for both the RamWorks and GSRam products but not
for the RamFactor.


  nnnnn   |
 / . . \  |  UUCP: [ ihnp4 sdcsvax nosc ] !crash!pnet01!pro-sol!pro-simasd!
(|  u  |) |                               !pro-colony!crash
 \ \_/ /  |  ARPA: crash!pnet01!pro-sol!pro-simasd!pro-colony!crash@nosc.mil
  \   /   |  ProLine: crash@pro-colony
/-->=<--\ |