Я взял структуру VS_VERSIONINFO из файла, а значение (VS_FIXEDFILEINFO) дополнено 32 битами.Структура VS_VERSIONINFO - ненужное заполнение
Согласно MSDN, значение должно быть дополнено падением на 32-битную границу.
Padding1
Тип: WORD
Содержит столько нулевых слов, сколько необходимо для выравнивания элемента значение на 32-битовой границе.
Но значение уже находится на 32-битной границе.
Почему VS_FIXEDFILEINFO имеет 32 бита на 32-битной границе?
Для выравнивания данных на 32-битной границе будет иметь смысл только отступы с менее чем 32 битами.
Я прошу об этом, потому что мне нужно разобрать RC-скрипт и сгенерировать этот ресурс.
О, так что они пытаются сказать, что wLength не содержит никаких дополнений между структурами VS_VERSIONINFO, а не дополнения между его членами. Но все же szKey уже упал бы на 32-битную границу. Эти 32 бита заполнения не нужны. В документах MS говорится: «Padding1: содержит столько нулевых слов, сколько необходимо для выравнивания элемента Value на 32-битной границе». Но значение уже находится на 32-битной границе. Нет смысла выравнивать данные на 32-битной границе с 32-разрядным дополнением. Будет иметь смысл только дополнение с менее чем 32 битами. – Chris
Я думаю, что они пытаются сказать (не очень понятно), что если сама структура 'VS_VERSIONINFO' не начиналась с 32-битной границы, тогда' Padding1' должен гарантировать, что 'Value' определенно будет. Справедливости ради отметим, что в конце концов они заявляют, что это не настоящая языковая структура, а просто удобный способ выразить организацию памяти в памяти. Читая между строками и отмечая единицы заполнения 16 бит, я ожидаю, что это дополнение появилось во время миграции структуры с 16 до 32 бит Windows. –
Ой, я был слепым. «VS_VERSIONINFO» - это строка в Юникоде, поэтому ее нужно прервать с нулем, поэтому szKey на 2 байта больше, чем я на самом деле отмечен на картинке, а заполнение - это на самом деле 16 бит, а не 32. Теперь это имеет смысл. – Chris