Comments 31
Ваш пример с SystemParametersInfoW на Go плох. Во-первых - волшебные константы, во-вторых в Visual Studio ровно то же самое будет в одну строку: просто вызов функции, без загрузки DLL и получения адреса функции.
Ваша версия?
Моя, конечно
я имею ввиду хотелось бы увидеть вашу версию вызова
#include <windows.h>
int main(void) {SystemParametersInfo(SPI_SETDESKWALLPAPER, 0, (void*)L"image.jpg", SPIF_UPDATEINIFILE);}
Собственно, весь вызов - одна строка
Так стоп )
Пропустил сразу этот момент: вы точно понимаете разницу между линковкой и динамической загрузкой библиотеки?
Какой вообще был смысл приводить пример на Си в статье по Golang?
То есть это я(!) в статье привел официальный HelloWorld на сях и показал какой же он монструозный? Хехе...
Смысл в том, чтобы опровергнуть фразу "так красиво скрыты все скользкие моменты". Не красиво - из-за совершенно ненужной динамической загрузки. И не изящно из-за магических констант, о чем я сразу и написал
Если что в Go только такая загрузка и есть, что скорее хорошо чем наоборот, поскольку позволяет отлавливать ошибки и вообще как-то реагировать, например показать пользователю сообщение что "Библиотека не найдена".
Что касается "магических констант", то сие не более чем дело лично вашего вкуса, который навязывать окружающим (тем более так настойчиво) является плохим тоном.
То есть, зная, что никаких иных вариантов, кроме динамической загрузки нет, вы сознательно написано про "так красиво"? К тому же я почему-то уверен что механизм импортов в скомпиленых файлах используется...
Да, ну потому что оно красивое, хотя-бы за счет динамической типизации.
Механизм импортов разумеется используется в нативных библиотеках, которые затем динамически загружаются в Go.
Что касается динамической типизации - " сие не более чем дело лично вашего вкуса ". Про импорты вы пишете откровенную чушь - возьмите собранный EXE и посмотрите что он там импортирует. Исполняемый файл без импортов из Go? Нуну
У собранного бинарника на Go действительно нет внешних зависимостей, поэтому он такой большой. Или вы что-то другое имели ввиду?
Ой, это же вы мне писали про разницу между линковкой и динамической загрузкой, да? Идите подучите матчасть на примере механизма импорта и экспорта функций в исполняемых файлах, для начала на винде
Ну понятно, дискуссии не получится в очередной раз.
Не пробовали оценить свое поведение со стороны? К чему оно приведет и что по-вашему будет дальше?
Посмотрите на себя: попрекаете других тем, что делаете сами. Примеры этого вам уже привели, они остались без ответа.
Дискуссия была бы возможна, если бы именно ВЫ разбирались в механизмах ОС, о которой ведете речь. Поэтому идите учить матчасть. Потом, как выучите - смотреть в список импортов собранного EXE. Потом - жду комментариев "вы были правы".
Ладно, подскажу что будет дальше: я продолжу писать интересные статьи и общаться с умными и интересными читателями, а вас и все ваши сообщения буду просто игнорировать.
Жаль что на Хабре еще не приделали бан-листы, но что поделать.
Так что все чего вы добились это игнора, вне зависимости от вашего уровня профессонализма и талантов.
Всего хорошего.
Чуть более сложный пример использования win32 на Go - запуск программы с дополнительной библиотекой, как LD_PRELOAD в GNU/Linux: github.com/kmeaw/zdrct:inject.go
Это уж совсем скотство какое-то:
err = windows.CreateProcess(
nil,
S(exePath),
nil, nil, false,
windows.CREATE_SUSPENDED,
nil,
nil,
&si,
&pi,
)Тему с динамической загрузкой библиотек в Go не изучал, но все же полагаю есть какое-то более разумное решение чем через дочерний процесс.
Увы, в моём случае exePath указывает на чужую программу, написанную на C++. А для родного Go-кода есть плагины.
Спасибо за статью. Всегда хотел посмотреть, как можно на Go работать с WinAPI. (Звучит как ирония, но это не ирония).
А разработка под Windows является отдельной специальной дисциплиной, чемпионы которой запросто могут не знать обычный C/C++ вообще и всю разработку (даже серверную) вести на инструментах WinAPI.
Тому есть причины. WinAPI — древнее зло древняя система. Многие даже не представляют, насколько. Реймонд Чен как-то писал, что хейтеры обвиняют Майкрософт в нарушении стандартов по работе с Юникодом. На самом же деле, Майкрософт поддерживал Юникод задолго до появления Юникода стандартизации комитетом языка Си. И, между прочим, к этому времени десятки, если не сотни тысяч программистов уже использовали вариант Майкрософт, что не помешало стандартизировать нечто совсем другое (видимо, назло монополисту и массовому программисту). Аналогично, многие другие вещи появились и были adopted в WinAPI раньше и лучше, что и привело к массовому использованию MS-specific, особенно если всё равно запускать под виндами.
Конечно, кросс-платформенные приложения так писать не стоит главным образом, потому что не получится.
Эх, молодежь.... Да, так на заре писалось большинство программ под Windows - чистый WinAPI со всеми обработками message в бесконечном loop'е. Попривыкали блин фреймворками мыслить ;)
Примерно в 1997 году баловался я Visual Basic. Так там оказалось так же можно импортировать функции из dll и вызывать их. Так я и начал знакомство с WinAPI. Потом купил компакт-диск с Visual C++ 4.2, самоучитель по C++ Подбельского, и книгу "Программирование в Windows на C++". Ну и понеслось... Осваивал самостоятельно, интернет был в диковинку. Раз повезло, и попался в магазине набор MSDN на 6 CD. Кладезь инфы, много лет пользовался. Так вот и стал C++ником. Под WinAPI правда давненько не работал. Эх, ностальгия...
Статья отмечена как сложная, но рассуждения во вступлении не очень умные. Какие такие задачи Google отличаются от обывательских, и как это проявляется в языке общего назначения? Дальше статья обещает, что в Go работа с Win32API проще, чем в С и C++, и нагло врёт. Это биндинги к тем же самым функциям, только аргументы приходится обёртывать в unsafe.Pointer(). Но потом дошёл до вот этой части
Поэтому задача как-то серьезно взаимодействовать с WinAPI (дальше чем разовый вызов какой-то функции) — всегда была, есть и будет сложной.
А разработка под Windows является отдельной специальной дисциплиной, чемпионы которой запросто могут не знать обычный C/C++ вообще и всю разработку (даже серверную) вести на инструментах WinAPI.
Что за чушь? Нет ничего сложного в Win32API. И чего такого разработчики под Windows не знают в "обычном" C ?
Ещё одно враньё статьи - это обещанная работа с Win32API «из коробки». Судя по примеру в главе "WinAPI и графический интерфейс" из коробки есть только syscall, и приходится пользоваться либами, которые спрячут преобразования типов.
Ну и так, технические придирки. Почему вы всё время ссылаетесь на CEdit, это же класс из MFC ? В Win32API этот класс окна называется "Edit". Насчёт того, что он не поддерживает добавление текста - это вы плохо искали .
Статья отмечена как сложная, но рассуждения во вступлении не очень умные.
С козырей зашли, браво.
Какие такие задачи Google отличаются от обывательских, и как это проявляется в языке общего назначения?
У вас дома есть распределенный геокластер с тысячей сервисов обработки данных? Есть задачи централизованного управления и мониторинга всей этой кухни?
Соседи не жалуются? А то жужжит наверно адски.
Дальше статья обещает, что в Go работа с Win32API проще, чем в С и C++,
Лаконичнее, это когда исходного кода меньше, сам он чище и не вызывает приступов паники при просмотре.
Это биндинги к тем же самым функциям,
Есть всего один способ не использовать "биндинги к тем самым функциям" при работе с WinAPI из любого языка: устроиться в Microsoft и заняться там разработкой WinAPI.
Только в этом единственном случае вы не будете работать с клиентской стороны.
Что за чушь? Нет ничего сложного в Win32API.
Обожаю такой слог, сразу видно профессионала.
Если серьезно то WinAPI это отдельная область знаний, разбирающихся в этом разработчиков крайне мало — собственно как и в любой узкой нише.
Для иллюстрации этой сложности, в статье приведен официальный пример «Hello world» на C++ под Windows с отображением пустого окна через вызовы WinAPI функций.
Если для вас лично это просто то для большинства обычных (и тем более начинающих) разработчиков — нет.
И чего такого разработчики под Windows не знают в "обычном" C ?
Ситуация ровно обратная: обычные С-разработчики, писавшие для Linux или встариваемых систем мало чего поймут при разработке под Windows.
Для иллюстрации приведен пример с отдельной точкой входа WinMain. Опять же нет сомнений что для вас лично это прописные истины.
Ещё одно враньё статьи - это обещанная работа с Win32API «из коробки». Судя по примеру в главе "WinAPI и графический интерфейс" из коробки есть только syscall, и приходится пользоваться либами, которые спрячут преобразования типов.
Видимо не разобрались, преобразования типов как раз из коробки — обратите внимание на типы полей (их нет).
Почему вы всё время ссылаетесь на CEdit, это же класс из MFC ? В Win32API этот класс окна называется "Edit".
Ну потому что биндинги для CEdit уже были в готовом виде, реализовывать их самому для просто Edit в рамках статьи было бы слишком объемно.
Насчёт того, что он не поддерживает добавление текста - это вы плохо искали .
Ну ок, немного через одно место но возможно. Плюсую.
Но вообще спасибо за толковый разбор, хоть кто-то еще может такое на Хабре ;)
Смертный, успокойся...
Фишка в том, что вот эта обвязка в коде, даже не всегда обязательна. В том смысле, что это можно вполне зашаблонить и туда заглядывать "только по праздникам", а остальная часть работы с WinAPI, куда как более изящна и проста (как минимум для меня) чем в твоих примерах.
В целом, ты высказал хорошую мысль по поводу корпоративной побрякушки, и тут ты оказался прав. Я точно так же думал, думаю и буду думать. Ну, в отличии от тебя. К слову, ради интереса, глянь как устроен GLEW. Ну, тупо хидер глянь, как он цепляется к OpenGL и ведет обмен с апишкой. Тебе достаточно скачать два файлика под пару метров и у тебя актуальная версия огла. Да, внутри там трэш и угар, но ты этого не видишь, и на результате это не сказывается.
В общем, восторги неофита понимаю, но ты меня не убедил. Но всё равно спасибо, статья презабавная и реально полезная, если игнорировать твои выводы. Без обид.
А мы уже на ты?
Вроде на брудершафт не пили и лично не знакомы — точно есть повод? Или вас в лесу звери воспитывали?
Если по делу, то наверное последнее место куда имеет смысл заглядывать это OpenGL, тем более в статье про Go и WinAPI.
Да, да, да... Обиделся.
Именно поэтому и предложил глянуть на апи огла. Там ситуация куда как хуже чем на винапи, при этом, строение программы неотличимо, от винапишного. В общем, как обычно на Хабре. Увидел блестящую цацку и понёс в массы, ну и просто понёс. Ладно уж, оставайся в плену своих иллюзий.
Просто оставлю это здесь: fyne
Чтобы умельцы развивали уже имеющуюся библиотеку для GUI, а не писали свою "с нуля"... Тем более, что она кроссплатформенная, а не только под Windows
«Бобер выдыхай»: Go, WinAPI и ассемблер