bugs@ardi.com
and make sure that you identify what version of Executor you're running (i.e. Executor/Linux 1.99k) 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.
Executor/Linux is bundled with a "send-pr" package that allows you to submit bug reports directly into our "gnats" bug tracking database. We prefer that you use this tool, although it's not necessary. See Q3.4 `Should bug reports be sent one at a time or in a big list?' for more information.
If you don't use send-pr, read Q2.15 `Executor dies, what should I do?' for more information about sending bug reports. Luckily, you won't have to fiddle with your
config.sys and autoexec.bat files.
Question 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.
In fact, if you're particularly brave, you can pick up the file
"send-pr.tar.gz" and install a program "send-pr"
which will allow you to send us bug reports pre-formatted for gnats. This will save us time and
also give you a bug tracking number that you can refer to in further e-mail to
ARDI about the bug.
Question 3.5. What kernel do you recommend?
We do not know of any problems with kernels 1.2.0 and greater.
1.1.72, and presumably older kernels didn't allow Executor to get SIGIO messages
when X-events arrived, so kernels with that problem result in Executor that
doesn't necessarily see events as quickly as we would like. In fact, with
1.99m, kernel 1.1.72 would result in Executor hanging. We believe this is
fixed in 1.99n, but we haven't taken the time to test it under kernel 1.1.72
and that particular bug never reared its head locally.
Question 3.6. Why is there no Executor for NetBSD or
FreeBSD?
We don't currently have the manpower to support it. NOTE:
"support" is different from "port" -- porting it is easy. Training tech.
support and buying more dedicated equipment is what we can't do quite yet. The
Linux release is a byproduct of the fact that we use Linux in-house. After
we've released Executor 2.0, we'll look into the feasibility of Executor for
NetBSD and FreeBSD.
Question 3.7. 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 we 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.
Question 3.8. Will there be an SVGALIB version of Executor/Linux in
the future?
This version was recently completed and is now available at the usual
sites.
Question 3.9. Why do other windows get creepy colors when Executor is
running?
This is no longer true for recent versions of Executor.
Executor/Linux can run in two modes on 4 or 8-bit X servers.
"private colormap" mode: In this mode, Executor "takes over" all colors on your screen when the cursor is in the Executor window. That means that the colors for all your other windows will suddenly change radically. This is the fastest mode, and provides the most accurate colors, but it can be a real eyesore. Still, if you're playing Wolfenstein 3D or some other interactive game, you may want to maximize performance by using this mode. You can enable this mode with "-privatecmap". NOTE: some X Window managers have problems and "-privatecmap" winds up doing the wrong thing unless you also specify "-geometry". We do not think this is an Executor bug, but if anyone has information to the contrary, we'd be happy to read it.
"non-private colormap" mode: In this mode (the default), Executor coexists nicely with other X windows by not mucking about with the colors they use. This mode loses some accuracy and speed, because Executor cannot set the entire color table to exactly what it wants and it must convert its internal graphics representation to one appropriate for the X screen whenever it updates your display. We have carefully optimized this conversion process, so you won't notice the performance penalty most of the time.
The "-privatecmap" flag is irrelevant to 16, 24, and 32-bit
X servers, since they don't have a color table.
Question 3.10. How does printing work under
Executor/Linux?
Executor expects to print to a PostScript printer, or to send output
to a PostScript compatible filter, like GhostScript. When an application
prints under Executor, a PostScript stream will be created and sent through
the program "executor_filter" which you can create by hand to
"do the right thing", or "lpr" if there is no
"executor_filter" for Executor to run.
On our systems, "lpr" automatically does the right thing, so other than occasionally setting our "PRINTER" environment variable, we don't have to do much to print from Executor.
If you need to write your own filter, you can test it by typing:
myfilter < myfile.ps
CAVEAT #1: The PostScript that is currently produced relies on some "Encoding" changes that appear not to work with GhostScript. As such, certain characters are improperly mapped. Word output for example can not print apostrophes! Yes, we know this is very bad and are looking for a remedy.
CAVEAT #2: Different apps running under Executor have different levels
of success when printing. As always, especially with the experimental versions, try first to make sure Executor will do what you want it to.
Question 3.11. Why does Executor complain that it cannot find
'libXt.so.6'?
If Executor complains as soon as you start it up, you are either
running an old version of Executor (prior to 1.99e, at least) or you are running
XFree86 2.x instead of XFree86 3.x. Currently we do not have the time to
create two separate versions of E/L, so use the "current" XFree86
server/libraries.
It has been reported that you can install the XFree86 3.x shared libraries and still use an XFree86 2.x server. We have not verified such trickery here at ARDI -- you're on your own.
When E/L 2.0 is released, we'll reevaluate our "3.x" only
policy and if there are a significant number of XFree86 2.x users that would like to run
E/L, we'll consider offering a version that links with the XFree86 2.x
libraries.
Question 3.12. How do I get E/L to see my b:
drive?
Try setting the MacVolumes environment variable to point to your B:
drive before running Executor, as:
% export MacVolumes="/dev/fd1"
This should work as long as you have permission to use your drive
device when you are you (and not root).
Question 3.13. Which FTP sites have E/L?
Other than ftp.ardi.com:/pub/Executor_
Linux (too slow) and and the usual mirrors, you can find Executor/Linux on
sunsite.unc.edu
in /pub/Linux/system/Emulators/executorlinux199
?.tar.gz.
See also Q1.20 `Where can I pick up the Executor demos?'
Question 3.14. Why does Lemmings' splash screen take so long to be
drawn?
As mentioned in Q3.9 `Why do other windows get creepy colors when Executor is
running?' Executor/Linux by default now 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.
Question 3.15. What free projects has ARDI
supported?
ARDI has 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. When we have more time, if Paul hasn't
finished and would like it, we'll be even more active in helping get a free
implementation of HFS that can be used with Linux, FreeBSD, NetBSD and
GNU.
ARDI has also done a minor rewrite of checker to make it much faster and fix many bugs. This rewrite should be available soon.
ARDI is not in the black, so allocating a portion of its profits
(losses) towards free software is not yet a good idea.
Question 3.16. Is there an ELF flavor of
Executor?
Yes; it was recently completed and is now available.
Question 3.17. Is Executor localized for languages other than
English?
Not yet. We recently added international keyboard support, though,
and romantic language localization should happen soon after 2.0 is
released.
Question 3.18. Can I Macintosh format disk
drives?
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 Q1.47 `What is 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.
Question 3.19. Why is the cursor inverted?
Starting with 1.99o, you should not ever see an inverted cursor. We
believe this is a bug in some X-servers. We found a workaround and installed
it in 1.99o. However, if you still see this problem, you can explicitly
tell Executor to invert the cursor with the "-invertedcursorbug"
command line option.
Question 3.20. How can Executor be configured for multiple
users?
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:
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:
~/executor/ ~/executor/Configuration ~/executor/SystemFolder ~/executor/ScreenDumps
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.
- 23 September 1995