Is this a Unicode problem?

[Norman Diamond]

Here are two complete lines of output from Visual Studio 2005:

1>$B%W%m%8%'%/%H=PNO$K(B Authenticode $B=pL>$7$F$$$^$9(B...
1>Successfully signed: c:\T

The first line means roughly:
Doing Authenticode signature to project output.

The second line is harder to translate. The reason is that the second line
says it successfully signed something that doesn't exist. I don't have a
file named c:\T and I don't have a folder named c:\T.

I do have some folders in the root of c: whose names start with a T. All of
their names are longer than one character. All of those folders contain
files and/or subfolders. One of them contains a subfolder which contains a
Visual Studio 2005 project.

Is this a Unicode problem? Perhaps Visual Studio 2005 more or less handles
filename strings in Unicode? Perhaps it was confused because the Unicode
codepoints for some characters, such as the Italian capital letter T, have a
zero value in their second byte?

In the MSDN feedback centre, Microsoft has told me enough times that
Microsoft will not fix bugs. I'm not going to waste time posting this one
to the feedback centre.

 

[Pavel A.]

VS captures console output of various command line
tools during build.
Some of these tools probaby are not too unicode friendly.


Regards,
--PA

 

[Guest]

check if your system default language and current user default language is
the same.

 

[Norman Diamond]

They are the same. The same language version of Visual Studio 2005 was
installed onto it and the same default language was left unchanged as well.

 

[Guest]

Maybe you can create hardlink with ANSI name for files in trouble.
http://www.microsoft.com/resources/.../proddocs/en-us/fsutil_hardlink.mspx?mfr=true

 

[Norman Diamond]

It doesn't look that way. According to the page you linked, the Fsutil
command can create a hard link, but it doesn't get to say if the new name
will be stored in NTFS structures as Unicode or ANSI. In my experience NTFS
volumes only contain names stored in Unicode.

Also, regardless of how a file system stores filenames, ANSI APIs will use
ANSI strings while interacting with the application and Unicode APIs will
use Unicode strings while interacting with the application. For example in
either Windows XP or Windows 98, CreateFileA will take a filename from the
application in ANSI, but on a VFAT volume it would write the usual mixture
of OEM and Unicode (or if the filename fits in 8.3 then it will write OEM
only). For example in either Windows XP or Windows 98 + MSLU, CreateFileW
will take a filename from the application in Unicode, but on a VFAT volume
it would write the usual mixture of OEM and Unicode (or if the filename fits
in 8.3 then it will write OEM only).

Therefore even if Partition Magic can change my partition from NTFS to VFAT,
Visual Studio 2005 will still be calling the same APIs that it was already
calling, and if Visual Studio 2005 gets confused by its own Unicode strings
then it will not be changed by this.