Would you consider setting up a SheepShaver or Basilisk II instance?
Inflating Mac files on a Windows OS is not really promising, especially when targeting MiniVMac.
If you choose to take that way, i´ll prepare a Stuffit4 zipped disk image for use in MiniVMac for you.
One obstacle is that not all Stuffit files are expandable by Stuffit4, the majority of archived stuff should work though.
24bit wrote:Would you consider setting up a SheepShaver or Basilisk II instance?
Inflating Mac files on a Windows OS is not really promising, especially when targeting MiniVMac.
If you choose to take that way, i´ll prepare a Stuffit4 zipped disk image for use in MiniVMac for you.
One obstacle is that not all Stuffit files are expandable by Stuffit4, the majority of archived stuff should work though.
Well, the instructions said to decompress *.sea.bin files to use for Mini-vMac. I don't have a real Mac.
Ant @ Quality Foraged Links (http://aqfl.net) and The Ant Farm (http://antfarm.home.dhs.org).
.sea.bin files are SFX Stuffit archives (they've got a resource fork) that have been macbinarry encoded to store the resource fork in the data fork so it won't get lost on non-HFS filesystems.
Unfortunately, .bin files require Stuffit or another archive tool in order to extract to a usable state, so you'll need Stuffit before you can expand them.
The situation is slightly different in this case since you don't need to worry about preserving the resource fork. (Otherwise, Stuffit Expander for Windows wouldn't work at all.)
The situation is slightly different in this case since you don't need to worry about preserving the resource fork. (Otherwise, Stuffit Expander for Windows wouldn't work at all.)
The link to the Windows version of The Unarchiver is dead; the current one is here:
The problem is, if you decode the appledouble file in Windows, you're left with a Stuffit SFX app, and Windows doesn't know how to handle the resource fork. Once the resource fork is stripped, the data fork is missing key compression-related info about the archive, so it usually fails to unstuff under the guest OS.
So it's better to drop the SEA into an image file and mount that in the guest OS, where it can be run to decode any future .bin files.
As an aside, Windows has technically been able to handle resource forks since NT3.1 -- the problem is, nobody ever wrote their tools to take advantage of this. Alternate Data Streams on Windows work almost exactly the same way as named forks under OS X -- meaning if you decompress an appledouble file, you can stick the data fork in the default stream, and then output the resource fork to a :resource stream -- in fact, MS created the feature in NTFS specifically to be binary compatible with HFS.
So if we created some tools that took advantage of this, we could transparently decode macbinary files to any NTFS volume and have them accessible via the shared folder. Doing so would require tweaking a decompression tool such as unar (The Unarchiver for Windows) to output resource forks to the resource ADS, and then tweaking Basilisk II / SheepShaver to read/write the Resource ADS in the shared folder.
Sorry for the bump, but the same problem is happening to me. But when I tried to extract the two disk images it showed up with something. Which version of the C++ Redistributable do I need to use for it to work correctly?
Sorry, I can't quite figure out which problem you're having -- that Stuffit for Windows Edition 9 is crashing for you? It sounds from your comments that this is not the problem?
Is your problem that you are having difficulty figuring out which MSVC to use to compile the source files Mini vMac outputs after running the script?
You are QUITE off... Yes, it crashes. But when I want to extract something (selecting the extract option in the context menu) it shows up the error, but the extract window appears, so I can select an option and extract the file. And I was asking which version of the C++ Runtime Redistributable do I need, because the error window mentions a runtime error, so maybe the cause of the program crashing at startup is because I don't have the neccesary C++ Runtime Redistributable installed.
The response at the top of the thread was that this is a bad idea in the first place; if you extract the sea file from the macbinary file, you'll be missing the resource fork in Windows. It doesn't fix your problem, but what you are attempting to do is probably not a good idea in the first place.
Is this still about a .sea file (self extracting archive application)? When such files are even only saved in Windows they will become irreversibly unusable. You need a Mac environment to use them. The .bin file needs to be decoded in a Mac environment and then the resulting .sea application can mount the image that is coded in that application.
