Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.95/text5517.txt

Internet Message Format | 1996-03-31 | 22.7 KB

Received: from tin (tin.monsanto.com [137.35.4.90]) by nacm.com (8.6.10/8.6.9) with SMTP id JAA00105 for <[e-mail]>; Tue, 17 Oct 1995 09:24:46 -0700
Received: from ccgw2dtmp.monlan.com by tin (5.65/Monsanto1.7)
    id AA21776; Tue, 17 Oct 1995 11:24:41 -0500
Received: from cc:Mail SMTPLINK 2.1 by ccmail.monsanto.com
    id AA813948735; Tue, 17 Oct 95 09:20:28 cst
Date: Tue, 17 Oct 95 09:20:28 cst
From: "Administrator" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Message not deliverable
Sender: [e-mail]
Precedence: bulk


executor-digest           Monday, 16 October 1995      Volume 01 : Number 301


  In this issue:

 Re: [ANNOUNCEMENT] 1.99p3 is out + status report
 Re: [ANNOUNCEMENT] 1.99p3 is out + status report
 1.99p3 & KalediaGraph(sp?)
 Re: [ANNOUNCEMENT] 1.99p3 is out + status report
 [none]
 Re: [ANNOUNCEMENT] 1.99p3 is out + status report
 Re: [ANNOUNCEMENT] 1.99p3 is out + status report
 MS Word save dialog works again in 1.99p3
 Canvas 2.0 almost works!
 Re: [ANNOUNCEMENT] 1.99p3 is out + status report
 BeBox Port??????
 Re: netatalk-style resource forks? (please? :)
 Future of ARDI in general (was Re: BeBox Port??????)
 Re: Canvas 2.0 almost works!
 Re: netatalk-style resource forks? (please? :)
 Re: executor-digest V1 #300
 commands
 menu
 Long filenames

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

From: [e-mail] (Clifford T. Matthews)
Date: Sun, 15 Oct 95 19:53 MDT
Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report

>>>>> "Fred" == Fred Salerno <[e-mail]> writes:

    Fred> Is sound really that hard of a problem to conquer?

No, but it would delay 2.0's release.  Right now we have four people
working incredibly long hours for a company with limited funds that
loses money every single month.  We can not do this indefinitely and,
in fact, it's in nobody's best interest to do so.

Once 2.0 is shipping we can hire more engineers and get things done so
much quicker that many tasks (including sound) will be completed
sooner by getting 2.0 out first and then hiring people than if we just
delayed 2.0 the additional time it would take to do the work with our
current resources.

- --Cliff
[e-mail]


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

From: Chad Page <[e-mail]>
Date: Sun, 15 Oct 1995 20:00:01 -0700 (PDT)
Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report

On Sun, 15 Oct 1995, Clifford T. Matthews wrote:

> If you've already installed 1.99p, I hope you can pick up 1.99p3 and
> test it against any applications you'd like to see run under 2.0 (be
> reasonable, sound and QuickTime will definitely not be supported).
> Then, send us bug reports about the largest problems you see.

 Sounds good!  I'm finally glad to see 2.0 coming out RSN!

 I'm going to give Pagemaker 4.2 another look-over (I really want
it to work sometime - some versions are closer than others, but I've
never seen one which runs it well... yet.)

 By the way, I've been lurking for a while, but I have picked up
Linux/SVGAlib and it lived up to my expectations (very fast :) - I'd like
to see it support VC switching better, but I love the speed - it's just
like a real Mac!  Executor/Linux has gotten *so* much better since the
first releases!  (And the later DOS versions - which I don't keep up with
as much anymore, are so much better than 1.2x, too :)

 I hope to see 2.0-release out soon... it's been a long journey.

 - Chad

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

From: [e-mail] (Michael R. Lewis)
Date: Mon, 16 Oct 1995 01:20:57 -0400
Subject: 1.99p3 & KalediaGraph(sp?)

I've been trying to run KalediaGraph (non math-co version) since I first saw
Executor in version 1.2. In previous versions it just gave me an out of
memory message. (This was parcular because the version I have runs on an LC
II with 2 MB of RAM). Now, the program loads up the title screen and the
computer freezes. There are no other errors the computer just freezes. It
could be a problem with my OS (WIN '95, in DOS mode). but I can't tell. I'm
running on a Pentium-100 with 16 MB RAM,Diamond Stealth Video VRAM with 2 MB
VRAM.

Thanks in advance for your help.
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&  Michael R. Lewis        e-mail: [e-mail]        &
&  BU Box 3163                 or: [e-mail] &
&  700 Commonwealth Ave.    phone: [phone]        &
&  Boston, MA 02215                                      &
&                                                        &
&  WWW: http://nyx10.cs.du.edu:8001/~milewis/home.html   &
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&


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

From: Ben Lindstrom <[e-mail]>
Date: Mon, 16 Oct 1995 01:16:23 -0500 (CDT)
Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report

On Sun, 15 Oct 1995, Fred Salerno wrote:

> Is sound really that hard of a problem to conquer?
>
>From a Linux/NeXT point of view no.   Since it's just a standard driver
for all sound cards. From a DOS standpoint...I'm unsure. I would bet it would
take a little code. It might not  be a BAD idea to implement sound  on
Linux/NeXT in the Hackathon II so it would be easier to implement it
under DOS.

(BTW, Windows/Windows95 would also be easy since it's like  Linux/NeXT..A
perfectly standardized API)

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

From: Daniel Perzynski <[e-mail]>
Date: Mon, 16 Oct 1995 10:26:21 +0100 (MET)
Subject: [none]

get executor

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

From: [e-mail] (Josh Vanas)
Date: Mon, 16 Oct 1995 10:05:33 -0400
Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report

>
>NOTE: I was not able to reproduce the slowdown that occurs when some
>people open DOS drives under E/D.  Mat did make some modifications to
>our interrupt code, so there's a slight chance that the mods speed
>things up.  I will send more e-mail about this particular problem
>later.
>
>--Cliff
>[e-mail]
>

I just installed 1.99p3 E/D.  The DOS drives still take 3 to 4 minutes to re
the root folder to come up.  This only happens in Win95 running in DOS full
scrteen mode.  If I boot straight to DOS 7.0 (no Win95 interface), the
problem does not exist!  I hope this makes your list of things that need
fix'n for the Hackathon.

- -Josh


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

From: [e-mail] (Josh Vanas)
Date: Mon, 16 Oct 1995 12:23:03 -0400
Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report

>>We're using some new code to handle Win95 long file names.  The
>slowdown you noticed may have appeared with the introduction of that
>code.  Can I send you a test Executor with that code removed to see if
>it still has the problem?
>
>-Mat
>

Sure. If you can send it as an attachment to an e-mail, that would be fine.
I'll try it out today and get back with you.

- -Josh


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

From: root <[e-mail]>
Date: Mon, 16 Oct 1995 12:34:10 -0400
Subject: MS Word save dialog works again in 1.99p3

I just tried out 1.99p3, and the save-dialog bug for MS Word 5.1 that was
introduced in p2 seems to be gone again.  Thanks!

 Jim

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

From: Tom Bartol <[e-mail]>
Date: Mon, 16 Oct 1995 09:54:43 -0700 (PDT)
Subject: Canvas 2.0 almost works!

Hi,

Just wanted to make a quick report on E/L 199p3.  I've just tried
Filemaker Pro 2.0 and it works beautifully (no more corrupted files and I
can read in my big research tracking data base).  Also, Canvas 2.0 (an old
version, I know) almost works!!  It fires up and and I see what appears
to be a flawless new document with tools but then it crashes executor
suddenly with the following error message...

executor: XError `8': BadMatch (invalid parameter attributes)
X_CreateCursor

I'm going to try to install Canvas 3.5 later today and cross my fingers...

Tom




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

From: Fred Salerno <[e-mail]>
Date: Mon, 16 Oct 1995 13:40:01 -0400 (EDT)
Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report

And I suppose a DOS version wouldnt be so bad since most cards support
the "Sound Blaster 1.0" settings... but theres all kindas configurations.

On Mon, 16 Oct 1995, Ben Lindstrom wrote:

>
>
> On Sun, 15 Oct 1995, Fred Salerno wrote:
>
> > Is sound really that hard of a problem to conquer?
> >
> >From a Linux/NeXT point of view no.   Since it's just a standard driver
> for all sound cards. From a DOS standpoint...I'm unsure. I would bet it would
> take a little code. It might not  be a BAD idea to implement sound  on
> Linux/NeXT in the Hackathon II so it would be easier to implement it
> under DOS.
>
> (BTW, Windows/Windows95 would also be easy since it's like  Linux/NeXT..A
> perfectly standardized API)
>

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

From: Kurt R Glaesemann <[e-mail]>
Date: Mon, 16 Oct 1995 13:11:48 CDT
Subject: BeBox Port??????

I think I will jump the gun (Ok, how about a whole army of guns) and ask.

A new dual CPU PowerPC computer has popped up called the BeBox.  It has very
little software since it was designed from the ground up with no backwards
compatability (see http://www.be.com/).  This would be a good market for
executor since the'll be a dearth of software in the begining (not to
mention that the box's look pretty powerful.  I could just see it now "I own
a PowerPC computer that run's mac apps, but not the native ones!!":  proof
that truth can be stranger than fiction.


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

From: Brad Midgley <[e-mail]>
Date: Mon, 16 Oct 1995 11:05:48 -0600 (MDT)
Subject: Re: netatalk-style resource forks? (please? :)

hello...

desktop representation is out of the question (too different for everybody),
but executor should at least put its resource forks in a subdirectory without
mangling the name. Other schemes could depend on softlinks to that directory.
(would only have to be fixed up when folders were created) Mangling the name
in the current directory is ugly.

The easy road to get executor to deal with a network on a netatalk-supported
host will be to depend on kernel DDP and link in the netatalk libs.  so why
not use a compatible naming scheme now and avoid the headache later?

btw, ardi's bugs/feedback page is broken.  anyone there?

On Thu, 12 Oct 1995, David E. Hollingsworth wrote:

> In article <[e-mail]> Brad Midgley <[e-mail]> writes:
> >   I'm not sure if this has come up yet, but since executor doesn't have
> >   network support, could it at least support the netatalk method of keeping
> >   resource forks in a .AppleDouble directory?  (how about a non-defaulted
> >   command-line option?)
>
> Of course, CAP aufs uses .resource directories, Helios EtherShare and IPT
> uShare use .rsrc directories, Xinet KA-Share uses .HSResource directories, and
> Pacer PacerShare uses afp_resource directories.
>
> There are corresponding differences for desktop representation.  Many of these
> systems also appear to have files or directories for storing finder
> information.  Fun, eh?

[e-mail]




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

From: [e-mail] (Clifford T. Matthews)
Date: Mon, 16 Oct 95 13:08 MDT
Subject: Future of ARDI in general (was Re: BeBox Port??????)

>>>>> "Kurt" == Kurt R Glaesemann <[e-mail]> writes:

    Kurt> I think I will jump the gun (Ok, how about a whole army of
    Kurt> guns) and ask.

    Kurt> A new dual CPU PowerPC computer has popped up called the
    Kurt> BeBox.  It has very little software since it was designed
    Kurt> from the ground up with no backwards compatability (see
    Kurt> http://www.be.com/).  This would be a good market for
    Kurt> executor since the'll be a dearth of software in the
    Kurt> begining (not to mention that the box's look pretty
    Kurt> powerful.  I could just see it now "I own a PowerPC computer
    Kurt> that run's mac apps, but not the native ones!!": proof that
    Kurt> truth can be stranger than fiction.

We've read about it and we're fairly interested, even though future
BeBox machines will be CHRP compliant and as such will theoretically
be able to run MacOS once Copland is released ('97 at best -- we're
not the only one who slips release dates of major new versions).

It turns out that Mat has been working on a successor to syn68k for a
while.  The successor will make writing different backends much easier
and should also be able to use different front ends.  Additionally,
the code that the successor generates will be much faster than what
syn68k generates.  A PPC backend has already been written for this new
synthetic CPU, so we've planned on putting Executor on the PPC for a
while now.

However, when we get Executor to run on the PPC, we'll also support
native PPC apps since adding that support should actually be fairly
easy, so the "but not the native ones" disclaimer will probably not
apply for any amount of time greater than three or four months, if
ever.

But Mat's syn68k successor can also have different front-ends, so our
plan is to allow Executor to run PPC Mac apps on non-PPC machines as
well.

So, when 2.0 is shipping and we have some extra dollars, we'll
*probably* pick up a Be Box and do an internal proof of concept port.
We don't expect Be to be particularly interested in our work because
eventually they'll have Copland and in the meantime, using ARDI's
technology is overkill, since they could also just as easily get some
clever engineers like Jim Drew, the Quix engineers, the author of
ShapeShifter, or half a dozen other people/teams who could get Mac
programs to run under the BeOS -- a simple task when compared to what
we do.

There would be a couple slight differences though.  Executor would of
course be running totally native on the PPC, while Copland will still
have portions running under emulation and with any Apple based port of
the Mac OS, Apple would play a significant role in determining the
price of the ported OS, while we could set the Executor/Be price to be
fairly low if Be decided they liked our work enough to bundle it with
every machine they shipped.

Right now people who think of SoftWindows when they think emulation
technology in general, or who think of Executor 1.2 or even 1.99<x>
where <x> < 'p' probably don't have a particularly good opinion of
emulators.  We will try very hard to change people's mind with 2.0's
release.  If we convince only a tiny fraction of our potential
customer base that we're worth taking a chance on, then the resultant
revenues will enable us to make the next release of Executor after 2.0
have at least as much improvement as you've seen between 1.99k and
1.99p3.

- --Cliff
[e-mail]

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

From: [e-mail] (Clifford T. Matthews)
Date: Mon, 16 Oct 95 12:46 MDT
Subject: Re: Canvas 2.0 almost works!

>>>>> "Tom" == Tom Bartol <[e-mail]> writes:

    Tom> Hi,

    Tom> Just wanted to make a quick report on E/L 199p3.  I've just
    Tom> tried Filemaker Pro 2.0 and it works beautifully (no more
    Tom> corrupted files and I can read in my big research tracking
    Tom> data base).

Yay.  It turns out that Filemaker Pro is the only app in a year and a
half to have failed due to a bug in Mat's synthetic CPU.  I have
actually tried to figure out the corruption file several times
previously but it was only through luck that I happened to run
Filemaker Pro with a debugging version of the synthetic CPU.  When I
did, Filemaker Pro worked.  It took me a while to figure out that the
difference was due to different versions of syn68k, but once I knew
that, Mat very quickly found and fixed the first syn68k bug (that I
can remember, at least) in a year and a half.

    Tom> Also, Canvas 2.0 (an old version, I know) almost
    Tom> works!!  It fires up and and I see what appears to be a
    Tom> flawless new document with tools but then it crashes executor
    Tom> suddenly with the following error message...

    Tom> executor: XError `8': BadMatch (invalid parameter attributes)
    Tom> X_CreateCursor

    Tom> I'm going to try to install Canvas 3.5 later today and cross
    Tom> my fingers...

Hmmm... I'm not sure what's causing the BadMatch error, but I suspect
that you're going to get a "m68k pc jumped to 0!" death with Canvas
3.5, since we were getting that with a demo version of 3.5.2.  We
fixed that bug and a couple other Canvas related bugs, but those fixes
won't be out until 1.99p4.

    Tom> Tom

Mat is still fighting with the bug that makes Executor unstable under
Windows 3.x, and we're also still trying to figure out the slowdown
when opening DOS drives under Windows '95.  When we make substantial
progress on those two, we'll release 1.99p4 which has fixes that make
Executor work better with Canvas 3.5.2, HyperCard 2.3 built
stand-alone applications, Quark XPress 3.5 and more that I can't think
of.

- --Cliff
[e-mail]



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

From: [e-mail] (Clifford T. Matthews)
Date: Mon, 16 Oct 95 13:37 MDT
Subject: Re: netatalk-style resource forks? (please? :)

>>>>> "Brad" == Brad Midgley <[e-mail]> writes:

    Brad> hello...  desktop representation is out of the question (too
    Brad> different for everybody), but executor should at least put
    Brad> its resource forks in a subdirectory without mangling the
    Brad> name. Other schemes could depend on softlinks to that
    Brad> directory.  (would only have to be fixed up when folders
    Brad> were created) Mangling the name in the current directory is
    Brad> ugly.

The problem is that the Apple Double spec. is an incredibly bad
specification, but rather than go our own way, we adhere to it.  There
are actually a few other Mac connectivity tools that adhere to the
spec. as written and Executor will interact with them correctly (off
the top of my head I think InterCon has a product that does this and I
think Paul Hargrove's HFS Linux filesystem can create in-spec
AppleDouble names).

    Brad> The easy road to get executor to deal with a network on a
    Brad> netatalk-supported host will be to depend on kernel DDP and
    Brad> link in the netatalk libs.  so why not use a compatible
    Brad> naming scheme now and avoid the headache later?

Yes and no.  We could make a very quick hack to support the netatalk
style names and have considered doing it at least for our own internal
use (Cotton uses netatalk) but have so far resisted.  I think Cotton
plans on writing a little script that will recursively convert a
directory and its children in either direction between the netatalk
naming convention to the AppleDouble naming convention.  That will be
useful to him and perhaps to many of you out there as well.

Internally Executor and netatalk both use the AppleDouble file format;
it's only the naming where they deviate from the spec.

    Brad> btw, ardi's bugs/feedback page is broken.  anyone there?

Send e-mail to "[e-mail]" and cc it to "[e-mail]" with
more detail and we'll get it fixed ASAP.  We have received a few bug
reports here and there so we assumed it was working.

    Brad> On Thu, 12 Oct 1995, David E. Hollingsworth wrote:

    >> In article
    >> <[e-mail]> Brad
    >> Midgley <[e-mail]> writes: > I'm not sure if this has
    >> come up yet, but since executor doesn't have > network support,
    >> could it at least support the netatalk method of keeping >
    >> resource forks in a .AppleDouble directory?  (how about a
    >> non-defaulted > command-line option?)
    >>
    >> Of course, CAP aufs uses .resource directories, Helios
    >> EtherShare and IPT uShare use .rsrc directories, Xinet KA-Share
    >> uses .HSResource directories, and Pacer PacerShare uses
    >> afp_resource directories.
    >>
    >> There are corresponding differences for desktop representation.
    >> Many of these systems also appear to have files or directories
    >> for storing finder information.  Fun, eh?

    Brad> [e-mail]

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

From: [e-mail] (Pat Gunn)
Date: Mon, 16 Oct 95 15:51:09 EDT
Subject: Re: executor-digest V1 #300

>From: Fred Salerno <[e-mail]>
>Date: Sun, 15 Oct 1995 20:59:33 -0400 (EDT)
>Subject: Re: [ANNOUNCEMENT] 1.99p3 is out + status report
>
>Is sound really that hard of a problem to conquer?

As a programmer, I can say that sound is one of the most annoying things to program
because you either use the lowest common denominator (like a SB8) or you spend weeks writing
seperate routines for every card you intend to support....
- ---------------------------------------------------
Pat Gunn, of Team OS/2, Libertarian party, and the Internet.
"And thus came the great god known as Emacs, and with him
came Neko, the forgotten one" Geek Code Follows:
Version: 3.1
GCS/IT d? s+:-- a? C+++$ ULSX++>$ P+? L++>$ E+>$
!W(+)>$ N++>$ o? K--? !w---$ O++$ M+(++)>$ V--
PS+++ PE++ Y++>$ PGP>$ t++(+++)>$ !5-- X++ R+(++)>$
tv(tv) b++++>$ DI D++(+++)>$ G+(++) e-(+++) h* r-- y*
- --------------------------------------------------

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

From: [e-mail]
Date: Mon, 16 Oct 1995 16:30:44 -0400
Subject: commands

commands

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

From: [e-mail]
Date: Mon, 16 Oct 1995 16:30:35 -0400
Subject: menu

menu

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

From: Brian Hawley <[e-mail]>
Date: Mon, 16 Oct 1995 15:45:20 -0500
Subject: Long filenames

Hi there.

Does Executor support long filenames on VFAT drives under Win95? I would
think that the filenames used by Mac files would map well to the Win95 ones,
and this would simplify things quite a bit for me.

Executor seems to work well for me so far. If I have any major problems I'll
be sure to mention them.

Brian Hawley
[e-mail]


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

End of executor-digest V1 #301
******************************


  To subscribe to executor-digest, send the command:

 subscribe executor-digest

in the body of a message to "[e-mail]".  If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-executor-digest":

 subscribe executor-digest [e-mail]

  A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "executor-digest"
in the commands above with "executor".