x86 assembler in .NET?

No, it's not possible - at least, not directly - to write inline ASM and call into it the way you can in C/C++. That was never a requirement for me, however - I just want something I can use to write ASM code and have it translated to a byte stream.

I'm one step closer today, thanks to Alex Lyman (whose blog is still under construction - I'll update later with a link) who answered my StackOverflow.com question with his X86Writer library.

Now I can write code like this:

    1 byte[] bytes;

    2 

    3 using (MemoryStream ms = new MemoryStream()) {

    4     X86Writer writer = new X86Writer(ms, new IntPtr(0x00400a00));

    5 

    6     var start = writer.CreateLabel();

    7     var func = writer.CreateLabel(new IntPtr(0x01000000));

    8 

    9     start.Mark();                                // start: 

   10 

   11     writer.Inc32(X86Register32.EAX);              // inc eax 

   12     writer.Cmp32(X86Register32.EAX, 5);           // cmp eax 05 

   13     writer.Jmp(X86ConditionCode.NotEqual, start); // jne start 

   14     writer.Call(func);                            // call 01000000 

   15 

   16     bytes = ms.ToArray();

   17 }

Really great stuff! I'd still like to be able to pass in a string, though - but this gives me a great platform on which to build!

Notice the support for labels - this really is the start of a powerful library, I think. Oh - and he open-sourced it under the New BSD License - which means everyone's free to contribute. If you have anything you want to add, please send me a patch!

Configuration via IConfigurationSectionHandler

So I had an 'oh wow!' moment today - one of our application's requirements is to integrate with several shipping carrier APIs. My goal of course is to keep this as generic as possible - the application should not have any knowledge of the individual shippers, and should communicate with them via a single ShippingService implementation.

So far, so good - I've managed to unify the API of these disparate web services, but I had run into a stumbling block regarding how to configure these. After several false starts, my team lead suggested implementing IConfigurationSectionHandler. At first I balked (silently) - I can't stand dealing with 2.0 style Xml DOM objects, which IConfigurationSectionHandler uses - but after getting over myself I decided to take a look.

And I'm glad I did - IConfigurationSectionHandler is a *very* simple interface, exposing only a single method:

public object Create(object parent, object configContext, XmlNode section) {...}

For my purposes, 'parent' and 'configContext' weren't necessary - I only needed to concentrate on the 'section' argument. Implementing this was, as I expected, a bunch of Xml DOM code - but it wasn't so bad since the xml I'm working with is very simple.

One of my self-inflicted requirements was to keep the individual shipping carriers in separate assemblies, mostly to make adding a new carrier a no-rebuild operation. I want to be able to create the shipping carrier, drop its assembly into our Bin folder, add a configuration element, and go. So I made use of Assembly.Load to load the assembly in question, and Activator.CreateInstance to create an instance of the concrete carrier implementation. The constructor for the abstract Carrier type takes an IDictionary<string, string> of configuration properties (also gathered through my IConfigurationSectionHandler implementation) which the individual carrier will make use of - things like web service urls, etc.

I am in awe of how easy it was for all this to come together - it took maybe 2 hours, including MSDN browsing, to go from 0 knowledge of the problem to a working implementation that I'm comfortable putting into our production system.

Fun stuff! =)

ASP.NET MVC Preview 5, jQuery, and Validation

I've been given an interesting task - figure out how to provide both client-side and server-side validation of forms, without duplicating the validation logic.

The ASP.NET MVC team just released Preview 5, which, among other bits of goodness, includes the ability to perform server-side validation automagically, and have the results of this validation sent to the view. It's pluggable, much like the rest of the framework.

Meanwhile I went in search of a validation framework (admittedly so I wouldn't have to write my own) and found ValidationFramework - which upon inspection appears to be exactly what I need for server-side validation. It's a well-put-together framework, and has an extensibility model that includes outputing client-side validation for ASP.NET using server controls.

Of course, ASP.NET server controls aren't the best solution when working with the MVC framework, so I considered writing my own adapter layer to generate some Javascript validation from the existing validation rules. I remembered the jQuery Validation plugin and, while I haven't explored it fully, considered that a good starting point.

Well, it seems I wasn't the only one to think so, as this discussion thread shows. I've been in contact with the original poster - Dane O'Connor - and have been reviewing the latest drops of a set of helpers and extensions on both ASP.NET MVC P5 and ValidationFramework that achieves exactly what I initially set out to do on my own!

Now I just have to hope that I'll be allowed by my employer to contribute some code to this project, as we'll be using the system in a production environment. Any improvements we provide would benefit others as well, and since the code is free, I'd like to give something back.

That's it for now.