• cbrumme's WebLog

    Initializing code

    • 5 Comments
    A common question is how to initialize code before it is called. In the unmanaged world, this is done with a DLL_PROCESS_ATTACH notification to your DllMain routine. Managed C++ can actually use this same technique. However, it has all the usual...
  • cbrumme's WebLog

    Inheriting from MarshalByRefObject

    • 8 Comments
    Developers often wonder why they are forced to derive from MarshalByRefObject or EnterpriseServices.ServicedComponent. It would be so much more convenient if they could add a CustomAttribute to their class or use a marker interface to declare that...
  • cbrumme's WebLog

    Interface layout

    • 3 Comments
    The CLR has two different techniques for implementing interfaces. These two techniques are exposed with distinct syntax in C#: interface I { void m(); } class C : I { public virtual void m() {} // implicit contract matching } class D...
  • cbrumme's WebLog

    Turning off the garbage collector

    • 7 Comments
    It is not generally possible to turn off garbage collection. However, the garbage collector won’t run unless “provoked.” Garbage collection is triggered by: 1) Allocation 2) Explicit calls by the application to System.GC.Collect 3) Explicit...
  • cbrumme's WebLog

    Managed objects and COM

    • 10 Comments
    All managed objects other than those derived from ServicedComponent, when exposed to COM, behave as if they have aggregated the free threaded marshaler (FTM). In other words, they can be called on any thread without any cross-apartment marshaling...
  • cbrumme's WebLog

    Static Fields

    • 4 Comments
    By default, static fields are scoped to AppDomains. In other words, each AppDomain gets its own copy of all the static fields for the types that are loaded into that AppDomain. This is independent of whether the code was loaded as domain-neutral or...
  • cbrumme's WebLog

    Request a topic

    • 30 Comments
    If there's a topic related to the CLR, feel free to drop me a line asking me to talk about it. I have a very time-consuming day job and a full life outside of work, so expect a long delay before I address your topic. Or I might feel I have nothing...
  • cbrumme's WebLog

    Unhandled exceptions

    • 11 Comments
    There are two kinds of threads executing inside managed code: the ones we start in managed code and the ones that wander into the CLR. The ones that started in managed code include all calls to Thread.Start(), the managed threadpool threads, and...
  • cbrumme's WebLog

    Virtual and non-virtual

    • 3 Comments
    The CLR type system supports both virtual and non-virtual instance methods. And IL can contain both CALLVIRT and CALL instructions. So it makes sense that IL generators would call virtual methods using CALLVIRT and call non-virtual instance methods...
  • cbrumme's WebLog

    Security and Asynchrony

    • 5 Comments
    In a comment to my last ramble, about asynchronous execution and pinning, someone asked for advice on using Windows impersonation in a managed application. Unfortunately, the managed platform currently has poor abstractions and infrastructure for controlling...
  • cbrumme's WebLog

    DLL exports

    • 1 Comments
    People often ask how they can expose traditional DLL exports from managed assemblies. Managed C++ makes it very easy to export functions. And you could use tricks like ILDASM / ILASM to inject DLL exports into managed assemblies built with other...
  • cbrumme's WebLog

    Hyper threading

    • 5 Comments
    If the operating system schedules multiple threads against a hyper-threaded CPU, the CLR automatically takes advantage of this. This is certainly the case for new versions of the OS like Windows Server 2003. Also, the CLR did work to properly...
  • cbrumme's WebLog

    Why don't metaobjects marshal by reference?

    • 4 Comments
    Objects that derive from MarshalByRefObject will marshal by reference rather than value. Metaobjects like Assembly, Type and MethodInfo do not derive from MarshalByRefObject. This is because we don’t want Type to be marshal by ref, which implies...
  • cbrumme's WebLog

    Surprising 'protected' behavior

    • 4 Comments
    There’s a subtle but important difference between protected access in unmanaged C++ and protected access (i.e. family) in the CLR. The difference is due to the CLR’s ability to build security guarantees on top of type safety. Imagine you had a...
Page 2 of 2 (39 items) 12