home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text0051.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  3.8 KB  |  81 lines
  1. >>>>> "John" == John de Bruin <j.bruin@auckland.ac.nz> writes:
  2. In article <30EDE214.5C26@auckland.ac.nz> John de Bruin <j.bruin@auckland.ac.nz> writes:
  3.  
  4.  
  5.     John> I've heard many times how ARDI designed Executor from the
  6.     John> ground up, using clean room techniques, because of the
  7.     John> proprietory and secret nature of the Macintosh toolbox
  8.     John> ROMs. Hence programs which use certain undocumented features
  9.     John> of the ROMs will not work on Executor.
  10.  
  11. I'm sure it sounds like an old song and dance to people who have
  12. followed us closely, but it's the truth and it explains questions that
  13. come up frequently, so you'll probably hear it more, too.
  14.  
  15. Technically we don't really need the ROMs, per-se, we only need a
  16. functional specification to work from.  In other words as long as we
  17. know what every single routine has to do, and all the side-effects
  18. that applications could count on, we could fairly easily code up
  19. equivalents.
  20.  
  21. The way "clean room/dirty room" engineering works is you get "dirty"
  22. engineers to examine ROMs and write functional specs and they then
  23. pass those specs to a bunch of lawyers who make sure that the specs
  24. are functional in nature and do not reveal any implementation
  25. details.  The lawyers then give the specs to the clean room engineers
  26. who then implement according to specs.  This is expensive, but it's
  27. doable.  It would take any company other than ARDI too long to do this
  28. though, due to the amount of work required.  Luckily, we wouldn't
  29. really have to implement much new stuff, just make sure all the
  30. side-effects were properly handled.
  31.  
  32.     John> How then, do you explain the new Power Mac clones, from
  33.     John> companies like Radius? These machines are supposed to be
  34.     John> 100% Mac compatible. Do they reverse engineer the ROMs, do
  35.     John> they buy the ROMs from Apple, or has Apple made avaiable the
  36.     John> code for these ROMs in the "Open Reference Platform" or
  37.     John> something like that.
  38.  
  39. They have not reverse engineered the ROMs.  There have only been a
  40. very small handful of companies who have tried anything even vaguely
  41. similar to what we've done, the most notable were Nutek and Quorum.
  42. Both had much less compatibility that we have and went (virtually)
  43. bust trying to do what we have done.
  44.  
  45. Radius and PowerComputing use Apple's ROMs via a license from Apple.
  46. We approached Apple's licensing department and were given the names of
  47. a couple people to talk to, but they did not return our e-mail.
  48. During MACWORLD Expo you can bet that we'll be talking (at least
  49. unofficially) to many Apple employees.
  50.  
  51. Apple's official position is that they will not license any 68k based
  52. stuff, so we'll have to get a PPC emulator going before we can
  53. officially license Apples's software (unless they change their mind).
  54. Luckily, VCPU will make a PPC emulator relatively easy, *and* even
  55. without Apple's permission we can make Executor so that you will be
  56. able to drop a copy of System 7.5 on top of it and have it work.  That
  57. requires a lot of work -- more than the few engineers we currently
  58. have, *but* it's work that we understand and we have a tremendous
  59. framework to start with, so it's largely a matter of getting money for
  60. engineers, which is something else we're pursuing at MACWORLD Expo.
  61.  
  62.     John> I'd be interested to know what Radius and the other clone
  63.     John> maker(s) do in this regard.
  64.  
  65. My understanding is that they not only license the ROMs, but they also
  66. license much more, too, including ASICs that are in such short supply
  67. that Gateway wasn't able to cut a licensing deal with Apple because
  68. they weren't able to turn out the ASICs quick enough.
  69.  
  70.     John> Bye....  -- ________________________________
  71.  
  72.     John> John de Bruin Email: j.bruin@auckland.ac.nz
  73.  
  74. I hope this explains some of the legal issues involved.  These are all
  75. matters that we're pursuing with vigor.
  76.  
  77.  
  78. --Cliff
  79. ctm@ardi.com
  80.  
  81.