home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text3319.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  8.7 KB  |  177 lines
  1. In article <ufohmnxs0u.fsf@ftp.ardi.com>, Clifford T. Matthews
  2. <ctm@ardi.com> wrote:
  3.  
  4. > I suspected Executor was mentioned, but I didn't know for sure,
  5. > especially since the 1/100th speed strongly suggests that Executor is
  6. > *not* what's being discussed.
  7.  
  8.    And it was somewhat obvious that the person in question didn't know
  9. alot about Executor.
  10.  
  11. >     Patrick>    I've played with Executor on a '486, and while it was
  12. >     Patrick> a nice application enviroment, doesn't quite equalify as
  13. >     Patrick> a emulator, in the sence of Emplant on the Amiga, or
  14. >     Patrick> SoftWindows on the Mac, i.e. - replicating every function
  15. >     Patrick> of the Operating System, rather than acting as a
  16. >     Patrick> application "envelope".
  17. > 
  18. > I'd prefer a different term than emulator, too, since emulators are
  19. > usually very slow and require the firmware and/or OS of the machine
  20. > they are emulating.  Executor is very fast, doesn't require an Apple
  21. > ROM or System file, but consequently doesn't have the degree of
  22. > compatibility a "traditional" emulator would.
  23.  
  24.    True, which is why I tend to call Executor a "Application Enviroment",
  25. since that, (IMHO), is what is does, it gives a MacOS application a
  26. enviromental "envelope" to run on a x86-based system.   The problem is
  27. that many PC advocates *think* that Executor is a full-fledged emulation
  28. system.   Granted that's a perception problem that's not ADRI's fault, but
  29. it's still a problem.
  30.  
  31. >     Patrick> In terms of speed, well, I would be far more impressed if
  32. >     Patrick> it could emulate the entire MacOS, including system
  33. >     Patrick> calls, networking, printing, System 7 support, etc., at
  34. >     Patrick> the speed, (or faster), of a 25Mhz 68040.
  35. > 
  36. > Some people are easily impressed, some are less so.  We're the only
  37. > company that has *any* Macintosh binaries running on an x86, with or
  38. > without using Apple's code, in addition we're the only company to have
  39. > rewritten enough of Apple's OS and toolbox code to run as many
  40. > applications as we do.
  41.  
  42.    True.   It's like the singing pig.  It's not how well the pig sings,
  43. it's that the pig sings at all.
  44.  
  45. >     Patrick> As it is, I feel ARDI is being somewhat dishonest or
  46. >     Patrick> misleading in making the claim that Executor is faster
  47. >     Patrick> than a 25Mhz 68040.  Yes it is, but again, it doesn't
  48. >     Patrick> emulate the full MacOS, doesn't support all the features,
  49. >     Patrick> and acts as a limited application enviroment.
  50. > 
  51. > I made the claim because it's true and it's relevant.  Yes, Executor
  52. > is not as compatible as a real Mac, but if the Mac app that you want
  53. > to run on a PC *does* run under Executor, then it will probably run
  54. > significantly faster on an entry level pentium than a 25 MHz 68040
  55. > based Mac.
  56.  
  57.    It's true and relevant in a sense, however, it's the claim that I think
  58. has been causing the above mentioned PC advocates to think that Executor
  59. is a full emulation system.
  60.  
  61.    Yes, Executor runs a limited selection of programmes on a '586, at
  62. speeds matching or surpassing a 25Mhz 68040.    This claim is used by some
  63. PC advocates I've encountered to claim that the PC "does Mac emulation
  64. better than the Mac does PC emulation."     Quite frankly, if I was to
  65. write a clean-room application enviroment that ran a limited selection of
  66. x86 apps on the Mac, I might be able to get speeds that are better than
  67. Insignia's SoftPC/SoftWindows.   However, it wouldn't have the same
  68. functionality.    By the same token, if ARDI was to get permission from
  69. Apple to use MacOS routines in Executor, (in much the same way Insignia
  70. uses Windows routines in SoftWindows), I have no doubt that the
  71. compatibility of Executor would go up, but I also have no doubt that the
  72. overall speed would not remain as fast.   I.e., I doubt that a variant of
  73. Executor with full MacOS emulation wouldn't keep the speed that the
  74. current version has.
  75.  
  76.    I will say that perhaps I was wrong in stating that ARDI was being
  77. misleading or dishonest.  ARDI certainly has no way to control how people
  78. interpret their information.    However, I wish that ARDI could be a bit
  79. clearing in stating that the speed increase is more due to the fact that
  80. Executor isn't emulating the same amount or level of code that something
  81. like SoftWindows does.
  82.  
  83. >     Patrick> SoftWindows, on the other hand, does emulate a full x86
  84. >     Patrick> chip set, and, (on a PowerPC-based Mac), emulates '386
  85. >     Patrick> code at '486 or faster speed.  Heck, SoftWindows 1.0, on
  86. >     Patrick> my 33Mhz 68040 Mac, is slightly faster than a '286.  Of
  87. >     Patrick> course, I tend to use SoftPC rather than SoftWindows, but
  88. >     Patrick> it's still not bad.
  89. > 
  90. > SoftWindows doesn't run everything, although it does indeed run a
  91. > larger percentage of programs than Executor does.  However, speedwise,
  92. > there is no comparison.  Mac apps that *do* run under Executor, run
  93. > much faster under Executor on an N MHz P5 than an equivalent x86 based
  94. > application would run on an N MHz 601 under SoftPC or SoftWindows.
  95.  
  96.    This is true.  However, as I mentioned above, Executor isn't emulating
  97. the same functionality or amount of code that SoftWindows is.    In the
  98. amount of code that Executor is running, the speed is pretty dammed
  99. impressive.    However, if Executor was emulating the same functionality
  100. and amount of code, I would still think you would get a speed hit.   
  101. Personally, I'd rather use a hardware DOS card than software emulation,
  102. but when you don't have one of those critters.....:-)
  103.  
  104. > I don't think it's misleading for us to say:
  105. > 
  106. >         "Executor on a modern Pentium machine runs much faster than a
  107. >         25 MHz 68040 based Mac.  Executor is not as compatible as a
  108. >         real Mac, but speed problems?  I don't think so."
  109.  
  110.    Misleading ?    Possibly.   Most people don't seem to read past the
  111. "Executor on a modern Pentium machine runs much faster than a 25 MHz 68040
  112. based Mac." part.    Perhaps a better way to write this might be:
  113.  
  114.    "Within the compatibility issues mentioned in our FAQ, Executor on a
  115. modern Pentium machine runs much faster than a 25 MHz 68040 based Mac.   
  116. No, you will not be able to run all the programmes a real Mac can run, but
  117. speed problems?  I don't think so."
  118.  
  119.    Granted, it's slightly wordier, but it does qualify your claim in such
  120. a way that doesn't leave it as open to misinterpretation.  Mind you, this
  121. is only my opinion, based upon discussions with PC advocates that haven't
  122. seemed to read your FAQ.....:-)
  123.  
  124. > Executor's
  125. > CPU emulation (which is basically flawless) *is* a much faster way to
  126. > run 680x0 code than a 25 MHz '040, which is especially important in
  127. > the context of using an Amiga to run Mac code, because the Amiga is
  128. > going to run CPU intensive code approximately at the same speed that
  129. > a comparable 680x0 Mac would run it.
  130.  
  131.    Well, the Amiga advocates tend to claim that the specialized chip sets
  132. in the Amiga help to speed up the Mac emulation, making a 25Mhz
  133. 68040-based Amiga faster than a 25Mhz 68040-based Mac.   However, I found,
  134. (with my old Amigas), that it depends on the MacROMs used.   If you use
  135. the ROMs from a 68040-based Mac, you get a speed boost.   If you use the
  136. ROMs from a older machine, the speeds are roughly the same, or even
  137. slightly slower.
  138.  
  139. > That's what I was trying to point out.  I didn't go into
  140. > Executor details at length because I didn't even know if Executor was
  141. > what was being discussed.
  142.  
  143.    Executor was being mentioned in passing, but the gist was, at that
  144. time, Mac emulation on the Amiga.
  145.  
  146. >  I did mention that it's not as compatible
  147. > as a Mac and I gave a URL where a demo copy and a FAQ can be read to
  148. > get much more detail than I could post.
  149.  
  150.    Which was a help - at least for me, since my copy of your FAQ was a bit
  151. out of date.....:-)
  152.  
  153. > Basically I agree with everything you've said with the exception of my
  154. > claim being misleading or dishonest.  I see speed and compatibility as
  155. > orthogonal issues.  As I mentioned before http://www.ardi.com/
  156. > contains enough information for people to see both what Executor is,
  157. > but also the claims we make for it.
  158.  
  159.    Hopefully I qualified my opinions on this a bit better this time.   
  160. While I don't say that Executor gives as much functionality as a PC
  161. emulator on the Mac, it's still a dammed impressive bit of software.    I
  162. don't think I'd object to seeing if ARDI could do the same with other
  163. platforms, (say, a x86 emulator or application enviroment for
  164. PowerPC-based machines, or if they could create a better 680x0 emulator
  165. for the PowerPC - hint, hint.....:-)
  166.  
  167.    - Patrick McKinnion
  168.  
  169. -- 
  170. <*>   SP2    Web Page at: http://www.csusm.edu/public/PWMcK/pmck.html
  171. -- Brought to you by "ouchies".  The sharp, prickly toy you bathe with... 
  172. -----BEGIN GEEK CODE BLOCK-----
  173. Version: 3.1
  174. GSS/CM d- s: a C++ UL+A W++> N+++ K w-- O+ M++ PS+ PE+ Y+ PGP++ t++@ 5++> X+ R b+++ DI++++ D+ G e+> h--> r++ z+>*
  175. ------END GEEK CODE BLOCK------
  176.  
  177.