Hi,
Pukka asked me to post some replies to this thread, so here's some quick answers. Sorry for the delay, I have been super busy with everything possible recently plus Christmas stuff...
adespoton wrote:Well done! Since there's no feedback form on the blog page, I'll add some stuff here:
Those icons are stored in the System file, so you'll need to create your own replacements. Shouldn't be too difficult. There's a few other places in the Finder where it calls for System resources instead of Finder resources -- hence why I thought this would be a good app for testing robustness, as it assumes all sorts of stuff is available from the System/Toolbox instead of replicating it in Finder resources. It always amazed me that you could swap Finder applications in different System versions because of some of this stuff -- but Apple seems to have done a decent job in the early days of tracking all its resource IDs to avoid conflicts.
Yes, actually after posting that I added some test icons to the System file and they worked pretty well. Actually, Apple uses complete icon bundles for FNDR (Finder) and ZSYS (System) in the System file, and including them not only added the icons to the "About Finder" window, but also added them to Desktop database and thus as correct icons in the Finder folder windows for Finder and System.
adespoton wrote:
This is part of what I'm talking about: from my days of skinning Finder 6.x, I can tell you that the Get Info doesn't use the same DRVR resource -- I believe this one comes from the toolbox, and you have to inject a resource with the correct ID into the System file to override the one provided by ROM. If you ResEdit a System file, you'll see the two sets of identical icons -- this is why there are two sets: they needed to use the two sets of IDs for compatibility purposes between System and Finder versions.
Actually, I was referring to the oddity that using Get Info "changed" the icon for the remaining time of the Finder was in memory on that run. The original (correct) icon does not actually come from ROM, but on real Macs resides as part of the Apple_Driver partition, which contains the device driver for that particular disk. That is, for example, iomega ZIP disks show the ZIP disk image when mounted on a system without ZIP drivers. These icons exist only as a black & white 32x32 icon, and don't have color versions (which is why, for example ZIP disk and drives formatted with FWB Hard Disk Toolkit have only black & white icons). And they are accessed using Device Manager's PBControl trap on the volume's driver with csCode 0x16 and 0x17 (for logical and physical media icons). Of course, in System 7.x that icon can be naturally customized as any Finder icon with the "Custom icon" finder flag and -16455 icon family - and deleting that custom icon will again display the original icon originating from the driver. I think this behavior changed somewhat in Mac OS 8, when they introduced the new builtin color icons for disks, but we haven't *yet* looked that far into the future.
EDIT: I was very tired when writing that last night, so I forgot to mention, that the icon driver control codes also apply to also resource-based (RAM or ROM) DRVR device drivers, not only the SCSI drivers in the Apple_Driver APM partition. And as they only return a pointer to the icon data, there are multiple ways to store and provide it. For example, Cloud 7 driver mentioned below in next answer (and one RAM disk implementation I have seen) use embedded 32x32 icon & mask within the DRVR code, and others may simply return a dereferenced ICN# resource, which has the same format. But the black & white limitation still applies.
adespoton wrote:
I *think* you're correct here, but my memory on this is fuzzy. Looking at an earlier System when HFS / HDSC20 was loaded as an extension would probably help here; this was presented as a different device than the external AppleTalk device, and was patched on via the System before the Plus ROM incorporated it (with the same ID) into the boot ROM.
It is true that the HD20 was quite a special case, I understand the extension was also necessary in later Systems to allow old ROMs to boot from the device, and load the HFS patches. But considering the usual use cases after HFS became standard, there's actually two use cases how the file system behaves - One is where the disk is a custom device, but contains a file system known by the System (such as RAM disks, or the really cool Cloud 7 at
http://www.synack.net/~bbraun/68khttpdisk.html which exposes HTTP URL as HFS disk), and the other use case is when the file system is completely foreign (such as AFP, DOS disks, etc). I think Finder might not have had proper foreign file system support until 7.x, because in System 6.x you still had for example to use Apple File Exchange to read and write PC floppy disks. So that might be why Finder 6.x is oblivious to these ExtFS file systems. Additionally, around System 7.5, FSM became also an option, and I think Basilisk and/or Sheepshaver uses FSM interface to allow the Unix filesystem access in that emulator.
adespoton wrote:
I seem to recall Apple had a separate routine for doing this, due to how Fonts, Desk Accessories and FKeys were loaded -- I think it was a cache manager routine running to actively manage this.
I haven't found any active code doing such polling, but there is a stack sniffer which monitors in VBL interrupts for potential stack-heap collisions. I think DAs (and drivers in general) were closed during Launch trap call by Segment Loader, Fonts were purged through resource manager calls done by InitApplZone. Additionally, System 7.x has a truckload of patches to these routines to allow the cooperative multitasking to work.
adespoton wrote:
Might I suggest changing ETS to call a routine at a specific place in memory instead of directly terminating the emulator? Then you can by default set the address to the terminate routine, but overwrite it with another memory location as needed. I used to do this with the programmer's key all the time; I usually used address FA700 to hold a routine that would call where I wanted to go; this allowed me to subvert Quit to open a DA (which was actually a mini launcher itself), which allowed for some interesting debugging opportunities.
Not really limited to ExitToShell, but we have a number of cases where a certain trap will need to have different behavior depending on the configuration; for example, many quickdraw traps need to have two alternate implementations for color and the classic monochrome versions, ExitToShell needs to not only handle the case of handling launch of lowmem global FinderName process and bundle application's exit() call, but also have a third option for having Process Manager compatibility when we some day get to adding support for it. Right now we have all global emulator configurations as #define:s, but will need to refactor them to be dynamically configurable.
adespoton wrote:
What implications does this have for attempting to trying to run installers that expect to be able to eject images and wait for the next disk to be inserted? I know we haven't got that far yet, but this will need to be explored in the future for disk image handling. Apple eventually started treating a folder structure as a valid replacement for disks in its installer, but early versions didn't do this, and neither did some third party installers.
Mostly the implications would be same as trying to eject the boot volume in later Mac OS versions
I know earlier Mac OS versions allowed the volume be in offline state, where it would be logically mounted but be physically ejected, which I think was used in the way you describe. However, we need to find some test cases to experiment this further (on both real Mac OS and in the emulator). But when it comes to disk-based installers, those might work out best when we some day add support for real HFS disks/images, but that is not a priority right now (we don't have yet any true HFS code, only the foreign filesystem code which abstracts the ExtFS interface like in AFP driver).
adespoton wrote:
Something else to remember: Dark Castle replaces the Finder with the Dark Castle application, so there may be some useful functionality added to DC on long tail errors from adding this Finder support.
Actually, Dark castle is a prime example of how independent the shell application was from the other System software - it was one of the first applications we got to work one year ago and did not have any issues with it being used as Finder replacement
(ps. speaking of Dark Castle, check the link later in this post after the replies
)
adespoton wrote:
Once again, great job guys!
Thank you very much, it is nice to get positive feedback. Although we originally started this project for our own entertainment (to allow us play our favorite games), it is encouraging to know there is wider interest for it. This will definitely motivate us to work harder on it, to make it a tool that everybody can benefit from.
adespoton wrote:
[edit] One more thing I forgot to ask about
Did you try printing from the Finder? That will expose a whole new set of calls you'll likely need to handle or mask
Personally, I'd love to see MACE support of a virtual Color LaserWriter that just writes a file to the host (as postscript, EPS or PDF, whatever's easier). Supporting the PrintToPDF INIT would also be interesting, but unneeded if your roll Postscript print capture directly into your System/Toolbox file.
We actually had to already implement some dummy PrGlue (the Printing Manager dispatcher) traps for Adobe Photoshop to run, so we have partial hooks for the API, but no actual native-side implementation. We haven't discussed about this yet, but I was myself thinking about the possibility of using QuickDraw and Print Manager imaging/printing functions to be converter into PostScript code, which might be passed directly to the host system printing system, allowing the *theoretical* possibility of printing directly from Classic apps on modern systems. However, there is a ton of things to implement for this to work (first of all, the actual print manager APIs, the PostScript print driver emulator, and native hooks). I think at some point Pukka did mention something about ImageWriter emulation, which is also again another venture. However, this is definitely on the "To Do" list, but again not with very high priority.
---
Speaking of the Dark Castle earlier, because we have been so busy recently, and had very little new completed features, I wrote up a quick "Holiday update" with a couple early teasers (about future MacTCP support and experimenting on Windows version of emulator), and 20+ minutes of Dark Castle gameplay with the Christmas tree easter egg here:
Holiday update:
https://mace.software/2019/12/26/happy-holidays/
Direct link to the short Dark Castle gameplay video:
https://youtu.be/cN_imqya9-g
Merry Christmas and a Happy New Year!