From: Pete B. <pb...@gm...> - 2011-02-28 21:26:56
|
On 2011.02.28 20:53, Michael Plante wrote: > As long as something that works with wprintf (UCS-2) is provided with at one > variant, and something that works with printf (ANSI or UTF8, not sure which) > is provided with the other. Basically, I'd like to be able to do what > usually works with the Windows API, and if that requires offering a third > variant for UTF8, fine 3 variants would be an overkill. As I said I can work with UCS-2 as well, just wondering what the preferences are. > I don't see much point in cp437 for libusb, so maybe getting rid of "A" > should be fine. Keeping "W" is what I was after, though. OK. I guess most Windows developers would be expecting a W as well, since this is Microsoft's way to support Unicode. Right now, I'm not so sure what we should do. I'd like to avoid having to support 2 calls just for the Windows implementation (we're really overkilling this whole thing IMO - it should be kept as simple as possible) but I'd like to have something that looks familiar to Windows users... Would the W call be made available to POSIX users? If not, the documentation will be quite confusing (If you're on Posix, use strerror(). On Windows use strerrorA(), or strerrorW()). Sounds a bit heavy for what is meant to be a simple API call... > That's troubling, but not nearly so much of a bother, since those DLLs could > go into system32 (or whatever the equivalent mess is with 64-bit windows), > since they're not necessarily particular to libusb like the translated > strings are. Even so, it'd be nice not to have to do that. Is it possible > to statically link without running into the MSVCRT dll problems we discussed > before? Oh there's that to consider as well! Are the gettext strings allocated dynamically and supposed to be free by the application developer? My understanding is that we would only run into an MSVCRT issue is something is allocated in libusb and freed in the app, so shouldn't we be safe here? Regards, /Pete |