Unicode API

22 Jun 2006 3:52 PM

Howard Kaikow

Are the following equivalent?

<DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
Private Shared Function FindFirstFile _
(ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
Integer
End Function

<DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
Private Shared Function FindFirstFileW _
(ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
Integer
End Function

<DllImport("kernel32", CharSet:=CharSet.Auto, SetLastError:=True)> _
Private Shared Function FindFirstFileW _
(ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
Integer
End Function

--
http://www.standards.com/; See Howard Kaikow's web site.

22 Jun 2006 4:30 PM

Claes Bergefall

No they are not

"Howard Kaikow" <kai***@standards.com> wrote in message
news:esFiRPhlGHA.4144@TK2MSFTNGP05.phx.gbl...
> Are the following equivalent?
>
> <DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
> Private Shared Function FindFirstFile _
> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
> Integer
> End Function

In this case ExactSpelling (a property of DllImportAttribute) is true
causing the runtime to *only* look for the method FindFirstFile. This fails
since there is no such method in kernel32

> <DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
> Private Shared Function FindFirstFileW _
> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
> Integer
> End Function

Here too ExactSpelling is true causing the runtime to *only* look for the
method FindFirstFileW. This works fine since that's actually one of the
methods exported from kernel32

> <DllImport("kernel32", CharSet:=CharSet.Auto, SetLastError:=True)> _
> Private Shared Function FindFirstFileW _
> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
> Integer
> End Function

When using CharSet.Auto, VB defaults ExactSpelling to False and in this case
the behavior depends on the platform.
On ANSI platforms it will first look for the method FindFirstFileW (i.e. the
exact spelling you used) and if not found it will try FindFirstFileWA (i.e.
appending an A to the name you specified). I don't remember if the
FindFirstFileW method exists on ANSI systems so I don't know if this
succeeds or not. You'll have to try it
On Unicode platforms it will first look for the method FindFirstFileWW (i.e.
appending a W to the name you specified) and if not found it will try
FindFirstFileW (i.e. the exact spelling you used). All Unicode systems
exports FindFirstFileW som this will succeed.

Unless you have compelling reason not to, I suggest you stick with this:
<DllImport("kernel32", CharSet:=CharSet.Auto, SetLastError:=True)> _
Private Shared Function FindFirstFile (ByVal lpFileName As String, ByVal
lpFindFileData As WIN32_FIND_DATA) As Integer
End Function

/claes

22 Jun 2006 4:37 PM

Mattias Sjögren

Hej Claes,

>> <DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
>> Private Shared Function FindFirstFile _
>> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
>> Integer
>> End Function
>
>In this case ExactSpelling (a property of DllImportAttribute) is true

No, ExactSpelling defaults to False and it's not set to anything else
in the code.

Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

22 Jun 2006 4:50 PM

Claes Bergefall

Hej Mattias :-)

This is what it says in my documentation (2005):

"CharSet.Unicode
String marshaling
Platform invoke copies strings from their managed format (Unicode) to
Unicode format.
Name matching
When the ExactSpelling field is true, as it is by default in Visual Basic
2005, platform invoke searches only for the name you specify. For example,
if you specify MessageBox, platform invoke searches for MessageBox and fails
if it cannot locate the exact spelling.
When the ExactSpelling field is false, as it is by default in C++ and C#,
platform invoke searches for the mangled name first (MessageBoxW), then the
unmangled alias (MessageBox) if the mangled name is not found. Notice that
Unicode name-matching behavior differs from ANSI name-matching behavior."

Since we're using VB.NET it defaults to True when specifying
CharSet.Unicode. In C# though it would default to False.

/claes

Show quoteHide quote

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:%23NCTDphlGHA.2392@TK2MSFTNGP04.phx.gbl...
> Hej Claes,
>
>>> <DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
>>> Private Shared Function FindFirstFile _
>>> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
>>> Integer
>>> End Function
>>
>>In this case ExactSpelling (a property of DllImportAttribute) is true
>
> No, ExactSpelling defaults to False and it's not set to anything else
> in the code.
>
>
> Mattias
>
> --
> Mattias Sjögren [C# MVP] mattias @ mvps.org
> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
> Please reply only to the newsgroup.

22 Jun 2006 4:57 PM

Claes Bergefall

Here is the doc btw:
http://msdn2.microsoft.com/en-us/library/7b93s42f.aspx

Show quoteHide quote

"Claes Bergefall" <louplou@nospam.nospam> wrote in message
news:e%23xrQuhlGHA.4212@TK2MSFTNGP03.phx.gbl...
> Hej Mattias :-)
>
> This is what it says in my documentation (2005):
>
> "CharSet.Unicode
> String marshaling
> Platform invoke copies strings from their managed format (Unicode) to
> Unicode format.
> Name matching
> When the ExactSpelling field is true, as it is by default in Visual Basic
> 2005, platform invoke searches only for the name you specify. For example,
> if you specify MessageBox, platform invoke searches for MessageBox and
> fails if it cannot locate the exact spelling.
> When the ExactSpelling field is false, as it is by default in C++ and C#,
> platform invoke searches for the mangled name first (MessageBoxW), then
> the unmangled alias (MessageBox) if the mangled name is not found. Notice
> that Unicode name-matching behavior differs from ANSI name-matching
> behavior."
>
> Since we're using VB.NET it defaults to True when specifying
> CharSet.Unicode. In C# though it would default to False.
>
> /claes
>
> "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
> news:%23NCTDphlGHA.2392@TK2MSFTNGP04.phx.gbl...
>> Hej Claes,
>>
>>>> <DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
>>>> Private Shared Function FindFirstFile _
>>>> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA)
>>>> As
>>>> Integer
>>>> End Function
>>>
>>>In this case ExactSpelling (a property of DllImportAttribute) is true
>>
>> No, ExactSpelling defaults to False and it's not set to anything else
>> in the code.
>>
>>
>> Mattias
>>
>> --
>> Mattias Sjögren [C# MVP] mattias @ mvps.org
>> http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
>> Please reply only to the newsgroup.
>
>

22 Jun 2006 5:37 PM

Mattias Sjögren

>When the ExactSpelling field is true, as it is by default in Visual Basic 2005,

This is wrong, or at least over simplified. It's only the default
(i.e. set automatically by the compiler) if you use the Declare
statement with the Ansi or Unicode modifier. If you use Declare Auto,
or the DllImport attribute as in the original poster's code, the
default is ExactSpelling=false.

Trevlig midsommar...

Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

22 Jun 2006 8:02 PM

Claes Bergefall

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:uqFIgKilGHA.5036@TK2MSFTNGP05.phx.gbl...
> >When the ExactSpelling field is true, as it is by default in Visual Basic
> >2005,
>
> This is wrong, or at least over simplified. It's only the default
> (i.e. set automatically by the compiler) if you use the Declare
> statement with the Ansi or Unicode modifier. If you use Declare Auto,
> or the DllImport attribute as in the original poster's code, the
> default is ExactSpelling=false.

Yes, it looks like you are correct (and it makes sense too since the
DllImport constructor doesn't set this value)

This works...
<DllImport("user32", CharSet:=CharSet.Unicode)> _
Private Shared Function SetWindowText(ByVal hwnd As IntPtr, ByVal lpString
As String) As Integer
End Function

....but this doesn't (although it looks fundamentally the same)
Private Declare Unicode Function SetWindowText Lib "user32" (ByVal hwnd As
IntPtr, ByVal lpString As String) As Integer

So I guess the documentation is incorrect (or at least incomplete) in this
case.

> Trevlig midsommar...

Detsamma

/claes

23 Jun 2006 9:54 AM

Howard Kaikow

So, if I want to use Unicode, the following is guaranteed to work on systems
supporting FindFirstFileW and Unicode?

<DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
Private Shared Function FindFirstFileW _
(ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
Integer
End Function

23 Jun 2006 1:53 PM

Claes Bergefall

Yes. You should pass lpFindFileData ByRef though (unless you defined
WIN32_FIND_DATA as a class) since it's an out parameter

/claes

Show quoteHide quote

"Howard Kaikow" <kai***@standards.com> wrote in message
news:uQILkrqlGHA.836@TK2MSFTNGP02.phx.gbl...
> So, if I want to use Unicode, the following is guaranteed to work on
> systems
> supporting FindFirstFileW and Unicode?
>
> <DllImport("kernel32", CharSet:=CharSet.Unicode, SetLastError:=True)> _
> Private Shared Function FindFirstFileW _
> (ByVal lpFileName As String, ByVal lpFindFileData As WIN32_FIND_DATA) As
> Integer
> End Function
>
>