[Prev][Next][Index][Thread]

RE: Let's get System 7.x on top!



NOTE: Dwight and I had a conversation on the telephone regarding our
plans fo r Executor in the future.  There have also been several
replies to this thread.  This post answers some of Dwights questions
and in a separate post I'll try to clarify exactly what our plans are
for the future.

>>>>> "Dwight" == Dwight W Weisman <weismand@limestone.kosone.com> writes:
In article <v02120d01ad92dea99753@[199.246.2.154]> weismand@limestone.kosone.com (Dwight  W Weisman) writes:

    Dwight> I favour implementation of MacOS overlay before a port to
    Dwight> Win95(aka Mac85).

We will embark on both simultaneously.  There are drawbacks to waiting
for the completion of either before starting the other.  However, a
port to Windows '95 is *much* easier (and less complicated legally)
and will probably finish much sooner than the drop-in feature.

    Dwight> In the first place, it still costs over $100 dollars for
    Dwight> the Win 95 upgrade here in Canada, and I already own
    Dwight> Executor, so I would rather it met my needs that expect me
    Dwight> to go out and spend more money to use it.  Incidently, yes
    Dwight> I own an unused copy of Mac OS 7.5 (Apple sent me three),
    Dwight> so that would cost me nothing to use.  Also while I think
    Dwight> that Win 95 can be grudgingly called 32-bit, the
    Dwight> appelation "native" may be a bit of a stretch.

We wouldn't not force you to upgrade to Windows '95.  We would
continue to build DOS versions of Executor and they would
automatically inherit all the bug-fixes that we make to the core of
Executor (Executor is more than 90% core, with less than 10% OS
specific features glued on).

Windows '95 has many features that Executor could potentially use with
a little bit of "glue".  Such features include better networking
support, a nice set of routines for manipulating screen memory,
QuickTime support and the ability to run multiple apps simultaneously.

Once we have Executor implemented as a Windows '95 application it's
not too unreasonable to imagine that we might make it so that when you
fired up a Mac application the application would run as a separate
Windows '95 app and leave the Browser running simultaneously so you
could fire up multiple apps just like on a real Mac, *BUT* with memory
protection and *pre-emptive* multiprocessing.  That feature just
wouldn't be available under DOS because DOS doesn't have nice
provisions for this feature.

    Dwight> A second consideration is memory.  Executor likes lots,
    Dwight> DOS needs very little, Win 95 needs LOTS.  Thus if we are
    Dwight> forced to use a W95 port we have to expec to use more
    Dwight> memory (and faster processors - there are still some
    Dwight> people out there running executor on 386's and 486/33's -
    Dwight> no good for W95).

Right.  You wouldn't be forced to use Windows '95, you just might not
be able to use some features under the DOS version.  In the
hypothetical example above, perhaps the Windows version would support
multiple apps running simultaneously.  If we *do* add that feature
soon, it's a feature that would require extra memory anyway.

    Dwight> Lastly, if W95 is an effective replacement for a DOS/WIN
    Dwight> environment (aka a real system upgrade) then it should run
    Dwight> the DOS version of Executor -- NO IFS, NO BUTS, NO MAYBES
    Dwight> -- if not, complain to Microsoft, not to ARDI.

True.  The problem isn't that W95 can't do everything DOS can as much
as DOS not being able to do everythin W95 can.

    Dwight> An implementation of Executor, that accepts a Mac OS
    Dwight> overlay (or is just a hell of a lot more sys 7 like) tha
    Dwight> can then be ported to all existing platforms (and yes I
    Dwight> suppose at some point W95) is a more valuable use of time
    Dwight> and resources than a W95 port.  One of the reasons that
    Dwight> ARDI has upheld for not making their product _dependent_
    Dwight> on a Mac OS overlay (or ROMS) is that it would then force
    Dwight> us to buy those items at additional cost to us.

The primary reason we haven't done this so far has been that it is a
very expensive undertaking.  The legal requirements are sufficiently
high that we simply didn't have the resources to do this so far.  I do
think that greater compatibility with MacOS is a good thing to aim for
and it's something we will pursue almost immediately after releasing
Executor 2 (there will actually be a period during which we add no new
features and do little bug-fixing while we restructure Executor's
source so that future bug fixes and ports will be easier).

    Dwight> Now, I assume that there are a lot of registered owners of
    Dwight> the _DOS_ version that already own Win 95.  However the
    Dwight> key element here is _DOS_.  I paid for a DOS application
    Dwight> (emulator) not a Win 95 app.  For ARDI to turn around and
    Dwight> say that implementing another platform is more important
    Dwight> that providing me with a better product would be a very
    Dwight> bad move.  I would be more than tempted to request a
    Dwight> refund.  I suspect that Linux and Next users would agree.

We do not intend to drop Executor/DOS in the near future.  The
possibility that some features would be implemented on one platform
before another shouldn't be foreign to readers of this newsgroup or
even readers of our FAQ.  For instance:

-------------------------------------------------------------------------------

Question 1.28.  Does Executor have networking support?

Currently, no.  Nor, will it be available in Executor 2.  Networking
support is planned for release 3, but we do not yet have an estimated date
of completion for Executor 3.  The first platform to have networking
support built in will probably be Linux.

-------------------------------------------------------------------------------

In the answer to the above question it should be clear that some types
of functionality will appear on some OSes before others.  However,
later today I'll draft a policy statement that will make things very
clear so there will be no misunderstandings (on this issue, at least)
on this issue.

--Cliff
ctm@ardi.com




Follow-Ups: References: