PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.65

Text File | 1988-06-18 | 44.0 KB | 1,098 lines | [TEXT/ttxt]

List (Unformatted): USENET MAC DIGEST V4 #65


Usenet Mac Digest     Friday, May 20, 1988           Volume 4 : Issue 65

Today's Topics:
     New System icon
     Bug in MPW Shell 2.0.2
     A Tale of Two Bugs
     Re: PrintMgr Bug?   (YES!!)
     Re: Using PixMaps in CopyBits
     Bug in List Manager?
     Re: SE Floppy Problem
     Re: Kinetics FastPath box & CAP
     Re: New System icon
     Re: Mac on airplanes
     Re: MS Excel recalculations
     Re: Dvorek keyboard
     Re: Mac ADA for MPW
     "There is nothing to choose" trouble
     BBS User Interface Ideas Wanted (3 messages)
     Looking for laser schwa
     Prodigy SE
     Re: Brief overview of FullWrite (Really solution to Word 3.01 problem)
     Re: How to quit MF?(was Re: Quitting the Finder under MF)
     Re: writing an INIT in LSP
     Re: FullWrite on shelves

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

From: [e-mail] (John Cothran)
Subject: New System icon
Date: 16 May 88 01:00:40 GMT
Organization: DeKalb College, Clarkston GA

  As everyone knows, the current System, Finder, and many releated OS
files bear the same icon they appeared with in the first version of the
Mac's OS.

  The Macintosh has since evolved and multiplied. We can now use any of
three seperate machines, each with its own unique case (the 128,512,and
512ke all sharing the Plus' case). While the single drive, one piece Mac
will always be remembered fondly, it will never again be the one and
only shape for Macintosh.

  How many people would like to see the original Mac icon remain?

  Does anyone have any suggestions for an all encompasing Mac icon?

  How about the people at Apple? Could you tell us what might happen w/
System 6.0 or later?

  What about different icons on each machine (I realize that this could
cause some problems for new users who wouldn't know wheather or not the
System file that looked like an SE should be booted on a Plus or a II)?

  Replies, comments, objextions, and briliant suggestions welocome and
appreciated.
--
===================================================================
=Charles D. Menser             !         seismo!gatech!dcc1!menser=
=Atlanta, Georgia              !         menser@dcc1              =
="The Greeks may have invented it, but we didn't upload it..."    =


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

From: [e-mail] (Norbert Lindenberg)
Subject: Bug in MPW Shell 2.0.2
Date: 13 May 88 19:35:45 GMT
Organization: University of Karlsruhe, W.-Germany

Today I found a bug in MPW Shell 2.0.2:

The "Open" command does not open a file read-only if the -r option is
used in conjunction with the -t option. "Open -r -t myFile" opens the
file as target window, but lets the user modify the file. Rewriting
"Open -r -t myFile" as "Open -r myFile; Open -t myFile" works, but
causes unnecessary window movements.

-- Norbert


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

From: [e-mail] (The Apathist)
Subject: A Tale of Two Bugs
Date: 15 May 88 00:07:06 GMT
Organization: Authorized Service, Incorporated


        I've been working on a custom MDEF, changing the InvertRect calls to
paint & redraw so it will work on color monitors.  I thought it was
working, but I kept having an uneasy feeling when I finished selecting
an item with it.  After watching it closely a few times, I figured out
why: the menu wasn't blinking when I let up the mouse.

        With some difficulty, I tracked down this problem -- part of it is
Apple's fault, and part is the fault of Lightspeed C.

        Apple's problem is that to make an item blink, MenuSelect calls the
MDEF with whichitem pointng to the low-memory global ToolScratch, which
alternately contains zero and the number of the item selected.  From my
understanding of the rules for ToolScratch, this is bound to lose; any
toolbox call that the MDEF makes may stomp all over it.  But I guess
some stingy Apple programmer wanted to save a couple of bytes of stack
space.

        However, I seem to have been lucky.  Nothing I called was messing up
ToolScratch.

        Here's where LSC comes in.  It's using ToolScratch too, and dumps the
address of the MDEF into it during its code resource initialization
code.  And thus making the same mistake Apple did: that address could
easily be trashed before it's used.  I don't know of any truly safe
place LSC could have used instead, but if there isn't, I'll let them
have one: just take the last four bytes of ApplScratch.  If more space
is needed, put a handle there.  They can save/restore it to avoid
reentrancy problems, and it will break few existing sources.  It need
not break *any* future sources if it was *documented*, like the use of
ToolScratch should have been.

        These problems are in LSC 2.15 and the 5.0 system software. What
versions will they *not* be in?

                                        --Tom Lippincott
                                        ..ucbvax!math!lippin
                                          [e-mail]

        "Well, you can't eat that raw!"
                                        --Mrs. Premise


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

From: [e-mail] (Alan Epstein)
Subject: Re: PrintMgr Bug?   (YES!!)
Date: 14 May 88 22:40:11 GMT
Organization: Meta Software Corporation, Cambridge MA


it appears there really is a bug in the LW driver. the complaint was
when printing polygons, random lines would be drawn across the paper.
apple's reply follows:

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

> scott douglass <[e-mail]> writes:

> I've got an answer.  Unfortunately the problem stems from a scamble
> bug in the LW driver.  The problem can occur anytime the LW is drawing
> a QD polygon and it has to dump its PostScript buffer.  In spite of the
> indications you saw, this bug is not related to spooling and can happen
> even when priting direct although printing under PrintMonitor may
> aggravate the problem.  The bug has been in the LW since about
> version 3.3.  It is NOT fixed in the lastest driver (5.2, I believe)
> that just shipped with System 6.0.  This bug should be fixed in the
> next version of the LW with System 7.0, which is due out in the fall.

> One way to work around this problem would be to use the PicComment
> polygon feature of the LW instead of normal QD polygons.  This is
> described in the LW ref manual and the technote on LW piccomments.
> This does not, however, work on the ImageWriter.  You would have to
> special case the LW in your print code.

> I'm sorry that the news isn't better.  Thanks for bringing the bug
> to our attention.

------------------------------------------
--
-----------------------------
Alan Epstein
Meta Software Corp                   UUCP:  ...bbn!metasoft!alan
150 Cambridgepark Dr        Internet/ARPA:  [e-mail]
Cambridge, MA 02140  USA
-----------------------------


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

From: [e-mail] (Roger L. Long)
Subject: Re: Using PixMaps in CopyBits
Date: 14 May 88 17:17:17 GMT
Organization: Wolfskill residence; Anaheim, CA (USA)

In article <[e-mail]>
[e-mail] (Tom Carstensen) writes:
>I'm having a slight problem in getting Copy Bits to
>work correctly.

>mypm = NewPixMap()
>Set mypm bounds rectangle
>Set mypm row bytes
>Set sourcerect = some small rectangle in the window
>
>HLock((Handle)mypm);
>(*mypm)->baseAddr = NewPtr(#bytes * (*mypm)->pixelSize);
>CopyBits(¤tWindow->portBits, *mypm,
>     &sourcerect, &(*mypm)->bounds, srcCopy, NULL)
>
>... do stuff ...
>.. then copy back
>
>CopyBits(*mypm, ¤tWindow-portBits,
>     &(*mypm)->bounds, &sourcerect, srcCopy, NULL);

>Well, I've checked all of the above code in the debugger,
>and all of it looks fine, but it DOESN'T work.  It does
>copies the bits back, but the color is messed up, like
>it's copying to/from a 1 or 2 bits screen.
>
>Does anyone see my problem, are had success doing something
>like this.

First, a disclaimer.  I've only been programming on the Mac II for a
little over a month, and thus far, I consider people who can get fancy
color programming to work with JUST Inside Mac vol V something close to
gods. However I have dealt with offscreen pixmaps, and think I see your
problem.

If you take a look at the IM-V description of NewPixMap, you'll see the
statement:

        "All fields of the pixMap are copied from the current device's
         pixMap except the color table.  A handle to the color table is
         allocated but not initialized."

Thus, what I'd add are the statements (which come to us from TN120, but
I've translated them to C):

        CTabHandle ourCMHandle;
        GDHandle theMaxDevice;

        ourCMHandle = (*((*theMaxDevice)->gdPMap))->pmTable;
        err = HandToHand(&CTabHandle);

        for (i=0; i<(*ourCMHandle)->ctSize; i++)
                (*ourCMHandle)->ctTable[i].value = i;
        (*ourCMHandle)->transIndex &= 0x7FFF;

        (*mypm)->pmTable = ourCMTable;

Basically, what this code does is clone the color table from the device
with the deepest pixels (you should be figuring out theMaxDevice already
to figure out things like how much storage to allocate to the actual
pixel storage.

Then, you make this new color map that you cloned look like a PixMap
color table instead of a device color table.

Once you've done that, just stick the handle into your PixMap.

You really should get hold of a copy of "TN120: Drawing into an
Offscreen PixMap".
--
        Roger L. Long
        dhw68k!bytebug


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

From: [e-mail] (William Lipa)
Subject: Bug in List Manager?
Date: 16 May 88 05:08:39 GMT

I am using the List Manager to display a two-dimensional list with
single characters in it. I want the user to be able to select disjoint
rectangles of cells in this list, in the same way that the Finder works
when you select icons with the box while holding down the shift key.

I cannot seem to get this to work. In particular, when you hold the
shift key down and sweep out a rectangle, and then return the cursor to
the point where you originally clicked, the rectangle does not shrink.
The selected rectangle stays stuck at its maximum extent. Inside Mac IV
seems to say this should be possible. On page 266, it says, "...the List
Manager expands AND SHRINKS a selected rectangle that's defined by the
mouse location and the 'anchor'...".

Am I doing something wrong, or is it the fault of the List Manager?
--
Bill Lipa
[e-mail]

PS. This is with the lNoExtend bit set to allow disjoint rectangles.


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

From: [e-mail] (Jim Macak)
Subject: Re: SE Floppy Problem
Date: 16 May 88 13:23:16 GMT
Organization: Lake Systems - Milwaukee, WI

Jeff Metzner writes:

> I have an SE with an internal HD20 and an internal floppy drive.
> Today, my floppy drive decided to stop accepting disks ("This disk is
> damaged...").
>
> All my disks worked fine yesterday, and they work on a friend's
> machine.
>
> Has anyone else had this problem?  Do I need to have the machine
> repaired, or is it a simple problem I can fix myself?

Jeff,

I had a similar problem with my 800K internal Mac Plus Drive a few
months ago. All of a sudden, after going through a bunch of public
domain disks of a user group library, the drive would not read any disk.

Over the next couple of days, I periodically tried the drive and got the
same result.  However, about 4 days after the original problem started,
the drive miraculously began working normally again and I have had no
problems with it since then!

I have talked with some local Mac "experts" who thought this all could
be explained by a dirty drive head that coused the inability of the
drive to read a Mac disk.  If the dirt was knocked off of the drive head
in the process of my retrying to use the drive, that would explain why
it started working again.

So, you may wish to try using a disk drive cleaner on the drive before
going to your friendly Apple dealer and forking over $200-$300 for a new
drive installation!

Jim


--

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Jim -->  [e-mail] (Jim Macak)  {Standard disclaimer, nothin' fancy!}
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


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

From: [e-mail] (Roy Smith)
Subject: Re: Kinetics FastPath box & CAP
Date: 16 May 88 13:54:49 GMT
Organization: Public Health Research Inst. (NY, NY)


        We've been running KIP/CAP for about a year now.  We've got a 4.3BSD
Vax driving 2 LaserWriters on a PhoneNet network spanning 4 floors with
about a dozen Macs in addition to the LWs.  We've also got 2 LWs driven
by RS-232 from Sun-3s.  The Vax, Suns, and kbox are all on an ethernet.

        Anyway, CAP seems to work about 90% as well as we'd like.  The biggest
problem is a niggling bug which sometimes causes the LWs to hang when a
print job starts.  Curiously, one of our LWs hangs a lot more often than
the other, and even more curiously, the one which hangs more frequently
is about the furthest node on the net (the other LW sits right next to
the kbox).  Charlie Kim at Columbia has been very helpful trying to
figure out what might be wrong and supply fixes.  We're running CAP
release 4, with many patches applied.  I understand that CAP release 5
will be out soon, and we're eagerly awaiting that, in the expectation
that the LW hang bug will finally go away for good.  We never did get
lwsrv (the Unix-side LaserWriter print spooler) to work, but since it's
not really needed in our environment, we don't miss it.  We've also
never experimented with the other half of CAP, which is AppleShare
support (lets you use your unix box as an AppleShare server).  Bottom
line is we probably print several hundred pages a day using CAP and
don't see the need to pay money for a commercial product to replace it.

        We also use NCSA Telnet, which includes ftp support, on our Macs so we
can do remote logins to our Unix boxes.  NCSA Telnet is a very nice
program.  We've found a few very minor bugs in it, most of which will
probably be fixed in some later version.
--
Roy Smith, System Administrator
Public Health Research Institute
455 First Avenue, New York, NY 10016
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri![e-mail]


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

From: [e-mail] (Keith Kinoshita)
Subject: Re: New System icon
Date: 16 May 88 12:19:40 GMT
Organization: U. of Hawaii, Manoa (Honolulu)

        Why complicate the system both visually and as a matter of  programming
simplicity for something as dubious as a visual representation for
hardware recognition? I thought the whole idea of the Mac environment
was  to hide the hardware level, and make everything as simple as
possible.
        Come to think of it, Apple should have standardized a CDEV and an INIT
icon for the mac as well.
--
Keith Kinoshita
INTERNET: [e-mail]         ARPA:  uhccux![e-mail]
BITNET:   keith@uhccux           UUCP:  ...!ucsd!nosc!uhccux!keith
PLATO:    keith / uhcc / hawaii


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

From: [e-mail] (Weng Seng Cheong)
Subject: Re: Mac on airplanes
Date: 16 May 88 15:54:47 GMT
Organization: Cornell Univ. CS Dept, Ithaca NY

I am forwarding this message for Eric who responded to my  earlier
posting ....

(Start of message)

I have been able to fit my Mac under the seats of and in the overhead
compartment of all the Boeing planes on which I have flown, from the
various incarnations of the 727 through the 757.  I have had
difficulties fitting it under the seats of Fokker planes, which are used
for some short runs in the U.S., and that French airbus, the number of
which escapes me.  (Perhaps it is A-303 or something like that.)  I also
vaguely remember  having trouble fitting it under the seat of a Lockheed
plane: it went, but only after the application of great force.

I use an old-fashioned Apple carrying case (with the unsafe strap
removed, of course).

I am in the habit of calling the airlines and finding out which planes
they use for the entirety of their run.  They enjoy telling me, as the
information is easily available to them, but hardly anybody ever asks.
--
Eric Pepke                           [e-mail]
Supercomputer Computations           [e-mail]
   Research Institute                [e-mail]
Florida State University             "You're living in your own private Idaho
Tallahassee, FL 32306-4052            On the ground like a wild potato."

Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.

(End of message)

---------------------------------------------------------------------------
Weng Seng Cheong
Dept. of Computer Science               Internet:  [e-mail]
Cornell University                      BITnet:    cheong@crnlcs
Ithaca, NY14850


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

From: [e-mail] (Jon Udell)
Subject: Re: MS Excel recalculations
Date: 16 May 88 21:01:24 GMT
Organization: Stanford University

In article <[e-mail]> [e-mail]
(Jim Clausing) writes:

>One thing you can do (unfortunately, you need to do it every time you
>open the spreadsheet), is to go over to the Options menu and select
>Calculation...

After quitting Excel, rename the "Resume Excel" file.  If you use this
file in the future to open the spreadsheet, you won't have to reset the
calculation mode.

Jon


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

From: [e-mail] (Hungry mind and open eyes . . .)
Subject: Re: Dvorek keyboard
Date: 17 May 88 00:24:50 GMT
Organization: U of Chicago- Department of Astrology and Metaphysics


   Yeah!!  The Dvorak layout is vastly faster than the QWERTY, and on
the new Macintoshes, it works beautifully.
   The Dvorak keyboard layout is documented in Tech note #160 (key
mapping). The deal, basically, is this:
   The new Macintoshes use a two-stage key decoding sequence.  In the
first stage, which involves the KMAP resource, keys are mapped from
their hardware values to some device independent values.  The KMAP
resource should only be used for this purpose.
   To switch the logical keyboard mapping, you use a KCHR resource.
This translates the device-independent key values into ascii values.
The format of the KCHR resource is documented in TN160- essentially, it
consists of a number (usually 8) of 128 byte tables which control key
mapping under different modifier keys.  What you should probably do is
copy the 'US' KCHR resource from the System file, and modify it to suit
your needs.  You then install the new KCHR resource, along with a SICN
resource of the same number into the System file.  From now on, the
Keyboard panel of the control panel will allow you to choose between the
US and Dvorak layouts.
   If anyone wants a ready-made KCHR and SICN set, send me mail.
   Incidentally, certain badly-written programs, like Telnet and MS
Word, do not work properly with a Dvorak layout.
                                                        -Matt


--
Matt Bamberger                  "Truth is after all a moving target
1005 E. 60th St., #346           Hairs to split, and pieces that don't fit.
312-753-2261                     How can anybody be enlightened?
...ihnp4!oddjob!mcb              Truth is after all so poorly lit." - Rush


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

From: [e-mail] (Peter C. Coffee)
Subject: Re: Mac ADA for MPW
Date: 16 May 88 19:06:35 GMT
Organization: The Aerospace Corporation, El Segundo, CA

In article <42384DN5@PSUVM> [e-mail] (D. Jay Newman) writes:
>I recently asked about Ada for the Mac in comp.lang.ada, found a supplier,
>and called for the price, and was shocked....

>   Meridian Software Systems, Inc.
>   Laguana Hills, CA
>   [phone]

or 1-800-221-2522

>   $1195.00

>Unfortunately, I am looking for an Ada compiler to learn the language on,
>not to become a Department of Defense contract programmer...

The Meridian literature that I received also describes an AdaStarter
version "identical to the validated v2.1 AdaVantage compiler" but with
limitations of up to ten library units, each of up to 200 executable
statements. Price applicable toward purchase of the production compiler.
$99.

Yes, $99. I don't know if this is shipping, but it's descibed in the
same literature as the big version.

Cheers -- Peter C.


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

From: [e-mail] (Dave Matthews)
Subject: "There is nothing to choose" trouble
Date: 17 May 88 02:51:58 GMT
Organization: Dept. Plant Pathology, Cornell University, Ithaca NY


All of a sudden I'm getting the message "There is nothing to choose on
the startup disk" when I try to use the Chooser.  This has happened to
two of my startup disks now.  They're stuck in ImageWriter mode,
apparently irreversibly.  Replacing the LaserWriter, Laser Prep,
ImageWriter, System and Finder with fresh copies from disks that work
doesn't help.  Changing machines doesn't help.  Disconnecting/connecting
Appletalk doesn't help. Has anybody ever seen this problem before?

(This is on Mac+'s and 512E's under System 3.2, nothing fancy.)

- Dave Matthews
  ARPA:[e-mail]
BITNET:matthews@crnlthry

USENET:...{cmcl2,shasta,uw-beaver,rochester}!cornell!batcomputer!matthews


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

From: [e-mail] (Andy J. Williams)
Subject: BBS User Interface Ideas Wanted
Date: 16 May 88 18:53:32 GMT
Organization: Kiewit Computation Center, Dartmouth College

*** A little long, advice NEEDED! ***

I am writing a rather large BBS package for use on our Appletalk Network
here at Dartmouth College and I would like a little advice.  The program
will be a Macintosh front end to a VPL1 Server running on a mainframe
here. The Server will contain

     All the netnews groups we receive (circa 200-300 last count)
     All the newsgroups which will be read locally
     and maybe a Finger User option and a conference system.

The big problem has been designing a user interface which presents, say,
300 newsgroups to the user in a very simple form that even a complete
neophyte can understand and know what to do (Intuitive programming)
Note that I intend to follow the Mac Interface guidelines very closely.

Some of the ideas have been basically: Present something akin to
SFGetFile which allows a heirarchical selecting of the news.  (Treating
comp and sys and mac as successive layers in a heirarchical tree).  I
object to this as it is rather dry and can be imposing to a new user.
Other ideas has been a fairly involved selection scheme which, once you
have decided which groups you want and dont want, allows you to save
macros which you click on to get the groups you want.

The questions I have been asking are: What would be the easiest to use?
What would be the most intuitive?  What would present the most
information in the simplest way?  etc.  Remember, we are talking about
300 + groups.

Any advive, snatches of code, or anything is welcomed and very
encouraged!

-Andy J. Williams
--
Andy J. Williams '90     |Ack Systems: [e-mail]|  _   /|
Software Development     +--------------------------------------+  \`o_O' ACK!
Kiewit Computation Center|Hello. My $NAME is ~inigo_montoya.    |    ( )  /
Dartmouth College        |You killed my process.  Prepare to vi.|     U


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

From: korn@eris (Peter "Arrgh" Korn)
Subject: Re: BBS User Interface Ideas Wanted
Date: 17 May 88 07:40:26 GMT
Organization: What, me organized???

Hmmm...  I've been thinking that when (and if) I get uucp up and running
on my mac, I'll want a user interface to choose what netnews groups to
read. While reading your posting, I got an idea:

In a menu somewhere (be it a pop up from a configure dialog that allowed
you to set things like kill files, etc., or from a pull down that's
located on the menu bar) you have the entire list of groups available.
The user will have to be able to scan the list at some point, and
breaking it up in this fashion seems reasonable.  Items that were marked
for reading would have a checkmark on them; items unsubscribed would
have another mark by them, etc.

This full list would then feed into a second menu, which was basically
your .newsrc (the analogy holds for those who use rn to read netnews).
Unread news would have a mark on the menu, etc.  The user could pick and
choose which groups to read by selecting them from the menu.
Alternately more advanced users could type the names of the newsgroups
in a box somewhere. A default would be to simply cycle through the
groups on the 'read list' from top to bottom (as currently in rn).  As
NewGroup messages come in, the program would have to update the master
menu list.

Somewhere in the custom WDEF would be a bunch of controls to do various
things.  One would indicate that the user wants to read the next posting
with the title of the current posting.  Another would kill all postings
with that title, etc.  One would have to pick and choose as to which
controls would be in the window.  Or, alternately, the user could
customize their interface, placing whichever controls *they* wanted to
have available at all times on their window, with the ones they didn't
tend to user not cluttering their window border.

Multiple windows are a must; with the user being able to read several
different articles at once; respond to several at once, cut & paste at
will.

An ideal addition would be a parser that removes all hard <CR>s (with
some kind of hueristic to sence when <CR>s are intentional...) and
format the messages in whatever size window was desired.  Replies should
be written in whatever size window the user desired; hard <CR>s always
carried over, and <CR>s added in just before the message was sent off to
the server (unless our server could do all of this for us).  Font should
be the user's choice.

The Mail headers should be hidable from users that don't want to fuss
with them.  Ideally some interface to pathalias would exist on the
server side. However, users that want to muck with that stuff must be
allowed to.  Never *ever* assume that the computer is smarter than the
user.  If by chance it is, the user will discover it in due time.  When
it's not, the user shouldn't be forced.

As with MacTerminal, the user should be able to print selections, as
well as entire messages.  Also the user should be able to save
selections  (by selection I mean an artibrary string of text that the
user selects with the cursor by dragging over it).

A possible "behind the user's back" that might be added is saving the
headers of any message that a user saves in the resource fork of the
document, so that the user doesn't have to do that seperately in order
to retain attribution.

Selecting discontiguous text would be nice (automagically insert elipsis
as appropiate [on a new line of the skip is over a <CR>, or on the same
line if the skip doesn't cross a <CR>] so that the user doesn't have to
go to the trouble -- this option should be turn off-able).  Certainly
not a necessity in version 1.0!

Incorporating MacPaint pictures, TIFF, etc. etc. would also be nice,
especially if a lot of intra-campus messages are exchanged.  Perhaps in
the "news group" data structure you would have a boolean that indicated
whether or not mac graphics were appropiate for this group and disallow
posting to "real" newsgroups.

A vi/emacs editor would be nice for those that want it and are used to
it.

And lastly, a very snazzy About box is without question the only classy
way to go on a program that does all this.

Hmmm...  and this was to be a quick note detailing some of my ideas...
Anyone out there have anything different?  Anything you would change?

Peter "the dreamer" Korn
--
Peter "Arrgh" Korn
[e-mail]
{decvax,dual,hplabs,sdcsvax,ulysses}!ucbvax!korn


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

From: [e-mail] (David C. Kovar)
Subject: Re: BBS User Interface Ideas Wanted
Date: 17 May 88 12:55:25 GMT
Organization: Bolt Beranek and Newman Inc., Cambridge MA


  I sent this directly to Andy but as it seems to be of general
interest, I'll post it as well.

  The Andrew system at Carnegie Mellon University provides mail and
message support. The system runs on various workstations (RTs, Suns, and
uVaxes) and is introduced to the entire freshman class each year. Last I
saw of it, it was very easy to learn for the beginner and quite powerful
for the expert. Just before I left, we started porting the mail and
messages program over to the Macintosh. (It'd already been put on to the
IBM PC.) You might want to contact CMU and see what sort of
documentation they have on the current system. I'm reluctant to hand out
names of people at CMU that you might contact but if they are reading
this group perhaps they could provide a pointer to documentation.
Lacking that, I'd be willing to describe the Mac interface as it was
before I left.

-David Kovar
 [e-mail]


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

From: [e-mail]
Subject: Looking for laser schwa
Date: 16 May 88 00:12:00 GMT


  Does anyone know of a laser font that contains a schwa character
(looks like an upside down 'e'). It must be a laser font. I know someone
who needs this character, but doesn't want to pay ~$200 for
Fontographer, just to edit one character. If it exists in a PD font,
that would be great.

Robert Brewer
    [e-mail]
    {ihnp4 | convex | pur-ee}!uiucuxc!clio!brewer


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

From: [e-mail] (Vernon Dale Frameli)
Subject: Prodigy SE
Date: 17 May 88 13:06:09 GMT
Organization: Digital Equipment Corporation

        hi,

            i saw lori's request for information regarding accelerators
        for the mac se. since i have a prodigy 4 se, i would like relate
        my experiences with it and then how the prodigy se compares to
        the radius accelerator. you guys with the radius accelerators be
        patient and feel free to correct me where i'm wrong.

            i bought my prodigy 4 se from levco last november. i got the
        4mb version; the 68881 is standard issue on all prodigy's. the
        prodigy was extremely easy for me to install. i received all of
        the necessary tools required, as well as very easy to follow
        instructions for doing it myself. it took me less than 20
minutes
        from start to finish. since that time, i have received an
upgrade
        from levco and once more i cracked open my mac se. i installed a
        new set of proms, pals, and gate arrays without a hitch. again
        the instructions where very easy to follow. to clarify things,

        i'm more of a programmer than a technician.

            i also received diagnostic software which will test the
68881,
        the 68851, and all of the onboard ram. in addition, software to
        create a bootable recoverable ramdisk is included. the
diagnostics
        are nice to have, but i can't say enough about the ramdisk. if
my
        system crashes for any reason, my ramdisk is preserved, and if a
        copy of my system folder is on the ramdisk, then my mac will
boot
        from it. it's very fast, i'd say it takes less than a second to
        reboot.

            it's true that the radius is priced lower than a prodigy,
but
        the 68881 math coprocessor comes standard on a prodigy; its a
        $295 option on most accelerators, i believe this holds true for
        the radius accelerator as well. it's also true because the
radius
        doesn't provide any additional ram beyond the 32k cache it uses.
        in contrast, my prodigy has 4mb of fast ram. in addition, it
also
        recognizes the ram you have on your motherboard. this gives your
        mac se the capability of upgrading to a total of 8mb, you can't

        do that with a radius.

            i'm not sure how all radius users feel about their
accelerator's
        performance. i read in a note in the mac conference here that it
        was quite fast at refreshing the mac's screen, but that the
owner
        was otherwise unimpressed. a prodigy, i my experience, is fast
at
        everything it does, i can point to at least three different
magazines
        which concluded that the prodigy was faster than any other
accelerator
        on the market. it was faster than a radius. it was also faster
        than the mac ii in the cpu bound test performed. the benchmarks
        used where not whetstones, and dhrystones, etc... the writer's
        choose instead to use real world applications using actual
products
        that are commonly available for the mac. they benchmarked with
        spreadsheets, database, word processors, etc...

            one nice thing about the prodigy is that the rom is copied
into
        a protected portion of the fast ram. one of the most noticeable
        places you'll see a difference is in disk access times. reading
        from a floppy takes less than half the time it would in a non-
        accelerated mac se. programs which make use of the mac rom's
        also benefit from a big increase in speed, the more "mac-like"
        a program is the better.

            the prodigy has the same ability to re-route sane calls to
the
        68881 that the radius has. it will also allow you to turn the
        68020 cache on and off, both can be done via the control panel.
in
        addition, the prodigy has a sound patch which keeps music,
etc...
        from sounding garbled when it's accelerated. it also has patches
        built into the firmware which allow you to run software which
can't
        run on a mac ii in those cases where the programmer failed to
follow
        apple's programming guide lines.

            the prodigy has an optional expansion slot, thus allowing
you
        to further enhance your mac. unlike the radius which sits in a
        vertical position within your mac the prodigy mounts flush with
the
        motherboard so that it won't get in the way of future
enhancements.
        both accelerators make provisions for adding a large screen
monitor,
        though i think the prodigy is compatible with more than one
brand,
        thus giving you a choice.

            finally, there's something that you can do with the prodigy
        that you can't do with the radius,...you can turn it off. in the
        event that a piece of software won't run because of timing
conflicts
        with the faster clock speed of the 68020, you can always turn
the
        prodigy off, and run as a plain ole mac se. with the radius, you
        would have to physically remove it in order to turn it off.

            i know some of you out there are saying to yourselves that
        levco's not out there any more. that's simply not true. the same
        parent company that owns levco owns supermac. the parent company
        just decided to let supermac flex it marketing muscle while
levco
        handles the technical end. if you want to buy a prodigy, you
call
        your apple dealer, or supermac. if you want to get your prodigy
        repaired or upgraded, it goes back to levco. levco still designs
        the enhancements, and does the upgrades. it's all the same ball
        of wax.

            levco has been at this a long time, i believe that they
where
        the manufacture of the very first accelerator for the mac. they
        introduced the prodigy series back in 84 or 85 near the time
that
        the mac was first introduced. they've had time to develop a
first
        rate product. what can i say, look at who's accelerator is shown
        in  apple's own advertisements, it's a prodigy se. is that an
        endorsement or what?

            ok guys, you've held it in long enough, go ahead and let me
        have it with both barrels. i know the radius performs well. i
        know it's one of the most popular accelerators out there. i know
        it's one of the best buys you can get in an accelerator. still i
        also know i'll get flamed really good for this one no matter
what
        i say now.

                                                  dale

                                                  dpdmai::frameli





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

From: [e-mail] (Jeff Meyer)
Subject: Re: Brief overview of FullWrite (Really solution to Word 3.01 problem)
Date: 17 May 88 14:57:45 GMT
Organization: John Fluke Mfg. Co., Inc., Everett, WA

>I understand a third very substantial missing feature is inheritance --
>FullWrite styles can't inherit from other styles as Word's can.

That's an excellent point, one I'll have to add to the checklist between
FW and Word.  However, I'd again have to point out how difficult it is
to use the Style Sheets in Word, and inheritance; however, MS is
supposed to be working very hard on making Style Sheets easier to use.

>The solution is to select the whole paragraph, and from Format menu, select
>Plain Text, which clears any formatting above the basic style.  If you like

That does work, but it's not very intuitive.  The trouble with Word is,
I run into problems with Word just often enough that I've forgotten the
solution to the problem.  However, it's rumored that Word 4.0 will have
intelligent style sheets which eliminate this problem (among other good
things), so MS isn't ignoring the problem.

>Have fun -- I'd like to try FullWrite, being just as interested as

As power goes, I side with Chuq; there are a ton of things that I can do
with FW that I can't with Word, and only a few that I can't do with FW.
More importantly, the things I *want* to do with a word processor are
supported in FullWrite, and are extremely easy to understand to boot.
However, Microsoft is certainly not sitting on their laurels, so we will
hopefully have two good high-level word processing programs by the end
of the year.  At this point, I'm not experiencing any bombs with FW, and
have no reason left to use Word.  We'll see when 4.0 comes out...
--
                        "I've got to concentrate.  I've got to concentrate!
                          ..Hello?
                             ..Echo!
                                ..Pinch hitting for Pedro Forfone, Manny Moto!"
---
                                        Moriarty, aka Jeff Meyer
INTERNET:     [e-mail]
Manual UUCP:  {uw-beaver, sun, microsoft}!fluke!moriarty
CREDO:        You gotta be Cruel to be Kind...
<*> DISCLAIMER: Do what you want with me, but leave my employers alone! <*>


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

From: [e-mail] (Bruce Horn)
Subject: Re: How to quit MF?(was Re: Quitting the Finder under MF)
Date: 17 May 88 15:32:13 GMT
Organization: Carnegie-Mellon University, CS/RI

The reason I put command-option launch into the Finder was not because
of the Lisa Pascal Workshop, but because when I was testing newer
versions of the Finder I didn't want to have to keep changing the type
and creator of the Finder file itself.  That was before we had support
for downloading to the Mac from the Lisa with type and creator
specified, if I remember correctly.--
--
Bruce Horn, Carnegie Mellon CSD
uucp: ...!seismo!cmucspt!cmu-cs-vlsi!blh
ARPA: [e-mail]


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

From: [e-mail] (Byron Han, fire fighter)
Subject: Re: writing an INIT in LSP
Date: 17 May 88 17:57:31 GMT
Organization: Communication Tools Group - Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Kevin Housen)
writes:
>
>I am having a problem writing an INIT in Lightspeed Pascal
>(version 1.11) on a Mac II.  After continual system bombs,
>I tried making a really simple INIT - as follows:
>
Here is an interesting situation.

Did you know that when INIT's are called, they are not locked in memory?
So, SysBeep which can potentially cause a heap compaction may cause your
INIT resource to be relocated.

Solution?  either set the locked bit in the INIT resource or put this at
the start of your INIT.

theHandle := RecoverHandle(@EntryPoint); HLock(theHandle);

and voila your problems should go away.
--
Byron Han,  Licensed to Dream.             "Macintosh - there is no substitute."

Apple Computer, Inc. MS 27Y                -------------------------------------

ATTnet:408-973-6450     applelink:HAN1     domain:[e-mail]       MacNET:HAN

GENIE:BYRONHAN    COMPUSERVE:72167,1664    UUCP:{sun,voder,nsc,decwrl}!apple!han



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

From: [e-mail] (Martin J. Duerst)
Subject: Re: FullWrite on shelves
Date: 17 May 88 03:39:57 GMT
Organization: Computer Center, University of Tokyo, Japan.


>had discussions with them relatively early in development about Script Manager
>compat and the answer was IMPOSSIBLE!!
    I don't belive that exactly.
>       I wish I could get it to work at least 'sort of' with ANY of the Int'l
>Scripts, but alas, NO!  Not even the draw layer works (but it does work better
>than the main program!!!)

   Here is an idea that could help to solve a lot of problems with the
internationalization of FullWrite and many other Word Processors(WP). It
is very clear that elaborated WP don't use the (new) TextEdit and the
ScriptManager because their (relative) lack of speed and functionality.
On the other hand, many users in the US and in many other countries
would shurely appreciate it if they can use non-roman characters in
their documents.
   So why not create a new category of document parts, in the same way
as may be graphics, tables, headers, footnotes, etc., are part of the
document. As for graphics, where e.g. Word 3.0.x just lets Quickdraw
draw a picture on screen or paper without caring about its contents,
text in non-roman scripts could be treated in a similar way. Instead of
calling Quickdraw, the WP would call TextEdit. As the script depends on
the font, it is very easy to make this changement between WP code and TE
(allmost) transparent. Also, speed is not affected for pure Roman-Script
users, because in this case the only additional check needed is to see
wether a font selected by the user has script Roman or not.
   For users that just want to insert small blocks of foreign text, e.g.
linguists that write an English thesis with foreign-language examples,
the preformance degradation will not be significant, but the additional
functionality very, very valuable.
      (This is, with some tricks, allmost
       possible in WriteNow (don't know about the other WP). Using a
Script
       Manager compatible draw program, you 'draw' the text you want,
then cut
       and paste it into the document as an inline graphic.
Unfortunately,
       the margin for the inline graphic is too big and blows up the
corresp.
       lines, but I am shure there are ways to correct this.)
   For users that write a document completly in a non-roman script, the
speed, as well as the functionality, will degrade, but this will depend
on the properties of the individual script. A lot of the nice features
of the WP can still be used, although sometimes not without tricks.
Tabulators for example, not included in the new TE, can be used by
taking a tab in a Roman-Script font.
   As for users with languages like Finish, German, French, etc., where
the script is the same as for English, and where the main problems are
spelling and hyphenation, most WP nowadays have two alternative
dictionaries for British and American English, and if some additional
code (for different scanning strategies/word endings) is included in
these dictionary files instead of being built into the WP, it will not
be very difficult to internationalize these programs.
      (I'm not considering the economic
       aspects (how many users are needed to make producing a foreign
dictionary
       profitable) nor the linguistic aspects (spelling checkers are
much more
       difficult for most other languages than for english), but only
the
       software engineering aspects, which seem to be farely simple.)

This is only an idea, and I don't know if it really works, but if not, I
would like to hear why not. Also, if any (or many, or all) WP companies
want to adopt any of the ideas in this article, please feel free to do
so (the sooner, the better).
--
Martin J. Duerst, Graduate Student,
Kunii Lab., Dept. of Inf. Sc.,
Fac. of Sc., Univ. of Tokyo
7-3-1 Hongo, Bunkyo-ku, 113 Tokyo, Japan

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

End of Usenet Mac Digest
************************

ACTION>