← All posts tagged winapi

lovesan
Python programming nopython кроссплатформенность например juick.com

Нет, чуваки, это может у вас на прыщах с питоном все заебись и работает, но блять.

Я лично заебался слушать все эти телеги про кроссплатформенность. Вся эта "кроссплатформенность" в 99% случаев упирается в писание кода под прыщами и натягивание прыщевой модели программ на винды, вплоть до установки костылей типа Cygwin.

Натягивание это выглядит как говно, глючит и тормозит, но прыщеадепты каким-то образом умудряются этим объяснять неудобность Windows вообще, и в частности, разработки приложений под неё.

Бля, по мне так убежденных разработчиков-линуксоидов вообще нельзя пускать под винду.

Они не осиливают SXS(в каком опенсорсном проекте с корнями в линуксе это используется? Хоть один назовите!).

Не осиливают распределения по директориям винды, и выстраивают в отдельной директории программы свой тупорылый FHS(не знают и не желают знать, что, например, нужно класть в Program Files(или в директорию с бинарниками программы, если она не в Program Files), а что нужно класть в %APPDATA%, например. Не понимают, что в %WINDIR%\system32 нельзя складывать ничего вообще, и тем более нельзя затирать существующие там библиотеки и программы.

Не осиливают нормально работать с именами файлов(начиная с имен с пробелами).

Не понимают, в большинстве, своем что PATH менять противопоказано.

Игнорируют все вменяемые механизмы межпроцессного взаимодействия и модульности(начиная с COM), и используют максимум сокеты и пайпы(прямо как в 70х).

Совершенно не заботятся о существовании различных сред исполнения программ и рантаймов языков программирования, например о .NET, и соврешенно не задумываются об интеграции с ними.

Игнорируют реестр, либо же наоборот, засирают HKLM разнообразным говном.

Кладут болт на систему безопасности Windows, вообще никак не принимают её в расчет.

Игнорируют SEH и VEH, вместо этого используя в приложениях урезанные сигналы из CRT, а то и setjmp/longjmp.

Вообще, перебарщивают с использованием CRT, вместо системного API. Чуваки! С CRT на Windows работать не очень приятно, не полезно и не безопасно. И это не проблема WinAPI, это проблема CRT — ей уже срать сколько лет, и естественно она не может даже близко выразить всю функциональность системы.

Не осиливают нормальную реализацию многопоточных приложений(привыкли форкать то).

Используют cmd.exe из программ(на манер вызова шелла из сишных программ в прыщах) — дада, и такое видел. Чуваки! cmd.exe это артефакт совместимости с DOS'ом, не надо его использовать вообще даже для скриптинга(PowerShell есть), не говоря уже про что-либо серьезнее.

Не осиливают и не используют не то что даже механизмы глобализации и интернационализации Windows, а даже работу с кодировками и юникодом(используют "A"-варианты функций и т.д.).

Если говорить о "кроссплатформенных" GUI-тулкитах — не используют системные виджеты и функционал "тем", и тем более не стараются даже рисовать свои виджеты "похоже" на них(видели GTK+ под виндой? Это пиздец!).

Тащат повсюду свой сраный кривой OpenGL, вместо использования навороченного стека графических технологий Windows(Direct3D, Direct2D, DirectWrite etc.)

Пишут на сишечке или C++!111

Сервисы? WMI? AD? Интеграция с шеллом? Эти понятия им, за редким исключением, вообще не знакомы.

И так далее, и тому подобное. Я просто устал перечислять, но таких моментов еще вагон.

И да, если возвращаться к ссылке в начала — Python под виндой это пиздец и говно.

Вообще, есть, конечно, исключения. Ну например, VirtualBox. Но такие исключения только подтверждают правило.
lovesan
mono GUI .net кроссплатформенность WPF А откуда пошло такое мнение, что WPF на Mono не портируют потому, что там используется много платформозависимых фич?

В Windows.Forms таких фич гораздо больше, но таки их портировали.

WPF — кроссплатформенный фреймворк, но он огромен и очень сложен. Кому кроме MS по силам разработать аналог, или хотя бы просто портировать его?

WPF не портируют по той причине, что это гигантский и очень сложный проект. Реально дико сложный. И он создан усилиями огромной команды высокооплачиваемых профессионалов. Группе энтузиастов такое просто не повторить. Ну то есть, тупо такой расклад:
Возьмем людей из опенсорса, которым интересно Mono. Возьмем из них тех, кто разбирается в GUI-фреймворках(в том числе знаком с эзотерическими подходами к GUI, типа реактивности), двумерной и трехмерной векторной графике, обработке видео, электронной, и не только, электронной типографике, accessibility и другом. Теперь возьмем из всех них тех, кому за все это дело проект Mono готов платить. Сколько народу получилось? Вот-вот.

И вот это единственная причина, а никакая не завязанность на WinAPI, никакие не козни Microsoft(MS, кстати, наоборот, даже помогает разработчикам Mono), и не что-либо еще.
lovesan
Python Ruby Lisp programming nopython Что-то давно не писал про лисп.

Вот мне что бывает действительно непонятно, в контексте популярности языков программирования, и предпочтения людьми одних языков другим, так это нахуя люди используют говно типа бидона или руби когда есть лисп, в частности — CL?

Нет, серьезно, я понимаю, почему люди берут Си, C++, C#, Java, да даже PHP, но бля.
Нет, конечно, многие, если говорить про настоящее время, про сейчас — возможно, многие берут тот же питон потому, что для него много чего якобы есть — библиотеки, фреймворки, особенно под веб, ну и так далее. Под него да, намного больше вакансий, чем под лисп(но в то же время, по сравнению с теми же Java или PHP — Python невероятно маргинальный язык. А уж Ruby — тем более).

Но все-таки — почему вокруг того же питона такой хайп, почему он был изначально, даже когда в питон не вкладывался гугл, даже когда никаких особо фреймворков под него и не было?

А почему руби? Не, ну рельсы — да, но все, больше там смотреть не на что.

И есть лисп.

Лисп, даже Common Lisp — намного проще бидонов и рубей. Серьезно. В CL 27 специальных операторов, и когда вы понимаете что они делают(а понимать там особо и нечего) — все, вы знаете весь язык; остальное это стандартная библиотека — ну да, она крупная и местами кривая, но вы не обязаны ее заучивать наизусть чтобы продуктивно пользоваться языком, как не обязаны заучивать всю инфраструктуру Java/.NET чтобы писать на жабе и сишарпе, и как не обязаны вызубривать API всех свободных библиотек на бидоне, чтобы писать на нем полезные программы. Стандартная библиотека, к тому же, спроектирована довольно неплохо, и в целом отдельные ее части совершенно ортогональны другим, так что можно использовать какое-то ее подмножество не то что не касаясь, а даже не зная про другие(вот в случае с каким-нибудь C++ такое не прокатит, да, но CL не C++).

У CL есть высокопроизводительные реализации, крутейшие оптимизирующие компиляторы. У CL средства отладки и разработки, даже встроенные в стандартную библиотеку, на порядки превосходят таковые в бидонах и рубях.

Да реализации этих двух упомянутых языков — говно просто сраное, в сравнении даже со свободными реализациями лиспов, я уж не говорю про коммерческие.

У CL тупо больше полезных и нужных фич — макросы, мультиметоды, и так далее.

Про лиспы вообще — есть куча книг, как заумных и дико интересных(AMOP, PAIP), так и простых, веселеньких и легких на подъем(PCL, Land of Lisp).

Синтаксис не нравится? Да это бред — у лиспа стандартный синтаксис намного менее перегружен и более удобен чем даже у питона. И не надо говорить что код хуже выглядит — код выглядит как говно когда написан как говно, и на питоне говно можно написать даже проще чем на лиспе(и я примеров видел довольно немало). И это я не говорю еще что синтаксис CL можно менять под себя.

Интеграция со сторонним кодом, с сишечкой? Да у того же CL просто охренительные FFI — простые, но мощные, многофункциональные и расширяемые, которым питоновские аналоги, типа ctypes, в подметки не годятся. И для CL тоже уже есть куча хороших библиотек-оберток над разным сишным кодом — от системных функций POSIX или WinAPI до GTK+, и даже до COM/OLE.

Нет, ну я не понимаю просто — вот какой-нибудь чувак, даже, скажем, гик, сидит и думает — а забабахаю-ка я опенсорс проект, или просто так себе что-нибудь напишу — и потом идет, и берет бидон. Или руби. Или начинает писать что-то совсем новое — и та же история.
Нахуя?

На лиспе приятнее писать, лисп проще в изучении, лисп проще в использовании, лисп функциональнее, лисп производительнее! Не используйте блять питоны и руби — это вершина идиотизма покуда есть лисп.
lovesan
Windows programming C winapi Написал тут недавно — библиотека-звонилка для винды. Обертка над RAS API, пока что может просто поднимать соединение по имени, закрывать, и сообщать о том, существует ли оно уже. Для VPN, диалапа, и пр.

Может кому надо:
github.com
lovesan
Linux Windows programming GCC mingw Собрал таки GCC и, вообще, минимальный дистр MinGW.
dl.dropbox.com
Позже распишу, как это все собирать — но сразу скажу, натрахался на год вперед.

Сконфигурировано все под i686-pc-mingw32.
i686 это P6(http://en.wikipedia.org/wiki/I686)

У всего вместе отрублен NLS, потому что он все-равно хреново работает.
То есть, общаются утилиты только на английском.

binutils-2.22
То есть, всякие там ld, as, windres, strip и т.п.
Утилиты слинкованы со всеми необходимыми библиотеками(gmp-5.0.2, mpfr-3.1.0, mpc-0.8.2, ppl-0.11.2, cloog-ppl-0.15.11) статически.

gcc-4.6.2
Собраны компиляторы для c, c++, fortran, objc и objc-c++
Стандартные библиотеки собраны как статические, так и динамические.
Влючены gomp и lto.
Также, дополнительно собрана дебаг-версия libstdc++(лежит в lib/bin).
Сами компиляторы, и вообще, исполняемые файлы, типа драйвера(gcc.exe) тоже, как и binutils, статически слинкованы с необходимыми либами.

w32api-3.17-2
Заголовочные файлы и библиотеки импорта для WinAPI.

minwrt-3.20
Рантайм MinGW.

zlib-1.2.5
Статическая и динамическая версии.

pthreads-w32-2-8-0
GC2-конфигурация, DLL.

libiconv-1.14
И DLL, и статическая версия.

gettext-0.18.1.1
Аналогично, и статическая версия, и dll'ки.

expat-2.0.1
Опять же, и DLL, и статическая библиотека.

gmp-5.0.2
DLL-версия.
C++-обертка(libgmpxx-4.dll) зависит от DLL'ек libgcc и libstdc++

mpfr-3.2.0-dev
Версия из SVN. DLL.

mpc-1.0.0dev
Аналогично — DLL, и собиралась из svn trunk.

ppl-0.11.2
cloog-ppl-0.15.11
Как и gmp/mpfr/mpc — собирались с --enable-shared --disable-static.

make-3.82
Лежит в bin, i686-pc-mingw32-make.exe.
По слухам, он довольно кривой, особенно в области распараллеливания, так что лучше использовать make из msys.

libtool-2.42
autoconf-2.68
automake-1.11.2
— GNU autocrap. Вроде работают.

bzip2-1.0.6
Версии библиотеки — как DLL, так и статическая.

xz-5.0.3
Аналогично bzip2.

Я бы в принципе, добавил еще GDB, но ему нужен питон, и мне пока лень их оба собирать.

Для корректной работы весь этот хлам надо распаковать в C:/MinGW
Кстати, насколько я понимаю, autotools, даже вот эти MinGW-версии, требуют unix-like окружение для работы, поэтому желательно еще добавить ко всему этому MSYS(ее брать с сайта mingw или через mingw-get, и устанавливать в C:/MinGW/msys).
lovesan
C++ programming habrahabr.ru
Есть пара вменяемых мыслей, но в основном — просто оправдания "чсв" плюсоздрота.

Вот это вот особенный пиздец:
-----------------
Язык C++ очень многолик и вариативен, что дает огромный простор для творчества. «Искусство программирования» — фраза, которая часто встречается в статьях и литературе по C++. Но насколько это хорошо? Разработка программного продукта отдельными разработчиками начинает походить на соревнование в мастерстве между самими разработчиками… Создаются конструкции и взаимосвязи, которые становятся понятными только редкому числу «опытных» программистов, знакомых с передовыми тенденциями развития языка.
--------------------

Бля, да 99% "конструкций и взаимосвязей" это костыли, которые окостыливают и оборачивают плюсцы до чего-либо вменяемого.

Я, вот, например, как-то давно, помнится, сел писать на плюсцах какие-то мелочи на тему толи 2д, толи 3д графики. Сидел вечера два, потом посмотрел, что я написал, и оказалось что до графики нихрена то и не дошло еще, зато я успел нагородил кучу классов для управления памятью, для менеджмента ресурсов, и до кучи еще оберток над MFC(!!! ладно бы еще над голым winapi, было бы простительно, но так обернул половину плюсового же фреймворка). Меня потом долго мучила совесть, какой же я долбоеб, и какой херней страдал. Мучила до того самого момента, как я впервые увидел "продакшн-квалити" код на плюсцах — это был такой же адский пиздец, того же рода, какой я в те два вечера написал, но только еще пиздецовее и навороченнее. Что еще интереснее, позже я понял, что такое — далеко не редкость, а совершенно стандартная ситуация в проектах, где разработка идет на С++. Автор статьи тоже об этом упоминает, кстати.


C++ — совсем не язык для "опытных" и "продвинутых" программистов, каким его любят выставлять задроты. Это язык для ограниченных задротов. Любовь к C++ это уже маркер.

Кстати, на закуску, поржать:
habrahabr.ru
lovesan
Linux programming С десктопом у линукса, конечно, вообще полный пиздец.
Мне вот для моей будущей аппликухи, которую я собираюсь продавать, понадобится три компонента(как начну над этим плотнее работать, напишу подробный пост, наверное):
1) компилятор парсеров по PEG, в машкоды
2) вменяемое и модное GUI
3) графическая инфраструктура для тридэ, удобная в использовании. Не слишком навороченная(я не тридээкшон писать собрался, сооответственно всякие там огры идут лесом)
это не считая инфраструктуры для деплоймента приложений, и всего что около

На линуксе для этого нихуя ровным счетом нет. Ну ладно, допустим (1) нигде практически нет, но это я сам напишу на CL(уже пишу). Но вот остального нет вообще. С GUI полная жопа(на винде можно модное WPF; да и голое winapi не так уж плохо в сочетании с нормальным языком; на линуксе есть пиздец в виде GTK+, еще есть Qt(но на C++ меня писать никто не заставит), всё больше ничего по факту нет). С графикой жопа еще хуже(OpenGL? Спасибо, нахуй-нахуй). С инфраструктурой — лучше промолчу.

И это еще ладно. Ну допустим, можно выкрутиться OpenGL, допустим можно как-то прикрутить Qt, допустим с деплойментом можно что-то придумать.
Но вот основной вопрос — кто это на линуксе будет покупать? Да никто, там 99% пользователей коммерческий софт вообще не нужен — в основном из-за отсутствия платежеспособности, ну кое-кому из-за религиозных принципов; несмотря на то, что, допустим даже, аналогов моей будущей аппликухи там нет.

Линукс на десктопе разработчикам не нужен потому, что основная его аудитория там — тупые малолетние задроты, охуевающие от собственной илитарности. То, что система сама по себе убогая, и инфраструктуры у нее почти ноль — это вторично.
lovesan
Linux C++ programming бд телега Существует два вида сложности.
Я сейчас про программное обеспечение, но вообще это, естественно, можно перенести и на другие области.

Первый вид сложности — сложность обоснованная, а второй — сложность дутая.

Отличить их, в принципе, легко, но не все на это способны, и почему — мне лично непонятно.

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

Пример технологий, которые сложны обоснованно — WinAPI, Common Lisp, современные РСУБД.
Если мы от этой сложности отказываемся, мы получаем такие кривые куски говна, как Linux, Python и NoSQL.
Если же нам нужен тот функционал, который первая тройка технологий имеет, например:
1) унифицированный доступ к ресурсам, интероперабельность между компонентами, обратная совместимость
2) неотделимые от языка макросы, компиляция в рантайме, производительность, продвинутые объектная система и протокол обработки исключений
3) производительность, надежность, масштабируемость
то мы вынуждены эту самую сложность, которую эти технологии вносят, терпеть, и обойти это никак не удастся, никакого лайфхака в этом плане нет — все аналоги с подобной функциональностью будут как минимум не проще в использовании(а скорее всего и сложнее, потому что приведенные технологии отточены многими годами).

Самый яркий пример дутой сложности, который я знаю — язык C++. Все неудобства, которые он вносит, можно убрать и не потерять совершенно ничего, и примеров тому — от Obj-C до того же Common Lisp.

Так я вообще к чему?
Make everything as simple as possible, but not simpler.
lovesan
Windows Lisp programming winapi com Рационализация моей работы с COM. Необходимая, наверное, вещь, раз тут один долбоеб уже заикнулся об этом.

Да, может OLE и протухло. Может, на чистом COM/OLE уже никто не пишет.
Но, чуваки, без интерфейса к COM на винде делать вообще нехуй. Совершенно.
Десктопные приложения, игрушки, или даже сервисы, без COM/OLE на винде не написать.

Любой язык, платформа или рантайм, который не принимает в расчет COM, у которого нет качественного интерфейса к этому — на винде нежизнеспособен и является как максимум академической игрушкой, а обычно же — студенческой поделкой.