Executor used to be polite when you tried to run it without a mouse.
It would tell you that it required a mouse and then exit. However,
due to a bug in 1.99k (and probably in 1.99j and 1.99i, as well),
Executor is much less polite. If you try to run it without a mouse
driver you'll just get a register dump.
I believe this may be one reason why Executor has run in a DOS box on
some OS/2 systems but not others. If Executor dies upon startup in a
Windows or OS/2 DOS box, you may want to check to see if there is a
mouse driver that you can run, prior to running Executor. The
built-in Windows and built-in OS/2 mouse drivers are *not* used by
Executor, so don't be lulled into a false sense of security.
If you have only 4 MB RAM in your PC, you will probably have to not
run a disk cache (like Smart Drive) when running Executor. Lately
we've been working on Executor/DOS's memory footprint since we once
again have a 4 MB machine that we can test on. The first thing we
noticed was that our disk cache had to go. Most of the other
observations are things that we can do better in future versions of
Executor to squeeze more bytes out of systems with less memory.
As I've mentioned before, I'm about to leave town for ten days, but
everyone else (Vaune, Mat, Cotton and Bill) will still be here, so as
long as your e-mail is sent to one of our aliases and not to me
directly, things should run smoothly in my absence (perhaps *too*
smoothly and they won't take me back).
--Cliff
ctm@ardi.com
From owner-executor Tue Mar 7 17:00:42 1995
Received: (from majordom@localhost) by nacm.com (8.6.9/8.6.9) id RAA00982 for executor-outgoing; Tue, 7 Mar 1995 17:00:42 -0800
Received: from netcom3.netcom.com (netcom3.netcom.com [192.100.81.103]) by nacm.com (8.6.9/8.6.9) with ESMTP id RAA00977 for <executor@nacm.com>; Tue, 7 Mar 1995 17:00:36 -0800
I wonder if ARDI could look into buying/licensing the code for
the Liken Macintosh emulator, and taking the code which let it run
Apple's System files on Executor. If this could be done quick+dirty
enough, it would be a good way to boost compatibility without working too
hard.
Is it me, or is MAE just plain too expensive ($495???). Even if
it DID run on an Intel platform, it would still cost too much, and that
would still leave a wide market for Executor.
In addition, how much work would it take to actually make
Executor run System 7.x. I know trying to run 6.0.7/8 segfaulted at a
certain point, so if the bugs could be tracked down, using GDB or other
debuggers... it MIGHT not take too long to get it up (but then again, it
might take a long time.)
Personally, I consider getting System 7.x to work, and a SVGAlib
Linux version (which would be as fast, or faster than Executor/DOS video,
since it can map a linear frame buffer on VLB cards) the top two items on
my wish list for post-2.0 work.
In addition, would it be possible to make a 'frontend' link-kit
(a executor.a library with all non-frontend code, and the source for the
front-end video sections outside of that library) which would help
facilitate ARDI outsiders such as myself work on things such as SVGAlib
support? I'd be interested into working on that, if possible.
(And now, some thoughts that might be crazy enough to actually
work, or the result of me going nuts!)
Actually, that's nothing compared to an idea I have : place
large parts of Executor under the GPL, or something similar. But, keep
cool stuff such as the enhanced 68040 emulator ARDI-proprietary, and use
the 1.2x synthetic CPU in the GPL version.
Or, if that's too much... GPL 1.2e + compatibility enhancements
taken from the 1.99x versions.
This SOUNDS crazy from a business perspective, but if ARDI could
organize independant development of Executor, and use the code developed
outside ARDI in new versions of Executor, it would ease the effects of
the lack of engineers that ARDI has, and vastly increase development.
This could even possibly increase sales in the long run, since
the color/enhanced CPU version could only be bought from ARDI. Even if
the other parts were redeveloped outside (which would take a long time
given how the WINE project is going), ARDI could still function as a
support business, much like Aladdin runs Commercial Ghostscript and
Cygnus Support handles gcc/gdb/etc..., and ARDI would still have the
general copyright, just like Linus Torvalds 'owns' the copyright on
Linux, and could add other enhancements as time went on.
I must be getting too much into the spirit of Linux... :)
- Chad Page
From owner-executor Tue Mar 7 18:35:27 1995
Received: (from majordom@localhost) by nacm.com (8.6.9/8.6.9) id SAA02440 for executor-outgoing; Tue, 7 Mar 1995 18:35:27 -0800
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by nacm.com (8.6.9/8.6.9) with SMTP id SAA02435 for <executor@nacm.com>; Tue, 7 Mar 1995 18:35:22 -0800
Received: from BILL-THE-CAT.MIT.EDU by MIT.EDU with SMTP
id AA22202; Tue, 7 Mar 95 21:35:21 EST
Received: by bill-the-cat.MIT.EDU (5.0/4.7) id AA13107; Tue, 7 Mar 1995 21:35:19 -0500
Do you think there should be a installer bug category? I'd like to know
if anyone has any problems.
--Jered
From owner-executor Tue Mar 7 22:02:13 1995
Received: (from majordom@localhost) by nacm.com (8.6.9/8.6.9) id WAA05419 for executor-outgoing; Tue, 7 Mar 1995 22:02:13 -0800
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by nacm.com (8.6.9/8.6.9) with SMTP id WAA05414 for <executor@nacm.com>; Tue, 7 Mar 1995 22:02:08 -0800
Received: from BILL-THE-CAT.MIT.EDU by MIT.EDU with SMTP
id AA02703; Wed, 8 Mar 95 01:02:06 EST
Received: by bill-the-cat.MIT.EDU (5.0/4.7) id AA15383; Wed, 8 Mar 1995 01:02:05 -0500
> I wonder if ARDI could look into buying/licensing the code for
>the Liken Macintosh emulator, and taking the code which let it run
>Apple's System files on Executor. If this could be done quick+dirty
>enough, it would be a good way to boost compatibility without working too
>hard.
I'm not familliar with the product, but I wouldn't imagine anything like this
occuring. I seem to remember hearing from Cliff that one of the things that
ARDI was working toward was 'drop in System 7' originally for 2.0, and pushed
to a later version. I'd guess a lot of work has been done, and I remember
reading
that ARDI was talking with Apple over this. Getting a license for part of a
commercial, competing product is not something that would come cheap, I would
bet.
> Is it me, or is MAE just plain too expensive ($495???). Even if
>it DID run on an Intel platform, it would still cost too much, and that
>would still leave a wide market for Executor.
It's expensive. But, until recently, almost all UNIX software was insanely
priced,
most still is. The basic concept is still multi-$1000 site licenses for
software.
This generally hasn't carried over into the home market (except for that OS/2
word processor, DeScribe, which forced you to buy some several $100/year
service
contract from them...for single user use!) and the same seems to be carrying
over to Linux, with more reasonable prices for programs from SimCity, to Maple,
to Executor, and so on.
When you're the only company that makes a genre of program, you can charge
whatever
you darn well please.
> In addition, how much work would it take to actually make
>Executor run System 7.x. I know trying to run 6.0.7/8 segfaulted at a
>certain point, so if the bugs could be tracked down, using GDB or other
>debuggers... it MIGHT not take too long to get it up (but then again, it
>might take a long time.)
I know I saw Cliff mention this at some point. See above comment about 'drop
in Sys7'. Personally, I don't like that, simply because Apple's System is the
most bloated, hideous, twisted program I have ever seen. It's stuck with
special
code for every Mac made, because Apple changed the hardware radically with each
new model! I gave up on Apple after the ][ GS....the last real machine they
made.
As for 6.0.x segfaulting, I would bet this is due to unimplemented features,
or trickery that Apple doesn't document. There's a heck of a lot of that. But,
I'm not a Mac expert.
> Personally, I consider getting System 7.x to work, and a SVGAlib
>Linux version (which would be as fast, or faster than Executor/DOS video,
>since it can map a linear frame buffer on VLB cards) the top two items on
>my wish list for post-2.0 work.
See above comment about Sys7.
I really don't know how beneficial a SVGAlib version of executor would be.
SVGAlib seems to be horribly outdated with hardware support, and nowhere
near as stable as XFree. Under DOS, you can use the VESA BIOS calls, and
standards,
and let the hardware vendor deal with support. With SVGAlib, I can't get
anything to run above 320x200 because I have a video card that's less than a
year old. I'm not that familiar with SVGAlib, but I would guess that it also
adds another layer of indirection.
> In addition, would it be possible to make a 'frontend' link-kit
>(a executor.a library with all non-frontend code, and the source for the
>front-end video sections outside of that library) which would help
>facilitate ARDI outsiders such as myself work on things such as SVGAlib
>support? I'd be interested into working on that, if possible.
Just guessing on this again, but I would bet that the effort required to
abstract
the graphics calls would be almost the same as adapting it to another interface
(i.e. SVGAlib.)
> Actually, that's nothing compared to an idea I have : place
>large parts of Executor under the GPL, or something similar. But, keep
>cool stuff such as the enhanced 68040 emulator ARDI-proprietary, and use
>the 1.2x synthetic CPU in the GPL version.
As a capitalist company, I would guess that it wouldn't be in ARDI's best
interest to do that. Besides, what good would it do?
What would you do with most of the source code to a Mac emulator other than....
use it in your own Mac emulator? The only thing that I could see coming from
ARDI doing something like that would be cheap knockoff's of Executor. And I
certainly wouldn't say the 1.2x synth-CPU isn't cool stuff.
> This SOUNDS crazy from a business perspective, but if ARDI could
>organize independant development of Executor, and use the code developed
>outside ARDI in new versions of Executor, it would ease the effects of
>the lack of engineers that ARDI has, and vastly increase development.
They might get a dozen or so people sifting through the code. But what good
would
it do them if they gave out the code with a license like the GPL? Or any
sort of license. I think this idea misses the whole idea of why SOFTWARE
COMPANIES
exist.
>Even if
>the other parts were redeveloped outside (which would take a long time
>given how the WINE project is going), ARDI could still function as a
>support business, much like Aladdin runs Commercial Ghostscript and
>Cygnus Support handles gcc/gdb/etc..., and ARDI would still have the
>general copyright, just like Linus Torvalds 'owns' the copyright on
>Linux, and could add other enhancements as time went on.
Excuse me, but the Wine project is progressing significantly. A (small)
variety of programs run under linux and netbsd, and using Winelib, some
Windows programs can even be recompiled to run on, say, a Sun.
Mat? Cliff? Anyone want to agree with me, or flame me for being completely
and utterly wrong?
Sorry if this letter sounds too flame-like. It's late. I'm tired. It's really
not meant to sound mean.
--Jered
jered@mit.edu
From owner-executor Wed Mar 8 01:58:24 1995
Received: (from majordom@localhost) by nacm.com (8.6.9/8.6.9) id BAA08854 for executor-outgoing; Wed, 8 Mar 1995 01:58:24 -0800
Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.9/8.6.9) with ESMTP id BAA08849 for <executor@nacm.com>; Wed, 8 Mar 1995 01:58:20 -0800
Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id DAA19470; Wed, 8 Mar 1995 03:00:43 -0700
Received: by mailhost (nextstep Smail3.1.29.0 #11)
