Executor 2.0/executorv2.0.iso/pc/linux/extra/docs/maillist/text/archive.94/text0138.txt

Text File | 1996-04-02 | 8.2 KB | 209 lines

Hi Folks,

After getting the Executor/DOS 1.99b demo out I slept, and slept and
slept and slept.  Now I'm awake and am about to put together the
commercial E/D 1.99b version out as well as the demo E/Linux 1.99b
and even an Executor/NEXTSTEP 1.99b.  However, let me answer a few
questsions now, before my e-mail gets too piled up.

Once the demo fits nicely onto two 1.4 Mb disks I'll make the demo
much more widely available and post many more pointers on various
related newsgroups.  Hopefully this will happen before Sunday, since
I leave for a brief (one week) vacation to Chile on Sunday.  BTW, if
any Executor users are in Santiago and would like a chance to chat,
let me know ASAP, but be prepared to speak English or Ameslan -- my
Espan~ol is *very* rusty.

Here are a few things that you may not be aware of:

    Control-BREAK under Executor/DOS will *usually* break you out
        of Executor.  There are still a few cases where this
        doesn't work and we're trying to find and fix them.

    Refresh is used for programs that write directly to the
        screen.  In this mode, programs write to an offscreen
        representation of the screen and then every "n" ticks
        (sixtieths of a second) the offscreen representation
        is copied to the physical screen.

    If you use "-macbpp 1 -realbpp 1" or "-macbpp 8 -realbpp 8"
        you don't need to use the refresh option for programs
        that write directly to the screen, since Exector will
        allow your app to write directly to the screen
        without needing a shadow buffer.  NOTE: 4 bpp is the
        default, and programs can't write directly to the
        screen in 4 bpp, because on a PC, 4 bpp is "planar"
        instead of "chunky".

    Direct Disk Access is only needed for programs that access
        the hard disk in a "raw" fashion -- Nortion Utilities
        for example.  It's best left off for "normal"
        applications.

    Flush Cache Often is (to the best of our knowledge) only
        needed for "Lemmings".  Lemmings depends on
        side-effects from certain system calls that we can
        mimic, but only at a price.

    Cache Heuristics isn't needed at all -- it was put there in
        anticipation of some hacks that I thought we'd need
        to implement to get HyperCard to be speedy, but the
        mods were sufficiently unobtrusive that we just
        run with them on all the time.

Here are a few bugs that were noted in 1.99a that have already been
fixed in 1.99b:

    Alt-shift-1 saying 1.30

    Stuffit not working

    Microsoft Word not working

Here are problems we're still working on:

    Alternate screen sizes:  Executor/X-Windows/Linux and
        Executor/NEXTSTEP both should trivially be able to
        support alternative screen sizes, although currently
        they can't.  In addition, most VESA compliant SVGA
        cards should also be able to support higher
        resolutions than the 640x480 that we currently
        implement.  These fixes will come in two stages:
        the ability to switch when Executor is first
        started should be working fairly soon.  The ability
        to dynamically switch may not happen until after
        2.0 is released.

    Crystal Quest demo dies after completing a level if run with
        bpp > 1.  We're looking into this one.  Strangely,
        there are other versions of CQ that do not show this
        behaviour.

    NIH Image 1.55 says complains about creating NewGDevice:
        We've made some progress on NIH image, but it even
        in 1.99b it trys to use a system call that we don't
        yet support.  NIH Image is a power-user of 32-bit
        Quickdraw, so it's taking us some time to get it
        going, but we don't see anything insurmountable
        (yet).

    Having the HFS_XFer window come to the forefront anytime the
        HFS_XFer menu item is chosen (under the Apple menu):
        Good idea -- I'll try to put that code in soon.

    Spectre 1.0 runs, but the colors are wrong:  we know why, but
        haven't put in the code to fix it yet.

    Other incorrect colors:  Some programs still produce grossly
        incorrect colors.  These errors need to be fixed
        ASAP.

    A refresh-screen FKEY (Control-alt-digit):  We hadn't thought
        of this, but Kurt Glaesemann suggested this and many
        other useful things.  This one is simple enough that
        we should be able to slip it into an upcoming
        release.

    The ability for Executor to switch screen depths through
        software.  We know how to implement this, but haven't
        gotten around to it yet.  This one's fairly low
        priority, but will probably be done before we release
        2.0.

    When not in 8 bits per pixel mode, some screen accesses are
        not properly done.  This is why the Eject button
        looks weird in 1 bpp and why the speedo gauages don't
        appear in 1 bpp or 4 bpp.

    1000 miles weirdness:  Thanks to Jacques Pannetier's
        observations and some new debugging tools, I suspect
        this bug will be fixed "soon" (within a month),
        although it's fairly low priority.

    Grow zone problems:  Yes, as Kurt has pointed out, many
        Claris programs draw grow zone lines inappropriately.
        Since this doesn't actually cause programs to crash,
        we haven't been particularly aggressive in fixing
        this bug, but it is sufficiently annoying that I'll
        try to get someone to look at it within the next
        couple of weeks.

Here are some suggestions that are quite good, but are lower priority
than the items mentioned above:

    Other incorrect colors:  Some color differences are really
        reflections of the differences in monitors.  The Mac
        has built-in support for "Gamma correction" to
        address this issue.  Although this is an important
        issue, it's not as important as getting more apps to
        be usable, so it has to wait until 2.0 is out before
        we can do anything about it.  Even then, it's a very
        tough issue to address without some help from the
        hardware manufacturers.

    Scrapbook DA:  I'll try to find an existing one and get it to
        work (send suggestions to [e-mail]), but if I
        can't find one, the person to write one will probably
        be Bill Goldman, and he's busy writing our Finder
        replacement.

    Keycaps DA:  same comment as Scrapbook, although Keycaps is
        lower priority.

    Browse option in file dialog boxes: we need to get more
        applications running before we can add this
        functionality.  Sorry.

    Built in support for binhex when moving files from the Mac
        side to the DOS side:  This is a good idea, although
        another possibility is to support Apple Single.
        Again, this solution takes a backseat to getting 2.0
        out (i.e. more applications running), but it's a
        high priority.

    A cool OS/2 and Windows Icon:  We need these things and we
        also need decent icons for our soon to be released
        file browser.  Our file browser has such PITIFUL
        icons (no offense, Bill) that we're hopeint to
        inspire some student effort to help us clean up.
        We have a nice Executor/NEXTSTEP icon that we may be
        able to modify for E/DOS, but we're waiting to see
        what gets thrown at us for free after E/D 1.99x is
        more widely available.

    System 7 compatibility:  One of the functions of 2.0 that
        we've had to back off on (others include sound and
        Windows interoperability) is System 7 support.  We
        know what system 7 functions we'd like to add, but
        after our most recent trip to Apple, it may make
        sense for us to make it so that Executor will allow
        you to add System 7 and automatically get a much
        greater degree of compatibility than Executor without
        System 7 from Apple.  That may make work on System 7
        now be redundant.  We're still researching this
        issue.

    The ability to easily modify file type and file creator:
        Once we've released our file browser, that is a
        logical addition.  Since we'll be releasing the
        source to our file browser, we expect a few mods
        to be made by Executor enthusiasts who just like
        to help out.  After it's been out and all bugs
        cleaned up, we'll prioritize a list of mods and
        start making them.  This timetable is independent
        of the release of 2.0, so this feature could be
        ready before 2.0 ships.

    HFS_XFer bugs:  Some of these have already been fixed, but
        we won't be releasing anything new until our file
        browser comes out.

BTW, if you've gotten this far, and are not a registered user, you
obviously care enough about our product to be worthwhile to talk to.
Although our official policy is not to provide tech. support to non
registered users, we'll gladly accept bug reports from anyone, the
more informed, the better.

    --Cliff