Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.92/text0041.txt

Text File | 1996-03-31 | 15.7 KB | 377 lines

> > May we get an expire-demo of Executor?
>
> This is a great idea! this way we can actually try out if the application
> we want to run will work under executor! I think a lot ppl out there are not
> buying executor because they are not sure if that particular application
> will work with executor, and most ppl don't want to just spend $80 to find
> out it doesnt' run THAT particular application.
>
> Jes
>
>
What is the current price of Executor?  Any educational discount?

Also I think the expire demo is a good idea.  There is a piece of software that I
have and would like to run but spending money to find out it won't work is not
what I call fun.

Kent

From iclone![e-mail] Wed Dec 16 16:52:06 1992
Received: from unmvax.cs.unm.edu by ictv.com with SMTP id AA00938
  (5.65c/IDA-1.4.4 for <[e-mail]>); Wed, 16 Dec 1992 15:55:30 -0800
Received: from iclone.UUCP by unmvax.cs.unm.edu (5.61/3.3) with UUCP
    id <[e-mail]>; Wed, 16 Dec 92 16:55:25 -0700
Received: by  iclone.ardi.com  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA02671; Wed, 16 Dec 92 16:52:06 GMT-0700
Date: Wed, 16 Dec 92 16:52:06 GMT-0700
From: iclone![e-mail] (Clifford T. Matthews)
Message-Id: <9212162352.AA02671@ iclone.ardi.com >
Received: by NeXT Mailer (1.63)
To: [e-mail]
Subject: Expire Demo

Dear Folks,

Unfortunately, we can't put a time-limited-only version of Executor
out on the archives.  Our reasoning will make sense to some of you,
but will seem awfully strange to others, but it's true.

The problem is that ARDI's purpose is to do Mac compatibility in
general, including both emulators for machines with their own
operating systems (NeXTs, Suns, IBM-PCs and clones) and ROMs for Mac
clones.  If you're familiar with the Mac clone market and the Mac
emulator market, you're aware that the existing "clones" and
"emulators" require Mac ROMs to work.  There's the rub; if we release
a time-limited-only version of Executor, then people could make
emulators that require our time-limited-only version of Executor
instead of Mac ROMs.

This may not seem very probable to you, but we're talking about a
potentially *LARGE* market.  The fact that people already have
emulators that require ROMs shows that people are willing to
disassemble the ROMs in order to know enough about them to build
emulators that require the ROMs.  Since Mac ROMs are expensive, these
emulators aren't particularly widespread.

It is not clear that it is possible to give away software that in
effect has our entire reverse engineered ROMs in it and legally
prevent people from writing emulators that read our demo into memory
and then jump in and out of it as necessary.  Again, this may sound
like paranoia, but due to certain unique aspects of the Mac cloning
game, it is in fact a serious consideration.

That's why the demo version that's out there can only run a few
programs; significant portions of ROMlib (our equivalent to the Mac
ROMs) have been *removed* (not just hidden) in the demo version.

However, all is not lost.  The problem that people are concerned
about should be ameliorated by a few things:

    NeXT is about to get a site license that will allow all NeXT
    *owned* machines to run Executor 1.3.  This will give them
    greater familiarity with our product and hopefully some of
    them will relay messages about what works and what doesn't.

    We've hired three non-programmers to handle tech. support.
    In the past we've had programmers doing tech. support and
    the unfortunate reality is that they'd get pulled into
    into programming at the expense of keeping logs of what
    works and what doesn't work.

    Executor 1.3 will be able to run more programs.  As more
    things run, the more copies we sell and the more feedback
    we get and the more likely it is that one of you will know
    the answer to the question of does xxx run.  It also means
    that it's more likely that someone you know, or who is in
    your users' group will have a copy of Executor.

    We're selling through dealers now; some of them are testing
    programs and letting us know the results.

    ISV's are increasingly willing to send us software for us to
    test so we can advertise that it runs, or make it run in the
    next version if it doesn't.

Happy Holidays.

    --Cliff

From [e-mail] Thu Dec 17 03:49:27 1992
Received: from bloom.harvard.edu by ictv.com with SMTP id AA27682
  (5.65c/IDA-1.4.4 for <[e-mail]>); Thu, 17 Dec 1992 05:48:35 -0800
Received: by bloom.harvard.edu (NX5.67c/NX3.0M)
    id AA18085; Thu, 17 Dec 92 08:49:27 -0500
Date: Thu, 17 Dec 92 08:49:27 -0500
From: Neil M. Donahue <[e-mail]>
Message-Id: <[e-mail]>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: [e-mail]
Subject: Re: Expire Demo
Reply-To: [e-mail]

Howabout supplying a time-fused version to people; in a minimal
configuration, which would be only sending to people with NeXTMail on
the net, this could be done with essentially no overhead.  Even
sending out floppies wouldn't be so bad.

Neil

From [e-mail] Fri Dec 18 16:58:00 1992
Received: from rmnug.org (nugget.rmNUG.ORG) by ictv.com with SMTP id AA09390
  (5.65c/IDA-1.4.4 for <[e-mail]>); Fri, 18 Dec 1992 23:07:57 -0800
Received: by rmnug.org with UUCP id AA18243
  (5.65c/IDA-1.4.4 for [e-mail]); Sat, 19 Dec 1992 00:07:54 -0700
Received: by  eddie.rmNUG.ORG  (NX5.67c/rmnug-sub-$Revision: 1.3 $)
    id AA02246; Fri, 18 Dec 92 23:58:00 -0700
Date: Fri, 18 Dec 92 23:58:00 -0700
From: [e-mail] (Tim Miller)
Message-Id: <9212190658.AA02246@ eddie.rmNUG.ORG >
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: [e-mail]
Subject: EndNote for Executor

EndNote and EndNote Plus don't seem to work. FileMaker also doesn't
seem to work. Anybody had any luck with these?

Tim

From iclone![e-mail] Fri Dec 25 09:58:01 1992
Received: from unmvax.cs.unm.edu by ictv.com with SMTP id AA04469
  (5.65c/IDA-1.4.4 for <[e-mail]>); Fri, 25 Dec 1992 16:01:21 -0800
Received: from iclone.UUCP by unmvax.cs.unm.edu (5.61/3.3) with UUCP
    id <[e-mail]>; Fri, 25 Dec 92 17:01:14 -0700
Received: by  iclone.ardi.com  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA05090; Fri, 25 Dec 92 16:58:01 MST
Date: Fri, 25 Dec 92 16:58:01 MST
From: iclone![e-mail] (Clifford T. Matthews)
Message-Id: <9212252358.AA05090@ iclone.ardi.com >
Received: by NeXT Mailer (1.63)
To: [e-mail]
Subject: FileMaker under Executor

FileMaker and a few other programs (Finale comes to mind) want to
write scratch files at the top of the "volume" that they're found on.
If you run them on a Mac, and you have a hard drive named "Disk", and
you have FileMaker in a subdirectory named "FileMaker", the scratch
files get written in "Disk" and not "FileMaker".

With our UNIX <--> Mac mapping this results in programs trying to
write directly into the UNIX directory "/" or "/usr" instead of
"/LocalApps/Executor.app/ExecutorVolume/FileMaker".

One way to diagnose such problems is to run the program once as root
and see if it runs better.  If it does, then you need to find exactly
where the scratch files are being written and then decide what to do
about it.

You have a few choices.  You could always run that particular
application as root.  Although this is the easiest solution, it's
probably the worst.  Getting in the habit of running programs in root
is a bad habit to get into.

Once you've figured out what directory you need access to, you may
want to either change the ownership or the permissions on the
directory.  BEWARE: If you give people "write" access to a directory,
that allows the people with "write" access to both CREATE new files
and to DELETE existing files.  If you want to allow creation, but not
"deletion", you need to add "sticky" access to the directory.  To
allow everyone to write new files into "/", but not to delete
existing files (unless they're the owner), you could issue the
following commands as root:

iclone# ls -ld /
drwxr-xr-x 25 root        1024 Dec 23 00:45 /
iclone# chmod a+w,+t /
iclone# ls -ld /
drwxrwxrwt 25 root        1024 Dec 23 00:45 /

The first command shows exactly what permissions "/" currently has,
the second adds "w"rite to "a" and also adds s"t"icky to the
directory.  The third command shows that everyone can indeed "w"rite
to the directory and the "t" in "drwxrwxrwt" shows that the directory
is indeed s"t"icky.

Most programs don't require this goofiness, most programs write
scratch files either in the "System Folder", or in the directory that
the program itself resides in.

I've spent a bit of time thinking about a way to trick these aberrant
programs, but haven't figured out anything yet.

Happy Holidays.

    --Cliff

From [e-mail] Tue Dec 29 23:24:22 1992
Received: from nikita.andi.org by ictv.com with SMTP id AA06705
  (5.65c/IDA-1.4.4 for <[e-mail]>); Wed, 30 Dec 1992 01:21:56 -0800
Received: by nikita.andi.org (NX5.67c/NX3.0M)
    id AA00545; Wed, 30 Dec 92 04:24:22 -0500
Date: Wed, 30 Dec 92 04:24:22 -0500
From: Bill Chin <[e-mail]>
Message-Id: <[e-mail]>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: [e-mail]
Subject: Re: FileMaker under Executor
Reply-To: [e-mail]

Clifford T. Matthews writes:
> FileMaker and a few other programs (Finale comes to mind)
> want to write scratch files at the top of the "volume" that
> they're found on.  If you run them on a Mac, and you have a
> hard drive named "Disk", and you have FileMaker in a
> subdirectory named "FileMaker", the scratch files get
> written in "Disk" and not "FileMaker".

>

> I've spent a bit of time thinking about a way to trick these
> aberrant programs, but haven't figured out anything
> yet.

>


I would like to define "drives" for Executor - similar to SoftPC.  That
way, I can have a shared system "volume" in
/LocalApps/Executor.app/ExecutorVolume, and then personal "volumes,"
say, ~/Library/ExecutorVolume and /.  That way, if a program wants to
write to the top of the volume, it will write it to the top of that
defined volume (and in most cases,
/LocalApps/Executor.app/ExecutorVolume).

I find myself trying to manuever in those awkward Mac open panels too
much; I wish I could hit ~username/filename and so on.  The Mac file
interface wasn't intended for the huge number of subdirectories so
pervasive in UNIX.  How about drag and drop filenames into the dialog
boxes?  :-)

While I'm at it, why not have HFS_XFer be a NeXTSTEP app?  Does it
*have* to be a Mac one?  If it was a native NS app, it would be faster,
have a better GUI, and (maybe) could run alongside of Executor.  As it
stands, running the two at the same time seems to really slow down the
system, and I get occasional file corruptions.

Happy New Year!

---
Bill Chin, NeXTSTEP Developer, PRC Inc.
VP Communications, Washington Area NeXT Users Group
Association of NeXTSTEP Developers International Technical Staff
[e-mail] - NeXTmail welcomed

From iclone![e-mail] Tue Dec 29 20:50:06 1992
Received: from unmvax.cs.unm.edu by ictv.com with SMTP id AA07503
  (5.65c/IDA-1.4.4 for <[e-mail]>); Wed, 30 Dec 1992 02:53:58 -0800
Received: from iclone.UUCP by unmvax.cs.unm.edu (5.61/3.3) with UUCP
    id <[e-mail]>; Wed, 30 Dec 92 03:53:49 -0700
Received: by  iclone.ardi.com  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA00328; Wed, 30 Dec 92 03:50:06 MST
Date: Wed, 30 Dec 92 03:50:06 MST
From: iclone![e-mail] (Clifford T. Matthews)
Message-Id: <9212301050.AA00328@ iclone.ardi.com >
Received: by NeXT Mailer (1.63)
To: [e-mail]
Subject: Re: FileMaker under Executor

Dear Folks,

Originally Executor *did* have drives, although they were a pain to
configure and you didn't have the option to access the entire UNIX
filesystem.  People didn't like that and I don't blame them.

However, with the exception of the problem of apps that want to write
on the "top" of volumes, you can to some extent emulate volumes just
by grouping your files into a directory and double-clicking on a
".appl" file to start a given program in a given directory.  Then,
when you use the Mac dialogs for opening or creating files, they'll
start out in the directory that contains the ".appl".

The problem then becomes how do you get between them.  Drag and drop
is a possibility as is implementing some sort of special key sequence
or menu.  I like the idea of a shortcut to get to various parts
within the UNIX filesystem better than having separate volumes,
although that will mean that we'll still need to do something with
rogue programs that want to write scratch files at the top of a
volume.  When I said that "I haven't figured out anything yet" I
really overstated the case.  I haven't finalized our plan, but I have
thought over a few strategies.

I don't think HFS_XFer will ever be a "NeXTSTEP app".  I do think
that HFS_XFer will be integrated into a smarter Executor and that the
smarter Executor will have some handy features:

    1) Not go away when you quit

    2) Allow you to double-click and start another ".appl" even
       when one's running already

    3) Provide a way so that arbitrary programs can open
       open documents the way ".mxl" and ".msw" currently work
       for Excel and Word.

Tentatively this is slated for 1.4, which is ostensibly due out in
March, but since 1.3 has slipped (we're still having trouble getting
sound support to work and we're waiting on Microsoft for a copy of
Word 5.1a and we're waiting on NeXT for some hardware), 1.4 will
probably also slip (it's hard to make up lost time with our current
resources).

Please keep sending suggestions.  Executor's been available for a
year and a week now, and 1.3 is head and shoulders above 1.0, thanks
to all your suggestions (and all of our hard work).

Happy New Year!

    --Cliff

From [e-mail] Mon Sep 28 12:11:39 1992
Received: from clarknet.Clark.Net by ictv.com with SMTP id AA06105
  (5.65c/IDA-1.4.4 for <[e-mail]>); Mon, 27 Sep 1993 10:01:17 -0700
Received: by clarknet.clark.net (5.0/SMI-SVR4)
    id AA17834; Mon, 27 Sep 93 13:01:48 EDT
>Received: by  ants.edu.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA02103; Mon, 28 Sep 92 12:11:39 GMT-0500
Date: Mon, 28 Sep 92 12:11:39 GMT-0500
From: [e-mail] (James D. Meacham 3rd)
Message-Id: <9209281711.AA02103@ ants.edu.edu >
Received: from ants.edu by clarknet.clark.net; Mon, 27 Sep 1993 13:01 EDT
Received: by  ants.edu.edu  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA02103; Mon, 28 Sep 92 12:11:39 GMT-0500
Received: by NeXT Mailer (1.63.RR)
To: [e-mail]
Subject: Stuffit under executor for black h/w
Content-Type: text
Content-Length: 683




Hallo!

Has anyone tried using stuffit under executor?  I'm giving a talk
next week from my thesis, which is, unfortunately, archived using
stuffit.  Anyone?

James

---
_____________________________________________________________________

            James David Meacham, 3rd

M.Div. Candidate
Andover Newton Theological School      e-mail:[e-mail]

210 Herrick Rd.                Phone: [phone]
Newton Centre, MA 02159               NeXTMAIL accepted

Intern Minister                64-66 Marlborough Street
First and Second Church in Boston    Boston, MA 02116
(Unitarian Universalist)        617-267-6730
_____________________________________________________________________