home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text2656.txt < prev    next >
Encoding:
Internet Message Format  |  1996-03-31  |  1.9 KB
  1. Received: from yonge.cs.toronto.edu (yonge.cs.toronto.edu [128.100.1.8]) by nacm.com (8.6.10/8.6.9) with SMTP id IAA18662 for <executor@nacm.com>; Wed, 5 Jul 1995 08:17:28 -0700
  2. Received: from neat.cs.toronto.edu ([128.100.1.65]) by yonge.cs.toronto.edu with SMTP id <86538>; Wed, 5 Jul 1995 11:17:19 -0400
  3. Received: by neat.cs.toronto.edu id <6165>; Wed, 5 Jul 1995 11:17:10 -0400
  4. From: Jeff Tupper <mooncake@cs.toronto.edu>
  5. To: mat@ardi.com
  6. Subject: Re: Future Questions
  7. Cc: executor@nacm.com
  8. Message-Id: <95Jul5.111710edt.6165@neat.cs.toronto.edu>
  9. Date:     Wed, 5 Jul 1995 11:17:04 -0400
  10. Sender: owner-paper@nacm.com
  11. Precedence: bulk
  12.  
  13. mat@ardi.com (Mat Hostetter):
  14.  
  15. > Long ago Executor was a source-compatible library, but it would be
  16. > difficult to resurrect it in that form.  There are also some very
  17. > difficult issues for developers involving byte ordering; have you
  18. > noticed that all platforms supported by Apple (680x0, PowerPC, and
  19. > those supported by MAE) are all "big endian"?
  20.  
  21. > -Mat
  22.  
  23. Well, I must be missing something, but the platforms supported by
  24. Apple all do so through emulation (in addition to native code). If
  25. one is emulating 68K code, preserving endianness is nice, but a
  26. fairly easy things for developers to avoid. After all, my program
  27. runs on both 68K and x86 [but not VAX]. Just don't write out longs and
  28. read them back as shorts or bytes. Read data in the same way you
  29. wrote it out. You have to have architecture independant file code
  30. but that can be done easily as well. What would be difficult to
  31. do is handle WMF/BMP files as PICT files - probably not worth the
  32. hassle, just let developers write a bit of code for that. (Well,
  33. it could be done - just warn developers about the holes) Accessing
  34. bitmaps/video would have to be patched up too, but none of this
  35. is as much work as porting to a different API (all this would be
  36. done, plus a whole bunch more :)
  37.  
  38. I'll take your word that it wouldn't be easy ;> 
  39.  
  40. jeff
  41.  
  42.