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)
