info-mac@uw-beaver (05/20/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Sunday, 19 May 1985 Volume 2 : Issue 48
Today's Topics:
Mac Fest at Stanford
Israeli Maclub
New Idle DA
Ramdisk finesse, Macterminal customizing
.BIN binary file format. From:MAC%PPC@LLL-MFE
A suggestion for C compiler review guidelines
Bug? Time and Date keeps changing. correcting file-creation date?
Atari 520ST for $789
----------------------------------------------------------------------
Date: Sun 19 May 85 18:11:01-PDT
From: John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
Subject: Mac Fest at Stanford
( Let me change hats for the moment, to a member of the Stanford
Users' Group:)
Stanford Macintosh Users' Group with help from Apple, will fill the
next two days with every imaginable activity related to the Macintosh.
Those in the vicinity may want to attend. Others who have not take the
opportunity to put one together ( we took a suggestion from Berkeley,
who, to the best of my knowledge ran the first ) might take this as an
example.
THe list of commercial exhibitor runs: Aldus, Apple, Berkeley Mac
Users' Group, Computer Software Design, Consulair, Creative Solutions,
Corvus, Dayna Communications, Enterset, ExperTelligence, Great Wave
Software, Haba Systems, Hayden, Infoserve, Innovative Data Designs,
Koala TEchnologies, Living VideoText, Lotus, Microsoft, Themis Systems
and Westridge Designs.
Exhibits will be open Monday and Tuesday 11AM to 5PM, on the second
floor of Tresidder Union. Seminars will run concurrently with the
Exhibits, and "CS001c", Introduction to the Macintosh, will open its
Tuesday sessions to the public.
On Monday night Alan Kay will speak in Terman Auditorium, at 7pm. On
Tuesday night the Macintosh Development Team will offer a panel
discussion in Kresge Auditorium, also at 7pm.
Attendence to all activities is free.
------------------------------
Date: 18 May 85 13:27-IDT
From: NYGUY%WEIZMANN.BITNET@Berkeley
Subject: Israeli Maclub
To: all Mac users From: The Irsaeli Macintosh Users Group - Maclub
Subject: Software trading
Dear Mac user,
The Israeli Maclub want to establish connections with Mac users in all
over the world.
We have alot of software (app. 180 disks) and we want to trade it with
you, if you are interested please drop a note to:
dena@taurus.bitnet
Or to the following address:
The Israeli Maclub
8 Romema st.
Tel Aviv, 69419 I S R A E L
------------------------------
Date: Thu, 16 May 85 10:30:57 pdt
From: Larry Rosenstein <lsr%apple.csnet@csnet-relay.arpa>
Subject: Idle DA
I am enclosing the latest version of Idle; these are messages that I
posted to USENET a few weeks ago. (This is the second version; I am
not sure if you ever had this version archived.) I am considering
posting the sources, but there is one more bug that I want to fix
first.
Larry
(P.S. I would have sent this earlier, but our mailer has been broken.)
===== [ The following explanations are saved in da-sleep4.doc -jma ]
I have posted 2 things to net.sources.mac.
The first is a new version of my Idle desk accessory. The only
changes since the first posting are:
* There is a 3-level (can be changed; see below) search path for the
icon to display. As distributed, it looks for: (1) ICN# 128, which is
generally the application's icon; (2) ICN# 130, which is the trash
can in the Finder, and (3) ICN# 3, which is the Macintosh icon. The
first icon that exists in the resource file(s) is used.
* There was a (known by me) bug where the menu bar would not be
cleared if the application happened to redraw it. I did not know of
any such applications at the time, but it turns out that Concertware
is such an application. The new version now erases the menu bar if it
finds that it has been redisplayed.
* The DA is now called New Idle. You can rename it with the
appropriate utility. The name should have a null at the beginning to
satisfy the PD DA Mover.
* I fixed a bug in which the icon could be displayed partially off the
screen.
The second posting is of a Resource Editor template for customizing
the new Idle DA. You must have the latest (Feb 85) version of the
Resource Editor to use this. If you paste this resource into your
Resource Editor, you will be able to change the icon search path, as
well as the frequency with which the icon is moved.
Both files are distributed in BinHex 2.1 format. You will need RMover
or the Resource Editor in order to install the resources into the
appropriate files. More complete instructions are posted with the
binary code.
Enjoy. Let me know of any comments you have.
-- Larry Rosenstein Apple Computer
UUCP: {nsc, dual, voder, ios}!apple!lsr CSNET: lsr@Apple.CSNET
===== This is the new Idle DA in BinHex 2.1 format. When you complete
the conversion, you will end up with a file containing a DRVR
resource. Use RMover or Resource Editor to paste the DRVR into a
System file or application.
If you do not know what Idle is, it is a desk accessory that erases
the entire screen and flashes an icon at random positions. Holding
down the option key will reveal the original screen display. (The DA
does not save the screen bits, so the host application must be able to
respond to update events.) In this version you should get the
application's icon when you are running most applications, the trash
can if in the Finder, and a Macintosh in all other cases.
Enjoy.
Larry Rosenstein Apple Computer
UUCP: {nsc, dual, voder, ios}!apple!lsr CSNET: lsr@Apple.CSNET
[ New Idle is archived in da-sleep4.hcx -jma ] =====
This is a resource that you can use to customize the latest Idle DA,
posted in BinHex 2.1 format. You must have the latest Resource Editor
(Feb 85) in order to take advantage of it.
When you convert this you end up with a file containing 1 TMPL
resource. Use the Resource Editor to paste this resource into itself
(or a backup copy of itself). Close the Resource Editor window to
ensure that the file is updated on the disk.
If you want to customize the new Idle DA do the following:
* Find the DA (it's a DRVR resource) in some resource file. It can be
a System file or the original file it came in.
* Hold down the Option and Shift keys and double click to open the
resource.
* You should get a scrollable list of resource types, including one
that says IDLE. Choose IDLE from the list.
* You should get a dialog window that breaks the DA header into a
number of fields. You must be sure not to change anything that will
break the DA.
You CAN change the following:
- The timing field (value is in 1/60 of a second); this determines
how often the DA gets control to move the icon.
- The list of icons; the original DA has a 3-level search path; you
can change any of those levels. Be sure that the resource you specify
is in the form of an icon.
- Adding/removing icons from the search path. This is more tricky.
You can select any of the separators (*****) in the search path and
give the New command to insert a new element in the list after the
selection. Or choose Clear to remove the element after the selection.
The count of icons in the list will be updated automatically.
Changing the # of icons in the list affects the offset from the DA
header to its code routines. You MUST also patch these offsets (there
are 5 of them: Open Offset, Prime Offset, Control Offset, Status
Offset, and Close Offset). Each entry in the icon list is 6 bytes; if
you add 1 entry, add 6 to each of the offset values (they are in
decimal).
I hope this is clear. Let me know if you have any problems or
comments.
Enjoy.
Larry Rosenstein Apple Computer
UUCP: {nsc, dual, voder, ios}!apple!lsr CSNET: lsr@Apple.CSNET
[ This resource file is archived in da-sleep4.resource -jma ]
------------------------------
Date: Sat, 18 May 85 13:50:13 pdt
From: ix924%sdcc6@SDCSVAX.ARPA (Chris Borton)
Subject: Ramdisk finesse, Macterminal customizing
Some of you have probably seen the new RAMdisk
available on net.sources.mac called RamStart. It doesn't look like
anything radically new over Assimilation (auto load what's in folder,
doesn't Eject...) but it has a very nice surprise. Slim Mac owners
now have a RAMdisk!!!! I was shocked to pieces when I ran it and it
worked! It allows a RAMdisk from 6K up to 26K. Although this isn't
large enough to hold something really useful like a system or finder,
it does have uses. For example: put the MacTerminal document you use
(don't save anything much/important on it) in there and no more disk
whirring!
Another patch I've seen hinted at but never explained
here on the net is how to put your own default settings into
MacTerminal. If you have a MacTerm document that has the settings the
way you like them, use ResEdit to go into it and Copy the INIT
resource. Then open MacTerminal and Paste it into there. When you
boot MacTerm without a document now it will come up as Untitled,
however the settings will be those of your document, making them
"defaults."
Happy Maccing! Chris Borton, UC San Diego Undergraduate CS
{ucbvax,decvax,akgua,dcdwest}!sdcsvax!sdcc6!ix924
------------------------------
Date: Thu, 16 May 85 05:30 PDT
From: MAC%PPC@LLL-MFE.ARPA
Subject: .BIN binary file format From:MAC%PPC@LLL-MFE
The following is a message I received from Scott Watson
(Red-Ryder4,5) concerning the critique by Harry Saal INFO-MAC Digest
V2 #44
Subj: BIN format comments... Date: 13-May-85 03:08 From: Scott
Watson 73176,61
Tom, appreciate the opportunity to comment on Harry's letter, as I
don't have access to ARPAnet, feel free to pass this along in any way
you see fit.
Comments to Harry Saal's critique of the Binary Format:
It is unfortunate that Harry was not a participant in the round-table
(round-modem?) discussion held among numerous Mac communications
program authors when the format was adopted for lowest common
denominator usage. I do appreciate many of his feelings, and would
like to pass along one author's feelings about his critique, and the
protocol in general.
Harry feels that the version byte (offset 0) should be extended to
four bytes to make room for upward expansion. As this byte is meant
only to be an echo of the standard Mac file directory structure, my
feeling is that if Apple changes this byte, they'll change many others
necessitating a complete overhaul of the binary header record. As
Apple has indicated upwards compatibility will be maintained in future
DOS/ROM upgrades, I'm not convinced extending this byte would add
utility to the format.
It's important to note that I refer to this entity as a "format" and
not a "protocol". Correctly implemented, it should operate with no
problems using any standard protocol (XMODEM, Kermit, etc.). The next
version of my program Red Ryder will be extended to not only support
the Binary format, but 7th bit quoting as well for systems using other
than no parity. The ultimate goal of the binary format adopters was to
unanymously agree on a format that would be simple to implement, yet
would communicate the base necessary information to reconstruct a file
correctly on a receiver's Macintosh. It in no way is meant to make the
file useful to non-Macintosh machines, and Dennis's suggestions for
CTRL-Z's, padding, LF's after CR's, etc., were just that -
suggestions, and are in no way to be considered cast in stone as part
of the format.
The implementation in Red Ryder does not do any preprocessing of the
file. If it is a non-TEXT type file, the file is sent as it exists on
the disk (data fork only). If it is non-TEXT, the binary format is
used. I am confused by Harry's extended signiture block and its
purpose and would like to hear more on this issue. Again, since the
header record has an exact byte placement by offset, and the carrier
protocol is assumed to trap errors, and additional CRC is superflous -
no LF's would ever be inserted in the header record for any reason
except bad programming, which of course is beyond the format's
description.
As for making byte offsets 74, 81, and 82 "reserved" rather than
"forced zero", again this is superflous. Most of the binary format
programs will not even bother to look at these bytes since they have
no meaning to the current Mac directory structure. Likewise, even
though
[ text missing! ]
SEVERAL additional fiel as quickly as possible. To tag more overhead
into Kermit or XMODEM can be likened to stuffing 10 pounds of manure
in a five pound bag. Again, I don't wish to discourage authors from
adding utility to file transfers, but they should understand any
diddling of the file should be done once it has been received
correctly. I personally like the PackIt library program and hope it is
adopted by all serious modem users. But few users would reject the
format on the basis of that the PackIt program must be used externally
of the transfer program. A smart author might wish to have a menu
choice in his communications program for packing and unpacking files.
Hmmm....
Again, although I am only an implementer of the protocol and not the
author, I do appreciate comments such as these and encourage more. If
the protocol proves too simple for real world needs, I will be the
first looking for a better solution. As of this day, I can say that it
seems to meet the needs of 99% of communicating Macintoshs and it's
non-elitist, non-exclusive nature guarantees broad acceptance.
Scott Watson
------------------------------
Date: Mon 13 May 85 15:01:22-PDT
From: Gustavo Fernandez <FERNANDEZ@SU-SCORE.ARPA>
Subject: A suggestion for C compiler review guidelines
There is a plethora of C compilers available and I have yet to see a
complete and impartial review of all of them. We are seeing the same
phenomena that we saw with the MS-DOS C compilers 2 years ago. (look
at the August '83 Byte) In any case, here is what I think is a
complete list of all of the compilers available, or announced.
SUMACC C - Vax cross compiler - No C I/O support, no segmentation.
Softworks C - (the first native, and most questionable
- based on Whitesmith's C) Hippo C - (very slow, but the
only one with a source level debugger.) Aztec (Manx) C - The most
unix-like, has a make facility, Copy protected. Consulair C - One of
the best supported. Has a horrible linker. Megamax C - A lot of
people like this one. Green Hills C - Beta versions available for
Lisa, will be included with MDS512 ons available on Lisa, will be
included with MSD512. DeSmett C - About to be released - nice price
at $150.
I cannot make full reviews of all of these packages as I use the Lisa
Pascal development system. I CAN offer the following guidelines for
potential users.
Toolbox Support - How well does it support the Mac user interface?
what is the largest Macintosh application which has been written using
the compiler? This is the main difference between a compiler and a
development system. A compiler translates code. A development system
has full header, example files, mac-specific utilities, etc.
Development support - The Mac user interface is nice for end-user
applications but not so nice when batch-oriented work (i.e.
compilation) is required. Is a good exec file system provided where
you can create a script which as a minimum, will compile all of the
files which are newer than the corresponding object files.
Expert support - How may programmer's tools are available? How well
does it support a hard disk environment? (most copy-protected programs
fail here even if they only require the key disk since you are always
going in and out of the shell, and programs tend to bomb a lot.)
Novice support - How much hand holding does the system do? Any
tyutorials which lead you through a complete Mac Application? How well
does it follow "Inside Macintosh?" (C itself fails miserably here
since all of the calling prototypes are written for Pascal, and the
translation especially where strings is concerned, is compiler
dependent.)
Programmer support - How fast is the compiler? What is the minimum
compile time for "Hello, world" and what is it for a 1,000 line source
file? How fast does the linker go through the standard library file?
How fast can it link a dozen user code files? Is an error file created
and can the editor read this file to point the cursor at the point in
the source code in which the error occurred? Is there a lood LINT
program available?
End-user support - How fast is the compiled code? How much of the
library must be linked in when a single printf is invoked? How fat is
the generated code? How much of the library was optimized in assembler
for speed and space efficiency? Are applications "double-clickable?"
ROM support - Does the compiler support segmented code using the
Macintosh segment loader? Are all ROM calls supported? (not just the
easy ones) Are all of the data structures specified in libraries? Did
the compiler writer have to re-invent the wheel regarding a specific
aspect of the Mac ROM or user interface, and write his own code to do
something that the Mac already does?
Library support - Not all of the documented routines in IM are ROM
calls. Many are subroutines in the Lisa object library. Are all of
these implemented?
UNIX support - How much of the UNIX library is available with the
compiler? How easily can a UNIX program be ported to the Mac? How
many equivalent routines have slightly different names and/or calling
sequences from their unix counterparts?
C support - Does the compiler comform completely to the K&R standard?
Does it allow common extensions to C since K&R such as enums,
structure copies, etc? Does it support floating point? if so, does it
use the Mac SANE library?
Obviously, no compiler will score streight A's on all of these
counts, but we can hope that as new versions are introduced, the
"ideal" becomes closer to reality.
------------------------------
Date: Sat 18 May 85 20:24:40-CDT
From: Werner Uhrig <CMP.WERNER@UTEXAS-20.ARPA>
Subject: Bug? Time and Date keeps changing. correcting file-creation
Subject: date?
It keeps happening to me over and over - all of a sudden I find my MAC
with a changed date and time, which results in incorrect
date/time-stamps on files.
I have not been able to narrow down when exactly this happens,
however, I have not removed the battery, so noone need to suggest
that. It must be something else, like turning the machine on/off or
booting from a different Finder.
Now besides wanting that to stop, of course, I need to find a
convenient and easy way to modify the incorrect date/time-stamp of
files created before I noticed the changed date/time. Any
suggestions?
Cheers, Werner
------------------------------
Sender: "Jack Bicer.OsbuSouth"@Xerox.ARPA
Date: 15 May 85 15:40:48 PDT (Wednesday)
Subject: Atari 520ST for $789
From: Bicer.OsbuSouth@Xerox.ARPA
Reply-to: Bicer.OsbuSouth@Xerox.ARPA
In the May issue of Byte, an outfit called 'Computer Mail Order' was
advertising the Atari 130ST and the 520ST(512K Ram). So I called them
up and asked for prices and availability. I was told that Atari
dropped the 130ST and the 520ST with a 3.5 inch drive and a monitor
will be selling for $789. He was ready to take my order for July
delivery.
Jack Bicer
------------------------------
End of INFO-MAC Digest
**********************