home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text1209.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  4.8 KB  |  102 lines
  1. >>>>> "Jeff" == Jeff Tupper <mooncake@cs.toronto.edu> writes:
  2.  
  3.     Jeff> mat@ardi.com (Mat Hostetter):
  4.     >> Long ago Executor was a source-compatible library, but it would
  5.     >> be difficult to resurrect it in that form.  There are also some
  6.     >> very difficult issues for developers involving byte ordering;
  7.     >> have you noticed that all platforms supported by Apple (680x0,
  8.     >> PowerPC, and those supported by MAE) are all "big endian"?
  9.  
  10.     >> -Mat
  11.  
  12.     Jeff> Well, I must be missing something, but the platforms
  13.     Jeff> supported by Apple all do so through emulation (in addition
  14.     Jeff> to native code).
  15.  
  16. This isn't meant to be a flame, just a simple explanation of some of
  17. the reasons Mat said what he said.  Both Mat and I are *extremely*
  18. aware of the issues being discussed.
  19.  
  20. Yes, one thing you appear to be missing is that Apple does not support
  21. any Mac emulators on little-endian machines.  They support the
  22. original 68k, the PPC, the SPARC and the HP.  Notably absent is the
  23. x86 and Alpha.
  24.  
  25.     Jeff> If one is emulating 68K code, preserving
  26.     Jeff> endianness is nice, but a fairly easy things for developers
  27.     Jeff> to avoid.
  28.  
  29. No, the semantics of the Mac system calls are such that endianness has
  30. to be considered everywhere.  If you're not familiar with programming
  31. the Mac, the following may not make sense, but what do you do with
  32. system routines that expect to pick up data in resources?  Should the
  33. resources be stored in native order or canonical (big endian) order?
  34. If you pick the former, then you can't pass files containing resources
  35. around between machines of different endianness.  If you chose the
  36. latter, then you have to do byte swapping yourself if you are going to
  37. use the resource internally.
  38.  
  39.     Jeff> After all, my program runs on both 68K and x86
  40.     Jeff> [but not VAX].
  41.  
  42. Your programs are not Mac programs, right?  Big difference (see above).
  43.  
  44.     Jeff> Just don't write out longs and read them back
  45.     Jeff> as shorts or bytes. Read data in the same way you wrote it
  46.     Jeff> out.
  47.  
  48. See?  You overlooked the system service issue.  Remember, the system
  49. services that MacOS provides are already cast in stone.  We're talking
  50. about tools to enable *existing* applications to be ported, not the
  51. possibility of writing tools that work well with new code.
  52.  
  53.     Jeff> You have to have architecture independant file code but
  54.     Jeff> that can be done easily as well.
  55.  
  56. Nope.  Same problem.  There are a variety of file formats that are
  57. *already* defined.  Hence the programmer has to be aware of the byte
  58. swapping issues.  That makes for significant amounts of extra code to
  59. write.  Guess what happens when you provide tools that aid in this
  60. process, but still require the end-user (i.e. the programmer doing the
  61. port) to pay careful attention to these things?  You get tons of calls
  62. by irate programmers saying "the tools don't work", and you know what?
  63. They'll be right -- one out of ten times.  That one out of ten will
  64. teach them not to trust the tools (the tools we're talking about are
  65. prone to the same clean-room development incompatibility issues that
  66. Executor is), so everytime something goes wrong, the tools will be blamed.
  67.  
  68.     Jeff> What would be difficult to
  69.     Jeff> do is handle WMF/BMP files as PICT files - probably not
  70.     Jeff> worth the hassle, just let developers write a bit of code
  71.     Jeff> for that. (Well, it could be done - just warn developers
  72.     Jeff> about the holes) Accessing bitmaps/video would have to be
  73.     Jeff> patched up too, but none of this is as much work as porting
  74.     Jeff> to a different API (all this would be done, plus a whole
  75.     Jeff> bunch more :)
  76.  
  77. In some cases you're right, in some cases not.  Some programs would
  78. port more easily using such tools than others.  However, we discovered
  79. years ago that it is impossible to offer such tools when you're a
  80. small company.  After 2.0 is shipping, if we have boatloads of cash,
  81. it may make sense for us to reimplement what we had before.  However,
  82. the tools would either be expensive or would have very high technical
  83. support fees tied to them.
  84.  
  85. Remember, this is what ARDI originally did.  We ran into all the
  86. problems mentioned above, and more.  Back then people would also ask
  87. us whether or not our tools would be good enough to port, say,
  88. Microsoft Word.  We'd answer "Yes.  <pause>  We think."  We'd then
  89. have to explain that we would never see the source to Microsoft Word,
  90. so all such answers would be speculation.  Eventually, to silence our
  91. critics, we wrote some glue and made a small program that would run
  92. Macintosh binaries -- you guessed it -- that program was Executor.
  93.  
  94. Once Executor got a little better, it was clear that we'd do much
  95. better working on and selling Executor -- in fact, we even had a
  96. couple of profitable months back in NEXTSTEP's heyday, back before
  97. NeXT stopped making hardware, but that's another story.
  98.  
  99.     --Cliff
  100.     ctm@ardi.com
  101.  
  102.