Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.9/8.6.9) with ESMTP id AAA15635 for <executor@nacm.com>; Wed, 9 Nov 1994 00:43:27 -0800
Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id BAA10964 for nacm.com!executor; Wed, 9 Nov 1994 01:44:45 -0700
Received: by iclone (NX5.67d/NX3.0M)
id AA26334; Wed, 9 Nov 94 01:38:33 -0700
Date: Wed, 9 Nov 94 01:38:33 -0700
From: "Clifford T. Matthews" <iclone!ctm@sloth.swcp.com>
Message-Id: <9411090838.AA26334@iclone>
Received: by NeXT.Mailer (1.100)
Received: by NeXT Mailer (1.100)
To: executor@nacm.com
Subject: Thanks for the comments -- here are some answers
Sender: Executor-Owner@nacm.com
Precedence: bulk
Hi Folks,
After getting the Executor/DOS 1.99b demo out I slept, and slept and
slept and slept. Now I'm awake and am about to put together the
commercial E/D 1.99b version out as well as the demo E/Linux 1.99b
and even an Executor/NEXTSTEP 1.99b. However, let me answer a few
questsions now, before my e-mail gets too piled up.
Once the demo fits nicely onto two 1.4 Mb disks I'll make the demo
much more widely available and post many more pointers on various
related newsgroups. Hopefully this will happen before Sunday, since
I leave for a brief (one week) vacation to Chile on Sunday. BTW, if
any Executor users are in Santiago and would like a chance to chat,
let me know ASAP, but be prepared to speak English or Ameslan -- my
Espan~ol is *very* rusty.
Here are a few things that you may not be aware of:
Control-BREAK under Executor/DOS will *usually* break you out
of Executor. There are still a few cases where this
doesn't work and we're trying to find and fix them.
Refresh is used for programs that write directly to the
screen. In this mode, programs write to an offscreen
representation of the screen and then every "n" ticks
(sixtieths of a second) the offscreen representation
is copied to the physical screen.
If you use "-macbpp 1 -realbpp 1" or "-macbpp 8 -realbpp 8"
you don't need to use the refresh option for programs
that write directly to the screen, since Exector will
allow your app to write directly to the screen
without needing a shadow buffer. NOTE: 4 bpp is the
default, and programs can't write directly to the
screen in 4 bpp, because on a PC, 4 bpp is "planar"
instead of "chunky".
Direct Disk Access is only needed for programs that access
the hard disk in a "raw" fashion -- Nortion Utilities
for example. It's best left off for "normal"
applications.
Flush Cache Often is (to the best of our knowledge) only
needed for "Lemmings". Lemmings depends on
side-effects from certain system calls that we can
mimic, but only at a price.
Cache Heuristics isn't needed at all -- it was put there in
anticipation of some hacks that I thought we'd need
to implement to get HyperCard to be speedy, but the
mods were sufficiently unobtrusive that we just
run with them on all the time.
Here are a few bugs that were noted in 1.99a that have already been
fixed in 1.99b:
Alt-shift-1 saying 1.30
Stuffit not working
Microsoft Word not working
Here are problems we're still working on:
Alternate screen sizes: Executor/X-Windows/Linux and
Executor/NEXTSTEP both should trivially be able to
support alternative screen sizes, although currently
they can't. In addition, most VESA compliant SVGA
cards should also be able to support higher
resolutions than the 640x480 that we currently
implement. These fixes will come in two stages:
the ability to switch when Executor is first
started should be working fairly soon. The ability
to dynamically switch may not happen until after
2.0 is released.
Crystal Quest demo dies after completing a level if run with
bpp > 1. We're looking into this one. Strangely,
there are other versions of CQ that do not show this
behaviour.
NIH Image 1.55 says complains about creating NewGDevice:
We've made some progress on NIH image, but it even
in 1.99b it trys to use a system call that we don't
yet support. NIH Image is a power-user of 32-bit
Quickdraw, so it's taking us some time to get it
going, but we don't see anything insurmountable
(yet).
Having the HFS_XFer window come to the forefront anytime the
HFS_XFer menu item is chosen (under the Apple menu):
Good idea -- I'll try to put that code in soon.
Spectre 1.0 runs, but the colors are wrong: we know why, but
haven't put in the code to fix it yet.
Other incorrect colors: Some programs still produce grossly
incorrect colors. These errors need to be fixed
ASAP.
A refresh-screen FKEY (Control-alt-digit): We hadn't thought
of this, but Kurt Glaesemann suggested this and many
other useful things. This one is simple enough that
we should be able to slip it into an upcoming
release.
The ability for Executor to switch screen depths through
software. We know how to implement this, but haven't
gotten around to it yet. This one's fairly low
priority, but will probably be done before we release
2.0.
When not in 8 bits per pixel mode, some screen accesses are
not properly done. This is why the Eject button
looks weird in 1 bpp and why the speedo gauages don't
appear in 1 bpp or 4 bpp.
1000 miles weirdness: Thanks to Jacques Pannetier's
observations and some new debugging tools, I suspect
this bug will be fixed "soon" (within a month),
although it's fairly low priority.
Grow zone problems: Yes, as Kurt has pointed out, many
Claris programs draw grow zone lines inappropriately.
Since this doesn't actually cause programs to crash,
we haven't been particularly aggressive in fixing
this bug, but it is sufficiently annoying that I'll
try to get someone to look at it within the next
couple of weeks.
Here are some suggestions that are quite good, but are lower priority
than the items mentioned above:
Other incorrect colors: Some color differences are really
reflections of the differences in monitors. The Mac
has built-in support for "Gamma correction" to
address this issue. Although this is an important
issue, it's not as important as getting more apps to
be usable, so it has to wait until 2.0 is out before
we can do anything about it. Even then, it's a very
tough issue to address without some help from the
hardware manufacturers.
Scrapbook DA: I'll try to find an existing one and get it to
work (send suggestions to ctm@ardi.com), but if I
can't find one, the person to write one will probably
be Bill Goldman, and he's busy writing our Finder
replacement.
Keycaps DA: same comment as Scrapbook, although Keycaps is
lower priority.
Browse option in file dialog boxes: we need to get more
applications running before we can add this
functionality. Sorry.
Built in support for binhex when moving files from the Mac
side to the DOS side: This is a good idea, although
another possibility is to support Apple Single.
Again, this solution takes a backseat to getting 2.0
out (i.e. more applications running), but it's a
high priority.
A cool OS/2 and Windows Icon: We need these things and we
also need decent icons for our soon to be released
file browser. Our file browser has such PITIFUL
icons (no offense, Bill) that we're hopeint to
inspire some student effort to help us clean up.
We have a nice Executor/NEXTSTEP icon that we may be
able to modify for E/DOS, but we're waiting to see
what gets thrown at us for free after E/D 1.99x is
more widely available.
System 7 compatibility: One of the functions of 2.0 that
we've had to back off on (others include sound and
Windows interoperability) is System 7 support. We
know what system 7 functions we'd like to add, but
after our most recent trip to Apple, it may make
sense for us to make it so that Executor will allow
you to add System 7 and automatically get a much
greater degree of compatibility than Executor without
System 7 from Apple. That may make work on System 7
now be redundant. We're still researching this
issue.
The ability to easily modify file type and file creator:
Once we've released our file browser, that is a
logical addition. Since we'll be releasing the
source to our file browser, we expect a few mods
to be made by Executor enthusiasts who just like
to help out. After it's been out and all bugs
cleaned up, we'll prioritize a list of mods and
start making them. This timetable is independent
of the release of 2.0, so this feature could be
ready before 2.0 ships.
HFS_XFer bugs: Some of these have already been fixed, but
we won't be releasing anything new until our file
browser comes out.
BTW, if you've gotten this far, and are not a registered user, you
obviously care enough about our product to be worthwhile to talk to.
Although our official policy is not to provide tech. support to non
registered users, we'll gladly accept bug reports from anyone, the
