> The UTF-16 equivalent for this in the byte order used by RDP would be:
>     43 6C 6F 75 53 74 6F 72 61 67 65 00
> Which is the equivalent of the string:
>     "ClouStorage"
> So you have apparently changed the UTF-16 string
> ("G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0") to something which is not encoded in
> UTF-16 ("ClouStorage"). Because RDP requires this to be UTF-16, it
> interprets it as such.
> - Mike
I'm playing with configuring the drive name and looking at the FreeRDP
source code, and I'm not sure that the actual name is supposed to be UTF-16

If I use xfreerdp to connect to a system I can specify the following flag:

When I connect to the system, I see a drive in the Computer called "tmp on
linux-host" - which means it isn't passing through a drive letter, it's
passing through a filesystem name.  What I suspect is happening is that
this filesystem name is *not* supposed to be UTF-16 encoded and when you
pass the UTF-16 encoded string that begins with either "G\0" (for
"Guacamole", as is the default) or "C\0" (for "Cloud Storage", as Amarjeet
is using), it takes the first character, stops at the null terminator, and
then just uses that first character and calls it either "G on Guacamole
RDP" or "C on Guacamole RDP" - which, because it's a single capital letter,
makes it look like a drive letter, when it's actually technically a share
name (\\tsclient\C or \\tsclient\G or \\tsclient\tmp).

Looking at the FreeRDP source code, I see the following...

- In channels/drive/client/drive_main.c, starting around line 705
(stable-1.1 branch)[1], you see the processing for the name of the drive.
It looks like this just gets adding to a UINT8 stream with no encoding.
- In channels/drive/client/drive_main.c, starting around line 407
(stable-1.1 branch)[2], you see the handling for the label of the
filesystem.  There is definitely a conversion to UTF done, here, using the
ConvertToUnicode() function.

Am I seeing this correctly, or am I missing something, here?  I'm going to
do some testing and see if I can get a configurable drive name passed
through correctly.

Probably the most annoying thing is that this means that printer name and
drive name have to be dealt with separately (as the FreeRDP code does),
because the printer name definitely does have to be UTF-16 encoded.


[1] -
[2] -

Reply via email to