Почему в .NET реализованы не все WinApi функции?

#c_sharp #net #winapi

Во всех книжках пропагандируют управляемый код и говорят, что в неуправляемый код
практически не придется окунаться.

Однако, некоторых WinApi аналогов нету в .NET=> приходится лезть в неуправляемый
код, оборачивать библиотеку и изобретать велосипед.

Вроде, у майков есть и все исходники и ничего им мешать не должно, что бы перенести
весь WinApi .NET, но по какой-то причине часть мощных функций так и остались в WinApi...
    

Ответы

Ответ 1

То, что в каких-то книгах пропагандируется чисто managed код - это просто маркетинговый
ход. 

Дело в том, разработчики .NET не ставили себе цель полностью заменить WinAPI. 

Основная идея .NET - предоставить новую, более простую и удобную платформу для разработки,
оставив при этом совместимость с существующими платформами - прежде всего, WinAPI и COM.

В определенных случаях это может быть достаточно близко к реальности - например в
web-разработке вы скорее всего P/Invoke не увидите. Но при разработке под десктоп (особенно
под WinForms) или под не-веб сервер вы будете регулярно натыкаться на на P/Invoke. 

Более того, со временем вы поймете, насколько тонок уровень абстракции, предоставляемый
.NET, и насколько мало управляемый код отличается от неуправляемого.


Ответ 2

Вообще интересный вопрос, который скорее относится к тому, почему .NET Framework
такой какой он есть. И ответ очевидно нужно искать в том времени когда он создавался.
А создавался он в попытке сделать "лучше чем Java", и в какой-то степени им это удалось.
Например, локализация, работа с датой/временем/таймзонами в .NET сразу было сделано
на лучшем уровне (воспоминания многолетней давности, вероятно сейчас ситуация уже изменилась).
Во времена .NET 1.0/1.1 набор классов/методов вообще смотрелся довольно бледно по сравнению
с WinAPI, с тех пор стало намного полнее.

С самых первых версий дотнета был Interop и P/Invoke, который собственно позволяет
вызвать WinAPI, и собственно что в этом плохого? Я бы не сказал что это изобретение
велосипеда -- вы же просто вызываете внешнюю функцию в неуправляемом коде, единственное
-- сделайте это правильно, вот и всё.

Дальше нужно уже видимо говорить предметно -- чего конкретно нехватает, каких функций.

Напомню про список:
Microsoft Win32 to Microsoft .NET Framework API Map
https://msdn.microsoft.com/en-us/library/aa302340.aspx


Ответ 3

Изначально .NET действительно создавался как альтернатива Java после очередных разборок
с Sun Microsystems, по поводу того, что улучшения и изменения внесенные Microsoft в
виртуальную машину Java для Windows, привели к несовместимости Java-кода на разных
платформах, что противоречит идеологии Java.

Т.к. .NET довольно долго даже не пытались сделать кроссплатформенным, и даже сейчас
он таковым является весьма условно, то со временем, для наиболее распространенных вызовов
Win API, на тот момент единственного Win32, в .NET были включены готовые оболочки.
Редко используемые функции всегда можно подключить руками, когда это понадобится.

Не углубляясь в детали и различия, .NET, как и Java, является виртуальной машиной.
Это позволяет с одной стороны забыть о аппаратных различиях платформ, с другой накладывает
ряд существенных ограничений, в частности, на прямой доступ к "железу". Значительная
часть API, это библиотеки функций для удобного использования низкоуровневых обращений
к драйверам, устройствам и функциям ядра ОС, которые, так или иначе, зависят от аппаратной
платформы. Например DirectX, к которому, кстати, до сих пор не родной оболочки в .NET,
WPF не в счет, там нельзя управлять процессом рендеринга.


Ответ 4

Какое WinAPI, .NET должен был быть самодостаточным и кроссплатформенным.


Ответ 5

Всё там есть. Просто скрыто.

.Net как бы язык более высокого уровня, чем cpp. 

А winAPI это windows aplication program interface, говоря простым языком правила
взаимодействия окон в windows.
Обойти их нельзя, на этом базируется винда.