Yes, thinking back, I believe this is the way the Radius board did it too -- there was a Radius init that overwrote the ROM address for graphics handling with an address on the Radius board. I don't recall seeing compatibility problems on the Pluses that had the two screen setup, but then, they were usually used for specific apps that needed the extra real estate in the first place.
Back to my other point gryphel: would it be possible to add auto-binhex into ImportFL so that people wouldn't have to worry about losing the resource fork? Or is this not done as the only platforms that would be able to handle this are Classic and OS X (and they handle it differently)?
ImportFL problem
Moderators: Cat_7, Ronald P. Regensburg
Re: ImportFL problem
It is not possible to do this by just adding to ImportFl. The resource forks of imported files are not accessible to programs running in Mini vMac.adespoton wrote:would it be possible to add auto-binhex into ImportFL so that people wouldn't have to worry about losing the resource fork? Or is this not done as the only platforms that would be able to handle this are Classic and OS X (and they handle it differently)?
It would be possible to add extensions to Mini vMac for reading meta data, such as the resource fork, of imported files. But this would require implementing code in Mini vMac for each platform (actually for each supported API). Reading a resource fork would need support for Classic Mac, Carbon for OS X, and Cocoa for OS X. Then the protocol for the extension would have to be defined, and code in Mini vMac would be needed to support the protocol. Then ImportFl would need to updated to use the protocol if it was available. (The binhex format would play no role.)
Even if I wanted to, I'm not likely to have time for all that in the foreseeable future. And I have doubts about whether it should be in "Mini" vMac.
Reading the OS X archive format in my MiniUnZp is a simpler problem. But I haven't had enough time to work on that either.