Каков порядок следования байтов / битов в этом документе Microsoft? - PullRequest
Новая
       10

Каков порядок следования байтов / битов в этом документе Microsoft?

1 голос
/ 14 января 2020

Это документация для формата ярлыка Windows .lnk:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943

Структура ShellLinkHeader описывается следующим образом:

screenshot

Это файл:

screenshot

Просмотр Размер заголовка , байты 4c 00 00 00, и это должно означать 76 десятичных. Это целое число с прямым порядком байтов, что неудивительно.

Далее идет LinkCLSID с байтами 01 14 02 00 00 00 00 00 c0 00 00 00, представляющими значение "00021401-0000-0000-C000-000000000046". Этот ответ , кажется, объясняет, почему меняется порядок байтов, потому что последние 8 байтов являются байтовым массивом, а остальные - порядковыми числами.

Мой вопрос о LinkFlags part.

Часть LinkFlags описывается так:

screenshot

И байты в моем файле 9b 00 08 00, или в двоичном виде: 

9    b    0    0    0    8    0    0
1001 1011 0000 0000 0000 1000 0000 0000
 ^

Сравнивая различные файлы, я обнаружил, что бит, отмеченный ^, является битом 6 / G в документации (отмечен красным).

Как истолковать это? Байты в том же порядке, что и в документации, но у каждого байта биты обращены?

1 Ответ

1 голос
/ 15 января 2020

Проблема здесь проистекает из того факта, что показанный список битов в этих спецификациях вовсе не предназначен для размещения числа под ним. Он предназначен для размещения списка битов под ним, и этот список переходит от младшего бита к старшему биту , который полностью противоположен тому, как мы читаем числа слева направо.

В списке четко показаны биты с номерами от 0 до 31, однако это означает, что это действительно одно 32-битное значение, а не четыре байта. В частности, это означает, что оригинальные байты чтения должны быть интерпретированы как одно 32-разрядное целое число , прежде чем делать что-либо еще. Как и для всех других значений, это означает, что его нужно читать как порядковый номер с обратными байтами.

Таким образом, ваш 9b 00 08 00 становится 0008009b, или, в двоичном виде, 0000 0000 0000 1000 0000 0000 1001 1011.

Но, как я уже сказал, этот список в спецификациях показывает биты от младшего к старшему. Чтобы соответствовать им, измените двоичную версию: 

0           1            2           3
0123 4567 8901 2345 6789 0123 4567 8901
ABCD EFGH IJKL MNOP QRST UVWX YZ@_ ____
---------------------------------------
1101 1001 0000 0000 0001 0000 0000 0000
       ^

Таким образом, бит 6, обозначенный в спецификации как 'G', равен 0.

Все это делает намного больше имеет смысл, если вы инвертируете спецификации, и логически перечисляете биты от старшего к низшему: 

 3           2            1           0
1098 7654 3210 9876 5432 1098 7654 3210
____ _@ZY XWVU TSRQ PONM LKJI HGFE DCBA
---------------------------------------
0000 0000 0000 1000 0000 0000 1001 1011
                               ^
   0    0    0    8    0    0    9    b

Это делает ссылки на алфавит c выглядят намного менее интуитивно понятными, но они идеально вписываются в цифры. c версии под. Этот бит соответствует вашим выводам (третий бит того, что у вас в качестве значения «9»), и вы также можете ясно видеть, что старшие 5 бит не используются.

...