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

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