home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.95 / text0552.txt < prev    next >
Encoding:
Text File  |  1996-04-02  |  3.3 KB  |  77 lines
  1. On Thu, 20 Apr 1995, Mat Hostetter wrote:
  2.  
  3. > >>>>> "Thurman" == Thurman Gillespy <tg3@u.washington.edu> writes:
  4. > 
  5. >     Thurman> I only use Macs, but I am distributing an image display
  6. >     Thurman> program for medical images. People always want to know
  7. >     Thurman> about a PC version, and I'm obviously interested in
  8. >     Thurman> having my program run with Executor. Someone in our
  9. >     Thurman> department got NIH-Image to run on a PC, which greatly
  10. >     Thurman> peaked my interest.  Unfortunately, I require some System
  11. >     Thurman> 7 features, actually just the 4 required apple events,
  12. >     Thurman> and the calls to CustomGetFile, CustomPutFile. So
  13. >     Thurman> question 1, what are the plans for System 7 support? If
  14. >     Thurman> you only supported the 4 required apple events, a lot
  15. >     Thurman> more programs could run under executor.
  16. > 
  17. > We intend to "spoof" all of the "easy" System 7 features, including
  18. > apple events.  Our preliminary plan is that the application will never
  19. > see any apple events.  When it asks if any are present, the answer
  20. > will just always come back "no".  That should make most apps happy.
  21.  
  22. If they were programmed for this contingency. But System 7 has been out 
  23. quite a while, and newer programs are going to require its presence.
  24.  
  25. > We also plan to implement many of the System 7 filesystem extensions.
  26. > We intend to begin work on this as soon as 1.99m is out.  Hopefully
  27. > we'll be able to spoof enough traps that many System 7 programs will
  28. > run.  Tricky stuff, like QuickTime, is out of the question for now,
  29. > but most programs don't appear to demand the tricky stuff.
  30.  
  31. Yes, I agree.
  32.  
  33. >     Thurman> Question 2. How feasible would it be to specify a (bogus)
  34. >     Thurman> system call that actually pointed to some 386/486 code
  35. >     Thurman> that would run in native mode?  This code would make no
  36. >     Thurman> calls to the Mac API, but could do a processing intensive
  37. >     Thurman> task that normally takes a real hit when run in
  38. >     Thurman> emulation. With the release of the Metrowerks CodeWarrior
  39. >     Thurman> Platinum system next month, this kind of mixed
  40. >     Thurman> development will actually become very easy on the Mac.
  41. > 
  42. > That wouldn't be hard at all; in fact, Executor already uses a
  43. > mechanism like this internally.  We just don't (yet) have any
  44. > incentive to provide a public API for it.  You have to beware of the
  45. > fact that x86 code manipulates little endian data, while a 68k
  46. > program's data is stored in big endian byte order.
  47.  
  48. I work with medical images, and the endian/byte order issue is something 
  49. that we have to handle all the time.
  50.  
  51. Here's two incentives for providing a public API for x86 native code trap: 
  52.  
  53. Incentive #1:
  54.  
  55. PLEASEPLEASEPLEASEPLEASEPLEASEPLEASEPLEASEPLEASEPLEASEPLEASEPLEASE
  56.  
  57. Ok, that didn't work. Lets try...
  58.  
  59. Incentive #2:
  60.  
  61. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
  62.  
  63. Are you guys nuts? There is *tremendous* interest in cross platform 
  64. development from Mac developers. Believe me, there are no good solutions 
  65. that cost under many thousands of dollars. I think the idea of using your 
  66. emulator to handle the GUI stuff, and then doing computationally 
  67. intensive work in native x86 code is a BIG winner.
  68.  
  69. Best regards,
  70.  
  71. Thurman Gillespy III
  72. Department of Radiology
  73. University of Washington
  74. Seattle, Washington
  75.  
  76.  
  77.