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

Re: Liken, MAE, and a crazy thought...



>>>>> "Chad" == pageone  <pageone@netcom.com> writes:

    Chad> 	I wonder if ARDI could look into buying/licensing the
    Chad> code for the Liken Macintosh emulator, and taking the code
    Chad> which let it run Apple's System files on Executor.  If this
    Chad> could be done quick+dirty enough, it would be a good way to
    Chad> boost compatibility without working too hard.

Such code is actually easy to write.  In addition to Liken, there have
been a wide variety of Macintosh emulators for the Amiga that do the
same thing.  True, Liken had a synthetic CPU, but our synthetic CPU is
already written.

The reason we don't have similar code is that all the ARDI engineers
are "clean".  That means that we have never disassembled any Apple ROM
or System file code and that we haven't been given any pointers by
anyone who has.  The Liken code is "dirty".  They could do that
because they required their end-users to procure code from Apple;
something we do not want to do at the time.

*When* (not "if") we add similar functionality we'll do it by using
"dirty" engineers who do not talk to our "clean" engineers.  Buying
code from the Liken folk just won't speed things up; we'll need
"dirty" engineers and a strict clean-room / dirty-room infrastructure
and neither comes cheap.

    Chad> 	Is it me, or is MAE just plain too expensive
    Chad> ($495???).  Even if it DID run on an Intel platform, it
    Chad> would still cost too much, and that would still leave a wide
    Chad> market for Executor.

I don't think you'll see MAE coming out for Intel processors anytime soon.

    Chad> 	In addition, how much work would it take to actually
    Chad> make Executor run System 7.x.  I know trying to run 6.0.7/8
    Chad> segfaulted at a certain point, so if the bugs could be
    Chad> tracked down, using GDB or other debuggers... it MIGHT not
    Chad> take too long to get it up (but then again, it might take a
    Chad> long time.)

It would be a lot of work, but we've already stated that after 2.0
comes out, it's a primary goal.

    Chad> 	Personally, I consider getting System 7.x to work, and
    Chad> a SVGAlib Linux version (which would be as fast, or faster
    Chad> than Executor/DOS video, since it can map a linear frame
    Chad> buffer on VLB cards) the top two items on my wish list for
    Chad> post-2.0 work.

An SVGALib version is only useful to Linux users, so the priority for
doing an SVGAlib backend is directly proportional to the number of
sales of Executor/Linux we think we can get, which will be estimated
based on the number of non-SVGAlib copies of Executor/Linux we sell.

    Chad> 	In addition, would it be possible to make a 'frontend'
    Chad> link-kit (a executor.a library with all non-frontend code,
    Chad> and the source for the front-end video sections outside of
    Chad> that library) which would help facilitate ARDI outsiders
    Chad> such as myself work on things such as SVGAlib support?  I'd
    Chad> be interested into working on that, if possible.

It may be possible, although it's pretty unlikely.

    Chad> 	(And now, some thoughts that might be crazy enough to
    Chad> actually work, or the result of me going nuts!)

    Chad> 	Actually, that's nothing compared to an idea I have :
    Chad> place large parts of Executor under the GPL, or something
    Chad> similar.  But, keep cool stuff such as the enhanced 68040
    Chad> emulator ARDI-proprietary, and use the 1.2x synthetic CPU in
    Chad> the GPL version.

Unlikely.  However, we are working with the person that is doing the
HFS support for Linux.  We've already sent him our source and sometime
in the future we may try to merge his and our source, the resultant
code would of course be GPL'd.

    Chad> 	Or, if that's too much... GPL 1.2e + compatibility
    Chad> enhancements taken from the 1.99x versions.

    Chad> 	This SOUNDS crazy from a business perspective, but if
    Chad> ARDI could organize independant development of Executor, and
    Chad> use the code developed outside ARDI in new versions of
    Chad> Executor, it would ease the effects of the lack of engineers
    Chad> that ARDI has, and vastly increase development.

I think you're underestimating the potential revenue stream of
Executor 2.0 when it's ready.  We are doing extremely well with just a
few engineers.  If we could double our engineers and off-load
non-development work to real system administrators and the business
and marketing end to real business and marketing people we'd get
things done *much* faster.

    Chad> 	This could even possibly increase sales in the long
    Chad> run, since the color/enhanced CPU version could only be
    Chad> bought from ARDI.  Even if the other parts were redeveloped
    Chad> outside (which would take a long time given how the WINE
    Chad> project is going), ARDI could still function as a support
    Chad> business, much like Aladdin runs Commercial Ghostscript and
    Chad> Cygnus Support handles gcc/gdb/etc..., and ARDI would still
    Chad> have the general copyright, just like Linus Torvalds 'owns'
    Chad> the copyright on Linux, and could add other enhancements as
    Chad> time went on.

    Chad> 	I must be getting too much into the spirit of
    Chad> Linux... :)

In all honesty, were I to start ARDI today, I would probably GPL
everything and start as a support company.  However, I started ARDI
eight years ago and it wasn't clear that Free software companies would
be viable.  Switching over now would be next to impossible.

	--Cliff
	ctm@ardi.com

	[flight leaves in less than 12 hours]



References: