INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (02/16/87)
INFO-MAC Digest Monday, 16 Feb 1987 Volume 5 : Issue 53
Today's Topics:
Re: Problem with MacDraw (and LaserWriter)
New standard Resource Type
Re: Look and feel copyright case [from Unix-Wizards]
TransSkel: Proposed Changes
Function Keys and Inits
Unix program for MacDraw->Imagen (in 3 parts)
FontDisplay 4.6
Lord of the Rings Font
Conversion software
Diskette quality of the various brands
Usenet Mac Digest V3 #11
Usenet Mac Digest V3 #12
Usenet Mac Digest V3 #13
Delphi Mac Digest V3 #11
----------------------------------------------------------------------
Date: Thu, 12 Feb 87 16:46:35 mst
From: dlc@LANL.ARPA (Dale Carstensen)
Subject: Re: Problem with MacDraw (and LaserWriter)
Two ideas:
1. You didn't list the version of your LaserWriter driver or LaserPrep.
Maybe a newer version has your bug fixed.
2. You could download the Adobe dump routine. Here's a copy in case you
don't have it:
%!
% lib/ehandler.ps -- Downloaded Error Break-page handler
% Copyright (c) 1984, 1985, 1986 Adobe Systems Incorporated.
% All Rights Reserved.
% RCSID: $Header: ehandler.ps,v 2.1 85/11/24 12:20:03 shore Rel $
% Change or remove this section to use ehandler.ps on a job-by-job basis.
0000 % serverloop password
/$brkpage where
{pop pop(Error Handler in place - not loaded again\n)print flush
stop} %aborts to end-of-job.
{dup serverdict begin statusdict begin checkpassword
{(Error Handler downloaded.\n)print flush exitserver}
{pop(Bad Password on loading error handler!!!\n)print flush stop}ifelse
}ifelse
/$brkpage 64 dict def $brkpage begin
/prnt
{dup type/stringtype ne{=string cvs}if dup length 6 mul
/tx exch def/ty 10 def
currentpoint/toy exch def/tox exch def 1 setgray newpath
tox toy 2 sub moveto 0 ty rlineto tx 0 rlineto 0 ty neg rlineto
closepath fill tox toy moveto 0 setgray show}bind def
/nl{currentpoint exch pop lmargin exch moveto 0 -10 rmoveto}def
/=={/cp 0 def typeprint nl}def
/typeprint{dup type dup currentdict exch known
{exec}{unknowntype}ifelse}readonly def
/lmargin 72 def
/rmargin 72 def
/tprint
{dup length cp add rmargin gt{nl/cp 0 def}if
dup length cp add/cp exch def prnt}readonly def
/cvsprint{=string cvs tprint( )tprint}readonly def
/unknowntype{exch pop cvlit(??)tprint cvsprint}readonly def
/integertype{cvsprint}readonly def
/realtype{cvsprint}readonly def
/booleantype{cvsprint}readonly def
/operatortype{(//)tprint cvsprint}readonly def
/marktype{pop(-mark- )tprint}readonly def
/dicttype{pop(-dictionary- )tprint}readonly def
/nulltype{pop(-null- )tprint}readonly def
/filetype{pop(-filestream- )tprint}readonly def
/savetype{pop(-savelevel- )tprint}readonly def
/fonttype{pop(-fontid- )tprint}readonly def
/nametype{dup xcheck not{(/)tprint}if cvsprint}readonly def
/stringtype
{dup rcheck{(\()tprint tprint(\))tprint}{pop(-string- )tprint}ifelse
}readonly def
/arraytype
{dup rcheck{dup xcheck
{({)tprint{typeprint}forall(})tprint}
{([)tprint{typeprint}forall(])tprint}ifelse}{pop(-array- )tprint}ifelse
}readonly def
/packedarraytype
{dup rcheck{dup xcheck
{({)tprint{typeprint}forall(})tprint}
{([)tprint{typeprint}forall(])tprint}ifelse}{pop(-packedarray- )tprint}
ifelse
}readonly def
/courier/Courier findfont 10 scalefont def
/OLDhandleerror errordict /handleerror get def
end %$brkpage
errordict
/handleerror
{systemdict begin $error begin $brkpage begin
%Note -- newerror is created in $error by all default error operators.
newerror
{/newerror false store
vmstatus pop pop 0 ne{grestoreall}if initgraphics courier setfont
lmargin 720 moveto(ERROR: )prnt errorname prnt
nl(OFFENDING COMMAND: )prnt/command load prnt
$error/ostack
known{nl nl(STACK:)prnt nl nl $error/ostack get aload length{==}repeat}if
systemdict/showpage get exec
/newerror true store/OLDhandleerror load end end end exec}{end end end}
ifelse}
dup 0 systemdict put %bind true systemdict value
dup 4 $brkpage put %bind true $breakpage value
bind readonly %lock it up
put %into errordict
------------------------------
Date: Thu, 12 Feb 87 22:34:55 EST
From: "Richard S. Palais" <PALAIS%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: New standard Resource Type
I have a suggestion for a new standard Resource Type,
to be called HELP.Eachresource of type HELP would be a single str255.
Any number of HELP resources could be added to an application
(or to the Resource Fork of a document).Each HELP resource
would give help on using some feature of the application, and
would have a mnemonic name referring to that feature.
An application with HELP resources would put up a HELP
menu on the menu bar using AddResMenu, so all the available
HELP item names would appear as items on this menu. When a
user chooses an item from this menu, a new HELP Manager would
put up a dialog box displaying the associated HELP string.
I see at least two advantages :
% There would be a uniform user interface to on-line documentation.
% It would become a piece of cake for developers to add basic
documentationto new applications
(using say REdit or ResEdit), SO
THEY WOULD BE MORE LIKELY TO DO IT.
The present method of attaching documentation to About...
screens is very un Mac-like in my opinion...everyone does it
differently, you donUt even know if its there if,like many users
you donUt bother to pull down the Apple menu, and it takes one
more special effort on the part of a developer.
------------------------------
Date: 14 Feb 87 1224 PST
From: Tovar <TVR%CCRMA-F4@SAIL.Stanford.EDU>
Subject: Re: Look and feel copyright case [from Unix-Wizards]
In Patent Number 4,464,652, Granted to Apple Computer on August 7, 1984,
entitled Cursor Control Device for use with Display Systems, Pull-Down
menues are covered by claim number 11. Thus, it is not possible to
duplicate Apple's Pull Down Menu Interface without infringing on this patent.
Remember, Patents do (and should) offer a stronger form of protection than
copyrights.
I'm sorry, i can't get very excited about this one. Having hacked various
types of machines which use mice, if anything, i find them annoying. On a
limited resolution, landscape mode screen, they consume valuable display real
estate and require extra hand motion to get to. As far as i'm concerned, they
aren't very innovative, except maybe to the naive users (to whom they might be
quite valuable), and do not at all compensate for the incredible choice of
only one button on their mouse. Two button mice are bad enough, and perhaps
the single button is why they had to "invent" this thing. To me, it's worse
than pop-up menus because you have to move the mouse so much (which will be
even more intensive on the new, larger screens). All this for "modelessness".
The innovative thing they did do wasn't the pull-down aspects of the menus
at all, but rather defining [and allowing a hacker to redefine] a keystroke
to correspond to a menu item. I'm sure it's been thought of before, but
Apple put it out as a part of a high visibility product.
Come on Apple, wise up. If you think you can get away with 5 grounds on a
SCSI port where everyone else uses 30 grounds, and have flushed the other 9
pin connectors, you can certainly recycle one of the two grounds on the
mouse's 9 pin connector to at least give us two mouse buttons! Better yet,
use the same connectors and pinouts as the other folk, and make some extra
money selling less expensive, easier to maintain mice to everyone else.
[My apologies to some Unix-Hackers for perhaps diverging somewhat from the
topic of that list, but several of you have, shall we say, managed to "push
my buttons"...]
------------------------------
Date: Wed, 11 Feb 87 09:10:27 CST
From: Paul DuBois <dubois@unix.macc.wisc.edu>
Subject: TransSkel: Proposed Changes
Proposal for Changes to TransSkel
1. Introduction
This document proposes a set of modifications to be made to the
TransSkel transportable application skeleton. The purpose of the
modifications is to correct a design deficiency in port-setting
behavior. To motivate the discussion, a model of "proper" port
behavior shall be specified, followed by a list of the changes
necessary to bring TransSkel into congruence with this model. This
list shall indicate how the current version violates the model and the
changes necessary to rectify the violation.
The fact that such a model has never been made explicit is itself a
deficiency. Had my thinking not been muddy in the first place, this
proposal might not have been necessary. My thanks to Duane Williams
for first pointing out my departure from orthodoxy.
As the proposed changes lead to some incompatibilities with existing
applications, I am requesting comment before proceeding. I should
emphasize that the incompatibities are well-localized, though, and host
applications are generally easily made compatible.
Readers who object to any or all of the proposed changes should say so,
and say why. Silence shall be taken as implicit assent.
The model is quite simple: The current port shall always be associated
with the frontmost (or active) window. This implies that persistant
changes to the current port are made only when a different window
becomes active, and that all other port changes take place purely
locally (i.e., the current port is saved before and restored after the
local port change).
The association of the current port with the active window is congruent
with the user's perception of the way the application works: most
actions are performed in the active window and those that aren't are
usually such as to bring another window forward. (From the user's
point of view, the port is changed by clicking in a window to bring it
to the front.) The local-changes-only clause of the model follows from
the description of SetPort in Inside Macintosh, which says: "Only
SetPort (and OpenPort and InitPort, which call it) changes the current
port. All the other routines in the Toolbox and Operating System (even
those that call SetPort, OpenPort, or InitPort) leave the current port
set to what it was when they were called."
I propose to make TransSkel adhere to this standard. Naturally,
TransSkel cannot do so without the cooperation of the host application.
As matters stand now, however, the host cannot follow the model whether
it wants to or not, because TransSkel itself violates it. This is an
unintended side effect of the guarantee TransSkel makes to window
handling routines that the port shall always be set to the affected
window when the routines are called. It turns out that if TransSkel
follows the model, the effect of the guarantee (to make sure the port
is set to the affected window) follows naturally, IF the host does not
itself gratuitously change the port. That is, those hosts that wish to
follow the model will be able to.
2. Description of Proposed Changes
2.1. Menu Handling Routines
No changes shall be made, as these do not directly affect the current
port.
2.2. Window Handling Routines - Non-dialog Windows
Each window handler comprises a set of routines for handling mouse, key
and closebox clicks, activate and update events, window disposal and
idle time. In addition, TransSkel's general event procedure
generically handles window growing and zooming.
Some of the changes below rely implicitly on the understanding that a
window is not deactivated until after it is activated and that activate
events have the highest priority.
2.2.1. Activate event handler
Current: If the window hander has a non-nil activate event handler, it
sets the port to the window and calls the procedure with an indication
of whether the window is coming active or going inactive.
Proposed: The port shall be set to the window if it is coming active,
whether the activate handling procedure is nil or not. Thus the
current port shall be set to that window, regardless of the action the
host takes in response to the event.
2.2.2. Update event handler
Current: Since updates may occur for any window (not just the active
one), the current port is saved prior to setting the port to the window
to be updated, and restored after calling the window's update
procedure.
Proposed: No change; the current behavior is correct.
2.2.3. Mouse click handler
Current: The mouse click handler is only invoked for clicks in the
content region of the active window. The port is set to the window in
which the click occurred, then the window's click handler is called.
Proposed: As the port has already been set to the window when it came
active, setting the port again is superfluous and shall not be done.
2.2.4. Key click handler
Current: Key clicks are passed to the key click procedure for the
frontmost window. The port is set to the frontmost window, then the
window's click handler is called.
Proposed: As the frontmost window is the active window, the port has
already been set to it when it came active. Setting the port again is
superfluous and shall not be done.
2.2.5. Closebox click handler
Current: The port is first set to the window in which the closebox
click occurred. If the window has a closebox handler, it is invoked,
otherwise the window is just hidden. The port is then set to the
screenport to avoid a dangling port.
Proposed: As only the closebox of the frontmost (active) window can be
clicked, the port is already set properly. Setting the port again is
superfluous and shall not be done. It is also unnecessary to avoid a
dangling port: if there is another window behind the one being closed,
it will come active and the port will be set to it. If not, there are
no windows, so it does not matter what the port is set to.
2.2.6. Window clobber handler
Current: This procedure is called by SkelRmveWind to dispose of the
window. The port is set to the window to be disposed of, and to the
screen port after disposal to avoid a dangling port.
Proposed: Since any window (not just the active one) may be disposed
of at any time, the current port shall be saved prior to setting the
port to the window to be disposed of, and restored after calling the
window's clobber procedure. In the case that the front window is being
disposed of, saving and restoring the port is harmless: if there is
another window behind the one being closed, it will come active and the
port will be set to it. If not, there are no windows, so it does not
matter what the port is set to.
2.2.7. Idle time procedure
Current: Since the idle procedure may be invoked for any window (not
just the active one), the port is set to the affected window before
calling its idle routine. The current port is saved before and
restored after doing so.
Proposed: No change; the current behavior is correct.
2.2.8. Window growing
Current: The window is grown, then the port is set to the window and
invalidated to generate an update event.
Proposed: A click in the grow region can only occur for the active
window, to which the port shall have already been set. Setting the
port again is superfluous and shall not be done.
2.2.9. Window zooming
Current: The port is set to the window to be zoomed before zooming it.
(ZoomWindow requires this.) Then the port is invalidated to generate
an update event.
Proposed: A click in the zoombox region can only occur for the active
window, to which the port shall have already been set. Setting the
port again is superfluous and shall not be done.
2.2.10. Summary
Only activate events shall set the port and leave it set. Mouse, key,
closebox, grow region and zoombox clicks shall not cause the port to be
set, as they are only relevant to the active window, to which the port
has already been set by the previous activate. Update, idle and
clobber procedures may be called for any window, so the port shall be
saved before and restored after setting the port to the affected window
and calling the handler routine.
2.3. Window Handling Routines - Dialog Windows
Dialog window handlers are comprised of event, closebox and clobber
procedures.
Dialog windows introduce a complication: The model relies on activate
events for proper port-switching, but activate events for dialog
windows are not seen directly (the Toolbox routine DialogSelect handles
them automatically with no explicit indication that it has done so).
Therefore, after IsDialogEvent is called but before DialogSelect is
called, the event must be checked and the port set if a dialog is
coming active. I assume that for other events, DialogSelect takes care
of saving and restoring the port properly itself.
2.4. Window Handler Installation
Current: When a handler for a window is installed, SkelWindow sets the
port to the window. SkelDialog calls SkelWindow, so the port is set to
any dialog for which a handler is installed.
Proposed: The port shall not be set.
*****************************************************
This change will make TransSkel incompatible with previous releases,
and will break existing applications built on top of it, if they draw
into a window or dialog immediately after installing its handler (i.e.,
if they rely on the port being set). The host shall be required to set
the port itself if it wishes to draw into the window before it comes
active.
*****************************************************
The proposed change will break, in particular, most of the demos
distributed with TransSkel, as well as TransDisplay and TransEdit.
---
Paul DuBois UUCP: {allegra,ihnp4,seismo}!uwvax!uwmacc!dubois
ARPA: dubois@unix.macc.wisc.edu
dubois@rhesus.primate.wisc.edu
------------------------------
Date: Sun 15 Feb 87 23:39:12-AST
From: Peter Gergely <GERGELY@DREA-XX.ARPA>
Subject: Function Keys and Inits
[Uploaded from MACKY BBS, Dartmouth NS, 1(902)466-6903]
In this document, there are four main files: JCLock, New SysAlert,
FKEYs and documentation. JClock and New SysAlert are INIT resources
designed to be put into your system folder and FKEYs is a FKEY Manager
document with seven FKEYs in it.
- Peter
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>INIT-ASSORTMENT.HQX
DoD
]
------------------------------
Date: Mon, 2 Feb 87 11:44:14 pst
From: Allan G. Weber <weber%brand@usc-oberon.ARPA>
Subject: Unix program for MacDraw->Imagen (in 3 parts)
This is part 1 of 3 of "drawimp", a program that runs on Unix to convert
MacDraw files into Impress commands for printing on Imagen laser printers.
Allan Weber
USC Signal and Image Processing Institute
(213) 743-5519
Arpa: Weber%Brand@USC-Oberon.ARPA
UUCP: ...sdcrdcf!usc-oberon!brand!weber
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UNIX-DRAWIMP-PART1.SHAR
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UNIX-DRAWIMP-PART2.SHAR
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UNIX-DRAWIMP-PART3.SHAR
DoD
]
------------------------------
Date: 9 Feb 87 22:00:06 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: FontDisplay 4.6
Name: FONTDISPLAY 4.6
Date: 9-FEB-1987 18:33 by JEFFS
[ Updated 9-FEB-1987 18:33 by JEFFS to version 4.6. Address change, LaserWriter
Cancel printing now works, couple alerts fixed. ]
[ Updated 14-SEP-1986 19:50 by JEFFS to version 4.5. This version features
Option Quit to not save text/options, better LaserWriter support, couple minor
bug fixes. ]
This is FontDisplay 4.5, a program that allows you to display and print files
containing fonts.
In addition to numerous bug fixes, version 4.5 features:
Sample Window text saved
Can now print Sample Window text as part of the Style Sheet
Indexed documentation with edit history
Better printing error messages
[
this version replaces version 4.5 in the archives.
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-FONTDISPLAY-46.HQX
DoD
]
------------------------------
Date: Mon, 9 Feb 87 11:15:25 PST
From: <DAVEG@slacvm.bitnet>
Subject: Lord of the Rings Font
From: <DAVEG@slacvm.bitnet>
Subject: Lord of the Rings Font
Date: Mon, 9 Feb 87 11:15:25 PST
[from usenet]
This is a 12-point font based on the Angerthas runes in Lord ot the Rings.
Date: 8 Feb 87 10:25:21 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Cirth Font
[ Uploaded from Delphi by Jeff Shulman ]
Cirth Font, created by Bill Andel. The Angerthas Daeron font as used in J.R.R.
Tolkien's "Lord Of The Rings" books. 48 point size only. Important to have if
you write lots of letters to dwarves.
[
these files have been combined into one Font/DA Mover document.
archived as [SUMEX-AIM.Stanford.Edu]<INFO-MAC>FONT-RUNES.HQX
DoD
]
------------------------------
Date: Sat, 14 Feb 87 16:10:33 MST
From: ZUC03AA@WYOCDC1.BITNET (SCOTT JOHNSON USER CONSULTANT
From: 766-5288)
Subject: Conversion software
I'm not on this mailing list so please send any correspondence to
me directly.
Prologue: We have files on a Macintosh built using MicroSoft Word.
We have files on a Zenith 158 micro in MicroSoft Word.
Both the Macintosh and Zenith have software which will
allow them to upload and download binary files from a
CDC 840 mainframe.
Problem: Is there any software available that will convert the
MicroSoft Word file on either machine so that it can be
read properly by MicroSoft Word on the other machine?
Epilogue: Failing the availability of any software, what is the
difference between the file structure of the two
MicroSoft Words?
Thanks
Scott Johnson
zuc03aa%wyocdc1.bitnet@wiscvm.wisc.edu
------------------------------
Date: 9 FEB 87 18:27-GMT
From: MACMAN%CZHETH5A.BITNET@wiscvm.wisc.edu
Subject: Diskette quality of the various brands
Long, very long time ago (two months), Tim Dowley [CML@IRISHMVS]
wrote:
> Has anyone a difinative review of diskette quality of the
> various brands ? ...
Steve Robiner [ur-univax!stro] at the Univerisity of Rochester
has made a poll last june on Usenet. The results were, shortly,
that Verbatim was extremely unreliable and that BASF wasn't
much better. The best scores were obtained by Apple, Sony and TDK.
We (at Macintosh Users Switzerland) use large disk quantities for
the PDS mailing service to our members. We have shifted through
several brands: Sony (excellent but expensive), Nashua (yuck!!!
leave them in the trashcan where they belong!) 3M (same), Maxell
(good. a little noisy, though). Finally, we tried Xidex, and this
is the brand we still use: they offer the best proce/performance
rate in Switzerland. Note that Xidex is, to my knowledge, the
only brand assembled in Switzerland. We have used one thousand
of them without problems.
Dan Schwendener
Swiss Federal Institute of Technology ETHZ
(BITNET) macman@czeth5a
(EAN) mactest@rzeth.ethz.chunet
------------------------------
Date: 14 Feb 87 12:24:28 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V3 #11
Usenet Mac Digest Saturday, 14 February 1987 Volume 3 : Issue 11
Today's Topics:
MacDraw Story
complaints about SFPutFile dialogs
Re: Jasmine Hard Disk
Re: Using MAC+ in the LAB - Help??
help w/resources needed
SCSI drives with tape backup
Looking for a Sanskrit word processor
Anybody tried to use AppleTalk from MacMETH modula-2 ??
Hershey Fonts and PostScript
The Magic of Macintosh: Programming Graphics and Sound (review)
Re: SCSI drives with tape backup
ExperLogo
squeaky 800K drives
Experience with fast screen refresh routines
Lighting programs
Re: Theatre lighting programs
Coral Object Logo
AppleTalk hierarchy help needed
T-Scan (MacPaint) to Professional Composer?
TimeMgr
Mouse Anti-Freeze routine needed.
How do you scale a picture equally in X and Y in MacDraw or Word?
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-11.ARC
DoD
]
------------------------------
Date: 14 Feb 87 12:25:35 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V3 #12
Usenet Mac Digest Saturday, 14 February 1987 Volume 3 : Issue 12
Today's Topics:
Making a Mac talk SCSI to a Sun
Code generation bug in MPW Pascal
MPW Tools Stand-Alone (?)
Icon Language for MPW
Pop Up Menus....
Advice on InBox vs. Intermail Wanted
Re: How do you scale a picture equally in X and Y in MacDraw or Word?
Re: Mouse Anti-Freeze routine needed.
Re: AppleTalk hierarchy help needed
Request: .dvi --> imagewriter program
Re: Making a Mac talk SCSI to a Sun
Mac PD Prolog wanted
3D Life -program status
Re: How do you scale a picture equally in X and Y in MacDraw or Word?
TransSkel: Proposed Changes
macwrite->text, on my VAX
Re: MPW Tools Stand-Alone (?) (2 messages)
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-12.ARC
DoD
]
------------------------------
Date: 14 Feb 87 12:26:20 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V3 #13
Usenet Mac Digest Saturday, 14 February 1987 Volume 3 : Issue 13
Today's Topics:
Full 8.5" x 11" on ImageWriter
Mac Workstation
Microsoft Basic question
NEXPERT experts?
WANTED: PD/Shareware CAD software
LSC ++ and -- operators
INFO NEEDED - Kinetics Fastpath Box
vt100 emulator DA wanted
Two Problems
Re: Mac projectors
Re: ExperLogo
Re: Mac-Toshiba Interface
Re: INFO NEEDED - Kinetics Fastpath Box
Re: Mouse Anti-Freeze routine needed.
Jasmine Direct Drive 20
Let's do _Launch
Re: Mac II
help on configuring system with davong
Re: Let's do _Launch (2 messages)
Source of 3d drawing example using GRAF3D library wanted
Re: ExperLogo
Shar for the mac?
WANTED: ARPANET ftp file transfer program for the Macintosh
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-13.ARC
DoD
]
------------------------------
Date: 15 Feb 87 10:05:51 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Delphi Mac Digest V3 #11
Delphi Mac Digest Sunday, 15 February 1987 Volume 3 : Issue 11
Today's Topics:
RE: draw-grab
RE: LaserSpeed -> WOW (4 messages)
Mac carrying cases
System 3.3 and MacXL
Lightspeed C and Macsbug symbols
MPW C Doc and MPW Tools (4 messages)
Re: Fortran Problem (2 messages)
New HELP Resource type. (3 messages)
Looking for Music Tutor
Serious ROM 'feature' causes problems wi
TMON with FPD (2 messages)
Mac Zap v4.5
cricket draw
Investigations into Memory Usage (3 messages)
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>DELPHIV3-11.ARC
DoD
]
------------------------------
End of INFO-MAC Digest
**********************