info-mac@uw-beaver (05/26/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Sunday, 26 May 1985 Volume 2 : Issue 51
Today's Topics:
faster text output for terminal emulators
RamDisk Technical Query
Data space access from Lisa assembly
MDS128 limitations
Signature bytes for the rest of us?
Re: Switcher
RE: a switcher question
Bug still in new system
Macwrite 4.5 Bug
MacWrite 4.5
Imagewriter compatability
New Finder and Disk Mounting
laserwriter fonts
Truth in Advertising
----------------------------------------------------------------------
Date: Fri, 24 May 85 15:33:02 pdt
From: Bill Croft <croft@safe>
Subject: faster text output for terminal emulators
A friend building a text output application notices that he can get a
tremendous speedup in the text output rate by using a simple trick.
If you use the 'normal' method and just call Quickdraw to do your text
output, it seems that the effective 'baud rate' to the screen is
limited to around 4800 (even when using the efficient Quickdraw
DrawText routine).
What you can do instead is build an array of pre-setup little blocks
of bits containing your font, and call CopyBits to stuff this directly
onto the screen. He claims the speedup after this mod gives him an
effective rate of 19K baud.
I guess Quickdraw has to do a lot of ORing, bounds, and font
calculations (for the general case) that you can bypass if you are
building a terminal emulator.
Even CopyBits might be more complexity than you need for this simple
case, and he estimates further improvements would result if a special
purpose routine were written.
------------------------------
Date: Fri, 24 May 85 12:35:26 edt
From: Ephraim Vishniac <vishniac%wang-inst.csnet@csnet-relay.arpa>
Subject: RamDisk Technical Query
I'm trying to understand what makes a Mac ramdisk "eject-proof." I
had originally been told that ramdisks that the finder thought were on
Appletalk (aka Applebus) would not be ejected. Comparing the
Assimilation process ramdisk to the Aztec C ramdisk, however, I see
that the finder believes both to be on AppleTalk. The Assimilation
ramdisk will not be ejected; the Aztec one will. I'm also told that
the finder ignores close errors from disk drivers; i.e., a driver
cannot simply refuse to eject a disk. Is this really the case?
I've examined the drive queue and the volume control block queue in
some detail and been unable to find any useful difference between
these two ramdisks. I've also examined the ramdisk drivers somewhat;
I have to rely on disassembly to look at the Assimilation driver, of
course.
The purpose of this exercise to make sure that a ramdisk driver I'm
writing for a Mac with megabyte memory will be difficult to dispose of
accidentally. Can anyone shed some light, or point me to an
especially enlightening passage in Inside Mac (loose-leaf edition)?
Ephraim Vishniac
[apollo, bbncca, cadmus, decvax, harvard, linus,masscomp]!wanginst!vishniac
vishniac%Wang-Inst@Csnet-Relay
------------------------------
Date: Fri, 24 May 85 21:42:52 cdt
From: brian@ut-sally.ARPA (Brian H. Powell)
Subject: Data space access from Lisa assembly
Okay, I asked this several months ago and got no response. Now
*I* need to use the information, not my friend, who needed the
information before.
Has anybody perfected the task of writing pure assembly language
code for the Macintosh using the Lisa's assembler? (pure = not
declaring all of your variables in Pascal and passing their
address(es) to an assembly routine.)
For those of you without Lisa's, the problem is that the
assembler only believes in the program space. ***FLAME ON*** The
Pascal compiler is the only program endowed with knowledge of the data
space. ***FLAME OFF*** Apple recommends (in "Putting together a
Macintosh Application") having a dummy Pascal program declare an array
of however many words you need and passing the address of it to your
assembly routine.
So how have you other people solved this problem? What we need
is MDS-XL. I think the MDS is excellent (except for the "Code
Optimization", but that's another flame.)
Brian H. Powell brian@ut-sally.{ARPA,UUCP}
U.S. Mail: Southwestern Bell
P.O. Box 5899 451-0739
Austin, TX 78763
AT&T
(512) 451-0739
------------------------------
Date: 24 May 1985 0840-PST
From: Contr04 <CONTR04 at NOSC-TECR>
Subject: MDS128 limitations
Reply-to: CONTR04 at NOSC-TECR
Can anyone tell me what the practical size limits are for assembly
files on a 128 ? How can I gauge my files so I don't exceed the symbol
table size. I realize that I can break code up into several files,
but as a novice at assembly, how much space in the symbol table gets
eaten up by including files ? How much help do I buy by placing my
equates in a separate file ? How much space do I buy by packing
files, and what are the limitations on packed files ?
Gosh, so many questions...but suggestions would be appreciated...
Actively holding out on upgrading,
Steve Hyland
<CONTR04 at NOSC-TECR>
------------------------------
Date: Fri, 24 May 85 21:43:38 cdt
From: brian@ut-sally.ARPA (Brian H. Powell)
Subject: Signature bytes for the rest of us?
How many of you amateur developers out there have had your
application's signature bytes approved by Apple Technical Support?
From the MDS manual: (and probably all over Inside Mac)
>(By the Way) > Application signature bytes, and type bytes for other
> files, must be assigned (or approved) by Apple Technical > Support.
Makes sense to me; we don't normally want a document to think it
was created by two separate applications.
The question is (hello, Apple?) are the rest of us
(non-certified, non-registered developers) supposed to do this also?
What number do we call, and who pays for the phone call? Or who do we
write?
Brian H. Powell brian@ut-sally.{ARPA,UUCP}
U.S. Mail: Southwestern Bell
P.O. Box 5899 451-0739
Austin, TX 78763
AT&T
(512) 451-0739
------------------------------
Date: Sat 25 May 85 17:18:51-PDT
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: Re: Switcher
I had a chance to speak with Andy Hertzfeld about the suggestion of
building "switcher" with one large dynamic heap instead of the present
method of fragmenting the heap ( and everything else) into a piece for
each application. In short he said that the idea has been raised, but
it looks too complicated to do in a manner that could run *existing*
applications. If someone wants to try this he wishes them the best,
since it might be possible, if a set of thorny questions could be
ironed out.
For instance, if all applications shared the same heap, you would not
want one application to purge another's blocks, and you'd have to find
a way where one program could relocate the blocks created by another
program - perhaps by shifting them out of the way when the first got
control and shifting them back to the same place when the second had
control returned to it. If an application just left all other
application's blocks alone, then the heap would be too fragmented. The
present ROM is just not designed as a multi-task memory manager.
Also Andy announced a new feature future applications could be
designed to take advantage of: He anticipates supporting backround
tasks like printing for applications run in the switcher. This idea
brings the switcher current version number up to 2.97.
-jma
------------------------------
Date: 22 May 1985 09:32-EDT
From: David.Anderson@CMU-CS-K.ARPA
Subject: RE: a switcher question
Dan Tappan asks:
Does anyone know why memory management in the applicationswitcher
was done the way it is (that is, with a fixed allocation for each
application) instead of something more dynamic, say a minimum size
for each application with the leftover passed around as needed?
I agree that this is rather unfortunate. My own feeling is that this
is an inevitable consequence of Apple's original one application at a
time operating system design -- and by now there are probably many
applications that were designed with this naive world view (that they
own the whole machine). It wouldn't surprise me if such applications
allocate almost all of the available memory at startup, and then never
look again for more. They may also not be very disciplined about
releasing memory that they no longer need. Some programs may want a
huge contiguous space that they then manage themselves internally. If
Apple ever comes out with a real multi-tasking OS for the Macintosh
family, it may have to go a fair distance to undo this design damage.
--david
------------------------------
Date: 22 May 85 07:57:03 EDT
From: Hans.Moravec@CMU-RI-ROVER
Subject: Bug still in new system
I was hoping the new system (that came with Finder 4.1) would fix the
keyboard settings initialization bug that I reported a few months ago:
alas - the bug remains unchanged:
I don't like autorepeat, especially fast autorepeat. Being a slow
moving kind of guy, I sometimes rest my finger for a moment on the
last key while choosing the next one, and don't apreciate seeing the
typed line quickly fill up with infinite copies of said last
character. So, no problem, you say - just set your control panel
heavy handedness parameter to 4, and, even better, set the
turtle-bunny repeat speed parameter to 0, turtle, to turn off
autorepeat altogether. I do that.
Nevertheless, each time I boot up, autorepeat is fully enabled (in the
Finder and any application). Peeking at the control panel shows the
keyboard parameters as I set them, despite the behavior. I can fix
the behavior by simply mousing to the turtle slider in the panel and
clicking (I don't actually have to move anything). After that,
autorepeat stays gone until the next boot. Having to deal with the
control panel every boot (usually after backspacing over a long string
of replicated characters) is a drag.
Hasn't anyone else on the list been bothered by this bug? Or is no one
else as slow as me? I think the problem shows up for other keyboard
parameter settings - i.e. it boots to some standard configuration that
doesn't correspond to the control panel settings - but the difference
between your settings and this standard is subtle if you want
autorepeat anyway. The problem exists on all of the several Macs I've
checked, so it's not something broken.
------ Hansssssssssssssssssssssssssssssssssssss
------------------------------
Date: 22 May 85 12:07:30 EDT
From: Phillip.McKerrow@CMU-CS-H
Subject: Macwrite 4.5 Bug
The following bug, which was not in the original Macwrite, but was in
Macwrite 4.2, has not been fixed in Macwrite 4.5. It is a very
annoying bug particularly when entering mathematical equations which
require frequent style and font changes. I am using a 128k Mac.
When you first open the document, the style change works, but
once you move far enough away from the initial cursor position to
require a disc access to change memory contents a request for a style
change results in a dialog box. The dialog box states that there is
not enough memory to undo the change. After you answer OK it will
execute that command, as long as it is a command for a new style, not
an undo request by toggling the current style selection. Closing,
saving, and reopening the file clears the fault for a while.
One way around the problem is to cut and paste special
characters, but paste often adds white space before and after single
characters.
------------------------------
Date: Fri 24 May 85 09:10:46-CDT
From: CMP.BARC@UTEXAS-20.ARPA
Subject: MacWrite 4.5
I have been using an official version of MacWrite 4.5 for a week now,
and I thought I would pass along my reactions. Hopefully Apple is out
there listening.
Capsule Review: Don't waste your time.
So far I have found at least two major bugs which conspire with the
500/2000 paragraph limit to make 4.5 almost useless. Bug #1 In some
documents, whenever you try to change the style (e.g. italic, bold
etc.) of text you get an out of memory, can't be undone error.
Sometimes it will make the change, sometimes not. This happens on
both fat and skinny Macs and does not seem to be related to document
size. It has not yet happened on the Lisa running MacWorks. Bug #2
Trying to insert returns in the footer causes a too many paragraphs
error. I haven't played with this one very much but it happens in
small documents on a skinny Mac. I don't know how often it happens.
Paragraph Limit The 500 paragraph limit that I complained about in 4.2
still exists in 4.5. It is mentioned in the documentation Apple
provides and I also verified it myself. What it amounts to is that
you can only have 500 rulers and return characters in a file. There
is some discussion of this in the Get Info section of June's MacWorld.
Fat Macs have a 2000 paragraph limit. This is not likely to be a big
problem, but aas long as Apple is going to gouge people on the price
of the Fat Mac upgrade, they had better continue to support the skinny
Mac.
Conclusion: My wife and I pitched all of our copies of 4.X (except
for ones kept for historical interest) and converted back to 2.2 and
went out today and bought Word.
Finder: The new finder 4.1 is okay. So far no problems with it. As
reported by other people here, the DA/font mover will not work with
big fonts. What give at Apple? They release a new font on the same
disk as the new DA/font mover, and the stupid thing blows up if you
try to install the new font. Have they forgotten about quality
assurance? My impression is that all of the good programmers have
left Apple. Too bad.
Douglas Surber
------------------------------
Date: Wed 22 May 85 11:48:32-PDT
From: Allan Weber <WEBER@USC-ECLC.ARPA>
Subject: Imagewriter compatability
I occasionally connect my Imagewriter to a spare serial port on an IBM
PC and use it as a plain Ascii printer. Does anybody know if the
Imagewriter emulates something like an Epson or Okidata printer when
using the escape sequences for doing things like graphics? I would
like to use it for stuff like Wordstar output but need to tell
Wordstar what type of printer it is. Thanks.
Allan Weber
Weber@USC-ECLC
------------------------------
Subject: New Finder and Disk Mounting
Date: 22 May 85 08:22:26 EST (Wed)
From: Steven B. Munson <sbm@Purdue.ARPA>
I have noticed that, sometimes, when I eject a disk with the new
System and Finder and insert a new one, the Finder requires me to do
two disk swaps (four disk insertions) before it will settle down and
display the new disk, and then I end up with the startup disk in the
drive again and have to do another disk insertion to run a program on
the newly mounted disk. Apparently, mounting the new disk requires
some code segment or something that isn't in memory yet, so it has to
ask for the startup disk again, and, of course, every time disk
swapping is involved, the startup disk ends up back in the drive by
the time its finished.
Since I will not be able to afford a memory upgrade for a while
(I have a 128K Mac), I wish Apple had made sure that the Finder NEVER
ejected a disk unless it had everything in memory it needed to mount a
new one. I also think it was a mistake to require one more insertion
just to get the startup disk back when the operation was done. About
50% of the time, the startup disk isn't the one I want in the drive
anyway. And while I'm on this subject, the Finder shouldn't dim the
desk accessories when the startup disk is out of the drive, either.
That just requires more motions to start up a desk accessory -- I have
to think about ejecting the disk in the drive and inserting the
startup disk, instead of the Finder ejecting the disk for me and
asking for the correct one. I wish I had time to put XINU on the Mac;
I could teach Apple a few things about writing operating systems.
Steve Munson
sbm@purdue.ARPA
sbm@purdue.CSNET
------------------------------
Date: 23 May 1985 14:27-EDT
From: Henry.Kautz@rochester.arpa
Subject: laserwriter fonts
I'm having problems with the Laserwriter Symbol font. Can anyone
help? 1. Easy problem first: how do you type the "not sign" (looks
like a horizontal line, with a short vertical line hanging off the
right end)? What about the "proportional" sign (looks like infinity,
but with the right end chopped off). I know these are in the font,
but I can't find the keyboard combination! 2. Hard problem: the
Symbol font SHOULD be ideal for doing symbolic logic... except that
they left out the "turnstile" and "double-turnstile" symbols (usually
used for "is derivable" and "entails" respectively)! Is there anyway
to construct these symbols from any of the laserwriter fonts? (I'd
really like to get these symbols with a slash through them, too!) If
not, any other ideas about how to get these symbols printed?
---- 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: Mon 20 May 85 14:28:56-CDT
From: CMP.BARC@UTEXAS-20.ARPA
Subject: Truth in Advertising
In the June issue of Mac World there is an add from Logic-Soft, a mail
order vendor that promises to beat any price by $10. Upon reading the
fine print I found that this applies only when their price is higher
than the price advertised by someone else and the order totals over
$100. They also offer overnight delivery at no extra charge. Sounds
wonderful. They offered Brand A disks for $30 a box, another company
advertised Brand A at $28 a box, so I thought I would call them up and
buy 6 boxes at $18 a box. I fished out the old VISA card and gave
them a call. Imagine my surprise when I was told that they no longer
followed that policy. It is the first of May and the issue is dated
June. I got some long song and dance about lead times and trying to
change the add, but so what. When they advertised this policy in inch
tall letters and then refused to honor it even before the offical
publication date of the magazine, it has to be an intentional effort
to trick the consumer, a classic bait-and-switch. I would like to
recommend that everyone avoid doing business with these people and
stick with more honorable vendors. (Note: the above opinions are my
own and ...)
Douglas Surber
------------------------------
End of INFO-MAC Digest
**********************