info-mac@uw-beaver (09/07/85)
From: Moderator Richard M. Alderson <INFO-MAC-REQUEST@SUMEX-AIM.arpa>
INFO-MAC Digest Saturday, 7 Sep 1985 Volume 3 : Issue 38
Today's Topics:
New SetFile desk accessory
WayStation - another mini-finder
IEdit 1.1
finder application parameters library
Teleport DA
Bill Atkinson's QuickFile (Rolodex)
LaserWriter, BitMaps...
... and Command Keys
Megamax, Mactalk and 3D
MDS .Rel Files, a query
Macsbug vs. Multi-Meg-Macs
Request for terminal program sources
Programming Question
Bug in SFGetFile?
mac and ham radio, a query
Wide carriage imagewriter printer, a query
----------------------------------------------------------------------
Sender: Platt@HIS-PHOENIX-MULTICS.ARPA
Date: Tue, 27 Aug 85 17:46 MST
From: Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA
Subject: New SetFile desk accessory
This posting contains an improved (6200+ byte) version of the Set File 2.0 desk
accessory (why oh why didn't the authors change the version number??) Unlike
the 3k version posted to INFO-Mac some months ago (and discussed at some
length), this version doesn't appear to need to run as resource#19; it can be
installed with the font/DA-mover with no difficulty. Its dialog window has
also changed. Shareware (contribution requested if you like it).
[Archived as [SUMEX]<INFO-MAC>UTILITY-SETFILE.HQX. --RMA]
------------------------------
Sender: Platt@HIS-PHOENIX-MULTICS.ARPA
Date: Wed, 28 Aug 85 13:18 MST
From: Dave-Platt%LADC@CISL-SERVICE-MULTICS.ARPA
Subject: WayStation - another mini-finder
This posting contains "WayStation", a public-domain minifinder.
WayStation permits you to quickly launch any of up to 24 different applica-
tions; the applications don't all have to be on the same disk (WayStation
apparently records the name/disk information in its own data fork). In this
version, you can only launch applications; launching of documents is promised
for a future release. WayStation has an automatic one-minute screen-saver
feature; click the mouse or strike any key to refresh the screen (this feature
apparently isn't aware of desk accessories such as MockWrite, and tends to
blank the screen suddenly if you're using such accessories from within
WayStation).
It's possible to make WayStation your default Finder (useful especially if you
don't have a ramdisk).
[In the interest of brevity, I have abridged this message. Complete instruc-
tions are in the file [SUMEX]<INFO-MAC>UTILITY-WAYSTATION.DOC; the program is
archived as [SUMEX]<INFO-MAC>UTILITY-WAYSTATION.HQX. --RMA]
------------------------------
Date: Fri, 30 Aug 85 14:29:48 EDT
From: Kent_Flowers%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: IEdit 1.1
I noticed earlier that IEdit 1.0 had been uploaded to the net. I have had a
version 1.1 that fixes some of the bugs in 1.0 for several months, but have
avoided uploading it to the net because I didn't think it was of suitable
quality for the net until version 2.0 was finished. However, since someone
thought version 1.0 worthy of passing along, I figured I should at least supply
the latest version I had. For those that have run into the bugs of 1.0 (saving
two icons to the same file that have the same ID for example!) I extend my
apologies for the hack. 1.1 is still a seat-of-the-pants hack, but hopefully
it is a more functional one.
For those who have sent me questions reguarding how to use the beastie, here
are some quick notes:
I have added a quick note at the end of the "Help" menu (which at this time
neither the "Help" or the "Resources & Misc" menus have function other than
their content telling about future additions) to tell folks about the hidden
features that are in the program:
...
Kent Flowers
[The program itself is archived as [SUMEX]<INFO-MAC>UTILITY-IEDIT.HQX. The
full contents of this letter are archived as UTILITY-IEDIT.DOC, since it was
more than 10000 characters long. --RMA]
------------------------------
Date: Sat, 31 Aug 85 13:10:20 PDT
From: shebanow%ucbernie@Berkeley (Mike Shebanow)
Subject: finder application parameters library
Here is the source for a library of routines which emulate the WorkShop
routines for accessing the Finder information. The Finder passes filenames and
other information to the application, in a manner similar to UNIX's argc/argv
convention. The code interfaces to MDS and Consulair's MacC.
The MacC conventions are:
/* type and constant info */
#define appOpen 0
#define appPrint 1
typedef struct {
short vRefNum; /* volume ref num for file */
OSType fType; /* the file's type */
short versNum; /* always 0?? */
Str255 fName; /* the filename */
} AppFile;
/* routines */
void CountAppFiles(message,count)
short *message; /* open files or print them */
short *count; /* number of files to handle */
void GetAppFiles(index,theFile)
short index;
AppFile *theFile;
void ClrAppFiles(index)
short index;
Have fun...
Andrew Shebanow
shebanow@ucbernie.ARPA
[These routines are stored as [SUMEX]<INFO-MAC>UTILITY-FINDER-ACCESS.ASM. The
conventions are repeated in UTILITY-FINDER-ACCESS.DOC. --RMA]
------------------------------
Date: Mon, 2 Sep 85 14:23:01 pdt
From: barry@playfair (Barrett P. Eynon)
Subject: Teleport DA
Here's a DA from Compuserve which teleports between applications after simula-
ting a Quit action. It is a Font/DA Mover document, packed with MacWrite 4.5
format documentation by PackIt, then encoded in HQX format with Binhex v4.0.
-Barry Eynon
[Archived as [SUMEX]<INFO-MAC>DA-TELEPORT.HQX. --RMA]
------------------------------
Date: Mon, 2 Sep 85 14:25:22 pdt
From: barry@playfair (Barrett P. Eynon)
Subject: Bill Atkinson's QuickFile (Rolodex)
Here is a new version of Bill Atkinson's freeware Rolodex program, now named
QuickFile. In HQX format.
-Barry Eynon
[This can be found in [SUMEX]<INFO-MAC>UTILITY-QUICKFILE.HQX. --RMA]
------------------------------
Date: Mon, 26 Aug 85 20:27:11 pdt
From: Leo Hourvitz <leo%apple.csnet@csnet-relay.arpa>
Subject: LaserWriter, BitMaps...
A bug was reported about how a large bitmap image is handled by Draw and the
LaserWriter. Here's the scoop: Two pieces of obscure information cause that
problem. One is that Draw can only handle bitmaps of a certain size; if it
gets (through paste) a bitmap larger than that, it splits the bitmap up into
several smaller bitmaps. The second piece of obscurity is that since a Mac
screen is 72 dots/inch and the LaserWriter is 300, the person implementing the
LaserWriter code decided that 288 (=72x4) was pretty close to 300, and when
bitmaps are printed on the LW, they are simply blown up by four in each
direction. So, those bands that show up in bitmaps under Draw come from two
things: one, draw split up your bitmap into a bunch of little ones, and two,
those little bitmaps (here's the death ray) EACH got independently shrunk by a
little bit when they were printed on the Laser.
The only workaround I've found is, immediately after pasting the bitmap into
Draw, select the whole thing by dragging out a rectangle, and group it
together. This solved my problem (which was horzontal bands), but still left
me with some inexplicable things. I found if I so much as clicked somewhere
before grouping them, the bands came out on the printer. WYSIWYG this is not.
Keep on Macking!
Leovitch
Leo Hourvitz
Apple Computer, Inc.
leo@apple.csnet
$ wittysaying -o
------------------------------
Date: Mon, 26 Aug 85 20:27:11 pdt
From: Leo Hourvitz <leo%apple.csnet@csnet-relay.arpa>
Subject: ... and Command Keys
Regarding a different planet...
Sadly, command keys CANNOT be entirely driven from the menus. The keys laid
out in the User Interface Guidelines as required (Undo(Z), Cut(X), Copy(C), and
Paste(V)) are hard-coded into the ROM. On a shadier side, MacPaint (and
Microsoft Word) boast command keys that cannot be menu-driven because they are
not direct equivalents of any menu command; e.g., MacPaint's command-shift-> to
get the next larger font; there is no 'Increment Font Size' command. Is
consistency with the menus worth not having the ability to change font sizes?
A long debate.
Keep on Macking!
Leovitch
Leo Hourvitz
Apple Computer, Inc.
leo@apple.csnet
$ wittysaying -o
------------------------------
From: pur-ee!kangaro!milo@Berkeley
Subject: Megamax, Mactalk and 3D
Date: Mon Aug 26 11:31:22 1985
I am sure most of you are familiar with the Mactalk and the 3D graphics package
that came with the latest release of the MacStuff Consortium disks. They
conviently provided us with MDS libraries so you could link the routines into
your own programs.
BUT! What if you don't have an MDS linker? I want to use these routines with
MEGAMAX C compiler but I can't seem to find enough information to let me write
a MegaMax/mactalk interface routine.
Has anyone else figured out how to use MacTalk or the 3D graphics routines from
MegaMax C yet?
If you have a set of interface routines please let me know...you will have to
send mail directly to me as I don't get INFO-MAC here. Thanks
Greg Corson
UUCP: {ihnp4 | ucbvax | harpo}!pur-ee!kangaro!milo
ARPA: pur-ee!kangaro!milo@BERKELEY (gatewaying through ucbvax)
Or leave a message to the sysop on The Connection BBS: (219) 277-5825
------------------------------
Date: Tue, 3 Sep 85 16:34:35 edt
From: ANDERER <anderer%udel-cc-vax1.delaware@udel-louie.ARPA>
Subject: MDS .Rel Files, a query
I'd like to be able to use some of the object files Apple supplies (like the
fixed-math stuff, Graf3D, etc.) I'm working in Megamax C.
Has anyone hacked up a routine to decompile the MDS .Rel files? And maybe even
put them into a format the Megamax linker can live with?
If not, is the format of the .Rel files documented anywhere?
------------------------------
Date: Wed, 4 Sep 85 15:27:35 edt
From: Ephraim Vishniac <vishniac%wang-inst.csnet@csnet-relay.arpa>
Subject: Macsbug vs. Multi-Meg-Macs
Long-time readers of this group have heard (read) me complaining about problems
involving Macsbug (and Maxbug, and all their kith and kin) and my overweight
Mac (1.5 meg). Thanks to MacNosy, I now understand the problem.
First, the plug. MacNosy is a disassembler for the Mac. I bought it from the
Programmer's Shop, in Hanover, MA, for $60 plus 5% tax plus $3 P&H. I imagine
it's a competent disassembler, but it's definitely oriented toward expert
users, and has a long learning curve. I have no connection with anyone who
would profit from sales of MacNosy; I'm just an accidentally delighted
customer.
Next, the problem. My usual working configuration is a 512K system area (low
mem stuff, system heap, application heap) followed by a large ramdisk, followed
by the video ram, and misc high mem stuff. With Macsbug (or Maxbug) installed,
the system would crash when the ramdisk was about half-full. Without macsbug,
everything was fine, except that I couldn't debug.
MacNosy comes with several sample "journal" files of disassemblies. One of
these is Maxbug, by a happy coincidence. A quick look at the output showed
that Maxbug makes some assumptions about the structure of memory:
1. It assumes that top-of-memory-relative things can always be got at with
fixed high addresses and wrap-around. For example, the screen is at 1A700 in a
thin Mac, 7A700 in a fat one, and higher still in others. If wraparound is
reliable *and* only power-of-two memory sizes are used, you can always hit it
by using 1FA700 (the screen location in a four-meg Mac). Fortunately, Macsbug
doesn't find the screen this way, but it does find its internal data this way.
2. It assumes a maximum of one meg. Period.
Results: Macsbug will not work in any mac with more than 1 meg of memory. It
will also not work in 1 meg systems where the upper half-meg is not recognized
by the system. More precisely, it will start to work on these systems, but
won't put its variables in the space reserved for them, leading to conflicts
with other programs.
The fix: Patch Macsbug for your real memory size. This involves >100 patches,
so a program to automatically find and apply the changes is definitely
indicated.
Ephraim Vishniac
[apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac
vishniac%Wang-Inst@Csnet-Relay
------------------------------
Date: Tue 3 Sep 85 08:33:40-PDT
From: Dwight Hare <DHARE@SRI-CSLA.ARPA>
Subject: Request for terminal program sources
I am writing my first substantial application for the mac, and it is yet
another terminal program. Of course, this version will have all of the
fancy features that I have always wanted in a terminal. Rather than reinvent
the wheel completely, I'd like to start from an existing terminal program.
I'm requesting the sources to a terminal program, hopefully written in Megamax
C, but I'd appreciate one written in any other C, or even written in Pascal.
I intend to post my resulting program (if I get it working) on info-mac, and
any help will be acknowledged.
------------------------------
From: berman@isi-vaxa (Richard Berman)
Date: 5 Sep 1985 1035-PDT (Thursday)
Subject: Programming Question
Do you know of any special setup or avoidance that should be observed by a
program if it is the startup applicaion on the system disk? In particular, I
find that when I call SFGetFile or SFPutFile (by directly calling the
particular routine in PACK3) I get an error 2.
I've checked, and there are no odd addresses being passed. All the routine
addresses are NIL, and the string addresses are ok. It does get to the Pack3
call and then spins the disk for a bit over a second. Then the bomb.
The identical code works if the program is opened from the Finder.
My first thought was...AHA! Obviously InitAllPacks (or InitPack(3)) isn't
being called if it is a startup application. But calling it had no effect. So
I'm hoping to find some other kind of operation that should be done.
The language I'm using is MicroMotion MasterFORTH, which provides a very low
level assembler-like interface to system traps.
Please send me any info you have on this kind of thing.
Best,
Richard Berman
Berman@ISI-VAXA
------------------------------
Date: 6 Sep 85 13:21:01 EDT
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: Bug in SFGetFile?
System: 512K Mac with external drive. Megamax C 2.1a.
Background:
I wrote an application (FontDisplay for those who are curious) that uses
SFGetFile to get a font file from the user. SFGetFile is passed a file filter
function that returns FALSE for files whose type is FFIL or System files. It
works fine.
In order to let the user select all the files on the disk, I added a button
("Disk") to the dialog list (which by the way had to be done with MDS Asm and
Linker since RMAKER doesn't like userItem's.) To process this button, I have a
dlgHook function that sets a global variable and returns getOpen when this
button is pushed. It too works fine.
Since I needed the list of font files when the user selected "Disk", I modified
my file filter to keep a list of all the files it "passed" (clever, eh?). I
also have my dlgHook clear this list whenever it receives an getEject, getDrive
or disk-insert item.
Bug:
The first time I call SFGetFile, it works fine. The list is cleared and reset
accordingly when I eject the disk, switch drives and insert a new disk. The
second time I call SFGetFile, the list is always empty.
After adding some debugging code to my dlgHook, I noticed the following:
1) The FIRST time it is called from SFGetFile, it is passed -1 (which isn't
documented anywhere.)
2) The second call to SFGetFile causes it to get called with repeated disk
insert events (100) when no disk insert has taken place!! This happens in an
endless loop.
Workaround:
I modified my dlgHook to check for a "real" disk insert event (using
EventAvail) and only clear my list then.
Has anyone else ever experienced this bug?
APPLE: do you know about it?
- Jeff "Is it live or is it Megamax?" Shulman
uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!shulman
arpa: SHULMAN@RUTGERS
------------------------------
Date: 2 Sep 85 02:11 EDT
From: Crawford @ DCA-EMS
Subject: mac and ham radio, a query
wanted
information/past experience with interfacing a mac with ham radio. i am
particularly interested right now in morse code transmission and reception. it
would be useful even if you know of a good algorithm for receivning morse code
at any speed from manual transmission. might be interested in the future in
amtor and packet.
thanks for any help you may be able to provide.
73
jerry k7upj
------------------------------
Date: Fri 6 Sep 85 14:20:04-PDT
From: Jeffrey Harvey <JHARVEY@SU-SCORE.ARPA>
Subject: Wide carriage imagewriter printer, a query
I'm going to be buying a Mac soon, and I'd like to get some opinions on the
wide carriage imagewriter printer. What are people's experience with them?
Are they worth the extra money? How is their reliability? Are they much
slower than the standard imagewriter? In general, what should I know before
making my decision.
For reference, I'll be getting a Fat Mac, drive, and printer "bundled". If I
get the bigger printer it will cost me about $200 extra.
Thanks in advance for your advice.
Jeff Harvey
------------------------------
End of INFO-MAC Digest
**********************