info-mac@uw-beaver (07/14/85)
From: Temporary Moderator Rich Alderson <INFO-MAC-REQUEST@SUMEX-AIM.arpa>
INFO-MAC Digest Sunday, 7 Jul 1985 Volume 3 : Issue 19
Today's Topics:
macafrica
Resource decompiler from net.sources.mac
New SUMacC rmaker available
multi-window text presentation -- BTW demo MacFORTH program
MS WORD update
Cap lock key & Kermit
Getting started with Binhex
The Word on Word
Agreement between Apple & GCC
LaserWriting Mac files (more on Laser Prep)
AppleTalk and LaserWriter protocols
Security of LaserWriters
Multivision Terminal Emulator
----------------------------------------------------------------------
Date: Fri 5 Jul 85 17:07:27-PDT
From: PIERCE@SRI-KL.ARPA
Subject: macafrica
I talked to Dave Wilson about the date change. He would like the
money in his hand by wednesday and a call to him by tuesday morning at
the latest. Any calls after that MIGHT mean that space is not
available or a copy of the book is not printed.
I hope this doesn't come too late.
Pierce@SRI-KL
------------------------------
Date: Thu, 27 Jun 85 12:31:42 edt
From: Alan Crosswell <alan%cucca@columbia.arpa>
Subject: Resource decompiler from net.sources.mac
This program (rekamr) was posted to net.sources.mac a while ago, but I
don't think it ever made it into [SUMEX]<INFO-MAC>. So, here it is,
with my own addition to decompile the POST resource used in the "Laser
Prep" file. I also had to change the case of some of the #defines
referenced in it since they didn't match the ones in our versions of
the header files which I believe come from <info-mac>.
I've also sent the corresponding additions for rmaker to Bill Croft,
so those should be available shortly as well. I will send a seperate
posting to Laser-Lovers outlining what I have learned about trying to
print Mac-generated PostScript files over RS232.
Alan Crosswell Columbia University
[This file is archived in [SUMEX]<INFO-MAC>REKAMR.C --RMA]
------------------------------
Date: Sun, 7 Jul 85 00:11:51 cdt
From: brian@ut-sally.ARPA (Brian H. Powell)
Subject: New SUMacC rmaker available
"Welcome to the Wonderful World of Source Code Maintenance", he
said. Okay, so there were at least two versions of rmaker out there.
And people keep adding code to one or the other. What to do; what to
do?
I complained, so I got the job.
There is a new version of rmaker available. This version
replaces the current version of rmaker.shar on SUMEX. It replaces
some lost bug fixes and additions and I've also added some code of my
own. Below, I've included the README file from the rmaker.shar file
(presumably available from SUMEX-AIM in <INFO-MAC>RMAKER.SHAR). There
is also a new rmaker.doc file to replace the (now-defunct) Inside Mac
manual "Putting Together a Macintosh Application." This new file
contains specifics on this version of rmaker.
Here is the README file from rmaker.shar:
As some of you have noticed, there is more than one version of
the SUMacC rmaker out there. This is an attempt to combine all
versions.
Summary of changes to rmaker:
Work done by Croft:
fix fwrite bug and add INIT and PACK resource types.
Work done by Maio/Schilit:
no NULL in DRVR name if device driver. Work done by Moy:
Implement CDEF, MDEF, WDEF and modify DRVR for dynamic
relocation.
Work done by van Rossum:
Added STR# resource types.
Work done by Crosswell:
Added POST (PostScript) resource type.
Work done by Horvath:
Added backslash escape sequences for strings.
Work done by Powell:
Combine all of above work.
Modify INIT and PACK to use dynamic relocation.
Added FKEY and PROC resource types.
Fix minor bugs in backslash code.
_______________________________________________________________________________
The dynamic relocation work done by Moy requires the use of
special crt*.s files for DRVR, PROC, CDEF, MDEF, WDEF, INIT, PACK and
FKEY types. For DRVR's, use crtdrvr.s (which is included in the shar
file) as an example. For the others, use crtproc.s (also included) as
an example.
[The rmaker file is available for anonymous ftp from ut-sally as
"mac/rmaker.shar".]
------------------------------
Subject: multi-window text presentation -- BTW demo MacFORTH program
Date: 07 Jul 85 18:47:59 EDT (Sun)
From: zim@mitre.ARPA
For the last 6 months or so, inspired by Xerox PARC's "NoteCards",
I've been working off and on with developing a system to present
information through Macintosh windows linked by buttons. ((Ask me if
you would like to see some net correspondence on this--many parallels
with Ted Nelson's HyperText, Randy Trigg's TextNet, etc.))
I finally realized that instead of writing an interpreter of my own to
do what I want, I should use MacFORTH's LOAD command on a FORTH blocks
file; each button is associated with a screen number to be LOADed when
that button is pressed. (The REFCON field is a convenient place in
the control record to save this screen number.)
A little (11K) CONVERT format demo program is appended to this note;
it works in Level 1 or 2 MacFORTH (Kernels 1.2 or 2.3) and requires no
auxiliary files. I'm happy to correspond with anybody who wants more
details.... -z
[This demo has been archived on <INFO-MAC>DEMO-NOTEMAKER.4TH at SUMEX.
--RMA]
------------------------------
Date: Mon 1 Jul 85 16:28:54-PDT
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: MS WORD update
I just received a letter from Microsoft offering WORD 1.05 for $15 to
current Word owners. The improvements are claimed to include:
400% speed up in laserwriter printing of word filefs
a utility to transfer back and forth from IBM to MAC word
files keeping formatting intact.
btw, the update is free to those who bought a backup disk for $10
before 4//85.
mark
------------------------------
Date: Fri 28 Jun 85 15:52:03-EDT
From: Mauricio Matiz <US.MATIZ@CU20B.ARPA>
Subject: Cap lock key & Kermit
Now that Kermit for the Macintosh has a keymap program that allows
mapping of the control key to the caps lock key, the locking mechanism
becomes a nuisance. There have been postings about taking the whole
keyboard apart and using a soldering gun, etc. in order to remove the
locking mechanism. I have come up with a simpler and easier method
that does not void your warranty.
Remove the key using a small screwdriver. There is a spring and the
end of it goes through the plastic that supports the key. Stick a
piece of paper or soft putty (very small) between the tip and the
bottom of the keyboard. This will prevent the key from depressing all
the way and locking, but still allow contact of the key. It even
works for repeating control characters. If you come up with a better
substance to stick in there let me know (or the Kermit people at
Columbia). I have been using this for some time with no problems. I
imagine that after a while I will need to change the paper because of
the continued pressing on it.
Maurice Matiz
Columbia University
User Services
[Disclaimer: Neither the Kermit distributors at Columbia, nor the
Info-Mac moderator, advocate making this modification to your
Macintosh. The information is being provided as a public service.
--RMA]
------------------------------
Date: Sat, 6 Jul 85 16:30:37 pdt
From: barry@playfair (Barrett P. Eynon)
Subject: Getting started with Binhex
In response to the recent request for how to distribute Binhex with
the Kermit tapes, here's a copy of version 2.0 of MakeMakers which was
just released on Compuserve (in hqx format). MakeMakers takes any
application file, and produces a MS-BASIC (decimal) and MacPascal file
each of which when run under the appropriate interpreter, will
reproduce the original application. The following messages contain
binhex4.bas and binhex4.pas, the results of running MakeMakers on
binhex version 4. Hope this simplifies things.
-Barry Eynon
[I have archived these files as <INFO-MAC>UTILITY-MAKE-MAKERS.HQX,
<INFO-MAC>UTILITY-BINHEX4.BAS, and <INFO-MAC>UTILITY-BINHEX4.PAS on
SUMEX.
However, I don't think they address the problem of the Kermit
distributors. They can send BinHex along on their tapes in any number
of ways; the question they posed is, how are their customers most
likely to be successful at transferring it from 9-track 1/2" magnetic
tape to Macintosh disks? Any answers? --RMA]
------------------------------
Date: 2 Jul 1985 11:02-EDT
From: Henry.Kautz@rochester.arpa
Subject: The Word on Word
I wrote to Microsoft and asked about the file format used by Word. I
wanted to write some filters to ease conversion between special fonts
(e.g., to painlessly convert Princeton to Symbol). They responded
that the file format used by Word is proprietary information. "Some"
information may be released to developers licensed through their
"Independent Software Vendor" program. (They didn't give an address
or name to contact for information on ISV. The definite implication
is that you are talking about $$$$ and all kinds of legal
entanglements.)
Sigh. Why isn't anyone (to my knowledge) working on a truly good
editor for the Mac, when word processing is the thing it does best?
Is everybody out their really that satisfied with MacWrite and Word?
(Incidently, my friends who own IBM PC's told me that editors which
encrypt their files, and have proprietary formats, have long since
vanished in the dust. They were rather suprised to hear that Mac
software had gone that route...)
---- Henry Kautz
:uucp: {seismo|allegra}!rochester!henry
:arpa: henry@rochester
:mail: Dept. of Comp. Sci., U. of Rochester, NY 14627
:phone: (716) 275-5766
------------------------------
Date: Sat, 6 Jul 85 12:37 EDT
From: Gary.Feldman@CMU-CS-A.ARPA
Subject: Agreement between Apple & GCC
A recent article in one of the trade weeklies (Electronic Industry
News, or something similar) indirectly quotes Apple Pres. Sculley as
claiming that Apple and General Computer reached an agreement whereby
authorized Apple Dealers can install the GCC Hyperdrive without
voiding Apple's warranty. Let's hope this is a sign of things to
come.
Gary
------------------------------
Date: Thu, 27 Jun 85 18:34:25 edt
From: Alan Crosswell <alan%cucca@columbia.arpa>
Subject: LaserWriting Mac files (more on Laser Prep)
Here's a little more news on getting Mac documents to print when the
LaserWriter is not running on AppleTalk (i.e. is on RS232).
First, a brief summary of what's been said about this stuff so far:
1) To get the PostScript source of a Mac document, hit Command-F and
hold it down for a while just after you select print from whatever Mac
application you are in. Instead of "Looking for LaserWriter" and
printing the document, the LaserWriter driver will create a file named
"postscript" which contains the file that is normally sent over
AppleTalk to the printer. This is a valid PostScript file, but it is
missing something: the definitions of the PostScript macros that it
invokes (which are in the "md" dictionary).
2) The PostScript macros are defined in the "Laser Prep" file which is
in the System folder of a "Laserized" disk. They are stored as
resources along with some other stuff (more on this later). Brian
Reid posted these PostScript definitions recently along with a lot of
very helpful comments.
Now, what I can add to this:
1) Brian posted version 13 of Laser Prep, but the version I got out of
a LaserWriter box just last week is version 12. I had trouble getting
his version 13 to work. The version number is in "av" in the md
dictionary. Here's a program to print it:
%!
md begin
/Times-Roman findfont 12 scalefont setfont
100 720 moveto
(md version is: ) show
av ( ) cvs show
showpage
end
2) I have recently sent modified versions of rekamr, the resource
decompiler, and rmaker, the resource compiler, to info-mac with
support for decompiling and compiling the POST resource which is in
the Laser Prep file. Using them you can get your own PostScript
definitions out whenever you get a new Laser Prep (and you can modify
them). Here's a summary of what (interesting) resources are in Laser
Prep:
LROM - I dunno, but sounds like something to do with the PostScript
ROM version to me.
POST - There are several of these. They contain the text of the
PostScript commands. Each POST resource has the following format:
1st 2 bytes: (binary) number of strings that follow
followed by: the above number of pascal strings (1st byte
length and then data).
Each string consists of one line of PostScript text.
PSHX - A bunch of binary data. This may very well be 68K code or
"compiled" PostScript.
When you look at the decompiled POST resources, you see that the last
statement is "currentfile eexec". Now, there is no "eexec" command
documented in Inside LaserWriter that I could find. There is an
"exec" command which executes commands from an input file whose handle
is on the stack.
By spying on the AppleBus with Peek, the sequence of data sent to the
LaserWriter consists of all the POST's followed by the PSHX converted
to hexadecimal. This hex is immediately preceded by the "currentfile
eexec". More on this later....
3) I popped into Emacs with the decompiled Laser Prep and did some
minor editing to toss everything but the PostScript stuff and comment
out the exitserver like Brian did. I also commented out the
currentfile eexec. I then cat'd this file with output from MacPaint
(using the command-F) and shipped them all down to the printer with
MacTerminal. It worked! But ONLY when I set the smoothing argument
of "dobits" false (see Brian's commented Laser Prep).
4) When smoothing was true (this is the difference between draft and
final mode of the MacPaint print command by the way), the printer
complained that the "smooth" command was undefined. Now, Brian
mentioned that the smooting function is proprietary, and, since it is
not "built in", my guess is that the PSHX resource contains the code
that implements it. So, to get things to work completely, you will
probably have to dump the hex down also. I haven't tried this yet but
will report on my success or failure shortly.
5) The next step is to get this working with the Scribe picture
command without trashing the environment. This looks fairly
straightforward, but you never know 'til you try it. I think one
thing that I will end up doing if I use this with RS232 and scribe is
put it into the permanent VM (i.e. exitserver) since it takes an awful
long time to send the PostScript and hex down once for each job. You
can also run the machine under Appletalk and kermit your scribe output
down to a Mac and use the Inside LaserWriter downloading program to
print it (or get a SEAGATE!).
Alan Crosswell Columbia University
------------------------------
From: stew%lhasa@harvard.ARPA
Date: 28 Jun 85 21:09 EDT
Subject: AppleTalk and LaserWriter protocols
Does anyone have the interfaces for these protocols in source form? I
want to use the Printer Access Protocol (PAP) described in Inside
LaserWriter, and I realized that I don't have any way of calling
things like PAPOpen, PAPWrite, etc... In fact, the binaries for these
things were not included on the disks that came with either the
Software Supplement or Inside LaserWriter. Do they come with Inside
AppleTalk? I was hoping I didn't need that... But since I am using
MegaMax C, not a Lisa, the binaries aren't even enough. I need source
that I can translate. The alternatives are 1) Writing a text file and
downloading with the utility that came with Inside LaserWriter or 2)
Disassembling that utility. Someone, please save me from that!
Stew
------------------------------
Date: Thu, 4 Jul 85 20:38:46 pdt
From: Vincent Manis <manis%ubc.csnet@csnet-relay.arpa>
Subject: Security of LaserWriters
We're going to be putting a LaserWriter in a student lab and we're a
bit nervous about it. In particular, we're worried that some
relatively hefty student might just walk away with it. There appears
to be no way of attaching a security kit to it, and we're a bit
nervous about drilling holes in the case and the like.
We'd be grateful for any suggestions.
Vincent Manis Department of Computer Science University of British
Columbia
------------------------------
Date: 1-Jul-85 22:51:20-PDT
From: sml@FORD-WDL1.ARPA
Subject: Multivision Terminal Emulator
I attended a demo of Multivision by Rammas Vision on 6/27 in
Sunnyvale. This product is to run on a Macintosh or IBM PC and allow
multiple active terminals, each running in its own window, when
connected to Unix (4.2 or System V), VMS, AOS/VS, or VM through an
RS232 connection. Terminals emulated include the VT100, HP2621, D200,
Tektronix 4014, and dumb tty.
The demo was of a pre beta version on the Mac and a mockup of the
interface under GEM on the PC. The pre-beta version could only
emulate a dumb tty. Multiple connections to a Unix host was
demonstrated. Beta testing is scheduled to begin July 1 and end July
15, a schedule which sounds rather short. The beta version is claimed
to have full functionality. Again the time between the demo of this
partially operational version and the "full function" beta version
seems short.
The product did indeed create multiple terminal windows to a Unix
system. A program on the Unix hosts manages pseudo-terminals which
are directed to the various windows. All screens are concurrently
updated. Each pull down menu has a help function for that menu. Help
pops up in a "normal" type of Mac window with the standard scroll bar
control. Available via a menu or an icon bar in the top of the window
were options to expand the window to full screen or to shrink it to
various sizes and locations. The normal window dragging and
stretching is available. Display of the icon bar is to be an option.
A window could be completely closed. An appropriate icon is displayed
and the window is still active. Commands (macros) may be defined for
a pull down menu. Plans are to allow for arguments and prompting.
Also planned is the ability to choose from assorted font sizes to
allow a full screen to be displayed in a smaller window. The window
is a viewport into terminal virtual memory, allowing scrolling. File
transfer will also be supported. It is unclear whether they will use
just their own protocols (these already exist because of the required
support on the host end) or also support others. I look forwards to a
demo of multiple emacs' running to different windows.
Product announcement for Mac and PC to Unix 4.2 is scheduled in July
with the Mac version to ship in August and the PC version in
September. The System V.2 version is scheduled for October. Other
systems will are scheduled to follow. Rammas Vision hinted of
smalltalk inspired products to follow.
Multivision as demonstrated was real but incomplete. The beta test
cycle seems to be rather short. There is great potential for this to
become the product that I would like to use when using my Mac to talk
to my Unix system. This may be an excellent tool in an environment
where a Mac or PC must be connected to a host. The power user can
have a multiple window connection to a host. The casual user can be
supported by a macro capability to provide desired functions from the
host.
Pricing is not yet totally decided. They expect to establish site
licenses with large customers. The Mac or PC disk is expected to be
$189. Prices for the Unix (or other OS) end were less definite.
Mentioned were $465 for a 4-8 user Unix box and $3000 for a 30-40 user
system.
Vendor information:
Rammas Vision Corporation
2685 Marine Way Shoreline 1325
Mountain View, CA 94043
(415) 969-2662
Standard disclaimor: My only relationship with Rammas Vision is as a
potential customer.
Steve Lazarus
(415) 852-4203
Ford Aerospace ...fortune!wdl1!sml (USENET)
MS X-20 sml@ford-wdl1 (ARPA)
3939 Fabian Way
Palo Alto, CA 94303
------------------------------
End of INFO-MAC Digest
**********************