LoadLibrary refactoring (#20841)
authorSwaroop Sridhar <Swaroop.Sridhar@microsoft.com>
Mon, 12 Nov 2018 19:56:18 +0000 (11:56 -0800)
committerJan Vorlicek <janvorli@microsoft.com>
Mon, 12 Nov 2018 19:56:18 +0000 (20:56 +0100)
commit214c3b62d889b2ff57425ab3f4ce70adf7503be6
tree6e58e67bf9a78bd0ade030d615bf57cbc3959baa
parent853a01279327163b099fdd70d1c04d8aaf61f772
LoadLibrary refactoring (#20841)

* Refactor LoadLibrary Methods

This change refactors the code in DllImport in preparation
for implementing the new NativeLibrary API here:
dotnet/corefx#32015

The two main changes are:

1) A change in the semantics of the internal LoadLibrary helper functions.

When a native library is loaded, there are two categories of callers
expecting different return values:

External callers like AssemblyNative::InternalLoadUnmanagedDllFromPath()
and the upcoming System.Runtime.Interop.Marshall.LoadLibrary()
need the raw system handle
Internal callers like LoadLibraryModule() need the PAL registered handle
This change modifies the internal LoadLibraryModule* methods to work
in terms of native system handles, so that external callers can obrain
them directly. Methods requiring PAL-handles can register them explicitly.

There is no change in external signature of DllImport class, or the
native Dll cache in AppDomain class.

2) Differentiate HMODULE and NATIVE_LIBRARY_HANDLE

This change defines NATIVE_LIBRARY_HANDLE type to represent
raw system handles to native libraries that are not registered
with the PAL (On Unix systems).

The types on PAL and DlImport methods are adjusted to make
this semantic distinction explicit.

*
Fix loading LibC via PAL_LoadLibraryDirect()
src/inc/palclr_win.h
src/pal/inc/pal.h
src/pal/src/loader/module.cpp
src/vm/assemblynative.cpp
src/vm/dllimport.cpp
src/vm/dllimport.h