This was likely a minor linker optimization, and never had a real side effect.įast forward to Windows 10 Creators Update. Since the early days, when the Delphi compiler (and linker) generate a DLL or package library (BPL) by assembling multiple units in a single binary file, and do so by making functions and methods available by creating multiple sections in the export/import table. Any other library or executable referring to it has an import table referring to functions of that export table. In both cases, when the DLL is generated it is has a table of entry points ( export table). On the Windows operating system, dynamic linking (DLLs) support both load-time binding and full runtime binding ( LoadLibrary). Let's start with some background information. But what is happening? The Core Issue: Optimized DLL Loading In general terms, the problem affects all applications that use runtime packages, built with any version of Delphi (recent, old, or even the early ones). In most cases, the slowdown for end user application is relatively limited, however applications with runtime packages on network shares are affected. The issue is affecting applications that use runtime packages (BPL), not applications compiled as a single executable. dpr file i add this : īut still, the compiled EXE file is not showing the correct verinfo.res info.Since Windows 10 Creators Update was released two months ago, we have started seeing reports of issues with runtime package (for example, RSP-17972, where myself, Embarcadero support and R&D have chimed in), mostly while debugging applications. Here is my verinfo.rc file : VS_VERSION_INFO VERSIONINFOĪnd in my. I use the same verinfo.rc model for all my apps and just change the variables for each app (FileVersion, OriginalFileName and so on), but only one of my apps is getting the error.
I'm not new to using an external version info file on my apps. I've been stuck on this issue for the last 4 hours, please help.
0 kommentar(er)
