Comments 13
160кб на всё про всё
Кошмар какой. В соседней теме вон вообще 3д сцены в 64 кб умещают…
Я как то раз тоже веб-инсталлер писал на чистом апи, получилось около 70кб, 3/4 из которых которых были иконка (6 в одном ico от 16х16 до 256х256) (чтобы нормально отображать в проводнике в режиме крупных значков) и лицензионное соглашение. Для создания компактных приложений первое от чего следует отказаться это линковка на статические библиотеки crt и прочий подобный мусор.
Совсем от всего не отказаться, придётся брать какой-нибудь CRT tiny и долго его допиливать. И времени это займёт прилично. Как вариант можно попробовать собрать в VS 6.0 минимизировав использование std и убрать все c++ 11 фишки. Там можно будет выбрать динамическую линковку к msvcrt.dll — она с Windows XP в системе есть.
В crt нет абсолютно ничего жизненно необходимого для однокнопочного веб инсталлера, отказаться элементарно, сторонние альтернативы не нужны, ничего допиливать не надо, и никаких неудобств, было бы желание. C++ тут тоже не нужен, ни 11 ни какой либо еще, чистый C является идеальным выбором. Другой вопрос что кроме как ради спортивного интереса в этом практический пользы действительно нет.
Сравнение с интро и демками выглядит странно — задача ведь не победить в специальной олимпиаде поразить всех минимальным размером, а реализовать необходимый функционал, оставаясь в рамках WinAPI. Размеры многих современных программ (в т.ч. инсталлеров) больше на порядки, на этом фоне разница между 160 и 70 килобайтами незаметна.
(Disclaimer: я не люблю венду и WinAPI, считаю его уродливым и перегруженным, но он позволяет сделать очень многое сам по себе, и это очень круто. В юниксах, при всех их прочих достоинствах, практически сразу встает вопрос выбора хотя бы из-за отсутствия нативного гуи-тулкита.)
Насчет использования C++ (да хоть бы и последних версий) в стендалон-приложениях, распространяющихся в исполняемом виде (в отличие от популярных опенсорсных библиотек, которые часто нужно собирать устаревшими компиляторами или линковать с имеющимся legacy-кодом) можно не переживать; обернуть графические примитивы WinAPI в иерархию классов — вполне естественное желание.
Статья порадовала, автор молодец. Такими и должны быть программы — легкими и компактными, не стесняться пользоваться нативными возможностями операционных систем вместо того, чтобы тянуть за собой веб-браузер по любому поводу.
(Disclaimer: я не люблю венду и WinAPI, считаю его уродливым и перегруженным, но он позволяет сделать очень многое сам по себе, и это очень круто. В юниксах, при всех их прочих достоинствах, практически сразу встает вопрос выбора хотя бы из-за отсутствия нативного гуи-тулкита.)
Насчет использования C++ (да хоть бы и последних версий) в стендалон-приложениях, распространяющихся в исполняемом виде (в отличие от популярных опенсорсных библиотек, которые часто нужно собирать устаревшими компиляторами или линковать с имеющимся legacy-кодом) можно не переживать; обернуть графические примитивы WinAPI в иерархию классов — вполне естественное желание.
Статья порадовала, автор молодец. Такими и должны быть программы — легкими и компактными, не стесняться пользоваться нативными возможностями операционных систем вместо того, чтобы тянуть за собой веб-браузер по любому поводу.
В юниксах, при всех их прочих достоинствах, практически сразу встает вопрос выбора хотя бы из-за отсутствия нативного гуи-тулкита
В никсах есть пакетные менеджеры. В принципе, попытки натянуть устаревшие win концепции на linux это распространенная ошибка.
UFO just landed and posted this here
Пакетные менеджеры, конечно, рулез, но я совсем про другое: в венде, если я хочу написать простое (или не очень) графическое приложение, долго раздумывать не приходится: WinAPI в зубы и вперед; там не нужно выбирать, какой пакет ставить: Gtk+, Qt или, например, FLTK.
WinAPI предоставляет удобный baseline: стандартную графику, работу со звуком и прочие компоненты. Юниксы, конечно, намного более удобная и приятная среда для разработки вообще, но так они не умеют: приходится определяться с графическим стеком, звуковой подсистемой, учитывать особенности разных версий месы и прочих ксоргов, конкретных реализаций libc (например, гнутой vs. BSD), помнить про кучу специфических вещей типа udev, которые есть в Linux, но нет в других юниксах, и которые влияют на диспетчеризацию событий, определение оборудования, и т.д.
Программа на WinAPI, написанная для условной WinNT, скорее всего заработает и в условной десятке. Про фрюниксы так сказать, к сожалению, нельзя.
WinAPI предоставляет удобный baseline: стандартную графику, работу со звуком и прочие компоненты. Юниксы, конечно, намного более удобная и приятная среда для разработки вообще, но так они не умеют: приходится определяться с графическим стеком, звуковой подсистемой, учитывать особенности разных версий месы и прочих ксоргов, конкретных реализаций libc (например, гнутой vs. BSD), помнить про кучу специфических вещей типа udev, которые есть в Linux, но нет в других юниксах, и которые влияют на диспетчеризацию событий, определение оборудования, и т.д.
Программа на WinAPI, написанная для условной WinNT, скорее всего заработает и в условной десятке. Про фрюниксы так сказать, к сожалению, нельзя.
да и я совсем про другое: в линуксе конкретно инсталляторы писать вообще не надо. Но разрабы не заморачиваются и переносят софт один в один, а потом героически сражаются с проблемами типа конфликтов версий и путей.
Бтв, я б завязался на Qt. Всё равно популярные графические оболочки linux от него зависят
Бтв, я б завязался на Qt. Всё равно популярные графические оболочки linux от него зависят
вы про электрон?
Подписи к чекбоксам доставили
1.Кажется все забыли про upx
ru.wikipedia.org/wiki/UPX
2.Мсье знает толк в извращениях.
3.Обычно Windows ос следующего поколения включают компоненты msvcrt.dll на которых написаны системные компоненты!
ru.wikipedia.org/wiki/UPX
2.Мсье знает толк в извращениях.
3.Обычно Windows ос следующего поколения включают компоненты msvcrt.dll на которых написаны системные компоненты!
Sign up to leave a comment.
Веб установщик на чистом WINAPI с поддержкой Hi DPI и векторным лого