Changes between Version 1 and Version 2 of WindowsDynamicLinking

Oct 13, 2016 6:26:03 PM (3 years ago)

Updated for review.


  • WindowsDynamicLinking

    v1 v2  
    111111it is not needed.
     113=== Misc ===
     114The following are some important pieces of the puzzle.
     116==== '''' ====
     117The DLL compiling logic Is implemented in this shell script. This script should be used to compile libraries on Windows (The Makefiles have
     118been updated to point to this shell script on Windows.). This script will automatically split a DLL is needed without any extra user action needed.
     120The resulting libraries can also be used as if they were not split without any special treatment.
     122==== ''compiler/main/Manifest.hs'' ====
     123Contains the new logic for manifest files. Coincidentally, SxS manifest do allow for an RPATH like functionality.
     124By using config files (which cannot be embedded in the exe) you can specify probing paths for SxS searches.
     127<!-- <appname>.exe.config -->
     129  <windows>
     130    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
     131      <probing privatePath="bin;..\bin" />
     132    </assemblyBinding>
     133  </windows>
     137Unfortunately according to MSDN you are limited to a laughable 9 entries..
     139==== ''driver\utils\dynwrapper.c'' ====
     140As with Linux, a dynamic GHC on Windows is a wrapper. However unlike Linux it's not a shell script
     141but a driver exe. The main application is compiled into a dll named *application.exe.dll* and the
     142wrapper loads this dll and sets the search path for libraries.
     144This process is driven by ''rules\''.
    113146==== Runtime selection ====
    114147The last remaining hurdle is that of runtime selection. Currently at link time a runtime is picked by the compiler to compile the libraries with.
    136169All the RTS versions should have the same ABI so that shouldn't be an issue.
     171Delay loading will require some changes to GHC, specifically static const data can no longer be just referenced from the DLL. To get the data you have to
     172go through a function. The overhead can be minimized somewhat by always inlining these accessor functions. This is a limitation of the delay load mechanism.
     174When delay loading there are no more entries in the '.idata' section and everything goes through a trampoline which loads the DLL on demand. Obviously referencing
     175data would end up referencing the address of the trampoline instead of the actual data behind it.
    138177During compilation of a `.exe` we can then set the search path using `AddDllDirectory` to allow the loader to pick the correct `RTS` variants for the `.exe`
    139178and all the DLLs since they are all in the same process space as the `exe` and so will inherit the search path.