# Executor FAQ - Section 6
Executor/DOS

- Q6.1. What is an HFV file?
- Q6.2. What is makehfv?
- Q6.3. What are the hardware requirements for Executor/DOS?
- Q6.4. What do I do if my Super VGA card isn't VESA compliant?
- Q6.5. Why is there a bright white border on the screen?
- Q6.6. E/D dies during startup. Why?
- Q6.7. E/D runs under DOS, but not from Windows. What do I do?
- Q6.8. What causes errors when transferring files?
- Q6.9. Why does my screen look funny when I run Executor?
- Q6.10. Does E/D require an ASPI driver to access SCSI?
- Q6.11. Why won't Executor/DOS work with my Diamond Viper PCI card?
- Q6.12. Why doesn't my mouse work when I run Executor under OS/2 Warp?
- Q6.13. Any OS/2 Warp suggestions?
- Q6.14. Does Executor/DOS work under Windows 95?
- Q6.15. Executor/DOS dies, what should I do?
- Q6.16. How does printing work under E/D?
- Q6.17. Why does E/D under Windows 3.x have problems hot-keying?
- Q6.18. Why can't I eject or format my DOS formatted floppy?
- Q6.19. Do E/D and QEMM fight?
- Q6.20. Does Executor fight with Novell DPMS?
- Q6.21. How can I speed up Executor/DOS?
- Q6.22. How do I make Executor/DOS run faster under VirtualPC

## Question 6.1. What is an HFV file?

Executor has the ability to store an entire Macintosh "volume" (i.e. filesystem corresponding to a disk drive or a partition within a disk drive) in a DOS or UNIX file. Under DOS, this feature is very handy because there is no way to have files with long names and upper and lower case characters in their names unless you use an HFV file. See Q6.2 `What is makehfv?'.

In general, HFV files should have filenames that end in "`.hfv`".

## Question 6.2. What is makehfv?

The program makehfv (formerly called mkvol) allows you to create virtual Macintosh volumes [see Q6.1 `What is an HFV file?']. It is now part of all Executor distributions, although it is more useful under DOS than under Windows or Linux.

To use makehfv you need to pick a name for the new HFV file, a name for the Macintosh volume that your new HFV file will represent and the number of kilobytes or megabytes that you want the HFV file to use. Here's an example that creates a file named "`bigtest.hfv`" that will appear in Executor as "BigTest" and will have 10 MB of space in it.

    makehfv bigtest.hfv BigTest 10m

Executor/DOS will automatically see HFV files if they are placed in the same directory as `executor.exe`, which is usually `C:\EXECUTOR` and their names have the suffix "`.hfv`".

Executor/Linux will automatically see HFV files if they are placed in the same directory as ExecutorVolume (NOTE: not in ExecutorVolume itself), which is usually `/usr/local/lib/executor` and their names have the suffix "`.hfv`".

If you're using DOS or Windows, if you use a compressed filesystem or if you plan to make a compressed archive containing an HFV file, you'll want to use the "-zeros" command line option to makehfv. That tells makehfv to explicitly write zeros in the new hfv which takes a little more time but makes the resulting HFV file much more compressible.

## Question 6.3. What are the hardware requirements for Executor/DOS?

Required: '386 or better, VGA, 15 MB disk space, and 4 MB RAM. A SCSI Controller is needed only if you want to access external Macintosh hard disks or PowerBooks.

Recommended: '486 or better, SVGA, 15 MB disk space, and 8 MB RAM. A SCSI Controller is needed only if you want to access external Macintosh hard disks or PowerBooks.

Executor/DOS 2 should work in sixteen colors on any VGA. In addition, if you have a Super VGA that is VESA 1.0 compliant, Executor/DOS should be able to provide 256 colors and a range of screen sizes. If you have a video card that is VESA 2.0 compliant, Executor's graphics will be significantly faster.

## Question 6.4. What do I do if my Super VGA card isn't VESA compliant?

There is a shareware SVGA utility that provides VESA compliance for SVGA cards that normally are not VESA compliant. SciTech Display Doctor is available from `<http://www.scitechsoft.com/>`. If you use it, you should pay the shareware fee as described in the documentation. If you have a recent SVGA card you probably don't need SciTech Display Doctor, although it may improve Executor's performance.

## Question 6.5. Why is there a bright white border on the screen?

The problem starts with Macs and PCs using different values to represent white and black. That's not too big of a problem, because Executor knows about this difference and translates things appropriately. The rest of the problem has to do with the fact that on video screens (unlike on laptop screens) there is a part of the screen that is outside the pixel area that is still illuminated by the video gun. That portion of the screen is known as the "overscan" area and the VESA 2.0 specs don't provide a way to set what color the overscan should be displayed as. Instead they use the value that is used for the binary representation that represents black on PCs. That works well, except we're already mapping that representation to be white.

This only happens when Executor detects and can use a "linear framebuffer". That's the fast way that allows Executor to write directly to the screen without an intermediate copy to an offscreen representation of the Mac screen. If we can't get access to a linear framebuffer then we can use the normal PC color mapping and patch things up as we transfer from the offscreen image. That allows the overscan area to be black but it's actually slower (significantly slower for some games).

## Question 6.6. E/D dies during startup. Why?

The most common cause of E/D not running under DOS is the lack of file descriptors that you might get if you don't have the line:

    FILES=30

in your config.sys. If Executor is giving you trouble and you don't have such a line in your config.sys file, please add it, or if you have a smaller number than 30, please increase your number to 30. There is no reason to decrease your number if it is greater than 30.

Windows NT doesn't use config.sys, instead you need to use the configuration file that is listed when you get to the "Program" portion of "Properties" and click on the WindowsNT button. The default Config Filename is

    %SystemRoot%\SYSTEM32\CONFIG.NT

"%SystemRoot%" will automatically be replaced with the location of your Windows NT file, which is likely

    C:\WINDOWSNT

The default CONFIG.NT file has "FILES=20" in it, so you need to either change the contents of CONFIG.NT probably

    C:\WINNT\SYSTEM32\CONFIG.NT

or use the WindowsNT button on the Program page of the Properties panel to use a different configuration file.

When all else fails, you can use the command line option "-desperate" to tell Executor to use as few extended features of your computer as possible in an attempt to avoid running into a problem. Under DOS you just add "-desperate to the command line, i.e.:

    C:\> executor -desperate

Under Windows, you need to make a short-cut to Executor and then use the Properties menu item to change the command line to include "-desperate".

## Question 6.7. E/D runs under DOS, but not from Windows. What do I do?

There are several things you can check:

- Do you have FILES=30 or greater in the appropriate config file [see Q6.6 `E/D dies during startup. Why?']?
- Are you running in 386-enhanced mode?
- Is virtual memory turned on?
- Is your mouse driver loaded and enabled (not just installed)?

If this checking produces no insights, write to `questions@ardi.com` and we'll try to track down the cause of the problem.

## Question 6.8. What causes errors when transferring files?

Error -42 is the error code generated inside a Macintosh when too many files are open. Executor internally generates this error when the underlying operating system disallows the opening of a file. This error is usually symptomatic of not properly setting `FILES` in your config.sys [see Q6.6 `E/D dies during startup. Why?'].

Similar errors may result when you try to copy Macintosh file to a DOS disk because many Macintosh file names are illegal under DOS. You can fix this by renaming the file to a normal DOS eight-dot-three name.

Executor versions that are older than 2.0j [available in mid June] have trouble with Windows 95's long file names. Specifically, any Macintosh file with a control-character as part of its name will cause trouble, and filenames will appear to all be in lower case. 2.0j solves these problems.

## Question 6.9. Why does my screen look funny when I run Executor?

Your video driver may not be fully VESA compliant. If Executor detects VESA compliance, it will try to use VESA modes. In general, this is a good thing, however, if these modes have bugs in them, Executor will invoke the bugs, and Executor may fail. Try getting a newer driver for your video card if this happens [see Q6.4 `What do I do if my Super VGA card isn't VESA compliant?'].

NOTE: If you run Executor with the "-info" switch, Executor will print out information it finds out about your video card. That information may be helpful in tracking down your problem.

## Question 6.10. Does E/D require an ASPI driver to access SCSI?

If your SCSI drivers patch the "INT 13" BIOS calls, then an ASPI driver is not needed. As long as "INT 13" can allow Executor to read a SCSI drive, there is no need to use ASPI. Similarly, if you have a 16-bit MSCDEX CD-ROM driver installed, Executor will be able to see your CD-ROM drive (whether it's SCSI or not) even without ASPI drivers.

## Question 6.11. Why won't Executor/DOS work with my Diamond Viper PCI card?

Executor/DOS requires VESA compliant graphics cards. Many cards are not directly VESA compliant and need a TSR to be run before they will work with Executor/DOS. On a Gateway computer, you can do this with the "vprmode VESA" command [see Q6.4 `What do I do if my Super VGA card isn't VESA compliant?'].

## Question 6.12. Why doesn't my mouse work when I run Executor under OS/2 Warp?

If it's not already there, you may need to add this line:

    DEVICE=C:\OS2\MDOS\VMOUSE.SYS

to your CONFIG.SYS. This, and related issues, are described on pages 206-207 of _User's Guide to OS/2 Warp_. This line should already have been added for you when you installed Warp.

Also, you may need to load MOUSE.COM in your AUTOEXEC.BAT, for example:

    LOADHIGH C:\OS2\MDOS\MOUSE.COM

You can also create an AUTOEXEC file specifically for Executor, place it in the same directory as Executor, and configure Warp to execute that file whenever you launch Executor.

## Question 6.13. Any OS/2 Warp suggestions?

Here is the advice of an Executor Enthusiast:

    I haven't been having any problems with running Executor/DOS in
    OS/2. What he needs to do (assuming he has Warp) is to run "Add
    Programs" object in the "System Setup" folder. This will make a object
    for Executor on his desktop (usually in the "Additional DOS Programs"
    folder). Go into the settings for that object, and select the
    "Session" tab. Set it to "DOS Full Screen", and choose "DOS
    Settings". He wants "All DOS Settings". Primarily, Executor needs the
    "DPMI Memory Limit" set to 16 megs, and "DPMI Memory Limit" set to
    enabled. Since it defaults to 4 megs and automatic, it won't work. For
    additional performance, he should set "DOS High" to on, "EMS Memory
    Limit" to 0, "Video 8514a XGA IOtrap" to off, "Video Retrace
    Emulation" to off, "XMS Memory Limit" to 0, and "XMS Minimum HMA" to
    63. The biggest boost comes from "Session Priority". Set this to at
    least 16, and if he is going to run no other programs, set it
    higher. If he is going to run other programs, this should be left
    at 16, and the "DOS Background Execution" needs to be set to on.

##
Question 6.14. Does Executor/DOS work under Windows 95?

Yes, Executor/DOS works well under Windows 95. But you should run Executor/Win32 under Windows 95. It has fewer compatibility problems and is just as fast.

## Question 6.15. Executor/DOS dies, what should I do?

If Executor dies even running the demo applications, try temporarily moving your config.sys and autoexec.bat files aside and create minimal versions of each, leaving only the lines that you need to initialize your mouse driver and the

    FILES=30

line in your config.sys. Then reboot and try running Executor. If Executor then starts working, you will have to slowly add back the things that are in your normal autoexec.bat and config.sys files until you know exactly what is causing the problem. Once you know that, you should send information to `bugs@ardi.com`.

If Executor only dies on a particular application, try increasing the amount of RAM dedicated to the application by using the "-applzone" switch when you run Executor. Also try turning on "Pretend Sound", or if the screen seems to be only partially updated, try turning on "Refresh".

Once you've done as much as you can to figure out the problem, send a bug report via `<http://www.ardi.com/bugform.html>`. Run Executor with the "-info" switch and include that information. Make sure you also include the version of Executor you're running (e.g. Executor/DOS 2), the name and version of the application that is dying (e.g. HyperCard 2.1), the name and version of the operating system you're running (e.g. DOS 6.22) and enough details to reproduce the crash (e.g. "start the application, choose the "more Elvis" from the "adjust music" menu and the application will crash"). If the application you are running is publicly available via anonymous ftp, telling us where we can pick it up for testing purposes also helps.

We accept bug reports from everyone, although paid customers' bug reports are almost always higher priority than those of potential customers.

## Question 6.16. How does printing work under E/D?

Executor/DOS will print directly to a PostScript-compatible printer if started with the switch -printer lpt1 (or lpt2, lpt3, or whatever as appropriate). Otherwise, it prints to a PostScript file. The first time you print, the file will be named `execout1.ps` and will be located in the same directory that `executor.exe` is located in. You can then print this file on a PostScript printer, or if you have a PostScript compatible driver, you can use a non-PostScript printer. A popular PostScript compatible printer drivers is Ghostscript, available for free (`<http://www.cs.wisc.edu/~ghost/>`).

## Question 6.17. Why does E/D under Windows 3.x have problems hot-keying?

When you use a hot-key to switch away from Executor, Windows 3.x doesn't know how to save the screen, because it only knows about the original VGA screen modes, but Executor uses SVGA/VESA screen modes. So when you switch back, Windows 3.x doesn't know how to replace the screen with what it used to contain.

This problem is further compounded by the fact that Executor has no way of knowing when it's been switched out and switched back. To make matters worse, some Windows drivers (ATI Mach 32, for example) don't even restore the mode properly, so not only will the screen be incorrect, but Executor will die shortly after you switch back.

Luckily this is less frequently a problem in Windows 95 or OS/2.

## Question 6.18. Why can't I eject or format my DOS formatted floppy?

Executor/DOS allows you to see DOS drives other than the drive you install Executor on. It also allows you to format floppies in the Macintosh format (it used to read and write Mac formatted floppies, but it wouldn't do the formatting itself).

Currently, the two abilities conflict. What we do is if a DOS formatted floppy is in the drive when E/D starts, we treat that drive as a fixed drive from that point on. You can no longer eject the floppy, nor can you convince Executor to consider that floppy as a Mac formatted floppy or a candidate for Mac formatting. This is confusing and ugly; but we haven't found a better solution yet.

## Question 6.19. Do E/D and QEMM fight?

We don't have QEMM in house for testing, but apparently older versions of QDPMI are incompatible DPMI providers for Executor. We have heard that QEMM 8.0 works with Executor, but we have not tested it. DPMI providers that are known to work are the supplied CWSDPMI, the DPMI provider in Windows 3.x and Windows 95, the DPMI provider in OS/2, and 386Max.

For now, if you have lines similar to these two:

    DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=8880 C:\QEMM\QDPMI.SYS

    SWAPFILE=DPMI.SWP SWAPSIZE=1024.

in your config.sys file, you should "rem them out" -- i.e. add "rem " to the beginning of each line -- at least when using Executor:

    REM DEVICE=C:\QEMM\LOADHI.SYS /R:1 /SIZE=8880 C:\QEMM\QDPMI.SYS
    REM SWAPFILE=DPMI.SWP SWAPSIZE=1024.

##
Question 6.20. Does Executor fight with Novell DPMS?

Yes. Novell DOS and Stacker both use this memory manager, but Executor will crash when Novell DPMS (DOS Protected Mode Services) is running. Fortunately, Stacker can be run without it if you are using another memory manager such as 386Max. Additionally, Stacker won't use DPMS when run under Windows.

This is another compatibility problem that we're looking into, although it has been reported that some other well known programs crash under DPMS's DPMI support (PKZIP, Geoworks and Logic Magician's Oberon System).

## Question 6.21. How can I speed up Executor/DOS?

Executor/DOS is of course dependent on the speed and type of CPU in your PC. Obviously you can make E/D run faster if you upgrade your 386 to a Pentium. However, there are other, non-obvious ways in which sometimes you can dramatically improve Executor's speed.

Use the "-info" switch to see how much DPMI memory you have compared to how much physical memory you have. In general, Executor itself will consume approximately 2 MB of memory even if you could have an applzone, syszone and stack size of 0 (which you can't). So on a 4 MB system, you can only allocate another 2 MB total to applzone, syszone and stack if you want to avoid paging (paging slows Executor down considerably), and that's only if you don't have drivers in your config.sys file or autoexec.bat tying up more of your memory. If you are low on memory, you should use DOS's "mem" command and see how much Extended (XMS) memory DOS thinks you have. The more you can increase that figure before Executor starts up, the more DPMI memory Executor will have and the easier it will be for Executor to avoid paging.

If you have plenty of memory, then you can also speed Executor up a little bit by running a disk cache. However, you should only run the disk cache in a write-through mode -- in other words you should enable the disk cache so that all disk writes are immediately sent to the disk. Failure to do so may result in corrupt HFV files after Executor dies.

Executor can access video cards in three different ways. The slowest is by using VGA calls. This is also the least flexible -- you are often limited only to 16 colors when using VGA calls, since the only VGA mode that supports 256 colors is too small to use with Executor. If your card is VESA compliant, or has a driver that makes it VESA compliant, Executor can drive the video card more efficiently. There are two major levels of VESA compliance -- VESA 1.x and VESA 2.x. Executor is even more efficient if it can drive your video card using a VESA 2.0 driver, if that driver supports "linear mapping". The SciTech Display Doctor driver allows many popular video cards to be linear mapped. If you want Executor to run quickly, you should probably pick up a copy of SciTech Display Doctor and test it on your system to see if it improves things. You can use "Speedometer" or "Globe" to get a rough approximation of how much it helps. On many cards, use of SciTech Display Doctor can double Executor's graphics speed.

## Question 6.22. How do I make Executor/DOS run faster under VirtualPC

Using the "`-oldtimer`" switch can speed Executor/DOS up by more than a factor of two when it's running under VirtualPC, a PC emulator made by Connectix `<http://www.connectix.com/>`.

Next: Esoterica.
Back: Executor/Linux.
Return to contents.

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