Почему стек должен быть выровнен на 4-байтную границу ??

Booster
Если ты есчо не понял, то я обьясню. Система предоставляет потоку сервисы, это единственное посредством чего он может общаться с системой. Выравнивание имеет значение только для сервисов, собственно с аппаратной частью никоим образом не связано. Я сам сталкнулся однажды с подобной проблемой.

 

Clerk
Ты о чём пишешь? Мы как будто на разных языках разговариваем. Если stdcall требует выравнивания, тогда ткните меня. Внутреннее устройство винды немного не в тему.

 

Еще раз - подразумевается
Формально об таких вещах не говорят. Так же как и о том какие регистры может менять винапи и т. д. В этом нет нужды когда код пишется на Си.
Если толкаешь в стек параметры по не выровненным адресам , это точно не нормально - получишь пенальти ~20%.

 

Booster
Можно и поиском воспользоваться. Это ABI называется. Найти можно везде. У Фога, у Чена в блоге, тот что Реймонд, в интернете.
x86-64.org

 

Booster
Почемуто я думол что подразумевается виндоз. Как в линуксе(порченом) и других осях мне не известно. Виндоз требует выравнивание стека на границу 4-х байт. Ткнуть - не знаю где это описано(мсдн для нубов). Вобщем следует соблюдать следующие условия для вызова системного апи(модель вызова не имеет значения, stdcall etc.):
> Стек выравнен на 4 байта.
> Страница стека доступна для чтения, записи и может быть расширена вниз при переполнении стека.
> Границы стека определены в TIB.
> Сброшен бит DF в регистре флагов.
> Изменяются регистры Eax, Ecx, Edx, Esp, EFlags.
> Валидные селекторы.
Для сервиса требования немного иные:
> Указатель на стек в регистре Edx, в регистре Eax номер сервиса. Остальное аналогично.
Наверно можно считать вопрос исчерпаным.

 

agrischuk
Что значит подразумевается и о таких вещах не говорят.
http://en.wikipedia.org/wiki/X86_calling_conventions

Речь не о этом.

Ещё бейсик вспомни.

А причём здесь процессор? Процессор x86 обрабатывает исключения выравнивания сам. stdcall это не процессор.

Clerk
И всё же, почему по-твоему ShowWindow работает не корректно?

 

у как всё запущено
*ABI = application binary interface
Да что пристали то к stdcall? других чтоли мало. я вообще о х64 платформе с её конвенцией говорю. agner.org calling_conventions.

 

Можешь теперь убедиться что там не все написано. На то оно и википедия.

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

Вопрос считаю исчерпаным.

 

Booster

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

 

asmfan

Ну что же поделать. Нашёл у Фога, что стек в Win32 должен быть выровнен на 4. Спасибо.

Окно должно быть нормального стиля (WS_OVERLAPPEDWINDOW), а показывается как WS_POPUP.

 

Увлекательное чтиво:
The history of calling conventions, part 1
The history of calling conventions, part 2
The history of calling conventions, part 3. The 32-bit x86 calling conventions.
The history of calling conventions, part 5: amd64

 

Booster

По моему, как я и предполагал не корректно работает твоё приложение, а ShowWindow() работает как и должна без ошибок. Для того чтобы определить где возникает ошибка нужно поставить точку останова в ядре на ExRaiseDatatypeMisalignment(). Мы увидим множество вызовов, причём все они из Win32k!xxxSendMessageEx(). Эта функция вызывается сервисом NtUserMessageCall, User32.dll имеет такоеже имя стуба. Если вызвать данный сервис с не выравненым стеком на границу 4-х байт, то сервис вернёт ноль. Далее уже ядерный отладчик не нужен. Ставим останов на инструкцию Ret 0x1C в этом стубе и видим множество вызовов, при которых сервис возвращает ноль(FALSE, при невыравненом стеке). В частности это вызовы из SendMessageTimeoutW() и твоей DefWindowProcA(). Далее хоть стек и выровнен, но изза внутреннего сбоя сообщения также не обрабатываются(вызываются ядерные кабаки, возможно в них ошибка происходит, но это весьма сложный код. Начинается с KiUserCallbackDispatcher(), у Twister хорошая стотья кстати.)).
Это и обьясняет почему окно не двигается - при инициализации какихто переменных, изза сбоя в первых посылках сообщений дальнейшая их обработка выполняется не может.
А как будет по твоему ?

 

Clerk
Мне нет причин тебе не верить.
Я о этой фиче не знал, спасибо за науку. Немного не понятно про x64, на асме под него кодить не доводилось. Но там походу жо.. со стеком.

 

В регистре EFLAGS есть бит AC (Alignment Check) - если он установлен, то процессор проверит каждый доступ в память, не только PUSH/POP/CALL/RET. И естественно - исключение.

 

AsmGuru62
Так вроде выравнивание стека проверяют функции винды, а не процессор. Ещё у Рихтера читал, что исключение в процессоре по-любому происходит, но x86 сам с этим может справляться. Получается c AC процессор его не обрабатывает?

 

AsmGuru62

Не проверит. Чтоб это проверку включенить нужно 18-й бит(AM) в регистре Cr0 установить в 1, а по дефолту он сброшен. Из юзермода никак не установить, а если даже его и взвести какимто способом, то первый вызов прерывания или Sysenter с невыравненным стеком приведёт к краху системы.

 

Не приведет. Это исключение работает только в 3-м кольце.

 

agrischuk
Не уверен.. При исполнении Iret с DPL=0 исключение возникнет когда CS будет перезагружен, или до того ?
[Ога, не падает. Забил вручную на двух процах Cr0.AM, при обращении к не выровненному стеку или данным(Ds) генерируется #AC, если взведён EFlags.AC. Странно это исключение обрабатывается:]

 

CS апдейтиться только после того как считываются значения для CS, EIP и EFLAGS:

http://www.intel.com/software/products/documentation/vlin/mergedprojects/analyzer_ec/mergedprojects/reference_olh/mergedprojects/instructions/instruct32_hh/vc143.htm

Удивительного в этом не вижу, ИМХО иначе оно бы плохо работало.

 

agrischuk

Это само собой понятно, я имел ввиду что если бы исключение произошло есчо до перезагрузки CS, то мы увидели бы голубой огонёк.
В принципе #AC абсолютно никакого отношения не имеет к необходимости выравнивания данных в Windows.