Closed atsvetkov closed 6 years ago
Thanks for this -- sorry for the delay in reviewing the PR. It looks good, but I would appreciate if you could make sure it indeed works. You can test by running Sysinternals VMMap on the msos.exe process. If it shows a 4GB virtual address space (look at the Total row in the table) then the binary change worked. @atsvetkov
Ok, with this knowledge I found out it didn't work, the reason being the MSBuild targets execution order: Kirill's package assumes a less sophisticated build configuration and runs after CoreCompile
target, while in msos there are also Fody steps happening after that and effectively creating a single new executable, without the header set.
I have added a custom target into the .csproj file, so that it now runs after FodyTarget
task, which results in the required header set on the final executable (msos.exe).
Verified this in two ways:
Running VMMap on the executable built in Release/x86 configuration shows about 3.6GB of free memory available to the process:
Running dumpbin.exe /headers "path/to/msos.exe"
reports that the executable is large-address-aware as well:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\SDK\ScopeCppSDK\VC\bin>dumpbin /headers "C:\Users\Alex\Documents\github\atsvetkov\msos\msos\bin\x86\Release\msos.exe" Microsoft (R) COFF/PE Dumper Version 14.00.23506.0 Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file C:\Users\Alex\Documents\github\atsvetkov\msos\msos\bin\x86\Release\msos.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES 14C machine (x86) 3 number of sections 5A11E956 time date stamp Sun Nov 19 21:28:06 2017 0 file pointer to symbol table 0 number of symbols E0 size of optional header 122 characteristics Executable Application can handle large (>2GB) addresses 32 bit word machine
So, now it seems to actually work.
Excellent! Thanks for verifying this. Merging now.
Instead of determining where to find
editbin.exe
locally depending on VS version, I hope I found a more elegant solution: LargeAddressAware Nuget package by Kirill Osenkov (sources are here). Since this is only required for 32-bit builds, I have added this condition when setting the<LargeAddressAware>
property, which triggers the execution of the tool.I don't really know how to verify the resulting executable, but at least I tested that it the tool from the package is indeed being run according to this logic. Funnily enough, verifying this was made super-easy by virtue of MSBuild Structured Log Viewer, built by Kirill Osenkov too. :) So, thanks to him!