Cutlass Developers' Journal

So, in order for Cutlass to be popular, it’s gotta support Windows. That’s the reality in today’s world. So I figured I should talk about how Cutlass intends to accomplish that.

First, and most importantly, we’re trying to stay away from platform-specific calls, at least in the library layer. (Cutlass is divided into libcutlass and clients, if you haven’t been playing along up until now). The two areas that we haven’t been able to avoid platform specifics we wrap. Those two areas are threads and time.

Luckily, those really aren’t that hard to wrap. While Windows threads are slightly different from pthreads, we’re not using any of the pthreads functionality that Windows has no equivalent for. So pretty much we’ve created our own cutlass_thread_handle and cutlass_mutex_handle structures, which we #define at compile time to contain the platform-specific structures.

Then we wrap all of the thread creating, detatchment, etc. functions. pthread_create and CreateThread get merged into cutlass_thread_create. pthread_mutex_lock and EnterCriticalSection get merged into cutlass_mutex_lock, and so forth. All of this happens in wrap_thread.c, with the structure definitions in <cutlass/wrap_types.h>.

Time is a bit more complicated. Sadly, Windows only offers millisecond timers by default, while Linux now gives you access to nanosecond-aware functions (Whether they’re accurate to nanoseconds is unlikely, but the interfaces are there). Right now, we’re defining a cutlass_time structure that can support nanosecond accuracy, and under Windows we just multiply milliseconds by one million in order to get nanosecond-equivalence. I suspect we’ll find some issues when we start testing the transport layers under Windows that we’ll need to tune, probably by bunching packets together if we’ve slept for too long.

Anyways, time checking and sleep functions are all wrapped up in wrap_time.c, following the same strategy as for threads.

Using these wrappers, most of the code compiles under both Linux and Windows (using MinGW). Still having a few linking issues in Windows, and one issue with the crypto module not locating some headers. We’ll get it hammered out, though.