Like the title suggests I'm wondering if there is any standard way to go about this?
... The reason I need to do this is that I'm developing a dll file that needs some external data, but it wouldn't do to clutter the plugin folder of the program where it will eventually end up with additional files.
The nice thing about standards is that you have so many to choose from.
Two were already mentioned:
Embedding binary resources is good, you can access the resources using standard Windows functions, and do so from any program that loads the dll. The steps to get a resource and load it into a buffer aren't hard, but because of the ease you can end up with lots of duplicates in memory if you don't pay attention to what you are doing. If this is bad or not depends on your app.
Creating a big buffer in the data segment can be nice. You get a simple array with all your data conveniently present at load time. There are many great tools out there like xxd that can turn your data into buffers, and assorted tools to convert your data directly into object form without an intermediate step. The downside is only your app gets access.
The biggest difficulty with both of these is that they become part of the executable and require space at all times the DLL is loaded. This can be great if your data is small and if it will never change once the program is built.
But we don't know those for your data. We don't know how much data you have, creating a 600MB DLL is going to put a serious strain on load time. We also don't know if the data has a separate lifetime from the DLL, if you want other people to be able to modify it without rebuilding a DLL, or if the resources come from only one file or many files.
You might be better off with a single separate file. Some options there might be:
* zip up all the stuff you need and extract as you need it
* dump it into a memory-friendly format and memory map into the file
* pack them up in a physfs or similar archive. This allows you to work as a normal file system during development, but pack it to a single compressed archive on release.
You might instead want to have a configuration file that accompanies the dll --- this is easy with the dot net configuration libraries --- so that you can keep the files wherever you want on the disk in a more traditional directory tree but only have one file in your plugin directory, "foo.dll.config", that anyone can modify and that can even be unique for each user of the machine.
If you are feeling non-traditional you can add a separate data stream to your file and write the data there. The OS uses alternate data streams all the time, as do many programs wanting to attach metadata to user created content. It can frustrate casual copiers and confuse people trying to understand disk space numbers, but it does keep the data in a single file.
There are many more options, really limited only by your creativity.
Each option solves different variations of the problem, and each has its own list of pros and cons.