[Prev][Next][Index][Thread]

Thanks for the comments -- here are some answers



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  
more informed, the better.

	--Cliff