Executor FAQ - Section 3
Executor/Linux


Question 3.1. Why can't I see files in my Appleshare volumes?

If you have an AppleSharePC card in your computer, Executor will show you the volume, but will not show you the files within the volume. This is a bug that is known to be in 1.99n. We should have this bug fixed by the time 2.0 ships.

Question 3.2. Can I buy the Linux version now?

Technically, our software is licensed rather than sold. You can now license Executor/Linux and be provided with a serial number and license key from ARDI and "unlock" the experimental Executor 1.99<x> releases as well as Executor/Linux 2.0.*. However, currently there is no printed manual available for Executor/Linux.

Question 3.3. Are we ready to hear about Executor/Linux bugs?

Yes. Send them to bugs@ardi.com and make sure that you identify what version of Executor you're running (i.e. Executor/Linux 1.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

where "myfile.ps" is some PostScript file you have lying around. The "<" is VERY important! Executor does NOT give your filter any command line arguments; it just "pipes" the PostScript file through it.

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

Then reassign these environment variables:

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.


Next: Executor/NEXTSTEP.
Back: Executor/DOS.
Return to contents.

- 23 September 1995

Extracted from Executor Frequently Asked Questions with Answers, Copyright ARDI 1995.