Michał Cierniak : Rotor - all

Secure CRT

michaljc — Mon, 03 Jan 2005 04:27:00 GMT

One of the cool new things we are doing in the security push is the conversion of all uses of potentially unsafe CRT (C Runtime) functions to their new, safe counterparts. When we think of unsafe CRT functions, we usually think of string manipulation functions and these functions are probably indeed responsible for most of the security bugs
(For a few examples of what can go wrong with the traditional string manipulation functions, read this post) but there are other improvements in the CRT libraries. As mentioned on MSDN the main categories of improvement in CRT are: parameter validation, sized buffers, null termination, enhanced error reporting, file system security, Windows security, and format string syntax checking.

Resources
For a great introduction to Secure CRT, read this article by Michael Howard. A list of secure CRT functions with short descriptions and links to longer articles is available in the Whidbey section of MSDN. Secure CRT is also mentioned by another blogger. A clever way of using templates to avoid typing the extra parameter when the compiler can deduce it itself is described here.

Rotor
Secure CRT functions are being discussed in the context of the ISO/IEC standard for C (in JTC1/SC22/WG14). You can read the submission and the Security TR Editor's Report online. However, since these functions have not been added to the C standard yet and we want to compile Rotor Whidbey on non-Windows platforms, we will include implementations of some of the secure CRT functions in the Rotor distribution. Our current plan is to include only as much as we need for Rotor, so this will not be a complete implementation.

Open Source Courses for .NET

michaljc — Sun, 24 Oct 2004 02:05:00 GMT

Open source courses based on .NET are a great resource both for creating courses at other universities and for people who simply want to use the materials to learn something on their own about either .NET in general or Rotor. I know of two such courses available today from the University of Linz in Austria (Johannes Kepler Universität Linz):

Application Development with C# and .NET. I am posting this before I had time to fully explore the web site but apparently there are 700 slides worth of presentations (equivalent to 30 45-minute lectures, in German and English), 200 exercises with sample solutions, a larger case study and references to books that have been written for the course (books are also both in German and English).
Compiler Construction. Again, I haven’t actually read any of this yet but this seems to be a very cool compiler class with over 300 slides and a case study of a complete compiler for Z# (I’ve never heard of Z# and I assume that it must be a language of the level of complexity appropriate for a compiler class).

Other .NET-related materials are available on a companion web site.

Rotor benchmarks

michaljc — Tue, 20 Jul 2004 04:21:00 GMT

To date there has been no standard set of benchmarks that do something meaningful, run on Rotor and execute long enough to enable performance measurements. Standard benchmarks are very important for publishing research results because they make easier to understand what applications are being presented in a given paper. Ben Zorn from MSR has just published two benchmarks. Hopefully, this is just a start and either Ben or others will put together more applications, so that we have a benchmark suite of 5-10 applications that can be used by all researchers looking into .NET.

The two benchmarks available today are lcsbench and ahcbench. Lcsbench is a front end of C# compiler written in C#. Ahcbench is an implementation of Adaptive Huffman Compression. Both benchmarks include three inputs of various sizes that achieve different execution times.

Do you know of other nicely packaged benchmarks for .NET? Do they run on Rotor? Let me know!

IVNET'05

michaljc — Sat, 29 May 2004 01:51:00 GMT

IVNET’05 (Conference of Innovative Views of .NET Technologies) is another conference related to CLI. Its scope is actually much larger but the CFP lists a few areas relevant to my Rotor blog. The two most obvious ones are programming languages and CLI implementations. IVNET’05 will be held in Porto, Portugal in June 2005.

Slides from MSR Academic Days in Portugal

michaljc — Fri, 28 May 2004 22:50:00 GMT

I returned yesterday from the MSR Academic Days. These events were quite interesting. Organizers of the event in Portugal made the slides used for presentations available on-line.

Slides for my Rotor presentations are there. In addition to Rotor, the presentation also mentions Semiworks and Phoenix at a very high level (two slides for each of these projects).

There are also other interesting presentations there: Don Syme about innovation in .NET. Damien Watkins had three talks: about Comega (Comega has its own web site), multi-language programming and .NET in teaching. Bruno Cabral talked about RAIL. Ivan Medvedev talked about Security in CLR. Other talks were not about .NET but they were all good (some talks were in Portuguese, so I didn't listen to them myself but I heard they were good).

Rotor RFP2 recipients

michaljc — Tue, 18 May 2004 14:13:00 GMT

As mentioned earlier, we have the final list of researchers awarded grants for proposed work related to Rotor. The list is now public. Check it out: there are many very exciting projects there.

A servicing update of Rotor

michaljc — Sat, 15 May 2004 02:38:00 GMT

Jan has just announced that he created a project with the modifications needed to build and run Rotor on versions of MacOS, FreeBSD and Windows that were released since Rotor was shipped. This servicing project is available at http://servicing.sscli.net

The following new OS versions are supported:

Windows XP SP2
Windows Server 2003
Mac OS X 10.3 (Panther)
FreeBSD 5.2

Rotor talks at MSR Academic Days in May

michaljc — Wed, 12 May 2004 04:29:00 GMT

I will be giving talks about Rotor next week in Vilamoura in Portugal and the week after that in Barcelona in Spain. If you are interested in Rotor and will be around there, let me know even if you will not attend these events.

Rotor BOF notes

michaljc — Tue, 11 May 2004 02:36:00 GMT

Last Thursday I went to the Birds-Of-A-Feather session about Rotor at the Virtual Machine (VM'04) conference. There were over a dozen attendees. Most people haven't done much work with Rotor yet and they were there out of curiosity. I managed to write down names of most but not all of the participants. If I missed you and you want to be included, please let me know.

John Gough had handouts of the newly written Appendix D for his book. This part talks about unsafe code and unmanaged data.
Neal Glew from Intel talked about their experiences integrating a new JIT and GC into Rotor. This work will be presented at the .NET workshop in a few weeks.
Lingli Zhang, a graduate student from UCSB, is considering using Rotor for her thesis.
Deepak Chandra, a grad student from UC Irvine, is considering using Rotor for his information flow work.
Mark Lewin from MSR was helping me present the winners of the Rotor RFP2. A few people asked for a link to a web page with that list but I think that it's not available yet (I will try to find out). The list of RFP1 winners is online.
Yahya Mirza announced a workshop he's organizing for OOPSLA.
Tarek Abdelrahman from the University of Toronto, Hans Boehm from HP and a few others were just listening.
Gil Tene and Ivan Posva from Azul Systems were asking questions about Pinvoke and interop with native code and wrote down the info I showed them about pinvoke.net and Adam Nathan's .NET and COM book.

Rotor BOF at the VM'04 conference in San Jose

michaljc — Mon, 03 May 2004 05:34:00 GMT

I wanted to remind you about the Birds-of-a-Feather session devoted to Rotor at the VM'04 conference this week. The BOF is scheduled for Thursday, May 6, 7:30 p.m.–10:00 p.m. You can find a description at http://www.usenix.org/events/vm04/bofs.html. The BOF is co-organized by John Gough, Peter Drayton and me. For those who cannot attend, I will write a short report after the BOF.

CLR loader and fusion

michaljc — Thu, 15 Apr 2004 08:02:00 GMT

One of the interesting features of CLR is the ability to control which version of a given assembly is used by an application. This mechanism is quite powerful and I thought I would create a concrete simple example to illustrate the basic concepts.
My example uses at the same time three different policies: application, publisher and administrator. Alan Shi wrote a very good article about these three policies.
I will assume that you have read this article or have otherwise knowledge when each of these policies should be used. I will merely demonstrate an example that will use all three policies.
If you want to learn more about fusion and the loader, you can have a look at three blogs written by Alan Shi, Suzanne Cook and Junfeng Zhang. Nice examples are also presented in Chapter 4 of the SSCLI Essentials and in Chapter 2 of Essential .NET, Volume 1.

Everything I present here applies to the product CLR and Rotor (except that the specific location of the machine config file is different) but it's great to use Rotor because you can look at the code that implements every piece of what I will demonstrate. To see how it is all implemented, look around the files in the clr\src\fusion\binder directory of the Rotor distribution. I include specific pointers to the source code at the end of the article.

Let's go to the example. Since we will place multiple versions of the same assembly in the GAC, we have to use a strongly named assembly. First we have to generate the key pair:
C:\michal\projects\binding>sn -k foo.snk

Key pair written to foo.snk

Now, we'll create a very simple assembly signed with the key we just produced:
C:\michal\projects\binding>type foo.cs
[assembly: System.Reflection.AssemblyKeyFile("foo.snk")]
[assembly: System.Reflection.AssemblyVersion("1.0.0.0")]

public class Foo {
static int version = 1;
public void M() {
    System.Console.WriteLine("I'm foo version {0}", version);
}
}
A simple application will first use reflection to print the full assembly name of our component including its version number and then will call into that component:
C:\michal\projects\binding>type app.cs
public class App {
static void Main() {
    System.Console.WriteLine("Using " + typeof(Foo).Assembly.FullName);
    Foo f = new Foo();
    f.M();
}
}

Now let's compile both the component and the app and run it:
C:\michal\projects\binding>csc -t:library foo.cs
Microsoft (R) Visual C# Shared Source CLI Compiler version 1.0.0003
for Microsoft (R) Shared Source CLI version 1.0.0
Copyright (C) Microsoft Corporation 2002. All rights reserved.

C:\michal\projects\binding>csc app.cs -r:foo.dll
Microsoft (R) Visual C# Shared Source CLI Compiler version 1.0.0003
for Microsoft (R) Shared Source CLI version 1.0.0
Copyright (C) Microsoft Corporation 2002. All rights reserved.

C:\michal\projects\binding>clix app.exe
Using foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479
I'm foo version 1

Note that if you repeat the experiment, you will see a different value for the PublicKeyToken. It is important that you use your value of the token in all places in this article where I ask you to type the public key token.

So far, so good. Now, we will place our component in the GAC, so that we can have multiple versions side by side:
C:\michal\projects\binding>gacutil -i foo.dll

Assembly successfully added to the cache

Now let's create versions 2 of the assembly, and place it in the GAC. We will modify the source file as follows and execute same commands as before to compile the component and add it to the GAC:
C:\michal\projects\binding>type foo.cs
[assembly: System.Reflection.AssemblyKeyFile("foo.snk")]
[assembly: System.Reflection.AssemblyVersion("2.0.0.0")]

public class Foo {
static int version = 2;
public void M() {
System.Console.WriteLine("I'm foo version {0}", version);
}
}
C:\michal\projects\binding>csc -t:library foo.cs
Microsoft (R) Visual C# Shared Source CLI Compiler version 1.0.0003
for Microsoft (R) Shared Source CLI version 1.0.0
Copyright (C) Microsoft Corporation 2002. All rights reserved.

C:\michal\projects\binding>gacutil -i foo.dll

Assembly successfully added to the cache

Let's run our application again:
C:\michal\projects\binding>clix app.exe
Using foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479
I'm foo version 1

It still uses version 1. Now imagine that the version 2 is a newer, better version and we would like to make our app use it but we have no access to the source of the app and we can't recompile it to link with the new version of foo.dll.

We will try various policies to make our app use the new version of the component. Let's start with the application policy. The application policy is specified by creating a configuration file that is placed in the same directory as the application. The config file must have the same name as the application with the .config suffix. Here's what I put in the config file for our example:
C:\michal\projects\binding>type app.exe.config
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="foo"
        publicKeyToken="8847c0fffaada479"
               culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
                 newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
As you can guess, this policy says that if the application requests foo.dll,version 1, the loader should load version 2 instead. Let's see if it worked:
C:\michal\projects\binding>clix app.exe
Using foo, Version=2.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479
I'm foo version 2

That was easy, right? Now let's assume that a yet newer version, version 3, of the component is developed and the author of the component wants to make sure that all users of version 2 will start using version 3. This can be accomplished with the publisher policy. Let's first create version 3 of our example and place it in the GAC using same direction as for creating version 2 but typing "3" instead of "2" in the obvious places in foo.cs.
This publisher policy is specified by creating an assembly with a name of the form policy.[major].[minor].[component name]. For our example, it is policy.2.0.foo.dll to specify that it works for all requests to load version 2.0 of foo.dll. The syntax for the policy is the same as for the application policy:
C:\michal\projects\binding>type publisher.config
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="foo"
        publicKeyToken="8847c0fffaada479"
               culture="neutral" />
<bindingRedirect oldVersion="2.0.0.0"
                 newVersion="3.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

We link the policy file as a resource into an assembly with the required name.
C:\michal\projects\binding>al /link:publisher.config /out:policy.2.0.foo.dll /keyf:foo.snk /v:2.0.0.0
Microsoft (R) Shared Source CLI Assembly Linker version 1.0.0003
for Microsoft (R) Shared Source CLI version 1.0.0
Copyright (C) Microsoft Corporation 2002. All rights reserved.

C:\michal\projects\binding>gacutil -i policy.2.0.foo.dll

Assembly successfully added to the cache

C:\michal\projects\binding>clix app.exe
Using foo, Version=3.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479
I'm foo version 3

We're running our unmodified application that requests foo.dll version 1. The application policy redirects the request to foo.dll version 2 and the publisher policy kicks in to redirect this request to foo.dll version 3.

The last policy I will write about it the administrator policy. Assume that we have a yet another version of our component. For our experiment we will simply replace "3" with "4" in foo.cs; recompile it and place in the GAC like we did before to create versions 2 and 3.

The administrator policy is placed in the CLR-wide configuration file. For Rotor, this file is %TARGETCOMPLUS%\config\machine.config
You can edit this file and add there the redirection from version 3 to version 4. The syntax is again the same as for the other policies, so you will need:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="foo"
        publicKeyToken="8847c0fffaada479"
               culture="neutral" />
<bindingRedirect oldVersion="3.0.0.0"
                 newVersion="4.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Place this text, say, at the end of the machine.config file, right before the </configuration> tag.

C:\michal\projects\binding>clix app.exe
Using foo, Version=4.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479
I'm foo version 4

Now we have chained three policies that redirect the requests from version 1 to 2, to 3 and to 4. Typically, you would not use all three policies for the same assembly but I wanted to demonstrate that it is possible. The policies are always consulted in the order presented in this article: application policy first, followed by publisher and followed by the administrator policy.

Finally, let's verify that all 5 assemblies created by us are present in the GAC:
C:\michal\projects\binding>gacutil -l

The Global Assembly Cache contains the following assemblies:
foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479, Custom=null
foo, Version=2.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479, Custom=null
foo, Version=3.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479, Custom=null
foo, Version=4.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479, Custom=null
policy.2.0.foo, Version=2.0.0.0, Culture=neutral, PublicKeyToken=8847c0fffaada479, Custom=null

(other assemblies omitted from the output)

If you want to see how this is implemented in Rotor, you may start with a debugger. Using windbg, start our application (type "windbg clix app.exe") and set a breakpoint in function ApplyPolicy in fusion.dll (type "bp fusion!ApplyPolicy").
ApplyPolicy is called first for "System" and then for "foo". To make sure that you're looking at the interesting invocation of ApplyPolicy, you may want to verify that local variable pwzAsmName (once it's initialized) points too "foo" (this is a Unicode string).
Interesting local variables are pwzVerAppCfg, pwzVerPublisherCfg and pwzVerAdminCfg with the obvious meaning associated with them. Happy hacking!

Annotations for Rotor source files (9) - clr/src/inc

michaljc — Fri, 05 Mar 2004 03:38:00 GMT

This is the last post giving brief summaries of .h files in the clr/src/inc directory of the Rotor distribution. As usually whenever the file contains a good summary in a comment, I simply quote the comment here, otherwise I write new notes to capture the contents of the file. Comments that are copied verbatim from the source file are distinguished by a font.

stgpool.h

Comment:
// Pools are used to reduce the amount of data actually required in the database.
// This allows for duplicate string and binary values to be folded into one
// copy shared by the rest of the database. Strings are tracked in a hash
// table when insert/changing data to find duplicates quickly. The strings
// are then persisted consecutively in a stream in the database format.
In-memory format used for the metadata heaps.

stgpooli.h

Comment:
// This is helper code for the string and blob pools. It is here because it is
// secondary to the pooling interface and reduces clutter in the main file.
Hash functions and get/put packed length

stresslog.h

Defines STRESS_LOG0 and STRESS_LOG1 which are defined to be nops in Rotor.

strongname.h

Comment:
// Wrappers for signing and hashing functions needed to implement strong names

switches.h

Comment:
switch configuration of common runtime features

threadpool.h

Constants for the thread pool.
Comment in the file is incorrect.

timeline.h

Comment:
// Simple timed manual event log, for profiling purposes.

timer.h

Comment:
// This module contains the CTimer class which will time events and keep
// running totals. This class will first try to use a high performance
// counter if the system supports it. This type of counter is much more
// accurate than the system clock. If the system does not support this, then
// the normal clock is used. The total time is returned

tpoolfnsp.h

Used like opcode.def. Declares thread pool functions through the STRUCT_ENTRY macro.

utilcode.h

Comment:
Utility functions implemented in UtilCode.lib.

utsem.h

Utility semaphors and locks.

vererror.h

Comment:
definitions of data structures, needed to report verifier errors

warningcontrol.h

Comment:
Header file to globally control the warning settings
Not widely used

winwrap.h

Comment:
This file contains wrapper functions for Win32 API's that take strings.

wsinfo.h

Not used in Rotor

wsperf.h

Comment:
// This is the internal interface for collecting and logging dynamic data
// allocations and deallocations. There is two kinds of data collected
// summary and detailed. Summary data gives a summary of of allocations made
// from various heaps (e.g. Highfrequency, Low frequency heap etc.). Summary
// data also includes number of common data structures allocated e.g. MethodDescs
// etc.

xmlparser.h

Defines the COM interface IXMLParser and related interfaces
Generated from an IDL file not included in the Rotor distribution

__mscoree_file__.h

Identification info put in resource files

Annotations for Rotor source files (8) - clr/src/inc

michaljc — Wed, 25 Feb 2004 02:40:00 GMT

palclr.h

Comment:
// Various macros and constants that are necessary to make the CLR portable.

palstartup.h

Comment:
// An implementation of startup code for Rotor's Unix PAL. This file should
// be included by any file in a PAL application that defines main.
// palstartupw.h is the Unicode version of this file.
Wraps user's main with a call to PAL_initialize and sets PAL_Terminate via atexit.

palstartupw.h

See palstartup.h

perfcounterdefs.h

Comment:
// Internal Interface for CLR to use Performance counters
Defines the shapes of perf counter blocks as they might appear in shared memory

perfcounters.h

Comment:
// Internal Interface for CLR to use Performance counters
Defines API to access counters and update them.

perflog.h

Comment:
// Internal interface for logging perfromance data. Currently, two types of logging
// formats are supported, Pretty print for stdout and perf automation friendly
// format.

pesectionman.h

Comment:
// Section Manager for portable executables
// Common to both Memory Only and Static (EXE making) code

posterror.h

PostError loads a resource string for a given error, fills it in using the equivalent of sprintf and generates an IErrorInfo via ICreateErrorInfo interface. Sets the current error to that value by calling SetErrorInfo.

prettyprintsig.h

Defines PrettyPrintSig which is used in ildasm and PrettyPrintSigInternal which is used internally to compute GUIDs for types for use in COM interop.

profilepriv.h

Helper structs, enums, variables and functions for the profiling API

querybinding.h

Comment:
// Query binding macros for internal use in mscoree.
Not used in Rotor.

regdisp.h

Arch-dependent but OS-independent struct representing register state and accessor functions.

safegetfilesize.h

Comment:
// This provides a wrapper around GetFileSize() that forces it to fail
// if the file is >4g and pdwHigh is NULL. Other than that, it acts like
// the genuine GetFileSize().

setupcodes.h

Comment:
// This file contains the errors that the Setup and related tools return
Not used in Rotor

shimload.h

Comment:
// Sets/Gets the directory based on the location of the module. This routine
// is called at COR setup time. Set is called during EEStartup and by the
// MetaData dispenser.

sighelper.h

Comment:
// This file defines the helpers for processing signature

stacktrace.h

Not used in Rotor.

stdmacros.h

Portability macros and formatting macros for logging

Annotations for Rotor source files (7) - clr/src/inc

michaljc — Thu, 19 Feb 2004 02:30:00 GMT

jitperf.h
- Comment:
  // Internal interface for gathering JIT perfmormance stats. These stats are
  // logged (or displayed) in two ways. If PERF_COUNTERS are enabled the
  // perfmon etc. would display the jit stats. If ENABLE_PERF_LOG is enabled
  // and PERF_OUTPUT env var is defined then the jit stats are displayed on the
  // stdout. (The jit stats are outputted in a specific format to a file for
  // automated perf tests.)
- A nop in Rotor v1.
log.h
- Comment
  // Logging Facility
- Usage is described in html docs for Rotor.
loglf.h
- Defines categories of things to log.
- See log.h and the html docs.
machine.h
- Defines DWORD and QWORD. Optionally includes windows.h etc.
md5.h
- Comment:
  // A pretty-darned fast implementation of MD5
mdcommon.h
- Comment:
  // Common header file for both MD and COMPLIB subdirectories
- Notes:
  1. Defines an enum for file formats
  2. Defines strings (A & W) of metadata stream names.
member-offset-info.h
- Defines MEMBER_OFFSET_INFO: appends _member_offset_info to its argument
- See dump-tables.cpp. This file defines structs that are declared as friends of various data structures.
metadata.h
- Comment:
  // Common includes for EE & metadata internal. This file contains
  // definition of CorMetaDataScope
- Definitions of internal metadata APIs (COM-based) and their supporting structs and enums.
metadatatracker.h
- In Rotor stubbed out.
metamodelpub.h
- Internal definitions of the metadata tables. See ECMA CLI Partition II.
mscorcfg.h
- A trivial XML parser for config files.
mscoree.h (not in tarball)
- Generated from mscoree.idl
nativevaraccessors.h
- Comment:
  // The following are used to read and write data given NativeVarInfo
  // for primitive types. Don't use these for VALUECLASSes.
- Related to ICorDebugInfo. Used by the impl of the Debugger API.
nsutilpriv.h
- Comment:
  // Helpers for converting namespace separators.
- E.g. splitting a string into a namespace and name.
openum.h
- Defines enums opcode_t (using opcode.def) and opcode_format_t.
opinfo.h
- Defines types that implement the IL opcode decoder.
outstring.h
- Comment:
  /* A simple, lightweight, character output stream, with very few
  external dependancies (like sprintf ... ) */

Annotations for Rotor source files (6) - clr/src/inc

michaljc — Sun, 15 Feb 2004 02:57:00 GMT

fuspriv.h (not in tarball)

Like other *.idl files, it is copied from palrt/idl
Unlike other files generated from idl, this one doesn't have a corresponding idl file anywhere in the tarball.

gchost.h (not in tarball)

Comment:
* Common Language Runtime Profiling interfaces
*
* The IGCHost allows a host environment to get statistics about the
* garbage collector as well as to gain some limited control over collections.
* This interface can be QueryInterface'd for on from the CorHost object.
Generated from gchost.idl

guidfromname.h

Defines two GUID generators: CorGuidFromNameW, CorIIDFromCLSID

holder.h

Comment:
// Various resource Holders
//
// General idea is to have a templatized class who's ctor and dtor call
// allocation management functions. This makes the holders type-safe, and
// the compiler can inline most/all of the holder code.
None of the types declared in this file seems to be used.

hrex.h

Comment:
HR <-> SEH exception functions.
Examples: ThrowHR, ThrowError

iceefilegen.h

An implementation is in ceefilegen.cpp. Parts of the interface dealing with signatures are deprecated in that implementation.
Forwards to CeeFileGenWriter

ilformatter.h

This is dead as are ilformatter.cpp and opinfo.[h,cpp].

il_kywd.h

Comment:
// COM+ IL keywords, symbols and values
//
// This is the master table used in ILASM (asmparse.y)
// and ILDASM (dis.cpp)
// symbols and values are defined in asmparse.y
// and not used in dis.cpp
Notes:

Lexemes for ilasm and ildasm.
Used like opcode.def

internaldebug.h

Comment:
// This is internal code for debug mode which will turn on memory dump checking
// and other settings. Call the api's according to:
// _DbgInit On startup to init the system.
// _DbgRecord Call this when you are sure you want dump checking.
//_DbgUninit Call at process shutdown to force the dump.
Notes:

In Rotor all of these are nops.
_DbgRecord sets a variable that is never used.

intrinsic.h

Comment:
// Force several very useful functions to be intrinsic, which means that the
// compiler will generate code inline for the functions instead of generating
// a call to the function.
A very short list of intrinsics we are asking the MS C++ compiler to inline