MacImage FAQ

• Home
• MacDisk
• MacImage
• Download
• Support
• FAQs
• Site Map

• Home
• MacDisk
• MacImage
• Download
• Support
• FAQs
• Site Map

Using the FAQ

The Table of contents below contains links to the answers given. From each answer, there is a link back to the table of contents, allowing you to navigate and find the information you are looking for.
Back to Main FAQ Page.

Open the 'Options' menu. Select the Language/Langue item. Select the English language. This setting is saved in the Registry. That means that you'll only have to do it once.

There is no size limit to projects (*.mipr files). Since the project is a plain file on the hard disk, its only limit is the available place. We tested the program with datasets of about 81,000 files and more than 3,300 folders.
Likewise, there is no size limit for disk images. The program warns you if the image size is more than 650 MB, but you can ignore this warning.
On the other hand, Macintosh data DVDs are just bigger CD-ROMs, and you can use MacImage to produce such images (tested up to 4.5GB).

You added a great number of files and folders to a project file in MacImage and would like to check whether all files are indeed included in the project. Several methods can be used to check the project.
First of all, the item "Information", in the "File" menu, displays the number of files and folders included in the project. You can compare this data with the data displayed by the Explorer in its Properties dialog box.
You can also launch a project refresh (check for file existence and update their size). This feature, in the Options menu, checks that all files and folders included in a project still exist on the hard disk. It is meant to check a project that you reuse some time later, but is also useful as a check after adding files to the project. Errors should show as missing files (one or two red dots). This check is only useful for little projects.
On the other hand, the list of missing or changed files displayed by the program can be printed to help you to pinpoint the causes of the problems encountered.

Macintosh applications (programs) are difficult to manage because those files are mainly contained in the resource fork. That means that you can't just get the file from a NTFS server or from the Internet and copy it to the project. Doing so, you're loosing the resource fork, and your program can't be executed any more.
We publish a specific page on Installation of Macintosh applications, where we give instructions for some classical examples, like Acrobat Reader, MS Internet Explorer, Netscape Navigator, etc. The information given there applies to all kinds of programs (Director projectors, and the like).
See also our page on Flash for some instructions on how to manage the Flash engine.

It is possible to test the image file produced by MacImage (result of the compilation of your project file) without burning it onto a CDR.
To test the ISO view, use one of those programs:

• WinImage, shareware available at www.winimage.com
• IsoBuster, freeware available at www.ping.be/~pin11466/isobust.html
• CdMage, freeware available at cdmage.cjb.net.

To test the HFS view, switch MacImage to the Partition mode (in the Options menu) and open the image file.

If you got on the PC a Macintosh (HFS) CD-ROM image (plain copy of a CD-ROM stored in a file), like the *.TIMG files created by Toast on the Macintosh, you can open the file in MacImage and make some modifications.
This feature would be useful if you got a Toast CD-ROM image and want to modify a filename, add a missing file or the like. Within some limits, you can also change the size of the image file (see the comments on this feature on MacImage page).
More, MacImage can open disk images created by DiskCopy (*.dmg or *.dmgg files) when those images are neither crypted nor compressed.

HFS images created by Toast can be pure HFS volumes, starting from the first sector. In this case, they don't contain at the 16th sector what Easy CD Creator expects from CD-ROM images (the "CD001" string) to ascertain whether they are mode 1 or mode 2 images. Such images can't be burnt with this program.
On the other hand, Toast also produces hybrid images, where the ISO volume and the HFS volume are superposed. Such images can be burnt with EZCD.
On the other hand, all major packages accepting plain images (Nero, CDRWin, WinOnCD, NTI, and so on) can burn the plain mode 1 data images from the Macintosh.

MacImage doesn't yet allow you to directly copy files from a NTFS disk managed by SFM (This will be added in the next version). For the time being, the solution is to copy the files with MacDisk in MacBinary mode from the NTFS/SFM folder to another folder (anyone). Then, copy the files to the HFS image created in MacImage. The resulting HFS image is then burnt the usual way.

Two different situations may exist. First, you want to burn an exact image of the existing Macintosh volume (a real Macintosh HFS volume, and not a Mac-like medium like NTFS volumes handled by SFM or MS-DOS volumes handled by Apple File Exchange). Make an image of the Macintosh volume with Hybridator, then burn this image. Some burning packages may dislike this kind of image (see the FAQ on CD-ROMs about burning real ISO images and other CD-ROM images).
In the second case, you only want to burn some files. This falls back to the question above (about NTFS volumes). The solution is the same (copy in MacBinary mode with MacDisk, then copy to the HFS image in MacImage).

Please note that files like the Desktop and its variants are not necessary. You don't need to copy them from the Macintosh medium. More, if you gather files from several sources and install the files in a new tree structure, you should not put several desktop files in several subfolders.
Files named 'Icon_' are pictures used in the parent folder to display the folder/subfolder with a more or less meaningfull icon. You can keep them, but don't forget to copy them with the MacBinary option (the data fork is empty). Please note also that those files have a special signature, comprising only spaces.

If the engine you install on the CD-ROM contains alias files, you must pay some attention. Alias files are like *.lnk files on the PC and allow the user to start an application without navigating to the subfolder containing the real program. The signature of alias files is 'adrp' for the file type, while the creator string is generally the same as the program. Since those files can start an application stored on another disk, they contain a complete access path, volume name included. That means that you have to name your (future) CD-ROM like the CD-ROM from which you copied the engine. I don't know about an alias editor on the PC. We plan to add such a feature to our MacImage (in the next version).

On the Macintosh, files are not identified by their extension, but by their signature. The signature is a string of four characters for the file creator and four characters for the file type. The signature of Acrobat PDF files is "CARO" (creator) and "PDF " (file type). Please note that the fourth character in the string "PDF " is a space. Those parameters should be entered with SignEdit in the internal table of the program. The internal table (and the external signature file) contain both extensions and signatures for most usual file formats. This doesn't mean that they will fit to your personal needs. If you don't know the signature for a specific Macintosh data file, you should note it from a real Macintosh medium (rightmost column in MacDisk). Our signature page contains a long list of signatures. If this list is not enough, the page has also a link to the most complete database about signatures I know of.

On a Macintosh medium, a file must bear a signature. MacImage gives the file a signature based on the extension. For an example, an Excel file (*.xls) will get the XLS5XCEL signature.
When MacImage doesn't know the extension of the PC file, it uses the generic signature TEXT????, which means that the file is a text file (TEXT) produced by an unknown creator (????). This will yield the generic Macintosh icon (a cornered paper sheet). This is a good solution if the file is indeed a text file. On the other hand, this is bad if the file is something else, say a MPEG file.
Therefore, MacImage offers a special feature: searching for generic signatures. The program scans the project file for files having a signature with four question marks (????). You can then accept those signatures, correct them all or one by one.
It can also happen that you have generic graphic formats, like JPEG, MPEG, TIFF and the like. By default, MacImage gives those files the signatures JPEG????, MPEG????, TIFF????. When the user clicks on such files, the Finder will open the file with the application which has registered the file type. However, the icon will still be the generic one.
If you are sure that the target computer will have some piece of software to open those files, try to get the creator code for this program (by reading a Macintosh medium storing such a file) and replace the four question marks with its string. You can do this for each file or change the signature file with SignEdit, the editor of the signature file.

You created a project, compiled it to produce an image and burnt it onto a CD-R. Now, when opening the CD-ROM in the Explorer, you only see a single file with the "iso" extension.
This is a classical confusion. You should understand that the iso file is the CD-ROM. You should not put it on the CD-ROM as a file, by creating a project, dragging the file to the project and burning the project. All major CD-ROM burning packages offer a method to burn plain iso data images.
See our FAQ on CD-ROMs for more information on the methods offered by several major software.

You successfully created and burned an image with MacImage, but when testing on several Macintosh computers, the CD-ROM mounts on some machines and not on all.
The HFS volume created on a CD-ROM doesn't store its driver (like other removable media) and should be mounted by the operating system. It happens that one has to use SCSI Probe or the like to mount such a volume.
More, remember that some (older) CD-ROM drives can't read rewritable CD-ROMs (CD-RW). If the Macintosh CD-RW you just burnt doesn't mount, please retry with a plain CD-R.

We have observed that, under some conditions, the last sectors of a perfectly valid image (ISO image or hybrid HFS/ISO image) aren't burnt onto the CD-ROM if the image doesn't end on a 4-sectors limit. It seems that this doesn't happen with burning software which default with adding the 150 post-gap sectors.
For an example, a valid image of 895 sectors will only contain 892 sectors on the CD-ROM. The last three sectors are not written to the disk.
You can observe this when trying to read the last file of the image from the burnt CD-ROM. The filelength is correct, but the end of the data is zeroed.
If one adds an empty sector to this image (now of 896 sectors, a multiple of 4, as you guessed it), the image is correctly burnt by all software packages.
Till now, we could not find an explanation for this behavior. Anyway, version 6.3.5 of MacImage was corrected to add empty sectors to let the image end on this 4-sectors limit. The problem can only happen with small images, because the cluster size (allocation block size) of bigger images goes very rapidly from 1 sector (2048 bytes) to 2 and 4.

When copied to a project file or to a virtual HFS partition in MacImage, a BinHexed file is not recognized as such and therefore not decoded.
We already saw some BinHex files where the line "(This file must be converted with BinHex 4.0)" was not the first one, but the second or event third one. Our programs choke on such files. Open the file in a text editor and delete what comes before this line. Save the file and try again.

On HFS and hybrid CD-ROMs, the available space is allocated in clusters. The size of those clusters depends on the overall size of the volume, because the binary table used to store free and allocated clusters must be addressed by a short integer (16 bits). HFS CD-ROM can address logical sectors of 512 bytes. For hybrid CD-ROMs, since the space on disk must be allocated in a way compatible with the ISO system, the cluster must be a multiple integer of 2048 bytes. Therefore, the limits are following:
Clusters of 2048 bytes: 65,000 sectors, 134MB
Clusters of 4094 bytes: 131,000 sectors, 268MB
Clusters of 6144 bytes: 196,000 sectors, 402MB
Clusters of 8192 bytes: 262,000 sectors, 536MB
Clusters of 10240 bytes: 327,000 sectors, 671MB
Clusters of 12288 bytes: 393,000 sectors, 805MB

On Web sites built in Dreamweaver and burnt on CD-ROM, some links that work perfectly on a PC fail on a Macintosh. The main entry point works fine, but some secondary links don't answer.
Check the way the links are written. Dreamwearver uses many indirect links, like '..\..\images\picture.gif', in particular for shared files used in numerous secondary pages. While Macintosh browsers correctly manage almost Unix-like or PC-like links, they fail on such complicated links.
Try to rewrite your links as to always go down in subfolders and never up. You can also try to code all links as absolute access paths from the Web site entry point.

When launching MacImage under Windows 95 or Windows 98, you get an error message stating that MacImage "is linked to the missing export OLEAUT32.DLL:VarNot".
This error happens on computers running Windows 95/98 without the latest DCOM updates.
To solve it, you'll have to update the DCOM software, using one of following links:
Link for Windows 98
Link for Windows 95.
The updater for Windows 95 is also present on the distribution CD-ROM, in a folder labelled DCOM. The updater for Windows 98 is not a freely redistributable component, and we could not include it on the CD-ROM.

In the Compilation dialog box, an 'Advanced' button allows you to specify the Publisher, the Data Preparer and the Application for the future CD-ROM you're preparing. Those fields are foreseen in the ISO 9660 standard but are rarely used or even displayed.
On the other hand, when you open the Autoplay feature of Windows on such a volume, you get the volume title and below a line stating: "Published by Microsoft Windows". When this issue was raised by a customer, I first thought that the burning tool used had replaced the original string by its own one.
Looking at the raw data of the image, the specified string is still there. Just, it doesn't get displayed in the Autoplay dialog bow.
Well, it appears that this is the "normal Microsoft" behaviour. There is nothing one can do about this, sadly.