--- /dev/null <[EMAIL PROTECTED]> wrote: > no worries - i'll give this a try. > i have a formatted mac floppy - so it should work if > i just unstuff in > windows and copy to the A drive?...
Nope! Not unless the .bin or .hqx file is a stuffit archive, which would be indicated with a .sit.hqx or .sit.bin extention. Most Macintosh files actually are two seperate files. They're called the data fork and the resource fork. All Mac files have a data fork even if there's nothing at all in it. They don't all have a reource fork. On a Macintosh, the System keeps track of where all the Resource and Data forks are and which ones go together. This is called the Apple Double filing system and it's always been a PITA for anyone who uses Macs along with any non-Mac computer. ;) Files without a resource fork (or ones where it's no problem if it's lost) are the only ones that can freely be transferred between a Mac and any other computer. Mostly those are images, video, office type documents like word processing, spreadsheets and text files or compressed archives like Stuffit, ZIP, RAR, ARJ, LHA, TAR.GZ etc. Everything else must be either archived or encoded with BinHex or MacBinary. There's a third format called Apple Single which combines both forks into one file that does not have to be encoded or archived to transfer intact through a non-Mac system. I've no idea why it's not commonly used or why it's not the standard format for all Mac files so people wouldn't have to hassle with all that encoding and archiving. BinHex uses 7bit ASCII* text characters. That causes some bloating of the file because lots of extra 7bit characters are needed to represent the 8bit bytes of a binary file. The reason for this was in the early days the Internet was primarily used for communicating via text, and since it was invented in the US by scientists who primarily spoke English and all english characters were contained in the first 128 places in the ASCII set it was a time and space saving expedient to make the original internet gateways only 7 bits "wide". Any 8bit wide data passing through would get the 8th bit removed. *American Standard Code for Information Interchange. Since most of the original electronic computing technology was invented in the US, the scientists and engineers opted to design it to use english characters. Using an 8bit format for text would have required memory and storage systems to be a "bit" larger or their capacity would be reduced a "bit". :) MacBinary is also a text encoding format but it uses 8bit characters from the Extended ASCII set which has 256 instead of 128 characters. That results in an encoded file very little larger than the original. If you've downloaded a .bin file and it won't decode, it probably got routed through some creaky old gateway (not Gateway! ;) computer that's still only passing 7bit data. Fortunately most of those are gone these days. So if you've downloaded a .bin or .hqx file on your non-Mac, you can't decode it unless the decoded file is some kind of archive or it doesn't matter if the resource fork gets lost. non-Mac systems simply ignore the resource fork or if they do decode or extract it you have two useless files. Unfortunately I know of no application for Mac that can be fed a seperated fork pair and rejoin them, placing the resource fork in its proper hidden place and updating the Desktop Database and the disk directory etc. If there was, the company owning it would've made a fortune selling it for $10 because almost 100% of Mac users would want it! There is one special case where a file type that requires a resource fork to work on a Mac can lose it and still be recovered. That's an _uncompressed_ Disk Copy disk image. If it's a floppy disk image then a popular Linux util that's also available for DOS and other systems can write it to a disk. It's called RAWRITE. RAWRITE will also work for images made from other removables like Syquest, Bernoulli, Magneto Optical, Zip etc. For disk images that weren't made from some type of rewritable media, the Windows CD-RW program Nero Burning ROM can write then to CD, provided the image is uncompressed, is standard HFS and will fit on a CD-R/RW disc. I haven't tred it but i think .smi or Self Mounting Images can also be recovered that way, provided they're not compressed. When I want to burn a bunch of Mac files to CD, I create a Disk Copy image on my PC from the Basilisk II Mac emulator. Then I just burn that to CD with Nero. :) I really need a desk or table big enough for 5 computers. My IIci with the Turbo 601, the Radius 81/110, the PowerMac 7300, the "Megatower 2000.5 PC"* and my poor old Pentium 75 Dell laptop. *It's been upgraded a bit from its original PIII to an Athlon and will soon get a refit to an Athlon XP. ;) ===== "Work it harder make it better do it faster makes us stronger. More than ever hour after our work is never over." Daft Punk __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com -- Vintage Macs is sponsored by <http://lowendmac.com/> and... Small Dog Electronics http://www.smalldog.com | Enter To Win A | -- Canon PowerShot Digital Cameras start at $299 | Free iBook! | Support Low End Mac <http://lowendmac.com/lists/support.html> Vintage Macs list info: <http://lowendmac.com/lists/vintagemacs.shtml> The FAQ: <http://macfaq.org/> Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive: <http://www.mail-archive.com/vintage.macs%40mail.maclaunch.com/> Using a Mac? Free email & more at Applelinks! http://www.applelinks.com
