home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text2455.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  8.3 KB  |  180 lines
  1. There has been a bit of discussion regarding what ARDI will be doing
  2. once Executor 2 is released.  For people who haven't followed all our
  3. responses, here's an explanation of our plans for Executor 2 and
  4. beyond.
  5.  
  6. Upgrades:
  7.  
  8.     All Executor 1.x licensees will receive an Executor 2 CD-ROM
  9.     sent to them free of charge.  This includes Executor/NEXTSTEP
  10.     users.  The rumor that we would drop NEXTSTEP support before
  11.     Executor 2 came out is FALSE.
  12.  
  13.     In addition, all Executor 1.99<x> licensees (i.e. people who
  14.     licensed Executor within the last year or two, but excluding
  15.     people who licensed Executor 1.0, 1.1 or 1.2) will also get
  16.     whatever free upgrades that we offer to Executor 2 licensees
  17.     during the first two months that Executor 2 is released.  We
  18.     don't yet know what our upgrade policy will be for Executor 2,
  19.     but whatever it is, 1.99<x> licensees will automatically get
  20.     it.
  21.     
  22. Development:
  23.  
  24.     All the material in this ("Development:") section is subject
  25.     to change.  ARDI is currently a small company but we do not
  26.     plan to remain small.  Some of what is described here will
  27.     require more engineers than ARDI currently employees.  We're
  28.     assuming that we'll sell more copies of Executor 2 when it's a
  29.     finished product than we've been selling to date, although
  30.     that is not a given.  If we can't support ourselves through
  31.     Executor 2 sales we'll seek funding elsewhere, but that could
  32.     cause some delays.
  33.  
  34.     After Executor 2 ships, ARDI will spend approximately one
  35.     month restructuring our existing code.  Executor is much
  36.     cleaner than most commercial software I've worked on (I was a
  37.     freelance software contractor in the early days of Executor as
  38.     well as before then), but to be maximally efficient when we
  39.     hire new engineers we need to clean up and restructure our
  40.     code.  This is no big deal, but it will allow us ARDI
  41.     engineers to catch our breath and even do some brainstorming
  42.     before going back to the implementation/bug-fix grind.
  43.  
  44.     Beyond the restructuring we'll be working in many different
  45.     areas in parallel (in alphabetical order):
  46.  
  47.     Compatibility with apps -- Many programs still die for mysterious
  48.     reasons.  We'll continue to look into and solve mystery crashes.
  49.  
  50.     Compatibility with extensions -- Our goal will be to support
  51.     INITs and CDEVs, *especially* ATM and QuickTime.  Some of the
  52.     work done in this area will be the beginnings of support for
  53.     System 7.5 drop-in capability.
  54.     
  55.     Intermachine communication -- Support for serial ports and
  56.     networking will be added.  We plan to leverage off of existing
  57.     OS support to do this, instead of writing our own low-level
  58.     drivers.
  59.  
  60.     Multitasking -- We plan to add both support for multi-tasking
  61.     within a single address space, at least enough to allow Word 6
  62.     and Excel 5 to run and also piggy-back on top of existing OS
  63.     support for multi-tasking under separate address spaces
  64.     (i.e. set things up so that when one app dies others will
  65.     continue to run).
  66.  
  67.     Ports to other OSes -- Tentatively it looks like we will port
  68.     Executor to Win32 (for Windows '95 and Windows NT) and OS/2.
  69.  
  70.     PowerPC emulation -- Mat has already done significant work on
  71.     a successor to Syn68k which will allow us to emulate the PPC
  72.     as well as the 68k and do so faster than Syn68k does.  The
  73.     successor is internally known as VCPU and it should also allow
  74.     us to port to non-x86 architectures more easily so that if
  75.     we're ever financially motivated we could (re)port Executor to
  76.     the Alpha or take advantage of the "native instruction set"
  77.     the P7 is rumored to sport.
  78.  
  79.     Working with ISVs -- A few Macintosh Independent Software
  80.     Vendors have expressed interest in using a bundled
  81.     "wrapperized" Executor to allow them to sell their Mac apps in
  82.     the Windows world.  We will pursue this to the degree that the
  83.     ISVs are willing to pay for the wrapperization work.  With
  84.     luck we can get extra funding for core Executor work from
  85.     royalties coming from bundled versions of Executor.
  86.  
  87. Supported OSes:
  88.  
  89.     All the material in this ("Supported OSes:") section is subject
  90.     to change for the same reasons why the material in the
  91.     previous paragraph is subject to change.
  92.  
  93.     NEXTSTEP has not been a viable operating system for
  94.     Independent Software Vendors for a long time now.  AppSoft,
  95.     ITS, Millenium, Pages, RightBrain, Xanthus and many other ISVs
  96.     have all bowed out of the NEXTSTEP market.  We will release
  97.     Executor 2 for NEXTSTEP but that very well may be our last
  98.     major release for NEXTSTEP.  Everything I know about the
  99.     NEXTSTEP marketplace suggests that it's time for us to leave,
  100.     but that decision won't be officially made until after
  101.     Executor 2 has been released so that the remaining powers in
  102.     the NEXTSTEP community can see what we've done so far and see
  103.     where we're going and point out market possibilities that we
  104.     may have missed.
  105.  
  106.     After Linux 2.0 is released we may consider dropping a.out
  107.     support in Executor.  Clearly a.out is on its way out although
  108.     we don't know whether we'll need to continue supporting it for
  109.     a year or five years.  I believe support for Linux ELF is
  110.     being worked into NetBSD, FreeBSD and BSDI, but if I'm
  111.     mistaken and they remain only able to run Linux a.out files
  112.     then we won't drop a.out support.  Unlike the NEXTSTEP
  113.     situation where we're likely to drop support for NEXTSTEP
  114.     soon, we're *not* planning on doing that with a.out (Linux 2.0
  115.     is still a ways away, I believe).  I am mentioning a.out
  116.     support here because it is something that will probably be
  117.     dropped at some point.
  118.  
  119.     DOS support will continue after Executor 2 is released and
  120.     Executor/DOS will probably directly benefit from our
  121.     "Compatibility with apps", "PowerPC emulation" and some of our
  122.     "Compatibility with extensions", "Intermachine communication"
  123.     and "Multitasking" work.  However, some of the work in these
  124.     areas is less likely to appear in Executor/DOS due to DOS's
  125.     limitations.  QuickTime support, Networking support, and
  126.     support for Multi-tasking in separate address spaces are
  127.     unlikely to be incorporated to Executor/DOS; DOS is just too
  128.     primitive to easily support those features.
  129.  
  130.     In all liklihood our major development efforts will be put in
  131.     Executor/Win32 (that's where the money appears to be) and
  132.     Executor/Linux (that's the OS we like).  On the other hand, if
  133.     Executor/OS-2 winds up being commercially successful we
  134.     definitely won't rob its revenue stream; we'll pump some
  135.     fraction of the profits into OS/2 specific enhancements and no
  136.     fraction of the OS/2 profits into Win32 or Linux specific
  137.     enhancements.  Most of the profits from all versions will go
  138.     into core work because Executor is > 90% core.
  139.  
  140. Reiterating one more time, to make a point, all the information above
  141. except for our Upgrade policy is subject to change.  Anyone who has
  142. tracked ARDI for a considerable amount of time will have noticed that
  143. we *haven't* been able to meet the timetables that we've set for
  144. ourselves in the past.  Almost all of this has been due to a lack of
  145. money -- it was *very* hard to get where we were with the budget we
  146. had.
  147.  
  148. When the bottom fell out of the NEXTSTEP market, it hit us hard.  When
  149. we thought we had lined up external financing and decided to rely on
  150. that rather than Executor 1.x sales to fund Executor 2, only to find
  151. out that the company that was to fund us wasn't serious, that too hit
  152. us hard.
  153.  
  154. Hopefully after Executor 2 ships we will have a larger budget to work
  155. with, either due to Executor 2 sales or due to the ability to acquire
  156. financing based on Executor 2's promise.  Although we haven't been
  157. able to do things in the timeframe that we've tried in the past, we
  158. *have* done most of the things we claimed we would (color, sound, our
  159. own Finder, dramatic speed improvements, increased compatibility), so
  160. there really is a good reason to believe we can do the above, at least
  161. if the market says we should have money.
  162.  
  163. We're very honest at ARDI.  I am serious when I say that all the major
  164. decisions will officially be made after Executor 2 ships.  For that
  165. reason I suggest that anyone wanting to provide us with suggestions
  166. for our post Executor 2 activity should wait until *AFTER* Executor 2
  167. is shipping.  We'll be much less harried and much more open to
  168. suggestion after Executor 2 is shipping.
  169.  
  170. Thank you for your interest.
  171.  
  172. --Cliff
  173. ctm@ardi.com
  174.  
  175. [This was cross-posted to c.s.n.a. since there has been a little
  176. traffic there concerning our declining support for E/NS.  For people
  177. not familiar with Executor, http://www.ardi.com provides more
  178. information]
  179.  
  180.