Coding Sanity

Let's discuss your application being a memory hog. A lot of people think that the CLR will “take care of memory” and that therefore they can just do what they damn well please with RAM. Whilst RAM is looked after very well by the CLR, that doesn't make it an infinite resource. I'm not going to get into disposable resources or GC here, I'm concentrating on memory and it's limits.

How much memory can your application use? You'd think that'd be a simple answer and you'd be wrong. On a 32-bit system simple logic suggests that 4GB is the amount of memory available to us. Well, sort of. However, Windows reserves 2GB of this memory space for itself. Thus, your application can only address 2GB. But, to add insult to injury, .NET steals a fair whack of this as well. The CLR does a lot of things under the hood, and the GC information can take up an awful lot of space. There's no hard and fast rule here, but generally if you stick to under 800MB you should be fine. You'll normally have between 800 MB and 1.2GB available to your application.

So what can you do about this? You can decrease the amount of memory that Windows grabs for itself. This is a two-step process. First you need to boot Windows with the /3GB option set. Secondly, you need to link your app with the LARGEADDRESSAWARE switch. For .NET applications you can set this switch by running the following command:

link -edit -LARGEADDRESSAWARE myApp.exe

from the Visual C++ bin directory.

This will now mean that Windows will only grab 1GB of the 4GB address space, giving your app a corresponding boost in the memory it can use. I haven't tested this myself, but I'd guess that you should now have access to between 1.2GB and 1.8GB.

Of course there is another option. You could just run your app on a 64 bit machine. Now the address space is 8TB. If we assume that Windows munches half of this, and .NET another half you'd still have 2TB of memory available to your app, and 2TB ought to be enough for anyone (shades of BillG's comments about 640KB come leaping to mind).

Given all this, the moment you start thinking about allocating huge amounts of memory (e.g. read an 800MB file into memory), it's time to look at other options. The GC does not make memory an ample resource, it just makes sure that you don't have to worry about freeing it. You still have to have some idea of how big your memory footprint is going to be.

An AppDomain is a unit of code isolation. In Windows 32, the process acts as this unit, where code from one process is stopped by the operating system from accessing code in another process. The only problem is that a process is a very large beast for such a task. Context-switching between processes is expensive and the overhead for having an active process is large.
To circumvent this, the bright sparks at Microsoft have introduced the concept of an Application Domain. Basically this is a lightweight process that exists within an operating system process. Due to the verification that the CLR performs, it can guarantee that code in one AppDomain cannot access code in another directly. As a result we have logical isolation, but not physical.

Now, our happy world is disrupted by a nasty thought. Logical isolation means that each assembly (and it's associated bookkeeping data and static instance data) must be loaded into each AppDomain separately. This makes sense in theory, but can mean a helluva lot of duplication between AppDomains that exist within one process. For this reason domain neutrality was introduced.

What domain neutrality means is that the assemblies which are domain neutral will only be loaded into the process once, and all AppDomains will share a copy. This cuts down unnecessary duplication. However we still get some "duplication" since the data segments are duplicated in order to provide the appearance to our code that the AppDomains have each got their own copy of the assembly. Thus, the static variables of our assembly are not shared across AppDomains, even though the code, JIT images, and lookup tables are.

So what actually happens? Well, when your application starts up, the CLR bootstrapper creates the following:
SystemDomain - responsible for process-wide string interning, creating interface IDs and starting the other AppDomains.
SharedDomain - responsible for managing domain-neutral assemblies. mscorlib is always loaded into this domain.
DefaultDomain - This is where your application plays.

Most applications have only these three AppDomains, but you can create your own at runtime if you wish.

So what is loaded as domain-neutral code? That's a bit trickier. It depends on what option the runtime host used when calling CorBindToRuntimeEx. There's three options here:
STARTUP_LOADER_OPTIMIZATION_SINGLE_DOMAIN - Only mscorlib is loaded domain-neutral.
STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN - All assemblies will be loaded domain-neutral.
STARTUP_LOADER_OPTIMIZATION_MULTI_DOMAIN_HOST - All strong-named assemblies will be loaded domain-neutral.

Interestingly you can actually impact this in your applications execution. When you create an AppDomain, you can specify some options for it's setup, specifically it's LoaderOptimization option. This has four options relating to domain-neutrality: MultiDomain, MultiDomainHost, NotSpecified, SingleDomain.

Surprise, surprise they appear to be the same as the CorBindToRuntimeEx options! Except for that NotSpecified option of course. Well, they are related, the settings you specify for this will override your applications settings for the created AppDomain. The NotSpecified option means that the created AppDomain will use the same setting as the AppDomain that is creating it.

So, what exactly happens if you have different rules between the two AppDomains? How then does the CLR decide whether an assembly is to be loaded domain neutral or not? Each AppDomains settings will apply for that AppDomain. Imagine we have three AppDomains: A, B, and C. A and B will load our assembly domain-neutral, whilst C will load it unshared. This will result in the assembly residing in two places: SharedDomain, and AppDomain C. AppDomain A and B will obviously contain references to the AppDomain in SharedDomain.

Seems simple enough doesn't it? However, there's a hitch. When we load an AppDomain as domain-neutral, all of it's referenced assemblies have to be loaded domain-neutral too. This set of assemblies is referred to as an assemblies binding closure. You might think this would be fine since an assemblies binding closure can't change from AppDomain to AppDomain, right? Wrong. Each AppDomain can have it's own assembly resolution rules.

So where does this leave us? Well, if the binding closures are identical, then all is well and good. However, if the binding closures are different, the CLR will create two copies of our domain-neutral assembly in SharedDomain. Any future AppDomains using this shared assembly will have their binding closures evaluated, and will get a reference to the appropriate copy (or a new copy made).

All this is fun and good, but what impact does it have on you? Well, first off it's a good idea to know what setting your DefaultDomain starts up as. Single Domain is the default .NET setting, whilst ASP.NET uses MultiDomainHost. The next thing to keep in mind is that loading shared assemblies with different binding policies may defeat the purpose of having shared assemblies. The point of shared assemblies is that you're trading a little speed for a smaller memory footprint. If you're throwing away the smaller footprint by having non-shared shared assemblies, then the performance hit isn't going to be worth it.

So how do we work out if an assembly is domain-neutral? Well, in .NET 1.0 and 1.1, you can try and work it out based on knowledge of the assembly coupled with knowing what LoaderOptimization option the AppDomain started with. In .NET 2.0 System.Diagnostics.Loader provides the method AssemblyIsDomainNeutral which will give you this information. In addition .NET 2.0 also provides runtime hosts with much finer grained control than the broad options outlined above. You can implement the GetDomainNeutralAssemblies method of IHostControl to give your host complete control over domain-neutrality.

References: Junfeng Zhang's brilliant article on domain-neutral assemblies, Chris Brumme's article on AppDomains.

• Verifiably type-safe - This has been proven to be type safe.
• Scummy - This code could be doing unspeakable things with your new HDD.

• If it cannot match an assembly automatically, it will not pop up an annoying dialog, it will merely populate the right pane with blank lines.
• There is now an ellipsis button just above the right pane that will bring up a combination framework assembly list/file selection to allow you to select a DLL.
• It will now remember the last 20 manual matches, so if you commonly diff one assembly to a specific location, and choose the right pane item for it, it will open it automatically next time. Manual matches obviously override automatic matches so if you want to diff mscorlib 1.1 to System.Data 2.0, it'll keep that link.
• The bug where sometimes the panes did not resize to fill the diff tool is now fixed.
• Scroll synchronisation has been improved.

• .NET is supposed to be a complete Framework
• The .NET components call into non-.NET components & libraries
• Not everything Microsoft has ever written has been ported to .NET yet

• #define LOOP while(1)
• #define class struct
• #define private public
• #define protected public
• void QSort_Pnts ( LsA _B, LsA _E ) { if ( _E <= _B ) return; LsA B = _B - 1, E = _E + 1 ; int Pnts = ( * _B )->Pnts ; LOOP { while ( ( * ++ B )->Pnts > Pnts ); while ( E >= B && ( * -- E )->Pnts < t =" *" b =" *" e =" T">

• A fast service running on a single server.
• A 30% slower service running on two load balanced servers.

I've started reading and posting on Usenet, and have come across a few whiny gripes about .NET that really get up my nose. Since I'm trying to be civil, I have restrained my righteous wrath in my posts, but need to blow off my steam.

Here goes!

Why is .NET so big?
Um, why is Java so big? Why is Linux so big, Windows? They're all platforms. They contain everything needed to run programs that do useful things. Java and .NET sit on top of other platforms, and call into said base platforms to do most of this stuff. However, they still have an awful lot of code to make said platforms services appear more OO. Plus, they both add all sorts of funky code that is separate from the platform. Plus, they provide funky JITters to ensure that your code will be optimized for the machine it's running on rather than the machine it was compiled on. Plus, they provide all sorts of little goodies like GC and reflection that are not provided by the base platform.

So then, why is .NET 10MB bigger than Java? Well, that would be due to MS's OWBIS (One Whomping Big Install Strategy) as opposed to Java's MBIS (Multiple Big Install Strategy). I'm not too clued up on Java, but from what I understand, things like Enterprise Beans and most of the decent UI libraries are not shipped with the basic Java install. With .NET you get Enterprise Services, Windows Forms, ASP.NET and the kitchen sink all together.

Why can't I just statically link my libraries?
Well, there are actually tools that allow this, but there are two good reasons not to. One's a bit superfluous though. The superfluous one is space & bandwidth. What's smaller?
1) 1 x 25MB file + 15 100K files
2) 15 x 2,100K files (2MB of framework linked to each file)

If a person is only going to use the library in one program, then statically linking makes the most sense. However, I've heard from a very unreliable source that the MS vision is going to be changed to "craploads of .NET programs in every home". If they all statically-linked the BCL, hope to hell that TB hard drives become affordable soon.

The biggest reason, in my opinion, is security. To be precise, Code Access Security (CAS). For those of you who may have slept through .NET boot camp, this is the funky little creature that stops your programs working. Or, to be more correct, stops scummy untrusted code from violating your computer in unspeakable ways.

Hmmm, but what's untrusted code? Well, it's code that either can't prove it's parentage, or comes from a shady background. The kind of code you'd be unhappy about your daughter dating in other words. Now, before you load up that shotgun, keep in mind that the code could actually be very good, trustworthy code. But how would you know? One way would be to establish it's background, another would be to give it only a little rope to hang itself with. .NET does a combination of both.

It allows the untrusted code to call and use libraries that are trusted. In other words it lets the code take your daughter out to restaurants where you're friends with the owner. It doesn't let your code do untrusted things, like calling Windows API's directly, or performing COM Interop, or taking your daughter to Lovers Lane.

Now here's a question (and where my analogy breaks down), how does it know that a library is trusted? Well, said library must be digitally signed for starters. If you can't tell if the library has been changed, then trusting that library is a bit silly. The library must also come from a reputable background. Alternatively the library must have been explicitly trusted. Now, if the library is trustworthy as well as trusted, it'll make sure that code calling it has an appropriate amount of trust before allowing said call to happen. A great example is System.Windows.Forms. It allows untrusted code to do things like show Common Dialogs. Internally System.Windows.Forms uses the Win32 API to do these things. Since System.Windows.Forms is trusted, this is allowed, and the framework trusts the library to ensure that untrusted code doesn't do something daft or dangerous.

So now your untrusted code is allowed to call trusted libraries that may or may not allow certain actions dependent on the untrusted codes permissions. The more trusted your code is, the more the libraries will allow it to do. I'm not going to get into evidence, which is how the Framework decides what level of trust to give your code. Partly because it's boring, partly because my daughter anology will help you grasp the concept, and mostly because I slept through that section of the documentation. Twice.

But what does all this have to do with static linking I hear you cry? Well, if we were to allow you to statically link in portions of trusted assemblies, and ship them as part of your code, how could it stay trusted? You can't sign it, because you don't have the private keys used to sign the assembly. Giving out said private keys would be tantamount to removing CAS from .NET. So, the library components you linked into your application would have to have the same level of trust as your application. If your application is untrusted, that means no PInvoke or COM Interop. So we can kiss showing dialogs, windows, messageboxes and suchlike goodbye. Bingo with console output, file access, and network connectivity. We couldn't allow it too much processor time, or too much RAM. So basically what your program would be able to do is take data hard coded into it, do some operations with it, and toss the result away. Not terribly useful.

Whew! I'm writing an essay, and I'm still not finished my ranting.

1. Whatever happens, it's not our fault, it's yours. No matter what.
2. You thought this product belongs to you, but it doesn't, it's ours and we're just letting you use it for a while.
3. We're going to tell you what you may and may not do with thise product, since it's not yours we can give you any instruction we like.
4. We don't trust you at all, not one iota. But you can trust us, promise.
5. We hate your guts and wish you were dead.

• Provide easy to understand EULA's (or if you have to have a long EULA, summarize it above the main body).
• If you're only leasing software, make sure that this is made very clear to the customer up front. Dishonesty will only breed unhappy customers (and irate blog entries).
• Make sure that the legally purchased software can be up and running on the users PC within minutes of the installation completing.
• Don't force users to do things they may not wish to do (except pay of course ;D). Suggest the best course of action, and make it easy to do what you want them to do, but forcing them just makes some customers irritated.
• If you're going to sell your software outside of the First World, keep in mind the fact that very few Third World users have dial-up, let alone broadband.
• Keep in mind that many people consider applications that quietly send information to the seller to be spyware, no matter how little information is sent. Also keep in mind that some of those users have firewalls that tell them that your program is being sneaky and underhanded.

• Calculate total A by adding the figures in the odd positions i.e. the first, third, fifth, seventh, ninth and eleventh digits.
  
• Calculate total B by taking the even figures of the number as a whole number, and then multiplying that number by 2, and then add the individual figures together.
  
• Calculate total C by adding total A to total B.
  
• The control-figure can now be determined by subtracting the ones column from figure C from 10.
  
• Where the total C is a multiple of 10, the control figure will be 0.

I broke one of the main rules of programming the other day. I'm writing a control which will host a COM control. Now, this COM control has a very chatty interface. So I thought, why not write an ATL shim between my .NET control and this COM control that will handle the chatty aspects. and only pass up the important stuff. So, I duly went along and spent a week and a half implementing this C++ shim.

Now the problem is that while I knew each Interop call would cost me cycles, and I knew that there were quite a few Interop calls, I hadn't profiled the problem. I came to my senses a couple of days ago, and wrote a pure .NET version in just a couple of days. Profiled the two, and what do you know, the performance differential between them is miniscule. Turns out that most of the chattiness is at startup and teardown, and much less during operation.

A typical example of premature optimization. You can't reliably know what's going to be the performance critical sections until you profile the system. I should have written in .NET, profiled it, and if there were bottlenecks, optimized those.

Just as another little performance tip with Interop. The main library I was using was MSHTML. It turns out that an awful lot of my startup time was going in loading this gigantic Interop library: 7.63MB, or almost 3 times the size of mscorlib. That's a lot, and all I needed was a subset. A little scratching around on the Web, a bit of Reflector, and all of a sudden I had the interfaces I wanted in 152KB. This is quite a useful trick when dealing with Interop. The Primary Interop Assembly is not an all or nothing proposition.

When using Reflector to look at interop assemblies, it's worth noting that Reflector puts property get accessors before property sets, so if you're using it as a guide, make sure that you check the IDL for the correct ordering.