home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text0233.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  5.5 KB  |  119 lines
  1. >>>>> "Chad" == pageone  <pageone@netcom.com> writes:
  2.  
  3.     Chad>     I wonder if ARDI could look into buying/licensing the
  4.     Chad> code for the Liken Macintosh emulator, and taking the code
  5.     Chad> which let it run Apple's System files on Executor.  If this
  6.     Chad> could be done quick+dirty enough, it would be a good way to
  7.     Chad> boost compatibility without working too hard.
  8.  
  9. Such code is actually easy to write.  In addition to Liken, there have
  10. been a wide variety of Macintosh emulators for the Amiga that do the
  11. same thing.  True, Liken had a synthetic CPU, but our synthetic CPU is
  12. already written.
  13.  
  14. The reason we don't have similar code is that all the ARDI engineers
  15. are "clean".  That means that we have never disassembled any Apple ROM
  16. or System file code and that we haven't been given any pointers by
  17. anyone who has.  The Liken code is "dirty".  They could do that
  18. because they required their end-users to procure code from Apple;
  19. something we do not want to do at the time.
  20.  
  21. *When* (not "if") we add similar functionality we'll do it by using
  22. "dirty" engineers who do not talk to our "clean" engineers.  Buying
  23. code from the Liken folk just won't speed things up; we'll need
  24. "dirty" engineers and a strict clean-room / dirty-room infrastructure
  25. and neither comes cheap.
  26.  
  27.     Chad>     Is it me, or is MAE just plain too expensive
  28.     Chad> ($495???).  Even if it DID run on an Intel platform, it
  29.     Chad> would still cost too much, and that would still leave a wide
  30.     Chad> market for Executor.
  31.  
  32. I don't think you'll see MAE coming out for Intel processors anytime soon.
  33.  
  34.     Chad>     In addition, how much work would it take to actually
  35.     Chad> make Executor run System 7.x.  I know trying to run 6.0.7/8
  36.     Chad> segfaulted at a certain point, so if the bugs could be
  37.     Chad> tracked down, using GDB or other debuggers... it MIGHT not
  38.     Chad> take too long to get it up (but then again, it might take a
  39.     Chad> long time.)
  40.  
  41. It would be a lot of work, but we've already stated that after 2.0
  42. comes out, it's a primary goal.
  43.  
  44.     Chad>     Personally, I consider getting System 7.x to work, and
  45.     Chad> a SVGAlib Linux version (which would be as fast, or faster
  46.     Chad> than Executor/DOS video, since it can map a linear frame
  47.     Chad> buffer on VLB cards) the top two items on my wish list for
  48.     Chad> post-2.0 work.
  49.  
  50. An SVGALib version is only useful to Linux users, so the priority for
  51. doing an SVGAlib backend is directly proportional to the number of
  52. sales of Executor/Linux we think we can get, which will be estimated
  53. based on the number of non-SVGAlib copies of Executor/Linux we sell.
  54.  
  55.     Chad>     In addition, would it be possible to make a 'frontend'
  56.     Chad> link-kit (a executor.a library with all non-frontend code,
  57.     Chad> and the source for the front-end video sections outside of
  58.     Chad> that library) which would help facilitate ARDI outsiders
  59.     Chad> such as myself work on things such as SVGAlib support?  I'd
  60.     Chad> be interested into working on that, if possible.
  61.  
  62. It may be possible, although it's pretty unlikely.
  63.  
  64.     Chad>     (And now, some thoughts that might be crazy enough to
  65.     Chad> actually work, or the result of me going nuts!)
  66.  
  67.     Chad>     Actually, that's nothing compared to an idea I have :
  68.     Chad> place large parts of Executor under the GPL, or something
  69.     Chad> similar.  But, keep cool stuff such as the enhanced 68040
  70.     Chad> emulator ARDI-proprietary, and use the 1.2x synthetic CPU in
  71.     Chad> the GPL version.
  72.  
  73. Unlikely.  However, we are working with the person that is doing the
  74. HFS support for Linux.  We've already sent him our source and sometime
  75. in the future we may try to merge his and our source, the resultant
  76. code would of course be GPL'd.
  77.  
  78.     Chad>     Or, if that's too much... GPL 1.2e + compatibility
  79.     Chad> enhancements taken from the 1.99x versions.
  80.  
  81.     Chad>     This SOUNDS crazy from a business perspective, but if
  82.     Chad> ARDI could organize independant development of Executor, and
  83.     Chad> use the code developed outside ARDI in new versions of
  84.     Chad> Executor, it would ease the effects of the lack of engineers
  85.     Chad> that ARDI has, and vastly increase development.
  86.  
  87. I think you're underestimating the potential revenue stream of
  88. Executor 2.0 when it's ready.  We are doing extremely well with just a
  89. few engineers.  If we could double our engineers and off-load
  90. non-development work to real system administrators and the business
  91. and marketing end to real business and marketing people we'd get
  92. things done *much* faster.
  93.  
  94.     Chad>     This could even possibly increase sales in the long
  95.     Chad> run, since the color/enhanced CPU version could only be
  96.     Chad> bought from ARDI.  Even if the other parts were redeveloped
  97.     Chad> outside (which would take a long time given how the WINE
  98.     Chad> project is going), ARDI could still function as a support
  99.     Chad> business, much like Aladdin runs Commercial Ghostscript and
  100.     Chad> Cygnus Support handles gcc/gdb/etc..., and ARDI would still
  101.     Chad> have the general copyright, just like Linus Torvalds 'owns'
  102.     Chad> the copyright on Linux, and could add other enhancements as
  103.     Chad> time went on.
  104.  
  105.     Chad>     I must be getting too much into the spirit of
  106.     Chad> Linux... :)
  107.  
  108. In all honesty, were I to start ARDI today, I would probably GPL
  109. everything and start as a support company.  However, I started ARDI
  110. eight years ago and it wasn't clear that Free software companies would
  111. be viable.  Switching over now would be next to impossible.
  112.  
  113.     --Cliff
  114.     ctm@ardi.com
  115.  
  116.     [flight leaves in less than 12 hours]
  117.  
  118.  
  119.