The problem is confirmed. An include directive causes CreateFile to be redefined as CreateFileA (non-Unicode) or CreateFileW (Unicode).
The CDB API currently exports CreateFile as CreateFileA, corrections will be made to force the intended name of CreateFile. Users will also need to ensure that none of their include statements redefine CreateFile (or any other method exported by the CDB API).
There is no plan at the moment to support Unicode in the CDB API, but we would appreciate your comments and reasons if you feel this is necessary.
I have no need for unicode myself but because of the system headers problem I also had it meant that it was very difficult to get a unicode build to work correctly (my qt apps default to unicode).
The CDB spec. clearly limits characters to those in the ascii set so unicode would be unnecessary unless this rule was relaxed.
Given that the filename spec. only really supports english I think that maybe it would be a good idea to support a unicode interface at some point and present the list of characters that are not allowed to be used instead of the list of characters that are.
Craig
When trying to compile a test app in a unicode build I get a linker error saying that CreateFileW could not be found. After searching with depends.exe this does appear to be the case as only CreateFileA is exported.
Is unicode not yet supported in the api? (or is this an unintentional mistake due to the use of macros in the windows header files?)