Archive

Author Archive

Testable Web UI IV: YUI Test (plus a bit of mocking)

February 16th, 2009
Comments Off

So, last time, I was trying to write a test around requesting some JSON data from a service, and return it. Unfortunately, JsUnit is not up to the task of handling asynchronous logic at all, so I decided to ditch it in search of greener pastures.

Having spent some time working with YUI in the past, I settled on trying YUI Test out.

It took some finagling, but I successfully managed to convert my first test over to the new testing framework. It’s got quite a lot of boilerplate, so I won’t inline it, but you can see it here.

Now that we’ve regained lost ground, time to try what we were doing before. Here’s my test:

testCanRequestJson : function() {
    var self = this;
    asyncRequestJson('getStats.json', function(result) {
        self.resume(function() {
            Assert.areEqual('andy', result.name);
            Assert.areEqual(9999, result.hit_points);
            Assert.areEqual(1, result.kickboxing);
            Assert.areEqual(99, result.linear_algebra);
            Assert.areEqual(99, result.cross_stitching);
        });
    });

    self.wait();
},

The way it works is that the “self.wait();” call tells the testing framework to wait until a corresponding “self.resume(fn).” If the resume doesn’t come within a few seconds, the test fails. It’s a bit ugly, but it does the job admirably, and I don’t know how you’d do it better without fibres or coroutines or something, so I’m not about to complain too loudly.

This is great, as it demonstrates I can interact with the network in a sensible way, but it’s kind of annoying that I have to have an extra data file just to make the test run. I think it’s fine for a functional test like this, but I don’t want to have to write functional tests for everything.

The next step is to plug these values into my widget. Here’s my test:

testWidgetIsPopulated : function() {
    var grueStats = {
        name:"Grue",
        hit_points:1,
        kickboxing:1,
        linear_algebra:0,
        cross_stitching:99999
    };

    var net = new FakeNetwork();
    var sw = new StatusWidget('avatar-1',
        function (url, onComplete) { return net.asyncRequestJson(url, onComplete); }
    );

    net.completeRequest('getStats.json', grueStats);

    Assert.areEqual("Grue", sw.getName());
    Assert.areEqual(1, sw.getHitPoints());
    Assert.areEqual(1, sw.getKickboxingScore());
}

FakeNetwork? Whassat? It’s this:

function FakeNetwork() {
    this.requests = {};
}

FakeNetwork.prototype = {
    asyncRequestJson : function(url, onComplete) {
        this.requests[url] = onComplete;
    },

    completeRequest : function(url, result) {
        this.requests[url](result);
        delete this.requests[url];
    }
};

Simple, yes? This way, I don’t have to actually have a JSON service for every little thing, and I don’t have to worry about asynchronous results or network funkiness. Win!

Tomorrow, I will do some badly-needed refactoring, and lay out what the future direction of the design should be.

Source code

Uncategorized ,

Testable Web UI III: XMLHttpRequest, and the Limits of JsUnit

February 15th, 2009
Comments Off

Last time, I started building an HTML widget to display a character’s status for some hypothetical RPG. This, in short, involved getting JsUnit going, sketching out the general jist of what it ought to look like, and an initial sanity test to ensure that some baseline of functionality was rigged correctly: we have a widget that can, if given a div ID on a page, return what the currently displayed name and statistics are.

A grand start, but nothing that resembles useful code just yet. Next, let’s see if we can make this service query a web service to populate the statistics.

The first thing I did was to do some quick Googling to learn how to do this. Thus armed, I cheated and wrote an implementation first:

function getStats(url, onComplete) {
    var req = new XMLHttpRequest();
    req.onreadystatechange = function() {
        if (req.readyState == 4) {
            if (req.status == 200) {
                var result = jsonParse(req.responseText);
                onComplete(result);
            } else {
                throw new Error("Request failed: " + req.status);
            }
        }
    }

    req.open('GET', url, true);
    req.send(null);
}

jsonParse comes from some random bit of code that I found on the internet that parses JSON.

And the test:

function testRequestStats() {
    getStats('getStats.json', function(result) {
        assertEquals('andy', result.name);
        assertEquals(9999, result.hit_points);
        assertEquals(1, result.kickboxing);
        assertEquals(99, result.linear_algebra);
        assertEquals(99, result.cross_stitching);
    });
}

Now, to actually make this test work, I need to write a JSON “service:”

{"name":"andy","hit_points":9999, "kickboxing":1,"linear_algebra":99,"cross_stitching":99}

Yay, green bar, right? Not quite: I cheated and wrote the implementation first, which means that I have never seen this test go red. Sure enough, breaking the test still nets me a green bar.

So, what gives? After doing a bit of debugging using Firebug, I’ve come to the conclusion that the test is not waiting for my asynchronous callback to finish! What’s worse, JsUnit doesn’t provide any solution to this problem at all, and the ad-hoc solutions suggested by other developers are all terrible.

Well, screw this. I’m only a few days in, so I’m going to find another testing library.

Tomorrow, I’ll try YUI Test out.

Uncategorized

Testable Web UI II: JSUnit

February 14th, 2009
Comments Off

Last time, I talked about the hypothetical allure of small, fast, reliable, parallelizable unit tests, and embarking on something of a research project to get a feel for what it’s like to test-drive an HTML interface.

The first thing to do is pick a project, I have bad product sense, no imagination, and an unhealthy fixation on games, so I’m going to go with a character details widget for some hypothetical RPG. That means that our requirements lie somewhere along these lines:

  • I want to see my character’s picture, name, and statistics
  • I want to be able to pick some equipment for my character
  • I want to see how my character’s equipment affects its statistics

Second, here are my rules:

  • I am not going to go into details with respect to the backend at all. That is a subject that warrants a completely different discussion on its own.
  • I am only going to worry about FireFox 3. Making web applications that run on all major browsers is important, but I am primarily interested in learning how to test drive a web application that works, not learning how to write a compatible web application.
  • Full disclosure: I do not have much background in HTML/CSS/JS, so if you see me do something that looks stupid, it’s probably because I’m doing something stupid.

The first thing I always look for when coding in an unfamiliar language is an xUnit. Fortunately, there is a such a thing as JsUnit, so I didn’t have to go long without having something to install and set up. There was some weirdness surrounding Firefox’s security restrictions around JavaScript running from the local machine: I hacked around it just by setting up an Apache server on my workstation.

Since we are talking about a user interface here, I’m going to start with some markup:

<div id="avatar-1" class="avatar">
    <div class="name">andy</div>
    <img class="avpic" src="avatar.png" />
    <div class="details">
        <div class="hitpoints_panel">HP:
            <span class="hit_point_score">5</span>
        </div>
        <div class="kickboxing_panel">Kickboxing:
            <span class="kickboxing_score">6</span>
        </div>
        <div class="linear_algebra_panel">Linear Algebra:
            <span class="linear_algebra_score">7</span>
        </div>
        <div class="cross_stitching_panel">Cross-stitching:
            <span class="cross_stitching_score">8</span>
        </div>
    </div>
</div>

One thing I do know is that node IDs have to be unique across the whole page, so I’m going to take a swing at avoiding them for things that do not really, really need to be uniquely identified. We’ll see how that pans out.

I haven’t even written any JS yet, but I’m staring at that blob of crap that I just dumped into my own lap, and I’m already worried that anything I code will be riddled with bugs caused by me fudging up the DOM. The first tests I want to write will simply be testing that I can affect the display properly:

<html>
<head>
    <script language="JavaScript" type="text/javascript" src="jsunit/jsUnitCore.js"></script>
    <script language="JavaScript" type="text/javascript" src="StatusWidget.js"></script>
    <script type="text/javascript">
        function testCanFetchHitPoints() {
            var sw = new StatusWidget("avatar-1");
            assertEquals(5, sw.getHitPoints());
        }
    </script>
</head>
<body>
    ... that thing I pasted up above ...
</body>
</html>

Now that I have a blob of HTML as a piece of data to hang my StatusWidget on, and a red test, all I have to do is make it pass:

StatusWidget = function(id) {
    this.id = id;
};

StatusWidget.prototype = {
    getHitPoints : function() {
        var xpath = "//div[@id='" + this.id + "']//*[@class='hit_point_score']";
        var i = document.evaluate(
            xpath, document, null, XPathResult.ANY_TYPE, null
        );
        var e = i.iterateNext();
        return parseInt(e.innerHTML);
    }
};

Green bar means victory! Now I follow through and write tests to ensure that the rest all work. Normally, this might be considered redundant and pointless, but I don’t expect my markup to stay as-is forever, and I just know I’ll want to know when (not if) I go and screw the basics up.

function testCanFetchStats() {
    var sw = new StatusWidget("avatar-1");

    assertEquals("andy", sw.getName());
    assertEquals(5, sw.getHitPoints());
    assertEquals(6, sw.getKickboxingScore());
    assertEquals(7, sw.getLinearAlgebraScore());
    assertEquals(8, sw.getCrossStitchingScore());
}

And the adjusted implementation:

StatusWidget.prototype = {
    __getChild : function(className) {
        var xpath = "//div[@id='" + this.id + "']//*[@class='" + className + "']";
        var i = document.evaluate(
            xpath, document, null, XPathResult.ANY_TYPE, null
        );
        return i.iterateNext();
    },

    __getInt : function(className) {
        return parseInt(this.__getChild(className).innerHTML);
    },

    getName : function() {
        return this.__getChild("name").innerHTML;
    },

    getHitPoints : function() {
        return this.__getInt("hit_point_score");
    },

    getKickboxingScore : function() {
        return this.__getInt("kickboxing_score");
    },

    // etc
}

It works, so I’m pretty confident that I’ve reached some sort of baseline level of functionality. Next time, I will try pulling the statistics themselves from a web service. (and mocking!)

Source code

Uncategorized

Testable Web UI: Part I

February 13th, 2009
Comments Off

One of the things that I spend an awful lot of time thinking about at IMVU is testability. I am always interested in finding ways to write tests that are faster, simpler, and more reliable. Once your tests reach a certain size, the return on investment you get by improving the performance of your tests increases linearly, until it’s just too valuable to pass up. You can push the problem off somewhat by investing in hardware, and you can save quite a lot of engineer-muscle by doing this, but there’s eventually going to be a point where you just can’t resist looking for some way to shave just a few percentage points off your top-line test time.

At IMVU, our tests fall into a few basic categories. Some tests are pure PHP logic. Some are PHP logic that also interacts with MySQL, Solr, or a number of other external services. Others still use Selenium to drive an actual instance of Internet Explorer. (we also have a whole slew of tests for our 3D client, but they run on a separate buildslave cluster)

One idea that I find particularly intriguing is sacrificing acceptance tests in favour of unit tests. Unit tests are small, reliable, fast, and, while they don’t have the same kind of guaranteed real-world applicability as a full-system acceptance test, and you probably don’t want to trust them to catch unexpected regressions, it turns out that you can get quite a lot of mileage out of a sufficiently large swarm of them. Real unit tests can also be run one per thread on a dualcore machine for twice the effective performance. (and really, who even has a single-core CPU these days?)

The set of constraints placed upon frontend web tests is formidable:

  • The tests have to be fast
  • The tests have to be race-free on a platform that is built entirely on stateless, asynchronous I/O
  • The tests have to run on whatever browsers your customers use, because every browser has subtle quirks that will randomly break your code
  • Most web developers aren’t used to the idea of letting tests dictate the structure of their markup or scripts

Some of these issues are engineering culture problems. Some of these requirements are directly in conflict with each other, while others are, think, poorly understood and categorically dismissed as intractable problems that must be endured.

Just to pick one example, Internet Explorer 7 may be the world’s most popular browser, but it also has one of the slowest current-generation JavaScript engines. In particular, there are certain Selenium operations that run hundreds of times slower in IE than they do in Firefox. On the other hand, IE7 does certain things very differently from Firefox, and failing to take those differences into account can have catastrophic results.

So it seems that the choice is to sacrifice realism by testing on a faster browser, or to sacrifice speed to actually catch issues that will impact customers.

So, with all this in in mind, I believe that it is perfectly reasonable to structure your web frontend as two major classes of tests:

  • Frontend unit tests that do not touch the network. These tests can run on a fast JavaScript engine (like Firefox, or maybe even Chrome).
  • Full-blown acceptance tests that exercise everything (including the backend). Since these guys are the last line of defense, I’m pretty sure we really do have no choice but to run them on IE7.

I have found no shortage of literature and experience surrounding unit testing in general, and similarly, nobody is terribly confused about how to write effective acceptance tests. Within the specific field of test driving HTML interfaces, however, I have found precious little. So, in my next few posts, I am going to do a little bit of research, and share it all with the you, my adoring reader(s), as I go.

Next, I will talk about what I am going to try to build and my testing setup. (squeeeee project time!)

* I am endlessly entertained by my vivacious vocabulary. Also, alliteration is awesome!

Uncategorized

Random Thoughts about Adopting TDD

February 12th, 2009
Comments Off

There are plenty of folk who have realized that test-driven development is an amazing way to deliver better code faster. One of the claims I hear from a lot of places is that you should strive to unit test everything. Unit tests are fast and small and super reliable, and we all want that, right?

Sure do, but if you are trying to testify an existing project, it’s going to be really bloody hard to get to the point where you can write real unit tests at all, and they are by no means the only kinds of tests you’ll want anyway.

Adopting TDD in an existing project, with an existing team is generally very difficult not only because you have to acclimate your company culture, but because whatever code you’ve got is not written test-first.

Instead of going whole hog on pure unit tests, you can get a huge part of the benefit at a fraction of the cost simply by sucking up the speed hit (and reliability) by writing functional tests instead. In a desktop game, that may mean constructing the entire app and prodding it with windows messages. On the server, you might just want to try setting up engineer workstations as tiny production-clones and allowing your tests to connect to an actual database.

Whatever the application, figuring out this bit of technology gives you what you need to instate what I consider to be the first important engineering policy that will turn your company culture the right way: wherever possible, bugs should not be considered to be fixed until they have regression tests. Acceptance tests are easy to intuitively grasp, so it should be relatively easy to eliminate repeat bugs this way.

Further, this approach saves you some momentum in the short run: figuring out how to write code that can be unit tested is hard and will take some time. Bugfixes are perfect targets for this effort simply because the feature already broke. Instead of (well, in addition to, I suppose) committing to abstract pontification about what kind of tests you need for some new feature that customers have never seen, you have a certifiable, concrete weakness in your software. All you have to do is write a tiny program that asserts that it no longer exists.

If you can nail this, you have gotten your foot in the proverbial door. You will probably have gnarly, unreliable tests that are a pain to deal with for awhile, but you have them, which puts you in a position of learning how to make them better.

Uncategorized

Using C++ Macros to Inline Annoying, Repititious Crap

February 11th, 2009
Comments Off

One of the neat things the IMVU client has is balls-awesome crash handling. We do a number of things to ensure that, any time our client crashes for any reason, that we find out as much as we can about them. This serves a bunch of purposes: we use the raw number of crashes to determine whether or not we have broken something, and we use all the information we can get out of the crashes (stack traces, memory dumps, log files, and the like) to fix them.

One of the tricks to testing crash handling is that you can’t really do it without crashing. :) To that end, we have a large array of functions that exist only to crash our client. Moreover, we have parameterized them on the context in which we would like the crash to occur: with Python on the stack, without, from a WndProc, from within an exception handler, and so forth

This would be a terrible source of duplicated code, but for a satanic little trick that you can do with the C preprocessor. Since I’m such a nice guy, I’ll even tell you what it is right up front, so you can skip the rest of this post if you want:

Macros can be macro arguments.

Here’s how it works:

First, we’re going to define a list of crashes, using the C preprocessor:

#define CRASH_LIST(F)               \
    F(WriteToNull)                  \
    F(ReadFromNull)                 \
    F(JumpToNull)                   \
    F(CallPureCall)                 \
    F(ThrowFromExceptionHandler)    \
    F(DestroySun)

Weird, right? Right. Now, the first thing we have to do with all of these crashes, is declare functions in a header file:

#define DECLARE_CRASH(T)       \
    void T();

CRASH_LIST(DECLARE_CRASH)

Next, we need to declare functions that crash within a WndProc:

#define DECLARE_WNDPROC_CRASH(T)       \
    void T ## InWndProc();

CRASH_LIST(DECLARE_WNDPROC_CRASH)

Then, we need to implement the crashes themselves:

void WriteToNull() {
    *((int*)0) = 1234;
}

/* etc */

Yeah, we can’t use the fun macro trick this time. :( You can’t win them all, I guess. Next, crashing in WndProc:

HWND createCrashWindow() { /*this is boring win32 gook */ }

LRESULT crasherWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    if (msg == IMVU_WM_CRASH) {
        void (*crashFunc)() = reinterpret_cast<void (*)()>(wParam);
        crashFunc();
        return 0
    } else {
        return DefWindowProc(hWnd, msg, wParam, lParam);
    }
}

void crashInWindow(void (*crashFunc)()) {
    HWND hWnd = createCrashWindow();
    PostMessage(hWnd, IMVU_WM_CRASH, reinterpret_cast<WPARAM>(crashFunc), 0);
}

#define IMPLEMENT_WNDPROC_CRASH(T)  \
    void T ## InWndProc() {         \
        crashInWindow(&T);          \
    }

CRASH_LIST(IMPLEMENT_WNDPROC_CRASH)

And lastly, we need to be able to call all of these functions from Python:

#define IMPLEMENT_BOOST_PYTHON_CRASH(T)    \
    def(#T, &T);                        \
    def(#T "InWndProc", &T ## InWndProc);

CRASH_LIST(IMPLEMENT_BOOST_PYTHON_CRASH)

Now, I’ll be the first one to wail in terror at how theoretically terrible the C preprocessor is, and what it does to maintainability, but, in this case, at least, the payoff is undeniable: with very small effort, and without having to build some kind of “CrashRegistry” framework, we can add additional crash cases to our client.

Uncategorized

Ghetto Closures in Win32 with C++ III: Templates and Traits and Interfaces, oh my!

February 10th, 2009
Comments Off

Hey kids! It’s that time again.

Last time, we went over generating a tiny ASM thunk that could wrap a C++ method pointer (instance plus function) up in a non-method __stdcall function pointer, suitable for use as, say, a win32 WndProc.

Next, I’m going to talk about wrapping it all up in a convenient API. To do this, we’re going to need some template-fu.

Since I am using a modern compiler, I am going to see how close I can get to boost.function‘s interface:

boost::function<void ()> fn = &someFunction;

I consider this interface to be pretty rad.

boost::function works with only a single template argument, so we could go that route too. We could also accept that we’re doing something a bit different, and add a second parameter:

Thunk<LRESULT (Window::*)(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)> wndProcThunk;

or

Thunk<Window, LRESULT (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)> wndProcThunk;

I picked the first one, mostly because it was the first thing that popped into my head. Here is my test harness:

#include <cstdio>
using std::printf;

struct I {
    virtual void print() = 0;
    virtual void printSum(double y) = 0;
};

struct C : I {
    C(int x)
        : x(x)
    { }

    void print() {
        printf("My x is %in", x);
    }

    void printSum(double y) {
        printf("%i + %f = %fn", x, y, x + y);
    }

    int x;
};

void main() {
    C instance(4);

    Thunk<void (I::*)()> thunk(&instance, &I::print);
    printf("n");
    thunk.get()();

    Thunk<void (I::*)(double)> thunk2(&instance, &I::printSum);
    printf("n");
    thunk2.get()(3.14);
}

First, I extracted the part of the code that actually constructs and cleans up the generated code. Everything else I’ll outline will just be scaffolding so that the interface is prettier.

template <typename D, typename S>
D really_reinterpret_cast(S s) {
    char __static_assert_that_types_have_same_size[sizeof(S) == sizeof(D)];

    union {
        S s;
        D d;
    } u;

    u.s = s;
    return u.d;
}

template <typename C, typename M>
void* createThunk(C* instance, M method) {
    char code[] = {
        0xB9, 0, 0, 0, 0,   // mov ecx, 0
        0xB8, 0, 0, 0, 0,   // mov eax, 0
        0xFF, 0xE0          // jmp eax
    };

    // YEEHAW
    *((I**)(code + 1)) = instance;
    *((void**)(code + 6)) = really_reinterpret_cast<void*>(method);

    void* thunk = VirtualAlloc(0, sizeof(code), MEM_COMMIT, PAGE_EXECUTE_READWRITE);
    memcpy(thunk, &code, sizeof(code));
    FlushInstructionCache(GetCurrentProcess(), thunk, sizeof(code));

    return thunk;
}

void releaseThunk(void* thunk) {
    VirtualFree(thunk, 0, MEM_RELEASE);
}

To be honest, this interface isn’t all that bad: all you have to do is remember to manage the lifetime of the generated code and cast the void* you get to the right type. That’s kind of boring, though, so let’s instead see if we can make something kickass and typesafe.

I like objects, so let’s start with one of those.

template <typename M>
struct Thunk {
    typedef M Method;
    typedef typename methodptr_traits<M>::class_type Class;
    typedef typename methodptr_traits<M>::function_type Function;

    Thunk(Class* instance, Method method)
        : ptr(createThunk(instance, method))
    { }

    ~Thunk() {
        releaseThunk(ptr);
    }

    Function get() const {
        return reinterpret_cast<Function>(ptr);
    }

private:
    Thunk(const Thunk&);

    void* ptr;
};

This is simple enough to be boring, except for this methodptr_traits thing.

methodptr_traits is an instance of something called a traits class. Basically, it is a fancy template type that defines various other types. You can think of it as a way to code ad-hoc, compile-time type introspection.

If you’ve never used templates this way, the implementation is pretty intimidating:

template <typename F>
struct methodptr_traits;

template <typename ReturnType, typename T>
struct methodptr_traits<ReturnType (T::*)()> {
    typedef T class_type;
    typedef ReturnType (__stdcall *function_type)();
};

This is one of the more convoluted things one can do with templates, and I’ll be the first to admit that I think it’s a bit scary. Let’s rewind a bit and look at this in simpler terms. Say we want a boolean variable that’s true if a particular template type is a number. We can use template specialization to accomplish this pretty easily:

template <typename T> struct is_int { enum {value = false}; };
template <> struct is_int<int> { enum {value = true}; };
template <> struct is_int<short> { enum {value = true}; };
template <> struct is_int<char> { enum {value = true}; };
// and so on

I might leverage this code with something like the following:

if (is_int<T>::value) { /* stuff */ }

and be off to the races.

Cool, right? Now what if we instead wanted to know whether something is a std::vector, whatever the element type? The same principle applies, but now we have a template specialization that is itself a template:

template <typename T> struct is_vector { enum {value=false}; };
template <typename E> struct is_vector<std::vector<E> > { enum {value=true}; };

How to use this should be obvious:

if (is_vector<T>::value) { /* do something that only works on std::vector */ }

methodptr_traits is just a tiny jump further. Most of the terror that this sort of thing inspires is really the fault of C++’s ridiculous function pointer syntax.

It is kind of a drag that C++ templates cannot express functions without specifying exactly how many arguments the function has. Because of this, a new specialization must be written for each argument count you want to support. I only did 0 and 1 arguments because this is just a small example. boost tends to support a minimum of 10 arguments by default, which is good enough for almost everyone.

For this example, I only need 0 and 1 argument, so here’s the specialization for a one-argument function:

template <typename ReturnType, typename T, typename Arg1>
struct methodptr_traits<ReturnType (T::*)(Arg1)> {
    typedef T class_type;
    typedef ReturnType (__stdcall *function_type)(Arg1);
};

And that’s it! With a single templatized class, we can dynamically generate an assembly thunk that works as a perfectly usable __stdcall function. We can pass this function pointer on to Win32, GLU, or whatever other C library we might need a callback function for.

Source code

Uncategorized ,

Ghetto Closures in Win32 with C++ II: __thiscall

February 9th, 2009
Comments Off

So, after some poking around, I have discovered that some guy has figured this out already. Rad! I’m going to go over it quickly anyway so that I can build on it for tomorrow.

First, the setup/demo part changes a bit:

struct I {
    virtual void print() = 0;
};

struct C : I {
    C(int x)
        : x(x)
    { }

    void print() {
        printf("My x is %in", x);
    }

    int x;
};

typedef void (__stdcall *Function0)();

It turns out that __thiscall and __stdcall are not all that different. All you need to do is stuff your ‘this’ pointer in ECX, and you’re set. Our satanic little blob of assembly changes to:

__asm {
    mov ecx, my_this        // B9 xx xx xx xx
    mov eax, real_func      // B8 yy yy yy yy
    jmp eax                 // FF E0
}

As before, we just have to create a block of memory, plug the code and pointers into it, and execute it:

// YEEHAW
*((I**)(code + 1)) = instance;
*((void**)(code + 6)) = really_reinterpret_cast<void*>(&I::print);

void* buffer = VirtualAlloc(0, sizeof(code), MEM_COMMIT, PAGE_EXECUTE_READWRITE);
memcpy(buffer, &code, sizeof(code));
FlushInstructionCache(GetCurrentProcess(), buffer, sizeof(code));

Function0 f0 = reinterpret_cast(buffer);

really_reinterpret_cast is a hack because we are doing Very Bad Things. The C++ standard says that you cannot convert pointer-to-methods to any other kind of pointer (not even void*!). I was unable to dig up the exact reasoning, but I think it is because the C++ implementation is allowed to make pointer-to-members have any format it wants. They don’t even have to be the same size as a normal pointer.

But that’s boring. :D I doubt Microsoft will change how this works any time soon now that existing code depends on it, and there is potential here to do something that is very useful.

It turns out that the unspecified implementation that they chose was for a pointer-to-member-function to either point to the code directly (like a stdcall function), or to point to a thunk that will go to the right place, if the method is virtual. In other words, we can just jump to it and we will be jumping to the right place.

Here’s my evil, standard-subverting cast:

template <typename D, typename S>
D really_reinterpret_cast(S s) {
    char __static_assert_that_types_have_same_size[sizeof(S) == sizeof(D)];

    union {
        S s;
        D d;
    } u;

    u.s = s;
    return u.d;
}

That weird looking char array is an ad-hoc compile-time assertion. A C array of length 0 is illegal, so if sizeof(S) != sizeof(D), then the compile will fail.

And, as before, the sweet thrill of victory:

Function0 f0 = reinterpret_cast<Function0>(buffer);
f0();

Source code

Uncategorized ,

Ghetto closures in win32 with C++

February 8th, 2009
Comments Off

One of the more annoying gaps in C++ is that there is no sort of “method reference” concept in the language. However, with just a bit of ingenuity and some knowledge of assembly and particular bits of win32, we can dynamically generate a bit of shim code that adds an extra argument into a function call.

The particular example I am going to go through only works for stdcall functions, which limits its usefulness somewhat, but it is still very useful when creating callbacks for particular Win32 functions. The first time I need it, for instance, was to subclass a window for which I did not have the source code. (that window was already using GWL_USERDATA to store its own ‘this’ pointer, so I needed to find another place for it, you see)

For reference, I am using Visual Studio 2008 as my C++ compiler. This code might violently explode if you try to use it on GCC, but you never know! You might get lucky!

First, a bit about how stdcall works. I am leaving out some details, but the important bits boil down to just a few simple things:

  1. Function arguments are pushed onto the stack in reverse order,
  2. The callee (the function you call) is on the hook for popping those arguments off the stack when it is through, and
  3. The return value lives in EAX, or EAX:EDX if it is 64 bits, or ST0 if it’s a double, or someplace in memory if it is, say, an object. Wherever the return value goes, it is not on the stack.

Given all of these things, it is possible to craft a bit of assembly code on the fly that pops off the return address, pushes our “extra” argument onto the stack, making it the “new” first parameter that will go to our real function, pushes the return address back, then jumps to the real function.

Thus armed, we are now ready to get ourselves into trouble. First, the setup!

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <cstdio>
using std::printf;

typedef void (__stdcall *Function1)(int x);
typedef void (__stdcall *Function0)();

void __stdcall the_func(int x) {
    printf("Hello!  x = %in", x);
}

void main() {
}

Next, we need to get the bytes of the code we want to generate. I couldn’t think of a clever way to do this automatically, so I just added a do-nothing function to my code and used Visual Studio’s disassembler view to tell me how the bytes fell out:

void nothing() {
    __asm {
        pop eax                 // 58
        push 0x12345678         // 68 78 56 34 12
        push eax                // 50
        mov eax, 0x87654321     // B8 21 43 65 87
        jmp eax                 // FF E0
    }
}

You could also try doing it by hand the Intel Manual, but that is a lot more work.

That was totally tedious and retarded. But that’s ok! Now we just have to stuff it into a block of memory, and tell Windows that we are okay if EIP somehow finds its way there:

char code[] = {
    0x58,               // pop eax
    0x68, 0, 0, 0, 0,   // push 0
    0x50,               // push eax
    0xB8, 0, 0, 0, 0,   // mov eax, 0
    0xFF, 0xE0          // jmp eax
};

// YEEHAW
*((int*)(code + 2)) = 31337;
*((Function1*)(code + 8)) = the_func;

void* buffer = VirtualAlloc(0, sizeof(code), MEM_COMMIT, PAGE_EXECUTE_READWRITE);
memcpy(buffer, &code, sizeof(code));

Also, we need to let the CPU know that we have just done Crazy Things with executable code:

FlushInstructionCache(GetCurrentProcess(), buffer, sizeof(code));

Now we whip out our big fat reinterpret_cast, and savor the thrill of the impossible:

Function0 f0 = reinterpret_cast<Function0>(buffer);
f0();

To let go of this memory once we are through, we use VirtualFree()

VirtualFree(buffer, 0, MEM_RELEASE);

Next time, I will either demonstrate the same technique for the __thiscall calling convention, or go into awful details about abusing C++ templates to build a sweet interface. I have yet to decide which, so it will be a surprise!!!

Also, I think I found a bug in Mass Effect

Uncategorized ,

Depression Driven Development

February 7th, 2009
Comments Off

I realized something today: legacy code is not the exception, it is the rule.

Basically, the majority of the code you will ever read, debug, or otherwise interact with is going to be crufty and stinky in some way or other. Maybe it’s because it was originally written to be a proof of concept, or maybe the original authors didn’t quite understand what the software would ultimately need to do. Hell, maybe performance requirements have changed since it was originally written. (I find it amusing that the it is effectively impossible for a Core 2 Duo processor to be limited by the number of instructions it can evaluate: in even the tightest code, it is pretty much always bottlenecked on instruction fetching or memory)

And even if you ignore all that stuff, there is no escaping reality the fact that most of every application you ever write will be built by stitching other peoples’ work together. (at IMVU, our software stack extends from DirectX, OpenGL and Python all the way to PHP, Mogile, Apache, and SQL) We have become the programmer archaeologists of Vernor Vinge’s novels.

So, considering all of the above, I make the claim that the single most valuable skill a software engineer can have is the ability to deeply understand and improve whatever horrid crap the last guy left behind. I further claim that it generally will be horrible, too, because if it wasn’t, you would not have to spend much time on it. (which is not to say that it never happens, merely that, when it does, the job is going to be done so quickly as to be unnotable)

Of further amusement is that the extrapolation of this thesis is that an engineer’s primary focus should be on skills that optimize for, well, optimizing crappy code: writing automated tests, refactoring, and so on.

In other words, I think I just reinvented Test-Driven Development, except with pessimism!

Also, I have been playing Blue Dragon. It is kind of lame so I do not think I will finish it, but it looks awesome on my HDTV.

Update: I found money in the poo! YAY!!!

Uncategorized