Does embedding a large binary as RCDATA in a Win32 EXE necessarily increase SizeOfImage, even if accessed on demand?

Question

Hi,

Objective: Our product goal is to ship a single executable file on Windows. To achieve this, we are evaluating embedding a DLL (or other large binary payload) directly into the EXE using Win32 resources, instead of distributing a separate DLL file.

What we tried: We embedded a large binary payload into a Win32 x64 executable as RCDATA in the .rsrc section (treating it purely as an opaque binary blob, not relying on any DLL semantics). At runtime, the resource is accessed via standard APIs (FindResource, LoadResource). We then inspected the resulting binary using dumpbin /headers.

What we consistently observe is that when the payload is embedded into .rsrc, the .rsrc section’s virtual size grows by approximately the size of the embedded data, and the PE Optional Header SizeOfImage increases accordingly, while other sections remain unchanged. This happens regardless of whether the payload is a DLL, bitmap, or generic binary blob.

At the same time, some documentation and articles state that Win32 resources are “loaded on demand” and are not fully loaded into memory by default, which creates ambiguity about what “on demand” actually means in terms of PE image layout versus physical memory usage.

Question: From a Windows PE loader and resource management perspective, is it fundamentally true that any large data embedded as .rc/RCDATA must increase the executable’s SizeOfImage because it becomes part of the mapped PE image, and that “loaded on demand” refers only to demand paging of physical RAM—not to avoiding growth of the image’s virtual size?

I’m looking for confirmation or correction of this understanding from a Windows internals / PE loader standpoint.

Also, as per our objective stated above, do help if there is any other alternative available.

Thank you

Answer 1

Hi @Varun Dixit ,

Thank you for your question. Your understanding is correct: embedding a large binary as RCDATA in .rsrc increases the executable’s SizeOfImage, even if you access it “on demand.”

According to the PE/COFF specification, SizeOfImage represents the total virtual address range reserved when the PE is mapped (https://learn.microsoft.com/en-us/windows/win32/debug/pe-format). Any data in .rsrc contributes to this, regardless of whether it’s touched at runtime.

The Win32 resource APIs (FindResource, LoadResource, LockResource) operate on data already mapped by the loader (https://learn.microsoft.com/en-us/windows/win32/menurc/finding-and-loading-resources). “Loaded on demand” refers only to physical memory paging, which means pages are faulted in when accessed, but the virtual address space is reserved at load time.

Overall, embedding resources always increases SizeOfImage. If your goal is a single EXE without inflating the mapped image, you’d need to append the payload after the PE image and read it manually at runtime.

Answer 2

Yes, embedding a large binary as RCDATA in a Win32 executable will increase the SizeOfImage in the PE header. This is because when you embed data into the .rsrc section, it becomes part of the executable's image. The PE loader maps the entire executable image into memory, and thus the virtual size reflects the total size of all sections, including the resources.

The term "loaded on demand" refers to how resources are accessed in memory. While the resource data is not fully loaded into physical memory until it is specifically requested (using APIs like FindResource and LoadResource), the virtual size of the executable, as indicated by SizeOfImage, will still include the size of the embedded resources. This means that the increase in SizeOfImage is not avoided by the on-demand loading behavior; it pertains to the layout of the executable in memory rather than its physical memory usage.

If your goal is to ship a single executable file, embedding the DLL or large binary as RCDATA is a valid approach, but you should be aware of the increase in the executable size. There are alternatives, such as using a self-extracting archive or a custom installer that packages the executable and the DLL together, but these would not meet the requirement of a single executable file.

---

References:

• Linking an executable to a DLL
• Example C Program: Verifying the Signature of a PE File
• Executable Images
• Building C/C++ Side-by-side Assemblies
• Locating Win32 PE Resources