info-mac@uw-beaver (05/11/85)
From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>
INFO-MAC Digest Friday, 10 May 1985 Volume 2 : Issue 44
Today's Topics:
for FTP: A new public domain ramdisk (Binhex 4.0 format)
[forwared] Re: Software Reset
[forwarded] macsend and xbin
"Put Back" vanishes from Finder
Remaking the Desk Top in the New Finder
[forwarded] DeSmet C-compiler Beta-review
Comments on Proposed MacBinary Protocol
Pasting pictures ?
----------------------------------------------------------------------
Date: Fri 10 May 85 12:21:34-CDT
From: Werner Uhrig <CMP.WERNER@UTEXAS-20.ARPA>
Subject: for FTP: A new public domain ramdisk (Binhex 4.0 format)
I found the following article on USENET's net.micro.mac
From supp@sphinx.UChicago.UUCP Mon May 6 00:16:47 1985 Subject: A new
public domain ramdisk (Binhex 4.0 format)
Here is a new public domain ramdisk I downloaded from CompuServe.
This new ramdisk has the following features:
1) Variable size Ramdisk
2) Automatically copies whatever files are in the same folder as the
application itself. In other words, if you put RamStart in a folder
and then launch RamStart all of the files within that file folder are
copied to the Ramdisk.
3) Can not accidentally eject the Ramdisk.
- --------------------------------------------------------------------------
[ now available, for a limited time, for FTP from UT-NGP, is the complete
article with the source in BinHex-4.0 format, PLUS, the files created
by program "xbin", ready for down-loading with "macput".
CONNECT / CD to subdirectory "public" and you'll find the files:
-rw-r--r-- 1 807 20 0 May 10 10:16 RamStart.data
-rw-r--r-- 1 807 20 24425 May 10 10:14 RamStart.hex
-rw-r--r-- 1 807 20 128 May 10 10:23 RamStart.info
-rw-r--r-- 1 807 20 17455 May 10 10:23 RamStart.rsrc
RamStart.hex is the posted article, the other 3 files were created by
the conversion program "xbin" when applied to it. on NGP, the command
"macput" downloads and creates a 'ready-to-tun' application on my MAC.
in the past, most people that complained about not being able to use
the stuff they obtain by FTP-transfer, did not set up the parameters
right for the transfer. Please familiarize yourself with FTP before
sending complaints - I can't help with that.
Werner ]
------------------------------
Date: Fri, 10 May 85 01:47:29 cdt
From: werner@ut-ngp.ARPA (Werner Uhrig)
Subject: Subject: [forward] Re: Software Reset
From: darin@tmq.UUCP (Darin Adler) Newsgroups: net.micro.mac Subject:
Re: Software Reset Date: Thu, 2-May-85 21:44:41 CDT Lines: 18
> I have the Manx C compiler, and am wondering how, in software, to
cause my
> Mac to do a reset...to beep and act as if I had just turned
it on. I know
> it is possible, I just can't find in in my copy of
"Inside Macintosh"
Inside Mac does NOT have the solution. In the recent versions of the
Software Supplement, there is a Restart procedure that does just what
you want. To use this method from 68000 ML this is the necessary
magic code:
MOVE.L ROMStart,A0 ; (ROMStart=$2AE)
ADD.W #10,A0 ; (decimal 10, hex $A)
JMP (A0)
Since it is OK'd by Apple, I assume this code will work on all
existing and future "Macintoshes" including the XL.
Darin Adler ihnp4!tmq!darin
------------------------------
Date: Fri, 10 May 85 01:48:25 cdt
From: werner@ut-ngp.ARPA (Werner Uhrig)
Subject: Subject: [forwarded] macsend and xbin
From: darin@tmq.UUCP (Darin Adler) Newsgroups: net.micro.mac Subject:
macsend and xbin Date: Thu, 2-May-85 22:23:00 CDT
The new macsend is GREAT, however it only works properly if the .info
and .data and .rsrc extensions are complete, i.e. the filenames are
short on the mac format files. xbin creates files that can be long,
but the are limited so that the last 2 characters form the extension
(at least .i .d and .r). Instead of modifying macsend, I have a local
copy of xbin that guarantees all 5 of the characters in the extension.
If it was desired, this could be made into an option, but for my
purposes this was unnecessary. The following are the mods to xbin.c:
231,232c231,232
< if (n > FNAMELEN - 2)
< n = FNAMELEN - 2;
---
> if (n > FNAMELEN - 5)
> n = FNAMELEN - 5;
Darin Adler ihnp4!tmq!darin
------------------------------
Subject: "Put Back" vanishes from Finder
Date: 08 May 85 22:38:02 EST (Wed)
From: Steven B. Munson <sbm@Purdue.ARPA>
The rumors about the new Finder are true; it doesn't have the Put
Back function (which puts the selected files back into the folders
they came from during the current run of the Finder). This is a big
loss, and I will miss it every time I want to select files in
different windows simultaneously, because now I will have not only to
move them to the desk top to select them, but also to manually put
them back in the windows they came from.
This problem is overshadowed, however, by the remarkable speed
that the new Finder has, not only in launching applications, but in
launching itself. It is a real relief to see how quickly it displays
disks with large numbers of files that the old Finder used to sit in
silence for many seconds digesting. Rather than put back the "Put
Back" function, Apple should add the feature that the Finder should
have had in the first place: the ability to select files in many
windows at the same time. This is such an obvious thing to want to
do; why does it take them so long to implement it?
Steve Munson
sbm@purdue.ARPA
sbm@purdue.CSNET
------------------------------
Subject: Remaking the Desk Top in the New Finder
Date: 09 May 85 08:39:43 EST (Thu)
From: Steven B. Munson <sbm@Purdue.ARPA>
Here is something I don't think anyone has noticed yet. I remade
the DeskTop file on my MacTerminal disk today with the new Finder (the
usual way -- hold down option-command while the Finder mounts the
disk), and it didn't throw away any folders! The icons moved around
in the folders a little, and the folders were renamed to Unnamed #1,
Unnamed #2, etc., but the whole process was made much more palettable,
since I didn't have to recreate them. If you think about it, this
makes sense; there is no reason the Finder can't remember the folders
before it deletes the DeskTop file and then recreate them.
I have heard that the new Finder prunes the DeskTop file when
files are removed from the disk. Is this true? If so, I won't have
to do this much more anyway, but in this case, I reclaimed 16K.
Steve Munson
sbm@purdue.ARPA
sbm@purdue.CSNET
------------------------------
Date: Fri, 10 May 85 01:51:31 cdt
From: werner@ut-ngp.ARPA (Werner Uhrig)
Subject: Subject: [forwarded] DeSmet C-compiler Beta-review
From: clif@intelca.UUCP (Clif Purkiser) Newsgroups: net.micro.mac
Subject: Complete C compiler for $150 Date: Thu, 2-May-85 13:32:45 CDT
I just finished Beta testing a new C compiler for the Mac. The
DeSmet/Ouye C development system for the Macintosh.
My two line review is that it is one of the best bargins for the
Macintosh. A complete C development system, for only $150, about half
the cost of comparable packages.
The DeSmet/Ouye C compiler, is an enhanced version of their very
successful C compiler for the IBM PC. They spent a lot of time,
making it Mac-like, although it has a definite Unix/MS-DOS flavor to
it.
The package consists of the following programs:
o C-Compiler: Full K&R implementation with floating point support.
o Version 7 based C
o 1 Pass
o Full support for the Mac toolbox
o Binder/Linker. Fast,standard options
o Assembler (Didn't use, looks fairly standard)
o Librarian (allows the creation of code Libraries)
o Shell: Unix like Shell. Features include
o Shell Scripts
o History support (I like history)
o Allows the setting of paths and default volumes
o Make facility
o Most CSH like programming capabilities
o See - a combination Mouse, and cursor based text editor,
o Based on Intel's very popular AEDIT
(Everyone at Intel really likes this editor. Enough to
port it to the VAX, IBM PC, Xenix systems, and now the
Mac)
o Two methods of Cursor control
o Use the mouse
o WordStar control characters (i.e. Command {asdfgxcwe})
o Cut and Paste with either the mouse or the cursor controls
o Menu based
o Macro's
o Fast
o Debugger: small window based debugger with disassembler,
patching, etc.
o Video Game - MacBugs shoot up Lisas, Macs, and other PCs
o RAMDISK program
o Misc. Utilites printing, etc.
o Example programs
o 400 page manual
o Surprisingly well written for a couple of engineers.
I have also used the Manx compiler for the Mac fairly extensively,
and I think this packages is as good at only 1/3 the cost.
SPEED:
I have not run benchmarks on it, but Mike Ouye says that he ran
the benchmarks from the article comparing 5 Mac Compilers and his is
quite comparable.
My experience is that the entire Compile, link process is about
20% faster than the Manx compiler, with everything, but source, in RAM
DISK
My major experience with both compilers is bring up a version of
Missile Command for the Mac (someday I will put it in the public
domain). My missile command game (SDI 2000 as I call it, (SDI is the
offical name for Reagan's StarWars ) seems be slightly faster with the
DeSmet/Ouye compiler.
HARDWARE REQUIREMENTS
The package is designed to run on a Single drive 128K Mac. I have
run it with a 512K 1 drive machine + RAMDISK without having a huge
amount of problems. (I have since broken down a gotten a second disk
drive, God what a difference.)
I think that you need either a 512K machine or an external drive,
to really use this package, a Hard disk would be ideal.
AVAILABILITY:
The latest Beta version two weeks ago I have recieved is virtually
bug free. The major problem is getting access to a Laser printer to
print out the manual, evidently Apple has been slow on delivering one
to C-Ware.
It should be available by May 15 from
C Ware Corporation
P.O Box C
Sunnyvale, CA. 94087
Price: $150.00
Disclaimer
I have no financial interest in C-Ware, or this product. However,
I am a friend of Mike Ouye. I want to see this thing sell, because
Mark DeSmet has promised to port his C source-level debugger to the
Mac, if the sales volumes justify it.
-- Clif Purkiser, Intel, Santa Clara, Ca. HIGH PERFORMANCE
MICROPROCESSORS
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!clif
{standard disclaimer about how these views are mine and may not
reflect the views of Intel, my boss , or USNET goes here. }
------------------------------
Date: Fri, 10 May 85 03:00:02 pdt
From: Harry Saal <hjs@Lindy>
Subject: Comments on Proposed MacBinary Protocol
I just received a description of the recently introduced "MacBinary"
transfer format proposal, by Dennis Brothers (dated 13 March 1985).
Apparently it has gained considerable momentum, already incorporated
in FreeTerm, Red Ryder, BinHex and an implied agreement to modify
MacTerminal by Apple. Here is my input to the technical dialogue;
better late than never!
I view Ward Christensen's original XMODEM protocol as follows: it is a
file transfer protocol, which results in the transmission of a stream
of arbitrary bytes from one point to another. The descriptions I have
read clearly indicate how files which are non-zero multiples of 128
bytes are sent; there is some discussion regarding the handling of the
"last block", ctrl-Z's and null padding. For the sake of simplifying
the discussion, I stipulate that it is capable of sending any length
of arbitrary bytes (including zero).
XMODEM describes a particular means of effecting this transfer, using
packets of 128 bytes each, starting with a packet with sequence number
1, incrementing, until an EOT message is sent. In retrospect, it is
unfortunate that XMODEM did not state ANY further description of the
internal format of the byte stream. Hence any stream is legal, and no
internal format or protocol identifier fields were defined.
Brothers' first paragraph clearly indicates that his intent is to
provide a standard stream format for Mac files, and that he considers
XMODEM, Kermit, etc. all viable lower level protocols for transmitting
such a stream reliably from point to point. In practice there are two
typical uses of this proposed protocol. One is for the point to point
transmission and reconstruction of files from Mac to Mac (e.g.
MacTerminal's intent) and the other is the purpose of sending the file
to some "foreign" storage medium, such as a file system resident on
Compuserve, Unix, a LAN, etc. Such files are then likely to be
downloaded and reconstructed on Macs, or internetted to other storage
systems (via FTPs, or E-mail), and later downloaded. Hence we will
critique the proposed format totally independent of XMODEM or
MacTerminal.
The protocol needs to be improved in these areas: the byte at offset 0
for protocol (or version number) ought to be a larger field, so that
it will serve a large class of future unforseen uses. I recommend
using a 4 byte field, as in Mac Resource files. Byte 74 ought to be
called "reserved", since presumably what is meant is the full 16 byte
Finder Info, and Apple may assign this field. Ditto the rest of the
bits of bytes 81 and 82 ought to be "reserved", not zero. It is
reasonable to pad out the header area to 128 bytes, for future
expansion, but I strongly recommend adding at least a 2 byte CRC at
the end of this field. Thus 6 bytes are used for ID+CRC, leaving 122
net data bytes. This CRC is to provide an internal consistency check
on the data, which might be corrupted by other phenomena than
transmission itself. For example, such a CRC would trap the effects of
accidental insertion of LFs after CRs erroneously while "writing" a
header record to a comms device left in "cooked" rather than "raw"
mode. Immediately following would be the data fork, followed by a
checksum. At this point, there is no purpose in padding out the data
stream to a 128 byte boundary, even assuming XMODEM is underneath; the
resource fork should follow at once, again followed by a higher level
CRC.
The data stream we have described can be encapsulated with XMODEM or
Kermit, or whatever, since both are 8 bit transparent. But there is a
strong dichotomony reflected between these two prototypical systems.
XMODEM assumes 8 bit transparency is easy to achieve. The Kermit
faction targets for the "lowest common denominator" of 7 bits based on
having to deal with lots of existing communications systems. For
example, my experience is that when trying to move files from machine
to machine, it is easy to send 7 bit data, but 8 bit data often takes
several tries to get right. Anyone who used an Apple II parallel
interface card will sympathize with the nature of the problem!
Another concern is that it is attractive to be able to download Mac
files stored in "archival" format using other preexisting tools, such
as standard emulator packages, followed by post processing, a la
BinHex, for those situations where this is the only choice. In this
case it is VERY important to restrict the character set of the encoded
data to printable characters, and preferrably 64 of them at most! My
own recommendation would be to take this into account at this level of
the protocol, packing 3 8 bit bytes into 4 6 bit characters, along the
lines of what BinHex HQX files do.
This resulting datastream could then be send as an XMODEM or Kermit
transfer. Kermit in particular works best when MOST of the datastream
does not have the high order bit on; it is optimized for this case.
XMODEM is neutral.
My final suggestion is a proposal on how to distinguish (assuming
XMODEM encapsulation) this new type of message (e.g. with a 4 byte ID
field as part of a 128 byte header) from "old" pure text datastreams.
The current suggestion basically describes a heuristic (looking at a
few bytes for zeroes), which could be tricked by a standard binary
XMODEM file.
All XMODEM implementations work as follows: when awaiting packet N, if
you receive packet N-1 (due to a previously garbled ACK), then ACK it
back, and keep on waiting. If this is true even at the beginning of a
file, then we can extend XMODEM by sending a packet #0, containing the
128 byte field we described. Former systems will just ACk and ignore
the header, but correctly store the data portion. New conforming
implementations will accept the initial header block, and interpret it
according to their environment. Presumably a Mac will actually create
the Finder file, whereas a Unix host will just save the whole stream
(unless it is a Mac External File System!). I propose that this header
mechanism NOT be Mac specific; rather one of the 4 byte combinations
be assigned (MACB?) to the format described above. The others are to
be used for similar issues for other OSs.
An implementing Mac would offer a choice of "all" or "text only" to
the sender, via radio buttons. "All" would send the full stream we
have been describing, and "text only" would send only the data fork,
without a packet #0, and would insert LFs after CRs. On reception the
selection would be made based on receipt of a leading packet #0 or #1.
------------------------------
Date: Fri, 10 May 85 14:08:19 EDT
From: stew@harvard.ARPA (Stew Rubenstein)
Subject: Pasting pictures
I have a somewhat puzzling problem. I am writing an application which
wants to paste a picture to the clipboard. It does so by doing an
OpenPicture, drawing, ClosePicture, ZeroScrap, PutScrap, and
UnloadScrap. Exiting and starting MacPaint or MS Word, and pasting
the picture, yields only the last dozen or so lines in the picture.
Interestingly enough, the PaintGrabber desk accessory gets the whole
thing! I can then "Swipe" with the PaintGrabber, and paste into
MacPaint or MS Word just fine.
Anyone have any ideas what is going wrong?
On a related topic, does anyone have the source for PaintGrabber?
There's not enough source posted to this network...
Thanx Stew
------------------------------
End of INFO-MAC Digest
**********************