Changes between Version 1 and Version 2 of WindowsDynamicLinking

Timestamp:

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

Author:

Phyx-

Comment:

Updated for review.

WindowsDynamicLinking

@@ -111 +111 @@
 it is not needed.
 
+=== Misc ===
+The following are some important pieces of the puzzle.
+
+==== ''build-dll-win32.sh'' ====
+The DLL compiling logic Is implemented in this shell script. This script should be used to compile libraries on Windows (The Makefiles have
+been updated to point to this shell script on Windows.). This script will automatically split a DLL is needed without any extra user action needed.
+
+The resulting libraries can also be used as if they were not split without any special treatment.
+
+==== ''compiler/main/Manifest.hs'' ====
+Contains the new logic for manifest files. Coincidentally, SxS manifest do allow for an RPATH like functionality.
+By using config files (which cannot be embedded in the exe) you can specify probing paths for SxS searches.
+
+{{{
+<!-- <appname>.exe.config -->
+<configuration>   
+  <windows>
+    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
+      <probing privatePath="bin;..\bin" />
+    </assemblyBinding>
+  </windows>
+</configuration>
+}}}
+
+Unfortunately according to MSDN you are limited to a laughable 9 entries..
+
+==== ''driver\utils\dynwrapper.c'' ====
+As with Linux, a dynamic GHC on Windows is a wrapper. However unlike Linux it's not a shell script
+but a driver exe. The main application is compiled into a dll named *application.exe.dll* and the
+wrapper loads this dll and sets the search path for libraries.
+
+This process is driven by ''rules\build-prog.mk''.
+
 ==== Runtime selection ====
 The last remaining hurdle is that of runtime selection. Currently at link time a runtime is picked by the compiler to compile the libraries with.
@@ -136 +169 @@
 All the RTS versions should have the same ABI so that shouldn't be an issue.
 
+Delay 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
+go through a function. The overhead can be minimized somewhat by always inlining these accessor functions. This is a limitation of the delay load mechanism.
+
+When 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
+data would end up referencing the address of the trampoline instead of the actual data behind it.
+
 During 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`
 and all the DLLs since they are all in the same process space as the `exe` and so will inherit the search path.