ftp.ardi.com
in /pub/Executor_
DOS. However, when you log on to ftp.ardi.com
, a list of mirrors will be provided and the
mirrors are usually much faster than ftp.ardi.com
. However, once we're happy with the stability of an Executor/DOS release, we put
a copy on the SimTel mirrors.
The primary SimTel mirror is oak.oakland.edu, and you can find the Executor/DOS demo within the "SimTel/msdos/emulator" directory. Look for exec199?.zip (where ? is a letter, the further into the alphabet the letter, the more recent the experimental release). Other SimTel mirrors are:
wuarchive.wustl.edu
(128.252.135.4) : /systems/ibmpc/msdos
(St. Louis, MO) archive.orst.edu
(128.193.2.13) : /pub/mirrors/simtel/msdos
(Corvallis, OR) archie.au
(139.130.4.6) : /micros/pc/oak
(Australia) src.doc.ic.ac.uk
(146.169.2.10) : /pub/packages/simtel
(England) ftp.funet.fi
(128.214.248.6) : /pub/msdos/SimTel
(Finland) ftp.ibp.fr
(132.227.60.2) : /pub/msdos
(France) ftp.uni-paderborn.de
(131.234.2.32) : /SimTel/msdos
(Germany) ftp.cs.cuhk.hk
(137.189.4.57) : /pub/simtel/msdos
(Hong Kong) ftp.technion.ac.il
(132.68.1.10) : /pub/unsupported/dos/simtel
(Israel) ftp.cyf-kr.edu.pl
(149.156.1.8) : /pub/mirror/msdos
(Poland) ftp.sunet.se
(130.238.127.3) : /pub/pc/mirror/SimTel/msdos
(Sweden) ftp.switch.ch
(130.59.1.40) : /mirror/msdos
(Switzerland) NCTUCCCA.edu.tw
(140.111.1.10) : /PC/simtel
(Taiwan) ftp.nectec.or.th
(192.150.251.32) : /pub/mirrors/msdos
(Thailand)
See also Q1.20 `Where can I pick up the Executor demos?'
Question 2.2. What are the hardware requirements for
Executor/DOS?
For Executor/DOS 1.2 you need a '386 or better, VGA, 7 MB disk
space, a 3.5" 1.44 MB floppy drive, and 4 MB RAM. A SCSI
Controller is needed only if you want to access external
Macintosh hard disks or PowerBooks.
Executor/DOS 1.99<x> should work in sixteen colors on any VGA,
although we do not have the facilities to test more than a few in
house. 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. Beginning with E/D 1.99n, if you have a video
card that is VESA 2.0 compliant, Executor's graphics will be even
faster.
Question 2.3. 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. At the time
this FAQ was last modified, univbe51.zip was the most recent
release of this extender.
It is not a product of ARDI, but as a convenience to people picking up
experimental versions of Executor, the file univbe51.zip is available
on /ftpon ftp.ardi.com in /ftpin /pub/ardi/Executor_DOS. If you use
it, you should pay the shareware fee as described in the documentation
included in the zip file. If you have a recent SVGA card you probably
don't need univbe. There may be a more recent version of univbe on
/ftpon oak.oakland.edu in /ftpin /SimTel/msdos/graphics. This
directory also has several other card specific VESA drivers, some of
which can be found in vesa-tsr.zip and vesadrv2.zip.
Question 2.4. 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
FILES
in your config.sys [see Q2.4 `E/D dies during startup. Why?'].
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 2.7. What's "GrSetMode ; unknown adapter type in
driver." mean?
You must be running an old version of Executor; this error cannot occur in versions >= 1.99h.
1.99b had problems when Microsoft's display.sys driver is in
config.sys. We have updated the code that had this problem
and hope that the problem is now fixed. If it is not, you
must remove display.sys from the config.sys section you use
when you're using Executor/DOS. Please report this bug if you
see it in E/D 1.99e or later.
Question 2.8. 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.
Question 2.9. Have you released Executor for OS/2
yet?
We plan on making an OS/2 specific version of Executor, but only
after we get Executor 2.0 shipping. However, Executor 1.99l
is reported to work well under OS/2 Warp.
Question 2.10. 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 Q2.3 `What do I do if my Super VGA card isn't VESA
compliant?'].
Question 2.11. 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
Also, you may need to load MOUSE.COM in your AUTOEXEC.BAT, for example:
LOADHIGH C:\OS2\MDOS\MOUSE.COM
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 Backround Execution" needs to be set to on.
Under Windows '95, there is a different way to access CD-ROMs -- a way that Executor doesn't use. However, Windows '95 can also use mscdex. To do so, you need to find and remove the:
rem - By Windows 95 Setup
FILES=30
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" [see Q1.38 `Are there other parameters I can adjust? [aka "Preferences Panel"]'], 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 to bugs@ardi.com
. 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 1.99n), 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 runing (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 applicaton 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 2.16. Should I have sent in my registration
card?
Yes. We use that card to assign your serial number and authorization
key so you can continue to download and unlock experimental versions
of Executor. In general, we do not assign such numbers when you first
purchase Executor because we do not know if you're purchasing Executor
as a gift for someone else, or if it's being purchased through a
company purchasing department, or what. We want to make sure that we
have the address of the eventual owner of Executor and the surest way
to avoid mistakes is to send in that card.
Question 2.17. How does printing work under
E/D?
Executor/DOS 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.
Two popular PostScript compatible printer drivers are
"GhostScript", available for free, and "ZScript", a commercial program from
ZenoGraphics.
Question 2.18. 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 not a problem in Windows '95 or OS/2.
Question 2.19. Why can't I eject or format my DOS formatted
floppy?
1.99n is the first version of E/D to allow you to see DOS drives other
than the drive you install Executor on. It's also the first version
to allow 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; we hope to change it in 1.99o.
Question 2.20. Why the white border on the
screen?
There is not yet any standard way for an application to set a video
board's "overscan" (i.e. border) color. Some video boards
set the overscan color in a way that interferes with Executor's ability to
write directly to the screen. This is because internally Macs and PCs
use different bit values to represent white and black. We hope to fix
this problem at least for most popular video boards by the time 2.0
ships.
Question 2.21. Do E/D and QEMM fight?
We don't have QEMM in house for testing, but apparently QDPMI is an
incompatible DPMI provider for Executor, starting with Executor 1.99n.
DPMI providers that are known to work are the supplied CWSDPMI, the
DPMI provider in Windows 3.x and Windows '95 and the DPMI provider in
OS/2. We are investigating the incompatibilities between Executor and
QDPMI.
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.
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 UniVBE 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 UniVBE and test it on your system to see if it improves things. You can use "Speedometer" or "Globes" to get a rough approximation of how much it helps. On many cards, use of UniVBE can double Executor's graphics speed.
- 17 July 1995