Non-ASCII DSN name troubles

Hi,

If you try to create a data source with a name that contains non-ASCII
characters, funny things will happen. I wouldn't expect the ANSI driver
to support that, but a Unicode driver ought to handle it.

1. We always use the ANSI versions of the functions to read/write the
config, SQLGetPrivateProfileString/SQLWritePrivateProfileString. In the
Unicode driver, I think we should be using the Unicode *W variants of
those functions, otherwise we cannot handle characters that don't have a
representation in the current system codepage.

2. Even if all the characters can be represented in the system codepage,
when built as a Unicode driver, we internally pass all strings as UTF-8
encoded char[] arrays, and convert between UTF-8 and UCS-2 in the
wrapper functions in odbcapiw.c. We also do that for the DSN name in
SQLDriverConnextW(), but we pass the UTF-8 encoded DSN name to
SQLGetPrivateProfileString() function, to get the config options. That
doesn't work, because SQLGetPrivateStringProfileString() expect the
string to be encoded in the system codepage, not UTF-8. Again, we should
be using the Unicode version, SQLGetPrivateProfileStringW().

3. We don't use the Unicode versions of the GUI functions, like
GetDlgTextItem(), when dealing with the configuration dialog. That again
means that the GUI cannot handle characters outside the system codepage,
but we also don't convert the strings to UTF-8 like we do to strings
coming through SQLDriverConnectW() and other API functions, so there's
another mismatch.

Attached patch fixes those issues, allowing you to create a use any
Unicode characters in the DSN name, or any other configuration fields,
with the Unicode driver.

This changes the behavior of how username and password are handled in
the Unicode driver. Without this patch, the username is read from the
registry in the system codepage, and also sent as such to the server.
After the patch, it's always sent to the server in UTF-8. I think that's
more sane behavior, but there's a small chance of breaking existing
installation that depend on the old behavior. So we probably should
include this patch when we bump the major version number to 9.4.

- Heikki