My<cod/>.net
Есть ли еще смысл изучать низкоуровневое программирование WinAPI?
Есть ли смысл, имея все C#-managed-bliss,, вернуться к программированию Windows Петцольда и попытаться создать код w/ чисто WinAPI?
Чему можно из этого научиться? Не слишком ли она устарела, чтобы быть полезной?
Этот вопрос граничит с религиозным :) но я все равно выскажу свои мысли.
Я действительно вижу ценность в изучении Win32 API. Большинство, если не все, библиотеки GUI (управляемые или неуправляемые) приводят к вызовам Win32 API. Даже самые тщательные библиотеки не покрывают 100% из API, и поэтому всегда есть пробелы, которые нужно заткнуть прямыми API вызовами или P/invoking. некоторые имена оболочек вокруг API вызовов имеют аналогичные имена с базовыми API вызовами, но эти имена точно не являются самодокументирующими. Таким образом, понимание лежащего в основе API и используемой в нем терминологии поможет понять оболочку APIs и то, что они на самом деле делают.
Кроме того, если вы понимаете природу базовых APIs, которые используются фреймворками, то вы сделаете лучший выбор в отношении того, какие функции библиотеки вы должны использовать в данном сценарии.
Ваше здоровье!
Я придерживался стандарта C/C++ в течение многих лет, прежде чем выучить Win32 API, и, если быть совсем откровенным, "обучение Win32 API" - это не лучший технический опыт в моей жизни.
В одной руке Win32 API довольно прохладно. Это как расширение стандарта C API (кому нужен fopen , когда можно иметь CreateFile . Но я думаю, что UNIX/Linux/WhateverOS имеют те же самые функции gizmo. Во всяком случае, в Unix/Linux,-м у них есть "Everything is a file"-й. В Windows году у них есть "Everything is a... Window" (без шуток! Смотрите CreateWindow !).
С другой стороны, это наследие API. Вы будете иметь дело с необработанным C и необработанным C безумием.
- Это все равно что сказать своей структуре ее собственный размер, чтобы она прошла через указатель
void *к какой-нибудь функции Win32. - Обмен сообщениями также может быть довольно запутанным: смешивание объектов C++ с Win32 windows приводит к очень интересным примерам проблемы курицы или яйца (забавные моменты, когда вы пишете своего рода
delete this ;в методе класса). - Необходимость подкласса a WinProc, когда вы более знакомы с наследованием объектов, является разделением головы и менее оптимальным.
- И конечно, есть радость от того, что " почему в этом мире гидроразрыва они сделали это таким образом ?? "моменты, когда вы слишком часто ударяете головой по клавиатуре и возвращаетесь домой с ключами, выгравированными на лбу, просто потому, что кто-то посчитал более логичным написать API, чтобы включить изменение цвета "Window", не изменяя одно из его свойств, а попросив его к родительскому окну.
- и т.д.
В последней руке ( три руки ??? ), учтите, что некоторые люди, работающие с legacy APIs, сами используют устаревший стиль кода. Как только вы услышите " const - это для чайников" или " я не использую пространства имен, потому что они уменьшают скорость выполнения ", или даже лучше " Эй, кому нужен C++? Я кодирую в своей собственной марке объектно-ориентированного C!!! "(Без шуток... В профессиональной среде, и результат был довольно зрелищным...), вы почувствуете такой ужас, какой испытывают только осужденные перед гильотиной .
Так... В целом, это интересный опыт.
Редактировать
Перечитав этот пост, я вижу, что он может быть воспринят как чрезмерно негативный. Это не.
Иногда бывает интересно (а также неприятно) узнать, как эти вещи работают под капотом. Вы поймете, что, несмотря на огромные (невозможные?) ограничения, команда Win32 API проделала замечательную работу, чтобы быть уверенным, что все, от вас "olde Win16 program" до вашего "последнего приложения Win64 over-the-top", могут работать вместе, в прошлом, сейчас и в будущем.
Вопрос в том, действительно ли вы этого хотите?
Потому что тратить недели на то, чтобы сделать то, что можно было бы сделать (и сделать лучше) в других более высокоуровневых и/или объектно-ориентированных API, может быть довольно дестимулирующим (реальный жизненный опыт: 3 недели для Win API, против 4 часов на трех других языках и/или библиотеках).
В любом случае, вы найдете блог Рэймонда Чена очень интересным из-за его инсайдерского взгляда на Win API и его эволюцию в течение многих лет:
https://blogs.msdn.microsoft.com/oldnewthing/
Родные APIs - это "real" операционная система APIs. Библиотека .NET - это (за редким исключением) не более чем причудливая оболочка вокруг них. Так что да, я бы сказал, что любой, кто может понять .NET со всей его сложностью, может понять относительно мирские вещи, такие как разговор с API без помощи посредника.
Просто попробуйте сделать инъекцию DLL из управляемого кода. Это невозможно сделать. Вы будете вынуждены написать собственный код для этого, для оконных настроек, для реальных подклассов и дюжины других вещей.
Так что да: вы должны (должны) знать и то, и другое.
Редактировать: даже если вы планируете использовать P/Invoke.
Исходя из предположения, что вы создаете приложения, ориентированные на Windows:
- конечно, это может быть полезно для понимания более низких уровней системы - как они работают, как ваш код взаимодействует с ними (даже если только косвенно), и где у вас есть дополнительные опции, которые недоступны в абстракциях более высокого уровня
- бывают случаи, когда ваш код может быть недостаточно эффективным, высокопроизводительным или точным для ваших требований
- Тем не менее, во все большем количестве случаев люди вроде нас (которые никогда не учились "неуправляемому кодированию") смогут справиться с программированием, которое мы пытаемся сделать без "learning" Win32.
- Кроме того, есть много сайтов, которые предоставляют рабочие образцы, фрагменты кода и даже полностью функциональный исходный код, который вы можете "leverage" (заимствовать, плагиировать-но проверить, что вы соблюдаете любую лицензию на повторное использование или авторское право!) для заполнения любых пробелов, которые не обрабатываются библиотеками классов .NET framework (или библиотеками, которые можно скачать или лицензировать).
- Если вы можете выполнить необходимые вам подвиги, не путаясь в Win32, и вы делаете хорошую работу по разработке хорошо сформированного, читаемого управляемого кода, то я бы сказал, что освоение .NET будет лучшим выбором, чем распространение себя в двух очень разных средах.
- Если вам часто нужно использовать те функции Windows, которые не получили хорошего покрытия библиотеки классов Framework, то обязательно изучите необходимые навыки.
- Я лично провел слишком много времени, беспокоясь о "other areas" кодировании, которое я должен понимать, чтобы производить "хорошие программы", но есть много мазохистов, которые думают, что потребности и желания каждого человека похожи на их собственные. Несчастье любит компанию. :)
Исходя из предположения, что вы создаете приложения для мира "Web 2.0", или что это было бы так же полезно/выгодно для пользователей *NIX & MacOS:
- Придерживайтесь языков и компиляторов, которые ориентированы на максимально возможное количество кросс-платформенных сред.
- pure .NET в Visual Studio явно лучше, чем Win32, но разработка против библиотек MONO, возможно, с использованием Sharp Develop IDE, вероятно, является еще лучшим подходом.
- вы также можете потратить свое время на изучение Java, и эти навыки очень хорошо перенесутся на Программирование C# (плюс код Java теоретически будет работать на любой платформе с соответствующим JRE). Я слышал, что Java больше похоже на "пиши один раз, отлаживай везде", но это, вероятно, так же верно ,как (или даже больше) C#.
Это и есть ответ на любой подобный вопрос.. "имеет ли смысл изучать язык низкого уровня / api X, даже если есть язык более высокого уровня/api Y"
YES
Вы можете boot поднять свой Windows PC (или любой другой OS) и задать этот вопрос в SO, потому что несколько парней в Microsoft написали 16-битный код assembly, который загружает ваш OS.
Ваш браузер работает, потому что кто-то написал OS kernel в C, который обслуживает все запросы вашего браузера.
Он идет вплоть до скриптовых языков.
Большой или маленький, но всегда есть рынок и возможность написать что-то на любом уровне абстракции. Вы просто должны любить его и вписываться в правильную работу.
Ни один api / язык на любом уровне абстракции не является неуместным, если нет лучшего языка, конкурирующего на том же уровне .
Другой способ взглянуть на это: хороший пример из одной книги Майкла Абраша: программисту C было дано задание написать функцию для очистки экрана. Поскольку C был лучшей (более высокого уровня) абстракцией по сравнению с assembly и всем остальным, программист знал только C и знал его хорошо. Он сделал все, что мог - переместил курсор в каждое место на экране и очистил там символ. Он оптимизировал петлю и убедился, что она бежит так быстро, как только может. Но все равно он двигался медленно... пока не пришел какой-то парень и не сказал, что есть какая-то инструкция BIOS/VGA или что-то, что может мгновенно очистить экран.
Всегда полезно знать, по чему вы идете.
Да, по нескольким причинам:
1) .net обертывает Win32-код. .net обычно является более совершенной системой для кодирования, но наличие некоторых знаний о базовом уровне Win32 (ой, WinAPI теперь, когда есть и 64-битный код) укрепляет ваши знания о том, что происходит на самом деле.
2) в этой экономике лучше иметь некоторые преимущества перед другим парнем, когда вы ищете работу. Некоторые WinAPI опыт может обеспечить это для вас.
3) некоторые системные аспекты еще не доступны через фреймворк .net, и если вы хотите получить доступ к этим функциям, вам нужно будет использовать p/invoke (см. http://www.pinvoke.net для получения некоторой справки там). Наличие хотя бы небольшого опыта WinAPI сделает ваши усилия по разработке p/invoke намного более эффективными.
4) (добавлено) теперь, когда Win8 уже некоторое время существует, он все еще построен поверх WinAPI. iOS, Android, OS/X, и Linux-все они там, но WinAPI все еще будет там в течение многих-многих лет.
Лично мне не очень нравится Win32 API, но есть смысл изучить его, поскольку API позволит больше контролировать и эффективно использовать GUI, чем такой язык, как Visual Basic, и я считаю, что если вы собираетесь зарабатывать на жизнь написанием программного обеспечения, вы должны знать API, даже если вы не используете его напрямую. Это происходит по причинам, сходным с теми, по которым полезно изучать C, например, как strcpy занимает больше времени, чем копирование целого числа, или почему вы должны использовать указатели на массивы в качестве параметров функции вместо массивов по значению.
Изучение нового языка программирования или технологии происходит по одной из трех причин:
1. Нужно: вы начинаете проект по созданию веб-приложения и ничего не знаете о ASP.NET
2. Энтузиазм: вы очень взволнованы ASP.NET MVC. почему бы не попробовать это?
3. Свободное время: но у кого оно вообще есть?
Лучшая причина узнать что-то новое-это потребность. Если вам нужно сделать что-то, что не может сделать платформа .NET (например, производительность), то WinAPI-это ваше решение. До тех пор мы держим себя занятыми изучением .NET
Для большинства потребностей на рабочем столе Вам не нужно знать Win32, однако есть LOT Win32 не в .NET, но это в расходных материалах, которые могут оказаться меньше, чем 1% вашего приложения.
USB поддержка, HID поддержка, Windows Media фонд просто сорвался с моей головы. Есть много классных Vista API-х, доступных только из Win32.
Вы сделаете себе большое одолжение, научившись делать interop с Win32 API, если вы занимаетесь настольным программированием, потому что, когда вам нужно позвонить Win32, и вы это сделаете, вы не будете тратить недели на то, чтобы почесать голову.
Я видел код низкого уровня Windows API... это не очень красиво... Жаль, что я не могу этому научиться. Я думаю, что полезно изучить низкий уровень, как в C, поскольку вы лучше понимаете аппаратную архитектуру и то, как все это работает. Изучение старого Windows API... Я думаю, что этот материал можно оставить людям в Microsoft, которым, возможно, потребуется изучить его, чтобы построить языки более высокого уровня и API... они его построили, пусть с ним и мучаются ;-)
Однако, если вам случится найти ситуацию, когда вы чувствуете, что просто не можете сделать то, что вам нужно сделать на языке более высокого уровня (немногие и далеко между ними), тогда, возможно, вы начнете опасное погружение в этот мир.
да. взгляните на uTorrent, удивительный образец эффективности программного обеспечения. Половина его небольшого размера объясняется тем, что большая часть его основных компонентов была переписана, чтобы не использовать гаргатуанские библиотеки.
Многое из этого не может быть сделано без понимания того, как эти библиотеки взаимодействуют с нижними уровнями API
Важно знать, что доступно с Windows API. Я не думаю, что вам нужно выкручивать код с его помощью, но вы должны знать, как это работает. Платформа .NET содержит много функциональных возможностей, но она не предоставляет эквивалентов управляемого кода для всего Windows API. Иногда вам нужно немного приблизиться к металлу, и знание того, что там внизу и как он ведет себя, даст вам лучшее понимание того, как его использовать.
Это действительно то же самое, что и вопрос, Должен ли я изучать язык низкого уровня, такой как C (или даже ассемблер).
Кодирование в нем, конечно, медленнее (хотя, конечно, результат гораздо быстрее), но его истинное преимущество заключается в том, что вы получаете представление о том, что происходит на близком к системному уровне, а не просто понимание чужой метафоры того, что происходит.
Это также может быть лучше, когда вещи не будут работать хорошо, или достаточно быстро, или с той степенью детализации, которая вам нужна. (И сделайте хотя бы некоторые подклассы и суперклассы.)
Кроме некоторых очень особых случаев, когда вам нужен прямой доступ к APIs, я бы сказал NO.
Существует значительное время и усилия, необходимые для того, чтобы научиться правильно реализовывать собственные вызовы API, и возвращаемое значение просто не стоит того. Я бы предпочел потратить это время на изучение какой-нибудь новой горячей технологии или фреймворка, которые сделают вашу жизнь проще и программирование менее болезненным. Не десятилетиями устаревшие библиотеки COM, которые никто больше не использует (извините пользователей COM).
Пожалуйста, не забивай меня камнями за этот вид. Я знаю, что у многих инженеров здесь действительно любопытные души, и нет ничего плохого в том, чтобы узнать, как все работает. Любопытство-это хорошо и действительно помогает пониманию. Но с управленческой точки зрения я бы предпочел потратить неделю на изучение того, как разрабатывать Android приложения, а не как вызывать OLEs или COMs.
Я скажу об этом так. Я не люблю программировать на Win32 API. Это может быть боль по сравнению с управляемым кодом. BUT, я рад, что знаю это, потому что я могу писать программы, которые в противном случае я бы не смог. Я могу писать программы, которые другие люди не могут. Плюс это дает вам больше понимания того, что ваш управляемый код делает за кулисами.
Количество пользы, которую вы получаете от изучения Win32 API, (помимо общих идей, которые вы получаете от изучения того, как гайки и болты машины подходят друг к другу) зависит от того, чего вы пытаетесь достичь. Многие из Win32 API были красиво упакованы в .NET библиотечные классы, но не все из них. Если, например, вы хотите заняться серьезным аудио-программированием, эта часть Win32 API будет отличным предметом изучения, потому что только самые основные операции доступны из классов .NET. Последний раз, когда я проверял даже управляемую библиотеку DirectX DirectSound, было ужасно.
Под угрозой бесстыдной саморекламы....
Я только что столкнулся с ситуацией, когда Win32 API был моим единственным вариантом. Я хочу иметь разные подсказки для каждого элемента в A listbox. Я написал, как я это сделал по этому вопросу .