Mac OS 9 Discussion > Software

use Apple Disk Image format (.dmg .smi .img) packaging os9 files to move to osX

<< < (10/10)

adespoton:
This is a bit of a bump, but there appears to be a bit of misunderstanding in these threads as to what disk images are, unless I'm totally misreading people's statements.

Way way back, Apple created a disk image format (DiskDup+?).  It took the contents of a 400 or 800Kb disk, and wrote it out to a file on a hard disk.  This was the original Apple Disk Image format, and was in direct competition with third party formats on the Apple series computers like SHK (Shrinkit).  The format included a wrapper that indicated the way the contents were formatted -- usually ProDOS, MFS or HFS.  The contents themselves were ignored, and presented directly to the host operating system as a virtual device -- so the OS would be in charge of reading out the contents and either recognizing or not recognizing the format.

When 1.44MB disks came along, along with larger SCSI hard disks, Apple came up with a New Disk Image Format (referred to as NDIF).

NDIF was a bit smarter about how it encoded the disk data; it also included support for metadata and a disk checksum, supported arbitrary disk sizes, and had reserved space for future data use.

This reserved space came in handy, as it meant that new file system types (Joliet, High Sierra, UDF, HFS+ [all the various versions]) could be encoded with the container being able to present useful decoding information directly to the host process.  So for the vast majority of "classic" Mac OS, NDIF images reigned supreme.

However, Toast came along with its own format for CD images; it was essentially the byte copy of the CD with a header on the front that included instructions on how to burn the data to the disc and append the index structure (because unlike HFS, optical disc formats write the index data at the end of the track, so that new tracks can be added to a write-only disc and the index information will still be up to date).  NDIF can't dynamically support this index style.

Meanwhile, Shrinkwrap came along and chose another format, where the metadata was used to enable smart compression of the block data.  This allowed for very accurate (and small) images of disks, but was not portable to different partition formats, and was not easily readable by other disk image tools.

When Apple introduced DMG-style disk images, they completely changed the container format: gone was the disk header with all the extra information; instead, this was all added to a footer, to make DMG files completely compatible with write-once-and-append read-only media.  This means that starting with OS X DMGs, the actual partition data starts at byte 0, and you need to read the end of the file to find out the partition format.  This can have some curious effects, especially when the first partition starts at block 0 with a ZIP file -- because the DMG then starts with a zip header, and the first file can actually be opened and manipulated by most zip applications.

Over the years, the partition formats Apple has supported in the OS have changed; first support for MFS was dropped, then support for HFS was dropped, then Apple dropped support for NDIF altogether in Disk Utility.  It also stopped supporting some of the earlier esoteric versions of HFS+ as well.

Separate from all this, you've got the various optical media formats, some of which are supported by Apple, some of which aren't.  ".iso" is *supposed* to refer to binary data in the ISO-9660 format, which can include HFS, High Sierra, Joliet, Red Book or even UDFv1 data.  The data is written straight to file, with the track metadata being written to the end of the associated track (which can be in any of these formats).

".toast" images are essentially ISO-9660 images with a header on the front that includes instructions to Toast for how to handle the file beyond the track data included in-line.

"bin/cue" file pairs are the ISO-9660 compatible binary data paired with an external file that uses ASCII text to define the image's structure.

"img/cue/sub/ccd" file quartets are again the ISO-9660 compatible binary data paired with the external cue file, plus sub-track instructions for the burning software (to overcome some copy protection schemes) plus a "Clone CD" data file with the general instructions to tie all this together for the Windows software "Clone CD".

The big thing to notice here is that "Apple Disk Image" actually refers to three different container types, all of which support different combinations of partition layouts and formats, and are in turn supported by different combinations of Apple image tools and operating systems.  You need to get the software, the operating system (with supported partition type) and the image format to all line up to be able to actually read/write/mount any given disk image.

Toast doesn't care about the partition type really, as long as it knows how to write it to disk.  It passes actually mounting the partitions off to the host OS, which does the heavy lifting.

IIO:
you probably mostly replied to coachla; toast "can" mount most dmgs in OS9 when OS9 can mount the volume type, because you usually end up with this combination (attempting to read a dmg in OS9) when the content of the optical media was some OS9/OSX software.

it is a bit like creating custom toast images in OSX - of content HFS-only (not hybrid) - and then mounting them in OS9 using shrinkwrap. (which works fine - while disk copy 6.3 doesnt)

so, moral of the story: beeing able to mount a volume && the compatibilty between image documents and certain apps to mount them are two different things.

adespoton:
Indeed; Shrinkwrap has always been my image mounter of choice, with Toast 4 being my fallback.  But you really need to be aware of both volume and image support because they're handled by different bits of software.

IIO:
and then there is cdxtract which can read the content of image files without mounting them on the desktop - or volume editing utilities, which can modify the content of image files bitwise.

and some day some wonderful person will write me a bluray driver for MacOS9.  :)

mrhappy:

--- Quote from: adespoton on July 15, 2020, 01:25:42 PM ---This is a bit of a bump, but there appears to be a bit of misunderstanding in these threads as to what disk images are, unless I'm totally misreading people's statements.

Way way back, Apple created a disk image format (DiskDup+?).  It took the contents of a 400 or 800Kb disk, and wrote it out to a file on a hard disk.  This was the original Apple Disk Image format, and was in direct competition with third party formats on the Apple series computers like SHK (Shrinkit).  The format included a wrapper that indicated the way the contents were formatted -- usually ProDOS, MFS or HFS.  The contents themselves were ignored, and presented directly to the host operating system as a virtual device -- so the OS would be in charge of reading out the contents and either recognizing or not recognizing the format.

When 1.44MB disks came along, along with larger SCSI hard disks, Apple came up with a New Disk Image Format (referred to as NDIF).

NDIF was a bit smarter about how it encoded the disk data; it also included support for metadata and a disk checksum, supported arbitrary disk sizes, and had reserved space for future data use.

This reserved space came in handy, as it meant that new file system types (Joliet, High Sierra, UDF, HFS+ [all the various versions]) could be encoded with the container being able to present useful decoding information directly to the host process.  So for the vast majority of "classic" Mac OS, NDIF images reigned supreme.

However, Toast came along with its own format for CD images; it was essentially the byte copy of the CD with a header on the front that included instructions on how to burn the data to the disc and append the index structure (because unlike HFS, optical disc formats write the index data at the end of the track, so that new tracks can be added to a write-only disc and the index information will still be up to date).  NDIF can't dynamically support this index style.

Meanwhile, Shrinkwrap came along and chose another format, where the metadata was used to enable smart compression of the block data.  This allowed for very accurate (and small) images of disks, but was not portable to different partition formats, and was not easily readable by other disk image tools.

When Apple introduced DMG-style disk images, they completely changed the container format: gone was the disk header with all the extra information; instead, this was all added to a footer, to make DMG files completely compatible with write-once-and-append read-only media.  This means that starting with OS X DMGs, the actual partition data starts at byte 0, and you need to read the end of the file to find out the partition format.  This can have some curious effects, especially when the first partition starts at block 0 with a ZIP file -- because the DMG then starts with a zip header, and the first file can actually be opened and manipulated by most zip applications.

Over the years, the partition formats Apple has supported in the OS have changed; first support for MFS was dropped, then support for HFS was dropped, then Apple dropped support for NDIF altogether in Disk Utility.  It also stopped supporting some of the earlier esoteric versions of HFS+ as well.

Separate from all this, you've got the various optical media formats, some of which are supported by Apple, some of which aren't.  ".iso" is *supposed* to refer to binary data in the ISO-9660 format, which can include HFS, High Sierra, Joliet, Red Book or even UDFv1 data.  The data is written straight to file, with the track metadata being written to the end of the associated track (which can be in any of these formats).

".toast" images are essentially ISO-9660 images with a header on the front that includes instructions to Toast for how to handle the file beyond the track data included in-line.

"bin/cue" file pairs are the ISO-9660 compatible binary data paired with an external file that uses ASCII text to define the image's structure.

"img/cue/sub/ccd" file quartets are again the ISO-9660 compatible binary data paired with the external cue file, plus sub-track instructions for the burning software (to overcome some copy protection schemes) plus a "Clone CD" data file with the general instructions to tie all this together for the Windows software "Clone CD".

The big thing to notice here is that "Apple Disk Image" actually refers to three different container types, all of which support different combinations of partition layouts and formats, and are in turn supported by different combinations of Apple image tools and operating systems.  You need to get the software, the operating system (with supported partition type) and the image format to all line up to be able to actually read/write/mount any given disk image.

Toast doesn't care about the partition type really, as long as it knows how to write it to disk.  It passes actually mounting the partitions off to the host OS, which does the heavy lifting.

--- End quote ---

Nice history lesson! ;D

Navigation

[0] Message Index

[*] Previous page

Go to full version