AppleCD on IBM AT?
10 messages in this thread
Is there hardware and software for IBM AT clones (ISA bus) that will read
disks created on an AppleCD SC Plus?
So far, I don't think so… Even if it did, how could it get past the
(major) differences between Mac and PC filename conventions? Then, the
software would need to understand the data fork / resource fork dichotomy
of the Mac. The Mac's filesystem is more compatible with the Amiga or
Unix.
There is 1 Reply.
Actually, it's not neccessarily so weird a notion as you might think,
John. It really depends more on the sort of data in the Mac files than
anything else.
A GIF is a GIF, regardless of system, for example: I have a few that I
shipped via serial cable to my Mac before I got a VGA, and they display
just fine with the GIF viewer there. Same for straight text. Now, if the
Mac files contained QuickDraw "pictures", or documents in a format
peculiar to a Mac spreadsheet or word processor, it would be tougher. But
there are programs around that handle translation, and a utility to
extract data from a Mac CD for transfer to DOS files, while not trivial,
is certainly do-able.
Ran
There is 1 Reply.
Actually, it has to do with two things: the data file format and the
volume format.
CD-ROMs for Apples use one of three formats: ISO-9660, High Sierra, or
HFS. A PC with MS-DOS CD-ROM Extensions can read the first two formats.
Currently there is no way for a PC to read the third format (HFS).
As Ran mentioned, all Apple files are actually made up of two parts: a data
fork and a resource fork. These two forks are essentially two seperate
files that share the same name. ISO and High Sierra have a similar system.
Each file may have an associated file that has the same name. Apple ISO
and Apple High Sierra CD-ROMs store the data fork in the main file and the
resource fork in the associated file.
PCs can read the main data file, but not the associated file. Therefore,
if the useful information is stored in the main data file (the data fork),
no problem.
There is 1 Reply.
Matt,
You mean after all this time no one has gotten around to doing that? Or
just that it's not built into MSCDEX? Perhaps the market's not big enough
to make it profitable, but it doesn't strike me as a difficult enough task
to have precluded it.
Ran
There is 1 Reply.
Nobody's gotten around to doing what?
1) Allowing access to Associated Files?
a) Associated files correspond to Resource forks. These forks contain
Macintosh menus, dialog boxes, etc (usually). Not very useful
on a PC.
b) How could MS-DOS represent this concept?
2) Allow reading HFS format discs?
If a publisher publishes a CD-ROM in HFS format, its normally because
it only contains files understandable to Macintosh programs. This makes
it unnecessary to publish in portable format like ISO-9660. Since
publishing in HFS allows full use of Mac icons and file names, and
is completely transparent to the Mac, some Mac publisher prefer this
format.
There is 1 Reply.
Ackshewally, one could all sorts of interesting things with stuff from the
resource forks, if one had the time and/or money. Aside from the CODE
resources, most could be used on a properly-designed PC platform that
emulated some key parts of the Mac software. The fact that the GUI
resources are much more standardized on the Mac would make it easier to use
them on a PC than vice-versa. If there were some standard "viewing engine"
that a lot of Mac CD publishers were using (and I have no idea whether
that's the case), a port to the PC would be more tedious than difficult.
It's one of the ironies of the gross mistake Apple made in releasing the
128K Mac: the set of standard routines supplied with the system was much
more primitive than it ought to have been, making it that much easier to
emulate <g>.
Here's what I mean: On some Mac HFS volume, you've got directories and
files with more than "abcdefgh.ext" filenames. They're mixed case, contain
spaces, and more than 8 chars long. So how do you translate those to a PC's
brain-dead file system? I've got CD-ROMs that contain non-PC filenames
(even though they're ISO) and my PC can't even 'cd' into some of the
directories. For transparent access, you have to play a lot of tricks to
get around this, like maintaining duplicate directories. On a CD, this
could take a lot of memory. This is similar to mapping file systems across
networks. Some networks solve this by providing a utility that understands
both file systems, and you're free to enter filenames in either system,
then copy the files from one system to another using the names you've
given. This redirects the name mapping problem from the computer to the
user. 🙂
As for data, of course you're right. I just wrote an article about CD-ROMs
that can be used on different platforms. They were few and far between,
unfortunately. Too many programs rely on platform-specific search engines.
There is 1 Reply.
Hello John!
I'd be interested in reading your article about cross-platform CD's — I'm
trying to publish one myself, and I'll be attending a conference in two
weeks which will try to address this issue, among others. I'm sure others
would be interested, too…
Can you give us a citation or (hope of hope!) up-load your article?
Thanks…
Which publication are you writing for? Mine will appear in AmigaWorld in a
few months. I hope to write others for other publications. Can't upload
the article, sorry. Which conference are you attending? I had hoped to go
to the CD-ROM Expo in D.C., but other conflicts prevented it.