Pages: 1 2 [3]   Go Down

Author Topic: use Apple Disk Image format (.dmg .smi .img) packaging os9 files to move to osX  (Read 64863 times)

DieHard

  • Global Moderator
  • Platinum Member
  • *****
  • Offline Offline
  • Posts: 2394

Quote
the entire point of this post was to urge the use of .img apple disk image files (NDIF)
BECAUSE they are compatible on all versions of OSX + almost all flavours of classic Mac OS (7.x, 8.x, 9.x)

That is an excellent point...
but not the only take-away from this discussion... we also wanted to explain the need for Macbinary encoding when transferring non-compressed files to the internet and back and using 'stuff-it" for archiving and then adding MacBinary encoding to the archive to prevent issues from transferring Archives to internet storage.

Lastly, an added tidbit, was to use Toast 4.1 and copy hidden blocks from CDs that may have copy protection schemes... this obviously won't work on some older Native Instruments that have physical copy protection (looks like a small BB/bullet struck the CD), but works on mant Steinberg and other CDs 
Logged

quadratour

  • Newcomer
  • *
  • Offline Offline
  • Posts: 2
  • New Member
Re: IMG format seems no longer supported
« Reply #41 on: October 16, 2019, 06:08:21 AM »

Just a note: macOS Mojave doesn't any longer open the IMG files posted here (tested: Logic Audio Anthology, Dongle Emulator). Apparently Apple has dropped support for legacy IMG formats. I could still open them with macOS 10.10 though.
Logged

IIO

  • Global Moderator
  • Platinum Member
  • *****
  • Offline Offline
  • Posts: 4557
  • just a number

thanks for the heads up. what happens with toast?
Logged
insert arbitrary signature here

quadratour

  • Newcomer
  • *
  • Offline Offline
  • Posts: 2
  • New Member

I haven't used Toast directly, but the Toast image file mounted fine on Mojave with a double-click.

From the Logic Anthology, all but the two most recent Logic Dongle emulator IMG also didn't open on 10.10 Yosemite. I didn't find the time to setup an earlier OS X (e.g. 10.6.8) with VMWare Fusion, as the latest emulator did it for me (needed to convert old Logic files).
Logged

IIO

  • Global Moderator
  • Platinum Member
  • *****
  • Offline Offline
  • Posts: 4557
  • just a number

i meant the other way round. :) do those .img files (which didnt mount with image mounter) mount when using toast in mojave?
Logged
insert arbitrary signature here

adespoton

  • Valued Member
  • **
  • Offline Offline
  • Posts: 39
  • Crusty Member

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.
Logged

IIO

  • Global Moderator
  • Platinum Member
  • *****
  • Offline Offline
  • Posts: 4557
  • just a number

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.
Logged
insert arbitrary signature here

adespoton

  • Valued Member
  • **
  • Offline Offline
  • Posts: 39
  • Crusty Member

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.
Logged

IIO

  • Global Moderator
  • Platinum Member
  • *****
  • Offline Offline
  • Posts: 4557
  • just a number

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.  :)
Logged
insert arbitrary signature here

mrhappy

  • Platinum Member
  • *****
  • Offline Offline
  • Posts: 1156
  • new to the forums

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.

Nice history lesson! ;D
Logged
Pages: 1 2 [3]   Go Up
 

Recent Topics