Front page | perl.perl6.users |
Postings from January 2020
Re: stolen uint's
Thread Previous
|
Thread Next
From:
ToddAndMargo via perl6-users
Date:
January 29, 2020 20:28
Subject:
Re: stolen uint's
Message ID:
7ed60ca2-fa76-6117-2e71-ebc88277e065@zoho.com
On 2020-01-29 11:36, Trey Harris wrote:
> On Wed, Jan 29, 2020 at 14:01 ToddAndMargo via perl6-users
> <perl6-users@perl.org <mailto:perl6-users@perl.org>> wrote:
>
> On 2020-01-29 06:34, Trey Harris wrote:
> > I was going to ask about that (but it seemed out of Raku-world,
> and I
> > don’t even play someone who knows about Windows on TV), but,
> okay, I’ll
> > bite... what are some examples of the precisely 3-byte + 32-bit
> null UTF
> > strings you imagine being encoded by this interface? I have never
> heard
> > of such a small fixed-width UTF data structure before because
> it’s just
> > so bizarre, and then mandating a null termination so you lose the
> 4th
> > byte that would make this structure at least somewhat coherent as a
> > UCS-4 codepoint... since there’s no such thing as UTF-24, I
> assume this
> > is three UTF-8 bytes packed (which I guess is what you mean by
> “little
> > endian C string”, but that becomes at best ill-defined abutted
> next to
> > “UTF”)... But, what on earth is it being used for?
> >
> > I’m fascinated, in the way a cat is fascinated by a snake....
>
> Trey,
>
> You are basically setting up a buffer of bytes
> and then telling the WinAPI how long the
> data in the buffer is as well as what type of
> data the buffer contains.
>
>
> That is clear from the document linked at
> https://docs.microsoft.com/en-us/windows/win32/api/winreg/nf-winreg-regsetvalueexw
>
> But what I was asking about and what I don’t understand is what you
> meant when you wrote:
>> where CbData can either be a UTF little endian C string,
>> terminated by a nul or a four byte little endian
>> unsigned integer (no two's complement allowed) depending
>> on the value of lpValueName (REG_SZ, REG_DWORD, etc.)
>
> Can you explain just this part:
>> where CbData can… be a UTF little endian C string,
>> terminated by a null
>
> That’s the part I’m fascinated by because it’s just so strange. What’s
> an example of a valid value of this type and not the “unsigned integer
> (no two’s complement allowed)”?
"Todd" would convert to
84 00 111 00 100 00 100 00 00 00
Here is a more elaborate UTF16 little endian example. It
return the WinAPI error string that goes with the error code
perl6 -I. -e "use lib '.'; use WinErr :WinFormatMessage; say
WinFormatMessage( 0x20, True );"
WinFormatMessage: Debug:
WinGetLastError 0
Error Number 32
nSize 1024
RtnCode 81
Error String Characters 79
ErrorString <The process cannot access the file because
it is being used by another process.>
lpBuffer
84 0 104 0 101 0 32 0 112 0 114 0 111 0 99 0 101 0 115 0 115 0 32 0 99 0
97 0 110 0 110 0 111 0 116 0 32 0 97 0 99 0 99 0 101 0 115 0 115 0 32 0
116 0 104 0 101 0 32 0 102 0 105 0 108 0 101 0 32 0 98 0 101 0 99 0 97 0
117 0 115 0 101 0 32 0 105 0 116 0 32 0 105 0 115 0 32 0 98 0 101 0 105
0 110 0 103 0 32 0 117 0 115 0 101 0 100 0 32 0 98 0 121 0 32 0 97 0 110
0 111 0 116 0 104 0 101 0 114 0 32 0 112 0 114 0 111 0 99 0 101 0 115 0
115 0 46 0 13 0 10 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1
The buffer was prefilled with 0xFF (-1) to clearly show
the 0x0000 terminator at the end of the buffer.
I will eMail you off line a test example I am including in
my WinAPI paper.
-T
Thread Previous
|
Thread Next