Login  •  Register


The time is now: Thu Nov 15, 2018 11:10 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 1 of 1 [ 18 posts ]
Print view Previous topic  |  Next topic
Author Message
PostPosted: Wed Oct 24, 2018 3:50 pm 
Offline
Student Driver

Joined: Fri Oct 12, 2018 5:35 pm
Posts: 11
Hello! I was able to get Basilisk up and running and figured out how to install programs I needed to view some files I wanted to take a look at, but now I have a different problem.

I have some PageMaker 4 files and a Hypercard file that I am trying to open, but when I try to open them in the emulated environment in Basilisk, the system doesn't recognize them as files created by those programs - when I try to double click them, the system gives an error saying that it can't find the programs used to create these files and therefore can't run them.

The Hypercard file I am trying to open can be found here: http://vispo.com/bp/hypercardversion.htm
(This file was uploaded to the Archive.org emulator by someone else, and it seems to work fine there).

The PageMaker files are extracted from Mac formatted disk images I created using HFSExplorer.
(This is an example http://s000.tinyupload.com/index.php?file_id=09022510312164212590)

I'm not sure if there's something that is happening when I save the files onto my Windows desktop and then put them onto the virtual hard drive file via HFV Explorer that makes them unreadable in the emulated environment? Is there something I need to do to these files to make it so that they are "recognized" as proper PageMaker/Hypercard files in the Mac 7.5.5 environment itself?
Is there a step I'm missing in order to be able to make these files recognizable by the emulated environment?

Thank you!


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 24, 2018 6:47 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 922
When you extract an old Mac file to the Windows desktop, you lose its resource fork and old Mac software doesn't know what to do with it.

If you're trying to get files out of a ZIP file, then copy this Zip-extractor to your Basilisk II system and use it to open the ZIP file inside Basilisk II:

viewtopic.php?f=1&t=8322#p47731

If you're trying to get files out of a SIT archive, etc., then find StuffIt Expander and install that in Basilisk II. You can find links to StuffIt on this forum.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 24, 2018 6:55 pm 
Offline
Student Driver

Joined: Fri Oct 12, 2018 5:35 pm
Posts: 11
Ah thanks, that's helpful!

Edit: Basilisk helpfully understands and mounts disk images as floppy disks which is helpful, but I'm still having the same problem with both files.

I used the script to extract the Hypercard zip file inside the emulated environment itself and it doesn't recognize the Hypercard file, and the system also doesn't recognizes the .pm files on the disk (which I know are PageMaker 4 files based on the ALB4 ALD4 file signature I can see in a hex editor and this table here: https://www.macdisk.com/macsigen.php).

Do I need to find the exact versions of each program to try to open them, or is there something else I'm missing?

Thanks again.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 24, 2018 7:51 pm 
Offline
Master Emulator

Joined: Fri Sep 17, 2004 4:22 am
Posts: 323
The utility in that other thread is used for .zip files created in OSX. These are easily identified by the presence of a folder named "__MACOSX" in the .zip file. It would seem what we are dealing with here is something completely different – zip archives of MacBinary-encoded files. I suspect the reason you are seeing "ALB4 ALD4" in a hex editor is because you are looking at a MacBinary header.

Anyway, the simple solution is to open these unrecognizable files with Stuffit Expander, which should decode them and let you open them in Hypercard and Pagemaker.

(ZipIt, which should run in Basilisk, should also probably identify MacBinary-encoded files in .zip files, but it is unnecessary.)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 24, 2018 8:14 pm 
Offline
Student Driver

Joined: Fri Oct 12, 2018 5:35 pm
Posts: 11
For the .pm files, I mounted the disk directly with Basilisk GUI so the emulator picks it up as a disk drive and then copied the files from the disk drive to the system - there is no extraction involved, but they are still unrecognized unfortunately..

For the hypercard file, I put the .zip file into the system image that I have connected to Basilisk and then used the script to unzip the file from within the emulated environment itself. I'm using StuffIt 5.5, and it doesn't recognize the .zip file - I have to use that script to extract it from inside the emulator.

(I also tried dragging the .pm files to StuffIt just to see if it would do anything and it doesn't work. I tried dragging the .pm files to Pagemaker 4.2 and the hypercard file to Hypercard 2.0 and neither worked either)

The direct link to the hypercard zip file is here if that helps: http://vispo.com/bp/download/FirstScree ... ercard.zip
(This is the emulated version on Archive.org - https://archive.org/details/hypercard_first-screening)

And I can try to post one of the disk images I made that contains the PageMaker files if that would help as well?

Thank you!


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 24, 2018 8:54 pm 
Offline
Master Emulator

Joined: Fri Sep 17, 2004 4:22 am
Posts: 323
I might be able to take a look at these later.

To be clear: did you try dragging the unzipped file onto Stuffit Expander?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Oct 24, 2018 8:57 pm 
Offline
Forum All-Star

Joined: Wed Nov 11, 2009 5:47 pm
Posts: 1155
Location: Germany
ZipIt is the one to inflate the file, thats right.
Strange enough the resource fork is missing still.
I added a resource fork and put the file into a disk image. Unzip and add the .img to the Basilisk II volume GUI.
If you run the hypercard file, it may ask for its "home" file. Select the FirstScreening file and it should run.

Hope it works on your side:
https://www.magentacloud.de/lnk/AFSNg4bg

For Pagemaker, I would install from scratch again.
Here are some PM6 installers collected: http://macintoshgarden.org/apps/adobe-pagemaker-60


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Oct 25, 2018 2:42 am 
Offline
Student Driver

Joined: Fri Oct 12, 2018 5:35 pm
Posts: 11
Thanks to you both for taking the time to look at it.
I was able to get the Hypercard image/file to load, which is great. :)

However, installing PageMaker 6 still didn't help unfortunately.
Here's a copy of the disk image itself if either of you might have time to look at it. There are some of .pm files and some other files with no-extension that I assume are related.
http://s000.tinyupload.com/index.php?fi ... 6203261424

The image mounts fine in Basilisk, but the PM4, 5, and 6 just won't recognize them as files that they can open. I guess it's possible they're not PM files, despite the file signature, but then I'm totally stumped...

Thanks again.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Oct 25, 2018 7:00 pm 
Offline
Master Emulator

Joined: Fri Sep 17, 2004 4:22 am
Posts: 323
I wonder if it's possible that the files are encoded with MacBinary III, and that Expander doesn't recognize them?

The quick and easy thing to do would be to try probing them with The Unarchiver. Try following the instructions at https://www.emaculation.com/doku.php/ex ... in_windows , but specify your .pm file instead of a .sit archive.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Oct 25, 2018 7:38 pm 
Offline
Inquisitive Elf

Joined: Wed Nov 19, 2008 4:58 pm
Posts: 31
The ".pm" files are Pagemaker files compressed with DiskDoubler.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Oct 25, 2018 7:47 pm 
Offline
Master Emulator

Joined: Fri Sep 17, 2004 4:22 am
Posts: 323
uhhu wrote:
The ".pm" files are Pagemaker files compressed with DiskDoubler.
Gee. Does Stuffit Expander not handle DiskDoubler? That's an unfortunate limitation.

The Unarchiver trick ought to work in that case as well, anyway.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Oct 25, 2018 8:00 pm 
Offline
Student Driver

Joined: Fri Oct 12, 2018 5:35 pm
Posts: 11
Disk Doubler did the trick (which means, yeah, unfortunately StuffIt didn't handle the files). I'll have to keep the different compression programs in mind since I'm so used to just using 7zip or Winrar to handle everything. :)

Thanks again for everyone's help, it's much appreciated!

Just an educational question - how do you know when you are dealing with a compressed file based on the information you might see in a hex editor? Is there another file signature to look for to show that it has been compressed?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Oct 26, 2018 12:56 am 
Offline
Master Emulator

Joined: Fri Sep 17, 2004 4:22 am
Posts: 323
firehawk12 wrote:
Just an educational question - how do you know when you are dealing with a compressed file based on the information you might see in a hex editor? Is there another file signature to look for to show that it has been compressed?
Probably – but it will be different for every compression format, and I doubt it is as well-documented as that type/creator listing you linked to. You can try digging through the source code for The Unarchiver.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Oct 26, 2018 5:22 pm 
Offline
Inquisitive Elf

Joined: Wed Nov 19, 2008 4:58 pm
Posts: 31
firehawk12 wrote:
Just an educational question - how do you know when you are dealing with a compressed file based on the information you might see in a hex editor? Is there another file signature to look for to show that it has been compressed?

The file signature, i.e., the type and creator, is stored on the Macintosh disk catalog tree, not in the file. Some programs can figure out the signature of some files by examining the data.

Mac signatures
More Mac info


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Oct 26, 2018 7:36 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2265
Location: Emaculation.com
Most file types contain a "magic word" at the top of the file (eg PK for zip files), which operates pretty much like the HFS file type. However, some old Mac file types just depend on the T&C in the Resource fork to do this. Also, some newer Mac file types (I'm looking at you DMG) store the metadata in the footer instead of the header, so if you look at the top of the file, you'll actually see the file type of the first file stored in the DMG container.

Also, if you're delving into examining files with a hex editor, it's probably useful to know that many many file types these days are multiple files flat-packed in some sort of container file. Examples of container file types are DMG, PDF, DOCX, IPA, RTF, BIN and MP4/M4V. The container then describes what sort of contents it contains, which could be any of a number of types of full files or data snippets.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Oct 27, 2018 3:16 pm 
Offline
Inquisitive Elf

Joined: Wed Nov 19, 2008 4:58 pm
Posts: 31
adespoton wrote:
However, some old Mac file types just depend on the T&C in the Resource fork to do this.

Yes, classic MacOS files (and therefore, the files in BasiliskII) depend on the type/creator. But it is neither in the data nor the resource fork of the file. It is stored on the disk. However, the binding info is in the application's resource fork (BNDL and fref) and is copied to the disk when the application is "inited". When a file is copied to another disk the file information is copied from the disk to the other disk, too.
https://en.wikipedia.org/wiki/File_form ... type-codes
https://en.wikipedia.org/wiki/Creator_code

When BasiliskII copies a file to its UNIX folder, the file is in three parts: data, resource fork, and file information. Data is the visible part, the resource fork with the same name is in an invisible directory ".rsrc" and file info in another invisible directory ".finf" (in Linux).

I just made an empty text file with SimpleText so the type/creator is TEXT/ttxt. Then I opened it with HexEdit 1.0.7 and cleared the resource fork put there by SimpleText. The file size is now zero and the length of the data and resource forks are zero. Yet the type/creator remains TEXT/ttxt.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Oct 27, 2018 7:43 pm 
Offline
Student Driver

Joined: Fri Oct 12, 2018 5:35 pm
Posts: 11
uhhu wrote:
firehawk12 wrote:
Just an educational question - how do you know when you are dealing with a compressed file based on the information you might see in a hex editor? Is there another file signature to look for to show that it has been compressed?

The file signature, i.e., the type and creator, is stored on the Macintosh disk catalog tree, not in the file. Some programs can figure out the signature of some files by examining the data.

Mac signatures
More Mac info


Oh I see, so at least when examining Mac files, I would need to hex edit the disk image itself to understand the file type? I can see the Disk Doubler signature when I do that.

Then I assume when I opened the .pm file and saw the Page Maker signature, that was Disk Doubler putting that information in the file so that it would be able to uncompress it?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Oct 29, 2018 12:08 am 
Offline
Inquisitive Elf

Joined: Wed Nov 19, 2008 4:58 pm
Posts: 31
firehawk12 wrote:
Oh I see, so at least when examining Mac files, I would need to hex edit the disk image itself to understand the file type? I can see the Disk Doubler signature when I do that.

You should mount the disk image and check the file type with Creator Changer. You could also use ResEdit.

firehawk12 wrote:
Then I assume when I opened the .pm file and saw the Page Maker signature, that was Disk Doubler putting that information in the file so that it would be able to uncompress it?

Yes, DiskDoubler must maintain the file info in the DD file because macOS does not know what is in there.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 1 of 1 [ 18 posts ]


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group