Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
прочитал полностью, отлично
у меня вопрос, судя по уровню вашего знания предмета, вам много приходится работать с unmanaged-кодом
а можете про это больше рассказать? зачем, почему, какие задачи это решает?
у меня вопрос, судя по уровню вашего знания предмета, вам много приходится работать с unmanaged-кодом
а можете про это больше рассказать? зачем, почему, какие задачи это решает?
На самом деле, работать с unmanaged-кодом приходится не много. По факту, буквально два-три случая вынудили меня изучить этот раздел .NET.
Несмотря на всю мощь фреймворка, многие узкоспециализированные задачи на нем не решаются. Например, установка integrity level (англ.) с помощью SDDL невозможна во встроенных классах безопасности .NET (попытка подать SDDL с описанием integrity level не вызывает ошибки, но не выполняет требуемых действий), поэтому приходится работать через p/invoke. Ну а COM применяется достаточно часто в больших проектах, а писать их на C# куда проще, чем на С++. Мне показалось проще один раз изучить все проблемы взаимодействия, чем учиться правильно и грамотно писать на С++.
Отмечу, что многие задачи на C# решить все-таки не получится. Например, работа с MAPI требует такой тонны рутинной работы по COM Interop (здесь фреймворк не справляется), что легче написать требуемый код на C++, обернуть его с помощью ATL в COM и заинтеропить уже получившийся объект. Получается что-то вроде Redemption, только заточенного под собственные нужды.
Несмотря на всю мощь фреймворка, многие узкоспециализированные задачи на нем не решаются. Например, установка integrity level (англ.) с помощью SDDL невозможна во встроенных классах безопасности .NET (попытка подать SDDL с описанием integrity level не вызывает ошибки, но не выполняет требуемых действий), поэтому приходится работать через p/invoke. Ну а COM применяется достаточно часто в больших проектах, а писать их на C# куда проще, чем на С++. Мне показалось проще один раз изучить все проблемы взаимодействия, чем учиться правильно и грамотно писать на С++.
Отмечу, что многие задачи на C# решить все-таки не получится. Например, работа с MAPI требует такой тонны рутинной работы по COM Interop (здесь фреймворк не справляется), что легче написать требуемый код на C++, обернуть его с помощью ATL в COM и заинтеропить уже получившийся объект. Получается что-то вроде Redemption, только заточенного под собственные нужды.
Нам тоже приходится много взаимодействовать с неуправляемым кодом. На это две причины: взаимодействие через COM (например, с Microsoft Office или 1C) и работа с нативными длл (последнее — на Mobile Devices через .NET CF).
С первым пунктом всё должно быть очевидно — лёгкость разработки на .NET приводит к экономии времени, которая в несколько раз превышает затраты на исследования COM Interop.
Во втором пункте приходится работать с функциями, управляющими специфичными для устройств оборудованием — WiFi-адаптером, вибратором, сканером штрихкодов. Что касается последних — то там вообще никакой унификации нет, каждый производитель предлагает свой подход.
С первым пунктом всё должно быть очевидно — лёгкость разработки на .NET приводит к экономии времени, которая в несколько раз превышает затраты на исследования COM Interop.
Во втором пункте приходится работать с функциями, управляющими специфичными для устройств оборудованием — WiFi-адаптером, вибратором, сканером штрихкодов. Что касается последних — то там вообще никакой унификации нет, каждый производитель предлагает свой подход.
Следуем заметить что если вы создаете деволтный DLL Win32 проект под Visual Studio (ну, тот который 42 возвращает) то с ходу работать с P/Invoke он не будет — нужно обернуть все элементы в extern «C» {… }. Или указать calling convention.
Статья просто супер!
Конечно нужно продолжение, тема очень интересна, а освещается, особенно на русскоязычных ресурсах редко. И у вас, на мой взгляд, отлично получается объяснять простыми словами сложные вещи.
Все WinAPI функции используют соглашение stdcall.
Не все. Функции, которые принимают
... используют соглашение cdecl aka WINAPIV, ибо в случае с ... вызываемая функция не может сама очистить стек.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
.NET в unmanaged окружении: platform invoke или что такое LPTSTR