Comments 13
прочитал полностью, отлично
у меня вопрос, судя по уровню вашего знания предмета, вам много приходится работать с unmanaged-кодом
а можете про это больше рассказать? зачем, почему, какие задачи это решает?
На самом деле, работать с unmanaged-кодом приходится не много. По факту, буквально два-три случая вынудили меня изучить этот раздел .NET.

Несмотря на всю мощь фреймворка, многие узкоспециализированные задачи на нем не решаются. Например, установка integrity level (англ.) с помощью SDDL невозможна во встроенных классах безопасности .NET (попытка подать SDDL с описанием integrity level не вызывает ошибки, но не выполняет требуемых действий), поэтому приходится работать через p/invoke. Ну а COM применяется достаточно часто в больших проектах, а писать их на C# куда проще, чем на С++. Мне показалось проще один раз изучить все проблемы взаимодействия, чем учиться правильно и грамотно писать на С++.

Отмечу, что многие задачи на C# решить все-таки не получится. Например, работа с MAPI требует такой тонны рутинной работы по COM Interop (здесь фреймворк не справляется), что легче написать требуемый код на C++, обернуть его с помощью ATL в COM и заинтеропить уже получившийся объект. Получается что-то вроде Redemption, только заточенного под собственные нужды.
Есть, конечно. Тот же самый Redemption. Но он, во-первых, стоит денег, а во-вторых — это дыра в безопасности.
Нам тоже приходится много взаимодействовать с неуправляемым кодом. На это две причины: взаимодействие через COM (например, с Microsoft Office или 1C) и работа с нативными длл (последнее — на Mobile Devices через .NET CF).

С первым пунктом всё должно быть очевидно — лёгкость разработки на .NET приводит к экономии времени, которая в несколько раз превышает затраты на исследования COM Interop.

Во втором пункте приходится работать с функциями, управляющими специфичными для устройств оборудованием — WiFi-адаптером, вибратором, сканером штрихкодов. Что касается последних — то там вообще никакой унификации нет, каждый производитель предлагает свой подход.
Следуем заметить что если вы создаете деволтный DLL Win32 проект под Visual Studio (ну, тот который 42 возвращает) то с ходу работать с P/Invoke он не будет — нужно обернуть все элементы в extern «C» {… }. Или указать calling convention.
UFO landed and left these words here
На самом деле в настройках DllImport есть возможность указать в качестве соглашения thiscall, а вот fastcall действительно не поддерживается.

То есть мы можем работать через stdcall, cdecl и thiscall.
UFO landed and left these words here
Конечно нужно продолжение, тема очень интересна, а освещается, особенно на русскоязычных ресурсах редко. И у вас, на мой взгляд, отлично получается объяснять простыми словами сложные вещи.
Все WinAPI функции используют соглашение stdcall.

Не все. Функции, которые принимают ... используют соглашение cdecl aka WINAPIV, ибо в случае с ... вызываемая функция не может сама очистить стек.
Only those users with full accounts are able to leave comments. Log in, please.