VerQueryValue()

[CornedBee]

Is it really exactly the same string? Have you UNICODE problems? What type is szSubBlocks and how is it initialized? Have you the line
#define UNICODE
somewhere?

[CornedBee]

Have you tested the GetLastError code?

[amac]

No I don't have UNICODE defined.

szSubBlock is defined as... and initialized using the tchar.h _stprintf()

    TCHAR szSubBlock[80] = TEXT( "" );

    _stprintf( szSubBlock, TEXT( "\\StringFileInfo\\%s\\Comments" ), szLangCodepage );

I dont know that much about UNICODE, and how to use it. I know I have to define UNICODE, but is that it?

I've noticed in the SDK documentation that it usually says if GetLastError() can be used to retrieve error info, but for this function it did not.

So... No I didn't, but above was my reason for not doing so.

[CornedBee]

Yeah, I found that last thing out too.
In that case I don't know what your problem could be. Sorry.

[amac]

What do you have to do to support UNICODE?

I haven't done any research on it, so this is probably a really easy question to answer... I know what UNICODE is... just not sure on how to implement it...

I know about tchar.h... and how it changes macroes depending on whether or UNICODE is defined...

I think it was you CornedBee, who said that DLLs should support both ANSI and UNICODE...

To do that should have two separate functions one UNICODE and one ANSI kinda like SetWindowTextA() and SetWindowTextW()... And then use macros to determine which one should be used?

What about MBCS? What is this all about?

[CornedBee]

To support UNICODE in a program is easy. Just always use TCHAR or _TCHAR, LPTSTR, LPCTSTR etc., wrap texts with _T, _TEXT or TEXT and use the tcs versions of the CRT functions (or the lstr versions that are in the WinDLLs, saves space).

Then, if you want a UNICODE compile, define BOTH the symbols _UNICODE (for tchar.h) and UNICODE (for windows.h).

Basically, everything that has an underscore is from tchar.h.
Another thing: use _tmain or _tWinMain, they will compile to either main/WinMain or wmain/wWinMain. If you have UNICODE defined, you also need to set the entry point to wmainCRTStartup or wWinMainCRTStartUp (again depending wether it is console or GUI).

For the C++ library, there is wcout and wstring and such for UNICODE, but no generic things (except that the templates themselves are generic). Therefore I have written (and attached) the file tcpp.h, that declares things like tifstream, tcout and tstring and will create the UNICODE versions of them if either UNICODE or _UNICODE is defined. Else it will create the ANSI versions.

DLLs are far harder. You can either go the MFC way and have different DLLs (maybe a waste of disk space, but sometimes it isn't possible otherwise), then decide inside the headers which library to use, or go the WinAPI way by defining two functions and let a macro decide which one to use. Strings sent to messages are assumed to be UNICODE if RegisterClass(Ex)W was used, else they are ANSI. You can find that out for yourself by calling the IsWindowUnicode function.

MBCS (Multi-byte character strings) are used only in Asian versions of windows (when the alphabet contains more that 128 characters, like Chinese). Some characters in the character set are switches, they say that the next byte is part of the character. This is extremly nasty because a character doesn't have a constant size, it can be either 1 or 2 bytes.

All CRT functions can handle MBCS by default, you don't have to worry about it (and you don't need to know it anyway becuase you're probably not going to write apps for the Chinese or Japanese market, and in the NT strain (NT, 2k, XP and what is to come) MBCS is obsolete anyway because those are using UNICODE).

[CornedBee]

BTW I forgot to post the attachement.