Недокументированные функции; Загрузка 32-х битных DLL в 64-х битный процесс.
Скажите, а невозможность загрузки в 64bit-процесс 32bit DLL - фатальна, или же возможны какие-то хаки, недокументированные обходные пути?
Отвечаю здесь, так как ответ получился слушком длинным.
Во-первых, про любые недокументированные возможности меня спрашивать бесполезно. Даже если такая возможность существует, я всё равно о ней не расскажу. Этому есть несколько причин, включая очевидные вещи вроде NDA, законе об авторском праве и т.д. Еще одна причина, почему я не горю желанием это делать, - это то, что раскрывая детали реализации того или иного компонента, я тем самым лишаю этот компонент возможности развиваться и улучшатся в следующих версиях.
Почему так? Приведу пример. Создавая класс, разработчик задаёт каждому его члену определённый уровень доступа:
- public – для членов класса, составляющих публичный интерфейс класса;
- protected – для членов класса, определяющих внутренний интерфейс класса;
- private – для членов, являющихся деталями реализации класса, о которых остальным знать не положено.
Сокрытие части функциональности класса облегчает будущие исправления и добавление новой функциональности, так как код может быть изменен при условии, что публичный интерфейс не изменяется. Windows, как и любой другой продукт, никак не отличается от класса в этом плане.
Недокументированные возможности существуют. Причины из недокументированности ровно те же самые, что и причины для существования private и protected членов класса. И если я (или другой инсайдер) поделиться с Интернетом описанием какой-либо недокументированной функции, то эта функция мигом становиться частью публичного интерфейса, так как появляются приложения, использующие эту функцию. Шишки за то, что такая программа перестаёт работать в следующей версии Windows, естественно сыпятся на авторов Windows.
Во-вторых, про загрузку 32-х битной DLL в 64-х битный процесс. Это можно сделать, если при вызове LoadLibraryEx указать флаг LOAD_LIBRARY_AS_DATAFILE. Это позволяет загрузить ресурсы, хранящиеся в этой DLL, но не позволяет выполнять код в DLL.
Если же нужно загрузить 32-х битную DLL в 64-х битный и выполнить код из неё, то это невозможно в принципе. Для этого нужно загрузить и проинициализировать Wow64, не говоря уже о структурах в ядре. Короче нужно будет на ходу превратить процесс в 32-х битный. Проще создать новый. 
Спасибо, понятно.
Хотелось узнать, не изобретаю ли я велосипед.
Что касается “создать новый процесс” - была такая идея, regsvr32 так и делает
В частности, если речь идёт о inproc COM-сервере в виде 32bit DLL, - нет ли (не планируется ли заведение) некоего 32bit host process (типа svchost.exe) специально для обеспечения межбитной COM-совместимости? Тем более, что у COM уже есть готовые средства межпроцессного маршалинга, изобретать которые заново не интересно…
Обычно для этого используют DllSurrogate.
извините. it’s not a mercy.
зачастую, _только_ недокументированные функции реализуют нужный функционал.
Ну и что? Даже если так, это совсем не оправдывает их использование. Одна из заповедей менеджеров программных (да и не только программных) проектов - “manage your dependencies”. Если срываются сроки поставки компонента, от которого зависит данное приложение - срываются сроки поставки этого приложения. Если нарушается контракт (публичный интерефейс) между прилодением и библиотекой - страдает приложение. А операционная система - это библиотека.
Кроме того, 9 из 10 раз когда звучит это утверждение, это не так. Обычно существует альтернативное решение. Оно кажется дороже в данный момент, но в перспективе это экономия на спичках.
Забыто еще одно применение недок.функций: создание скрытого функционала.
Именно об этом я и говорю. Любая библиотека/программа содержит в себе “скрытый функционал”. В том числе любое приложение с открытым исходным кодом.