info-mac@uw-beaver (05/09/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA> INFO-MAC Digest Thursday, 9 May 1985 Volume 2 : Issue 43 Today's Topics: UCSD native code generator Re: SUMACC under new VMS ? draft mode weirdness MacPaint on Write protected disk computer insurance Send me your NEON questions. Will Apple take over Hyperdrive? MacBinary discription and comment [from Usenet] ---------------------------------------------------------------------- From: <bang!crash!bwebster@Nosc> Date: Mon, 6 May 85 08:56:23 PDT Subject: UCSD native code generator I posted some Mac benchmarks here a while back that included an NCG time for the Mac p-System. SofTech has talked about bringing out an NCG for MacAdvantage (UCSD Pascal compiler running under the Finder), but I don't know how far advanced those plans are. Anyway, here's a extract from those benchmarks, along with some IBM PC benches for comparison. ..bruce.. Bruce Webster/BYTE Magazine bang!crash!bwebster@nosc {ihnp4 | sdcsvax!bang}!crash!bwebster Language Compilation Linking Execution Normalized -------- ----------- ------- --------- ---------- MacASM..................1.1........--.......3.1.......1.1 longword fill.........1.1........--.......2.9.......1.0 Megamax C...............3.2.......27.8......6.5.......2.2 and improver.........+6.8........--.......6.2.......2.1 register vars.........3.1.......26.8......4.4.......1.5 and improver.........+6.4........--.......4.2.......1.4 Mac p-System...........16.9.......--.......92.6......31.9 no rcheck, FillChar..18.8.......--.......59.6......20.6 native code gen......18.6......19.3.......6.5.......2.2 Turbo Pascal (3.0).......................173.8.......59.9 user interrupts turned off {$U-}.........25.9........8.9 and range checking turned off {$R-}......14.5........5.0 and using FillChar.......................11.6........4.0 ------------------------------ Subject: Re: SUMACC under new VMS ? Date: 07 May 85 00:59:03 PDT (Tue) From: Van Jacobson <van@lbl-csam> I'm running SUMACC under (a beta release of) Eunice for VMS v4. The distributed Eunice SUMACC runs with no mods & no problems. You should find that Eunice binaries linked with the sharable C library (all the SUMACC binaries were linked with the sharable library) run unchanged under v4 Eunice. - Van Jacobson, LBL ------------------------------ Date: Mon, 22 Apr 85 16:31:38 PDT From: Steve Loving <GA.SJL@Forsythe> Subject: draft mode weirdness A mac user brought in a 16k MacWrite file with headers and footers. When he tried to print out the file in standard mode it worked fine. When he tried to print in draft mode, after the Imagewriter did a reverse form feed to number the page, he gets a dialog box saying the printer is not responding. Now, no matter what he clicks , ok or cancel, the file just keeps on going (although he must select one of those two choices). Removing the headers solves this weirdness. Anyone else run into this? Why does one get that particular dialog box and why no distinction between cancel and ok? thanks for your answers steve l To: INFO-MAC@SUMEX ------------------------------ Date: Tue, 7 May 85 22:27:10 EDT From: Joel Malman <malman@BBNH.ARPA> Subject: MacPaint on Write protected disk Has anyone noticed that you can NOT run MacPaint (version 1.4) on a write protected (protect tab 'up') disk? For example: if you have MacPaint in the internal drive (write protected) and a scratch disk in the external drive (un-protected) you STILL get the error message: MacPaint can't find work space on default drive Why doesn't MacPaint try for scratch space on the external drive? In my case, I have many files on the internal disk (with MacPaint) that I want to protect against loss. On my external drive I have my working paint files. joel ------------------------------ Date: Mon, 6 May 85 02:17:34 EDT From: Dan_Bower%RPI-MTS.Mailnet@MIT-MULTICS.ARPA Subject: computer insurance The Kemper Group offers a general computer equiptment policy with the following features: Policy covers hardware, software and data. Software is replaced if media is destroyed with all available backups. Data replacement means that if your database or text or whatever is lost, they will pay you at your hourly worth to reconstruct it. Example: The office burns, destroying everything. You were working for someone else at a contracted rate of X dollars/hour. They pay you X dollars/hour to reconstruct. Naturally, claims are more easily processed if you can document your hourly rate and your last backup. Rates vary according to value of hardware, the existance of agreements to borrow equiptment, deductables, and a whole bunch of other stuff. I'm paying $250/year to insure $10,000 of hardware and software at $250 deductable. I've never had a claim, so I can't say how well they process claims. It is a reasonably well known firm, though. The policy is modeled after a fire insurance policy. Also, you must provide and maintain an inventory of all insured items. Items are covered while at the location insured as well as in transit and at temporary locations. For any other details, contact an insurance salesman. (I have no affiliation with this insurance other than as a customer.) Dan Bower, TIME Support Center, Rensselaer Polytechnic Institute "Dim stars shine bright in dark skies." ------------------------------ Date: Tue 7 May 85 14:02:40-MDT From: Tony Jacobs <T-JACOBS@UTAH-20.ARPA> Subject: Send me your NEON questions. I just got my copy of NEON. They mentioned when I talked to them on the phone that they didn't have any distributors or dealers, that they were only selling direct! The manual looks real nice. Type set or LazerWriter set most likely. The main sections are: A Neon Tutorial (about 100 pages, looks good for any level of programmer) Using Neon (about 65 pages, 6 chapters) Predefined Classes (Data Structures,Strings,Files,Events,Windows,Menus,Controls Graphics,Dialogs,Drivers) The Neon Glossary (they say around 1000 words) Appendices (Error messages, Equates, & System Error codes) Just from the browsing I've done in the manuel so far it looks like they've taken the best of Forth, Smalltalk, and the Mac and made a nice product. They've included lots of examples and source. I have only played with one example program and that was for a very short time, so I can't say much about the performance. I plan on doing some bench testing on it. If you have a favorite bench, send me the source and I'll see what I can do to implement it in NEON. It looks to have very close ties with the toolbox calls and the guts of the mac so it should prove powerful. Any way, send me your questions and I'll summarize in a later article. Tony Jacobs t-jacobs@UTAH-20 ------------------------------ Date: Mon 6 May 85 22:45:10-EDT From: Randy Forgaard <RANDY@MIT-XX.ARPA> Subject: Will Apple take over Hyperdrive? From the Tidbytes section of Michael McCarthy's News Desk column in the current (May 13) issue of InfoWorld: "Apple and General Computer of Cambridge, Massachusetts, are reportedly involved in hot and heavy negotiations regarding the fate of the latter's Hyperdrive internal hard disk drive for the Macintosh. Betting is that Apple will take over the product." -- Randy Forgaard ------------------------------ Date: 1 May 1985 1123-PDT (Wednesday) From: Elgin Lee <ehl@Navajo> To: info-mac@sumex Subject: MacBinary discription and comment [from Usenet] Here's a couple of messages (one mine) from net.micro.mac regarding the new MacBinary BinHex format. -------------------- From: jimb@amdcad.UUCP (Jim Budler) Subject: New MacBinary Protocol from Compuserve Date: 29 Apr 85 18:42:23 GMT Lines: 217 The folks at Compuserve have been at it again. Here is a copy of the proposed standard for transferring files between machines. It differs from previous binhexes in that it is eight bits wide, and contains all the Macintosh information about the files including Get Info. Because of this I am initially just posting the standard. I have BinHex version 5 which supports it, but that means there is no compatible xbin, and in addition if a compatible xbin is developed the additional information is lost. A better way of using it is with a terminal program such as FreeTerm which decodes the information during the download, as the transfer time then seems to relate more to the decoded size than the encoded size. It is rumored that part of the reason for the delay in MacTerminal 2.0 is because this format will be included. ----------------------< submitted for your approval >------------------ Macintosh Binary Transfer Format Proposal ----------------------------------------- Dennis F. Brothers - 13 March 1985 (Revision 1 - 10 April 1985 - Miscellaneous clarifications) (Revision 2 - 12 April 1985 - Corrected reversal of icon position v,h) The following notes are a proposal for a standard format for binary transfer of arbitrary Macintosh documents via a telecommunication link. It is intended for use both between Macintoshes running (possibly different) terminal programs which adhere to the standard, and for use in uploading arbitrary Macintosh documents to remote systems (where it is presumed that they will be stored as an exact image of the data transmitted). A proposal is also made for standard processing to be performed on text files transferred via a protocol, to maximize the likelihood that text files transmitted to a remote system will be usable by that system, and that text files received from a remote system will be usable by the Macintosh. The binary format described is independent of the communication protocol used to accomplish the transfer, and assumes only that an 8-bit transparent transfer can be accomplished. Such protocols as Christensen (usually referred to as XMODEM or MODEM7), Kermit, and CompuServe A or B meet this requirement. Because of the proposed standard's MacTerminal/XMODEM heritage, there is a requirement that the transmitted data be padded (with nulls) to a 128-byte boundary at certain points, but this in no way implies that a block-oriented protocol must be used. The basic format proposed is identical to that used by MacTerminal, by Mike Boich and Martin Haeberli, and can be used with a version of MacTerminal that has had a patch applied to "normalize" its implementation of the XMODEM protocol. In brief, the binary format consists of a 128-byte header containing all the information necessary to reproduce the document's directory entry on the receiving Macintosh; followed by the document's Data Fork (if it has one), padded with nulls to a multiple of 128 bytes (if necessary); followed by the document's Resource Fork (again, padded if necessary). The lengths of these forks (either or both of which may be zero) are contained in the header. The format of the 128-byte header is as follows (offsets and lengths are given in decimal): Offset Length Contents ------ ------ -------- 000 1 Zero. This is a "version" byte. 001 1 Length of filename. 002 63 Filename (only "length" bytes are significant). (the following 16 bytes are a standard Finder Info record) 065 4 File type. 069 4 File creator. 073 1 Finder flags: Bit 7 - Locked. Bit 6 - Invisible. Bit 5 - Bundle. Bit 4 - System. Bit 3 - Bozo. Bit 2 - Busy. Bit 1 - Changed. Bit 0 - Inited. 074 1 Zero. 075 2 File's vertical position within its window. 077 2 File's horizontal position within its window. 079 2 File's window or folder ID. (End of Finder Info) 081 1 "Protected" flag (in low order bit). 082 1 Zero. 083 4 Data Fork length (bytes, zero if no Data Fork). 087 4 Resource Fork lenth (bytes, zero if no R.F.). 091 4 File's creation date. 095 4 File's "last modified" date. 099 29 Zero fill (reserved for expansion of standard). Note that it is the responsibility of the receiving terminal program to resolve file name conflicts, generally by somehow modifying the name of received file if there already exists a file with the original name on the target volume. Note also that, while the original window or folder ID and position may be transmitted, the receiving terminal program would not normally set these items for the received file, but would instead accept the values that the File Manager assigns when it creates the new file. It is suggested that Macintosh terminal programs implement two modes of protocol transfer: text and document. Text mode is used for unformatted files of type TEXT (with only a data fork), and document mode (using the binary format proposed here) is used for all other files. Document mode may also be used on text files, of course, if it is desired to preserve such things as the file's creator ID or creation date. The intent of text mode is to provide compatibility with text files on other systems. Toward that end, it is recommended that a linefeed be inserted after each return character as the text file is transmitted, and that, in the case of block-oriented protocols, the last block be explicitely padded with nulls if the text does not end on a block boundary. In the specific case of XMODEM protocol, a CTRL-Z (hex 1A) character should be inserted following the text and before the padding, as this will provide compatibility with the broadest range of systems implementing the XMODEM protocol. When receiving in text mode, linefeeds and trailing nulls (and the trailing CTRL-Z, if any) should be stripped. Note that the above discussion applies only to text files transferred under some protocol, where an exact image of the transmitted data will be stored in a file on the remote system. When receiving a file via a protocol, a terminal program may distinguish between text and document modes by examining bytes 0, 74, and 82 of the first 128 bytes received. If they are each zero (and at least 128 bytes have been received), then it is a safe assumption that a document is being received. Terminal programs implementing possible future versions of the proposed standard would, of course, accept an appropriate set of version numbers in byte 0. Since a text-mode document does not contain a file name, it is suggested that when text-mode is detected, a file be opened under a dummy name on the receiving Macintosh, the text written to that file, and the file renamed to a name selected by the user (via an SFPutFile box) after the reception is completed. This will avoid problems caused by indeterminate delays for name selection at the beginning of the file transfer. It is desirable to allow the user to specify the destination volume in advance of the actual start of transfer for either type of transfer. Two methods are suggested for this: provide a "Select Destination Volume" menu selection, presumably in the menu containing the "Receive File" selection; or query the user immediately after the "Receive File" menu selection is made. Either or both of these methods could be implemented in a given terminal program - the independent "Select Receive Volume" method is particularly desirable if the ESC-a/ESC-b automatic receive facility (see below) is implemented. The volume selection procedure should provide the same functions as the volume selection portion of the SFGetFile and SFPutFile dialog boxes. First proposed extension to the proposed standard: -------------------------------------------------- It is proposed that the binary format described above be extended to allow the transmission of descriptive text with a Macintosh document (specifically, the descriptive text from the Finder's "Get Info" box for the file being transferred). This is to be accomplished in a transparent manner by assigning bytes 99 and 100 of the header described above to be used to hold the length of the descriptive text (or zero, if there is none). The descriptive text, if any, will begin on the 128-boundary immediately following the Resource Fork, if present, else the Data Fork, if present, else immediately following the header if neither fork is present. It is hoped that methods for reading and setting a file's "Get Info" text will be made public at some point. Notes on MacTerminal's XMODEM implementation, and a proposed extension: ----------------------------------------------------------------------- Familiarity with the Christensen (XMODEM) protocol is assumed in the following discussion. When doing "Mac-to-Mac" transfers, using the binary format described above, unmodified MacTerminal does not use a true XMODEM protocol, and is therefore incompatible with most non-Mac systems. The differences lie in two specifics: the transmitting Macintosh initiates the transfer by sending the the two characters ESCAPE (hex 1B) and "a" (hex 61); the receiving Macintosh is expected to reply with the character ACK (hex 06). The transfer then proceeds using normal XMODEM procedures, except that each of the header and the two forks (if present) is treated as a separate XMODEM transfer, with the transmitting Macintosh waiting for a NAK (hex 15), then sending the blocks of that phase (beginning with a block number of one), then sending EOT (hex 04) and waiting for an ACK (hex 06) from the receiving Macintosh. It is proposed that a modified procedure be accepted as a standard, to be implemented instead of or in addition to the above-described MacTerminal "Mac-to-Mac" protocol in complying terminal programs. The modified procedure, which is compatible with standard XMODEM implementations, functions as follows: The transmitting Macintosh sends the two characters ESCAPE (hex 1B) and "b" (hex 62). The receiving Macintosh may optionally reply with ACK (hex 06) (this is allowed so as to have minimum impact on existing MacTerminal-compatible implementations). The transmitting Macintosh then awaits receipt of a NAK (hex 15) (or optionally a "C" (hex 43), if the receiving terminal program supports CRC checking), following which a single, normal XMODEM transfer occurs. The transfer may be in text mode or document mode, will begin with block number one, and block numbers will increment uniformly (modulo 256) throughout the transfer. It is expected that a patch to MacTerminal making it compatible with the above proposed procedure will be available in the near future. Responses to proposals: ----------------------- Please address comments on the above proposals to: Dennis F. Brothers 197 Old Connecticut Path Wayland, MA 01778 CompuServe: 70065,172 Delphi: DBROTHERS MCI Mail: DBROTHERS Path Wayland, MA 01778 -- Jim Budler Advanced Micro Devices, Inc. (408) 749-5806 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amdcad!jimb Compuserve: 72415,1200 -------------------- From: ehl@Navajo.ARPA (Elgin Lee) Subject: Re: New MacBinary Protocol from Compuserve Date: 1 May 85 18:17:21 GMT Organization: Stanford University Lines: 27 Some initial thoughts about the MacBinary protocol: Seems to me that the folks at CompuServe have come up with something that makes a lot of sense for CompuServe but not for Usenet or ARPA. It makes sense in for CompuServe to have a file format that will enable file transfers to be essentially transparent -- instead of having to binhex and upload or download and binhex, with a compatible terminal emulator people can simply transfer via XMODEM (MacBinary) and automatically transfer a single file (not three like MacTerminal) that contains all the required Macintosh information within it and is faster to transfer to boot (8-bit vs. ASCII hex encoding). The scheme does not make much sense for Usenet or ARPA -- ever try to get 8-bit binaries through your local mailer? Sure, you can uuencode/uudecode things, but that implies having a UNIX system around, which in particular is not valid for the ARPA INFO-MAC setup. BinHex version 5 is definitely not helpful -- it will convert the previous BinHex formats, but will only produce the new MacBinary .BIN files. My feeling: stick with BinHex version 4 and the .HQX format. -- Elgin Lee UUCP: ..decvax!decwrl!glacier!navajo!ehl ARPA: ehl@su-navajo.ARPA, ehl@su-score.ARPA End of INFO-MAC Digest **********************