[Prev][Next][Index][Thread]

Executor 1.99c is out + FAQ



Hi Folks,

Executor 1.99c is out for NEXTSTEP and Linux.  There is no 1.99c for DOS,
because the benefits are too slight to make it worth downloading.

The major changes are Linux related:

	We now link with the XFree86 3.1 shared libraries (X11R6)

	We detect a variety of reasons to not use the SHM extension
		and back off appropriately

	We do not allow you to attempt to resize the Executor window

In addition, a bug that prevented Executor/NEXTSTEP from printing more
than 128 pages at a time under Word has been fixed, and a bug that affects
all copies of Executor that prevented a particular type of "transparency"
drawing mode from working has been fixed.

I had a wonderful time in Chile, I wound up spending more time answering
e-mail when I got back than I expected, hence the relatively small number
of changes in 1.99c and the missing Appendix A in the FAQ printed below.

I'm off to Denver for the week.  I'll be working on Appendix A during the
day and visiting old friends during the evening.

To pick up 1.99c for Linux, you'll need to retrieve  
ftp.cs.unm.edu:/pub/ardi/Executor_Linux/executorlinux199c.tar.gz (remember
to use BINARY mode when you pick it up).

To pick up 1.99c for NEXTSTEP, you'll need to retrieve
ftp.cs.unm.edu:/pub/ardi/Executor_NEXTSTEP/Executor.gz and
ftp.cs.unm.edu:/pub/ardi/Executor_NEXTSTEP/%System.gz (remember
to use BINARY mode when you pick up these two files).  You'll then need
to gunzip both files and replace your current /LocalApps/Executor.app/Executor
and /LocalApps/Executor.app/ExecutorVolume/System Folder/%System files,
remembering to keep the permissions the same as your current files.

	--Cliff
	ctm@ardi.com
	(e-mail sent to "questions@ardi.com" is handled more promptly)

=====================================================================
	FAQ for Executor [last updated 94-11-28]

This set of answers to Frequently Asked Questions is not designed to
take the place of our Executor manual.  However, currently our manual
is not available on-line, so this FAQ does briefly touch on some
issues that are covered more in depth in our manual.

In addition to this FAQ, there should be README files associated with
the demo versions of Executor and there is also an Executor/DOS
document that describes how to get started with Executor/DOS from a
DOS user's point of view, which may be useful to users of Executor on
other platforms as well.  That document is called "ERNSTOUD.TXT",
since it's hard to come up with useful names when constrained by the
DOS 8.3 filename limits and the author of the document is Ernst
J. Oud.

[1] Executor in General

	[1.1]  What is Executor?
	[1.2]  On which platforms is Executor available?
	[1.3]  Who makes Executor?
	[1.4]  Pronunciation?
	[1.5]  Does Executor require you to obtain ROMs or System Files
		from Apple?
	[1.6]  How long has Executor been in development?
	[1.7]  What techniques were used to rewrite the OS and Toolbox
	[1.8]  What limitations does Executor have?
	[1.9]  Does Executor run all applications?
	[1.10]  What do the various Executor version numbers mean?
	[1.11]  Where can I pick up the Executor demos?
	[1.12]  Is Executor shareware?
	[1.13]  How do the demo versions differ from the commercial versions?
	[1.14]  What's next?
	[1.15]  When will 2.0 be out?
	[1.16]  How can I get in ARDI's beta program?
	[1.17]  Does Executor have networking support?
	[1.18]  How do you install Fonts and Desk Accessories (DAs)?
	[1.19]  Will Desk Accessories work under Executor?
	[1.20]  Does E/D run xxx?
	[1.21]  What's the best way to keep informed about Executor?
	[1.22]  Why shouldn't I send e-mail to ctm@ardi.com?
	[1.23]  What is an ".hfv" file?
	[1.24]  Can I launch apps directly from the command line?

[2] Executor/DOS

	[2.1]  Which FTP sites will carry stable versions of the E/D demo?
	[2.2]  What are the hardware requirements for Executor/DOS?
	[2.3]  What do I do if my Super VGA card isn't VESA compliant?
	[2.4]  Executor crashes with "GrSetMode ; unknown adapter type
		 in driver."
	[2.5]  Does E/D require an ASPI driver to access SCSI?
	[2.6]  Have you released Executor for OS/2 yet?

[3] Executor/Linux

	[3.1]  Can I buy the Linux version now?
	[3.2]  Why can't the Linux version access floppies with option-shift-2
	[3.3]  Are we ready to hear about Executor/Linux bugs?
	[3.4]  Should bug reports be sent one at a time or in a big list?
	[3.5]  Why is there no Executor for NetBSD or FreeBSD?
	[3.6]  Where are the bitmaps stored on the Linux version of executor?
	[3.7]  Will there be an SVGALIB version of E/L in the future?
	[3.8]  Why do all the non-Executor Windows get creepy colors when
		Executor is running?


[4] Executor/NEXTSTEP

	This section has not yet been written.

[1.1]  What is Executor?
------------------------

	Executor is a commercial emulator that allows non-Macintosh
	hardware to run some applications originally written on a
	Macintosh.  Executor has many limitations, see below.

[1.2]  On which platforms is Executor available?
------------------------------------------------

	Executor/DOS (E/D) is an implementation that runs under
	DOS and Windows.  Executor/NEXTSTEP (E/NS) is an implementation
	that runs under NEXTSTEP, both on original NeXT hardware
	and Intel based hardware running NEXTSTEP.  Executor/Linux
	is an implementation that runs under Linux, using X-Windows.

[1.3]  Who makes Executor?
--------------------------

	ARDI				questions@ardi.com
	Suite 4-101
	1650 University Blvd., NE
	Albuquerque, NM  87102

	+1 505 766 9115 Phone		+1 505 247 1899 FAX

[1.4]  Pronunciation?
---------------------

	Ig-zek'-yu-tor

[1.5]  Does Executor require you to obtain ROMs or System Files from Apple?
---------------------------------------------------------------------------

	No.  Executor reimplements from scratch the Macintosh
	Operating System and Toolbox.

[1.6]  How long has Executor been in development?
-------------------------------------------------

	Work began in September of 1986.

[1.7]  What techniques were used to rewrite the OS and Toolbox
--------------------------------------------------------------

	Entirely clean-room techniques.  That is to say none of the
	Apple ROMs or Apple System File were ever disassembled.
	Instead ROMlib (the section of Executor that emulates the OS
	and Toolbox) was written from the manuals "Inside Macintosh",
	and Tech. notes.  That isn't sufficient to get the degree of
	compatibility that we need, so tests were written and run on
	Macs to see what a real Mac would do.  In addition, we run
	applications under Executor and when they deviate from how
	they would behave on a Mac, we take a look at what is going on
	and fix Executor accordingly.

[1.8]  What limitations does Executor have?
-------------------------------------------

	Because the OS and Toolbox have been rewritten from scratch,
	Executor has many limitations, including no AppleTalk, no
	sound, no System 7, no INITs, no CDEVs and no
	Internationalization.  Executor can read and write 1.4 Mb Mac
	formatted floppy disks, but can not format floppies, nor can
	it read or write 800 Kb floppy disks.

	E/NS can access the serial ports and can print, E/D and
	E/L can not.

[1.9]  Does Executor run all applications?
------------------------------------------

	Currently, no.  In addition to applications that won't run
	because they require something that we currently don't
	support (e.g.  System 7), due to our rewriting of the OS
	and Toolbox, there is room for enough incompatibility that
	many large programs do not work.  For this reason, we make
	demo versions of Executor available for potential customers
	to run before purchasing Executor (see below).

	We are in the process of cataloging what we have tested
	and will include that as appendix A.

[1.10]  What do the various Executor version numbers mean?
----------------------------------------------------------

	Any 1.x release other than 1.99 is a black and white release.
	Any release that ends in a lower case letter is technically an
	"experimental" release.  In general, experimental releases are
	pre-beta or beta releases that will eventually be released
	with a higher version number.

	The most recent non-experimental release of Executor/NEXTSTEP
	is version 1.3.  The most recent non-experimental release of
	Executor/DOS is 1.2.  There has not yet been a
	non-experimental release of Executor/Linux.

	Currently, with the recent addition of color support to
	Executor, Executor is experimental for all platforms.  We are
	trying to release new versions for all platforms in lockstep,
	so 1.99b has roughly the same feature set and bug set under
	DOS, Linux and NEXTSTEP.  Our goal is to put out a new 1.99<x>
	version each week, but with the holidays and people taking
	vacations, we are not currently meeting that goal -- we're
	still making tremendous progress, though.


[1.11]  Where can I pick up the Executor demos?
-----------------------------------------------

	As long as they put up with us, the most up to date
	experimental versions of Executor can be found on
	ftp.cs.unm.edu in /pub/ardi.  However, ftp.cs.unm.edu does not
	have the bandwidth to accept many simultaneous users, so when
	we're happy with the stability of one of our color
	experimental versions, we'll make that version available on
	the tradtional sites for commercial demos of the given
	platform.  See the platform specific answers for a list of
	these sites.

	We don't mind people making our current experimental versions
	available on other sites, but *please* be sure to include all
	the READMEs and FAQs which will allow users to find more
	current versions of Executor as they're released.


[1.12]  Is Executor shareware?
------------------------------

	No.  Executor is a commercial program available from ARDI.
	The demo versions are the only versions that should be found
	on bulletin boards or FTP sites.  If you find a non-limited
	version of Executor available to download, it was put there
	illegally.

[1.13]  How do the demo versions differ from the commercial versions?
---------------------------------------------------------------------

	The E/D, E/L and E/NS demos are time limited to ten
	minutes of use.  Once your ten minutes are up, you are
	thrown out, but you can restart the program again and run
	for another ten minutes if you'd like.  In addition, the
	E/D demo does not allow you to access Macintosh formatted
	SCSI hard drives.

[1.14]  What's next?
--------------------

	Our immediate goal is to get Executor 2.0 out.  Back before
	1.99 was out, we had a set of goals for what would be in 2.0.
	We have had enough trouble implementing 32-bit color QuickDraw
	that we have had to pare some features out of what we had
	orginally proposed for the 2.0 feature set.  Features present
	in 2.0 are *still* subject to change, but our current plans
	are to add:

		A file browser -- we've written one in house.  We will
		be releasing it with source.

		Better documentation

		The ability to change the screen "depth" (number of colors
		that can be present at one time on the screen) and size
		on the fly.

		A simpler method for installing fonts and Desk Accessories

		A better set of demo and utility programs

	We also have a set of general and platform specific bugs that
	we need to have fixed before we can freeze 2.0.

	Beyond 2.0, we want to make Executor compatible with Apple's
	System 7.5, so you'll be able to purchase a copy of System
	7.5, install it on top of Executor and get even more
	compatibility and features.

[1.15]  When will 2.0 be out?
-----------------------------

	The answer here is embarrassing.  Our original target was
	summer of 1994.  With the experimental releases coming out
	regularly, there is a light at the end of the tunnel, but we
	can't say exactly when it will be.  We had some
	miscommunication with our investors that prevented us from
	working very efficiently in the spring, summer and fall of
	1994.  It looks like we've got that cleaned up now.

[1.16]  How can I get in ARDI's beta program?
---------------------------------------------
	
	Our beta program is really boring.  The only thing that you
	get that you can't get over the net is an actual set of
	floppies that contain installation scripts.  As such, we
	really don't need new beta members.  Just pick up the
	experimental versions and keep us informed.

	
[1.17]  Does Executor have networking support?
----------------------------------------------

	Currently, no.  Nor, will it be available in Executor 2.0.
	Networking support is planned for release 3.0, but we do not
	yet have an estimated date of completion for 3.0.  The first
	platform to have networking support built in will probably be
	Linux.

[1.18]  How do you install Fonts and Desk Accessories (DAs)?
------------------------------------------------------------

	The short answer is "wait for our new file browser that will
	allow you to install fonts and DAs via drag and drop."
	However, if you are an old time Macintosh user and you have a
	copy of Font/DA Mover on a Mac, you can copy the Executor
	System file over to a Mac, install the Fonts/DAs over there
	and then bring the System file back to Executor.  This is
	tricky and not for the faint of heart.

[1.19]  Will Desk Accessories work under Executor?
--------------------------------------------------

	Currently Desk Accessory support is very weak; most will not
	run.  After we get the browser released that allows easy
	installation and removal of desk accessories, we'll spruce up
	our DA code and work on insuring that some of the more popular
	DAs work.

[1.20]  Does E/D run xxx?
-------------------------

	With all the rush to get 2.0 out the door ASAP, we're
	putting our testing people to work testing new experimental
	versions, instead of testing 1.2.  There is plenty that
	1.2 will not run, and as such, we recommend people try out
	the demo before purchasing Executor.

	We will be making a list of what runs and what doesn't available
	as part of this document as Appendix A, but that information is
	not available in this release of the FAQ.

[1.21]  What's the best way to keep informed about Executor?
------------------------------------------------------------

	Join the Executor mailing list.  Send a message to
	"majordomo@nacm.com".  Make sure your subject line is blank
	and your message body says:

	subscribe executor yourname@yoursite.yourdomain

	We try to post important events to the net, and send new
	release information via U.S. mail to our current customers,
	but the Executor mailing list is where we post news about our
	experimental versions and where you can send mail to talk with
	other people who are using Executor.

	If you'd rather get the Executor Interest information in a
	digest form, say "subscribe executor-digest" instead of
	"subscribe executor" as described above.  The digest is a new
	feature, currently it's made once a day, but that may change.

	To remove yourself from either mailing list, send a message to
	majordomo@nacm.com with a body of "unsubscribe executor" or
	"unsubscribe executor-digest".

	The Executor Interest mailing list is administered by a
	volunteer.  We do not directly control the list.  Lately there
	has been a request that we operate a mailing list for
	announcements only.  Although we can't provide that right now,
	we're hoping the digestification will make such a separate
	list much less needed.

[1.22]  Why shouldn't I send e-mail to ctm@ardi.com?
----------------------------------------------------

	Cliff gets tons of e-mail.  E-mail sent to questions@ardi.com
	is answered much more punctually.

[1.23]  What is an ".hfv" file?
-------------------------------

	Executor has the ability to store an entire Macintosh "volume"
	(i.e. filesystem corresponding to a disk drive or a partition
	within a disk drive) in a DOS or UNIX file.  Under DOS, this
	feature is very handy because there is no way to have files
	with long names and upper and lower case characters in their
	names unless you use a ".hfv" file.

[1.24]  Can I launch apps directly from the command line?
---------------------------------------------------------

	Yes.  If an app resides within a UNIX or DOS filesystem, you
	can specify the name of the app, and documents that you would
	like the app to open when it starts up, on the command line.
	In 1.99c, the license info is still printed, and must be
	dismissed by clicking on the "OK" button, or typing a RETURN.
	We know this is annoying and will be fixing it so that once
	you've read the license you won't have to see it again until
	you ask to see it explicitly.

	Apps that reside in ".hfv" files can't currently be launche
	from the command line.  This will change soon.

[1.25]  What are all the command line switches?
-----------------------------------------------

	Switch      Min     Max     Default         Default when switch
                                                    is present, but with no
                                                    value specified

	macbpp      1       8       4               8
	realbpp     1       8       4               8
	refresh     0       60      0               10
	shadow      0       1       0               1

	nosplash    0       1       0               1
	debug       0       10      0               10

	noclock     0       1       0               1
	noint8      0       1       0               1

	drivecheck  0       1       0               1

	nomouse     0       1       0               1

	applzone    128     8192    1024            2048
	syszone     128     4096    512             1024
	stack       64      4096    256             128


	nativecode  0       1       1               1

	The switches macbpp, realbpp, refresh and shadow all affect
	how the screen is emulated.  The number of bits per pixel that
	the program running under Executor sees is specified by
	macbpp.  If macbpp is set to 1, then there are only two
	"colors" (black and white) available.  If it is set to 8, two
	hundred fifty six colors are available.  The switch realbpp
	specifies how many bits per pixel the display is actually
	configured to show to you.  In general, you want these two
	switches to be given the same value.

	When Executor first starts up, a "splash screen" is printed.
	You can omit this splash screen with the nosplash switch.

	Sometimes Executor detects potential errors that may be useful
	for us to see when we try to figure out why a given program
	won't run under Executor the debug option controls the
	printing of these error messages.

	One of the hardest things to emulate properly is the internal
	timing mechanisms of a Macintosh.  Sometimes it is desirable
	to turn off our clock emulation.  Both noclock and noint8 do
	this, although in slightly different ways.

	When Executor displays a standard "get" or "put" dialog box,
	there is a button marked "drive" that allows you to cycle
	through the Macintosh volumes that Executor knows about.  You
	can use the drivecheck switch to have Executor examine your
	DOS drives each time you click the "drive" button.  In
	general, this is more annoying than it is useful.

	Although Executor is almost totally useless without a mouse,
	Executor/DOS can be started without a mouse if you use the
	nomouse switch.  If you don't use that switch and you don't
	have a mouse, Executor/DOS will politely tell you that you
	can't run Executor.

	The switches applzone, syszone and stack control how much
	memory is allocated to the application, the system, and the
	application stack.  In general, if you have more memory,
	you should override the default applzone and allow Executor
	to use more memory.

	Executor 1.99<x> uses a new "synthetic CPU" which is much
	faster than the synthetic CPU in previous releases of Executor.
	The speed increase is due to our use of native code.  However,
	like anything that is new, there's a chance that our improvement
	has some hidden drawbacks.  You can turn off the use of native
	code by specifying nativecode 0.

	Here is an example of some of those switches:

		executor -applzone 4096 -noclock -nativecode 0

	That would allocate 4 Mb of memory for the applications use,
	turn off our clock emulation and revert to a slower type of
	synthetic CPU emulation -- an unlikely combination of
	switches.

[1.26]  Can I have Executor use more than 8Mb for the application zone?
-----------------------------------------------------------------------

	Currently, no.  We are reorganizing our memory layout to allow
	you to do this in the future.


[2]  Executor/DOS
=================

[2.1]  Which FTP sites will carry stable versions of the Executor/DOS demo?
---------------------------------------------------------------------------

	Currently the most recent "stable" version of Executor/DOS is
	1.2.  That version is black and white and doesn't run as much
	software as 1.99b does.  However, 1.99b is just a little too
	rough to put out for general inspection, so we're waiting for
	1.99d or greater before we put a color version on the SimTel
	mirrors.

	E/D is available from the SimTel mirrors.  The primary
	SimTel mirror is oak.oakland.edu, and you can find the
	Executor/DOS demo within the "SimTel/msdos/emulator"
	directory.  It comes in four pieces: exctr12?.zip where ?
	represents the letters a,b,c and d.

        Other SimTel mirrors are:

         St. Louis, MO:  wuarchive.wustl.edu (128.252.135.4)
                         /systems/ibmpc/msdos
         Corvallis, OR:  archive.orst.edu (128.193.2.13)
                         /pub/mirrors/simtel/msdos
         Australia:  archie.au (139.130.4.6)
                         /micros/pc/oak
           England:  src.doc.ic.ac.uk (146.169.2.10)
                         /pub/packages/simtel
           Finland:  ftp.funet.fi (128.214.248.6)
                         /pub/msdos/SimTel
            France:  ftp.ibp.fr (132.227.60.2)
                         /pub/msdos
           Germany:  ftp.uni-paderborn.de (131.234.2.32)
                         /SimTel/msdos
         Hong Kong:  ftp.cs.cuhk.hk (137.189.4.57)
                         /pub/simtel/msdos
            Israel:  ftp.technion.ac.il (132.68.1.10)
                         /pub/unsupported/dos/simtel
            Poland:  ftp.cyf-kr.edu.pl (149.156.1.8)
                         /pub/mirror/msdos
            Sweden:  ftp.sunet.se (130.238.127.3)
                         /pub/pc/mirror/SimTel/msdos
        Switzerland:  ftp.switch.ch (130.59.1.40)
                         /mirror/msdos
            Taiwan:  NCTUCCCA.edu.tw (140.111.1.10)
                         /PC/simtel
          Thailand:  ftp.nectec.or.th (192.150.251.32)
                         /pub/mirrors/msdos

	If you have AFS, you can pick up Executor/DOS demo 1.2 by
	changing directories to
	/afs/umich.edu/group/itd/archive/msdos/emulators/macintosh.

[2.2]  What are the hardware requirements for Executor/DOS?
-----------------------------------------------------------

	For Executor/DOS 1.2 you need a '386 or better, VGA, 7 Mb disk
	space, a 3.5" 1.44 Mb floppy drive, and 4 Mb RAM.  A SCSI
	Controller is needed only if you want to access external
	Macintosh hard disks or PowerBooks.

	Executor/DOS 1.99<x> should work in sixteen colors on any VGA,
	although we do not have the facilities to test more than a few
	in house.  In addition, if you have a Super VGA that is "VESA
	compliant", Executor/DOS should be able to provide 256 colors.

[2.3]  What do I do if my Super VGA card isn't VESA compliant?
--------------------------------------------------------------

	There is a shareware SVGA utility that provides VESA compliance
	for SVGA cards that normally are not VESA compliant.  At the time
	this FAQ was last modified, univbe50.zip was the most recent
	release of this extender.

	It is not a product of ARDI, but as a convenience to people
	picking up experimental versions of Executor, the file
	univbe50.zip is available in
	ftp.cs.unm.edu:/pub/ardi/Executor_DOS.  If you use it, you
	should pay the shareware fee as described in the documentation
	included in the zip file.  If you have a recent SVGA card you
	probably don't need univbe.  There may be a more recent
	version of univbe in oak.oakland.edu:/SimTel/msdos/graphics.

[2.4]  Executor crashes with "GrSetMode ; unknown adapter type in driver."
--------------------------------------------------------------------------

	1.99b has problems when Microsoft's display.sys driver is in
	config.sys.  We are in the process of updating the code that
	has this problem and expect a fix soon.  In the meantime, you
	must remove display.sys from the config.sys section you use
	when you're using Executor/DOS.

[2.5]  Does E/D require an ASPI driver to access SCSI?
------------------------------------------------------

	If your SCSI drivers patch the "INT 13" BIOS calls, then an
	ASPI driver is not needed.  As long as "INT 13" can allow Executor
	to read a SCSI drive, there is no need to use ASPI.

[2.6]  Have you released Executor for OS/2 yet?
-----------------------------------------------

	We plan on making an OS/2 specific version of Executor, but only
	after we get Executor 2.0 shipping


[3]  Executor/Linux
===================

[3.1]  Can I buy the Linux version now?
---------------------------------------

	(Technically, our software is licensed, not sold) Not yet
	(as of November 23), but soon we'll start licensing the
	experimental versions so that you won't have the time limit
	interrupting you.

[3.2]  Why can't the Linux version access floppies with option-shift-2
----------------------------------------------------------------------
		(like  the DOS version does)?
		-----------------------------

	Oversight on our part.  Executor/Linux 1.99b and 1.99c were
	rushed out the door so that folks could get a peek at it and
	contribute suggestions while we were in the process of
	polishing it up.  This should be fixed soon.

[3.3]  Are we ready to hear about Executor/Linux bugs?
------------------------------------------------------

	Yes.  Send them to "bugs@ardi.com" and make sure that you
	identify what version of Executor you're running (i.e.
	Executor/Linux 1.99b) as well as what kernel and X-Windows
	you're using.  Please mention what Mac software you were
	running when you encountered the bug and explain whether the
	bug is reproducible or not.  If Executor provides some sort of
	debug output, please include that as well.  Our NEXTSTEP
	version has a bug-sending facility that automatically fills in
	all that information for you.  If we get some time, we'll
	incorporate that code into Executor/Linux.

[3.4]  Should bug reports be sent one at a time or in a big list?
-----------------------------------------------------------------

	In general, it's easier for *us* if you send them one at a
	time.  Internally we use "gnats", a free bug-tracking tool and
	we need to separate each bug into a single file for tracking.
	On the other hand, since by providing us with bug reports
	you're helping us out, we won't refuse bug reports that are
	collections.

[3.5]  Why is there no Executor for NetBSD or FreeBSD?
------------------------------------------------------

	We don't currently have the manpower to support it.  The Linux
	release is a byproduct of the fact that we use Linux in house.
	It's also a very rough release.  After we've cleaned up the
	Linux version and get some Executor/Linux sales, we'll
	look into the feasibility of Executor for NetBSD and FreeBSD.

[3.6]  Where are the bitmaps stored on the Linux version of executor?
---------------------------------------------------------------------

	All versions of executor maintain an internal bitmap
	corresponding to the actual screen.  We accrue a "dirty rect"
	as the program draws to what it thinks is the screen via
	Executor's QuickDraw implementation.  We periodically update
	the _real_ screen (e.g., the X window) by transferring the
	dirty rect across.  So basically our graphics interface to the
	host machine consists of nothing more than blitting rectangles
	to the screen, which aids our portability.  Under X, we use
	shared memory extensions for speed, but we don't do anything
	fancy like trying to cache Mac fonts on the X server side.
	Spending time trying to do so would be a bad idea for a number
	of reasons I won't go into.

	"Refresh" mode is useful when the program directly manipulates
	the frame buffer itself.  In this mode, we periodically
	analyze the internal screen memory to decide what has been
	changed, and transfer the changed data to the real screen.

[3.7]  Will there be an SVGALIB version of Executor/Linux in the future?
------------------------------------------------------------------------

	Probably.  Executor/Linux would clearly get a major
	performance benefit from an SVGALIB implementation.  We are in
	the process of rewriting our graphics and event handling code
	so that it will be easy to add this sort of capability, but we
	don't yet have a timetable for doing so.

[3.8]  Why do all the non-Executor Windows get creepy colors when Executor
--------------------------------------------------------------------------
		is running?
		-----------

	Currently Executor requests a "private color map" so that it
	can get allocate display colors that are as close to what the
	Mac program has requested as possible.  It is possible for us
	to make an approximation that will be good enough for many
	applications to run and not make all the other colors look so
	bad.  We'll be doing this in a future version.