You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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.
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!
The text was updated successfully, but these errors were encountered: