This weekend I've been hacking the win32 port of WvStreams to work more smoothly. It already works, but the unit testing framework didn't compile, so I had my suspicions that it didn't all work. Sure enough, I fixed the few minor bugs in the unit testing framework, and next thing you know - failing unit tests everywhere.

So first of all, yay for unit tests. Automated magic bug pinpointers, they are. A busy weekend of hacking got the failure count down to zero where it should be, and sure enough - all the WvStreams demo apps work way better now.

Anyway, since I would hardly want to resort to using Visual C++, and since the unit tests are kind of most convenient when used with GNU Make, I thought: let's see how much of this I can do on my Linux system.

Ha. So I now know all about mingw32 (a wonderful system). I also know more than I'd like to know about msvcrt.dll's fd-to-handle mapping (a terrible system). And it all runs correctly under WINE (a truly horrendous pile of puke).

Oh well, if nothing else, I guess I can extend my UniConf demo. Now I can run a UniConfDaemon under wine, exporting the Windows registry over TCP so I can connect to it from a Linux box, replicate it into my Maildir, point gconfd at that, and then configure KDE through gconf. If all that put together doesn't crash, I guess something doesn't suck.

Related Question

If you're doing _read(0,buf,sizeof(buf)) in a thread in win32, does anybody know how, from another thread, to get _read() to back out gently and return? I wouldn't even mind closing fd#0 in order to do this, but stunningly, close() blocks forever because _read() is blocking while in a critical section. Argh. I'm sure there has to be a way to do this.

I used to think the Worse is Better guy was just making an idle example. But good old EINTR - holy cow. How I miss you!

Irony

Tomorrow, I'm giving a presentation on how to write/debug code more quickly. And I spent the weekend working around Windows quirks. Sigh.