home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text0347.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  3.5 KB  |  72 lines

  1. In article <4e0ooo$f5l@news.voicenet.com>, chessman@voicenet.com (ChessMan) 
  2. declares...
  3.  
  4. >  The program is 
  5. >essentially emulating System 6.0.7 which Apple stopped shipping with their 
  6. >computers over 3 years ago
  7. [snip]
  8. >The software runs without any control panels or inits - a 'real' mac user 
  9. has 
  10. >many of these little programs at the tip of their finger tips - and of 
  11. course 
  12. >it's not multi-processing aware - to run two applications; you must run it 
  13. >under windows and start it twice.  So it really doesn't have the  feel of a 
  14. >MAC - but hey - it plays that little Risk game  like a champ.
  15.  
  16. I don't actually disagree with any of this, but thought it might be a good 
  17. opportunity to remind people/clue in newcomers about the long-term ARDI 
  18. strategy, at least as I, a registered Executor customer with no other ties to 
  19. ARDI, understand it.
  20.  
  21. Right now, they're doing everything they can to get a commercially viable 
  22. version 2.0 out the door.  The revenue from that will fund development for 
  23. networking support, serial port support, better sound, more colors, etc.  
  24. This may raise yet more money.  But the longer-term goal, for version 3.0 or 
  25. so, I guess, is to make Executor a base onto which one will install a real 
  26. copy of System 7.x and run all MacOS functionality.
  27.  
  28. There are three or so obstacles:
  29.  
  30. 1) Dirty/Clean engineering.  ARDI has figured out most of the Mac ROM 
  31. functionality through "clean-room" techniques; they haven't broken any 
  32. copyright or patent agreements to figure out what the ROMs do.  Finding out 
  33. the remaining undocumented features of the ROMs and other low-level features 
  34. involves hiring a new, "dirty" team of engineers to reverse-engineer and 
  35. otherwise mess around in Mac innards to find out such details. Those details 
  36. will be used to draft pure specifications, which will go to the clean team, 
  37. allowing them to cleanly implement that functionality.  A couple of 
  38. iterations of this, and the above goal could be reachable, at least in 
  39. theory.  So the 6.0.7 functionality is a way of *funding* System 7.x 
  40. droppability.
  41.  
  42. 2) PowerPC.  Mat Hostetler, the syn68k (ARDI's Motorolla emulator) has 
  43. indicated that a PPC emulator won't be too much work, so Executor should 
  44. eventually run PPC binaries.  He's even said that developers could include 
  45. native x86 code, and that Executor could declare itself and allow Mac apps to 
  46. run natively on the x86 (or whatever other processor Executor is ported to) 
  47. if they were developed with such a "superfat" binary.  Tantalizing.  This, 
  48. too, awaits more moolah.
  49.  
  50. 3) Copeland.  System 7.x won't be a poor OS laggard for too many more years 
  51. before Apple, provided it's solvent, releases Copeland, the next major 
  52. upgrade.  (I know it *sounds* like I'm starting a religious war, but I'd 
  53. rather not, as such wars on this group get intensely weird.  Best that we can 
  54. all just emulate each other, IMHO :-)).  Presumably, once (2) is 
  55. accomplished, (3) won't be a big problem, but there may be technical details 
  56. I don't know about.  There are also Common Hardware Reference Platform specs 
  57. I'm fuzzy on.
  58.  
  59. In other words, the 6.0.7 limitation isn't final.  BUT, and this is the 
  60. tricky bit, it's against ARDI's long-term interests to spend much time 
  61. hacking 7.x functionality now when it will eventually turn all that over to 
  62. Apple.  They need just enough System 7 support to get a customer base; after 
  63. that, lower-level issues have greater marginal utility.
  64.  
  65. Again, none of this is official, though the dirty/clean room stuff is 
  66. summarized from one of Cliff Mathews' posts.
  67.  
  68. Scott Shuchart
  69. shuchart@fas.harvard.edu
  70.  
  71.  
  72.