Еще немного ликбеза... Когда я писал про ядро системы, я имел в виду именно код ядра системы, исполняющийся в защищенном режиме, а не код kernel32.dll (API-интерфейс ядра для user mode приложений).
Дело в том, что приложения не могут обращаться к защищенному коду ядра напрямую, им нужен "посредник", живущий на прикладном уровне. Эту задачу и решает Kernel32.dll - DLL, подгружаемая прямо в адресное пространство приложения, то есть в user mode.
Итак, небольшая поправка: приложения на Delphi, как и любые другие приложения, в принципе не могут обращаться к кода ядра напрямую. Напрямую можно вызывать API-функции, в том числе, являющиеся посредниками для кода ядра.
> А подобные выкрутасы с управлением памятью (это уже kernel) давали раза два синее окно смерти.
Вот это действительно сильно! Причем сразу по двум причинам:
1. Управление памятью через функции типа HeapAlloc, хоть формально и экспортируются из Kernel32.dll, реально почти на 100% исполняются непосредственно в user mode, поскольку они управляют адресным пространством самого приложения. "Ныряние" в защищенный код ядра при этом происходит крайне редко - только ради выделения физических страниц памяти на виртуальные адреса, что делается крупными блоками "про запас". Но, видимо, удалось хорошенько попортить содержимое памяти хипа.
2. Эта подсистема ядра ОС из наиболее "древних" и, следовательно, хорошо отлаженная. Уронить ее некорректными параметрами вызова не так-то просто... Хотя и возможно - в сети можно найти различные примеры кода для целенаправленного получения блюскринов.
На Си++ у меня таких прецедентов не было
. И слава Богу...
