executor/docs/faq.xml

<?xml version="1.0" standalone="no"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN">
<article class="faq">
<articleinfo>
  <corpauthor>
    <ulink url="http://www.ardi.com/">ARDI</ulink>
  </corpauthor>
  <title>Frequently Asked Questions about ARDI and ARDI's Products</title>
  <titleabbrev>ARDI FAQ</titleabbrev>
  <abstract>
    <para>
This article provides answers to questions that have at one time been
frequently asked about ARDI, Executor and Carbonless Copies.
    </para>
  </abstract>
  <copyright>
    <year>1996</year>
    <year>1997</year>
    <year>1998</year>
    <year>1999</year>
    <year>2000</year>
    <year>2001</year>
    <year>2002</year>
    <holder>Abacus Research & Development, Inc.</holder>
  </copyright>
</articleinfo>

<note>
<para>
This document is a "quick and dirty" way to provide answers to
questions associated with ARDI.  Its existence admits
that ARDI's web pages and documentation need work.  As ARDI improves
its web pages and documentation this document will shrink.
</para>
</note>

<note>
<para>
This document is provided as is.  The information in it is
<emphasis>not</emphasis> warranted to be correct; you use it at your own risk.
</para>
</note>

<qandaset defaultlabel="number">
  <qandadiv>
    <title>ARDI</title>
<para>
This is the list of Frequently Asked Questions about Abacus
Research and Development, Inc., a Delaware Corporation.
platforms.
</para>
  <qandaentry>
    <question>
<para>
Is this a placeholder?
</para>
    </question>
    <answer>
<para>
Yes, because qandadiv apparently requires at least one question.
</para>
    </answer> 
  </qandaentry>
  </qandadiv>
  <qandadiv>
    <title>Executor</title>
<para>
This is the list of Frequently Asked Questions about Executor,
the only Macintosh Emulator that requires no intellectual property
from Apple Computer, Inc.
platforms.
</para>
    <qandadiv>
      <title>Executor in General</title>
      <qandaentry>
        <question>
<para>
How is Executor pronounced?
</para>
        </question>
        <answer>
<para>
Ig-ZEK-yu-tor
</para>
        </answer>
      </qandaentry>  
      <qandaentry>
        <question>
<para>
What version of the Macintosh operating system does Executor emulate?
</para>
        </question>
        <answer>
<para>
Executor knows how to emulate most of System 7.0, but the default
version that Executor reports to applications is System 6.0.7, because
some bad programs make calls to undocumented System 7.0 traps if we
acknowledge that we've implemented System 7.0.  Each time a different
application is run under Executor, Executor checks an application
specific configuration file for application specific settings.  Many
of the configuration files adjust the System to 7.0.
</para>
<para>
You can manually adjust the system version.  Start Executor and call
up the Preferences Panel with Cmd-shift-5 [see <xref linkend="wherecmd"/>].  Set
the System to 7 and click OK (don't save yet; these are just the
Browser settings).  Now start your application, call up the
Preferences Panel again, and save it with the System 7 setting.  After
that, Executor will automatically invoke System 7 support when you run
that application.
</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
What limitations does Executor 2 have?
</para>
        </question>
        <answer>
<para>
Because the OS and Toolbox have been rewritten from scratch, Executor
2 has limitations, including no serial port access, no modem use, no
AppleTalk, primitive sound, limited System 7 support, no INITs, no
CDEVs and no Internationalization.
</para>
<para>
Executor can read and write 1.44 MB Mac formatted floppy disks, but
due to limitations in PC hardware, <emphasis></emphasis> read or write 800
KB floppy disks.
</para>
<para>
In the lab we have limited serial port access and we're working on
improving sound.
</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
If I have 800 KB floppies, what can I do?
</para>
        </question>
        <answer>
<para>
Very little.  It is not ARDI's fault and there's nothing we can do
about it, but the way that Apple squeezed 800 KB onto floppies when
PCs were only getting 720 KB on floppies was to write more data on the
floppy tracks far from the center than on the tracks near the center.
This was clever, but extremely incompatible.
</para>
<para>
There <emphasis></emphasis> ways to squeeze more information onto PC floppy
drives than PCs usually use.  However, these methods <emphasis></emphasis>
be used to write or even read 800 KB Macintosh formatted floppies.
</para>
<para>
Luckily, very little is supplied on 800 KB floppies anymore, but if
you have some, you're almost definitely going to need the use of a
Macintosh somewhere to copy the contents onto "HD" 1.4 MB formatted
floppies (PCs and Macs use the same low-level format for 1.4 MB
floppies).
</para>
<para>
One Executor Enthusiast suggested using Kinko's public Macs for this
purpose, and this description was given:
</para>

<blockquote><attribution>An Executor Enthusiast</attribution>
<para>
1.  Moving 800 KB Mac Files onto 1.44 MB Mac disks.  The easiest thing
that I have found when working on a real Mac is to preformat the
Mac disks to 1.44 MB.  Insert the 1.44 MB disk and eject it with
(Cmd-E).  Then insert the 800 KB mac disk.  Drag the icon of the 800
KB disk over the 1.44 MB disk.  All the files will be transferred as
will the file names.  The Mactools fastcopy program can also copy
between densities.
</para>
<para>
2.  Kinko's Public Machines.  Kinko's public Macs are equipped with a
program known as "Desk Tracy" which is designed to stop people from
pirating Kinko's software from the hard disk.  The problem is that when
you are copying files between your own disks the program will still
trigger if the file has a namesake on the Kinko's machine. What you
will need to do is get a Kinko's employee to shut the program off,
which is obviously a discretionary call with them.  I didn't have a
problem and have done it twice, but we obviously will be using
different Kinko's.
</para>
</blockquote>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Does Executor have networking support?
</para>
        </question>
        <answer>
<para>
Currently, no.  Some Networking support may be included in Executor 3,
but we do not yet have an estimated date of completion for Executor 3.
The first platform to have networking support built in will probably
be Linux.  NOTE: networking support will most likely first be an
implementation of Open Transport and/or MacTCP, followed by EtherTalk.
Supporting AppleTalk over serial lines is unlikely to happen due to
differences in PC and Mac hardware.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How do you install Fonts and Desk Accessories (DAs)?
</para>
        </question>
        <answer>
<para>
You just drag them into the hot-band and our browser will do the right
thing.  However, we only support bit-mapped fonts, not Type 1 or
TrueType fonts.  In addition, there is a bug which causes the hot-band
to forget which desk accessories have been loaded, which then makes it
impossible to remove desk accessories.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Will Desk Accessories work under Executor?
</para>
        </question>
        <answer>
<para>
Currently Desk Accessory support is very weak; most will not run.
When we add support for extensions, we'll also go back and fix some
desk accessory bugs.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why do some installers not work?
</para>
        </question>
        <answer>
<para>
Currently there is one major class of application installer that is
known not to work with Executor.  Installers based on Apple's old
Installer do not work.  An example is Microsoft Word 5's installer.
Some installers require that you use Cmd-shift-5 and set the system
version to 7 and turn on the "Pretend" options before they'll work
properly.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
May I bundle the DEMO version of Executor on a CD-ROM?
</para>
        </question>
        <answer>
<para>
The short answer is "yes".
</para>
<para>
You are able to freely copy and distribute demo versions of Executor,
as long as you follow the restrictions set forth in Executor's license
panel.  Please run the demo version of Executor and choose "About
Executor..." to see the restrictions that you must follow.
</para>
<para>
A suggestion: contact us to make sure you have the latest version of
Executor.  We can tell you if a new release is imminent.
</para>
        </answer>
      </qandaentry> 

    </qandadiv>

    <qandadiv>
      <title>Using Executor</title>
      <qandaentry>
        <question id="wherecmd" xreflabel="Where are the Cmd (Clover) and Option keys?">
<para>
Where are the Cmd (Clover) and Option keys?
</para>
        </question>
        <answer>
<para>
On a PC keyboard, Executor uses the left "Alt" key as a Cmd key and
the right "Alt" key as the Option key.
</para>
        </answer>
      </qandaentry>

      <qandaentry>
        <question>
<para>
What is an image file?
</para>
        </question>
        <answer>
<para>
Some Macintosh sites contain image files that are exact copies of a
Macintosh Hierarchical FileSystem (HFS) volume with a few bytes of
header information prepended.  Executor allows you to use image
files just like HFVs, although they should have the suffix
"<filename>.ima</filename>" instead of "<filename>.hfv</filename>".



</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Can I launch applications directly from the command line?
</para>
        </question>
        <answer>
<para>
Yes.  If an application resides within a UNIX or DOS filesystem, you
can specify the name of the application, and documents that you would
like the application to open when it starts up, on the command line.
Applications that reside in HFV files are specified using colons to
delimit the pathname,
e.g. "<filename>executor MyVolume:directory:application</filename>".


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
I installed a font in Executor, but I still can't print in it.  What's the deal?
</para>
        </question>
        <answer>
<para>
You have to install the same font in Ghostscript.  Otherwise,
Ghostscript will use the default Helvetica font since it can't find
the one you want.  Don't forget to add the paths to the fonts into
your fonts pfb file.
</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Can I have Executor use more than 8 MB for the application zone?
</para>
        </question>
        <answer>
<para>
You can use up to 64 MB for the applzone.
</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
An application I'm trying crashes.  What should I do?
</para>
        </question>
        <answer>
<para>
Perhaps the most common avoidable cause of crashes is insufficient
memory for the emulated application.  You can fix this by increasing
the "applzone" parameter.  For example, many programs which normally
die quickly will work with "executor -applzone 4m" (which allocates 4
MB of space for the emulated application; see the list of command line
switches and their meanings elsewhere in this document).
</para>
<para>
DOS NOTE: If you run "executor -info", it will tell you how much DPMI
memory is available and how much memory is being used by the applzone,
syszone and stack.  If there is less DPMI memory available than the
sum of the applzone, syszone and stack memory requirements, then
Executor will page between DPMI memory and a special "paging" disk
file.  This paging slows you down and also consumes disk space.  It is
possible to manually override the applzone, syszone and stack defaults
with smaller values, but when you do so, you run the risk of not
having enough memory for an application to run.  Unfortunately,
Macintosh programs are often not polite at all when they do not have
enough memory.  The Lemmings demo is an example of such a program; if
you run that program on a real Mac and only give it 1200k of memory,
weird errors will occur.  Doing the same under Executor will also
yield weird errors.
</para>
<para>
If Executor needs to make a paging file, and there is not enough disk
space to create one, you will get an error message during Executor's
startup.  If you have the environment variable "TEMP" set, then
Executor will try to place its paging file there, so if TEMP is set to
point to a small RAM disk, or a disk that is nearly filled, Executor
may run out of memory too easily.
</para>
<para>
Some programs are unhappy with Executor's limited sound support, and
crash.  You can turn on the "pretend sound" option before running the
application in question and see if this helps.  In addition, some
programs have menu items, or preference check boxes that can be used
to disable sound.  It is always recommended that you disable sound
from within a program in addition to using the Executor sound
preferences, if you have to disable sound.
</para>
<para>
One example of a program that will have problems with sound is
"Ultimate Solitaire".  If you do not disable sound from within
Ultimate Solitaire, the game will play fine, until you win.  At that
point it will tell Executor to start playing a sound and request that
Executor notify it when the sound is done playing.  If sound is off,
this will result in Ultimate Solitaire hanging after you win a game.
</para>
<para>
Some programs also save preferences in a file, and if something bad
happens to that file, the program can then get confused and will not
run properly.  Occasionally this happens to Microsoft Word, and you
need to use the browser to delete the file "Word Preferences" from
your "System Folder".
</para>
<para>
Although it should not happen, even our file browser keeps a file
around that can cause trouble if it becomes corrupt.  That file is
"godata.sav".  It stores which folders you have open and the contents
of your "hot-band".  If that file gets corrupt, the file browser may
not run.  In the rare case that the browser won't run, you can use the
"-nobrowser" switch when you start Executor to bypass the browser, but
to get the browser back you'll need to either delete "godata.sav"
somehow or replace exsystem.hfv with one from the original
distribution.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why do some applications claim I don't have an FPU?
</para>
        </question>
        <answer>
<para>
The problem is probably that the applications you are trying to use
try to directly manipulate the FPU unit that some Macintoshes have.
</para>
<para>
The key words are "directly manipulate".  Apple warned software makers
to not directly manipulate the FPU, but to instead use their numerics
library ("SANE" Standard Apple Numerics Environment).  Programs that
don't use SANE, but directly manipulate the FPU run faster on Macs
that have FPUs, but don't run at all on Macs that don't have FPUs.  If
that is actually the source of your problems, then such programs also
wouldn't run on Apple machines like the Quadra 605.  This limitation
is also present on Apple's PowerPC based Macs.
</para>
<para>
One workaround for this problem is an "INIT" called "SoftFPU".
SoftFPU will make a Mac without a co-processor work as though there is
one there, however the floating point computation will be done very
slowly.  However, SoftFPU can't be used with Executor until Executor
supports INITs.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="compact" xreflabel="Why does Compact Pro have trouble with multi-volume archives?">
<para>
Why does Compact Pro have trouble with multi-volume archives?
</para>
        </question>
        <answer>
<para>
Executor takes a short cut that causes trouble for some programs;
Compact Pro is one of them.  The problem is that a real Macintosh can
keep track of volumes that are not physically in the drive.  That is
why Macintoshes sometimes tell you to put one disk in their floppy
drive, then they eject it and ask for another one, then eject it and
ask for the first one.  Executor currently isn't so clever.  When a
disk is ejected, Executor forgets about it.  Few programs count on the
behavior of a real Mac, but those that do currently won't work with
Executor.
</para>
<para>
In Compact Pro's case you can just copy all of the pieces of the
archive to your hard disk, then open the last piece from the hard disk
and everything will work properly.  This workaround requires more hard
disk space than you'd need if you could just read the pieces off a
succession of floppies.
</para>
<para>
Since this difference affects very few programs, it's not as high
priority as adding other new features.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="internet" xreflabel="How can I use Mac software from the internet?">
<para>
How can I use Mac software from the internet?
</para>
        </question>
        <answer>
<para>
Find a site that legitimately has Mac software for use.  There is a
Macintosh FAQ that lists many sites -- here are some of them:
</para>

<simplelist>
<member><ulink url="ftp://ftp.ardi.com/pub/samples">ARDI</ulink> (USA)</member>
<member><ulink url="ftp://liquify.isca.uiowa.edu/mac/infomac">UIowa</ulink> (USA)</member>
<member><ulink url="ftp://wuarchive.wustl.edu/systems/mac/info-mac">wustl</ulink> (USA)</member>
<member><ulink url="ftp://ftp.technion.ac.il/pub/unsupported/mac">technion</ulink> (Israel)</member>
<member><ulink url="ftp://ftp.sunset.se/pub/mac">sunset</ulink> (Sweden)</member>
<member><ulink url="ftp://src.doc.ic.ac.uk/packages/info-mac">info-mac</ulink> (UK)</member>
<member><ulink url="ftp://ftp.is.co.za/info-mac">ftp.is.co.za</ulink> (South Africa)</member>
</simplelist>

<para>
Our <ulink url="TODO">samples directory</ulink> is there to give you a few files in a
variety of different formats that are known to work with Executor.  If
you have trouble downloading Mac software from the internet, you may
want to practice these instructions using the files in our
<ulink url="TODO">samples directory</ulink> first, so you'll know you're not
attempting something impossible.
</para>
<para>
Before transferring a large application, you might want to see what
the requirements of that application are, most sites have a collection
of small notes about applications that you can look at first.
</para>
<para>
Use BINARY mode to transfer the files that you want to use.  Files
whose names end in ".hqx" are usually the easiest to handle.
</para>
<para>
In general, StuffIt Expander will do well with many different types of
files.  However, some of the Web Browsers out there interfere with
StuffIt Expander by trying to expand the files as you're downloading
them from the net.  The browser sees that you're not running on a
Macintosh, so the non-Macintosh information (like the type and
creator) is thrown away!  One way to avoid this problem with some of
the web browsers is to hold the shift key down when you click on a
link that contains a Macintosh file.  There are other ways that
specific browsers can be configured to tell them to <emphasis></emphasis>
expand Macintosh files as they're picking them up.
</para>
<para>
Under DOS, you need to make an HFV file [see <xref linkend="makehfv"/>] that will
be large enough to hold the files as you've downloaded them and also
hold the files after they've been expanded.  Once you've made the HFV
file, copy all the files you've downloaded into it, then follow the
remaining directions.
</para>
<para>
Under all operating systems, your next step is to run StuffIt Expander
and use the "Expand..." menu item from the "File" menu to open each
of the files you've downloaded.  In general, especially when dealing
with files whose names end in ".hqx", StuffIt Expander will do the
right thing.  However, some sites do not store files in ".hqx" format,
and StuffIt Expander may fail.  Remember, under DOS, you must do the
StuffIt Expansion inside an HFV file.
</para>
<para>
If StuffIt Expander fails, you can try using the Get Info option of
Executor's browser to change the creator and type information of the
file.  If you believe the downloaded file in question is a StuffIt
Archive, you can change the type and creator each to "SIT!" and then
try StuffIt Expander again.  If you believe the downloaded file is a
Compact Pro archive, you can change the creator to "CPCT" and the type
to "PACT" and then try StuffIt Expander again.  Similarly, you can use
creator "BnHq" and type "TEXT" if you think that the file is a
MacBinary file.  StuffIt Expander 4.0 should be much better at
automatically determining what format an archive is in.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How can I use Mac software from Bulletin Boards?
</para>
        </question>
        <answer>
<para>
In general, follow the procedure in <xref linkend="internet"/> -- know the
limitations of what Executor can run, transfer in binary mode and use
StuffIt Expander to unpack the files you download.  Just like with
files downloaded from the internet, sometimes you'll need to change
the file type and creator, first.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How can I use Mac software from AOL?
</para>
        </question>
        <answer>
<para>
AOL sometimes (about half the time) uses a format that StuffIt
Expander under Executor has trouble with.  For DOS/Windows users, use
this workaround.  Get a copy of unstuff.exe (available on AOL
compressed as unsitins.exe) and use the -mb tag to convert your
downloaded files to MacBinary format before ever moving them into
Executor.  E.g.:
</para>
<para>
<command>unstuff -mb somefile.sit</command>
</para>

<para>
And you'll get somefile with a different extension.
</para>
<para>
Then start up Executor and use BinHex's Download --> Application
function to convert the file to an application and move it into
an Executor volume simultaneously.
</para>
<para>
Note that if the file can be unstuffed in the usual manner, then
trying to use this workaround will break it.  It's usually best,
therefore, to try normal unstuffing first.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="textfiles" xreflabel="Why do files which aren't text files look like text files?">
<para>
Why do files which aren't text files look like text files?
</para>
        </question>
        <answer>
<para>
Macintosh files have File Type and File Creator information stored in
their directory entries on a Macintosh filesystem.  These two pieces
of information are often lost when the file is put onto a PC.
Executor's default is to assume that a file is a text file, because
text is the most universal of file types.  If the file is not a text
file you'll probably want to use StuffIt Expander (see <xref linkend="internet"/>)
to expand the archive, or in rare cases you'll have to change the File
Creator and File Type.
</para>
<para>
To change a file's Creator and Type information, run Browser, select
the file's icon, and choose Get Info from Browser's File menu.  Then
change File Creator and File Type to the appropriate codes from the
filetype.txt list in the docs directory of your Executor CD.
</para>
<para>
NOTE: in addition to having Type and Creator information, Macintosh
files also often have information in the "Resource Fork" portion of
the file.  That information is also often lost when a file is
transferred to a PC, so it's possible that changing the Type and
Creator information will not be sufficient to allow you to use a Mac
file on a PC under Executor unless you use some sort of archiving
program (e.g. StuffIt, Compact Pro) to make sure all the Mac
information is stored in the "Data Fork" of the file.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
What does "You may open a 32000 character selection" mean?
</para>
        </question>
        <answer>
<para>
As mentioned in <xref linkend="textfiles"/>, files that don't have a file type are
assumed to be text files.  That means that if you double-click on
them, Tex-Edit will try to open up the file, even if the file is in
some other representation.  Executor does not use filename extensions
to determine a file's types, so if you download a file named
"testfile.bin" and then let Executor see the file, it will still
appear to be a text file, even though the name strongly suggests that
it's a BinHex file.
</para>
<para>
You can use StuffIt Expander (see <xref linkend="internet"/>) to expand a variety
of different file types, but you'll have to start StuffIt Expander up
directly, by double-clicking on it and then use the "Expand..." item
in the "File" menu to select the file you want to expand
(e.g. "testfile.bin").

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
What is Speedometer?
</para>
        </question>
        <answer>
<para>
Speedometer is a shareware application that we have included with
Executor for demonstrational purposes.  We have done so with
permission of Speedometer's author, Scott Berfield.  It benchmarks
Macintoshes (and PCs running Executor) to find out how quickly their
CPU, graphics, floating point and disk subsystems work.  The current
version of Speedometer is Speedometer 4.x, but that uses a timing
mechanism that Executor currently doesn't support.  Speedometer 3.23
can give you a rough approximation of how quickly your PC is emulating
a Mac.  Remember, Speedometer is shareware, and ARDI has not paid the
shareware fee for you.  If you repeatedly use Speedometer, please
register it with Scott.
</para>
<para>
Speedometer will show you that Executor is a very efficient emulator.
Please note, ARDI has not put special hooks into Executor to recognize
Speedometer's code and bypass it; Speedometer is treated just like any
other application when run under Executor.  Yes, it would be possible
for us to cheat and make Speedometer return values that are higher
than you could expect to see in real life, but we don't do that sort
of thing.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How can I get a screen dump of Executor?
</para>
        </question>
        <answer>
<para>
Just type Cmd-Shift-3, just like on a Mac.  The difference is that the
screen shot will be in TIFF format (uncompressed, for now) and will be
written in the directory that contains <filename>executor.exe</filename> under
DOS, or in <filename>/tmp</filename> under Linux.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How does your Browser show file size?
</para>
        </question>
        <answer>
<para>
Listing mode will show you the combined size of a file's resource and
data fork.  There is currently no way to determine the size of a
folder.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How does your Browser show free space?
</para>
        </question>
        <answer>
<para>
Select the volume, then choose "Get Info" from the File menu.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why does Browser display question marks for some documents?
</para>
        </question>
        <answer>
<para>
Browser uses the question-mark icon for documents for which it doesn't
recognize the file type and creator.  Furthermore, Browser isn't good
about remembering type and creator information.
</para>
<para>
Here's how Browser works: when Browser starts, it examines each
application that is either on the hot-band or is in a folder that is
open on Browser's desktop.  Then, as it is drawing the icons for
documents, it only uses icons for those applications that it saw upon
startup.
</para>
<para>
So, if the application that creates a document isn't either on the
hot-band or in an open folder, browser will present a question-mark
icon.  A real Mac remembers any icons that it has ever seen (until you
rebuild the desktop).
</para>
<para>
If you have the application that corresponds to the document that has
a question mark, you can get rid of the question mark by dragging the
application onto the hot-band and then quitting Executor and
restarting (or by running an application and then quitting the
application).  When Browser restarts it will see the application in
the hot-band and then remember the icon that should be used for
documents of that type.
</para>
        </answer>
      </qandaentry>
    </qandadiv>

    <qandadiv>
    <title>Executor/Win32</title>
      <qandaentry>
        <question>
<para>
How does Executor/Win32 compare to Executor/DOS?
</para>
        </question>
        <answer>
<para>
Executor/Win32 is a Win32 application and can run only under Windows
95 or later and Windows NT 4 or later.  For those platforms,
Executor/Win32 is preferred, since it will usually have fewer
compatibility problems and it runs in its own window, or full-screen.
Some people are still running OS/2, Windows 3.x or even DOS, and they
can't run Executor/Win32.  Additionally, Executor/Win32 can't be run
on a SX-class 386 machine.  Such machines are very old and very slow,
but they can still run Executor/DOS.
</para>
<para>
Our product, Executor for Windows, includes both Executor/Win32 and
Executor/DOS, so you don't have to choose one or the other when
ordering.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How do I use command-line switches with Executor/Win32?
</para>
        </question>
        <answer>
<para>
Command-line switches can be used by creating a
short-cut or by creating the file <filename>commands.txt</filename>, or a
combination of both.
</para>
<para>
To use command-line switches with a short-cut, you need to create a
short-cut to <filename>executor.exe</filename>, then select it and choose "Properties..."
using your right mouse.  The Properties panel has several tabs, one of
which is labeled "Shortcut".  After selecting the Shortcut tab, you can
then edit the "Target:" field.  Keep the information that is already
in there (e.g. "<filename>C:\ExecWin32\executor.exe</filename>") and then add a space,
followed by the command-line option(s) you want to use when you
double-click on that short-cut (e.g. " -size 800x600 -applzone 4m").
</para>
<para>
Since you can use command-line switches to specify a Macintosh program
for Executor to run, you can create individual short-cuts for
individual programs (e.g. " C:\ExecWin32\Apps\Freeware\Risk!").
</para>
<para>
If you have some command-line switches that you want to apply to
<emphasis></emphasis> invocations of Executor, you can create a file called
<filename>commands.txt</filename> in the same directory that includes
<filename>executor.exe</filename>.  You can put all the switches on one line, or
use a separate line for each switch.
</para>
<para>
Switches in commands.txt override the ones that are specified in
short-cuts.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why do I get only a black screen when running Executor/Win32?
</para>
        </question>
        <answer>
<para>
You've encountered a bug.  The bug may be in your video driver or in
the screen-accessing DLLs that Executor uses.
</para>
<para>
To see if it's in your video driver, try adjusting your Display
settings.  In the Control Panel there's a Display icon.
Double-clicking that should let you select a panel named "Settings",
which probably has an "Advanced..." button.  If you click the
"Advanced..." button, you should be able to select a panel named
"Performance".  Try turning the Performance down and see if that fixes
the problem.  You might also want to try downloading a newer driver
from the maker of your video card.
</para>
<para>
To see if it's our screen-accessing DLLs, Try renaming the file
"<filename>SDL-dx5.dll</filename>" to "<filename>SDL-dx5.dll.SAVE</filename>".  That will
prevent Executor from seeing that DLL, so Executor will then use a
different DLL (<filename>SDL-dib.dll</filename>) which will cause it to access
the screen in a different way.  If that solves it, then you may have
found a bug in <filename>SDL-dx5.dll</filename>.  If so, please send e-mail to
<email>bugs@ardi.com</email> and let us know.
</para>
        </answer>
      </qandaentry>

    </qandadiv>

    <qandadiv>
    <title>Executor/Linux</title>
      <qandaentry>
        <question>
<para>
I can't get the option key to work under X. What should I do?
</para>
        </question>
        <answer>
<para>
Executor doesn't map raw keys to Mac modifiers, instead it uses the
X "Meta" (mod1) modifier to mean command-key and the X "Mode Switch"
(mod3) modifier to mean option-key.  Many X configurations
automatically set up the left Alt to be Meta and the right Alt to be
mode switch, but not all.
</para>
<para>
If you're using XFree86, check to make sure your XF86Config file
doesn't have the right-alt function definition commented out.  They
are commented out by default in some distributions.
</para>
<para>
If you're not using XFree86, or you don't want to change your
XF86Config file, you can use xmodmap to make your right Alt key be
"Mode Switch" (mod3):
</para>
<para>
xmodmap -e 'remove mod1 = Alt_R' -e 'add mod3 = Alt_R'

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Where are the bitmaps stored on the Linux version of executor?
</para>
        </question>
        <answer>
<para>
All versions of Executor maintain an internal bitmap corresponding to
the actual screen.  We accrue a "dirty rectangle" 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 we won't
go into.
</para>
<para>
"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.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="svgamouse" xreflabel="My mouse won't work with the SVGALIB version.  What's the deal?">
<para>
My mouse won't work with the SVGALIB version.  What's the deal?
</para>
        </question>
        <answer>
<para>
Make sure your mouse works with other SVGAlib programs before you
suspect there's an Executor specific problem.  Make sure your
/etc/vga/libvga.config file contains the proper mouse information and
that /dev/mouse is a symbolic link to the right device.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="linuxb" xreflabel="How do I get E/L to see my second floppy drive?">
<para>
How do I get E/L to see my second floppy drive?
</para>
        </question>
        <answer>
<para>
Before running Executor, set the MacVolumes environment variable to
point to the entry in "/dev" that represents your B: drive, as:
</para>
<para>
Using "sh", "bash" or other Bourne Shell like shell:
</para>
<para>
	<prompt>$ </prompt><command>export MacVolumes="/dev/fd1"</command>
</para>
<para>
Using "csh", "t-csh" or other C Shell like shell:
</para>
<para>
	<prompt>% </prompt><command>setenv MacVolumes "/dev/fd1"</command>
</para>
<para>
This should work as long as you have permission to access the drive in
question ("/dev/fd1" in the above example).  If it doesn't, try using
the -nodrivesearch switch to disable Executor's usual probing for
devices.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why does Lemmings's splash screen take so long to be drawn?
</para>
        </question>
        <answer>
<para>
Executor/Linux tries
to cooperate with X-Windows when assigning colors.  That leaves X in
charge of "the colormap", which means Executor can't quickly change
the colors in the colormap itself.  If you use the "-privatecmap"
option when you start Executor, you'll find that Lemmings splash
screen will come up much quicker, but you'll also experience the
"creepy colors" problem in other windows.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
What free projects has ARDI supported?
</para>
        </question>
        <answer>
<para>
ARDI sent a copy, with the appropriate legal release, of its HFS
implementation to Paul Hargrove to aid him with his implementation of
a true HFS filesystem under Linux.  This saved him considerable time
reverse engineering various undocumented aspects of HFS.
</para>
<para>
To build Executor/DOS, ARDI uses <ulink url="TODO">DJGPP</ulink>, a free 32-bit
programming environment for DOS based mostly on GNU tools.  As users
of <ulink url="TODO">DJGPP</ulink>, we have contributed bug fixes and some source code
to the project.  For more information about <ulink url="TODO">DJGPP</ulink>, see
<ulink url="http://www.delorie.com/djgpp/"></ulink>.
</para>
<para>
ARDI has also done a minor rewrite of Checker to make it much faster
and fix many bugs.  Unfortunately, the modifications were in the hands
of one of ARDI's contractors and appear to have slipped through the
sands of time.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Is Executor localized for languages other than English?
</para>
        </question>
        <answer>
<para>
Not yet.  We recently added international keyboard support, so
romantic language localization is not difficult, per-se, but we're
concentrating on building awareness of Executor in English speaking
countries first.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Can I Macintosh format disk drives?
</para>
        </question>
        <answer>
<para>
Yes, but if you do not consider yourself a UNIX wizard, you probably
shouldn't do it.  All you have to do is find out the formatted disk
capacity and then run makehfv [See <xref linkend="makehfv"/>] with arguments so it
writes directly to the disk drive you want formatted.  You can only do
this if you have write permissions on the drive in question.
Obviously all data currently residing on that drive will be lost, and
if you make a typo and inadvertently specify the wrong drive, you'll
erase the data on the wrong drive.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How can Executor be configured for multiple users?
</para>
        </question>
        <answer>
<para>
Executor has a variety of environment variables that can be altered to
allow individual users to override the default locations Executor
expects to find key files.  Here are the important environment
variables and their default values:
</para>
<simplelist>
<member>ConfigurationFolder "+/Configuration"</member>
<member>SystemFolder "+/ExecutorVolume/System Folder"</member>
<member>PublicDirectoryMap "+/DirectoryMap"</member>
<member>PrivateDirectoryMap "~/.Executor/DirectoryMap"</member>
<member>DefaultFolder "+/ExecutorVolume"</member>
<member>MacVolumes "+/exsystem.hfv;+"</member>
<member>ScreenDumpFolder "/tmp"</member>
</simplelist>
<para>
The leading "+/" represents the directory "/usr/local/lib/executor".
So to allow multiple users to all have their own preferences, you can
create an executor directory for each potential user like this:
</para>
<para>
<literal>
~/executor/
    ~/executor/Configuration
    ~/executor/SystemFolder
    ~/executor/ScreenDumps
</literal>
Then reassign these environment variables:
</para>
<simplelist>
<member>ConfigurationFolder "~/executor/Configuration"</member>
<member>SystemFolder "~/executor/SystemFolder"</member>
<member>PublicDirectoryMap "~/DirectoryMap"</member>
<member>DefaultFolder "~/executor"</member>
<member>ScreenDumpFolder "~/executor/ScreenDumps"</member>
</simplelist>
<para>
You'll then need to populate the System Folder either with copies of
what's in "/usr/local/lib/executor/ExecutorVolume/System Folder", or
with symbolic links to the actual files.  The Desktop Textures program
actually modifies the System File, so if different users are going to
want different desktops, or if you want to make sure there's no
interference between users, then you should use copies rather than
symbolic links.
</para>
        </answer>
      </qandaentry>
    </qandadiv>

    <qandadiv>
      <title>Executor/DOS</title>
      <qandaentry>
        <question id="whatishfv" xreflabel="What is an HFV file?">
<para>
What is an HFV file?
</para>
        </question>
        <answer>
<para>
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 an HFV file.
See <xref linkend="makehfv"/>.
</para>
<para>

In general, HFV files should have filenames that end in "<filename>.hfv</filename>".


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="makehfv" xreflabel="What is makehfv?">
<para>
What is makehfv?
</para>
        </question>
        <answer>
<para>
The program makehfv (formerly called mkvol) allows you to create
virtual Macintosh volumes [see <xref linkend="whatishfv"/>].  It is now part of
all Executor distributions, although it is more useful under DOS than
under Windows or Linux.
</para>
<para>
To use makehfv you need to pick a name for the new HFV file, a name
for the Macintosh volume that your new HFV file will represent and the
number of kilobytes or megabytes that you want the HFV file to use.
Here's an example that creates a file named "<filename>bigtest.hfv</filename>"
that will appear in Executor as "BigTest" and will have 10 MB of space
in it.
</para>
<para>
<command>makehfv bigtest.hfv BigTest 10m</command>
</para>
<para>
Executor/DOS will automatically see HFV files if they are placed in
the same directory as <filename>executor.exe</filename>, which is usually
<filename>C:\EXECUTOR</filename> and their names have the suffix
"<filename>.hfv</filename>".
</para>
<para>
Executor/Linux will automatically see HFV files if they are placed in
the same directory as ExecutorVolume (NOTE: <emphasis></emphasis> in
ExecutorVolume itself), which is usually
<filename>/usr/local/lib/executor</filename> and their names have the suffix
"<filename>.hfv</filename>".
</para>
<para>
If you're using DOS or Windows, if you use a compressed filesystem or
if you plan to make a compressed archive containing an HFV file,
you'll want to use the "<option>-zeros</option>" command line option to makehfv.  That
tells makehfv to explicitly write zeros in the new hfv which takes a
little more time but makes the resulting HFV file much more
compressible.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
What are the hardware requirements for Executor/DOS?
</para>
        </question>
        <answer>
<para>
Required: '386 or better, VGA, 15 MB disk space, and 4 MB RAM.  A SCSI
Controller is needed only if you want to access external Macintosh
hard disks or PowerBooks.
</para>
<para>
Recommended: '486 or better, SVGA, 15 MB disk space, and 8 MB RAM.  A
SCSI Controller is needed only if you want to access external
Macintosh hard disks or PowerBooks.
</para>
<para>
Executor/DOS 2 should work in sixteen colors on any VGA.  In addition,
if you have a Super VGA that is VESA 1.0 compliant, Executor/DOS
should be able to provide 256 colors and a range of screen sizes.  If
you have a video card that is VESA 2.0 compliant, Executor's graphics
will be significantly faster.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="vesa" xreflabel="What do I do if my Super VGA card isn't VESA compliant?">
<para>
What do I do if my Super VGA card isn't VESA compliant?
</para>
        </question>
        <answer>
<para>
There is a shareware SVGA utility that provides VESA compliance for
SVGA cards that normally are not VESA compliant.  <ulink url="TODO">SciTech Display Doctor</ulink> is available from
<ulink url="http://www.scitechsoft.com/"></ulink>.  If you use it, you should pay
the shareware fee as described in the documentation.  If you have a
recent SVGA card you probably don't need SciTech Display Doctor,
although it may improve Executor's performance.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="white" xreflabel="Why is there a bright white border on the screen?">
<para>
Why is there a bright white border on the screen?
</para>
        </question>
        <answer>
<para>
The problem starts with Macs and PCs using different values to
represent white and black.  That's not too big of a problem, because
Executor knows about this difference and translates things
appropriately.  The rest of the problem has to do with the fact that
on video screens (unlike on laptop screens) there is a part of the
screen that is outside the pixel area that is still illuminated by the
video gun.  That portion of the screen is known as the "overscan"
area and the VESA 2.0 specs don't provide a way to set what color the
overscan should be displayed as.  Instead they use the value that is
used for the binary representation that represents black on PCs.  That
works well, except we're already mapping that representation to be
white.
</para>
<para>
This only happens when Executor detects and can use a "linear
framebuffer".  That's the fast way that allows Executor to write
directly to the screen without an intermediate copy to an offscreen
representation of the Mac screen.  If we can't get access to a linear
framebuffer then we can use the normal PC color mapping and patch
things up as we transfer from the offscreen image.  That allows the
overscan area to be black but it's actually slower (significantly
slower for some games).


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="doa" xreflabel="E/D dies during startup.  Why?">
<para>
E/D dies during startup.  Why?
</para>
        </question>
        <answer>
<para>
The most common cause of E/D not running under DOS is the lack of file
descriptors that you might get if you don't have the line:
</para>
<para>
<literal>
FILES=30
</literal>
</para>
<para>
in your config.sys.  If Executor is giving you trouble and you don't
have such a line in your config.sys file, please add it, or if you
have a smaller number than 30, please increase your number to 30.
There is no reason to decrease your number if it is greater than 30.
</para>
<para>
Windows NT doesn't use config.sys, instead you need to use the
configuration file that is listed when you get to the "Program"
portion of "Properties" and click on the WindowsNT button.  The
default Config Filename is
</para>
<para>
<literal>
%SystemRoot%\SYSTEM32\CONFIG.NT
</literal>
</para>
<para>
"%SystemRoot%" will automatically be replaced with the
location of your Windows NT file, which is likely
</para>
<para>
<literal>
C:\WINDOWSNT
</literal>
The default CONFIG.NT file has
"FILES=20" in it, so you need to either change the contents of
CONFIG.NT probably
</para>
<para>
<literal>
C:\WINNT\SYSTEM32\CONFIG.NT
</literal>
or use the WindowsNT button on the Program page of the
Properties panel to use a different configuration file.
</para>
<para>
When all else fails, you can use the command line option "<option>-desperate</option>"
to tell Executor to use as few extended features of your computer as
possible in an attempt to avoid running into a problem.  Under DOS you
just add "-desperate to the command line, i.e.:
</para>
<para>
<prompt>C:\> </prompt><command>executor -desperate</command>
</para>
<para>
Under Windows, you need to make a short-cut to Executor and then use
the Properties menu item to change the command line to include "<option>-desperate</option>".
</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="winwedge" xreflabel="E/D runs under DOS, but not from Windows.  What do I do?">
<para>
E/D runs under DOS, but not from Windows.  What do I do?
</para>
        </question>
        <answer>
<para>
There are several things you can check:
</para>
<simplelist>
<member>Do you have FILES=30 or greater in the appropriate config file [see <xref linkend="doa"/>]?</member>
<member>Are you running in 386-enhanced mode?</member>
<member>Is virtual memory turned on?</member>
<member>Is your mouse driver loaded and enabled (not just installed)?</member>
</simplelist>
<para>
If this checking produces no insights, write to <email>questions@ardi.com</email>
and we'll try to track down the cause of the problem.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
What causes errors when transferring files?
</para>
        </question>
        <answer>
<para>
Error -42 is the error code generated inside a Macintosh when too many
files are open.  Executor internally generates this error when the
underlying operating system disallows the opening of a file.  This
error is usually symptomatic of not properly setting <literal>FILES</literal>
in your config.sys [see <xref linkend="doa"/>].  
</para>
<para>
Similar errors may result when you try to copy Macintosh file to a DOS
disk because many Macintosh file names are illegal under DOS.  You can
fix this by renaming the file to a normal DOS eight-dot-three name.
</para>
<para>
Executor versions that are older than 2.0j [available in mid June]
have trouble with Windows 95's long file names.  Specifically, any
Macintosh file with a control-character as part of its name will cause
trouble, and filenames will appear to all be in lower case.  2.0j
solves these problems.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why does my screen look funny when I run Executor?
</para>
        </question>
        <answer>
<para>
Your video driver may not be fully VESA compliant.  If Executor
detects VESA compliance, it will try to use VESA modes.  In general,
this is a good thing, however, if these modes have bugs in them,
Executor will invoke the bugs, and Executor may fail.  Try getting a
newer driver for your video card if this happens [see <xref linkend="vesa"/>].
</para>
<para>
NOTE: If you run Executor with the "-info" switch, Executor will print
out information it finds out about your video card.  That information
may be helpful in tracking down your problem.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Does E/D require an ASPI driver to access SCSI?
</para>
        </question>
        <answer>
<para>
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.  Similarly, if you have a
16-bit MSCDEX CD-ROM driver installed, Executor will be able to see
your CD-ROM drive (whether it's SCSI or not) even without ASPI
drivers.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why won't Executor/DOS work with my Diamond Viper PCI card?
</para>
        </question>
        <answer>
<para>
Executor/DOS requires VESA compliant graphics cards.  Many cards are
not directly VESA compliant and need a TSR to be run before they will
work with Executor/DOS.  On a Gateway computer, you can do this with
the "<command>vprmode VESA</command>" command [see <xref linkend="vesa"/>].


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why doesn't my mouse work when I run Executor under OS/2 Warp?
</para>
        </question>
        <answer>
<para>
If it's not already there, you may need to add this line:
</para>
<para>
<literal>
DEVICE=C:\OS2\MDOS\VMOUSE.SYS
</literal>
</para>
<para>
to your CONFIG.SYS.  This, and related issues, are described on pages 206-207
of _User's Guide to OS/2 Warp_.  This line should already have been added for
you when you installed Warp.
</para>
<para>
Also, you may need to load MOUSE.COM in your AUTOEXEC.BAT, for
example:
</para>
<para>
<literal>
LOADHIGH C:\OS2\MDOS\MOUSE.COM
</literal>
</para>
<para>
You can also create an AUTOEXEC file specifically for Executor, place it in
the same directory as Executor, and configure Warp to execute that file
whenever you launch Executor.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Any OS/2 Warp suggestions?
</para>
        </question>
        <answer>
<para>
Here is the advice of an Executor Enthusiast:
</para>
<blockquote><attribution>An Executor Enthusiast</attribution>
<para>
I haven't been having any problems with running Executor/DOS in
OS/2. What he needs to do (assuming he has Warp) is to run "Add
Programs" object in the "System Setup" folder. This will make a object
for Executor on his desktop (usually in the "Additional DOS Programs"
folder). Go into the settings for that object, and select the
"Session" tab. Set it to "DOS Full Screen", and choose "DOS
Settings". He wants "All DOS Settings". Primarily, Executor needs the
"DPMI Memory Limit" set to 16 megs, and "DPMI Memory Limit" set to
enabled. Since it defaults to 4 megs and automatic, it won't work. For
additional performance, he should set "DOS High" to on, "EMS Memory
Limit" to 0, "Video 8514a XGA IOtrap" to off, "Video Retrace
Emulation" to off, "XMS Memory Limit" to 0, and "XMS Minimum HMA" to
63. The biggest boost comes from "Session Priority". Set this to at
least 16, and if he is going to run no other programs, set it
higher. If he is going to run other programs, this should be left
at 16, and the "DOS Background Execution" needs to be set to on.
</para>
</blockquote>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Does Executor/DOS work under Windows 95?
</para>
        </question>
        <answer>
<para>
Yes, Executor/DOS works well under Windows 95.  But you should run
Executor/Win32 under Windows 95.  It has fewer compatibility problems
and is just as fast.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question id="dosbugs" xreflabel="Executor/DOS dies, what should I do?">
<para>
Executor/DOS dies, what should I do?
</para>
        </question>
        <answer>
<para>
If Executor dies even running the demo applications, try temporarily
moving your config.sys and autoexec.bat files aside and create minimal
versions of each, leaving only the lines that you need to initialize
your mouse driver and the
</para>
<para>
<literal>
FILES=30
</literal>
</para>
<para>
line in your config.sys.  Then reboot and try running Executor.  If
Executor then starts working, you will have to slowly add back the
things that are in your normal autoexec.bat and config.sys files until
you know exactly what is causing the problem.  Once you know that, you
should send information to <email>bugs@ardi.com</email>.
</para>
<para>
If Executor only dies on a particular application, try increasing the
amount of RAM dedicated to the application by using the "-applzone"
switch when you run Executor.  Also try turning on "Pretend Sound",
or if the screen seems to be only partially
updated, try turning on "Refresh".
</para>
<para>
Once you've done as much as you can to figure out the problem,
<ulink url="TODO">send a bug report</ulink> via <ulink url="http://www.ardi.com/bugform.html"></ulink>}.
Run Executor with the "-info" switch
and include that information.  Make sure you also include the version
of Executor you're running (e.g. Executor/DOS 2), the name and version
of the application that is dying (e.g. HyperCard 2.1), the name and
version of the operating system you're running (e.g. DOS 6.22) and
enough details to reproduce the crash (e.g. "start the application,
choose the "more Elvis" from the "adjust music" menu and the
application will crash").  If the application you are running is
publicly available via anonymous ftp, telling us where we can pick it
up for testing purposes also helps.
</para>
<para>
We accept bug reports from everyone, although paid customers' bug
reports are almost always higher priority than those of potential
customers.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How does printing work under E/D?
</para>
        </question>
        <answer>
<para>
Executor/DOS will print directly to a PostScript-compatible printer if
started with the switch -printer lpt1 (or lpt2, lpt3, or whatever as
appropriate).  Otherwise, it prints to a PostScript file.  The first
time you print, the file will be named <filename>execout1.ps</filename> and will
be located in the same directory that <filename>executor.exe</filename> is
located in. You can then print this file on a PostScript printer, or
if you have a PostScript compatible driver, you can use a
non-PostScript printer.  A popular PostScript compatible printer
drivers is <ulink url="TODO">Ghostscript</ulink>, available for free
(<ulink url="http://www.cs.wisc.edu/~ghost/"></ulink>}).


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why does E/D under Windows 3.x have problems hot-keying?
</para>
        </question>
        <answer>
<para>
When you use a hot-key to switch away from Executor, Windows 3.x
doesn't know how to save the screen, because it only knows about the
original VGA screen modes, but Executor uses SVGA/VESA screen modes.
So when you switch back, Windows 3.x doesn't know how to replace the
screen with what it used to contain.
</para>
<para>
This problem is further compounded by the fact that Executor has no
way of knowing when it's been switched out and switched back.  To make
matters worse, some Windows drivers (ATI Mach 32, for example) don't
even restore the mode properly, so not only will the screen be
incorrect, but Executor will die shortly after you switch back.
</para>
<para>
Luckily this is less frequently a problem in Windows 95 or OS/2.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Why can't I eject or format my DOS formatted floppy?
</para>
        </question>
        <answer>
<para>
Executor/DOS allows you to see DOS drives other than the drive you
install Executor on.  It also allows you to format floppies in the
Macintosh format (it used to read and write Mac formatted floppies,
but it wouldn't do the formatting itself).
</para>
<para>
Currently, the two abilities conflict.  What we do is if a DOS
formatted floppy is in the drive when E/D starts, we treat that drive
as a fixed drive from that point on.  You can no longer eject the
floppy, nor can you convince Executor to consider that floppy as a Mac
formatted floppy or a candidate for Mac formatting.  This is confusing
and ugly; but we haven't found a better solution yet.


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Do E/D and QEMM fight?
</para>
        </question>
        <answer>
<para>
We don't have QEMM in house for testing, but apparently older versions
of QDPMI are incompatible DPMI providers for Executor.  We have heard
that QEMM 8.0 works with Executor, but we have not tested it.  DPMI
providers that are known to work are the supplied CWSDPMI, the DPMI
provider in Windows 3.x and Windows 95, the DPMI provider in OS/2,
and 386Max.
</para>
<para>
For now, if you have lines similar to these two:
</para>
<para>
<literal>
DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=8880 C:\QEMM\QDPMI.SYS 
</literal>
</para>
<para>
<literal>
SWAPFILE=DPMI.SWP SWAPSIZE=1024.
</literal>
</para>
<para>
in your config.sys file, you should "rem them out" -- i.e. add "rem " to the
beginning of each line -- at least when using Executor:
</para>
<para>
<literal>
REM DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=8880 C:\QEMM\QDPMI.SYS 
REM SWAPFILE=DPMI.SWP SWAPSIZE=1024.
</literal>
</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
Does Executor fight with Novell DPMS?
</para>
        </question>
        <answer>
<para>
Yes.  Novell DOS and Stacker both use this memory manager, but
Executor will crash when Novell DPMS (DOS Protected Mode Services) is
running.  Fortunately, Stacker can be run without it if you are using
another memory manager such as 386Max.  Additionally, Stacker won't
use DPMS when run under Windows.
</para>
<para>
This is another compatibility problem that we're looking into,
although it has been reported that some other well known programs
crash under DPMS's DPMI support (PKZIP, Geoworks and Logic Magician's
Oberon System).


</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How can I speed up Executor/DOS?
</para>
        </question>
        <answer>
<para>
Executor/DOS is of course dependent on the speed and type of CPU in
your PC.  Obviously you can make E/D run faster if you upgrade your
386 to a Pentium.  However, there are other, non-obvious ways in which
sometimes you can dramatically improve Executor's speed.
</para>
<para>
Use the "-info" switch to see how much DPMI memory you have compared
to how much physical memory you have.  In general, Executor itself
will consume approximately 2 MB of memory even if you could have an
applzone, syszone and stack size of 0 (which you can't).  So on a 4 MB
system, you can only allocate another 2 MB total to applzone, syszone
and stack if you want to avoid paging (paging slows Executor down
considerably), and that's only if you don't have drivers in your
config.sys file or autoexec.bat tying up more of your memory.  If you
are low on memory, you should use DOS's "<command>mem</command>" command and see how much
Extended (XMS) memory DOS thinks you have.  The more you can increase
that figure before Executor starts up, the more DPMI memory Executor
will have and the easier it will be for Executor to avoid paging.
</para>
<para>
<emphasis></emphasis> you have plenty of memory, then you can also speed
Executor up a little bit by running a disk cache.  However, you should
only run the disk cache in a write-through mode -- in other words you
should enable the disk cache so that all disk writes are immediately
sent to the disk.  Failure to do so may result in corrupt HFV files
after Executor dies.
</para>
<para>
Executor can access video cards in three different ways.  The slowest
is by using VGA calls.  This is also the least flexible -- you are
often limited only to 16 colors when using VGA calls, since the only
VGA mode that supports 256 colors is too small to use with Executor.
If your card is VESA compliant, or has a driver that makes it VESA
compliant, Executor can drive the video card more efficiently.  There
are two major levels of VESA compliance -- VESA 1.x and VESA 2.x.
Executor is even more efficient if it can drive your video card using
a VESA 2.0 driver, <emphasis></emphasis> that driver supports "linear mapping".
The SciTech Display Doctor driver allows many popular video cards to
be linear mapped.  If you want Executor to run quickly, you should
probably pick up a copy of SciTech Display Doctor and test it on your
system to see if it improves things.  You can use "Speedometer" or
"Globe" to get a rough approximation of how much it helps.  On many
cards, use of SciTech Display Doctor can double Executor's graphics speed.

</para>
        </answer>
      </qandaentry>
      <qandaentry>
        <question>
<para>
How do I make Executor/DOS run faster under VirtualPC
</para>
        </question>
        <answer>
<para>
Using the "<option>-oldtimer</option>" switch can speed Executor/DOS up by
more than a factor of two when it's running under VirtualPC, a PC
emulator made by <ulink url="TODO">Connectix</ulink> <ulink url="http://www.connectix.com/"></ulink>}.
</para>
        </answer>
      </qandaentry>
    </qandadiv>
  </qandadiv>
  <qandadiv>
    <title>Carbonless Copies</title>

<para>
This is the list of Frequently Asked Questions about Carbonless
Copies, a tool for deploying Macintosh applications on non-Macintosh
platforms.
</para>

  <qandadiv>
    <title>Carbonless Copies in General</title>

    <qandaentry>
      <question>
<para>
On which platforms can Carbonless Copies applications be deployed?
</para>
      </question>
      <answer>
<para>
It's easy to use Carbonless Copies to reach the Windows Market.
Carbonless Copies applications run under Windows 95, Windows 98 and
Windows NT 4.0 and will run under Windows 2000.
</para> 

<para>
It's also possible to reach the Linux market with Carbonless Copies,
but it's slightly more complicated.  ARDI is well-versed in Linux, but
our initial Carbonless Copies clients have chosen to deploy on
Windows, so that's where we have the most experience deploying
Carbonless Copies based applications.  Internally, we do most of our
development under Linux, so the Linux core is as stable as the Windows
core.
</para> 

<para>
This FAQ is written from the perspective of deploying on Windows, but
Carbonless Copies for Linux generally has equivalent tools.
</para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
How much does Carbonless Copies cost?
</para>
      </question>
      <answer>      
<para>
Carbonless Copies licensing is done by formal contract (as opposed to
shrinkwrap licenses), and until the time the contract is signed,
license fees are technically subject to change.
</para>

<para>
Currently, we license the Carbonless Copies runtime system for one
application for up to 1,000 seats for $5,000.  License fees for
applications which will be deployed on more than 1,000 seats are
negotiated individually.
</para>
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Will Carbonless Copies support my application?
</para>
      </question>
      <answer>
<para>
If your application currently runs under Executor, yes.  If not,
you'll need to talk to someone at ARDI <email>questions@ardi.com</email> to
determine which limitations need to be overcome.  Although Carbonless
Copies is built on the Executor core, it has the ability to run many
applications that Executor can't.  Additionally, we add features to
the Carbonless Copies core for our Carbonless Copies clients.
</para>
      </answer>
    </qandaentry>    

</qandadiv>
<qandadiv>
<title>Carbonless Copies for end-users</title>

    <qandaentry>
      <question>
<para>
How are Carbonless Copies applications installed?
</para>
      </question>
      <answer>
<para>
Currently, the Carbonless Copies license fee includes ARDI building an
InstallShield based installer for each application licensed to use the
Carbonless Copies runtime.  The end result is a single
<literal>".exe"</literal> file that installs the application, all the support
files and an uninstaller.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
How fast do Carbonless Copies applications run?
</para>
      </question>
      <answer>
<para>
Carbonless Copies applications can call natively compiled functions
from arbitrary dynamically linked libraries (DLLs), leaving the
performance in the hands of the programmer.  This requires some
modifications to the Macintosh source-code to make the application
Carbonless Copies aware.
</para>
<para>
Without <emphasis>any</emphasis> modification, Carbonless Copies applications run
at the same speed that they run under Executor, which is very fast for
an emulator, but still slower than a natively compiled application.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
How do Carbonless Copies applications print?
</para>
      </question>
      <answer>
<para>
Under Windows, Carbonless Copies applications print using the standard
Windows print panel to specify the printer.  All the printers
available on a Windows system (e.g. local printers, remote printers,
FAX modems) are available to Carbonless Copies applications.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
How do Carbonless Copies applications cut and paste?
</para>
      </question>
      <answer>
<para>
Currently, Carbonless Copies applications can cut and paste text with
all other applications.  We have also written most of the code to
allow graphics to be exchanged with other applications, but it is not
yet available for deployment.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Where are the Cmd (Clover) and Option keys?
</para>
      </question>
      <answer>
<para>
By default, like Executor, Carbonless Copies applications use the left
"Alt" key as a Cmd key and the right "Alt" key as the Option key, but
it's possible to make Carbonless Copies applications use Windows-style
short-cuts and make both Alt keys behave identically.
</para>
      </answer>
    </qandaentry>

</qandadiv>
<qandadiv>
  <title>Carbonless Copies for programmers</title>

    <qandaentry>
      <question>
<para>
Which OS and toolbox calls are supported?
</para>
      </question>
      <answer>
<para>
Carbonless copies supports much of the Macintosh System 7.0 API, with
these exceptions:
</para>

<simplelist>
<member>monophonic sample sound output only</member>
<member>limited serial port support</member>
<member>limited script manager</member>
<member>limited Alias Manager</member>
<member>limited Apple Events</member>
<member>limited ADB traps</member>
<member>limited icon suite</member>
<member>low-level printing calls (DraftBits, NoDraftBits, GetRotn) not implemented</member>
<member>no networking</member>
<member>no INITs or CDEVs</member>
<member>no non-trivial process manager</member>
<member>no balloon help</member>
<member>no edition manager</member>
</simplelist>
<para>
these traps are not implemented:
</para>
<para>
GetStdFilterProc, SetDialogCancelItem, SetDialogTracksCursor, OutlineMetrics, FlushFonts, PBExchangeFiles, PrJobMerge, AddComp, DelComp, DisposCCursor, NewTempScreenBuffer, CharExtra, SaveFore, RestoreFore, SaveBack, RestoreBack, DisposePictInfo, RecordPictInfo, RecordPixMapInfo, RetrievePictInfo, NewPictInfo, GetPictInfo, WritePartialResource, SetResourceSize, ShutDwnInstall, ShutDwnRemove, SetStylScrap, TECustomHook, TENumStyles, TempTopMem
</para>

<para>
GDeviceChanged, PortChanged, PixPatChanged and CTabChanged are poorly
implemented.  GetCPixel doesn't work for bpp > 8.  OpenCPicture just
calls OpenPicture.  RestoreClutDevice's implementation is shaky.  Our
inverse color table routines don't do a good job of discriminating
between colors that are close to each other.
</para> 

      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Which languages are supported?
</para>
      </question>
      <answer>
<para>
As long as your code can be compiled into an application that runs on
a 68LC040-based Macintosh (like the Quadra 610), the language doesn't
matter.  The Carbonless Copies core includes a dynamic recompiler that
translates 680x0 instructions into 80x86 instructions.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Can I protect my application with a dongle?
</para>
      </question>
      <answer>
<para>
Yes.  You can query the Sentinel Pro dongle by using special Gestalt
calls.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Can my application use custom WDEFs, CDEFs, etc.?
</para>
      </question>
      <answer>
<para>
Yes, although if you choose to use Carbonless Copies' Windows styles,
you'll need to make sure your custom xDEFs also adopt that style.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Can my application patch traps?
</para>
      </question>
      <answer>
<para>
Yes.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Can my application use Apple Events?
</para>
      </question>
      <answer>
<para>
Currently?  No.  In the future, yes.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Can I use custom fonts in my application?
</para>
      </question>
      <answer>
<para>
Yes.  You'll need to make them available both in bitmap form for the
screen and in Type 1 form for printing.
    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Can I use Apple system extensions within my Carbonless Copies app?
</para>
      </question>
      <answer>
<para>
In general, no, but check with us <email>questions@ardi.com</email> if that's
the only thing preventing your application from working with
Carbonless Copies.  There are ways that problem may be worked around.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
How can I use features ARDI hasn't yet implemented?
</para>
      </question>
      <answer>
<para>
It depends on the feature.  Some new features are already in
development, others are awaiting interest from potential customers.
It's also possible to link in and use native DLLs (see <xref
linkend="needspeed"/>), including Apple's QuickTime.
</para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question id="needspeed" xreflabel="How can I make my app run faster?">
<para>
How can I make my app run faster?
</para>
      </question>
      <answer>
<para>
Compute intensive portions of your code can be natively compiled into
dynamically linked libraries and then called from within your
application.  This can be done using gcc, the free C compiler
available from the FSF or by using any tool that produces DLLs
under Windows, including CodeWarrior.  Since Macs store
multi-byte quantities in "big-endian" format and the PC stores them in
"little-endian", you may need to add some byte-swapping to the
functions that you turn into DLLs.  This is tricky the first few times
you do it, but we have a lot of experience with this issue, so we can
do it quickly.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
Since PowerPCs are faster, wouldn't it be faster to emulate the PowerPC?
</para>
      </question>
      <answer>
<para>
No.  Other than byte-swapping concerns (see <xref linkend="needspeed"/>) the
68LC040 instruction set is better suited to be translated into 80x86
instructions than the PowerPC instruction set.  So even though your
program is represented as 68LC040 instructions, the Carbonless Copies
core running on an entry-level PC will run your program much faster
than any 680x0 processor ever released.  When that isn't fast enough,
you can include code compiled into native 80x86 instructions by your
favorite 80x86 compiler.

    </para> 
      </answer>
    </qandaentry>

    <qandaentry>
      <question>
<para>
What are the steps to build a Carbonless Copies application?
</para>
      </question>
      <answer>
<para>
Try to get the application running under Executor.  You may want to
let us know you're interested, so we can discuss licensing fees.  We
can sign a Non-Disclosure Agreement if necessary.  If you have trouble
getting your application(s) running under Executor, we can analyze the
problems and describe remedies.  If there are any technical
difficulties, we can usually iron them out before you need to provide
any licensing fees or execute the Carbonless Copies license agreement.

After the license agreement has been executed, you provide us with a
copy of your software, and a splash screen and we extract the Icons
from it and some customization configuration files that are used to
modify the Carbonless Copies core to reflect your application (splash
screen, serial number assignments, license agreement text).  We then
build an installer that puts all the pieces together, and then you
have something you can test.

We recommend getting a real PC to do your testing, but some people use
Virtual PC instead.  Testing may reveal incompatibilities.  Sometimes
programs that appear to work perfectly on a Macintosh have subtle
defects that cause them to fail under the Carbonless Copies core.  We
have powerful debugging tools that help us diagnose such problems.
Sometimes the fix requires a change to the application, sometimes a
change to the Carbonless Copies core.  Once all the bugs have been
fixed, we build a new installer and testing resumes.  This process is
repeated until the product is ready to ship.
</para>
      </answer>
    </qandaentry>
  </qandadiv>
  </qandadiv>
</qandaset>


</article>

<!-- This comment is for emacs users.  Please leave it at the end of the file.
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:nil
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
sgml-xml-p:t
End:
-->