Month: May 2004

Time flies when a house is being built..

While in reality it’s only been a few months since I first mentioned I was having a new house built, in my mind it’s been decades.  I’m quite anxious to move into the new place, and all the waiting around is agonizing to say the least.  Aside from the fact that I will be saving about an hour a day on my commute, there is something to be said for actually having the house built that *you* wanted.  Start with nothing, and then end up with a house.  It’s an interesting proposition.

Of course, then you have all of ‘Nothing’.  And you have this ‘nothing’ for what seems like a long time.

Then all of a sudden, you have a foundation down!

So you’d think that with something going on, you’d be happy..  Like, WOOHOO! Something’s going on!  But that’s not really what happens.. Instead you’re thinking “Man, what’s taking so long! Aren’t they done yet?!!“  Maybe that wouldn’t be so bad, but it’s only been 15 minutes since the foundation was down..

Next thing you know, they’re actually building a structure.

Then it becomes maddening.  You can phsyically see the thing there, and you still can’t do anything but wait..  It is quite awesome to see it coming together piece by piece (”Hey, if you imagine a wall right here, I’m gonna put my tv right there!”), and one of the ‘coolest’ experiences i’ve had, but there’s still two months left before it’s done and i’ll be able to move in.

I’m convinced these two months will take at least another 8 years to get here.

Hey, it is difficult to write a book?

Ever since I published my first book, this question seems to come up a lot.  In all honesty, I asked that same question a few times to other author’s I knew before I wrote that book.  Now that my second book is coming out in a few short weeks, I figured I’d write a bit about these experiences.

First, let me point out that the differences between writing the first book and the second book were enormous.  The basic things I was hearing when I was asking around about writing a book was that it was a major time sync.  It was difficult, and time consuming.  Yet minor things like weren’t going to deter me!

For anyone who knows me, they probably know that I’m verbose.  I tend to ‘type’ a lot, and many times they think it’s just because I like to read the words I’m thinking on screen.  For me, writing the first book wasn’t difficult at all.  I found the experience rewarding, and while not something I would consider ‘easy’, given my knowledge of the subject, and my knack for rambling on while writing, it just seemed to come naturally.

The second book on the other hand, was much more difficult.  For one, my real job beckoned, and the little free time I had when writing the first book basically disappeared.  It doesn’t matter how good of an author you are, you suck if you can’t write.  Then, when you only have a short period of time any given day or week to write, you barely get anything written.  Then with long stretches between writing sessions, you forget where you were in your train of thought, and have to go back and re-read the last sections you’ve already written to get back into the writing mode.

So, to answer the underlying question, I suppose the best answer is ‘It depends!’. If you have a passion for writing and know you’ll have the time to dedicate to writing (at least an hour or two a night, 3-5 days a week), then no, not really.  On the other hand, if you lack those two things, it can be a taxing experience to say the least.

It’s definitely not something I regret, let me tell you that much.

So you say that startup time is slow?

One of the first things that people may notice when they’re running managed applications is that the startup time is slower than a ‘native’ application.  Without delving into details, the major cause for this ‘slow down’ is the actual compilation that needs to happen (called JIT – Just in time compiling).  Since the managed code has to be compiled into native code before it’s executed, this is an expected delay when starting the application. Since Managed DirectX is built on top of this system, code you write using the Managed DirectX runtime will have this behavior as well.

Since the JIT compilation can do a lot of optimizations that just can’t be done during compile time (taking advantage of the actual machine the code is running on, rather than the machine it was compiled on, etc.) the behavior here is desired, the side effects (the slowdown) is not.  It would be great if there was a way to have this cost removed. Luckily for us, the .NET Framework includes a utility called NGen (Native Image Generator) which does exactly this.

This utility will natively compile an assembly and put the output into what is called the ‘Native Assembly Cache’, which resides within the ‘Global Assembly Cache’.  When the .NET Framework attempts to load an assembly, it will check to see if the native version of the assembly exists, and if so, load that instead of doing the JIT compilation at startup time, potentially dramatically decreasing the startup time of the application using these assemblies.   The downsides of using this utility are two-fold.  One, there’s no guarantee that the startup or execution time will be faster (although in most cases it will be – test to find out), and two the native image is very ‘fragile’.  There are a number of factors which cause the native images to be invalid (such as a new runtime installation, or security settings changes). Once the native image is invalid, it will still exist in the ‘Native Assembly Cache’, and never be used.  Plus, if you want to regain the benefits, you’ll need to ngen the assemblies once more, and unless you’re watching closely, you may not even notice that the original native assemblies are now invalid.

If you’ve decided you would still like to ngen your Managed DirectX assemblies, here are the steps you would take:

  • Open up a Visual Studio.NET 2003 Command Prompt Window
    • If you do not wish to open that command window, you could simply open up a normal command prompt window, and ensure the framework binary folder is in your path.  The framework binary folder should be located at %windir%microsoft.netframeworkv1.1.4322 where %windir% is your windows folder.
  • Change the directory to %windir%microsoft.netManaged DirectX, where %windir% is your windows folder.
  • Go into the folder for the version of Managed DirectX you wish to ngen from here (the later the version, the more recent the assembly).
  • Run the following command line for each of the assemblies in the folder:
    • ngen microsoft.directx.dll (etc)
    • If you’re command prompt supports it you may also use this command line instead:
      • for /R %i in (*.dll) do ngen %i

If you later decide you did not want the assemblies compiled natively, you can use the ngen /delete command to remove these now compiled assemblies.

  • Note that not all methods or types will be natively compiled by ngen, and these will still need to be JIT’d.  Any types or methods that fall into this category will be output during the running of the ngen executable.