В чем суть WinApi?

После прочтения очередной главы по WinApi меня начал терзать вопрос,а так ли нужен ли этот API? Если все имеющееся в нем можно написать с помощью тех же библиотек Boost и STL. Надеюсь мы объясните в чем таки суть ,и почему использовать API выгодней(или не выгодней ) нежели выше указанные библиотеки?
  • Вопрос задан
  • 6625 просмотров
Решения вопроса 1
@Mercury13
Программист на «си с крестами» и не только
Windows API — это самый низкоуровневый интерфейс Windows, доступный прикладному программисту — в том плане, что он на долгосрочной поддержке и не изменится с Windows 11.

Поверх Windows API работают все BOOST и STL.

Пример: читать файл в 130 мегабайт по одному байту. Добавив асинхронного чтения через OVERLAPPED, я сумел это сделать менее чем за 2 секунды (это был поток общего назначения с виртуальными read(), write() и seek(); специализированный прикладной буфер даст ещё выигрыша, но и это хорошо). То же самое через FILE* — не дождался.

Пример второй, всё те же файлы. Дело в том, что Excel захватывает свои файлы на всё время, пока он открыт. Закрывать? — плохой выбор. Добавив один флажок в CreateFile, документы всё-таки стало возможным открывать при работающем Excel.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
VoidVolker
@VoidVolker Куратор тега Windows
Dark side eye. А у нас печеньки! А у вас?
Вы не так понимаете значение "Win API", давайте расшифрую: "Windows Application Programming Interface" или "Интерфейс программирования приложений ОС семейства Windows". Т.е., во-первых - через этот интерфейс осуществляется взаимодействие любых программ в ОС с самой системой. А что такое ОС? Это прослойка между железом и прикладными программами, которая занимается управлением ресурсами (процессор, память, и т.п.). Давайте уберем Win API - что останется? А ничего вообще не останется - даже ОС (ну может там загрузчик ОС останется или что-то еще совсем низкоуровневое). Тогда, как же прикладная программа может быть запущена? Ну, так же как и все ОС: загрузиться с загрузчика, инициализировать процессор, видеокарту, аудиокарту, клавиатуру, мышку, какие-то дополнительные железки - чтобы все это использовать. Только вот чтобы все это железо использовать - к нему часто нужные драйвера. А некоторые из них проприетарные (т.е. исходников нет). И это только начало. А процессоры-то у нас многоядерные - а программа одна, значит надо реализовывать поддержку нескольких потоков, управление памятью. А если несколько программ хочется запустить? Тогда, надо как-то по очереди давать пользоваться процессором - для этого надо писать управление потоками и памятью, при этом для обеих программ должен быть реализован одинаковый интерфейс. Что-то вроде API. Хмм, кажется где-то было что-то похожее? Ну да ладно. Кстати, если подняться чуть выше в категории - можно обнаружить, что кроме Win API, существует еще Linux API, BSD API - да и вообще в любой ОС есть свой API. И они отличаются - поэтому нельзя напрямую запустить приложение от одной ОС в другой ОС, т.к. приложение банально не будет знать "языка" этой ОС и как дать понять ОС что от неё хочет приложение. Так что любая ОС - это просто менеджер ресурсов ЭВМ, можно сказать "фреймворк", а API - это "язык", на котором приложение может общаться с этим фреймворком. Всякие стандартные и не стандартные библиотеки и прочее - это еще один уровень абстрагирования от "низкуровневого" ОС API. Над библиотеками делается какой-то еще один уровень абстрагирования и его опять называют фреймворком, а там и еще сверху часто бывает что-то. Так что получается, что фреймворк сидит на фреймворке и фреймворком погоняет. Ну и при этом львиная часть ресурсов ПК уходит на все эти абстрактные слои между фреймворками. Поэтому даже в 2017 году, после 27 лет развития браузеры по-прежнему тормозят.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы