# Executor FAQ - Section 5
Executor/Linux

- Q5.1. I can't get the option key to work under X. What should I do?
- Q5.2. Where are the bitmaps stored on the Linux version of executor?
- Q5.3. My mouse won't work with the SVGALIB version. What's the deal?
- Q5.4. How do I get E/L to see my second floppy drive?
- Q5.5. Why does Lemmings's splash screen take so long to be drawn?
- Q5.6. What free projects has ARDI supported?
- Q5.7. Is Executor localized for languages other than English?
- Q5.8. Can I Macintosh format disk drives?
- Q5.9. How can Executor be configured for multiple users?

## Question 5.1. I can't get the option key to work under X. What should I do?

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.

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.

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):

xmodmap -e 'remove mod1 = Alt_R' -e 'add mod3 = Alt_R'

## Question 5.2. 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 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.

"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 5.3. My mouse won't work with the SVGALIB version. What's the deal?

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.

## Question 5.4. How do I get E/L to see my second floppy drive?

Before running Executor, set the MacVolumes environment variable to point to the entry in "/dev" that represents your B: drive, as:

Using "sh", "bash" or other Bourne Shell like shell:

    	$ export MacVolumes="/dev/fd1"

Using "csh", "t-csh" or other C Shell like shell:

    	% setenv MacVolumes "/dev/fd1"

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.

## Question 5.5. Why does Lemmings's splash screen take so long to be drawn?

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.

## Question 5.6. What free projects has ARDI supported?

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.

To build Executor/DOS, ARDI uses DJGPP, a free 32-bit programming environment for DOS based mostly on GNU tools. As users of DJGPP, we have contributed bug fixes and some source code to the project. For more information about DJGPP, see `<http://www.delorie.com/djgpp/>`.

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.

## Question 5.7. Is Executor localized for languages other than English?

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.

## Question 5.8. 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 Q6.2 `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 5.9. 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:

- ConfigurationFolder "+/Configuration"
- SystemFolder "+/ExecutorVolume/System Folder"
- PublicDirectoryMap "+/DirectoryMap"
- PrivateDirectoryMap "~/.Executor/DirectoryMap"
- DefaultFolder "+/ExecutorVolume"
- MacVolumes "+/exsystem.hfv;+"
- ScreenDumpFolder "/tmp"

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:

- ConfigurationFolder "~/executor/Configuration"
- SystemFolder "~/executor/SystemFolder"
- PublicDirectoryMap "~/DirectoryMap"
- DefaultFolder "~/executor"
- ScreenDumpFolder "~/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.

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

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