> You could extend the types of resource supported by means of a template, itself stored as a resource, so developers could define new resource types appropriate to their own apps.
That’s not true. ‘TMPL’ resources solely were for ResEdit (and fairly late version of ResEdit; the first versions didn’t have the. ‘TMPL’ extension mechanism) so that it could display some resources in a dialog. Developers would just ask the resource from the system and interpret its bytes in any way they saw fit.
> In those days, it was ResEdit that displayed the Get Info dialog for folders and files, where the sizes of resource and data forks were revealed.
It wasn’t. The finder showed the “Get Info” dialog. ResEdit had its own more extended version (the one shown in the article)
> Resource forks and the thinking behind them are ingenious and empowering, but open up many security issues
I don’t think it’s fair to blame resource forks for that; it was the combination of the Resource Manager with its “when asked for a resource, I’ll go through all open resource forks, starting with the last one opened” and the Finder with its “when a disk is mounted, I’ll open a resource fork to the desktop file and keep it open”.
This is somewhat similar to having “.” In your PATH. That can cause your shell to run programs that you don’t expect to run, but you don’t blame the existence of executable files for that do you?
A security-conscious API design for the resource manager would have it require a (file ID, resource type, resource number) triple to obtain resources, or require explicit buy-in for “put this file in the set of files to search”.
That’s not true. ‘TMPL’ resources solely were for ResEdit (and fairly late version of ResEdit; the first versions didn’t have the. ‘TMPL’ extension mechanism) so that it could display some resources in a dialog. Developers would just ask the resource from the system and interpret its bytes in any way they saw fit.
> In those days, it was ResEdit that displayed the Get Info dialog for folders and files, where the sizes of resource and data forks were revealed.
It wasn’t. The finder showed the “Get Info” dialog. ResEdit had its own more extended version (the one shown in the article)
> Resource forks and the thinking behind them are ingenious and empowering, but open up many security issues
I don’t think it’s fair to blame resource forks for that; it was the combination of the Resource Manager with its “when asked for a resource, I’ll go through all open resource forks, starting with the last one opened” and the Finder with its “when a disk is mounted, I’ll open a resource fork to the desktop file and keep it open”.
This is somewhat similar to having “.” In your PATH. That can cause your shell to run programs that you don’t expect to run, but you don’t blame the existence of executable files for that do you?
A security-conscious API design for the resource manager would have it require a (file ID, resource type, resource number) triple to obtain resources, or require explicit buy-in for “put this file in the set of files to search”.