[fa.info-mac] INFO-MAC Digest V3 #40

info-mac@uw-beaver (09/14/85)

From: Moderator Richard M. Alderson <INFO-MAC-REQUEST@SUMEX-AIM.arpa>


INFO-MAC Digest          Friday, 13 Sep 1985       Volume 3 : Issue 40

Today's Topics:
                            SUMacC for Apollo
                       Problem with DA-DELETE.HCX
                       VI Mode for Microsoft Word
                      MenuClock shareware/freeware
                     Command Key Bindings (re: RFC)
                  How does one write a printer driver?
                      QuickDraw timing info needed
                      QMS laser printer and the MAC
                              File Servers
                               Book review
                      Sources from ARPAland, again


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

Date: Fri, 6 Sep 85 10:57:54 EDT
From: Eric_Shapiro%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: SUMacC for Apollo

We have SUMacC running on a single Apollo node.  We'll bring it to a few others
when Apollo sends us a final release of their UNIX system (already two weeks
late).

  -Eric Shapiro, Univ. of Michigan

If you didn't know already, Paul Killey is the one to talk to with porting
questions if anyone else is trying to use SumacC with the Apollos.

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

Date: Wed, 11 Sep 85 17:50:22 EDT
From: David M. Krowitz <DAVID@MIT-MC.ARPA>
Subject: Problem with DA-DELETE.HCX

there seems to be a small problem with the DA-DELETE.HCX file in the Info-Mac
program library.  The file has no line-feed characters following the
carriage-returns in the file.  This causes some machines (in particular a
VAX/VMS machine that I downloaded software into my Mac with) to choke on the
file.  Perhaps some line-feed characters should be inserted into the copy of
the file that is in the <INFO-MAC> directory ...

						Dave Krowitz
						( DAVID@MIT-MC.ARPA )

[I have taken care of this.   --RMA]

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

Date: 13 Sep 85 (Fri) 14:13:50 EDT
From: Dan Winkler <daw%brown.csnet@CSNET-RELAY.ARPA>
Subject: VI Mode for Microsoft Word

Here is Mark Stowe's VI Mode for Microsoft Word.  The first file in this letter
is vmode.doc, a description of the system, and the second is vmode.Hqx, a
binhex copy of the DRVR itself.

Dan.

[These files are to be found under [SUMEX]<INFO-MAC>DA-VMODE.HQX and
DA-VMODE.DOC, respectively.  --RMA]

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

Date: Thu, 12 Sep 85 12:15:19 pdt
From: oster%ucblapis.CC@Berkeley
Subject: MenuClock shareware/freeware

Here is Menu Clock.  Yet another clock.  This one produces a simple digital
time display on the right hand side of the menu bar.  It is free for your use
and distribution, no strings attached.  However, it contains an advertisement.

If you register your copy of Menu Clock with the author, and pay the
registration fee, you recieve a reference card describing how to make the clock
be part of your system startup.  This allows you to throw away the rather large
menu clock install program from your working disks.

Menu clock differs from the other clocks in that you turn it on and forget
about it.  It takes up no room on the desk top, and doesn't go away when you
change system disks or applications.

Menu Clock is compatible with every configuration and every piece of software
I've ever seen except:

1.) Screen Blacking programs that call SystemTask while the screen is black (I
use sleep1 myself - later versions of sleep call systemTask, but the original
didn't)

---
The clock was designed to be unobtrusive: small, out of the way, and letting
all input be handled by what used to handle it.  If a menu needs to use that
portion of the menu bar, that's okay, the menu is still active.  It sits beside
the switcher icon, not on top of it.

Here it is, in two files in Hqx format:
(the files are concatednated together into a unix Shell archive - you
can split them with a text editor if you aren't on Unix)

[These two files are archived on SUMEX as <INFO-MAC>DA-MENUCLOCK.HQX and
<INFO-MAC>DA-MENUCLOCK-DOC.HQX.  --RMA]

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

Date: 08 Sep 85  1636 PDT
From: Tovar <TVR%CCRMA@SU-AI.ARPA>
Subject: Command Key Bindings (re: RFC)

My only request for a "standard" on these matters is that bindings be made in
the resource file, not in the code, whenever feasible.  It's tempting to CONS
up your own menus, but as has been stated before, this wreaks havoc with those
who would want to use a Mac in a language other than English.  Putting the
bindings in the menu not only allows them to be changed for use in other
countries, it also allows more knowledgable users to customize applications
according to their own particular habits.  (It also helps relieve some of the
symptoms of too-many-different-systems-disease among us who don't use Mac's as
their primary computer--i would have had great difficulty using Gosling EMACS
[an editor under UN*X] if it had not been possible to redefines some of
commands).  Remember, the idea of putting things into the resource files is to
allow some behaviors and appearences to be changed without changing (or even
possessing) the source code.

While i respect Leovitch's remarks and recognize that there are many machines
out there with old ROMs that will never be changed, that doesn't mean we have
to perpetuate a mistake into eternity.  Nor does putting things into resources
solve the problem for desk accessories.  But it's a step in the right
direction, and perhaps if even Apple might fix the ROM someday, especially if
most programs follow a particular standard.

							-- Tovar

P.S.  Speaking of annoying ROM features, does anyone know how to turn off
accent prefixing so the OPTION key can be used as a META key in a terminal
program?  (Reply to TVR@SU-AI; i will summarized if requested.)

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

Date: 6 Sep 1985 17:24-EST
From: mss%dartvax%dartmouth.csnet@csnet-relay.arpa
Subject: How does one write a printer driver?

I am trying to write a new printer driver.  The Printer Manager seems to leave
out a lot of details.  It implies that the control calls that the driver will
receive are simply "print bitmap", "print uninterpreted character codes" and
some carriage control (CR with a specified number of vertical movement in
dots).  I'm sure there is more to it than that--in fact, I expected to have to
respond to all quickdraw calls, or at least specify which I can handle and
which I want quickdraw to translate into a bit map for me.  If I want to take
advantage of my printer's high level printing commands (Postscript level), do I
have to install my own basic Quickdraw routines when my driver is setup so that
I can change them into appropriate "character commands"?  Can someone tell me
where this information is hidden?
					-Mark (mss@Dartmouth.csnet)

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

Subject: QuickDraw timing info needed
Date: 08 Sep 85 08:21:38 EDT (Sun)
From: zim@mitre.ARPA

I am experimenting with various animation tasks on the Mac and need help:

  --> How long do various QuickDraw operations take? <--

Answers could be narrow and specific (e.g., 'to invert a region shaped like a
doughnut 200 pixels across takes 10 ms') or general (e.g., "polygon painting
takes time proportional to the number of vertices to the 5th power", etc.).  I
don't need extraordinary precision, but just an order-of-magnitude idea for how
long 'typical' things take, so I can design algorithms to run as efficiently as
possible.

For instance, if region arithmetic is much slower than clearing the screen, I
don't want to spend time computing the regions to be changed from one frame of
the animation to the next...I should just redraw the new shapes, maybe.

I haven't seen answers to this published, so would appreciate pointers to the
archives or to the literature elsewhere.  In attempts to replicate an Atari ST
demo (smooth transformation of one filled polygon into another) I've had bad
problems with glitching/shearing as region and polygon operations take more
than 1/60th of a second when the areas involved are large.

Many tnx! ^Z

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

Date: 6 Sep 1985 10:11-EDT
Sender: WEINSTEIN@BBNG.ARPA
Subject: QMS laser printer and the MAC
From: WEINSTEIN@BBNG.ARPA

My preliminary report on using the QMS laser printer instead of an Apple
laserwriter was perhaps a bit too rosy.  Here are some residual problems:

1. The smoothing algorithm does not work.  In fact, you must turn smoothing off
when printing, or else nothing will come out of the laser printer at all.

2. The Postscript-equipped QMS laser printer is apparently incapable of running
at faster than 9600 baud yet.  That means its speed is communications-bandwidth
limited, and it is excruciatingly slow (i.e., several minutes per page).  I
suspect it is even worse in this regards than an Apple Laserwriter.

3. There is a bug in the laserwriter$_header file on info-mac.  There should be
10 entries in the definition of "vrb" (lines beginning "/vrb"); instead there
are only 9 entries.  The missing entry is another repetion of the entry
{eofill}; it should be inserted before the line {initclip eoclip newpath} in
the definition of "vrb".  I got this out of the other version of this header
file archived on info-mac (laserwriter$_header.12, or something like that), but
I haven't gotten the latter to work yet for other, unknown reasons.

Unless this bug is corrected, it will be impossible to download bitmapped fonts
or print macpaint images, and the margin boxes of macwrite documents will
sometimes get printed as visible rectangles.

To get the Laserwriter driver, you must buy it from Apple.  I do not believe
you needed to buy a Laserwriter to do this, since you need one driver per
Macintosh but many Macintoshes can share a Laserwriter.  Also, there has been a
question as to what I meant by holding down the ^F key; I meant the Command-F
key, and one must press it and hold it down immediately AFTER clicking OK and
continue to hold it until the message "Creating Postscript file" appears.

However, until the speed problem on the communications interface to the QMS is
solved, I honestly do not recommend this arrangement for anything involving
printing of bitmapped images (including anything other than the built-in
laserwriter fonts).

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

Date: Fri 6 Sep 85 18:40:19-CDT
From: Chris Teo <CL.MAC.TEO@R20.UTEXAS.EDU>
Subject: File Servers

AT this moment there is only one file server for the Macintosh.  This file
server is produce by MicroDesign and is called the Keeper.  It is a great file
server and have many good points.  The rest of the hard dirves are disk server
basically.  You can find out more by calliing

MicroDesign
(512)-441-7890
6301B Manchaca Road
Austin, Texas 78745

If you need support, they even have a developers support plan and there are
rumors that Apple has a few of their file servers.

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

Date: Fri, 6 Sep 85 15:37:49 pdt
From: pdc750!pls (Paul Springer)
Subject: Book review

Forwarded for a friend (lcc!pdc750!pls@ucla-cs):


***  BUYER BEWARE ***

Micro Analyst Inc. (the makers of MacZap) are marketing a book entitled
SOFTWARE PROTECTION USING DISK FORMATTTING AND OPERATING SYSTEM MODIFICATION
MACINTOSH/APPLEII/IBM.  There is very little in here that is applicable to the
Mac, certainly not enough to develop a protection scheme on it.  Despite the
title, no mention is made of any Mac O/S modifications that can be made.  No
mention whatsoever is made of any Mac disk I/O routines or hooks into them.
There is a section on "Apple Sector Addressing", but it is left unclear as to
which portions of that are applicable to the Mac.  In fact if you follow the
guidelines in this section to write a sector onto the Mac, it just won't work.

In summary, don't expect to become an expert on Mac Software Protection after
reading this book.  Indeed, to quote their book, "The newer Macintosh computer
has little if any documentation on its disk operating system and hardware
setup.  In cases like this the protection systems are built from information
learned by trial and error."  By the way, they have no refund policy--I
checked.

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

From: davidl@teklds.UUCP (David Levine)
Subject: Sources from ARPAland, again
Date: 9 Sep 85 23:01:41 GMT
Reply-to: davidl@teklds.UUCP (David Levine)

Could some kind soul with the ability to do the mythical "anonymous FTP from
SUMEX" please post the following nifty programs to net.sources.mac?  Failing
that, if you can mail one to me I'd be glad to repost it.

                      Mockchart (tm) desk accessory
                       New SetFile desk accessory
                    WayStation - another mini-finder
                                IEdit 1.1
                  finder application parameters library
                               Teleport DA
                   Bill Atkinson's QuickFile (Rolodex)

These have all been mentioned in the last few 'fa.info-mac' digests, but have
failed to appear (so far) on net.sources.mac.  It seems our friends in ARPAland
are failing to gateway to us again.  GRR!

If you can get through to INFO-MAC-REQUEST@wherever, please forward this
message to him (it?).  For reasons unknown, messages from me to the ARPAnet
generally bounce off the interface and land in my lap.

David D. Levine  (...decvax!tektronix!teklds!davidl)          [UUCP]
                 (teklds!davidl.tektronix@csnet-relay.csnet)  [ARPA]

P.S.  To all those who selflessly post nifty things to net.sources.mac, THANKS!
Your efforts are appreciated.

********
(I posted the requested files for him -- Bill Tomczak)
Return-Path: <tomczak@harvard.ARPA>

[My thanks to Mr. Tomczak, and my apologies to all those in uucp-land who have
been frustated by the lack of postings from here.  I've finally figured out how
to send things along, so I won't be the cause of such gnashing of teeth in
future.  --RMA]

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

End of INFO-MAC Digest
**********************