Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!apple!uokmax!servalan!rmtodd From: rmtodd@servalan.uucp (Richard Todd) Newsgroups: comp.unix.aux Subject: Re: translation programs that would be useful... Message-ID: <1990Aug27.234208.14293@servalan.uucp> Date: 27 Aug 90 23:42:08 GMT References: <20450@fs1.NISC.SRI.COM> Distribution: comp Organization: Ministry of Silly Walks Lines: 65 cwilson@NISC.SRI.COM (Chan Wilson) writes: >Macintosh: >FFTs (foreign file translators) for SparcStation 1.4M and 720K 3.5" floppies, > MSDOS floppies, ProDOS floppies. Dunno about SparcStation 1.4M and 720K 3.5" floppies, but if they're MFM-format disks, they at least can be read by the low-level device drivers, so that it should be possible to write a program to read/write the disks. (I suspect that the filesystem layout is different enough that you couldn't just mount a SparcStation floppy with a filesystem on it on the Mac; however, assuming the Sparcs aren't doing something too funky with the sector numbers etc., I should think that tar or cpio-containing floppies should be directly readable. Alas, as the newest workstation at OU is a Sun 3/160, I'm in no position to test any of this :-(. As for ProDOS and MS-DOS disks, the MacOS program Apple File Exchange should read from and write to them just fine (I've done it with MS-DOS, but not with ProDOS). For some reason, though, I can't seem to format a MS-DOS floppy from within Apple File Exchange. I can do so from a shell script (just invoking diskformat with the -720 option and then "dd"ing an image of a DOS directory, etc., I had squirreled away). Anybody know why? Is this just some MacOS call they forgot to implement properly under A/UX, or is something more complicated going on here? >OS patch to allow access of HFS (Macintosh OS) disks from A/UX. Actually, you might get away with not having to patch the OS. My understanding is that it's possible to write your own NFS server in user code, which works as a normal NFS server and responds to mount, etc., requests just like a real NFS server but acts on whatever filesystem structure you want. So, it should be just a Small Matter of Programming to create a user-level NFS fileserver that can grok the format of the Mac filesystems on /dev/dsk/c?d?s30 and respond appropriately. A Small Matter of Programming to those who are very familiar with both NFS and the MacOS filesystem structure, I mean, which counts *me* completely out. >AppleSingle/AppleDouble file utilties to allow extraction of data >forks, resources, and whatnot from the UNIX side of the world. Fcnvt will convert from AppleSingle, AppleDouble, MacBinary, etc. to any of the other forms it knows. That'd give you the resource and data forks as separate files; to extract a single resource from one of those resource forks is somewhat more tricky, but should be doable with rez/derez and substantial hackery... > macdraw/paint -> pbm (i believe these exist),ps Both MacPaint->PBM and PBM->MacPaint are in the current PBMPlus release (available on the X11R4 contrib tapes or your friendly neighborhood archive site). Once you've got it into PBM format, going to PostScript is easy (with pbmtops, I believe, also part of PBMPlus). >possibilities here for the enterprising programmer, although half the >work would be finding data sheets for the formats... No kidding. I'm not sure any of the commercial word processor formats (MS Word, etc.) are documented. Looking at hex dumps of MS Word files, you can't even see anything recognizable as ASCII text. (And yes, I've often been driven to hex-dumping the doc files for various freeware Mac programs that are in Generic Expensive Word Processor Format #543252, just in order to try to get *some* information out of the things.... At least troff and TeX are human readable, and even PostScript usually can be deciphered fairly easily.) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!