Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site uw-beaver Path: utzoo!watmath!clyde!cbosgd!ucbvax!decvax!tektronix!uw-beaver!info-mac From: info-mac@uw-beaver Newsgroups: fa.info-mac Subject: INFO-MAC Digest V3 #38 Message-ID: <1541@uw-beaver> Date: Sat, 7-Sep-85 14:07:16 EDT Article-I.D.: uw-beave.1541 Posted: Sat Sep 7 14:07:16 1985 Date-Received: Tue, 10-Sep-85 03:25:52 EDT Sender: daemon@uw-beaver Organization: U of Washington Computer Science Lines: 461 From: Moderator Richard M. Alderson 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]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]UTILITY-WAYSTATION.DOC; the program is archived as [SUMEX]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]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]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]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]UTILITY-QUICKFILE.HQX. --RMA] ------------------------------ Date: Mon, 26 Aug 85 20:27:11 pdt From: Leo Hourvitz 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 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 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 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 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 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 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 **********************