Remnants of the pre-crash BUG Pickles thread

[cheesestraws]

Re: Format: Please post files in .sit.hqx format. .sit files are not easily portable to sheepshaver via PC, etc.

Why? Stuffit doesn't use the resource fork at all: surely the only reason to use hqx is if you're transferring it over a seven-bit ASCII connection between your old Mac and your PC?

 

[Phipli]

Why? Stuffit doesn't use the resource fork at all: surely the only reason to use hqx is if you're transferring it over a seven-bit ASCII connection between your old Mac and your PC?

The only thing I can think is that hqx (and .bin) are more generally recognised without file creator/type, while .sit internally has multiple types and can do that silly thing where it just quits without extracting... But...

It isn't too difficult to re-type files.

I did have trouble with the copy of these files from Mac garden though, I suspect someone recompressed them with a OSX version of stuffit and uploaded it.

 

[micheledipaola]

The Pickles 8.24A+ I own is fully equipped with a crystal oscillator.
Does the performance differ depending on the presence or absence of a crystal oscillator?

BTW it seems we all missed this. I think one of my cards has an oscillator which detached... should I change it? with a faster one maybe?

 

[Phipli]

BTW it seems we all missed this. I think one of my cards has an oscillator which detached... should I change it? with a faster one maybe?

Faster doesn't mean better in this case.

 

[MacOSMonkey]

@cheesestraws .sit files do not work properly when downloading to the PC and then transferring to sheepshaver - they become corrupted. They need to be binary files in order to transfer correctly to emulation via PC. Unfortunately, users and services like Macintosh Garden do not appreciate this problem, so the majority of user uploads are mostly useless. binhexing files should be required for all uploads, and Macintosh Garden and Macintosh Repository should batch process all of their current repos.

Using ResEdit to fix the filetype/creator does not fix this issue.

 

[Hollie]

@cheesestraws .sit files do not work properly when downloading to the PC and then transferring to sheepshaver - they become corrupted. They need to be binary files in order to transfer correctly to emulation via PC. Unfortunately, users and services like Macintosh Garden do not appreciate this problem, so the majority of user uploads are mostly useless. binhexing files should be required for all uploads, and Macintosh Garden and Macintosh Repository should batch process all of their current repos.

Using ResEdit to fix the filetype/creator does not fix this issue.

I may argue that you probably don't need the driver files for a particularly unknown rare Japanese Nubus graphics card if you're running an emulator...
The files that @cheesestraws kindly provided work fine.

 

[zigzagjoe]

@cheesestraws .sit files do not work properly when downloading to the PC and then transferring to sheepshaver - they become corrupted. They need to be binary files in order to transfer correctly to emulation via PC. Unfortunately, users and services like Macintosh Garden do not appreciate this problem, so the majority of user uploads are mostly useless. binhexing files should be required for all uploads, and Macintosh Garden and Macintosh Repository should batch process all of their current repos.

Using ResEdit to fix the filetype/creator does not fix this issue.

I'm not sure what your workflow looks like, but I think you are corrupting them somewhere or using a very old a version of stuffit. Taking the .sit files from Macintosh Garden, I am able to unstuff them just fine in Basilisk II (on a PC) using either Expander 3.5.1 or Stuffit 5.5.

As stated there is no need to binhex files without a resource fork.

 

[MacOSMonkey]

I do not think it is a Stuffit/Stuffit Expander version issue. I have tried 3.5.1 and also 5.5, I think. Downloading on my PC and then handing them off to Sheepshaver via a shared directory usually results in corrupt files. It doesn't work, or at least not for me. Conversely, binary files ALWAYS work.

 

[Phipli]

Come on folks. There are more important things to argue about.

I downloaded a copy of these files from Mac Garden, and I can say they would not expand on my IIx in either Stuffit 4.5, or Stuffit 5.x. That is a fact. It did that thing where it just quits straight after launching. That is not a skill thing, or a bad day thing, it is fact. In the end, I expanded them with Stuffit 6 on System 10.4 on another machine, then recompressed them in Stuffit 5.* And transfered them over to the IIx again, where they decompressed perfectly.

If the Mac Garden copy is identical, then I can perfectly understand why MacOsMonkey is having issues. Yes, it is likely an issue they could muddle through but...

This is uncalled for, and frankly not actually true :

I may argue that you probably don't need the driver files for a particularly unknown rare Japanese Nubus graphics card if you're running an emulator...

@MacOSMonkey : do you have access to an OSX copy of Stuffit? Or even perhaps try a newer version of the Classic Mac OS. I was running 7.1 when I had issues and didn't have the Stuffit Engine extension installed. None of this should matter, but perhaps it does.

 

[joshc]

I do not think it is a Stuffit/Stuffit Expander version issue. I have tried 3.5.1 and also 5.5, I think. Downloading on my PC and then handing them off to Sheepshaver via a shared directory usually results in corrupt files. It doesn't work, or at least not for me. Conversely, binary files ALWAYS work.

Try these. Tested with Stuffit Expander 5.5 in Basilisk OK for me. I kept the .sits as they were but ran them through DropStuff 5.5 to binhex them.

 

[MacOSMonkey]

I am running Sheepshaver with 7.6.1. Anyway, it's not a skill issue (which I thought was a funny). And, I don't mind the other commentary. If the files in the online mac software repos were all binhexed (which they should be for maximum compatibility across all uses), none of these issues would exist. But, alas, they are not, which also leads to the Catch-22 situation of trying to download alternate StuffIt versions that have been uploaded in .sit instead of .sit.hqx format which then end up corrupted/unusable.

I am surprised that there hasn't been a focus on this issue in the past, but maybe they will eventually enforce/covert uploads to binary format. Anyway, life goes on.

@joshc Thanks. They are .hqx files, so they will work fine.

@Phipli Thanks!

 

[Phipli]

I am surprised that there hasn't been a focus on this issue in the past, but maybe they will eventually enforce/covert uploads to binary format. Anyway, life goes on.

Oh there has. There are so many sits that won't work on actual retro hardware out there that I assumed that the older versions had a resource fork. Turns out even Stuffit 4 didn't have a resource fork.

It's a mystery why, but something upsets Stuffit when some archives have been near Windows / Linux. Beyond just needing to set the creator / type.

I wish I knew what it is. Does Windows add a header to the file or something? Is StuffIt picky about some other Mac OS flag? I really don't know.

I wish everything was .bin myself. .hqx is easier though because DropStuff does it.

 

[joshc]

I wish everything was .bin myself. .hqx is easier though because DropStuff does it.

.bin isn't without problems as well, at least according to Wikipedia (hmm)...

The first incarnation of MacBinary was released in 1985. The standard was originally specified by Dennis Brothers (author of the terminal program MacTEP and later an Apple employee), BinHex author Yves Lempereur, PackIt author Harry Chesley, et al. then added support for MacBinary into BinHex 5.0, using MacBinary to combine the forks instead of his own methods. Most terminal programs and internet utilities added built-in MacBinary support during this period as well.

Two years later it was updated to MacBinary II, to accommodate changes in Mac OS. MacBinary II remained compatible with subsequent updates of the operating system for some time. This changed with the release of Mac OS 8, which necessitated the release of MacBinary III in 1996. In the meantime, Apple itself had released the AppleSingle and AppleDouble formats, which serve the same purpose as MacBinary, but correct some problems with it.

Anyway, we should probably break this out into a new thread if we want to continue discussing it.

 

[olePigeon]

I think technically Stuffit 1.0 .sit files shouldn't need anything special and should be cross platform safe, but I have also run into issues with opening the files with Stuffit on my IIfx. Unarchiver complained as well. However, the genuine Stuffit for macOS did work. I then used Basilisk to restuff and binhex the file, then copy it over to my IIfx.

Something about them is getting corrupted in a way that doesn't happen when they're binary encoded, rendering the file unusable on a vintage Mac.

 

[MacOSMonkey]

@olePigeon @Phipli Thumbs up for you guys!

 

[joshc]

Do StuffIt 5.5 archives encode the resource fork safely for transfer to a non-Mac ?

I'm trying to understand the necessity to BinHex (.hqx) files before uploading to a website. In the old days, we always downloaded a .hqx file, that we decoded, which contained a compressed archive, often .sit. At some point, it seems that StuffIt changed its compression/encoding to account...

68kmla.org