[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: