So I was presented with a situation where I needed a binary to simply run some predetermined commands on Windows. I said, "Why, this is a simple fork/exec under Linux. How hard could it be in Windows?"
Turns out, a lot fscking harder than it needs to be.
The primary problem stems from the way Windows "attempts" to support multibyte characters. Or rather, the wayS it supports multibyte characters... you have a choice of the ANSIish widechar that can do UTF-8, or the one that MS Visual Studio defaults to LPWSTR for UTF-16. The Windows libraries helpfully provide replacement functions for stuff like sprintf() and such, but the common and well known string functions are cut off from you. Worse, some wrappers to system calls like GetCurrentDirectory() will only return LPWSTR and only take LPWSTR args, and because these are differently sized types you can't just cast your out of the problem.
Oh, and stuff like malloc()/calloc() doesn't appear to work with the macros, either. Or at least I didn't have the time to unravel what the correct way to use them were in the time I had alotted.
In the end, I used something like:
wchar_t* thing[SIZE];
and just used a typecast whenever I needed to move into or out of the variable: (LPRWSTR) thing, like when using _stprintf() to build up these strings.
So, basically, I ended up being corralled into doing freshman level C just to get stuff working.
What I've taken away from this experience is that I absolutely, positively, 100% don not ever want to do any serious Win32 C/C++ development. Ever. EVER. And if I do have to go down that road, then I'm going to try and stick with ANSI... maybe even to the point of using cygwin exclusively to avoid getting sucked into this nightmare again.
No comments:
Post a Comment