home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text0232.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  5.7 KB  |  128 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.