Здравствуйте, ononim, Вы писали:

O>Ну прежде чем делать какие либо выводы нужно бы заглянуть в WININET!DispatchAPICall+0x3f0. А предде чем заглядывать в вывод отладчика вообще нужно бы настроить символы..
Не понял, какие символы настроить? Это была всего лишь иллюстрация бездумного сохранения при вызове простейшей функции.
SSE2 используются не часто, ну и запоминайте их в тех редких случаях, когда их действительно используют

O>Это часть соглашений о вызове.
Lunix без этого обходится. Там как раз запоминается, что нужно, а не вообще все

O>Такое исключение не приведет к падению. 64 стек всегда аллоцируется кратным sizeof(void *) то есть 8. Добиться неровности можно только некорректным кодом, а не исключением в корректном коде, сгерененным компилятором с учетом известных ему правил. Если писать свой код на асме который делает add rsp, 3, а потом хвататься за свою голову остается только посочувтсовать. Как я уже сказал — меньше всего авторы соглашений колдогенерации в х64 позаботились о любителях теплого лампового ассемблера.
Это вообще не понял. В примере речь шла вообще не о стеке, а об исчезновении порядка ("антипереполнении") переменной x типа double. В программе в этом случае ей присваивается "чистый" 0.0E0. В ряде вычислений так и надо, но иногда антипереполнение — это признак ошибки расчета. Перехватывается аппаратное прерывание от FPU и корректируется переменная. После исключения программа продолжает нормальное (предусмотренное) выполнение. Это был пример на "жизнь после исключения".