INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator David Gelphman...) (11/22/86)
INFO-MAC Digest Friday, 21 Nov 1986 Volume 5 : Issue 14
Today's Topics:
Copying Resources
Lightspeed Pascal Bug, and Workaround...
Lightspeed Pascal Wishes...
SCSI driver id numbers?
Re: Info Wanted: Macintosh in the Laboratory
Macintosh in the Laboratory
Posting of Moose Frazer, Launch Fkey, and LaserWriter Reset DA
Xerox 9700/8700 font editor
DynaBook Lives!
Re: Apple's responce about Bugs in Apple Software
The new system
Re: Apple // emulation on Lisa
RE: Wanted: the MacBinary specification
RE: document can't be opened
Re: Adding Fonts to the fonts menu
Usenet Mac Digest V2 #95
Delphi Mac Digest V2 #60
----------------------------------------------------------------------
Date: Wed, 19 Nov 86 20:23 PST
From: PUGH%CCX.MFENET@LLL-MFE.ARPA
Subject: Copying Resources
Can anyone help me with this? I want to copy a file's resources to another
file. Is there a straightforward way of doing this? I have to play games
that seem to be unsafe to close all the resource files except for the one I
am looking at so that CountTypes and CountResources will only report on that
file. What point am I missing? Is it possible to do a block copy of the
entire resource fork from Pascal?
Any clues? Reply direct please, I'm in a hurry (as usual).
Jon
------------------------------
Date: Thu, 20 Nov 86 10:56:33 est
From: rs4u#@andrew.cmu.edu (Richard Siegel)
Subject: Lightspeed Pascal Bug, and Workaround...
I was porting a program from the TML Source Code Library over to Lightspeed
Pascal the other day, and LSP kept crashing on a call to GetItemStyle, which,
given a menu handle and an item number, returns the QuickDraw character style
of that item.
procedure GetItemStyle (m : MenuHandle; item : Integer; var s :Style);
LSP was crashing with an odd address exception...
I called THINK, explained the problem and an hour later I got a call from one
of the LSP developers. I explained the problem, and 3 hours later he had an
explanation and a work-around. This piece of code generates the crash:
program MenuCrash;
var
m : MenuHandle;
s : Style;
begin
m := GetMenu(300); {assuming that there's a menu 300 in our
resources}
InsertMenu(m, 0); {put in the menu}
DrawMenuBar;
GetItemStyle(m, 1, s); {Pascal will crash here}
DisposeMenu(m);
end.
The reason Pascal crashes is due to the way that LSP packs sets. They
couldn't be more specific than that, though...
The fix is the following: at the very beginning of your VAR declarations,
declare TWO Style variables:
var
bogus, itemStyle : Style;
when you call GetItemStyle, call it the usual way, except that after the
call, look in the variable called BOGUS for the actual value, like this:
GetItemStyle(menuH, itemNum, itemStyle);
itemStyle := bogus;
It sounds really strange, but it works. I've tried it, and it works fine. The
person I talked to called it "a really slimeball fix"....
It's a rather esoteric bug; however, it may also apply to other calls that
return packed set-types; I don't know....
Hope this helps...
--Rich
------------------------------
Date: Thu, 20 Nov 86 11:01:56 est
From: rs4u#@andrew.cmu.edu (Richard Siegel)
Subject: Lightspeed Pascal Wishes...
When I talked to THINK, I asked if they were going to implement the
Object Pascal standard on Lightspeed Pascal, and when the next release would
be. They responded that they were waiting to see if Object Pascal was only a
fad; they also said that they were market-driven, and they really want to
hear response from users; if they get enough requests for a feature, they
might just implement it...
Since the good people at THINK don't have access to the net, it probably
would be best if you called them directly or sent a letter; alternatively,
you can all send me mail, and I'll collect the requests and send them in...
--Rich
Richard M. Siegel
Bitnet: rs4u%andrew.cmu.edu@wiscvm
Decnet: rs4u%andrew.cmu.edu@cmccte
Mailnet: rs4u%andrew.cmu.edu@carnegie
Arpanet: rs4u@andrew.cmu.edu
US Mail:
Box 698
5115 Margaret Morrison Street
Pittsburgh, Pa. 15213
Phone:
(412) 268-4224
Disclaimer:
Disclaimers are bogus. Mannheim Steamroller rules, and Dave Grusin is
his prophet, and David Lee Roth cleans the bathroom.
------------------------------
Date: Wed, 19 Nov 86 22:45:25 PST
From: <DAVEG@slacvm.bitnet>
Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu
Subject: SCSI driver id numbers?
I've been using the Dreams of the Phoenix DA installer+ to install more
than 15 DAs into my system file. I've had it work well (I've manually
gone in and set the MENU nonpurgable bit myself since that is not done
correctly by the program) and haven't had any problems with the extra
DAs. Of course there are 10**6 DAs available now and I'd like to have
even more installed than I currently do. The way the installer works is
to first use the 15 'Apple OKed' slots, then the 'Apple Reserved' slots,
then the SCSI drivers slots, etc. You can set this priority ordering if
you wish. I've filled up all the 'Apple Reserved' slots and now am eyeing
the SCSI drivers slots.
The question is how do these slots work? I am currently using 1 SCSI
device and sometimes use a second drive also. If I leave 2 of these slots
available will I run into problems? I figure there is no problem if I
never use a SCSI device. How do the driver numbers for a SCSI device
get assigned?
David Gelphman BITNET address: DAVEG@SLACVM
Bin #88 SLAC ARPANET address: DAVEG@SLACVM.BITNET
Stanford, Calif. 94305 UUCP address: ...psuvax1!daveg%slacvm.bitnet
415-854-3300 x2538
usual disclaimer #432 applies: my employer apologies for the fact
that I have access to this net.
------------------------------
Date: Thu, 20 Nov 86 09:48:00 est
From: rs4u#@andrew.cmu.edu (Richard Siegel)
Subject: Re: Info Wanted: Macintosh in the Laboratory
The past two summers, I worked at NASA/Langley Research Center. For
the past two years, we've had Macintoshes there, that have mainly been used
for wordprocessing, and preparing presentations, but not for acquisition and
control, even that was the eventual goal. The programmer that was (and still
is) there is a genius, but he got his degree in Computer Science, not in
physics or material science, so although he's a great programmer, he couldn't
write code to drive the Macintosh properly in a lab environment. Enter me.
I'm an undergrad Physics major, and certified developer. My boss gave
me a Macintosh with a Hyperdrive, an adaptor to connect the Macintosh's RS422
port to an IEEE-488 bus, and a task. I had to trigger a loadframe, and then
read simultaneously a voltmeter and a frequency counter, store the readings,
and when the run is done, plot the information on the screen, do a
regression, and display the results. And of course, use the Macintosh User
Interface, and be able to print the whole thing out on any standard printer
(Imagewriter, LaserWriter).... I wrote the whole thing in about a month, and
it ran faster than the old version of the program, running in BASIC in an HP
micro. The next project was to replace an overloaded VAX 780's task of
reading a Nicolet 1170 Signal averager; read the digitizer's memory, and plot
the information, then save it for uploading to the Vax for processing. This
task was also accomplished in about a month, using this Rs422->IEEE488 box.
The Macintosh was able to perform this particular task about 4 times faster
than the Vax.
Basically, the Macintosh has the horsepower to read and control lab
equipment. If you wanted to do real-time work, a Prodigy board (I wasn't
using one, but I will be) would probably make life easier; otherwise, the
serial ports, even at 57.6KBaud, are fast enough to work nicely.
Also, the key is to write the critical parts (acquisition and
control) FROM SCRATCH for a specific task; this guarantees that it'll run as
fast as it can; of course, the basic serial i/o and user-interface routines
can be re-used... If you write the code yourself, it'll invariably run faster
than a commercial package such as LabView.
I haven't covered everything here, so feel free to ask....
--Rich
------------------------------
From: BGT.WB%GEN.BITNET%cernvax.BITNET@WISCVM.WISC.EDU
Date: 21 nov 86 11:45 GMT +0100
Subject: Macintosh in the Laboratory
In reply to the query by Barbara Weintraub (INFO-MAC V5 #13), CERN
has experience of using MacVEE Plus systems in the laboratory for
data acquisition, experiment control and monitoring, as well as
for equipment development and test.
MacVEE (Microcomputer Applied to the Control of VME Electronic
Equipment) provides direct memory-mapped access from the Macintosh
(or Macintosh Plus) to up to 8 VMEbus crates, or up to 7 VMEbus
crates and 8 CAMAC crates via Mac-CC, a dedicated Macintosh CAMAC
crate controller.
Small physics experiments have been successfully completed in
which the only computer used was a MacVEE system with CAMAC. At a
large experiment, such as UA1 at the proton-antiproton collider,
the data acquisition itself is performed by a distributed system
of 65 VMEbus CPUs and 134 other VME/VMXbus modules, and a dozen
MacVEEs are used in the control room for the programming, control
and monitoring of these.
One MacVEE is dedicated to perform as the data acquisition
console, and it also carries out automatically the functions of
the old experimenter's log book (recording all operator commands,
selected histograms, diagnostics etc). Other MacVEE systems are
used for the control of trigger processors comprising farms of
SLAC/CERN emulators of IBM mainframes (six 168 and six 3081)
through their VMEbus interfaces.
In a MacVEE system, the selected external VMEbus or CAMAC address
space simply appears within the address space of the Mac's 68000,
so that no special drivers are required to access it.
User-vectored interrupts from VME can be handled, as well as CAMAC
LAMs. A composite video signal output is provided for use by
remote video monitors.
Mac-CC is equipped with a standard auxiliary controller bus (like
a type A2 crate controller) allowing multiple controllers in a
CAMAC crate, and operates in conjunction with standard LAM
graders. The MacVEE VMEbus interface module has system controller
capability as well as allowing multi-processing in the VMEbus
crates.
The introduction of the Macintosh has led to some interesting new
approaches to providing interactive user interfaces to laboratory
experiments. For example, when a data acquisition MacVEE detects
any abnormality in the statistics, it highlights the corresponding
histogram on its mutli-histogram display (and outputs a speech
message).
To obtain more detailed information, the operator just has to
click on a chosen histogram with the mouse to see an expanded
display with additional diagnostic data. It proves much easier
for the physicists on shift to master this type of user interface
to a complex apparatus than to have to remember the sequences of a
conventional command language.
A total of 176 MacVEE systems are currently in use. I can provide
a limited number of copies of the MacVEE User Manual to other
professional researchers.
B.G. Taylor
EP Division
CERN (European Organization for Nuclear Research)
1211 Geneva 23
Switzerland
Bitnet: bgt.wb@gen
Arpanet: bgt.wb%gen.bitnet@wiscvm.arpa
Usenet: bgt.wb@gen.bitnet.uucp
------------------------------
Date: Wed, 19 Nov 86 21:57:10 PST
From: <DAVEG@slacvm.bitnet>
Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu
Subject: Posting of Moose Frazer, Launch Fkey, and LaserWriter Reset
Subject: DA
Here are three programs which came into my hands to be posted. The
Frazer allows the user to add new phrases to the talking moose file.
Be sure and backup your original Moose Phrases file before you start.
The Launch Fkey allows you to transfer to another application. It does
it in a relatively dirty way, so close your files before you transfer.
The LaserWriter DA allows you to reset the laserwriter without powering
it off.
I'm just posting these and can't take any credit for writing them.
David
[ archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-FRAZER.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>FKEY-LAUNCH.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>DA-LWRESET.HQX
DAVEG
]
------------------------------
Date: Thu, 20 Nov 86 09:04:59 PST
From: <LOGANJ@byuvax.bitnet>
Reply-to: LOGANJ%BYUVAX.BITNET@forsythe.stanford.edu
Subject: Xerox 9700/8700 font editor
Date: Thu, 20 Nov 86 08:17 MST
From: <LOGANJ@BYUVAX.BITNET>
Subject: Xerox 9700/8700 font editor
To: INFO-MAC-REQUEST@SUMEX-AIM
X-Original-To: INFO-MAC-REQUEST@SUMEX-AIM.STANFORD
We have a font editor for Xerox 9700 and 8700 laser printers. It
runs on the Macintosh and presently works on small fonts only.
You can use the editor to create, modify, copy, and delete
letters in a font. Creating and modifying letters is done like
'fatbits' in MacPaint or like a very simplified INTRAN system.
We might be willing to share this application while it's under
development if there's enough interest.
Interested? Then, respond to Jim Logan at loganj@byuvax.bitnet
(I won't be able to respond to questions until early December).
If there's enought interest I'll post a BinHex'd version of the
program to net.sources.mac or mod.mac.binaries and send a copy
to INFO-MAC - in December or January.
Regards,
jim
------------------------------
Date: Thu, 20 Nov 86 16:04:24 PST
From: gunther.pa@Xerox.COM
Subject: DynaBook Lives!
I just received a collection of Mac-related bingo cards. Included was a
card advertising the "Dynamac" which is a *fully portable* Mac+
compatible. Apparently this machine was briefly reviewed in MacWorld
but I had not seen that article. I recently asked Info-Mac about a
similar machine being developed by Colby but the response was
underwhelming, so I'm assuming this machine may be interesting news
(more on Colby in a minute).
I rang Dynamac Computer Products Inc. in Colorado. Here is how the
machine is configured:
Grid style package - dark brief-case type
Fully Mac+ compatible
800K disk with 20 or 40 MB internal hard disk
300/1200 baud internal modem
U.S., European voltage compatible power supply (no ext. transformer
required?)
640 x 400 "gold" electroluminscent display (that's where the cost is)
"E-machine" to provide output to a 1024 x 808 external display
Mouse (Mac type?)
I think it is not battery powered, but I'm not certain
Available in Jan. '87 starting at $4995. Keep in mind that the initial
target is the business market. Dynamac Computer Products Inc. has an
established agreement with Apple Computer Inc. to develop and market
this product. It is not clear to me that Colby is yet in this position.
It seems this is closest approximation yet, to Alan Kay's original
"DynaBook" vision.
Neil Gunther.pa@Xerox.com
Usual disclaimer inserted here. I'm employed by Xerox PARC and you
already no that story....(sigh!).
------------------------------
Date: Thu, 20 Nov 86 08:54:52 PST
From: woody%junk-in-lnames@Iago.Caltech.Edu (William E. Woody)
Subject: Re: Apple's responce about Bugs in Apple Software
Having worked in a large company (National Cash Register) for a short time
(summer intern), and having seen their "Software Trouble Report" and
procedures, I can tell you that Apple's treatment of bugs in their software
is excellent. After all, that Apple is able to (1) manage a large number
of suspected bug reports, not all of them real bugs, (2) distribute updates
of their software to the [100k, 1M, how many Macs are out there?] users
using Macintoshes, and (3) develop new software for their computers, all
in the relm of a unique and somewhat overwelming user interface, is an
extremly impressive accomplishment.
Let me put it this way: Suppose YOU ran Apple. Would YOU have as good
a track record doing:
(1) Organizing suspected bug reports in order of priority, priority
dictated by (a) the market place [what's the point fixing a bug when there
is a workaround, when there's another which is blowing away user documents?],
(b) the audience of the bug [it's better to have Users happy than programmers,
as there is a h*ll of a lot more of them than us!], (c) the level of difficulty
of the bug, and (d) the programmers who will eventually have to fix the
bug.
(2) Get the bug report to the proper programmers, with a proper level
of priority. Note that the programmers must also have time to work on
future software (usually only 20% of their time should be spent fixing
bugs, else they may simply give up, and move on to another company--after
all, would you like to spend the rest of YOUR life fixing bugs you made
five years ago? Eventually, you'd simply say "to H*ll with the rest of
the world; I quit!")
(3) Have the programmers properly test the bug, along with the right
support personal, in order to find the bug so they can fix it. This is
a problem in itself; after all, many people may write in, saying "MacWrite
just ate my document when I tried to quit." No other details. (AND DON'T
FLAME ME BY SAYING THAT USERS TELL APPLE MORE THAN THIS! MANY DO NOT!!!!!
I know; I spent some time fixing bugs from bug reports sent in by System
Operators, and Programmers, and some of the bug reports were even more
Vague than the above!!!)
All right. "MacWrite just ate my document when I tried to quit."
Where in 30,000 lines of pascal is that bug?
Note that there is a side problem in all this; many of Apple's software
was developed by outside venders (read MacWrite). When the software bug
report generated by Apple for something like MacWrite gets sent to another
company, the same process (steps 1 through 3 above, and all of the below
steps) are EXACTLY duplicated by the company. After all, the company
who developed the software may already be fixing the bug Real Soon Now, and
they have to discover which bugs comming into their queue are duplicated
down the road.
(4) Now, the programmer must fix the bug. Usually, the level of priority
of a bug sets a deadline as to how much time a programmer has to fix the
bug. For example, at NCR, a Level 1 priority bug ment that the programmer
had three days (yes, 3) to fix it. Of course, those three days included
three nights as well. God help the poor soul who has to fix 20 level 1 bugs;\
he won't have any sleep in over 2 months. And I bet you he'll collapse
long before then.
(5) While the bug is being fixed, the management must deside exactly
how the fix is to be distributed. Usually in a company like DEC or NCR,
where the audience may be as small as 50 users, the fix may be distributed
in a patch tape or a new release, sent free of charge. They can do it,
as there are only 50 tapes to be made, and the users spent well over $30k for
the product. The $10.00 tape won't make much of a difference. But Apple
has an audience of a h*ll of a lot more than 50 users!!! Distributing a
floppy to everyone who bought the software (including those who didn't
register, or who has moved in the meantime) is an extremely expensive
proposition, especially when they didn't spend $30K per program. So Apple
almost always must rely upon distribution to their dealers, (imagine the
management and manpower problem just to distribute software to every
Apple authorized dealer, from the ones in Los Angeles, to the one up by
Bass Lake in the foothills of the Sierras above Fresno--could YOU find it?),
and Apple can rely upon having a new release.
Apple may be in the fortune 500. Apple may be a lot larger than some
other small companies (employing 5 people, who have only one product). But
because Apple is a lot larger than Megamax doesn't mean that Apple sould be
able to go a lot faster than Megamax; in fact, the size of Apple creates
management problems which make managers not sleep, management consultants
rich, and paperwork problems which boggle the imagination. And that
management and paperwork is necessary to keep Apple's relatively high
level of quality as some of the people at Apple must be held by the hand
to work properly with the rest of the community. Apple does NOT have
"infinite" resources. Shucks, IBM doesn't have infinite resources, and
IBM is the largest company in the world (by ranking of Business Week).
So don't complain that Apple is doing a poor job. Granted, Apple could
probably do a better job. But how? (And I can assure you that for
each money saving, quality improving, speed increasing suggestion that
exists, Apple probably really WANTS to know. It makes their lives easier,
as well as making your lives easier.) And realize that their personal
cannot work 24 hours a day; they'd quit first.
And the fact that people at Apple actually read the network news is
absolutely remarkable; that average run-of-the-mill Apple programmers
answer network mail is incredible. Note that though DEC and NCR and
IBM also do this, the personal who answer are PAID to answer network
mail. I've yet to hear of an Apple person who is PAID to give out
information (or, usually, disinformation--YES, I KNOW firsthand that
some of the information IS disinformation) to the rest of us.
I'm so sorry that this message is so long, but I had to get it off
my chest.
Flames to:
- William Woody mac > /|\ && ][n
woody@juliet.caltech.edu
------------------------------
Date: 20 Nov 86 20:30:49 EST
From: Peter.Su@gnome.cs.cmu.edu
Subject: The new system
>>>From: ST401385%BROWNVM.BITNET@WISCVM.WISC.EDU
> The advantage of the new finder is that it now knows about folders.
>For an ordinary mac without a hard disk, this is a dubious improvement,
>especially as the people who wrote the new finder chose to show you
>everything that's in a folder when you open something from within
>an application, even the things that you can't open. This may have
>
Er um, last time I checked, the Finder had no control over what files you
could open from insdie, say Macwrite. It seems to me the only extra files
that show up are folders, which makes sense, since how could you get into
them if you couldn't open them?? Folders DO make a lot of sense even if you
are only working with floppies. This is because the floppies hold nearly
1Meg worth of data...which is a LOT of files. If HFS wasn't there, the
Finder would spit up and die trying to figure out what was on the disk all
the time.
>the system (I'm using--or trying to use--the program Ramstart 2.22,
>which seems to be the latest version available. The program bombs
>when you try to put the system on the ramdisk and then run it.) This
Ramstart 2.2 doesn't work with HFS. You need Ramstart 2.23 I think.
> The new system is pretty stupid, too. It continuously wants
>disk swaps, even when you can't figure what in the world it wants
>them for. It is far too stupid to use free memory or even cache
Sounds like a Mac to me... ;-)
Seriously though, I think the new system stuff shows people what the Mac can
really do. It is slick, it is fast, and just all around pretty neat.
Pete
----
ARPA: hugo@cmu-cs-gandalf.arpa BELL:412-681-7431
UUCP: ...!{ucbvax,ihnp4,cmucspt}!hugo@cmu-cs-gandalf.arpa
USPS: 5170 Beeler St., Pittsburgh PA 15213
QUOT: "What's that I smell? I smell home cooking. It's only the river!"
_ Talking Heads
------------------------------
Date: Thu, 20 Nov 86 20:15 MDT
From: <SLRS9%USU.BITNET@WISCVM.WISC.EDU> (Harold Stuart)
Subject: Re: Apple // emulation on Lisa
The Apple // emulation mode on the Lisa (Mac XL) does not work. The mode
appears to directly poll hardware addresses, and the XL gets the system
bomb as soon as the program is run.
The mode does appear to work correctly on a "real" Macintosh. It's
an interesting idea, but it's time has not come on a Lisa.
Harold Stuart
SLRS9@USU.BITNET
------------------------------
Date: Fri, 21 Nov 86 01:47 N
From: <INFOEARN%HLERUL5.BITNET@WISCVM.WISC.EDU> (Thomas Fruin)
Subject: RE: Wanted: the MacBinary specification
Thanks to Ric Ford over on Delphi for answering my MacBinary query (you mean
CompuServe does and ICONtact _doesn't_ have the specification!? :-). I'm
posting this message though, because I live in Holland and there is _no_way_
for me to reach C'serve (well, at least without losing that arm and leg).
If there is anybody out there who has this specification, could s/he mail it
to me? Or if somebody has Dennis Brothers' address, I'll mail him myself.
While I'm at it, I'm also looking for the Binhex specification, since that's
something which I think should be done during up- and downloading too and I'd
like to include it in my program as well. Where can I get that?
Let's try to get this very useful information around.
-- Thomas
FRUIN@HLERUL5.BITNET
------------------------------
Date: Thu 20 Nov 86 23:11:37-PST
From: Lance Nakata <K.Kirin@HAMLET.STANFORD.EDU>
Subject: RE: document can't be opened
If MacWrite 4.5 gives a "This document can't be opened" message,
there might be paragraph damage to the file. Perhaps it tried to
save a portion of the file on a bad disk sector. In any case, you
can try using the Utility-WriteRecovery.Hqx program (known as Rescue)
that is in the Sumex archives. There is no guarantee that Rescue
will work, especially if the damage is severe. But it is definitely
worth a try.
But first, use Copy II Mac to sector copy the damaged disk!! Always
work on the copy. If Rescue doesn't work, you will have to find a
local Fedit expert. Fedit Plus 1.0.7 can piece together files that
even MacTools 6.2 (that's right, version 6.2) can't recover.
Too bad you don't live a little closer to Stanford. I would have
been glad to help out. Good luck.
Lance Nakata
K.Kirin@Hamlet.Stanford.Edu
------------------------------
Date: Thu, 20 Nov 86 09:34 PST
From: PUGH%CCX.MFENET@LLL-MFE.ARPA
Subject: Re: Adding Fonts to the fonts menu
In the Sumex archive is an FKEY called Fontsie 1.5 that adds fonts to the menu
named FONT. It works for the duration of the session and has a few minor
display problems (the font doesn't get checked and the sizes aren't outlined),
but it works very well. I use it (well, not much now that I have a hard disk).
Check it out.
Jon
------------------------------
Date: 20 Nov 86 11:03:58 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Usenet Mac Digest V2 #95
Usenet Mac Digest Thursday, 20 November 1986 Volume 2 : Issue 95
Today's Topics:
Re: Mac pictures inside a troff doc??
Re: Help - Kermit eats HD20 space
Re: Algorithmic and implementation references about Quickdraw
Re: Video problems with upgraded 512K Mac
Re: Help: Bomb Recovery Applications needed.
MAC with HP Laserjet ???
Word -> MacWrite?
Word Lists
On vague or cryptic error messages
Re: Snobol for the Mac?
Re: Snobol for the Mac?
Summary of answers to my laserwriter questions
Need cheap Mac printer
Re: Small bug in MacMETH toolbox-interface
Re: Help - Kermit eats HD20 space
InfoWorld this week covers LANs and LaserPrinters
Re: ZoomWindow...Help Needed
Mac+ Keyboard Bug?
milliseconds & NCR 5380
split baud rates?
[ archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV2-95.ARC
DAVEG
]
------------------------------
Date: 20 Nov 86 14:35:54 EST
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Delphi Mac Digest V2 #60
Delphi Mac Digest Thursday, 20 November 1986 Volume 2 : Issue 60
Today's Topics:
RE: Hard disk drives (Re: Msg 14839) (4 messages)
Hyper Drawers warning
RE: Booting SCSI & HD20 Hard disk
RE: human touch "One Touch" board (alter (Re: Msg 14845) (2 messages)
RE: Apple fellows & "Application already open" message?
RE: Expanding your system heap (3 messages)
power supply parts
New Apple Sales Promotion? (3 messages)
Programmers at Work (2 messages)
DataFrame 40 XP is _Fast_
RE: Wanted: the MacBinary specification
RE: Computerworld Focus 11/12
RE: IBM-PC <-> VAX <-> MAC network?
RE: APL for the Mac (2 messages)
RE: ZoomWindows...Help Wanted
RE: Mac fan comparison
Re: mac video - drawing into ScreenBits
PCPC's HFS Backup (3 messages)
RE: Font questions
RE: HD vs. Floppy: $/Kb (3 messages)
SCSI pinouts
HFS Blues Revisited
RE: mac video - drawing into ScreenBits fast?
[ archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>DELPHIV2-60.ARC
DAVEG
]
------------------------------
End of INFO-MAC Digest
**********************