Static files in Go

Re:Static files in Go by adrianratnapala on Wednesday August 10, 2016 @01:32AM (#12259679)

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.

[ Parent | on HN ]

Re:Static files in Go by pjc50 on Wednesday August 10, 2016 @06:41AM (#12260669)

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.

[ Parent | on HN ]

Re:Static files in Go by adrianratnapala on Wednesday August 10, 2016 @02:17PM (#12263755)

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.

[ Parent | on HN ]