home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / dos / extra / docs / maillist / text / archive.95 / text0240.txt < prev    next >
Encoding:
Text File  |  1996-03-31  |  8.4 KB  |  200 lines

  1.  
  2.  
  3. On Sat, 1 Apr 1995, Clifford Thomas Matthews wrote about the Future of 
  4. Executor 1.99x and the Great Release of 2.0:
  5.  
  6. (And then I wrote a reply about all the stuff he talked about, and now 
  7. you're reading it.  :)  It's a bit late now, so this probably isin't the 
  8. most focused post, but here goes...
  9.  
  10. > Yeah, that's the good side of "experimental" releases.  We don't have
  11. > to go through a "code freeze" before they come out.  The bad side is
  12. > that every once in a while an experimental version comes out that is
  13. > significantly *worse* than its predecessor.
  14.  
  15.     Sounds just like Linux 1.1.x releases.  Or better yet, the Linux 
  16. 0.99 kernels (I started by tinkering with a 0.99pl13 Yggdrasil release - 
  17. but didn't really get into it until later...)
  18.  
  19.     [Some really cool 1.99l stuff left out to focus on stuff I want 
  20. to reply to...]
  21.  
  22. >     Browser will be used by default
  23.  
  24.     Yeah!
  25. >     Chaining from one app to the browser and to another app works
  26. >         much better than the old chaining stuff
  27.  
  28.     Sounds good too...
  29. >     We got permission to include Stuffit Expander, so it will be
  30. >         much easier for folks to expand .hqx files and
  31. >         whatnot.
  32.  
  33.     That'll make it much easier for people to get stuff, and will 
  34. help the demo audience for sure.
  35.  
  36. >     Printing will work for Linux users
  37.     Yes!  Now I can do all my wordprocessing under Word 5 in Linux! :)
  38.  
  39. >     Animation works better under Linux (See Ultimate Solitaire)
  40.  
  41.     Is this the 4-dirty rectangle setup Mat was thinking about?  If so, 
  42. that'll be a BIG improvement.
  43.  
  44. >     Right alternate is now option key under Linux
  45.     Ah, I just love a bunch of new options :)
  46.  
  47. >     A lot of misc. fixes that will make it more likely that
  48. >         randomly selected programs will work
  49.     Wonder if some of them will make PageMaker 4 work (fingers crossed...)
  50. > I'm not sure if I've posted this timeline to this list yet.  If this
  51. > is old information, you have my humble apology:
  52. >     1.99m will have a significantly faster blitter under DOS,
  53. >         (we're hoping for about a speedup of about a factor
  54. >         of five).  It will also support some screens with 16
  55. >         bpp (thousands of colors) and 32 bpp (millions of colors).
  56. >         We also hope that the remaining
  57. >         DPMI provider bug that we know of will be fixed by
  58. >         then, and we will be paying attention when people find
  59. >         browser bugs.  I don't know if System 7 spoofing will
  60. >         be in "m", but it is my goal (however, of all the ARDI
  61. >         employees, I'm the one who is most likely to not meet
  62. >         my goals).  Floppy disk formatting and the ability to
  63. >         install fonts and DAs by dragging them into the hot
  64. >         band are also tentatively slated for 1.99m, as is a
  65. >         "death certificate" that tells you *why* Executor died
  66. >         when it dies unexpectedly.
  67.  
  68.     (Yipes!  Just as you release 1.99l, you tell me more cool stuff 
  69. planned for 1.99m/n... :)
  70.  
  71.     I'm especially glad to see floppy disk formatting and font/da 
  72. support go in.  Those are things which Executor really needs to become a 
  73. full Mac-like environment, along with the browser.
  74.  
  75. >     1.99n will have any of the features mentioned above in 1.99m
  76. >         that don't make the cut.  Tentatively, 1.99n will be
  77. >         the last experimental version to have new
  78. >         functionality.
  79.     And then, finally we'll get 2.0!  (Sadly,  this will mean Linux 
  80. will still have the record for longest x.99x public pre-release cycles.)
  81.  
  82. >     Beyond 1.99n we plan to fly Cotton out to Albuquerque (he
  83. >         normally works out of Boston) and have a two or
  84. >         three (three is preferred) week "hackathon", where
  85. >         without having to worry about getting a new version
  86. >         out the door, and without any of us having to add new
  87. >         functionality or chase DOS extenders, we'll work
  88. >         exclusively on making more applications run.
  89.     Sounds like that'll really bring things up a level or two in 
  90. terms of compatibility.
  91.  
  92. >     After the "hackathon" is finished, Executor will go into a six
  93. >         week beta period where we only fix major bugs, and
  94. >         document minor bugs.  During this time we'll also be
  95. >         working on our packaging and documentation, working on
  96. >         our list of how well which apps work and which don't,
  97. >         and lining up our distributors, writing our press
  98. >         releases and placing our ads in popular magazines.
  99. >     After those six weeks have elapsed, 2.0 will ship.
  100. > That's the plan, anyway.
  101.  
  102.     So, 2.0 will be out, in around, say July/August?  Anyone wanna 
  103. take bets on whether Executor 2.0 or Windows 95 is going to go final 
  104. first?  (I'm using Win95 build 347 now.  It's pretty stable, but a lot of 
  105. technical stuff is weak.  I can't go above 640x480x256, and support for 
  106. (E)IDE specific functions is nonexistant - it uses BIOS only, and dosen't 
  107. even touch the drive's identify feature (which mentions what the hd's 
  108. name is, among other things...).  Amazing what a Linux EIDE driver can do to 
  109. your expectations :)
  110.  
  111.     Seriously, good luck!  I'm REALLY looking forward to 1.99l now!
  112.     
  113.     - Chad
  114.  
  115. > [We actually have plans for beyond 2.0, but astrology is hard]
  116. >     --Cliff
  117. >     ctm@ardi.com
  118.  
  119. From owner-executor  Sun Apr  2 05:26:25 1995
  120. Received: (from majordom@localhost) by nacm.com (8.6.9/8.6.9) id FAA15790 for executor-outgoing; Sun, 2 Apr 1995 05:26:25 -0700
  121. Received: from mailhost.pipex.net (mailhost.pipex.net [158.43.128.3]) by nacm.com (8.6.9/8.6.9) with SMTP id FAA15785 for <executor@nacm.com>; Sun, 2 Apr 1995 05:26:18 -0700
  122. Received: from EMX01.LANDP.CO.UK (actually emx018.landp.co.uk) 
  123.           by pipe.pipex.net with SMTP (PP); Sun, 2 Apr 1995 13:26:13 +0100
  124. X400-Received: by mta EMX01.LANDP.CO.UK in /PRMD=LANDP/ADMD=ATTMAIL/C=GB/;
  125.                Relayed; Sun, 2 Apr 1995 13:25:44 +0100
  126. X400-Received: by mta ldnmail in /PRMD=LANDP/ADMD=ATTMAIL/C=GB/; Relayed;
  127.                Sun, 2 Apr 1995 13:28:13 +0100
  128. X400-Received: by mta chmail in /PRMD=LANDP/ADMD=ATTMAIL/C=GB/; Relayed;
  129.                Sun, 2 Apr 1995 13:28:13 +0100
  130. X400-Received: by mta butter in /PRMD=LANDP/ADMD=ATTMAIL/C=GB/; Relayed;
  131.                Sun, 2 Apr 1995 13:28:12 +0100
  132. X400-Received: by mta NeXT in /PRMD=LANDP/ADMD=ATTMAIL/C=GB/; Relayed;
  133.                Sun, 2 Apr 1995 13:25:44 +0100
  134. X400-Received: by /PRMD=LANDP/ADMD=ATTMAIL/C=GB/; Relayed;
  135.                Sun, 2 Apr 1995 13:28:07 +0100
  136. Date: Sun, 2 Apr 1995 13:28:07 +0100
  137. X400-Originator: bchin@landp.co.uk
  138. X400-Recipients: executor@nacm.com
  139. X400-MTS-Identifier: [/PRMD=LANDP/ADMD=ATTMAIL/C=GB/;0005100001093690000002]
  140. X400-Content-Type: P2-1988 (22)
  141. Content-Identifier: NEXTSTEP grap...
  142. From: Bill Chin <bchin@landp.co.uk>
  143. Message-ID: <9504021228.AA02682@chmail>
  144. To: executor <executor@nacm.com>
  145. Subject: NEXTSTEP graphics and SPARC port (was Re: brief status report)
  146. Reply-To: bchin <bchin@pangea.com>
  147. X-Pge: 0,barrow796825631.405.4,0,0,0
  148. Sender: owner-executor@nacm.com
  149. Precedence: bulk
  150.  
  151. [comments about NEXTSTEP port by Joshua W Burton and Clifford  
  152. Thomas Matthews removed]
  153.  
  154. Presumably the "slow" blitter for NEXTSTEP is running at the  
  155. current speed.  Right now, speed isn't my biggest concern, it's  
  156. the core emulation.  The last beta release for NEXTSTEP is dated  
  157. November '94 and does not reliably run MS-Word; it's a few steps  
  158. back from 1.30e. I'd love to see some release that brings us up to  
  159. at least the current emulation level with color.
  160.  
  161. Presumably, you need help with the Interceptor API for direct  
  162. framebuffer manipulation, bypassing the Display Postcript graphics  
  163. for faster alternative graphics engine performance.  Microsoft  
  164. calls this "advanced multimedia technology" and promotes it as a  
  165. new and exciting technology while NeXT develops it first, hides it  
  166. away and refuses to let most developers use it. _sigh_. I know  
  167. that SoftPC for NEXTSTEP, co-Xist (X11 package), and Doom II for  
  168. NEXTSTEP all use the Interceptor API.  I know Insignia got the API  
  169. officially for SoftPC, but how did the rest get it?  However, even  
  170. given official support for the Interceptor API, it is a good idea  
  171. to always have the "slow" mode as a back up.  The Interceptor  
  172. stuff is very hardware dependent and if you run across a  
  173. framebuffer type you can't handle right away, at least you can use  
  174. the slow mode to draw.
  175.  
  176. Finally, any plans for a NEXTSTEP/SPARC port?  If not, then this  
  177. is another reason to include the slow mode... I can run the app on  
  178. my mono NeXTstation with -NXHost and display it elsewhere (in  
  179. color).  I cannot do this with an Interceptor based app.
  180.  
  181. Thanks!
  182.  
  183. ..Bill Chin
  184.  
  185.  
  186.