Т.е. у приложений отобрали их законное право вытворять со своим стеком что хотят? Как-то не верится.

Не совсем так. Приложение может вытворять со своим стеком все, что ему вздумается. Но в результате:

1. Отладчик не покажет корректный корректный стек. Это верно и для x86, но в отличие от x64 там позволяются куда большие вольности;

2. Не будет корректно работать stack unwinding при обработке исключения. Плохо в этом случае будет исключительно самому приложению.

Ну и понятное дело, что при вызовах системных API параметры должны идти в правильном порядке.

Ну то есть сохранение всё таки есть, просто в другом куске ядра.

Есть конечно. Только работает оно совсем не так, как я себе представлял.

Тогда это приложение работать не будет. �то все равно, как если бы прилоение решило параметры функций в другом порядке указывать.

Т.е. у приложений отобрали их законное право вытворять со своим стеком что хотят? Как-то не верится. Всякие cconv всё таки придуманы не только под процессор, но и под языки.

При переходе в kernel mode на стеке будет создан trap frame, куда ebx и сохранится

Ну то есть сохранение всё таки есть, просто в другом куске ядра.

А если приложение на соглашения положит?

Тогда это приложение работать не будет. Это все равно, как если бы прилоение решило параметры функций в другом порядке указывать.

Вот внутри произвольной функции стоит: mov ebx, 3. И тут пришла пора переключить поток. Кто этот ebx сохранит?

При переходе в kernel mode на стеке будет создан trap frame, куда ebx и сохранится. На amd64 возможны варианты. Вообще-то поскольку rbx - non volatile, он сохраняется в exception frame, но если ситуации когда он сохраняется и в trap frame.

Получается, что к моменту непосредственного переключения большинство регистров уже сидит в стеке.