Мне интересно, есть вообще смысл писать приложения (без GUI естесно) используя исключительно функции ntdll.dll, структуры UNICODE_STRING etc. вместо вместо всем известных функций из kernel32.dll, advapi32.dll etc. Вообще повысившаяся скорость (и намного она повысится?) оправдает чрезвычайную трудность разработки ? З.Ы. Ну не приходят мне в голову нормальные топики, только дурацкие лезут
Обычно в таких случаях возникает вопрос о совместимости, а трудностей никаких я и близко не вижу. Также не ясно почему "без GUI естесно".
Трудность я вижу только в том, что надо запомнить всяки nt zw перед названиями функций, да и функций поболее =) И ответь сам себе на вопрос: "как измениться производительность, если я напишу прогу 'Hello, world!' на Delphi, а потом тоже самое на MASM32?"
Трудностей особых нет, но в большинстве случаев нет смысла, потому что обычные неNative функции не такие медленные, если их отдизасмить и посмотреть последовательность вызовов. В большистве случаев неNative функции сделаны как раз для удобства программирования. А вот передти с ASCII на UNICODE - это реально даст прирост в скорости, потому что в NT/2000/XP все ASCII параметры перекодируются в UNICODE(за исключением некоторых, например GetProcAddress). И как сказал Quantumпроблемы с совместимостью действительно могут появиться, так что лучше не рисковать или сразу ориенироваться на возможные проблемы. Но эта действительно дает хорошие результаты при реализации техник системного программирования(например узнать информацию об описателе).
Моно поподробне? A то у мя тут прога написано почти на чистом ntdll, могут быть проблемы на других версиях NT ? Собственно я и взялся написать на ntdll, чтоб пахала на всех NT виндах.
Flasher Дело в том, что Microsoft официально через свою документацию поддерживает интерфейс Windows API. Но иначе обстоит дело с Native API - ntdll.dll - так как Microsoft не документирует эти функции, то автоматически она оставляет за собой право модифицировать их - менять параметры или вообще исключить функцию из Native API. В одим прекрастных момент ваша программа скажет "Не найденная указанная процедура в библиотеке NTDLL.DLL"
Вот с UNICODE - это да, это может дать прирост быстродействия. А как же, например, NtQueryDirectoryFile вместо FindFirstFile/FindNextFile - нативная гораздо быстрее выполнится. А насчет совместимости - у меня есть html-ка с адресами всех функий всех NT-систем. Тоесть если в какой-то системе этой функции не было, то это там показано. 412240491__syscalls.rar
mix_mix Конечно, даст. Если ориентироваться только на NT, то имеет смысл переходить на юникод. В вижуале для этого специально глобальная директива предусмотрена. Почему это гораздо быстрее???, ведь FindFirstFileExW именно NtQueryDirectoryFile и вызывает. А если файл уже найден, то не вызывает, так что в лучшем случае может оказаться даже быстрее. Ну и что? В MS могут наплевать на эту html-ку и в следующей NT что-нибудь поменять.
mix_mix: на счет использования native api, то тут широкие возможности, нежели с Windows API, советую почитать книгу Undocumented Windows 2000 Secrets. в ней описано многое. а на счет совместимости, то это "больной" вопрос действительно.
Чтобы небыло проблем с совместимостью, можно проверять версию ОС, и в соответствии с ней решать использовать Native-оптимизацию или нет.
Ну нет смысла забивать гвозди микроскопом. w32 api все-равно в итоге вызывает соответсвующие процедуры из ntdll. Обратная совместимость, все дела. Но если уж так хочется, вариант в стиле "садомазо" - sysenter\int 2eh, ага.
The_Lord_Impaler )) Короче, как я понял основные функции - не стоит, всякие вкусности, вроде NtShutdownSystem - можно, а из основных функций использовать только юникод варианты.
Бывают случаи, когда сами гвозди микроскопические. И чем их тогда забивать? To mix_mix: Если функции недокументированы, то MS в следующей версии может вообще засунуть их в другую dll. Это вспомогательные функции, и никто не должен о них знать .
Или пользователю просто не положено о них знать, пример - NtLoadDriver. Сразу обходит все защиты, менеджеры, понаставленные всюду МракоСофт. Что засунут в другую dll - врядли, как была ntdll, так ею и останется (не может изменится на какую-нибудь dotnetkernel.dll)
Господа, может кто нибудь привести аналогию NtQuerySystemInformation из неNativeAPI? Что то затрудняюсь. Вот к примеру преимущество. На счет UNICODE тоже большой прирост, системе не приходится тратить время на бесполезные преобразования. Да и вообще должно быть понятно - чем глубже - тем быстрее. А ntdll.dll по идее функции практически не экспортирует, как известно она являет собой переходники к NativeAPI ядра, из чего можно сделать недвусмысленный вывод...
У NtQuerySystemInformation нет прямого аналога из обычных апи. К этой функции обращается целая толпа апи, собирающих системную информацию, и являющихся обертками для вызова NtQuerySystemInformation с тем или иным классом информации. Например, Module32First/Next, Process32First/Next и т.д.
О том и речь, единственный минус Native - M$ может поменять что либо и не сказать об этом. А в остальном лично я предпочитаю использовать именно NativeAPI, т.к. это более рационально, а местами и более удобно. Кстати, привыкнув к UNICODE, ANSI будет казаться недоделанным атавизмом.
