Я по горло сыт стандартно выглядящими приложениями. Сегодня все десктопные приложения Windows выглядят одинаково, да и внутри устроены одинаково: их создают на основе дурацких браузерных обёрток React, Electron, electronbun и Tauri, имитирующих реальные десктопные приложения. Они медленно работают и занимают кучу памяти — по сути, это bloatware. Блокнот — это, блин, приложение для простых ЗАМЕТОК, а не замена Word, калькулятор — это калькулятор, а не планировщик лунной миссии НАСА. На каком-то этапе Microsoft сбилась с курса, как будто сдалась и передала бразды правления куче веб-разработчиков, незнакомых с концепцией оптимизации.
Чёртов Блокнот занимает в памяти почти 50 МБ, хотя эквивалентное приложение, написанное на чистом Win32 C, занимает 1,8 МБ. Вроде бы, по современным меркам 50 МБ — это не так много, но в том-то и смысл: эти мегабайты постепенно накапливаются. Недавно я купил новый Intel Ultra 9 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.
Программирование на Win32 API — утерянное ныне искусство; я с ностальгией вспоминаю, как когда-то программировали приложения для Windows. Процесс был запутанным, но обеспечивал полный контроль.
Программирование современных UI чаще всего пытается спрятать от нас операционную систему. Мы привязаны к прямоугольной коробке, хотя в эпоху Windows XP был период, когда крутыми считались нестандартные окна приложений, такое было даже у Windows Media Player.
Не все окна обязаны быть скучными скруглёнными прямоугольниками с боковой панелью, шестерёнкой настроек и спрятанным под ними веб-стеком. Когда-то приложениям Windows дозволялось быть странными. Проигрыватели мультимедиа выглядели как приборы. По рабочему столу гуляли животные. Вспомогательные панели походили на пульты управления, игрушки, радиоприёмники или маленькие инопланетные интерфейсы. Окно не должно было обязательно иметь прямоугольную форму только потому, что таким было окно операционной системы.
Обычно смысл этого заключался не в удобстве пользования, а в индивидуальности.
В современных десктопных UI её практически не осталось. Не потому, что в Windows она больше невозможна, а потому, что большинство разработчиков теперь не программирует на том уровне, где они могут управлять самим окном.
Репозиторий GitHub к этому посту — небольшое напоминание о том, что Win32 по-прежнему позволяет нам это делать. Один пример из него делает окно овальным. Другой создаёт окно по форме растрового изображения, Третий превращает окно в анимированное животное, живущее на рабочем столе. Ни для одного из них не требуется огромный фреймворк, они просто работают с Windows напрямую.
Первое, что сбивает с толку людей, имеющих опыт в играх, браузерных приложениях и современных фреймворках UI — это то, что в центре внимания Win32 не находится цикл обновления, которым управляет разработчик. В нём всё зависит от сообщений. Приложение работает, а Windows постоянно обрабатывает его события:
while (GetMessage(&msg, NULL, 0, 0) > 0) { TranslateMessage(&msg); DispatchMessage(&msg); }
Этот цикл становится контрактом. Windows сообщает, что произошло какое-то событие, а процедура окна решает, что оно значит. «WM_CREATE» означает, что создаётся окно. «WM_PAINT» означает, что его нужно перерисовать. «WM_SIZE» означает, что изменилась клиентская область. «WM_DESTROY» означает, что работа завершена. Вот так по-настоящему выглядит программирование Win32: разработчик строит поведение из отдельных сообщений.
И как только понимаешь это, окна странной формы перестают быть загадкой.
Обычное окно верхнего уровня имеет прямоугольную форму, но у Windows также есть понятие объекта области (HRGN). Если при помощи SetWindowRgn присвоить окну область, то окном будет считаться только эта часть. Всё остальное исчезает, и визуально, и с точки зрения интерактивности. В этом и заключается хитрость.
Простейшая версия подобного находится в basic/main.c. Этот код создаёт окно без границ, а затем выполняет следующее:
region = CreateEllipticRgn(0, 0, rc.right, rc.bottom); SetWindowRgn(hwnd, region, TRUE);
Этого достаточно, чтобы превратить окно в овал. Не в поддельный овал, нарисованный внутри прямоугольной рамки, а в настоящий овальный HWND. В примере также обрабатывается одна практическая мелочь, о которой часто забывают: после удаления панели заголовка система больше не будет перетаскивать окно за нас. Поэтому при «WM_LBUTTONDOWN» код имитирует перетаскивание панели заголовка, передавая «WM_NCLBUTTONDOWN» с «HTCAPTION».
Эта маленькая деталь — миниатюрная версия всей истории с произвольными окнами. Создать форму просто. Настоящая работа заключается в том, чтобы заменить всё то, что обычное окно делало автоматически.
В следующем примере всё становится интереснее. drivenbyimage/main.c определяет форму не математически, а получает её из данных растрового изображения. Программа загружает shape.bmp, считывает пиксели при помощи GetDIBits, а затем построчно сканирует изображение. Каждый горизонтальный интервал непрозрачных пикселей становится небольшой прямоугольной областью, и эти интервалы объединяются в одну область окна.
#define TRANSPARENT_COLOR RGB(255, 0, 255)
Маджента обозначает пустое пространство, всё остальное становится частью окна.
Это значит, что растровое изображение одновременно выполняет две задачи. Во-первых, это то, что мы отрисовываем в «WM_PAINT». Во-вторых, это форма самого окна. Именно так работали старые приложения с возможностью смены скинов. Разработчики не были ограничены кругами, скруглёнными углами и красивой векторной геометрией. Окно могло принять форму изображения, на котором нарисована собака, космический корабль, магнитофон или мультяшное лицо.
Отчасти благодаря этому старое десктопное ПО было таким интересным. Прямоугольник окна переставал быть законом природы и становился лишь одним из вариантов.
Однако области, создаваемые на основе растровых изображений, всё равно имели резкую границу. Пиксель или был, или его не было. Это отлично подходит для силуэтов или вырезанных UI, но если вам нужны плавные границы, просвечивающие пиксели или анимация, то приходилось переходить к многослойным окнам.
Именно эту задачу решает пример Animated/. Я нашёл на itch.io красивый лист спрайтов с анимированной 8-битной собакой авторства художника inmenus, который передал свою работу в Creative Commons. Спасибо ему за это.
Вместо того, чтобы вырезать окно из области, пример создаёт всплывающее окно «WS_EX_LAYERED» и при помощи UpdateLayeredWindow загружает в него 32-битное изображение с альфа-каналом. В примере используется лист спрайтов, кадры которого меняются по таймеру, выполняется отрисовка в битовую карту памяти при помощи GDI+, а затем результат передаётся на рабочий стол. Мы уже не говорим «окно будет эллипсом» или «окно соответствует этой маске», а сообщаем «окно будет тем, что представляют из себя эти пиксели».
Для анимации больше подходит многослойное окно (layered window), потому что благодаря нему мы получаем попиксельный альфа-канал, более плавные края, настоящую полупрозрачность и возможность менять видимую фигуру в каждом кадре.
Однако есть одна проблема с программированием Win32 API: при работе с произвольными окнами нужно всё делать самостоятельно, контролируя каждое сообщение Windows, а такая система ненадёжна.
Неприятности начинаются, когда мы решаем отказаться от обычного окна. Нам придётся реализовывать собственное перетаскивание, изменение размеров, поведение при закрытии, проверку нажатий мыши, обработку ввода с клавиатуры, правильность перерисовки, обработку DPI и все раздражающие маленькие пограничные случаи, которые для стандартного окна были решены десятки лет назад. Именно поэтому окна странной формы легко прототипировать и сложно доводить до ума.
Если в результате не получается что-то поистине выдающееся, пользователи обычно не ценят усилий.
Культура десктопного UI перестала считать крутыми безумные скины, она хочет, чтобы окна надёжно работали и не мешали процессу. Странные окна стали ассоциироваться с уловками, рекламным ПО, панелями инструментов и раздутыми утилитами, нежели с серьёзным ПО. И это печально.
Но мне всё равно нравится, что они существуют. Это напоминает мне о том, что когда-то Windows была платформой, на которой ПО могло иметь физическую идентичность, а не просто структуру страницы внутри замаскированной под приложение вкладки браузера. Чаще всего правильным выбором будет обычное прямоугольное окно, но полезно помнить, что это лишь один из вариантов, а не непреложный закон.
В Win32 здорово то, что он не пытается отговорить нас от этого. Он просто даёт нам сообщения, дескрипторы, API отрисовки и достаточно возможностей для создания чего-нибудь интересного.
Код к посту можно найти в репозитории GitHub.
Комментарии (83)
Pascal1990
20.04.2026 05:20Программирование на Win32 API — утерянное ныне искусство
Ну лично мне такое искусство нафиг не нужно. Пишу на javafx кроссплатформенно под винду, мак и линукс и живу хорошо. Памяти много не ест. Единственный минус - приходится тащить с собой jvm полностью, но 40 мегабайт в нынешнее время это уже приемлемо. Столько весит обычное мобильное приложение.
Хотя вцелом согласен, что electron и прочие web-gui это зло.
На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
Goron_Dekar
20.04.2026 05:20На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
Уже давно нет. Если вам надо пускать одну и ту же программу на разных платформах - вы делаете сайт. А сейчас на разных платформах запускаются разные программы, реализующие функционал одной платформы. Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами. Вы разделяете UX - что-то ваши пользователи получают в телефон, а что-то - на ПК.
13werwolf13
20.04.2026 05:20Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
kirigami хочет с вами поспорить, к сожалению фреймворку безгодунеделя от роду, и примеров софта мало, я знаю пожалуй только neochat и tokodon, и они прекрастны в своей универсальности, и на android и на десктопе использую, удобный ui для обоих вариантов
d3d14
20.04.2026 05:20Два чая этому господину.
Как уже задолбали эти велосипеды с браузером внутри EXE. Некоторые еще создают кучу дочерних процессов. Эти дочерние процессы были придуманы в браузерных движках, их смысл - при открытии вкладки не тратить время на создание процесса для нее, а передавать ее в заранее созданный и ожидающий процесс. Но криворукие лентяи перенося браузерный движок в EXE приложение, не удосужились оключить многопроцессность. И в итоге, приложение, в котором нет никаких вкладок, единственная "вкладка" - его корявый интерфейс - зато имеет несколько висящих без надобности дочерних процессов. Нуачо, железо же позволяет....
MonkAlex
20.04.2026 05:20Дочерние процессы то вам чем не угодили?
Не знаю конкретно про электрон, но посмотрел на запущенные программы на моем пк. Thunderbird - два подпроцесса, с разными целями. Стим - пяток подпроцессов, из которых только парочка с типом renderer (что можно наверно привязать к "вкладкам"), дискорд - пяток подпроцессов, каждый для своих целей и не создаются новые на "вкладки".
И даже firefox, который действительно создает много подпроцессов не создает их для каждой вкладки, что легко проверяется - можно закрывать в диспетчере случайный подпроцесс и смотреть что отваливается\перезапускается в этом случае. Некоторые подпроцессы критичны и ломают всё целиком, а некоторые просто потребуют перезагрузить вкладку.
d3d14
20.04.2026 05:20Их внедрение даже в браузерных движках было спорным решением, а уж в standalone приложениях, они подавно не нужны.
некоторые просто потребуют перезагрузить вкладку.
Это и есть процессы для вкладок.
MonkAlex
20.04.2026 05:20Проблема то в чём? В памяти? Так память жрать они все жрут, вне зависимости от количества процессов. Процессы, отмечу, для разных целей, т.е. общего кода там скорее всего не то чтобы много.
В стиме можно уронить интерфейс и подпроцессы его перезапустят. Это удобно с пользовательской точки зрения.
Мне тоже неприятно видеть большое количество процессов, но это чисто вкусовщина в моём случае, т.к. пока оно работает стабильно и не жрёт лишней памяти - проблем я не вижу. Да, это всё потребляет уже не 512мб оперативы как когда-то на винХР, но и цены давно другие, софта разного и с разными функциями стало больше. Всё ещё можно пользоваться софтом с ВинХР, если сильно важна память и много-процессность.
ПС: прекрасно помню времена, когда зависание какой-нибудь вкладки в лисе завешивало весь браузер. Спорное решение исправило эту проблему by design, что на мой взгляд прекрасно. Напомню, что в те времена даже код аддонов выполнялся в едином процессе, что делало всё очень грустно и сложно для пользователей.
HemulGM
20.04.2026 05:20Каждый процесс внутри поднимает отдельный рантайм, который нужен для его работы. Который и так поднят в хостовом процессе.
Без множества процессов создаваемых браузером, вообще и нет понятия "упал UI".
MonkAlex
20.04.2026 05:20Отдельно отмечу, что это примерно та же история, что монолит vs микросервисы. У обоих есть свои плюсы, золотую середину каждый ищет для себя сам.
qvvah
20.04.2026 05:20Спорным решением? Емнип, это было сделано для безопасности и изоляции, чтобы одна вкладка, в случае успешного использования уязвимостей, не получила доступ к содержимому всех остальных вкладок и к основному движку браузера (ФС, сеть, куки, пароли). Хотя может быть вы правы и нужно изобретать какую-то новую схему разграничения памяти, чтобы не плодить кучу процессов - что-то вроде подпроцессов, изолированных друг от друга и от процесса-родителя, но при этом разделяющих часть ресурсов.
FoxWMulder
20.04.2026 05:20++ попытка использовать один и тот же UI на разных платформах провальна изначальна. т.е. не то чтобы она провальна, но это компромисы между универсальностью и удобством. например иногда забывают что телефон и ПК это два устройства с разными физическими параметрами экрана, с разными перефирийными устройствами и с сильно разными сценариями использования.
HemulGM
20.04.2026 05:20Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами
Можете
Один и тот же проект с одним и тем же UI
Win11 
Android/iOS
artptr86
20.04.2026 05:20Вы не можете использовать один и тот же подход к UI на телефоне с лапками и крохотным экранчиком и на ПК с клавиатурой и несколькими огромными экранами. Вы разделяете UX - что-то ваши пользователи получают в телефон, а что-то - на ПК.
Тем не менее, сейчас есть 3 десктопных платформы и 2 мобильных. В любом ли случае нужно 5 приложений? И если да, то на чём тогда писать GUI под линукс?
13werwolf13
20.04.2026 05:20На win32 api сейчас писать не вариант просто потому что одну и ту-же программу в нынешнее время приходится выпускать сразу для целой кучи платформ: винда, мак, линукс, андройд, айфон.
qt насколько я знаю вполне себе позволяет писать софт под все платформы и при этом не тащить за собой тяжеленный рантайм как java
Nagdiel
20.04.2026 05:20Qt тоже не бесплатен по размеру, т.к. требует библиотек, которые должны быть на целевой платформе или распостраняться вместе с приложением. Другое дело, что можно линковать только те библиотеки, которые реально нужны для работы приложения. Но все равно это могут быть десятки или сотни мегабайт зависимостей.
13werwolf13
20.04.2026 05:20Другое дело, что можно линковать только те библиотеки, которые реально нужны для работы приложения. Но все равно это могут быть десятки или сотни мегабайт зависимостей.
Ну я в общем-то это и имел ввиду. На десктопе половина либ и так будут стоять в системе, их тащить с сабой не прийдётся. А на мобильной платформе взять только необходимые, ещё и пожать/порезать))
unreal_undead2
20.04.2026 05:20И откуда на обычном десктопе с виндой библиотеки Qt (да ещё и той версии, которая нужна приложению)? Да и под линуксом (если распространяется единый бинарный пакет, который должен бегать на разных дистрибутивах) расчитывать на бинарную совместимость с установленными в системе библиотеками может быть оптимистично. По опыту даже libstdc++ лучше таскать с собой.
13werwolf13
20.04.2026 05:20Делать единый пакет под разные дистрибутивы уже само по себе ошибка, а вы придумываете проблему там где её нет.
unreal_undead2
20.04.2026 05:20Задача вполне решаемая - скажем, интеловские тулы (компилятор, vtune и т.д.) можно скачать в виде self-extracting архива общего для разных систем. Сборка разных пакетов для зоопарка разных систем требует отдельных ресурсов.
13werwolf13
20.04.2026 05:20задача решаемая кто бы спорил, но это всё равно будет неправильным подходом, фу таким быть..
сборка под десяток дистрибутивов родного для них пакета с родными для них зависимостями это задача решаемая за несколько минут под кофе с сигареткой, и работать это будет годами без серьёзных изменений.
а если ваш софт достаточно хорош (под этим в том числе подразумевается и открытая лицензия) и станет популярным то эту задачу за вас решат мейнтейнеры дистрибутива сами (хотя никто не запрещает им в этом помочь).unreal_undead2
20.04.2026 05:20сборка под десяток дистрибутивов родного для них пакета с родными для них зависимостями это задача решаемая за несколько минут под кофе с сигареткой, и работать это будет годами без серьёзных изменений.
Вопрос ещё в разных версиях - скажем, нужно поддерживать разные версии Redhat за последние лет десять. И какого то нужного функционала в версиях библиотек на старых системах может не быть.
под этим в том числе подразумевается и открытая лицензия
Я скорее проприетарщину с грузом легаси имел в виду.
13werwolf13
20.04.2026 05:20Вопрос ещё в разных версиях - скажем, нужно поддерживать разные версии Redhat за последние лет десять. И какого то нужного функционала в версиях библиотек на старых системах может не быть.
снова несуществующая проблема, умные дяди уже давно всё порешали и на этот счёт в гайдлайнах есть ответ что делать
Я скорее проприетарщину с грузом легаси имел в виду.
мазохизм - дело добровольное, если кому-то больше нравится самому заниматься дистрибьюцией это их выбор, но это не отменяет всего вышесказанного
JerryI
20.04.2026 05:20electron не зло, если знать, как его готовить. Просто большинство не знает и пихает туда свой веб сайт
прим. Fusion360, VSCode (до появления Copilot)
13werwolf13
20.04.2026 05:20прим. Fusion360, VSCode
плохие примеры, если пользователь готов мириться с рядом недостатков ради некого кол-ва преимуществ это нисколько не отменяет наличия недостатков.
alliumnsk
20.04.2026 05:20Это же так, что JVM какое-то фиксированное количество памяти съела и всё, сама программа будет больше потреблять раза в три из-за использования сборщика мусора плюс ещё то, что JVM затрудняет написание программ, эффективно использующих память
ris58h
20.04.2026 05:20Не смог понять содержимого вашего комментария. Это утверждение, вопрос, крик души?
Ilirium
20.04.2026 05:20На самом деле Win32 API приложения благодаря Wine вполне себе работают и на других платформах. Даже где-то был полушуточный пост, что вот дескать Win32 API это единственный стабильный GUI API для Linux :)
Вот на телефонах и планшетах да, я так понимаю Wine не будет работать. Либо, если мы даже и запустим, то пользоваться на сенсорных экранах таким приложением будет неудобно.unreal_undead2
20.04.2026 05:20Даже где-то был полушуточный пост, что вот дескать Win32 API это единственный стабильный GUI API для Linux :)
При этом и линуксовые сисколлы для каких то специфических задач никто не мешает использовать.
А когда то и конопочные телефоны с Win32 были - понятно, что раскладку контролов по экрану надо было подгонять под размеры, но API был практически тот же.
randomsimplenumber
20.04.2026 05:20Окон (обьектов которые обрабатываят сообщения) в одной небольшой программе легко может набраться больше 100. Удачи рулить ими через winapi.
unreal_undead2
20.04.2026 05:20Контролы обычно завёрнуты в свои API и руками их сообщения обрабатывать не надо.
По теме статьи - по мне так проблема скорее в обратном, большая часть приложений использовала стандартные контролы, внешний вид которых можно было настроить под себя в одном месте (стандартная настройка свойств экрана), да и в целом всё выглядело строго и единообразно. Сейчас даже заголовок активного/неактивного окна расцвечивается у всех по своему.
Arhammon
20.04.2026 05:209 285 с 32 ГБ ОЗУ, но при запуске Windows 11 память уже была заполнена на 77%.
Вроде как радоваться надо что память на которую немало потрачено занимается чем-то полезным, а не простаивает. Помниться во времена Висты/7ки, Виста с жестким и большим объемом памяти была отзывчивее 7ки - просто за счет агрессивного префетча использовавшего все 8гб, в то время как 7ка помня провал ноутбуков 256Мб+Виста, отдавала на пред загрузку всего пару гигабайт.
ArtFrost
20.04.2026 05:20А если бы память заполнялась на 100% то уровень радости вырастал бы на дополнительные 23% что вся память используется ?)
clicky
20.04.2026 05:20А зачем кривляться если вам человек верно сказал что "заполненная" память это на самом деле кеш и суперфетч и это сделано нарочно? Чистится при востребованности другим приложением она моментально, но чаще предзагруженные данные как раз понадобятся и будут использованы, что делает видимую отзывчивость системы в разы выше.
mayorovp
20.04.2026 05:20Если бы этот кеш и правда чистился моментально, так ведь нет - мой домашний компьютер долгое время готов был в своп скидывать страницы данных лишь бы файловый кеш в памяти удержать. Приходилось держать rammap -et на горячей клавише. Потом я догадался выключить этот superfetch нафиг, и проблема ушла.
hw_store
20.04.2026 05:20Это же старая как мир парадигма Wintel: софт требователен к железу -> создаёт рынок для нового железа -> делаем софт ещё более ресурсоёмким -> делаем более лучшее железо -> загружаем его ещё более ресурсоёмким софтом...бесконечный цикл. Не удивлюсь, если когда-нибудь выяснится, что MS, AMD и Intel управляются с одной и той же Нибиру
MountainGoat
20.04.2026 05:20Я на веб-технологиях могу написать блокнот, который будет весить 2 мегабайта. Может, всё таки, рукожопы? Да не, АПИ плохой...
d3d14
20.04.2026 05:20Кстати, вот есть класс браузера, встроенный в ОС (IWebBrowser). ЕХЕ, использующее его, имеющее интерфейс на HTML/CSS/JS и проброс HTML/JS-обработчиков в нативный код весит ~100kB (вместе с HTML/CSS). Но все равно тащат этот мерзкий электрон с хромиумом.
zapimir
20.04.2026 05:20Да проблема не в рукожопах, а в том что за оптимизацию по сути не платят. Нужно сделать быстро и получать деньги. Сам конечно офигеваю, с теми же ИИ-шками. Пишу нужна таблица для админки, где будет 1 максимум 3 юзера - ИИ-шки: Мы тебя поняли, без BIGINT для id юзера не обойтись. А ведь так почти все пишут, зачем думать просто берём самый большой тип. А как CSS используют вообще мрак, когда видишь элемент и в нём пара десятков классов прописано. И так практически у каждого элемента, какая там каскадность CSS.
tenzink
20.04.2026 05:20В случае с id пользователя ИИ всё правильно делает. В случае 3х пользователей вы, вероятно, не сможете измерить разницу в потрблении ресурсов.
zapimir
20.04.2026 05:20Ну, да использовать в 8 раз больше памяти, чем нужно, это правильно. А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт. Да если бы эти 8 байт были только в одной маленькой таблице куда не шло, но есть куча других таблиц, где этот userid используется и там уже далеко не 3 записи, плюс по ним строятся индексы, а иногда и составные индексы. Так и набегает...
mayorovp
20.04.2026 05:20У BIGINT та же самая разрядность, что и у самого обычного указателя на современной платформе. И эти 64 разряда в указателе точно так же избыточны, но указатели используются намного чаще, чем ваш идентификатор пользователя, в том числе и в браузерах. Заботиться о длине идентификатора пользователя, но игнорировать указатели довольно странно, не находите ли?
Кстати, тот же Javascript имеет вообще ровно 1 числовой тип данных (под капотом иногда используется два разных), а потому размер страницы в браузере вообще никак не зависит от разрядности идентификатора пользователя.
zapimir
20.04.2026 05:20Причём тут указатели, если речь шла о базе данных? Да и указатель может указывать на структуру данных, а не на одну переменную.
В том же JS свои приколы, например, я делал свой data grid. ИИ-шки поголовно пытаются для каждой ячейки ставить кучу классов, на каждую ячейку вешать обработчики событий (а не использовать один общий). Начинают для каждой ячейки добавлять свой ID, не пытаются переиспользовать DOM при обновлении и т.п.. Да если их тыкать везде носом, то сделают.MountainGoat
20.04.2026 05:20Речь шла о том, что вы экономите ровно 3 байта памяти, рискуя ради этого реальными багами на конвертации типов и ещё такой же крошечной, но потерей производительности. При этом в этом же коде компилятор впустую потратит миллион этих байт.
playermet
20.04.2026 05:20а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Совсем не потому, что в таблице с тремя записями используется BIGINT для id. Это экономия на длине древка спички в рамках единственного требуемого коробка.
tenzink
20.04.2026 05:20Не набегает. Набегает за счёт использования неоптимальной архитектуры, неправильных алгоритмов и неудачного выбора структур данных. У решения с BIGINT по-умолчанию есть много достоинств:
у него нулевая когнитивная нагрузка на команду, поддерживающую код
оно не требует решения "проблемы 2000-го года" при неожиданном росте данных
оно почти всегда "бесплатно"
НО, если у сценарий, что использования BIGINT может оказать заметное влияние на производительность, то, уверен, вы это сами знаете, и являетесь достаточно квалифицированным специалистом (иначе вас просто не допустили бы делать такой выбор), чтобы это осознавать и добавить в prompt "используй для хранения user_id INT или что-там-ещё . Я знаю, что делаю"
А потом такие упс, а чего это страничка WP генерируется 2 секунды на пустом сайте, а страничка в браузере занимает несколько сотен мегабайт
Не нужно натягивать сову на глобус. Замена BIGINT на INT никак не уменьшит размер страницы в браузере и никак не повлияет на эти 2 секунды
pvvv
20.04.2026 05:20речь объём используемой памяти.
то что на веб технологиях можно сделать блоктнот весом 2МБ с функциональностью вот этого дата uri аж на 40 байт, это здорово конечно.
data:text/html, <html contenteditable>на винапи можно в несколько кБ .exe упихать, и он при исполнении загрузит в память лишь user32.dll размером те самые 1.8МБ, а браузер(электрон), с единственной такой вкладкой сожрёт пару сотен МБ, не говоря про то сколько сам весит.
beeruser
20.04.2026 05:202МБ? Что вы там хотите напихать?
notepad.exe в Windows11 на диске занимает 360кб (триста шестьдесят килобайт).
50 мегабайт, которые показывает винда - это рантайм вместе с замапленными библиотеками.
С веб-технологиями ваш редактор будет занимать мегабайт 300 в памяти.
Может, всё таки, рукожопы? Да не, АПИ плохой...
рукалицо
Wesha
20.04.2026 05:20Я по горло сыт стандартно выглядящими приложениями.
Ви так говорите, как будто это что-то плохое.
eee
20.04.2026 05:20Блокнот — это, блин, приложение для простых ЗАМЕТОК, а не замена Word, калькулятор — это калькулятор, а не планировщик лунной миссии НАСА
Тем временем планировщик миссии Аполлон 11 весил 72 КБ и требовал 4 КБ памяти.
randomsimplenumber
20.04.2026 05:20Планировщик freertos помещается в микроконтроллер где всего 32к флешки. Еще и хватает места на что то полезное.
VBDUnit
20.04.2026 05:20Было дело, тогда это казалось высокими технологиями. Помню в школе, когда про саму возможность существования таких окон узнал, очень впечатлился и векторный редактор написал под это дело. Ну, чтобы такие окна пихать везде где можно :)
VB6, если что
tenzink
20.04.2026 05:20В большинстве своём подобные нестандартные окна смотрятся откровенно плохо. Да и создание принципиально непортируемых windows-only приложений, это отвратительная идея
salnicoff
20.04.2026 05:20Да и создание принципиально непортируемых windows-only приложений, это отвратительная идея
Вспоминайте идеологию MVC и ее аналоги. Ядро программы будет портироваться, внешний вид будет переписываться под каждую платформу. Даже если Вы делаете что-то кросс-платформенное на каком-нибудь FreePascal'е, эта идеология у Вас в приложении будет присутствовать в той или иной форме.
tenzink
20.04.2026 05:20Согласен, это всё можно сделать, и не является rocket science. Но в дикой природе я пока не сталкивался с хорошими кроссплатформенными приложениями с окнами нестандартной формы. Вероятно всё чуть сложнее или заметно дороже, чем кажется
salnicoff
20.04.2026 05:20Вероятно всё чуть сложнее или заметно дороже, чем кажется
Оно чуть сложнее и дороже, поэтому мало кому хочется такими вещами заниматсья. Лучше ядро программы отполировать, сделав стандартный интерфейс под каждую ОС. Да и пользователи бывают разными. Во времена расцвета нестандартных окон под Windows, которые делали через всякие хаки WinAPI, пользователи Mac'ов крайне негативно относились к "неродным" для этой ОС контролам и интерфейсам, и что-то написанное на Java можно было протолкнуть, только это был безальтернативный кровавый энтерпрайз.
VBDUnit
20.04.2026 05:20Всё относительно. В те времена это было «вау» и работало, потому что «Windows only» в те времена это даже хлеще чем сейчас «Anrdoid only». Применять современные мерки к тем штукам бессмысленно. Примерно как рассуждать о непрактичности карет с лошадьми на фоне автомобилей.
HemulGM
20.04.2026 05:20Подойти к реализации этой идеи можно разными способами.
Это вот работает у меня и на Винде и на Лине
NeoCode
20.04.2026 05:20Мне такие нестандартные окна не нравятся, хотя для вау-эффекта выглядят прикольно. Но все-же идеология разделения клиентского и системного UI должна быть. Вот client area, в ней рисуй что хочешь, но за пределы не вылезай - система должна оставаться системой.
А вот современные окна в современных ОС, несмотря на их "прямоугольность", реально бесят. Отсутствие явного заголовка, четких границ окна, полосы прокрутки вообще практически невидимые, какие-то невзрачные элементы управления (кнопки и прочее) - зачастую непонятно кнопка это или просто надпись. Лучшие окна были в старых классических системах: Win95/98/XP, в семерке еще можно настроить классическую тему, но увы - все современные браузеры даже под линукс пропихивают этот баззаголовочный ужас.
То есть "окна странной формы" и современный UI - это два отклонения в разные стороны, а норма была в старых добрых системах. И ее прелесть в том, что элементы управления были заметные и скевоморфные, но при этом стандартные и структурированные, что избавляет от необходимости привыкать к каждому конкретному интерфейсу.
VBDUnit
20.04.2026 05:20Мне нравится как сделан интерфейс в Microsoft Office до 2003 версии включительно. Там все элементы на панельках можно как угодно перетащить и настроить под себя. Панельки вытаскиваются в отдельные окна, прилипают к краям экрана, группируются как угодно. А меню сверху и списки со шрифтами являются частным случаем таких перетаскиваемых кнопочек — туда можно впихивать нужное и убирать ненужное, настраивается абсолютно всё.
Фокус в том что эти менюшки‑кнопочки настраивались в GUI через Drag&Drop. То есть интерфейс был редактором самого себя. Ты не настраиваешь список команд в отдельном окне, ты буквально перетаскиваешь кнопки на панельку/менюшку.
Для простого пользователя это оверкилл+переусложнение. А вот для профессионального использования это прекрасно, я считаю. В VisualStudio кажется до 2008 версии так тоже было можно делать, потом порезали. Вообще, в современном тяжелом софте такое сейчас встречается. Например, в 3ds max есть кастомизируемый ленточный интерфейс, где тоже всё можно таскать и настраивать.
Arhammon
20.04.2026 05:20Ну в том же 3Д/САПР профессиональное использование подразумевает клавиатуру, а интерфейс зачастую для неофитов(тут автодескам заслуженная 5ка) или вообще на него положен большой и толстый болт... Ну просто холостой выбег мыши от детали до интерфейса очень большой
FoxWMulder
20.04.2026 05:20согласен с автором. в туже степь: недавно в очередной раз обратил внимание на стенд со смартфонами в магазине, точнее на то что все, ВСЕ, абсолютно все смартфоны это прямоугольник с экраном. все экраны были погашены - картина 30 штук чёрных прямоугольников. просто нет таких смартфонов теперь которые своим дизайном производили бы вах эффект и хотелось бы их купить.
электрон тоже не люблю. электрон это то что лучше бы вообще никогда бы не создавали.
valera_efremov
20.04.2026 05:20Фото
Снова обретают популярность раскладушки. Так же появился новый форм-фактор - книжки
maxzh83
20.04.2026 05:20Аж олдскулы свело, я делал такие окна на vb и delphi в начале 00-х и мне это казалось фантастикой и хакерством. Добрые были времена. Сейчас выберу что-то стандартное. Но приложения на браузере осуждаю)
LF69ssop
20.04.2026 05:20Как по мне так правильнее когда внешним видом окон и элементов управления занимается оконный менеджер. И только он.
Для этого в том числе и придуманы темы оформления.
urvanov
20.04.2026 05:20А мне приложения со стандартным интерфейсом нравились. Хотя бы понятно было, куда кликать. А сейчас зачастую вообще не поймёшь, что там у них в интерфейсе.
vvbob
20.04.2026 05:20Меня сильно раздражает современная любовь к "воздушным" интерфейсам, когда на весь экран у тебя одна кнопка и поле ввода, и что-бы что-то настроить надо по десятку экранов пройтись по мудреному маршруту с развилками, при этом огромная площадь остается незадействованной, занята просто фоном или дизайнерскими украшательствами.
Особые лучи возмущения тем, кто делает крохотные поля ввода для длинного текста, при огромным свободных пространствах.
vvbob
20.04.2026 05:20Культура десктопного UI перестала считать крутыми безумные скины, она хочет, чтобы окна надёжно работали и не мешали процессу. Странные окна стали ассоциироваться с уловками, рекламным ПО, панелями инструментов и раздутыми утилитами, нежели с серьёзным ПО. И это печально.
Эта ассоциация не на пустом месте появилась, часто именно так оно и было, все эти выпендрежные окна очень любили разные создатели мусорного ПО, которого в те годы тоже хватало. Да и все эти нестандартные украшательства довольно сильно раздражали. Бывало непросто догадаться как такое окно свернуть, перетащить, хоть как-то с ним взаимодействовать. Как по мне хорошая ОС должна стимулировать писать под нее максимально стандартным способом, со стандартным интерфейсом. Пользователь не должен ловить ступор, видя окно с которым непонятно вообще как работать.
aitras
И хорошо, что теперь не так, ИМХО.
Goron_Dekar
Как раз очень плохо, что всё ещё так. Не хватает унификации в вебе. Все эти тошнотные плоские кнопки, менню-неменю и прочий треш, потихоньку лезущий через electron в обычные приложения, угнетает мой больной ум.
achekalin
Это обычно подается как "минималистический интерфейс", на деле же переводится как "разработчик не умеет в UI-удобство".
И это даже нормально - не все умеют.