• Please review our updated Terms and Rules here

I have found a way to write old Mac software to a floppy disk as long it is in a .dsk format but I can’t work out how to get a .sit format to work

Speaking of the deadman in Yosarians tent...

Should I have prefaced it with "its my opinion"?

I dont think I am alone in this camp
If its something you have fondness for thats great, my thoughts and opinions are only my own drawn from experience. You are allowed to feel different and like it. Those are just my impressions on it.
 
That problem is hardly unique to the Macintosh. I'm looking at some old IBM PC wares archives, and it is full if oddball image formats I have never heard of and different, incompatible, revisions of the formats. There were zillions of disk imaging tools out there, and each had their own idea on how to be "better".
 
As someone who has put together piles of archives, I assure you that is not as simple as it sounds. One has to use what is popular, well supported, and works, but the moment one comes across an oddball disks that standard format may not work. I've gotten in to the habit of including multiple formats where it might be beneficial.

Compression was key back in the day. People wanted to store image archives on floppy disks, which surprise, surprise, is just a tad too large unless compressed.

For Mac disks, I archive with a kryoflux and decode with software on a PC. I get a raw 400k, 800k or 1.44mb disk image - the files never have resource forks or creator types. Then I get complained at because someone somehow exacted it to a real Mac where it won't magically open in Apple Diskcopy....
 
To quote XKCD:

standards.png


I see no reason introducing new imaging standards and formats over telling others to adapt or get shunned. If you develop newer imaging software for other platforms that cannot interpret the most common of the legacy formats (or worse, you don't allow other tools to handle your own formats without touching on extremely butt-ended legal issues and yes I'm taking about KryoFlux), the new imaging standard is worthless.
 
olePigeon said:
However, it would be nice if there was a concerted effort to convert all the original software to more portable formats like raw DSK and ISO files.
Click to expand...

Now that there is Applesauce, there is an active effort to re-image original distribution floppies into .a2r flux archive format.
Thanks to that, there are now a bunch of copy-protected old apps that can now be run in emulators as well as period hardware.

Stuffit is also problematic in that Aladdin kept adding proprietary compression formats. Only Raymond's original 1.5 was ever
documented by having the source released.
 
olePigeon said:
This is a bit unfair. Disk images (and the Disk Copy application) have been apart of the Macintosh ethos since its inception in 1984, with the Disk Copy 4 format released only a few years later. DC4 and later DC6 image formats haven't changed in nearly 40 years, and a lot of the software now available on places like Macintosh Garden were actually imaged 20-40 years ago; said software had previously been floating around on usergroups, BBSes, Gopher, FTP, and early internet archives for several decades prior to being uploaded to places like Macintosh Garden.
Click to expand...
Macintosh software using Disk Copy 4.2 vs a raw sector dump is excusable. The platform has unique disk formats (400/800k GCR) that, until recently, could only be written back to disk using real hardware. Software on other platforms simply didn't accommodate those disks.

The bigger problem I've run into on sites like the Garden are the kiddies that don't know what they are doing. I have come across applications that were in ZIP archives... except classic MacOS never used the format. It would have been fine if it was an OS X style ZIP using the "._" AppleDouble format to store the resource forks, but it was archived with a somewhat older classic MacOS archiving program that required said program to properly extract and preserve the forked files.

The biggest offender of weird archives had to have been Apple themselves. The Apple IIgs system software images on their old FTP site were Macintosh self extracting archives with the Disk Copy 4.2 disk images. It was easy to create a set of disks or use the images in an emulator if you had a Macintosh, but a headache if you only had a PC to go with your Apple II. I landed up using Executor on the PC to extract the archives and grab the Disk Copy images. Had Apple used the .SDK image standard (raw 800k images in a Shrink-It compressed archive), which is the defacto standard on that platform, it would have been less headaches. Heck, even a Stuff-It archive of a Disk Copy image would have been less headache as there was PC software to extract that.

Oh and if you need a tool to unpack old archive formats like Stuff-It, there is the UnArchiver, with buildable source available: https://theunarchiver.com/command-line
 
Al Kossow said:
Now that there is Applesauce, there is an active effort to re-image original distribution floppies into .a2r flux archive format.
Thanks to that, there are now a bunch of copy-protected old apps that can now be run in emulators as well as period hardware.

Stuffit is also problematic in that Aladdin kept adding proprietary compression formats. Only Raymond's original 1.5 was ever
documented by having the source released.
Click to expand...

As I mentioned before, AppleSauce has a new format called MOOF which I really like. It's open and well documented. I believe both of TashTari's devices (HD20 and Floppy emulators) support it already, and theoretically anything that can accurately emulate an IWM/SWIM should be able to support it. So that should include the FloppyEmu and hopefully Mini vMac & Basilisk soon. It's described as a chunk-based file binary format. The neat part is (if I'm reading it right) that you have the option of storing Flux information and actually matching the data to a specific track, thereby allowing for the creation of disk images from copy protected disks. :) Not to mention small quality of life improvements, like meta information such as Publisher, Copyright, Bit Depth, Language, Hardware Requirements, etc. Basically, all the stuff you can fill out when you make a flux copy in AppleSauce.

NeXT said:
I see no reason introducing new imaging standards and formats over telling others to adapt or get shunned. If you develop newer imaging software for other platforms that cannot interpret the most common of the legacy formats (or worse, you don't allow other tools to handle your own formats without touching on extremely butt-ended legal issues and yes I'm taking about KryoFlux), the new imaging standard is worthless.
Click to expand...

The problem is that Disk Copy is limited to non-copy protected disks. Theoretically the leaked Disk Copy 5.5 beta can copy some copy protected disks, but this was unreleased software. *shrug* So having just one additional format to handle the relatively small amount of copy protected disks would be nice. The MOOF format seems like a nice middle ground. Plus, you can use the AppleSauce software to convert non-copy protected disk images to DC4 anyway. So it's not like DC4 is being abandoned.
 
I think many people are also not aware of the differences between Disk Copy 4.2 and Disk Copy 6.x. You can safely throw a DC4 image around on pretty much anything, but it's limited to just floppies. However, if staying within the vintage Mac ecosystem, Disk Copy 6 is fantastic. Tons of great features like compression, signed images, support for dialog boxes, AppleScriptable, self-mounting images, segmented images, self-writing images, etc. It was sorely underused in its day (and in regards to modern conservation efforts, probably for the better), but for its time it was awesome. It really should have been the way to distribute classic Mac software back then. Apple really developed it for that purpose, but it never really caught on.

However, if people want to maintain all those cool features, a fancy DC6 image itself[/] needs to be encapsulated inside a generic ISO. It may seem redundant putting an image (or set of images) inside yet another image format, but it's the best way to protect the integrity of the file. So it's not that we have to abandon the awesomeness that is Disk Copy 6 or the even more obscure DART and ShrinkWrap formats, but change how people distribute vintage software. That may mean being rather draconian on software archives, but people will learn.

@njroadfan I'm a bit surprised no one created a disk imaging program for the IIgs that supports DC4 format. I could have sworn there was a IIgs version of Disk Copy, but it looks like I'm wrong. Of course now we stuff like FloppyEmu.
 
Not being file system portable didn't help either. The Apple II world created the 2IMG format (from a Usenet collaboration between the authors of XGS and Bernie ][ The Rescue) because there was a need for a standard disk image format beyond 5.25" disk once Apple IIgs emulators showed up. Prior to that, there were competing non-standard formats. The image file itself is fairly simple, just a header with some metadata followed by a raw block image. If you needed to load the data into something else, just strip the header. No resource forks or any of that.

 
You must log in or register to reply here.
Back
Top