info-mac@uw-beaver (06/25/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.arpa>
INFO-MAC Digest Wednesday, 19 Jun 1985 Volume 3 : Issue 11
Today's Topics:
SimpleTools: C routines to help use the Mac interface
C Programming Caution
Mac disk caches?
Suggestion to replace RAMdisk
Word File Format?
SUMacC sound driver interface ?
Homegrown Cabling for AppleTalk ?
MacTracks problems.
Macs In-Heat
More overheating comments
----------------------------------------------------------------------
Date: Tue, 11 Jun 85 02:26:10 pdt
From: erik%ucbssl.CC@Berkeley (Erik Kilk)
Subject: SimpleTools: C routines to help use the Mac interface
I have written a set of C routines to aid in writing simple Macintosh
programs. At the moment I am testing them out, seeing how many menus,
windows, and whatever else I can do with them can be done without
crashing. They seem to be working rather well. I'm having one
problem which seems to be related to how large my program is. I hope
to have it fixed soon. Does anyone know if the memory manager
relocates a block by copying its contents or does it just relocate the
space you use?
Here is a summary of the routines. If you are interested in them, OR
HAVE SUGGESTIONS, please let me know. I'm thinking about asking for a
few $$$ ($5-$10 for my effort), a SASE and a disk to give you the
sources, routines, some demo programs, and keep you informed of
revisions.
The purpose of these routines is to allow you to write those little
programs that you avoid due to the huge programming overhead needed to
get menus and windows to work. The object is to be simple and if
there are powerful options, hide them so you don't have to worry about
them unless you really want to.
A Summary of SimpleTools (c) 1985 E. Kilk
1) simpletools()
Installs the Apple, File, and Edit menus. Initializes the data
structures used by SimpleTools. Calls all the initgraf, initwindows,
and other inits usually needed. Just call this as the first line in
your main routine.
2) simpleevents()
To be called in your main loop. Infact, the program:
main()
{
simpletools();
for (;;) simpleevents();
} is all you need if you just want to run desk accessories.
Simpleevents does all monitoring of events and whatnot: systemtask(),
getnextevent(), menu selection and execution (see below!, great
stuff), DA startup with enabling and disabling
Undo/Cut/Copy/Paste/Clear as needed, systemclick(), dragwindow(), grow
& sizewindow(), trackgoaway(), window content clicks (another great
feature, see below!), keydowns, autokeys, window activates,
deactivates, and updates.
3) menu ("Settings", "Trace", traceselected)
Installs a menu item named "Trace" under a menu "Setting". Informs
simpleevents() to run the procedure traceselected when the user picks
Trace. If "Settings" didn't exists, it adds it. If you call this
again with all the same arguments except for a different procedure
name, the new procedure replaces the original in simpleevents()'s
"things to do list". You can call this same thing again and replace
the procedure name with: 0L to disable Trace, 1L to enable Trace, 2L
to put a check mark by it, and 3L to remove the check mark. If you
called: menu ("Settings", "Debug", 0L) you would get a new diabled
item (its procedure is a no_op until you set it.)
Each procedure assigned to a menu item is passed a (char *) to the
name of the item clicked (so several items can use the same
procedure). Of course your program can forget about this if it doesn't
need it.
4) window ("Trace Window", 20,20,200,50, trace_activate,trace_deactivate,
trace_update, trace_incontent)
Installs or modifies a window to be taken care of by simpleevents().
The coordinates are only used when installing the window. The user
then has complete control of the window's placement and size. You
pass the procedures you want to run for various events, which can be
no_ops. The window procedures assigned are passed a pointer to the
target window. Your procedure can ignore this or use it to call real
Window Mangaer routines. Each assigned procedure is called after the
output port (setport) has been called for that window. (So you know if
it does output it will go where you want it.)
Each procedure you assign as an "incontent" procedure will receive
two ints giving the x and y location of the mouse click in that
window's local coordinates.
A menu item of the window's name is placed under the menu "Window".
Selecting a window's name will activate the window. Useful if the
window is behind something or if you have clicked its go-away box.
5) withwindow ("Trace Window")
Sets the output port to the window named Trace Window for any
following output (plotting or printfs).
6) run (timedisplay)
Installs a procedure to be run each time simpleevents() is called.
Up to 50 procedures can be installed. The routine: stop (timedisplay)
removes the procedure from simpleevents()'s list.
There are also several utility type routines, the most important for
more experienced programmers are "windowpoint ("Debug Window")" and
"mhand ("Settings")". These return the window pointer or the menu
handle of the named window or menu. Then you can call regular tool
box routines with your SimpleTools' installed and maintained menus and
windows.
Data used by these routines is allocated dynamically and in linked
lists using newhandle for each new menu, item, or window so that space
isn't wasted for a large list "just to be ready for lots of menus and
windows" and so that there is no unrealistic limit to the number of
menus and windows you can have. Amount of memory is the only limit.
I have implemented these routines with Megamax C 2.0 compiled as an
object file to be linked to an application program. The code takes
about 9K. I would assume it would work with little or no
modifications with other brands of C compilers.
A demo program (the whole thing) which does all the window moving,
sizing, closing, menu selecting, D.A.s etc. etc. etc (and even a
"background looking" job):
int waitreset = 2000;
info() /* this will run periodically */
{
static int wait=1;
if (--wait == 0) { /* print message sometimes */
withwindow ("Demo");
puts("Please try the menu and window functions.");
wait = waitreset;
}
}
hello() /* to be attached to a menu */
{
withwindow ("Demo");
puts("Hi");
}
leave() /* to be attached to a menu */
{
exit(0);
}
nop() {} /* place holder */
main()
{
simpletools();
menu ("File", "Quit", leave);
menu ("Demo", "Hello", hello);
window ("Demo", 50, 50, 450, 300, nop, nop, nop, nop);
for (;;) simpleevents();
}
-- Erik Kilk
3141 College Avenue #6
Berkeley, CA 94705
erik@ucbssl.CC.Berkeley.ARPA
------------------------------
Date: Thu, 13 Jun 85 19:49:59 pdt
From: erik%ucbssl.CC@Berkeley (Erik Kilk)
Subject: C Programming Caution
After spending several evenings searching for an intermittent problem
in SimpleTools, I found it and a serious problem I bet most C
compilers have.
If you have allocated a relocatable block of memory with newhandle and
are keeping strings in this block, you cannot safely call a toolbox
routine which may allocate memory with one of those strings! The
reason is because the string has to be converted into a Pascal string
before the toolbox call and converted back to a C string after the
call. If the memory manager decided to move your block, the C toolbox
interface doesn't know about it and never gets a chance to turn your
string back into a C string. You can be left with a Pascal string in
your block. For example, I keep a menu's item name in a structure
allocated with newhandle. I cannot call appendmenu with this string.
I either copy the string to an auto variable in the procedure or lock
down the relocatable block. I suggest copying it so that you don't
jam up any memory compactions.
I am using Magamax C but don't blame them for this problem, I bet the
other compilers have the same difficulty.
Erik Kilk
------------------------------
Date: Tue, 11 Jun 85 19:49:35 CDT
From: Mike Caplinger <mike@rice.ARPA>
Subject: Mac disk caches?
Has anyone used either the Mainstay or Nevins disk caches? How well
do they work? Has anybody written a public domain cache? Is there
any point in doing this for a 128K Mac?
- Mike
------------------------------
Subject: Suggestion to replace RAMdisk
Date: 09 Jun 85 18:00:27 EST (Sun)
From: Steven B. Munson <sbm@Purdue.ARPA>
I remember hearing someone on the net ask (in an article about
how the 128K Mac was being forgotten) for someone to write a RAMdisk
for the 128K Mac, and thinking, "What are you going to do with a 6K
RAMdisk?" Well, if anyone is looking for something really nifty to
write, how about considering something better than a RAMdisk for a
128K Mac? I have seen something called TurboCharger advertised for
$95 in MacWorld, which caches disk blocks in memory, apparently only
performing disk I/O when it is absolutely necessary. This is
potentially better than a RAMdisk; you only need to clutter up memory
with the disk blocks that are used, not entire files, so that a cache
small enough to fit on a 128K Mac could still be useful, at least to
stop the disk from spinning every 8 seconds in MacTerminal.
Unfortunately, the advertisement said that TurboCharger only worked on
a 512K Mac.
I do not have Inside Macintosh, or I would write this one myself,
but I envision something like the following: a desk accessory (or
maybe an application, so it could be the startup application) that
installs itself on the system heap and intercepts all disk reads and
writes, maintaining a cache (of user-requested size) of disk blocks.
Each of the blocks is labeled by disk name, block number, and read or
write. The "cacher" uses some method of determining whether the disk
block in question goes in the cache or not, which could be as simple
as least- recently-used, but might want to be more intelligent for use
with very small caches. Blocks in the cache that have to be replaced
are disposed of if they are "read" blocks, and written to the disk if
they are "write" blocks.
The idea is that blocks read from the disk very frequently should
be kept in the cache, so that they only have to be read once, and
blocks written to the disk don't cause any I/O until the cache fills
up. Blocks frequently overwritten don't have to cause any I/O, since
the block in the cache can be overwritten instead. The
least-recently-used algorithm might be replaced by something that
keeps track of the frequency of access of disk blocks for small caches
that would fill up quickly; I will have to think about that one. It
might be a good idea to perform disk I/O during idle time to clear out
the cache or something.
I think this is a neat enough and simple enough idea that I might
even buy Inside Macintosh to do it myself, but, if anyone else thinks
this is as neat as I do and knows how to do it, let me know, and we
can trade ideas. If anyone has seen one of these already, I would
appreciate a pointer to it.
Steve Munson
sbm@purdue.ARPA
sbm@purdue.CSNET
------------------------------
Date: 18 Jun 1985 19:10-EDT
From: Henry.Kautz@rochester.arpa
Subject: Word File Format?
Does anyone know the format used by Microsoft Word files? If you do,
PLEASE send me a summary. I'll post to the net if there is a
response.
---- 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: Thursday, 6 June 1985 16:22:25 EDT
From: Peter.Monta@cmu-cs-g.arpa
Subject: SUMacC sound driver interface ?
I am trying to play a list of four-voice chords with SUMacC. It seems
that SUMacC supports a different StartSound than is described in the
Sound Driver Programmer's Guide, version of 11/15/84; the SUMacC
routine supports only the four-voice synthesizer and does not provide
completion routines.
So, I am able to start a chord and make it last for any duration, but
how am I to know when it stops, so that I can start the next (SUMacC
does not provide a SoundDone function)? Or, as the manual suggests,
if I set the duration to some large value to avoid clicks, how do I
know when to change the rate fields?
If anyone has successfully used SUMacC to play lists of chords, I'd
like to know how you did it.
Thanks,
--Peter--
------------------------------
Subject: Homegrown Cabling for AppleTalk ?
Date: 17 Jun 85 23:09:27 EST (Mon)
From: Christopher A Kent <cak@Purdue.ARPA>
I haven't gotten two Macs together into the same room yet, but I
decided tonight to start experimenting. I have a paper to do, we just
received a LaserWriter, and I thought I'd try to make use of those
pieces. So I cobbled up a cable, 3 straight through, 5 and 9 swapped,
and tried to hook the LaserWriter and the mac (a 128K model) together,
figuring if two Macs can boogie this way, a Mac and a LaserWriter
should be able to.
I tried running the test/installation software that came with the
LaserWriter, to no avail. Choose Printer (v1.1 in the lower right
corner) never has the AppleTalk radio buttons ungreyed (most
disappointing.) The printer namer claims that it can't load AppleTalk
(not enough memory?) When I try to Choose Printer out of MacWrite, it
doesn't even launch -- it just beeps at me.
This is really annoying. I'd really rather not have to go out and buy
all the "real" AppleTalk components this month, the budget's pretty
tight as it is. Can anyone help me out?
Cheers, chris
------------------------------
Date: Fri, 7 Jun 85 21:35:56 pdt
From: ix924%sdcc6@SDCSVAX.ARPA (Chris Borton)
Subject: MacTracks problems.
Has anyone out there also had problems with Mac*Tracks and Mac-
Paint? Mac*Tracks, for the benefit of those who haven't seen it, is
a wonderful DA that allows a series of mouse movements/buttons to be
recorded and thereafter associated with a control character. It dif-
ferentiates between upper and lower case, allows all keys, not just
alpha, to be used, and the smartest thing is that it keeps a separate
set of keys for each application. i.e. if you define <cntrl>a to
close the Get Info window on the Finder, it won't execute the same
command in MacWrite. You can make a separate <cntrl>a for MacWrite.
I have it on all my used-a-lot disks, but ran into problems with Mac-
Paint. The first time I tried to install it it would always end with
a long bell. I've seen this happen before, but don't know what it
is. I then tried again later to install it; this time it went fine.
Now, however, Show Page in MacPaint always bombs ID=10 (line 1111
trap). I tried to delete Mac*Tracks with the Font/DA Mover; it
thought it did. Funny thing: when selected it said only 678 bytes
selected, and I know that Mac*Tracks is more on the order of 17K
because that's what my disk space decreased by when I installed it.
After deleting it I ran Paint; it still bombed. Went back to the
DeskTop, and what should I see but a Mac*Tracks File. Couldn't
delete it or the Paint 1 and 2 since the INIT bits were set. Used
Fedit to clear those bits, and then trashed the three files. Ran
Paint again, still bombed, and on the Desktop were the same three
files with the INIT bit set again. There must be some resource from
Mac*Tracks that isn't bundled with the DRVR and is recreating the
file every time, as well as the bomb. It did this with both MacPaint
1.4 and 1.5. Anyone know of a cure?
Chris Borton, UC San Diego undergraduate CS
{ucbvax,decvax,akgua,dcdwest}!sdcsvax!sdcc6!ix924
------------------------------
Date: Wednesday, 12 June 1985, 08:00-PDT
From: KUO at SCH-GILA
Subject: Macs In-Heat
To all Mac users with heat related problems:
I have found a centrifugal blower fan that fits inside the Mac. It is
approximately 5" in diameter and 1.5" thick. I am experimenting with
various mounting schemes. Anyone interested please contact me over the
net. I think this can be a aftermarket product.
Kuo-Fung Yen Micro-Air Research
------------------------------
Date: Thu, 13 Jun 85 12:52:55 pdt
From: jww@SDCSVAX.ARPA (Joel West) (ttyj0)
Subject: More overheating comments
I, too have experienced problems over the last 16 months with Macs
overheating. The problem seems to be worse when:
1) The machine has been on for more than 2 hours
2) The ambient temperature is over 75 F; or
3) The case is exposed to direct sunlight. I wrote a book
last fall using the Mac and was on the machine 16 hours some days.
Using a pre-release MacWrite 3.x, I experienced a number of crashes;
some were probably software, but some were probably hardware. I
suspected the latter when the machine would no longer do known things.
During the winter I haven't used the fan, but may still have
experienced some overheating problems (during software development,
it's hard to tell.) Recently, I have spent 4-10 hours on weekend days
using the Mac. The weather is warm here, and during our 80 degree
days the machine acts up after 2 or 3 hours. As noted by
pugh%e@LLL-MFE.ARPA (Vol. 1, #6):
It worked fine after it was no longer warm to the touch.
Once the machine has overheated, using the 5" table fan I keep by the
Mac is no use. The right approach seems to be in hot weather, or in
warm weather and you plan to use it for a few hours, the fan should be
started from the very beginning.
It seems to me to be a very awkward way around Mr. Job's anti-fan
obsession. I do like the quiet, but obviously the convection cooling
of the current design won't cut it outside an air-conditioned
environment. If someone made a reasonably priced ($30, not $70)
external fan (ala Apple II) I'd probably buy it, particularly since I
plan to start running the machine 24 hours in a few months.
Joel West
CACI, Inc. - Federal (c/o Gould CSD)
{ucbvax!sdcsvax,ihnp4!bonnie}!gould9!joel
gould9!joel@NOSC.ARPA (also joel@NOSC)
------------------------------
End of INFO-MAC Digest
**********************