# Executor FAQ - Section 3
Executor/Linux

- Q3.1. Can I buy the Linux version now?
- Q3.2. Are we ready to hear about Executor/Linux bugs?
- Q3.3. Should bug reports be sent one at a time or in a big list?
- Q3.4. What kernel do you recommend?
- Q3.5. Why is there no Executor for NetBSD or FreeBSD?
- Q3.6. Where are the bitmaps stored on the Linux version of executor?
- Q3.7. Will there be an SVGALIB version of Executor/Linux in the future?
- Q3.8. Why do other windows get creepy colors when Executor is running?
- Q3.9. How does printing work under Executor/Linux?
- Q3.10. Why does Executor complain that it cannot find 'libXt.so.6'?
- Q3.11. Which FTP sites have E/L?
- Q3.12. Why does Lemmings' splash screen take so long to be drawn?
- Q3.13. What free projects has ARDI supported?
- Q3.14. Is there an ELF flavor of Executor?
- Q3.15. Is Executor localized for languages other than English?
- Q3.16. Can I Macintosh format disk drives?

## Question 3.1. Can I buy the Linux version now?

(Technically, our software is licensed, not 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.2. 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.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

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.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.

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

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