How to transfer Unicode from C# through Win32API to Putty?

[Morten Wennevik]

I made a program than can send text to Putty (A telnet/ssh client)
http://www.chiark.greenend.org.uk/~sgtatham/putty/
And I discovered that Unicode characters doesn't reach it

I'm using PostMessage with WM_CHAR, the text source is taken straight
from a textbox and sent character by character to putty (putty handle is
previously found with FindWindow)

private void sendText(string text)
{
foreach(char ch in text)
{
Win32.PostMessage(puttyHandle, 0x0102, ch, 0);
}
}

PostMessage is defined in Win32 namespace
0x0102 is WM_CHAR

[DllImport("User32.Dll")]
public static extern bool PostMessage(int hWnd, int Msg, int WPARAM, int
LPARAM);

ch is unicode, while it never reaches putty as one?
Am I doing something wrong?

(There is a possibility that putty doesn't treat WM_CHAR properly. I've
checked the source code for it, and found it converts wPARAM to unsigned
char)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Jon Skeet]

Morten Wennevik <mo************@hotmail.com> wrote:

<snip>

ch is unicode, while it never reaches putty as one?
Am I doing something wrong?

(There is a possibility that putty doesn't treat WM_CHAR properly. I've
checked the source code for it, and found it converts wPARAM to unsigned
char)

There's also the possibility that whatever connection you've got
doesn't really support Unicode.

I'll forward your post to the author of Putty (a friend of mine from
university) and let you know the results.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet]

Jon Skeet <sk***@pobox.com> wrote:

(There is a possibility that putty doesn't treat WM_CHAR properly. I've
checked the source code for it, and found it converts wPARAM to unsigned
char)

Thinking about it, of course unsigned char in C is just a single byte,
so that indeed won't get the unicode values. The question is whether or
not Putty is expecting anyone to be posting unicode values to it in the
first place.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Morten Wennevik]

Well, I'm using PostMessage, and if I understand it correctly, .net
framework automatically translates it to PostMessageW if it spots a unicode
character.

Also, I know putty receives something, but always a single ascii character
(I suspect whatever first or last byte of the unicode character).

As you mentioned, I suspect it is because it's cast into unsigned char.
I got the source code, and if I manage to compile it properly under Visual
Studio .Net I'll play around with the code to see if I can make something
work.

Thanks for your reply.

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

[Jon Skeet]

Morten Wennevik <mo************@hotmail.com> wrote:

Well, I'm using PostMessage, and if I understand it correctly, .net
framework automatically translates it to PostMessageW if it spots a unicode
character.

Also, I know putty receives something, but always a single ascii character
(I suspect whatever first or last byte of the unicode character).

As you mentioned, I suspect it is because it's cast into unsigned char.
I got the source code, and if I manage to compile it properly under Visual
Studio .Net I'll play around with the code to see if I can make something
work.

Thanks for your reply.

I've just had this from the author:

<quote>
PuTTY should be able to accept Unicode input from the keyboard, the
Windows clipboard etc, at all times. It will translate the Unicode into
whatever character set it is configured to believe the server is
speaking - so I suppose in that sense you could argue that whether it
`supported' Unicode depended on the connection configuration, although
I'd prefer to say that PuTTY supports Unicode always, and your
connection to the server might or might not be restricted to a subset
of it.

Checking the source, it appears we don't support arbitrary Unicode
coming in through WM_CHAR messages, and the reason why not is that we
believe WM_CHAR itself doesn't support it - we expect the parameter to
WM_CHAR to be in the system's default code page (typically Win1252). If
there is an extension to WM_CHAR which supports Unicode, then we
clearly ought to support it; if someone tells us about it it should be
easy enough to do so.
</quote>

So, do you have any documentation I could pass along which talks about
Unicode support in WM_CHAR messages?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Michael \(michka\) Kaplan [MS]]

A few corrections and elaborations, inline....

"Jon Skeet" <sk***@pobox.com> wrote...

Morten Wennevik <mo************@hotmail.com> wrote:

Well, I'm using PostMessage, and if I understand it correctly, .net
framework automatically translates it to PostMessageW if it spots a unicode character.

This is incorrect. It uses PostMessageW depending on your pinvoke wrapper.
If you use CharSet.Auto on a NT-based platform or CharSet.Unicode ever, then
it will try to use PostMessageW.
Checking the source, it appears we don't support arbitrary Unicode
coming in through WM_CHAR messages, and the reason why not is that we
believe WM_CHAR itself doesn't support it - we expect the parameter to
WM_CHAR to be in the system's default code page (typically Win1252). If
there is an extension to WM_CHAR which supports Unicode, then we
clearly ought to support it; if someone tells us about it it should be
easy enough to do so.
This is incorrect. If the Window is a Unicode window, then it is supposed to
be expecting WM_CHAR to give it a WCHAR. If it is not a Unicode window, then
a CHAR is passed.
So, do you have any documentation I could pass along which talks about
Unicode support in WM_CHAR messages?

The WM_CHAR documentation should be clear enough, as should the windowing
system (I am looking at the source in Windows as I say this). You can have
them contact me offline at mi****@trigeminal.com if they need more info.

--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.