home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text0168.txt < prev    next >
Encoding:
Text File  |  1996-03-31  |  12.4 KB  |  263 lines

  1.  
  2. My $0.02+tax+plates+license:
  3.  
  4. >    I wonder if ARDI could look into buying/licensing the code for 
  5. >the Liken Macintosh emulator, and taking the code which let it run 
  6. >Apple's System files on Executor.  If this could be done quick+dirty 
  7. >enough, it would be a good way to boost compatibility without working too 
  8. >hard.
  9.  
  10. I'm not familliar with the product, but I wouldn't imagine anything like this
  11. occuring. I seem to remember hearing from Cliff that one of the things that
  12. ARDI was working toward was 'drop in System 7' originally for 2.0, and pushed
  13. to a later version. I'd guess a lot of work has been done, and I remember 
  14. reading
  15. that ARDI was talking with Apple over this. Getting a license for part of a
  16. commercial, competing product is not something that would come cheap, I would 
  17. bet.
  18.  
  19. >    Is it me, or is MAE just plain too expensive ($495???).  Even if 
  20. >it DID run on an Intel platform, it would still cost too much, and that 
  21. >would still leave a wide market for Executor.
  22.  
  23. It's expensive. But, until recently, almost all UNIX software was insanely 
  24. priced,
  25. most still is. The basic concept is still multi-$1000 site licenses for 
  26. software.
  27. This generally hasn't carried over into the home market (except for that OS/2 
  28. word processor, DeScribe, which forced you to buy some several $100/year 
  29. service
  30. contract from them...for single user use!) and the same seems to be carrying
  31. over to Linux, with more reasonable prices for programs from SimCity, to Maple,
  32. to Executor, and so on.
  33.  
  34. When you're the only company that makes a genre of program, you can charge 
  35. whatever
  36. you darn well please.
  37.  
  38. >    In addition, how much work would it take to actually make 
  39. >Executor run System 7.x.  I know trying to run 6.0.7/8 segfaulted at a 
  40. >certain point, so if the bugs could be tracked down, using GDB or other 
  41. >debuggers... it MIGHT not take too long to get it up (but then again, it 
  42. >might take a long time.)
  43.  
  44.   I know I saw Cliff mention this at some point. See above comment about 'drop
  45. in Sys7'. Personally, I don't like that, simply because Apple's System is the
  46. most bloated, hideous, twisted program I have ever seen. It's stuck with 
  47. special
  48. code for every Mac made, because Apple changed the hardware radically with each
  49. new model! I gave up on Apple after the ][ GS....the last real machine they
  50. made. 
  51.  
  52.    As for 6.0.x segfaulting, I would bet this is due to unimplemented features,
  53. or trickery that Apple doesn't document. There's a heck of a lot of that. But,
  54. I'm not a Mac expert.
  55.  
  56. >    Personally, I consider getting System 7.x to work, and a SVGAlib 
  57. >Linux version (which would be as fast, or faster than Executor/DOS video, 
  58. >since it can map a linear frame buffer on VLB cards) the top two items on 
  59. >my wish list for post-2.0 work.
  60.  
  61. See above comment about Sys7.
  62. I really don't know how beneficial a SVGAlib version of executor would be.
  63. SVGAlib seems to be horribly outdated with hardware support, and nowhere
  64. near as stable as XFree. Under DOS, you can use the VESA BIOS calls, and 
  65. standards,
  66. and let the hardware vendor deal with support. With SVGAlib, I can't get
  67. anything to run above 320x200 because I have a video card that's less than a
  68. year old. I'm not that familiar with SVGAlib, but I would guess that it also
  69. adds another layer of indirection.
  70.  
  71. >    In addition, would it be possible to make a 'frontend' link-kit 
  72. >(a executor.a library with all non-frontend code, and the source for the 
  73. >front-end video sections outside of that library) which would help 
  74. >facilitate ARDI outsiders such as myself work on things such as SVGAlib 
  75. >support?  I'd be interested into working on that, if possible.
  76.  
  77. Just guessing on this again, but I would bet that the effort required to 
  78. abstract
  79. the graphics calls would be almost the same as adapting it to another interface
  80. (i.e. SVGAlib.)
  81.  
  82. >    Actually, that's nothing compared to an idea I have : place 
  83. >large parts of Executor under the GPL, or something similar.  But, keep 
  84. >cool stuff such as the enhanced 68040 emulator ARDI-proprietary, and use 
  85. >the 1.2x synthetic CPU in the GPL version.
  86.  
  87. As a capitalist company, I would guess that it wouldn't be in ARDI's best
  88. interest to do that. Besides, what good would it do?
  89.  
  90. What would you do with most of the source code to a Mac emulator other than....
  91. use it in your own Mac emulator? The only thing that I could see coming from
  92. ARDI doing something like that would be cheap knockoff's of Executor. And I
  93. certainly wouldn't say the 1.2x synth-CPU isn't cool stuff.
  94.  
  95. >    This SOUNDS crazy from a business perspective, but if ARDI could 
  96. >organize independant development of Executor, and use the code developed 
  97. >outside ARDI in new versions of Executor, it would ease the effects of 
  98. >the lack of engineers that ARDI has, and vastly increase development.
  99.  
  100. They might get a dozen or so people sifting through the code. But what good 
  101. would
  102. it do them if they gave out the code with a license like the GPL? Or any
  103. sort of license. I think this idea misses the whole idea of why SOFTWARE 
  104. COMPANIES
  105. exist.
  106.  
  107. >Even if
  108. >the other parts were redeveloped outside (which would take a long time 
  109. >given how the WINE project is going), ARDI could still function as a 
  110. >support business, much like Aladdin runs Commercial Ghostscript and 
  111. >Cygnus Support handles gcc/gdb/etc..., and ARDI would still have the 
  112. >general copyright, just like Linus Torvalds 'owns' the copyright on 
  113. >Linux, and could add other enhancements as time went on.
  114.  
  115. Excuse me, but the Wine project is progressing significantly. A (small) 
  116. variety of programs run under linux and netbsd, and using Winelib, some
  117. Windows programs can even be recompiled to run on, say, a Sun.
  118.  
  119.   Mat? Cliff? Anyone want to agree with me, or flame me for being completely
  120. and utterly wrong?
  121.  
  122.   Sorry if this letter sounds too flame-like. It's late. I'm tired. It's really
  123. not meant to sound mean.
  124.  
  125. --Jered
  126. jered@mit.edu
  127.  
  128. From owner-executor  Wed Mar  8 01:58:24 1995
  129. 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
  130. 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
  131. 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
  132. Received: by mailhost (nextstep Smail3.1.29.0 #11)
  133.     id m0rmI2E-000YdzC; Wed, 8 Mar 95 02:28 MST
  134. Message-Id: <m0rmI2E-000YdzC@mailhost>
  135. Date: Wed, 8 Mar 95 02:28 MST
  136. From: ctm@ardi.com (Clifford T. Matthews)
  137. To: pageone@netcom.com
  138. Cc: executor@nacm.com
  139. Subject: Re: Liken, MAE, and a crazy thought...
  140. In-Reply-To: <Pine.3.89.9503071642.A6700-0100000@netcom3>
  141. References: <Pine.3.89.9503071642.A6700-0100000@netcom3>
  142. Sender: owner-executor@nacm.com
  143. Precedence: bulk
  144.  
  145. >>>>> "Chad" == pageone  <pageone@netcom.com> writes:
  146.  
  147.     Chad>     I wonder if ARDI could look into buying/licensing the
  148.     Chad> code for the Liken Macintosh emulator, and taking the code
  149.     Chad> which let it run Apple's System files on Executor.  If this
  150.     Chad> could be done quick+dirty enough, it would be a good way to
  151.     Chad> boost compatibility without working too hard.
  152.  
  153. Such code is actually easy to write.  In addition to Liken, there have
  154. been a wide variety of Macintosh emulators for the Amiga that do the
  155. same thing.  True, Liken had a synthetic CPU, but our synthetic CPU is
  156. already written.
  157.  
  158. The reason we don't have similar code is that all the ARDI engineers
  159. are "clean".  That means that we have never disassembled any Apple ROM
  160. or System file code and that we haven't been given any pointers by
  161. anyone who has.  The Liken code is "dirty".  They could do that
  162. because they required their end-users to procure code from Apple;
  163. something we do not want to do at the time.
  164.  
  165. *When* (not "if") we add similar functionality we'll do it by using
  166. "dirty" engineers who do not talk to our "clean" engineers.  Buying
  167. code from the Liken folk just won't speed things up; we'll need
  168. "dirty" engineers and a strict clean-room / dirty-room infrastructure
  169. and neither comes cheap.
  170.  
  171.     Chad>     Is it me, or is MAE just plain too expensive
  172.     Chad> ($495???).  Even if it DID run on an Intel platform, it
  173.     Chad> would still cost too much, and that would still leave a wide
  174.     Chad> market for Executor.
  175.  
  176. I don't think you'll see MAE coming out for Intel processors anytime soon.
  177.  
  178.     Chad>     In addition, how much work would it take to actually
  179.     Chad> make Executor run System 7.x.  I know trying to run 6.0.7/8
  180.     Chad> segfaulted at a certain point, so if the bugs could be
  181.     Chad> tracked down, using GDB or other debuggers... it MIGHT not
  182.     Chad> take too long to get it up (but then again, it might take a
  183.     Chad> long time.)
  184.  
  185. It would be a lot of work, but we've already stated that after 2.0
  186. comes out, it's a primary goal.
  187.  
  188.     Chad>     Personally, I consider getting System 7.x to work, and
  189.     Chad> a SVGAlib Linux version (which would be as fast, or faster
  190.     Chad> than Executor/DOS video, since it can map a linear frame
  191.     Chad> buffer on VLB cards) the top two items on my wish list for
  192.     Chad> post-2.0 work.
  193.  
  194. An SVGALib version is only useful to Linux users, so the priority for
  195. doing an SVGAlib backend is directly proportional to the number of
  196. sales of Executor/Linux we think we can get, which will be estimated
  197. based on the number of non-SVGAlib copies of Executor/Linux we sell.
  198.  
  199.     Chad>     In addition, would it be possible to make a 'frontend'
  200.     Chad> link-kit (a executor.a library with all non-frontend code,
  201.     Chad> and the source for the front-end video sections outside of
  202.     Chad> that library) which would help facilitate ARDI outsiders
  203.     Chad> such as myself work on things such as SVGAlib support?  I'd
  204.     Chad> be interested into working on that, if possible.
  205.  
  206. It may be possible, although it's pretty unlikely.
  207.  
  208.     Chad>     (And now, some thoughts that might be crazy enough to
  209.     Chad> actually work, or the result of me going nuts!)
  210.  
  211.     Chad>     Actually, that's nothing compared to an idea I have :
  212.     Chad> place large parts of Executor under the GPL, or something
  213.     Chad> similar.  But, keep cool stuff such as the enhanced 68040
  214.     Chad> emulator ARDI-proprietary, and use the 1.2x synthetic CPU in
  215.     Chad> the GPL version.
  216.  
  217. Unlikely.  However, we are working with the person that is doing the
  218. HFS support for Linux.  We've already sent him our source and sometime
  219. in the future we may try to merge his and our source, the resultant
  220. code would of course be GPL'd.
  221.  
  222.     Chad>     Or, if that's too much... GPL 1.2e + compatibility
  223.     Chad> enhancements taken from the 1.99x versions.
  224.  
  225.     Chad>     This SOUNDS crazy from a business perspective, but if
  226.     Chad> ARDI could organize independant development of Executor, and
  227.     Chad> use the code developed outside ARDI in new versions of
  228.     Chad> Executor, it would ease the effects of the lack of engineers
  229.     Chad> that ARDI has, and vastly increase development.
  230.  
  231. I think you're underestimating the potential revenue stream of
  232. Executor 2.0 when it's ready.  We are doing extremely well with just a
  233. few engineers.  If we could double our engineers and off-load
  234. non-development work to real system administrators and the business
  235. and marketing end to real business and marketing people we'd get
  236. things done *much* faster.
  237.  
  238.     Chad>     This could even possibly increase sales in the long
  239.     Chad> run, since the color/enhanced CPU version could only be
  240.     Chad> bought from ARDI.  Even if the other parts were redeveloped
  241.     Chad> outside (which would take a long time given how the WINE
  242.     Chad> project is going), ARDI could still function as a support
  243.     Chad> business, much like Aladdin runs Commercial Ghostscript and
  244.     Chad> Cygnus Support handles gcc/gdb/etc..., and ARDI would still
  245.     Chad> have the general copyright, just like Linus Torvalds 'owns'
  246.     Chad> the copyright on Linux, and could add other enhancements as
  247.     Chad> time went on.
  248.  
  249.     Chad>     I must be getting too much into the spirit of
  250.     Chad> Linux... :)
  251.  
  252. In all honesty, were I to start ARDI today, I would probably GPL
  253. everything and start as a support company.  However, I started ARDI
  254. eight years ago and it wasn't clear that Free software companies would
  255. be viable.  Switching over now would be next to impossible.
  256.  
  257.     --Cliff
  258.     ctm@ardi.com
  259.  
  260.     [flight leaves in less than 12 hours]
  261.  
  262.  
  263.