Mac OS 9 Discussion > Software

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

<< < (4/10) > >>

supernova777:
just for the record i just downloaded the cubase 4.0 tutorial dvd and it was a .toast.bin file.. i decoded by unstuffing (on mac os x 10.6.8 intel) with stuffit 12 or something.. and i was lazy didnt have toast on my macbook air and wanted to watch some of the content,
i simply renamed the decoded .toast file to .dmg and it mounted fine with disk utility so .dmg + .toast files seem to be totally interchangable

IIO:

just to clear the confusion caused here a bit:

 - toast file also mount using disk utiliy when not renamed to .dmg (all images do)
 - dmg does not work in OS9
 - image files do not need to be .bin´ed, as they are binary files.
 - self mounting images should be avoided on the net because they execute code

additional thought:

it can under circumstances be wise to stuff or zip images files, namely when the image is a master, i.e. may not be changed in order to make it work from CD or DVD later. especially when using shrink wrap images it can easily happen that you change its content by accident.

DieHard:

--- Quote --- image files do not need to be .bin´ed, as they are binary files.
--- End quote ---

The reason we "Mac Binary" encode toast images, even though they are "Binary already" is to encapsulate them so the the icon and creator is preserved in the resource fork... although the image remains intact without encoding... our initial tests with Adrive (the service we use) exposed that when a toast image file is not encoded, after downloading it does not have an icon and "newbies" may not know that they have to open toast first to burn or mount the file... even though we named most files .toast

So at the time, I chose to encode all files, so that when un-encoded they would retain the icon and creator info.,  the un-encoding on a Quick Silver or MDD, even on a full CD image should not take longer than a few minutes; then you can store the un-encoded image as your own personal backup.

 

supernova777:

--- Quote from: 110 on July 15, 2014, 02:40:09 PM --- - dmg does not work in OS9
 - self mounting images should be avoided on the net because they execute code

--- End quote ---

hi 110;

this is partially correct and partially incorrect.
dmg files can be opened by diskcopy 6.5b3 provided they meet a certain specific criteria.
that is pertaining to which file system they are created with.. and the specific properties.
but yes some can be mounted and accessed in os9

the whole point of this post is to highlight that .dmg and .img are not so different and are in fact different flavours of the same design, implemented by apple http://en.wikipedia.org/wiki/Apple_Disk_Image

i would love it if you could go into further detail on the secnd point ive quoted here
because as you know since the dawn of macosx (and even sligtly before that) apple's
primary way of getting installation based software packages over the internet has been .dmg + .img
and its the entire sole reason that the apple disk image format was conceived and created...
for exactly that purpose and that purpose alone... to transport the filesystems of software installers over the internet

"self mounting images should be avoided on the net because they execute code"
i really fail to understand where u are coming from with this.. of course it executes code it installs the app?
so does anything else u can put in a stuffit once u expand it?


--- Quote ---it can under circumstances be wise to stuff or zip images files, namely when the image is a master, i.e. may not be changed in order to make it work from CD or DVD later. especially when using shrink wrap images it can easily happen that you change its content by accident.

--- End quote ---

when creating a shrinkwrap package there is a matrix of different settings

file format = [shrinkwrap 3.x, Self-Mounting(.smi), disk copy 6, disk copy 4, diskdup+, ms-dos]
compression = [none, simple, diskcopy, stuffit]
encryption = [none, 40bit]
segment size = [too many options to list]

if u select simple, diskcopy or stuffit for compression settings, the disk image is READ ONLY and its contents can never be changed...
so "it can easily happen that you change its content by accident" not so much... read only is read only.

supernova777:

--- Quote ---The reason we "Mac Binary" encode toast images, even though they are "Binary already" is to encapsulate them so the the icon and creator is preserved in the resource fork... although the image remains intact without encoding... our initial tests with Adrive (the service we use) exposed that when a toast image file is not encoded, after downloading it does not have an icon and "newbies" may not know that they have to open toast first to burn or mount the file... even though we named most files .toast
--- End quote ---

sure macbinary encoding is always a breeze to expand.. ti takes about as long as it takes to copy the file, because theres no de-compression taking place..
so by all means.. please do .bin everything! .bin at will! .bin there and done that ;) hehe

but i really hope that whoever is packaging files with extreme stuffit compression will choose "Faster compression" or no compression at all (For files smaller then 250mb or so?)
because this uncompressing takes forever and we literally cant use the mac for up to an hour just to decompress a file.. its ridiculous. especially when its not saving much disk space? if it was shrinking the file by 40-50% i guess it might be worth it but these days we all have enuff space we arent running out of hard drive space.. id gladly sacrifice a few more mb to avoid that 1hr-2hrs of waiting for stuffit to unstuff.

Navigation

[0] Message Index

[#] Next page

[*] Previous page