Moderators.Jon.Pugh;Dwayne.Virnau;Lance.Nakata@SUMEX-AIM.STANFORD.EDU (06/12/88)
INFO-MAC Digest Sunday, 12 Jun 1988 Volume 6 : Issue 60
Today's Topics:
Fortran competition: Absoft, Mactran and MPW (long)
tired of xbin dumping core ?? here is a fix.
Re: InvisHDMainBo3b
InvisiHDMainBo3B File
Sound cdev patch
BroadCast's shutdown feature
Re: Appleworks->MacWrite Transfer
More info on Dimmer/Mac ][/System 6.0
Shutdown of OREGON1
Bill Gates in Copenhagen
MF Event Documentation
MacMysteries
Disassemblers
International Sorting
OCR-A font
JIODone call at end of drvrCtl DA routine
Asnyc Peek
Anyone know if Apple is planning to offer 1.6 Mb floppy capability?
----------------------------------------------------------------------
Date: 5 Jun 88 18:11:00 EST
From: "Charles E. Bouldin" <bouldin@ceee-sed.arpa>
Subject: Fortran competition: Absoft, Mactran and MPW (long)
Reply-to: "Charles E. Bouldin" <bouldin@ceee-sed.arpa>
I have been beta testing and/or using the 3 Fortran compilers for the Mac. In
fact, this is taken from the article that I sent to Mactutor. First, the raw
numbers on the tests that I ran. I chose to run the Sieve, Whetstone and
LinPack. These are virtually universal tests of all Fortran compilers on all
computers. These will tell a lot about the number crunching ability of these
compilers, although virtually nothing about the integration of the compilers
into the Mac environment. All tests were run on an upgraded 68020/881 Mac+
with Novy systems board. This gives about Mac II speed. Table entries are
always, top to bottom, DCM Mactran, Absoft, and Lang. SYS.
With that said, the results:
Compile and Link Time Code Size Run time
Sieve 5.2 sec DCM 155K bytes 12.1 sec
5.1 sec Absoft 13K 9.8 sec
29.0 sec Language Systems 49K 13.5 sec
Whetstone 14.5 sec 171K 16.0 sec
7.8 sec 19K 12.4 sec
52.8 sec 54K 12.4 sec
LinPack 11.5 sec 160K 549K whets*
6.3 sec 16K 526K whets*
40.2 sec 49K 347K whet*
*On the whetstone test, the results are given in units of "whetstones" that
reflect have many floating point operations were done. On the whetstone test,
a larger number means FASTER execution. All other execution times are in
seconds, where, of course, smaller number means faster.
Strictly by the numbers, Absoft is a clear winner on 7 of 9 tests, ties one
and loses whetstone speed slightly to DCM Mactran 77. But, the numbers don't
tell all. Absoft's bugginess is legendary. Their small code size is because
their philosophy is to put zero support for the Mac environment in the runtime
package; for example, the default runtime window is a simple "glass tty". If
you want Mac features, you must do it yourself.
DCM suffers from the staggering 155K runtime library which is "dumb-linked"
into your code. Thus, "hello, world" takes 156K. They even force you to carry
the software floating point libraries around when you generate hardware
floating point! No excuse for this, in my opinion. To be fair, part of the
size is Mac environment stuff in the runtime libs.
MPW fortran (language systems) is slowest on compile and is intermediate in
code size. I think they hit the correct balance on code size, but need to work
on the compile speed. They are competitive on Sieve, lose big on whetstone,
and actually win Linpack (12.37 secs to Absofts 12.44). Lotta bugs still in
the beta compiler, however.
Easily the worst thing with all 3 compilers is the bugs. Folks on this net are
well aware of the sad history of the Absoft compiler, but I also found code that
DCM Mactran wouldn't compile which Absoft would. Lang. sys. compiler is still
(beta, remember, I wanna be fair) easy to crash, either during compile or at
runtime.
Bottom line for me: I am sticking with Absoft compiler, since I think I know
most of the things to avoid at this point. Neither of the alternatives shows
(yet) enough improvement for me to switch. Absoft will have a significantly
improved 2.4 release in late summer, with a lot of bug fixes, so I am going to
wait and see. If 2.4 doesn't fix known problems, then I will think again about
changing compilers.
------------------------------
Date: Mon, 6 Jun 88 02:06:48 CDT
From: werner@rascal.ics.utexas.edu (Werner Uhrig)
Subject: tired of xbin dumping core ?? here is a fix.
if you use xbin on your UNIX-box to unhexify archived Macintosh files,
you, probably, know that every so often xbin dumps core.
this is, usually, caused by the fact that the name of the file which
xbin is trying to create contains characters which are not legal under UNIX.
this can be fixed why modifying xbin so that it does
not try to create files with illegal characters.
below follows a diff-file of the necessary C-source changes to the xbin
source-code (which can be found in the archives at SUMEX and, probably,
on your machine somewhere, if the executable is available)
255,262c255,266
< /* get rid of troublesome characters */
< for (np = namebuf; *np; np++)
< if (*np == ' ' || *np == '/')
< *np = '_';
<
< sprintf(files.f_data, "%s.data", namebuf);
< sprintf(files.f_rsrc, "%s.rsrc", namebuf);
< sprintf(files.f_info, "%s.info", namebuf);
---
> /* get rid of troublesome characters */
> for (np = namebuf; *np; np++){
> if (*np == ' ' || *np == '/' || *np == '!' ||
> *np == '(' || *np == ')' || *np == '[' || *np == ']'
> || *np == '*' || *np == '<' || *np == '>' ||
> *np == '?' || *np == '\'' || *np == '"' || *np == '$')
> *np = '_';
> *np &= 0x7f;
> }
> sprintf(files.f_data, "%s.data", namebuf);
> sprintf(files.f_rsrc, "%s.rsrc", namebuf);
> sprintf(files.f_info, "%s.info", namebuf);
------------------------------
Date: Mon, 6 Jun 88 09:38:38 edt
From: moy@nrl-csr.arpa (Gene Moy)
Subject: Re: InvisHDMainBo3b
This is in response to the following:
I have a file called InvisiHDMainBo3b on my hard drive. It is in the
>root directory. It takes up 325460 bytes in the data fork, and has no
>resource fork. It is flagged as Invisible. I recognized the Bo3b as the
>name of someone from Apple (see your TechNotes). What is this file? Do I
>need it? It's taking up a lot of room.
>
This file is created by Aplle's HD Backup program. I t keeps track of
files that have been backed up. There is also a file on each of
the diskettes InvisHDBo3b on each of the floppies used in the backup
process. The file starts out small if you do a complete backup around
several hundred Bytes (yes Bytes, not KBytes). Whe you do incremental
backups, this file seem to get larger. Does it have to be that large, I
don't know. I did delete this file on my hard disk and HD Backup did
not think I had ever done any backups before.
------------------------------
Date: Tue, 07 Jun 88 09:30:40 EDT
From: Atul Butte <ST602397%BROWNVM.BITNET@Forsythe.Stanford.EDU>
Subject: InvisiHDMainBo3B File
Brian Schipper <claris!skip@ames.arc.nasa.gov> answered my question about
that invisible file on Apple Hard Drives:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
To: ST602397@BROWNVM.BITNET
Subject: Re: InvisiHDMainBo3b
This file is used by Apple's HD Backup program to keep track of when
and where each file has been backed up. You'll need it if you want
to do incremental backups from your last backup, or if you want to
restore a file automatically.
UUCP: {ames,apple,portal,sun,voder}!claris!skip Applelink: SCHIPPER1
Arpanet: claris!skip@ames.arc.nasa.gov Phone: 415-960-2618
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_______________________________________________________________________
Atul Butte
Brown University /-------\ /---------\
. ! OK ! ! CANCEL !
. \-------/ \---------/
ST602397%BROWNVM.BITNET@MITVMA.MIT.EDU
------------------------------
Date: Tue, 7 Jun 88 09:28:36 PDT
From: PUGH@NMFECC.ARPA
Subject: Sound cdev patch
For those of you receiving Apple's System 6.0, you might dislike the small
size of the Sound cdev's selection window, as I did. You can enlarge this
with a couple of simple patches. This is, of course, not recommended, so
beware.
Open the Sound file with a disk editor and change
0095 0062
to 0095 00FD
and 009E 0054
to 009E 00F1
What you are doing is to enlarge two DITL items in the Sound resources.
This is a bit difficult to do in ResEdit due to the layering of other DITL
items. I used DeRez and Rez to change them and then compared them to get the
patches since I can't distribute a modified piece of Apple's software.
Jon
------------------------------
Date: Wed, 8 Jun 88 21:59 MET
From: JOACHIM LINDENBERG <JOACHIM@iravcl.ira.uka.de>
Subject: BroadCast's shutdown feature
I got several mails concerned about the possibility to turn off
a Macintosh remotely. Calm down...
*** NO ONE CAN SHUTDOWN YOUR MACINTOSH UNLESS YOU ALLOW TO ! ***
The shutdown mechanism is a runtime option, available on Mac IIs only.
If used on Mac 512, +, SE only the shutdown dialog will be presented,
power will remain on. There is a flag in the BroadCast globals called
"shutdownenabled", that if true will allow shutdown messages to be
processed. A shutdownmessage is simply an empty message.
*** NOTE THAT THIS FLAG IS OFF BY DEFAULT - YOU NEED A PROGRAM TO
SET IT (or enter the debugger) ! ***
The user interface of BroadCast makes no provision to enable or send
such messages, as it has been implemented for use in our lab - used
by undergrad students to learn programming - it allows the operators
to turn all machines collectivelly off. A special program is required
to enable/send these type of messages, ON BOTH MACHINES.
The feature is useless in a standard environment where the user should
have complete control over the machine. I can't imageing that you'll
need this feature. I mail you this information, that you get the feeling
that none is able to shur your machine off without your consent.
Please mail all questions/suggestions/bugs to one of the addresses
below, use the bitnet address given only to request a copy of broadcast.
Joachim
-
Joachim Lindenberg, Dept. of Computer Science, University of Karlsruhe
Sommerstrasse 4, 7500 Karlsruhe 1, Federal Republic of Germany
joachim@ira.uka.de, joachim@germany.csnet, ..!mcvax!unido!uka!joachim
-
Joachim Lindenberg, Dept. of Computer Science, University of Karlsruhe
Sommerstrasse 4, 7500 Karlsruhe 1, Federal Republic of Germany
joachim@ira.uka.de, joachim@germany.csnet, ..!mcvax!unido!uka!joachim
------------------------------
Date: Fri, 10 Jun 88 07:55:36 PDT
From: halff@nprdc.arpa (Henry Halff)
Subject: Re: Appleworks->MacWrite Transfer
> Date: Fri, 3 Jun 88 14:01 EST
> From: JJ_KRAME%FANDM.BITNET@cunyvm.cuny.edu
> Subject: Appleworks->Macwrite transfer
>
> Hello All,
>
> I need to transfer a large appleworks(Apple ][)file to Macwrite. I have tried
> Apple's file exchange and MacLink but have found that there is no suitable
> translator.. Can anyone inform me of a simple method for completing this
> task? Any help would be appreciated. Joe Kramer
>
> Bitnet: JJ_kramer@fandm
> Consultant -- Franklin and Marshall College
>
Funny thing. I had to do the same thing yesterday. Here is my
best solution.
0. Put a beer in the fridge.
1. On the ][, load Appleworks and bring the file up on the
desktop. Hit open-apple-P and choose the last alternative on the
menu, namely, print to disk. Make up a new file name and supply
its full path name when Appleworks asks for it. The file will be
printed to disk in the Apple ]['s funny version of ASCII.
2. Get yourself an Apple ][ telecommunications program. Figure
out whether it runs under Prodos or DOS 3.3.
3. If the telecommunications program runs under DOS 3.3, use the
PRODOS utilities to convert the file you created in step 1 to DOS
3.3.
4. Start the telecommunication program in the ][ and load a
telecommunications program (like miniterm or Red Ryder) on your
mac.
5. Hook the two machines together using modems or a null modem
cable. (How to make a null modem cable: Plug the Apple ][
imagewriter cable into the "telephone" jack on the back of the
Apple ][. Plug a regular modem cable into the "telephone" jack
on the back of the mac. Hook the two cables together with a
female-female gender gender changer. [How to make a female-
female gender change: Go down to Radio Shack ... .])
6. Set the two programs to communicate at the highest possible
speed allowed by the programs/modems.
7. Start a text capture on the mac. Have the Apple ][ transmit the
file you created in Step 1, or the one you created in Step 3.
(DO NOT USE AN ERROR CORRECTING PROTOCOL FOR THIS TRANSFER.)
When the file has been sent, close the text capture on the mac.
8. On the mac, get into MacWrite and open the file you captured
in Step 7.
9. Open the beer you put in the fridge in Step 0. It's probably
cold by now.
Hope this helps.
hh
------------------------------
Reply-to: pnet01!pro-simasd!pro-nsfmat!pro-la!pro-citadel!fredc@trout.
Reply-to: nosc.mil
Date: Sat, 11 Jun 88 04:58:01 PDT
From: fredc@pro-citadel.cts.com (Fred Condo)
Subject: More info on Dimmer/Mac ][/System 6.0
In an earlier message, I wrote that the Dimmer CDEV for the Mac ][, which is
by Chris DeRossi of Apple, is incompatible with the new system release (6.0).
Further investigation has shown that the incompatibility comes about as a
result of an interaction between Dimmer and the MacroMaker. You can use one or
the other, but not both. Of course, since Dimmer is a Mac-][-only CDEV, this
applies only to Mac ][s.
------------------------------
Date: Wed, 08 Jun 88 16:39:18 PST
From: "David Boyes (Network Postmaster)" <556@OREGON1>
Subject: Shutdown of OREGON1
This is primarily directed at the BITNET subscribers to the Info-Mac
Digest who receive their digests from MAC-L@OREGON1, but is of general
interest to this forum as well.
Host OREGON1 is being shut down by administrative fiat, therefore all
subscribers receiving digests from this site will be moved to other
servers over the next few days. You shouldn't miss any digests, and the
address for submissions is still Info-Mac@sumex-aim.Stanford.Edu.
Thank you for your patience in this manner. The Administrative Empire
won this round...
----------
David Boyes (503) 686-4394 |BITNET: 556@OREGON1
Systems Group |ARPA : 556%OREGON1.BITNET@
University of Oregon Computing Center| CUNYVM.CUNY.EDU
UUCP: [your fav backbone]...!tektronix!uoregon!oregon2!oregon1!556
------------------------------
Date: Tue, 07 Jun 88 21:00:23 DNT
From: Jakob Nielsen Tech Univ of Denmark
From: <DATJN%NEUVM1.BITNET@Forsythe.Stanford.EDU>
Subject: Bill Gates in Copenhagen
Bill Gates (CEO of MicroSoft) was in Copenhagen yesterday and gave
a talk on his views of the future in the IBM PC sector. He promoted
graphical user interfaces and windows very heavily and tried to
get everybody to jump on that bandwagon.
One of the major points of his presentation was a demo of PC-Excel
which was indeed nice and has some features not in the present Mac version.
Of most interest for this newsgroup may be the fact that Gates pointed
to Excel as the exemplary application for the new hoped-for consistent
user interfaces on the PS/2 (i.e. the same role as that played by MacWrite
in the Mac world). On the basis of my experience at a recent ACM workshop
on consistency,I asked Gates what other methods they would use to
ensure consistent user interfaces. The answer was not really satisfactory
but included a "MS Windows style Guide" (= Apple Human Interface Guidelines ??)
It certainly seems that the OS/2 will take people down somewhat the
same road as that travelled by Mac users.
------------------------------
Date: Sat, 4 Jun 88 13:23 EST
From: <BELSLEY%BCVMS.BITNET@Forsythe.Stanford.EDU> (DAVID A. BELSLEY)
Subject: MF Event Documentation
What are the sources available for documentation for the new Multifinder
Event items; that is, WaitNextEvent, Resume, Suspend, etc?
a. are there any non-ADPA sources, such as an add-on to Inside Macinosh?
b. are there any TechNotes that deal in detail with these items?
c. what is the relevant ADPA document name?
Many thanks to responders - I know this stuff has been around for a while,
but I've just encountered my first need for it. I am a bit miffed that it
doesn't seem to be available in the normal ways. This is material that is
highly akin to that of Inside Macintosh, and, to my way of thinking, ought
to be similarly available.
david a. belsley
boston college belsley@bcvax3.bitnet
------------------------------
Date: Mon, 06 Jun 88 11:33:17 CDT
From: CB Lih <CL06076@UAFSYSB>
Subject: MacMysteries
Hello, I have to setup Mac SEs on a regular basis. There's some things
that have been bothering me about this process. Perhaps someone on the
net could tell me why:
do they put the top of the plastic sack on the bottom of the SE?
do they put tape around the ends of the plastic sack on the keyboard cable?
don't they twist the screen adjusters so it uses the whole screen?
don't they give me a Mac II?
Ok, I know the answer to the last question. Any takers on the others?
And another thing. Why does the SE default to (tablet) instead of the
mouse? Even 'slow' would be a great improvement over 'very slow'.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sincerly, and I mean that,
=---> CB Lih <---=
User Services -> Computing Services -> University of Arkansas -> Fayetteville
CL06076@UAFSYSB Disclaimer: There's a hole in my ozone layer.
------------------------------
Date: Tue, 7 Jun 88 16:45 EDT
From: "Maj. Doug Hardie" <Hardie@DOCKMASTER.ARPA>
Subject: Disassemblers
I am looking for a disassembler that is not dependent on a particular
form of object code. The disassembler in the archive appears to look
for a specific form from one compiler and it will ignore code that is
not in that form.
-- Doug
------------------------------
Date: Wed, 8 Jun 88 01:19:59 PDT
From: Fung-Fung Lee <lee@shasta.stanford.edu>
Subject: International Sorting
Mac's international sorting routines are supposed to handle the sorting
processing for non-Roman scripts. However, I recently found that
they did not sort quite well with the Chinese Talk, the Chinese Script
Interface System. Is it possible to create my own ordering routines?
How can I do that?
Fung F Lee (lee@shasta.stanford.edu)
------------------------------
Date: Wed 8 Jun 88 08:18:16-EDT
From: Computing Analysis Corporation <eoyang@A.ISI.EDU>
Subject: OCR-A font
We have a need for an ugly font to be printed with a Mac on a Laserwriter:
The IBM Ball says OCR-A #96
Our people would rather produce the documents on their Mac than on a
selectric, however it must be scannable by a specific scanner which reads
only this font.
Does anyone know if it exists?
Thanks much,
Greg Eoyang
------------------------------
Date: Thursday 09 Jun 88 10:30 AM CT
From: Tom Pinkerton <ASTTOMPA%UIAMVS.BITNET@CUNYVM.CUNY.EDU>
Subject: JIODone call at end of drvrCtl DA routine
Anyone,
For a while now, I've been using an ending to the drvrCtl desk accessory
routine that was supplied with my MDS development package. That ending,
rather than simply returning, calls the low-level Device Manager routine
IODone (pointed to by the JIODone global variable) before returning. I've
been blindly keeping this in all my DA sources without really knowing its
purpose. I assume that who ever wrote the sample DA for the MDS development
system knew what he or she were doing when they added this call. All I can
figure is that the call somehow clears the IO Request sent to the DA from the
driver IO Queue so that other devices won't receive the request (since they
needn't bother with it, I guess). Does anyone know anything about this? Is
it safe to continue using this call, or can it have bad side effects on
anything?
Thanx,
Tom P.
------------------------------
From: "R.Crispin - Psychology" <psych@watdcsu.waterloo.edu>
Subject: Asnyc Peek
Date: 9 Jun 88 12:39:31 GMT
Reply-to: "R.Crispin - Psychology" <psych@watdcsu.waterloo.edu>
A few weeks ago I got some stuff that was supposed to contain Async Appletalk
and Async Peek. Appletalk I got, but only the documentation for Async Peek
was included. Could some one send it to me.
Thanks
Richard Crispin
Dept. of Psychology Bitnet: psych@watdcs
University of Waterloo Unix : psych@watdcsu.UWaterloo.ca
Waterloo, Ont. Canada N2L 3G1
(519)885-1211 ext 2879
------------------------------
Date: Thu, 9 Jun 88 16:31:02 est
From: Lucius Chiaraviglio <chiaravi@silver.bacs.indiana.edu>
Subject: Anyone know if Apple is planning to offer 1.6 Mb floppy
Subject: capability?
A while ago I heard a rumor that Apple was planning to offer 1.6 Mb
(quadruple density, I guess) 3+1/2 in. floppy drives for the MacIntoshes.
Does anyone know when (if ever) this is supposed to happen? Also, does anyone
have any idea of how compatible these 1.6 Mb floppy drives (if any) will be
with 800 kb disks? I would prefer that they be able to write as well as read
800 kb and 400 kb disks. . .
-- Lucius Chiaraviglio
chiaravi@silver.bacs.indiana.edu
lucius@tardis.harvard.edu (in case the first one doesn't work)
------------------------------
End of INFO-MAC Digest
**********************