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.3 `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.14 `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.3. 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.4. What kernel do you recommend?
We do not know of any problems with kernles 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.5. 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.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 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.7. Will there be an SVGALIB version of Executor/Linux in
the future?
Yes. Most of the work has already been done.
Question 3.8. 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.9. 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.10. 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.11. Which FTP sites have E/L?
Other than ftp.ardi.com:/pub/Executor_
Linux (too slow) and ftp.cs.unm.edu:/pub/ardi/Executor_
Linux, you can also find Executor/Linux on sunsite.unc.edu
in /pub/Linux/system/Emulators/executorlinux199
?.tar.gz.
See also Q1.19 `Where can I pick up the Executor demos?'
Question 3.12. Why does Lemmings' splash screen take so long to be
drawn?
As mentioned in Q3.8 `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.13. 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.14. Is there an ELF flavor of
Executor?
Not yet, but we're keeping an eye on ELF with the intent to switch
over.
Question 3.15. Is Executor localized for languages other than
English?
Not yet. In fact, we don't yet have international keyboard support,
so using Executor outside the U.S. can be troublesome. We fully
intend to support foreign keyboards by the time 2.0 is released.
Romantic language localization should happen soon after 2.0 is
released, but support for multi-byte characters is still at least six
months away.
Question 3.16. 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.46 `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.
- 04 July 1995