Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs comment: RSRC format is just modified Macintosh Resource Fork #18

Open
superdave opened this issue Jan 3, 2024 · 1 comment
Open

Comments

@superdave
Copy link

I know this probably isn't exactly the place to make this comment, but I thought I might mention that the RSRC format as documented looks to be just a slightly modified Macintosh Resource Fork (as documented here in Apple's Inside Macintosh reference manual). Specifically, at a glance, it looks like it's the resource fork with a 16-byte header that replicates the necessary bits of the Finder info (creator/type fields, which vintage Mac OS used instead of file extensions) stapled on to the front, though there might be some nuances I didn't spot at a glance (Apple used a pretty similar approach for their .dfont files, which are just original Mac font resource files with the Resource Fork splatted to the data fork, but that didn't even have a header tacked on).

I thought I'd mention partly because it might clear up some of the unknowns you see. For example, some of the unknown fields in the resource map, which you've called Block Info List Header, are just empty in the file format because they're just placeholders for pointers to be filled after loading from disk (early 32-bit operating systems, eh?). But also I mention it because you might not need to go into too much detail in the future since the Resource Fork is pretty well documented all over.

All of this makes sense because LabView very much started life as a Mac application, and the structuring of the library files as resources would have made a lot of sense in that context. I'm sure it turned out to provide plenty of hassles when porting to other operating systems, though.

Nothing needs to change, per se, but it might help future explorers a bit if you added a link or two to the Wiki, and it might help you out a bit too in the future if something isn't working quite right. Hope this helps rather than hinders!

@mefistotelis
Copy link
Owner

If there are fields and structures with established names, the tool should switch to using them.
People did mentioned the Resource Fork to me before, but I did not had the understanding that it goes beyond main header.

Will keep that in mind, in case I will get back to work on this tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants