registrywrapper.cpp

// Licensed to the .NET Foundation under one or more agreements.
// The .NET Foundation licenses this file to you under the MIT license.
// See the LICENSE file in the project root for more information.
//*****************************************************************************
// File: registrywrapper.cpp
//

//
// Wrapper around Win32 Registry Functions allowing redirection of .NET
// Framework root registry location
//
// Notes on Offline Ngen Implementation:
//
// This implementation redirects file accesses to the GAC, NIC, framework directory
// and registry accesses to root store and fusion.
// Essentially, if we open a file or reg key directly from the CLR, we redirect it
// into the mounted VHD specified in the COMPLUS config values.
//
// Terminology:
// Host Machine - The machine running a copy of windows that mounts a VHD to
// compile the assemblies within. This is the build machine in the build lab.
//
// Target Machine - The VHD that gets mounted inside the host. We compile
// native images storing them inside the target. This is the freshly build
// copy of windows in the build lab.
//
// The OS itself pulls open all manner of registry keys and files as side-effects
// of our API calls. Here is a list of things the redirection implementation does
// not cover:
//
// - COM
// We use COM in Ngen to create and communicate with worker processes. In
// order to marshal arguments between ngen and worker, mscoree.tlb is loaded.
// The COM system from the loaded and running OS is used, which means the host
// machine's mscoree.tlb gets loaded for marshalling arguments for the CLR
// running on the target machine. In the next release (4.5) the ngen interfaces
// don't expect to change for existing ngen operations. If new functionality
// is added, new interfaces would be added, but existing ones will not be
// altered since we have a high compat bar with an inplace release. mscoree.tlb
// also contains interfaces for mscoree shim and gchost which again we expect to
// remain compatible in this next product release. In order to fix this, we will
// need support from Windows for using the COM system on another copy of Windows.
// - Registry Accesses under
// - HKLM\software[\Wow6432Node]\policies\microsoft : SQM, Cryptography, MUI, codeidentifiers, appcompat, RPC
// - HKLM\software[\Wow6432Node]\RPC,OLE,COM and under these keys
// - HKLM\Software\Microsoft\Cryptography and under
// - HKLM\Software\Microsoft\SQMClient
// - HKLM\Software[\Wow6432Node]\Microsoft\Windows\Windows Error Reporting\WMR and under
//
// These locations are not accessed directly by the CLR, but looked up by Windows
// as part of other API calls. It is safer that we are accessing these
// on the host machine since they correspond with the actively running copy of
// Windows. If we could somehow redirect these to the target VM, we would have
// Windows 7/2K8 OS looking up its config keys from a Win8 registry. If Windows
// has made incompatible changes here, such as moving the location or redefining
// values, we would break.
// - Accesses from C:\Windows\System32 and C:\Windows\Syswow64 and HKCU
// HKCU does not contain any .NET Framework settings (Microsoft\.NETFramework
// is empty).
// There are various files accessed from C:\Windows\System32 and these are a
// function of the OS loader. We load an executable and it automatically
// pulls in kernel32.dll, for example. This should not be a problem for running
// the CLR, since v4.5 will run on Win2K8, and for offline ngen compilation, we
// will not be using the new Win8 APIs for AppX. We had considered setting
// the PATH to point into the target machine's System32 directory, but the
// Windows team advised us that would break pretty quickly due to Api-sets
// having their version numbers rev'd and the Win2k8 host machine not having
// the ability to load them.
//
//
//*****************************************************************************
#include"stdafx.h"
#include"registrywrapper.h"
#include"clrconfig.h"
#include"strsafe.h"