Какую литературу выбрать для изучения WINAPI?

Question

[sddvxd]

Доброго времени суток

Стал лезть на MSDN - PVOID, HANDLE, PWSTR и прочие страшные названия типов спугнули меня и поэтому я решил прибегнуть к старым добрым книгам

Если еще знаете такую литературу где описаны основы работы с памятью (внедрение DLL, хуки) и вообще как все это в винде устроено - буду благодарен если посоветуете

Comments

[Adamos]

Извините за оффтоп, но вы уверены, что хотите потратить свое время именно на изучение этих дебрей?
Востребованность на "крестовиков" давно ушла в "кроссплатформенный", "высоконагруженный", "распараллеленный" и прочие распознавания образов и нейронные сети. Копание в древних виндовских потрохах - не самая популярная ниша уже сейчас. Уж лучше с POSIX познакомиться поближе, имхо.

[sddvxd]

Adamos, мне просто это интересно, думаю знания в этой области не будут лишними

[Adamos]

sddvxd, дело в том, что в IT практически невозможно нахвататься знаний по учебникам "про запас, пусть будут". То, что не получается применить в работе - не усваивается и только тратит время.

[sddvxd]

Adamos, у меня есть практические задания. например: Создать приложение для отслеживая копирования файлов с сетевого диска. Я решил что буду применять хуки для вылавливания функции создания файла и с помощью регулярного выражения вычленять название диска. Моих текущих знаний не хватает чтобы все это реализовать

[Adamos]

sddvxd, да балуйтесь, ради бога. Просто не рассчитывайте, что этот опыт конвертируется во что-либо ценное. Таких утилиток за годы существования Виндов написаны вагоны, новые мало кому нужны. А когда подобные функции требуются в современных проектах - то используется не голый WinAPI, а сто лет как отлаженная высокоуровневая обертка вокруг него на каком-нибудь Шарпе.

[sddvxd]

Adamos, соглашусь с вами что улучшения языка которые помогают сокращать время на написание кода делают работу программиста продуктивнее и з/п соответственно его будет выше. Но мне кажется в наших реалиях это не много не так работает, вернее работает и довольно-таки хорошо, но только у успешных компаний которые идут в ногу с технологиями.
Я вообще начинал с ассемблера так как считал что тот кто владеет этим языком тот может вообще все, но со временем понял что это гиблое дело, перешел на питон. Год на питоне пописал - открыл для c++: столько возможностей, столько типов.

Я считаю что лучше изучить основы работы системы, прежде чем изучать какое-нибудь API не зная как работают те или иные функции, так я просто деградирую

[Adamos]

sddvxd, увы, востребованы не столько знания, сколько навыки.
Если в Сях и Крестах мне ассемблер еще как-то помогал, то в Пыхе, например, его применить практически некуда.
Если быть реалистом, стоит все-таки прокачивать именно навыки решения востребованных задач. Если попутно удастся копнуть глубже в тему - это прекрасно. Но становиться высоклассным специалистом в невостребованной области - чревато большими разочарованиям... да и невозможно стать именно высококлассным спецом, если область применения знаний не востребована и не развивается.
Где сейчас спецы по Дельфям, FoxPro, MFC?

[sddvxd]

Adamos, то-есть вы считаете что изучение winapi, архитектуру, устройство памяти в windows можно опустить?
Если вы уже наступали, как вы считаете на эти "грабли", то мне стоит прислушаться к вашему совету

[Adamos]

sddvxd, нет, именно на эти грабли я не наступал.
Я плотно писал на С/С++ лет десять, но это были прикладные программы (не дельфоподобные, конечно, но и не лезущие всерьез в систему). WinAPI мне за это время понадобился только однажды, и изучения в этот раз не потребовалось - обошелся гуглением.
Если вы собираетесь писать низкоуровневые утилиты под Винды - возможно, вам нужны эти знания. Если вы реально считаете это перспективным направлением развития. Я в этом, признаться, сомневаюсь, но это только мое мнение. Особенно сомнительное оттого, что Виндами я в последние годы практически не пользуюсь.

Answer 1

[Stalker_RED]

Вообще, в книгах Марка Руссиновича довольно круто все это описывается. Но боюсь, что уровень там не для совсем начинающих.

Answer 2

[15432]

Допустим, такое вот
https://www.ozon.ru/context/detail/id/20285651/

Comments

[sddvxd]

книга конечно полезная, но ничего из вышеперечисленного она не имеет

[sddvxd]

все-равно спасибо. прочту

Answer 3

[Fil]

С ума сошли предлагать Руссиновича. Книга крутая, но точно не первая для ознакомления с ОС. Рихтера советую, это тоже классика

Answer 4

[dmshar]

Еще немного классики.
https://www.ozon.ru/context/detail/id/2575245/
Довольно доходчиво написано.

Answer 5

[res2001]

PVOID - void*
PWSTR - wchar_t *
HANDLE - просто целое, подробностей, обычно, знать не нужно - это идентификатор объекта (хэндл).
И берите Русиновича по совету 15432

Comments

[dmshar]

Вообще-то говоря, HANDLE - это указатель, а не "просто целое".
Если таких подробностей не знать, то зачем тогда (и как) разбираться в WinAPI?

[res2001]

dmshar, я не против, давно в windows.h не заглядывал.
К тому же кто мешает рассматривать указатель как целое?
size_t intval = (size_t)handleval;
Вам сильно помогло знание того что handle это указатель? Я когда-то знал, но за ненадобностью подзабыл.
Все равно то на что указывает HANDLE вы используете с помощью функций WinAPI. HANDLE - это абстракция для обозначения дескриптора/идентификатора объекта. Он может быть указателем, но запросто может им и не быть.

[Adamos]

res2001, обычно знание недокументированных деталей реализации скорее вредно, так как их использование вполне может стать причиной проблем после обновления.
Однако то, что HANDLE - это на самом деле PVOID, указано в документации.
И сразу наводит на мысль, что это самое "целое, без подробностей", например, при переходе на x64 удлинится вдвое и может преподнести сюрприз, если вы имели неосторожность с ним работать не только в функциях WinAPI ;)