INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (04/02/87)
INFO-MAC Digest Friday, 1 Jan 1904 Volume 5 : Issue 73
Today's Topics:
RE: Strange, slow Mac+ (really: April Fools miss the point)
Strange, Slow Mac+
Re: VBL Tasks and Dead Mice
Re: LARGE file editing
uw -- setuid and command key
Help with MacDraw printing???
Dealers and Apple Support
Word 3.0 Bugs & Requests
Wierd Problems ...
Apple LaserPrep |______ font names
Using option as control
Backup software for AST-4000
Cricket Graph & SuperPaint
Laserstart & +
Memory and SCSI upgrades for 512e
Fullpaint Hassle
----------------------------------------------------------------------
Date: Tue 31 Mar 87 12:12:39-CST
From: Werner Uhrig <CMP.WERNER@R20.UTEXAS.EDU>
Subject: RE: Strange, slow Mac+ (really: April Fools miss the point)
RE: missing the point.
TOUCHEE - rereading the original messages certainly has me agree
with you that there is reason to suspect that the only basis of
their claim to a slow running machine may be the slow speed of
running the Stars DA, but then again, that does not give folks the
benefit of the doubt, does it now? Besides, I'm one of those
folks that believes that the only "stupid" question is the one
you don't ask. And the value of the answer is often greater than
the value of the question. Anyway, I appreciated (*REALLY*) that
Jon didn't pass up my missing the point and decided to post the
*obvious*.
the more I think about it, the original article deserved to have been
posted on April 1 to see which fool falls for it - it caught my eye
in a particular vulnerable moment, as, when I read it, I was just in
the process of guiding a friend through the steps to improve the
speed on his hard-disk - and he really did have a problem after mucking
around with the fonts in his System file a lot; and my fix *DID* work
for him.
BTW, do not miss reading John Gantz's column "Tech Street" in this weeks
InfoWorld titled: "IBM to Deep-Six 80386-based PC thanks to New Technology"
The new computer he writes about seems to be an improved on Mac-II ....
But, in the meantime, my hat is off to Jon, who is a better "sleuth" than me;
the next round is on me, Jon (-:
[
There is certainly no such thing as a stupid question. Well, maybe a few.
But read on for even more twists to this story. DoD
]
------------------------------
Date: Wed, 1 Apr 87 11:39:58 EST
From: Franklin Davis <davis%v750%wanginst.edu@RELAY.CS.NET>
Subject: Strange, Slow Mac+
Boy do I feel dumb. Moral: Don't rely on unknown tests to draw
conclusions, 'specially about hardware. (But who would have thought
Stars would be such a sophisticated hack that it remembers its galaxy...)
Franklin
[and again. DoD]
Date: Wed, 1 Apr 87 18:32:22 EST
From: Franklin Davis <davis%v750%wanginst.edu@RELAY.CS.NET>
Subject: Re: Strange, slow-running Mac+
Well, the obvious gets stranger. I was happily convinced that both our
Macs are _of course_ running at the same speed. Then, someone EASILY beat
the "Bash Big Blue" program.
I tried it on the other machine (where I was sitting) and those little IBMs
pop around FAST! But, honest and truly, they are SLOW on the first
machine.
What I really need now to convince me the whole thing isn't just April
Fool Gremlins :-) is some objective speed measure. Plus possible hints
about hidden system goodies that could eat up time.
This whole thing is getting funny -- but it's not a joke. Really. Help!
Franklin
[
why would people use STARS-DA and Bash Big Blue as performance tests? But
then again, I can't think of anything better. (the only real test of computer
power is how much the lights dim when you switch it on %:-) For all you
doubter's, this exhange is for real.
Bill Berner's joke last year was less than well received, but it was all
this talk of April's Fools that put ideas into my head (what, me worry?).
So I take full responsibility for nothing.
DoD
]
------------------------------
Subject: Re: VBL Tasks and Dead Mice
Date: Tue, 31 Mar 87 12:57:15 EST
From: sbm@purdue.edu
My sincere thanks to Ephraim Vishniac for mentioning the inVBL bit
of the VBL queue header. I have finally solved my problem. Apparently,
when they say that inVBL is bit 6 of the qFlags field, they mean it is
bit 6 of the high-order byte of the qFlags field. At any rate, I am
implementing multitasking, but I was not keeping the inVBL bit as part
of the saved state of the processes. The result was that, when the VBL
task found events available and context switched to the process that
handles events, the inVBL bit would be left on during the execution of
that process, which prevented the cursor position and the button state
from being updated.
Once I saw the problem, the solution was simple. I made inVBL part
of the saved state of a process. Now, when the VBL task interrupts
process A and context switches to process B, process B runs with inVBL
cleared. When the context switches back to process A, inVBL is set
again until the VBL task returns, when the Vertical Retrace Manager
clears it.
Everything seems to work beautifully now. Does anyone see any
potential problems with dealing with the inVBL bit this way?
Steve Munson
sbm@Purdue.EDU
sbm@Purdue.CSNET
------------------------------
Date: Wed, 1 Apr 87 03:29 CDT
From: BOYD@TAMLSR.BITNET (Scott T. Boyd)
Subject: Re: LARGE file editing
Do you consider 965K big? If so, we work with big files all the time
with the MPW Shell (edit, save, etc.). Saving it takes a while (c4.5 mins.)
but it works without crashing on a Plus. The Shell can also do a nice
job of opening a 1.4M file for reading. We've never tried editing it,
but it's great for reading and searching.
scott boyd
the machax(tm) group
------------------------------
Date: Wed, 1 Apr 87 15:04:02 PST
From: John Bruner <jdb@mordor.s1.gov>
Subject: uw -- setuid and command key
As John Kohl described, the common problem with UW and "talk" or similar
applications is caused by the lack of an "/etc/utmp" entry. X shares this
problem, as does the 4.3BSD window program. In a secure system,
"/etc/utmp" is not world-writeable. "suntools" is able to write into
"/etc/utmp" (and avoid the problem) because Sun made "/etc/utmp" mode 666.
There is code in the UW v3.4 server to write entries into "/etc/utmp". You
can enable the code by compiling with UTMP defined (add -DUTMP to the
OPTIONS line in the makefile). This will work if "utmp" is world-writeable
or if the uw server is setuid or setgid to a uid or gid which can write the
"utmp" file. The code which handles "/etc/utmp" does a setgid(getgid()),
setuid(getuid()) immediately after the open.
The UTMP code in the server will handle windows created on the Mac and
windows created via "uwtool". I didn't have time to put the relevant code
into "uwterm" before the v3.4 release.
Warning: playing with setuid/setgid programs is always risky. You
should assure yourself that making the UW server setgid or setuid
is benign before you do it.
On an unrelated topic: UW will recognize menu-key equivalents. A long time
ago I removed the lock on my caps-lock key; I now use it as a control key
in UW and use the command key for menu equivalents. Since UW can also
disable dead-key processing you could define a keyboard map which uses the
option key as a control key, leaving command free for its intended use.
------------------------------
Date: 31 Mar 87 12:32:00 EST
From: <bouldin@ceee-sed.arpa>
Subject: Help with MacDraw printing???
I digitized a blueprint with a scanner, and ulitmately fed the output into
MacDraw. I thought I was pretty clever to easily convert an old hand-drawing
into something machine readable. HOWEVER, when I print it out, the dimensions
come out wrong!! The dimensions are correct on the screen, but about 6%
larger on the paper. I am printing to an Imagewriter II from a Mac+. I used
both "tall adjusted" and no "tall adjusted" options on the Page Setup, with
no changes in the output.
I am at wits end, as I had planned to use the output to produce more drawings
for the design I am working on. Anyone know what is going on here???
I _can_ salvage things since our Xerox has a 93% reduction size, which is
almost exactly what I need to get the paper output to the same size as the
screen. However, I would rather understand what is happening and avoid the
problem if possible. Thanx.
------------------------------
Date: 31 Mar 87 13:58 EST
From: JOHNC%CAD2.decnet@ge-crd.arpa
Subject: Dealers and Apple Support
Kuras%BCVAX3 writes:
>visit your dealer
My dealer doesn't even understand the questions. (grin)
Seriously, I've tried several different places, and none of them know anything
technical. Applelink gets them information with yes or no answers; "Does
application X run on system Y with Z printer?" Beyond that I've never been
satisfied. It's an unusual dealer who will even try to answer a question
unless he/she feels a sale is predicated on that answer. As post-sales support
I find all dealers deeply deficient. I think an 800 number is a poorer way
to get support than a good user group or InfoMAC. Best of all though,
I'd like to see Apple bundle an AppleLink-like product with each Mac and
provide a non-800 number staffed by a support team. That the call costs
should discourage frivolous questions; and the response wouldn't be immediate.
However, they would be providing a very valuable service to people who need
it, and taking a load off dealers who are very ill prepared to answer
technical questions. And... it's a very Mac-ish way of providing support.
John Child
"Problems are the price of progress" General Electric
Aircraft Engines
Lynn MA
------------------------------
Date: Tue, 31 Mar 87 09:08 EDT
From: Jeffrey Shulman <SHULMAN%slb-test.csnet@RELAY.CS.NET>
Subject: Word 3.0 Bugs & Requests
[ Uploaded from Delphi by Jeff Shulman ]
Name: WORD 3.0 BUGS AND REQUESTS
Date: 30-MAR-1987 20:34 by DSACHS
Bugs and requests for Microsoft Word 3.0. Edition of March 29, 1987.
[ Text copy below - Jeff ]
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-WORD-30-BUGS-REQUESTS.TXT
DoD
]
------------------------------
Date: 31 Mar 87 14:25 EST
From: JOHNC%CAD2.decnet@ge-crd.arpa
Subject: Wierd Problems ...
I had an analog board replaced in a 512e w/ hyperdrive after it went "pfooost"
and spat out smoke. The repaired system ran fine for 4 or 5 days and then went
belly up: no power to CRT or digital board. The hyperdrive started to spin
when the power switch was flipped on, but that's all.
I took the machine back and the dealer _very nicely_ replaced both the analog
board and the CRT. "WOW", thought I, "almost like a new machine". Not
so. (sigh)
A number of applications and DAs now fail, where they ran fine originally
and after the first analog board replacement. Replacing the system and
applications from the original disks produced no changes. The behavior is
the same whether the programs are run from the hyperdrive or a floppy, whether
the system is booted from the hyperdrive or a floppy, and whether the system
file is 3.2 or 4.0. (I did try all the combinations: it took a while :-))
Symptoms are: application or DA hangs in a loop, typically near address
413F24(hex). The loop executes one toolbox trap, GETRESOURCE at address
401F24(hex). Doing a WHERE in MACSBUG says that's in PACK2, but I doubt that.
PACK2 is quite different in system 3.2 and 4.0, but the behavior is identical
under both systems. As far as I can tell the problem is the same with each
failing program.
The failing programs are: ResEdit 1.01, Rolodex 0.01, Finder 4.1 (I tried
it just to see), FindFile DA, Chooser DA (the one new with System 4.0),
and the MiniWriter DA. MS Word won't print to the imagewriter anymore,
and I suspect the same problem.
Has anyone seen this, or have a suggestion? It appears to be directly related
to the hardware problem or repair; but it seems like a software problem.
Any help will be deeply appreciated.
John Child
A false principle, once arrived at, is not General Electric
easily dislodged. Aircraft Engines
Lynn MA
------------------------------
Date: Tue, 31 Mar 87 16:47:01 mst
From: dlc@LANL.ARPA (Dale Carstensen)
Subject: Apple LaserPrep |______ font names
I think I recall seeing some instructions for printing Mac QuickDraw files
on LaserWriters which are connected to non-Mac computers. Some mentioned
not only sending LaserPrep, but how to handle references to font names such
as |______Symbol or |______Helvetica. Simply sending the part of LaserPrep
that defines the md dictionary (so it doesn't tie up so much memory that
nothing else can run) leaves us with errors that such fonts are undefined.
What else do we need to do?
As an aside, the version 40 LaserPrep has a name in it which consists of
two octal 312 characters (J plus 128 decimal), which gets clobbered by
editors that like nice 7-bit character files (such as vi).
------------------------------
Date: Tue, 31 Mar 87 08:38:48 PST
From: Stephen E. Miner <miner@spam.istc.sri.com>
Subject: Using option as control
Here's an old Info-Mac article that I saved some time ago. Thanks go
to Larry Rosenstein who originally posted the message. I hope this
helps (re)settle the issue. I also hope that Microphone offers an
option->control mapping when they finally get around to delivering
their update. (They told me it would take another month or so. Of
course, that's what they said last December.)
I think that the beta-version of micro Emacs had a similar problem
with 'dead' keys. One work-around was to use the Option Key Disable DA
which is available in the archives as DA-OPTIONKEY-DISABLE.HQX.2.
Steve
Date: 29 Jul 86 01:01:21 GMT
From: voder!apple!lsr@ucbvax.berkeley.edu (Larry Rosenstein)
Subject: Dead Keys
Sender: info-mac-request@sumex-aim.arpa
{}
A long time ago there was a discussion of using the Option key as Control in
Red Ryder. The problem is that certain option key combinations (eg.,
Option-e) are dead keys and don't generate a character until the next key is
typed.
Contrary to the messages posted at the time, it is very easy to disable
dead keys in the keyboard driver (although I'm not sure that this has been
documented). MacTerminal does it, in fact.
Basically, there are 2 resources (pieces of code, actually) that map raw
keycodes, generated by the keyboard, into ASCII characters. One resource
handles the main keyboard and the other the external keypad. It is
possible to completely replace these resources if you want to modify the
mapping in some unusual way.
Turning off dead keys, however, is very easy and already provided in the
system. Low memory location $29E contains the address of the main mapping
function. The resource begins with a 2-byte BRA instruction, followed by a
1-byte flag.
If the flag is $FF then dead keys are on, if it is $00, then dead keys are
off (ie., typing option-E will give you an accent character immediately).
It's as easy as that. Programs that turn off dead keys should make sure to
re-enable them when they terminate.
It would be trivial to write a desk accessory that allows you to
enable/disable dead keys at any time. Then it might be more convenient to
use the Option key in Red Ryder.
I hope this helps current and future terminal emulators.
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
------------------------------
Date: 31 Mar 87 08:55:26 EST
From: Kerien.Fitzpatrick@cive.ri.cmu.edu
Subject: Backup software for AST-4000
Does anyone have REAL backup software for the AST-4000? The software that
comes with the drives is trash. AST's reason for not having decent
software that can handle HFS is that Apple did not get the information to
them fast enough (why then do other companies have backup software that can
handle HFS?). I have recently switched our two server network from
MacServe (MacTrash?) to AppleShare (AppleSlow?) and need the capability to
perform incremental backups to the built in tape drive. I would imagine
that there are a few other AST owners that would love to have decent backup
software so come software hackers fix us up with something that works. Any
info would be appreciated.
Thanks,
Kerien Fitzpatrick
reply to Info-Mac
or
fitz@cive.ri.cmu.edu
------------------------------
Date: Tue, 31 Mar 87 14:27:53 CST
From: David Wilson <WILSON/DAVID@scarecrow.waisman.wisc.edu>
Subject: Cricket Graph & SuperPaint
When I transfer a graph from Cricket Graph to the draw layer
of SuperPaint, SuperPaint crashes. Silicon Beach Software
says they are looking into the problem.
------------------------------
Date: Wed, 01 Apr 87 11:07:45 SA
From: Tero Siili <FYS-TS@FINHUT>
Subject: Laserstart & +
Hi|
There was some inquiry concerning Mac/HP LaserJet interfacing. Here's
a question to those, who know more than I do: If I have a laser, HP
or emulating, and I purchase , say, LaserStart Plus, which features
of Mac is the laser able to print? Does it print from internal character
sets or does it recognize Mac fonts(Times, Geneva, etc) and different
sizes and proportional spacing and is it capable of producing same
graphics as LaserWriter? Or do these nice features require a PostScript
laser?
Tero
------------------------------
Date: Wed, 1 Apr 87 17:37:15 PST
From: PUGH%CCC.MFENET@nmfecc.arpa
Subject: Memory and SCSI upgrades for 512e
Well, this is boggling my mind. Can anyone out there provide me with info?
I am planning on upgrading my Mac 512e to a meg+ and add an SCSI port (for
that nifty Jasmine 80 Meg drive). I also have two meg of 256K chips just
lying around and I would love to be able to use them in an upgrade, but I am
beginning to think it is impossible and not just unlikely.
I have been speaking with numerous dealer types and getting the "Um, I think"
reaction from most of them with regards to memory and SCSI upgrades. I am
beginning to suspect that the simplest and best thing to do is spend the $550
and get a real Mac+ board (from Priority One in San Jose). That way I would
know what my choices are with regards to upgrades (does anyone make a
socketted SIM?).
So, could y'all email me any info ya gots on memory and SCSI upgrades?
Personal experience counts a lot, so please, if you've done this, let me know
how it went. I am praying that I am not the first to try this.
Jon
N L pugh@nmfecc.arpa
M A L National Magnetic Fusion Energy Computer Center
F T N Lawrence Livermore National Laboratory
E L PO Box 5509 L-561
C Livermore, California 94550
C (415) 423-4239
------------------------------
Date: 31 Mar 87 12:52:00 EST
From: bouldin@ceee-sed.arpa
Subject: Fullpaint Hassle
Or, this could be subtitled, "Why I always feel ripped off when I pay for
Software".
I have been a user of Fullpaint for sometime. I love it. But, it
doesn't work with large screens, Megascreen, etc, nor does it work with
the large "virtual screen" created by Stepping Out.
I called Ann Arbor Software to ask about this problem, with these results:
1. They are well aware of the problem.
2. No, they aren't working on a fix, as they are _all_ busy on finishing up
Fullwrite.
3. No, they don't know when or IF it will be fixed.
4. When FullWrite is done, they will "evaluate" their plans for what to do
with this bug in FullPaint.
5. They won't even admit that it is a flaw! They said that when FullPaint
was written that neither Stepping Out or the Megascreen existed. I pointed
out that they MUST have violated the Apple guidelines in some way, as
MacDraw (a much older program) runs just fine.
I have never felt the need to do this before, but:
<<<<FLAME ON>>>
This is just the kind of nonsense that makes me sorry I ever laid out any
money for this program. They will not even admit that there is a problem which
is their fault. The program performs incorrectly because they obviously
violated Apple's guidelines about how to deal with the screen. To assert that
they couldn't "look into the future" (their phrase) is complete nonsense.
So if you are considering Fullpaint be aware: There is no suport at present,
as ALL the programmers are working on FullWrite. They may never fix this bug,
as they will not even admit that it is a bug.
I think it is extremely poor practice to completely remove technical support
on an old product while involved in rushing a new product to market. That
doesn't give me much confidence in the support that I can expect for
FullWrite, either. This is typical policy of too many software companies,
rushing out new products to gain revenue, while there are still glaring flaws
in the old products. I also expect that we will all be expected to pay for
an upgrade to fix Ann Arbor's original poor programming. This type of policy
accounts for a lot of the software piracy in the world. Why pay for a program
when you just get screwed later on??
My advice: Consider Superpaint, it works just fine with every screen that I
have tested it on.
<<<FLAME OFF>>
------------------------------
End of INFO-MAC Digest
**********************