Individual platforms do seem to do it. If I understand Windows resources (and I don't really), they are just file blobs munged into the executable and then accessed through a simple sort of namespace.

Seen that way, resources are over-engineered. The basic compiler feature we weant is something like:

    const char blob[] = __include_binary__("blob.dat");

But if I could do that, then probably the next thing I would do is invent some macro-magic to provide a resource-like namespace on top of the feature.

Windows resources were originally built to fulfil two requirements:

- display an icon for an executable

- automatic localisation of application menus etc.

So FindResource() takes three parameters: a type (icon, string, dialog, bitmap, menu etc), a name, and a language ID. That means that changing the language ID can transparently select a different UI layout and text as required.

Meanwhile Explorer (and its ancestor Program Manager) will display the first icon in the resource file as the default program icon.

Resources are just a separate section within the PE executable format.

Thanks for the explanation.

So it sounds like the critical thing that Windows resources have over the thing I outlined is that they and their namespaces are relatively transparent to external tools such as the Program Manager.

The critical thing is that MS could impose a standard. Anyone can write tools to put such a section to their ELF binaries. But it would be useless because then no one would know to read it.

Windows, Mac OS, BeOS, Symbian and quite a few others offer direct support for it, it is just a matter of using the OS APIs.

This was already like that on the 16 bit days.

For example, with Turbo Pascal for Windows, you only needed to do, after generating the resources via the resource compiler

   {$R resource name}

and then make use of FindResource/LoadResource/LoadFromResourceName

You can always (ab)use the linker! [0]

[0]: (shameless plug) http://stackoverflow.com/questions/8923097/compile-a-binary-...