Комментарии 97
В общем всё верно написано. У меня вот прямо сейчас в разработке небольшое измерительное приложение под Windows (оно на Расте написано), выглядит вот так:
С математикой (Фурье, интерполяции) всё хорошо, но каждый, кто хоть когда-нибудь сам делал вьюпорт для картинки с зумом, скроллингом и метками, регионами интереса, либо графики с множественными осями и аннотациями знает, какая это попаболь бывает местами. Вот казалось бы сейчас ИИ, скорость разработки улетает в небеса, но как-то вменяемых фреймворков, чтобы с WYSIWYG — нет их пока хороших и удобных. Конкретно для Раста есть целая куча всяких разных egui, gpui и т.д., но стоит начать делать приложение как выше, и количество бойлерплейта и "обвязки" просто начинает зашкаливать. Смотрю на Дельфи с нежной грустью.
LabView возьмите ;)
С LabVIEW я работаю с середины 2000, и там с интерфейсом всё норм, но ирония в том, что на Расте я теперь пишу быстрее, потому что я могу ему просто сказать "а теперь по вот этому вектору, сделай Фурье, возьми магнитуду и дай мне значение на 10%, до кучи рассчитай частоту Найквиста", и получаю живой рабочий код, а Nigel AI из LabVIEW - это жалкое подобие копилота, он так не умеет. Впрочем тот интерфейс, что выше, взят из NI CVI, я сделал биндинги и наступило почти счастье ("почти" - потому что не кроссплатформенно это), так что "ноги" в общем растут из того же места, что и LabVIEW (декорации у графиков и вид переключателя как бы намекают).
Хе-хе. То-то я и чувствую узнаваемый стиль.
Да, я вот тут писал, как там всё устроено.
Чтобы попаболь была не только местами с закатом солнца вручную с графиками/зумом/скроллом, а вообще везде? а месье знает толк ;)
Досталась как-то в наследство некая измерительная программа где так же решили в качестве гуёвой библиотеки взять даже не labview, а аж labwindows (тот же рантайм но со своим нескушным С89 в качестве языка) - "много всякого говна я в своей жизни повидал, но гаже вот этого ещё не было"(с)
А для программы @AndreyDmitriev типа как на скриншоте выше, когда надо на лету графики показывать, я бы просто gnuplot позвал с его родным терминалом и зумом/скороллом/..., да немного коряво, что отдельное окошко, но всё равно лучше всякой самодеятельности с графиками.
Чтобы попаболь была не только местами с закатом солнца вручную с графиками/зумом/скроллом, а вообще везде? а месье знает толк ;)
Ну нет в мире совершенства, что уж тут поделать...
я бы просто gnuplot позвал с его родным терминалом
Я в курсе, но покажите мне хоть одну современную среду разработки, которая возьмёт gnuplot и позволит набросать интерфейс вот так:
это что на гифке?
Это тот самый "labwindows" из коммента выше (точнее LabWindows/CVI). Я просто биндинги к Расту прикрутил и избавился от "нескушного С89", точнее C99.
RAD Studio, Delphi
Про RAD Studio я в курсе, но мне и придётся писать тогда на Дельфи. Против Дельфи я ничего не имею, даже использую для небольших андроид приложений (мне так проще), но на десктопе хочу использовать Раст, а туда такой роскоши в виде VCL не завезли. Нет в мире совершенства.
Про RAD Studio я в курсе, но мне и придётся писать тогда на Дельфи.
Можно и на C++
Но я не уговариваю :)
Напиши dll/so, в общем проект библиотеки на Раст. И в ней опубликуй одну единственную функцию, которая вернёт тебе ссылку на интерфейсный объект, в котором будут все нужные функции. И готово. В обратную сторону тоже можно.
Придется, к сожалению, параллелить код интерфейса, но я не думаю, что это большая проблема. В крайнем случае можно даже небольшой конвертер написать.
Смотрю на Дельфи с нежной грустью
Так в чем проблема? Делфи никуда не делось. И там всякие эти графики навороченные есть, и масштабируемые и с осями и т.п.
На Дельфи я писал довольно много в конце девяностых, но сейчас мне нравится Раст больше. На самом деле я в процессе изучения, и "открываю" всё новые и новые стороны языка, это увлекательный процесс. И мне иногда снится среда разработки, такая как RustRover, но с VCL, как на Дельфи. А Дельфи не так cильно эволюционировал, хоть туда и завезли дженерики и лямбды, но что-то не хочется возвращаться к begin...end. А, и там вроде до сих пор запрещён инлайн ассемблер в 64 бит, а я балуюсь этим иногда. В Расте - нет проблем.
Зато там нативный VCL, а что в Расте сейчас - Tauri и Electron?
Не только они, там много чего есть - Are we GUI Yet?. В общем никто не запрещает на чистом WinAPI это делать через FFI, просто возни довольно много будет, по части обработки сообщений в том числе.
А чего бы не сделать ядро на расте, а гуй на делфи?
Я думал об этом, но пока не знаю как элегантно скрестить их вместе и пробросить в код на Расте коллбеки от изменения контролов без создания внушительной библиотеки-помощника.
Лиспом! ;)
На правах шутки, которая не очень шутка:
в современных реалиях это может сделать ИИ, и я имею в виду не написать библиотеку, а каждый раз при компиляции, создавать прослойку между двумя проектами, это очень простая операция, с ней однозначно справится агент на базе дешевых быстрых llm или сделать генератор на основе каких-нибудь анализаторах кода. Например rust код как dll библиотека, подключаемая в delphi... и там все будет unsafe.
Не запрещен там инлайн вам 64
Писать нормальный WYSIWYG это адски дорого в поддержке. Вендорам проще заставить нас верстать формочки кодом, чем пилить визуал
Не только дорого, но и бесполезно - WYSIWYG концепция хорошо работает только на простейших интерфесах где все свалено в одну кучу, но довольно быстро разваливается когда компоненты интерфейса начинают зависеть от данных, а в design-time их нет. Или от архитектуры - достаточно вместо одного божественного файла на 9 тысяч строк применить какой-н паттерн со вложенными вьюмоделями например и все, а в возможности формошлепить мышкой отдельные панельки в этом случае ценности не особо много.
Это в простейшем случае справедливо, но C#/WPF с разметкой в XAML в общем как-то работает, Авалония норм, кстати, я по работе ПЛК B&R иногда программирую, там в mappView примерно такая же концепция. Важно, чтобы визуальное представление было отделено от кода, а не так как в том же egui, где всё вперемешку:
eframe::run_ui_native("My egui App", options, move |ui, _frame| {
ui.ctx().request_repaint_after(Duration::from_millis(50));
egui::CentralPanel::default().show_inside(ui, |ui| {
ui.heading("My Application");
ui.label(format!("Counter: {}", counter_value));
ui.label(format!("Average Pixel Value: {:.2}", avg_value));
ui.label(format!("FPS: {}", fps_value));
ui.separator();
// и пошло поехалоТакже важно, чтобы я в статике мог свойства контролов и индикаторов поменять, при этом создавать их динамически когда надо, ну и по итогу чтобы всё это потом не натягивалось на веб через HTML, когда грубо говоря браузер начинает всё это отображать с чудовищным оверхедом.
И WPF весьма неплохо оптимизирован под даже слабое х86 железо. В отличие от Electron'ов/WebView2 и тп, WPF практически как UWP и win32 не грузит на ровном месте компьютер, софт менее раздутый, чем у самых новых фреймворков. И это радует :)
При этом Android, где долгое время жила XML разметка интерфейсов, внезапно решил вернуться к истокам в виде Jetpack Compose с его формочками в коде.
Я так и не понял зачем это произошло, вроде недавно (ну как недавно, лет 15 назад) отказались в джава-мире от Swing с ровно тем же подходом, а тут обратно к нему вернулись.
Почему не qt/c++? Старое провереное решение, которое просто работает
Делфи кроссплатформенный и стабильно развивается. Легко решит эту задачу
Оказывается, не только у Линукса всякий зоопарк технологий и фреймворков, но и у винды тоже! и если надо делать кроссплатформенное приложение, то как всегда остаётся Java. Да, ещё развивали Mono/.Net, а также QT. Потом стали развиваться веб-технологии и появился Электрон, приложения на котором будут тащить браузер, даже если надо просто показать одно окно.
В общем, всё как на картинке про 16 конкурирующих стандартов.
Думаю, по количеству платформ QT и Flutter вне конкуренции
Одно слово - Avalonia
Эх, кто бы её к Расту прирастил, наступило бы счастье. На реддите вроде был робкий эксперимент, но кода так и не показали.
Avalonia не все так просто, вроде и кроссплатформ, но как только начинаешь копать, начинают вылазить всякие неприятные вещи. Там из без этого на бумаге все хорошо, пока собственно не начинаешь что-то делать, более-менее серьезное. Да и раз тут контекст от комментария выше про электрон, я видел достаточно приложений на авалонии которые как минимум по весу даже больше чем весь электрон вместе взятый. (а это основной хейт в его сторону, т.к. все считают что приложение бы весило 10-20 мегабайт, а остальное это все затраты от веб технологий)
Delphi имеет кроссплатформенный GUI WYSIWYG фреймворк и позволяет собирать его под Win, Linux, Mac, Android, iOS.
https://xkcd.ru/927/
Погуглите Джоела Спольски "Огонь и движение", там как раз про это.
Статье 20+ лет, но ничего не изменилось.
Подумайте об истории всевозможных стратегий доступа к данным, разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET - И все абсолютно новые! Может это было вызвано технологической необходимостью? Может это результат некомпетентной группы проектирования, которой необходимо придумывать по-новой доступ к данным каждый чертов год? (Возможно, это в самом деле так.) Но конечный результат - всего лишь огонь для прикрытия. Конкуренты не имеют никакого другого выбора, кроме как тратить своё время, переписывая код под новые библиотеки и поспевая за лидером - время, которое они не могут использовать для создания новых возможностей.
Вот как ни крути, всё, кроме чистого WinAPI, это костыли и обёртки, из-за которых итоговая масса приожения будет в разы больше, чем его собственный код из-за килотонны зависимостей, которых надо либо доустанавливать пользователю, либо таскать их с собой вместе с приложением. Если я пишу программы под Windows без Qt (который в основном использую на линухах и макоси, а также под винду отдельные сборки), то стараюсь точить под чистый WinAPI, чтобы приложение было максимально компактным и независимым, а также чтобы самостоятельно контролировать совместимость со старыми и новыми системами. Единственный плюс подобных обёрток - упростить разработку и сократить время создания конечного продукта, но, ценой компактности и даже совместимости с конкретными системами.
Дополняю: лично я больше всего недолюбливаю Electron, из-за того, что приложения получаются крайне неповоротливыми и чрезвычайно прожорливыми, даже не смотря на то, что выполняют жалкий минимум, который легко запихнуть в исполняшку на Чистом Си весом несколько килобайт.
Вот как ни крути, всё, кроме чистого WinAPI, это костыли и обёртки
К сожалению, используя только чистый WinAPI, невозможно использовать все GUI-фичи, поддерживаемые виндами.
Ну WinAPI это не только базовый набор, но ещё куча куча различных библиотек в составе, которых тоже можно задействовать, чтобы добраться до нужной фишки. Не спорю, что некоторые подобные фишки сами реализованы на других языках или интерфейсах, и с ними надо стыковаться совсем по другому. Либо базовый WinAPI чего-то НЕ даёт, и это нужно реализовать самостоятельно, программно на голом виджете, хватая вручную события мышки и клавиатуры, и выводя анимацию при взаимодействии с подобными штуками.
Как через WinAPI вписаться в оконный композитинг с акриловой кистью? Это спор (в смысле дискуссия), который я ХОЧУ проиграть.
В плане, чтобы создать инструмент для графического редактора, или интеграция с графическим планшетом и стилусом? Или тему оформления окна сделать?
https://learn.microsoft.com/en-us/windows/apps/design/style/acrylic
Вообще, поработав хотя бы с одним худо бедно большим интерфейсом, за чистое WinApi топить странновато. Примерно как за ассемблер в качестве языка программирования.
Понял, и я тут же накопал демку https://github.com/selastingeorge/Win32-Acrylic-Effect и описание того, как именно тот смог это повторить. И более того, заявлено, что оно будет работать даже на виндосемёрке/восьмёрке, но автор не проверял (могу потом по приколу проверить дома, виртуалки есть).
И кстати, я бы мог применить подобную штучку кое-где в своём проекте, чтобы окошко одно выглядело по красивее. На виндосемёрке с эффектом Aero оно у меня красивое, а на всём, кроме Vista и 7, используется базовый стиль, ибо фишка провоцирует глюки. Но сделать мне надо это так, чтобы не ломало совместимость с Windows XP (проект сам целится на ретрокомпьютеры в том числе).
Там есть подходы, про которые я не знал, за это вам большое спасибо и плюс в карму (если это в наши дни ещё что-то значит).
Не в огорчение вам (ещё раз спасибо за то, что поделились), ничего из этого демо, к сожалению, не годится. Сам пример не работает с несколькими мониторами, а автор не знает, как это пофиксить (это же недокументированный хак). И предлагает юзать официальный интероп.
Я ещё покурю SetWindowCompositionAttribute(), про который автор пишет, что его позже сломали, но в любом случае для продакшена… что-то мне совсем не хочется закладываться на недокументированные функции.
В общем, Майкрософт — @#$%^&^.
Для крупных проектов использую Qt, первым делом потому, что точу кросс-платформенно, а не исключительно под Windows. Но вот мелочёвку в виде специфичных утилит, настроечников и т.п. пишу на чистом WinAPI, чтобы весило мало.
пишу на чистом WinAPI
А, кстати, как вы это делаете, неужели начиная с CreateWindowEx, и дальше там ShowWindow и очередь собщений и всё такое? Я, в принципе могу, тряхнув стариной и на чистом асме сделать оконное Windows приложение, но прогресс-то на месте не стоит, или вы WinForms имеете ввиду или просто консольные приложения пишете?
CreateWindowEx - GetMessage - DispatchMessage
либо DialogBoxParam - декларативный, при том нативный подход
Плюс, сегодня с агентной разработкой это стало проще - агенты отлично пишут на WinAPI, им не нужны эти фреймворки (которые делались именно для людей).
WinForms это вовсе не WinAPI, это гигантская библиотека из набора .NET. Если говорить о чистом WinAPI, конечно же CreateWindowEx, GetMessage и DispatchMessage, ну и говоря о формах, максимум диалоговые окна через редактор ресурсов (.rc-скрипты) собрать, и потом хватать их через соответствующие функции. Но вот серьёзные окна лучше собирать динамически из кода.
Для разработки gui на win32 был и wisiwyg дизайнер форм (как штатный от visual studio так и сторонние, например недавно почивший ResEdit) так и встроенный генератор кода (visual studio и вроде бы есть ide pelilsc).
Вот пример простейшей формы (создано openai:gpt5.5 api)
resource.rc
#include <windows.h>
#include "resource.h"
IDD_MAIN DIALOGEX 0, 0, 260, 150
STYLE DS_SETFONT | DS_MODALFRAME | DS_CENTER | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX
CAPTION "Win32 ListBox Demo"
FONT 8, "MS Shell Dlg", 400, 0, 1
BEGIN
LTEXT "Text:", -1, 10, 12, 35, 10
EDITTEXT IDC_EDIT, 50, 10, 140, 14, ES_AUTOHSCROLL
DEFPUSHBUTTON "Add", IDC_ADD, 200, 9, 50, 16
LISTBOX IDC_LIST, 10, 35, 240, 100, LBS_NOINTEGRALHEIGHT | WS_BORDER | WS_VSCROLL | WS_TABSTOP
ENDresource.h
#ifndef RESOURCE_H
#define RESOURCE_H
#define IDD_MAIN 100
#define IDC_EDIT 1001
#define IDC_ADD 1002
#define IDC_LIST 1003
#endifmain.c
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include "resource.h"
static void AddTextToList(HWND hDlg)
{
char text[512];
GetDlgItemTextA(hDlg, IDC_EDIT, text, sizeof(text));
if (text[0] != '\0')
{
SendDlgItemMessageA(
hDlg,
IDC_LIST,
LB_ADDSTRING,
0,
(LPARAM)text
);
SetDlgItemTextA(hDlg, IDC_EDIT, "");
SetFocus(GetDlgItem(hDlg, IDC_EDIT));
}
}
static INT_PTR CALLBACK MainDlgProc(
HWND hDlg,
UINT msg,
WPARAM wParam,
LPARAM lParam
)
{
(void)lParam;
switch (msg)
{
case WM_INITDIALOG:
SetFocus(GetDlgItem(hDlg, IDC_EDIT));
return FALSE;
case WM_COMMAND:
switch (LOWORD(wParam))
{
case IDC_ADD:
if (HIWORD(wParam) == BN_CLICKED)
{
AddTextToList(hDlg);
return TRUE;
}
break;
case IDCANCEL:
EndDialog(hDlg, 0);
return TRUE;
}
break;
case WM_CLOSE:
EndDialog(hDlg, 0);
return TRUE;
}
return FALSE;
}
int WINAPI WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow
)
{
(void)hPrevInstance;
(void)lpCmdLine;
(void)nCmdShow;
DialogBoxParamA(
hInstance,
MAKEINTRESOURCEA(IDD_MAIN),
NULL,
MainDlgProc,
0
);
return 0;
}собрать на linux (нужен mingw или mingw-w64):
x86_64-w64-mingw32-windres resource.rc -O coff -o resource.o
x86_64-w64-mingw32-gcc main.c resource.o -o win32_listbox_demo.exe -mwindowsК сожалению, отсутствие хоть какой то поддержки 4k мониторов (а точнее динамической подстройки под dpi), полностью убивает принципиальную возможность вернуть это.
ой как интересно, а поддержка dpi есть, если ее не включать, приложение при включенном масштабировании windows становится 'мыльным', но если добавить манифест и его в .rc
Скрытый текст
app.manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="*"
name="Win32ListBoxDemo"
type="win32"
/>
<description>Win32 DPI aware demo</description>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<!-- Windows Vista+ -->
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
true
</dpiAware>
<!-- Windows 10+ -->
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
system
</dpiAwareness>
</windowsSettings>
</application>
</assembly>resource.rc
#include <windows.h>
#include "resource.h"
#define RT_MANIFEST 24
1 RT_MANIFEST "app.manifest"
IDD_MAIN DIALOGEX 0, 0, 260, 150
STYLE DS_SETFONT | DS_MODALFRAME | DS_CENTER | WS_POPUP | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX
CAPTION "Win32 ListBox Demo"
FONT 9, "Segoe UI"
BEGIN
LTEXT "Text:", -1, 10, 12, 35, 10
EDITTEXT IDC_EDIT, 50, 10, 140, 14, ES_AUTOHSCROLL
DEFPUSHBUTTON "Add", IDC_ADD, 200, 9, 50, 16
LISTBOX IDC_LIST, 10, 35, 240, 100, LBS_NOINTEGRALHEIGHT | WS_BORDER | WS_VSCROLL | WS_TABSTOP
ENDто все меняется, причем .rc размеры будут корректно преобразовываться в пикселы согласно настройкам dpi, но приложение должно само, в случае каких то работ с формой преобразовывать dialog units в пикселы, согласно base units.
p.s. т.е. это реально, разрабатывать приложения dpi aware для современных систем на базе win32, не скажу что это будет удобно, НО! у нас есть ИИ, которому можно давать эту простую и скучную работу.
Скрытый текст
Есть же замечательный лёгкий Windows Template Library (WTL), прекрасно дополняющий ATL, и ещё даже немножко живой.
Вообще, поработав хотя бы с одним худо бедно большим интерфейсом, за чистое WinApi топить странновато
Если у вас для большого интерфейса есть большой движок на плюсах, а от виндов как таковых вам нужна только пара эффектов, то интероп не порадует. (Блендинг вы не можете сделать изнутри движка — я первый раз попробовал сколхозить этот эффект при помощи текстуры с альфа-каналом десять лет назад, и это было жалкое зрелище… хотя и пошло в продакшен (ударение в слове «пошло» можно ставить любое)).
Ну почему же. Я вот думаю что "все GUI-фичи" как раз и работают через WinAPI. По-другому они в принципе работать не могут.
Тут большое поле для софистики. Отобразите HDR картинку внутри окна. GUI-фича? Почему нет. В лучших win95-практиках, через дедовский софтварный GDI, без вариантов, придется заиспользовать DirectX. Это API? API. Это Windows? Windows. Значит WinAPI - cомнительно но окэй. Но можно и через OpenGL, а это уже по другому...
Два чая этому господину! Я тоже стараюсь максимально писать на чистом WinAPI
Вот как ни крути, всё, кроме чистого WinAPI, это костыли и обёртки
Обёртками вокруг Win32 API являются только MFC и WinForms. WPF, Swing, Flutter, QT, Tauri отрисовывают свои контролы сами. Из перечисленных я работал со Swing, он гораздо богаче того, что есть в Win32 API (ui.dll + comctl.dll), ни разу не костыли.
интересный факт, если приложение будет полностью winapi (без рюшечек, графических дополнений и т.п., чистые нативные контролы), то это приложение может практически без особых тормозов работать через rdp удаленный доступ чуть ли не на модемном соединении (ну ок, edge/gprs со 100кб/с), ни одно другое современное приложение так не сможет (исключение, какие-нибудь хитрые diff прокси для html, примером такой прокси была opera mini)
все современные смогут более менее комфортно транслироваться на удаленный терминал только по технологиям видеокодирования (они есть в rdp старших версий)
Вы на практике это пробовали? Есть некоторые сомнения что современную версию протокола можно заставить работать в этом режиме вместо видео кодека
ни одно другое современное приложение так не сможет
современные приложения, когда предназначены для такого сценария - тонких клиентов используют, это работает куда лучше, никакой rdp не нужен
В Delphi, VCL - не тянет никаких зависимостей для создания Win32 интерфейсов. Кроссплатформенный FMX фреймворк - тоже не тянет никаких зависимостей.
Так целостной концепции ни в одной ос нет. А там где кажется что она есть, казаться так будет (да и в принципе будут мысли о какой то целостной концепции) до первой задачи сделать что то кроссплатформенное или портировать что то.
Есть ешё Sciter если нужен GUI на HTML (жив ли он?) и куча мелких библиотек для GUI, которые в статью не попали. Вообще, у Windows не только с графическим интерфейсом проблемы, но и с другими технологиями, см.
История программных революций от Microsoft, вкратце:
Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они таки представили концепцию «System File Protection», исключающую DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
В конце девяностых я прослушал целый доклад на конференции, стараясь понять разницу между документом OLE, объектом COM и управлением ActiveX. Я весь час смотрел на выступающего с недоумением, будто у него изо рта торчал крысиный хвост.
Смотрим оригинал.
I sat through a conference session in the late nineties trying to understand the difference between an OLE document, a COM object, and an ActiveX control.
Артикль “an” перед “ActiveX control” говорит нам, что это не может быть «управление». Это именно контрол, то есть, говоря литературным языком, «элемент управления».
А разница очень простая.
Объект COM — это бинарный (то есть, не требующий виртуальном машины из Java, .Net или браузера) объект, написанный на одном языке, а используемый на другом. Для этого были придуманы роли (интерфейсы) и строгие правила, по которым объекты играют эти роли (как они расположены в памяти, кто чистит стек после вызова и т.п.). Если ты соблюдаешь эти правила и на языке C++, и на языке Паскаль, то объекты (например, хранилище данных или парсер текста или что угодно ещё) можно написать на C++, а использовать в Delphi.
Если среди играемых ролей есть набор «то, что умеет любой элемент управления по стандарту ActiveX», такой объект COM становится элементом управления ActiveX (например, кнопкой, графиком или полем ввода).
Если какое-нибудь приложение написано по стандарту OLE (их там, насколько я помню, три, два из которых — стандарт на то, как быть гостем, и стандарт на то, как быть хозяином), то его документы могут содержать вставки с документами чужих (неизвестных) приложений. Например, электронную таблицу внутри отчёта в текстовом редакторе, при щелчке по которой интерфейс текстового редактора незаметно заменяется интерфейсом электронной таблицы. Документы таких приложений и называются «документами OLE». А чтобы соответствовать стандарту, надо уметь создавать объекты COM, играющие такие роли как «чужой документ внутри моего документа».
Однако, несмотря на придирки, в целом автор прав: с уходом Гейтса в МС развели самый настоящий бардак. А переводчик, в целом, переводит хорошо, и берёт интересные статьи, за что ему спасибо.
Один отдел пилит годный фреймворк, а соседний его закапывает, потому что у их вице-президента другие KPI - корпоративная разработка стайл
Для того, чтобы иметь целостную концепцию чего бы-то ни было, нужно, для начала, иметь желание что-то такое целостное предложить. Существует ли хотя бы одна работа (вполне себе научная проблема), посвящённая пользовательскому интерфейсу (каким он может/должен быть)? От создателя операционной системы (ОС) ожидаешь именно концепцию пользовательского интерфейса, то есть — целостное описание того, какие могут быть элементы, как они стандартно реагируют на действия пользователя. У каждой ОС должен быть свой пользовательский интерфейс, то есть — своя логика обработки событий.
Если бы такое целостное представление о GUI существовало в те времена, то не случился бы и взлёт web-приложений: web-приложения закрыли вопрос с GUI при помощи браузера, хотя и здесь (также по естественным и очевидным причинам) возник зоопарк технологий. Далеко ходить не надо: достаточно посмотреть как на деле реализуется данная страница (страница комментариев Хабра), чтобы взяться за голову. А если бы был стандартный GUI, то к нему было бы легко добавить слой, связанный с удалённым (распределённым) управлением.
Кстати! Для примера. Если взять комментарии (как здесь, на Хабре), то как такая страница могла бы быть реализована средствами стандартного GUI ОС? Заметим, что сами комментарии — это дерево (при этом у нас должна быть возможность переключаться из одного линейного или плоского режима отображения реплик в другой развёрнутый или иерархический режим отображения). Здесь нужен стандартный компонент, который способен отображать дерево. Но элементы (узлы) этого дерева — это специальные блоки. Вот и возникает фундаментальная проблема построения GUI: как реализовать компонент ДЕРЕВО (TTreeView?), чтобы при наличии определённого вида узловых элементов (TTreeNode?) обеспечивать требуемое поведение (добавление комментариев, голосование, создание закладок)?
Насколько же бесит нейрослоп в диаграммах. Ну не может модель рисовать текст нормально — так что мешает сделать поверх сгенерированной картинки текстовые блоки в графическом редакторе (хотя бы даже со сгенерированным текстом — с этим модели как раз справляются)? Но нет, вывалим всё как есть, с неведомыми символами вместо букв.
Всего навсего, в технологии полезли маркетологи, с большой буквы.
Скорее всего кроссплатформенная концепция могла ударить по самому майкрософт тем что компании в один прекрасный момент начнут от windows отказываться в пользу более дешевых альтернатив, типа linux+mono.
Не по этой ли причине майкрософт примерно в это же время, купила и уничтожила monodevelop?
Правильно ли я понял, что автора очень сильно возмущает то, что у разработчиков есть возможность выбора средств разработки?
Скорее, что средства на выбор ведут себя не всегда одинаково.
Могу от себя сказать, что MS за столько лет (с 95-ки, кажется) так и не вылечила баг, при котором половина функций полагает точку "0;0" в углу экрана, а другая функция - в углу видимой части экрана (т.е. за вычетом таскбара и прочего). Пока панель задач внизу - всё ок, а вот если её переставить наверх - половина окошек заголовками залезают под таскбар, и работать становится невозможно.
Смешно, но в 10 и 11 версиях с этой напастью справились - сделав вид, что её нет, потому что быть не может. Просто запретили перемещать таскбар наверх.
Так что претензии к MS имеют место быть, да. А еще больше - за нежелание фиксить.
Фраза "одна ОС, один API, один язык" звучит немного как отсылка на не очень приличный лозунг)
Вот и получается потом, что Codex под Mac умеет работать сразу с разными курсорами под разные окна, а под Windows всё норовит твой курсор утянуть и потом текст куда попало лепить. Но, с другой стороны, у Windows во главу угла поставлена обратная совместимость, что не может не радовать, хотя работает иногда своеобразно.
MAUI (2022) — кросс-платформенный последователь Xamarin.Forms. Текущий приоритет команды .NET.
Идут разговоры о том, что MAUI - все. К счастью, для .NET есть Avalonia. К счастью потому, что ее делает не MS.
увы, что Avalonia, что MAUI - очень громоздкие и медленные тулкиты. На фоне WPF и WinForms выглядит очень неповоротливо и если ищется тулкит не для огромного монстра уровня IDE/Офисного пакета/Ещё какой-то крупной среды - то запускать такое уже неприятно - будто какую-то стильно-модно-молодёжную фигню, даже электрон порой быстрее стартует...
Кстати, Windows Forms можно использовать и для кроссплатформенных приложений. Есть порт реализации из Mono на современный дотнет. К сожалению gdiplus не развивается, потому на юниксах пока что рисуется только через иксы, но при желании это можно поправить. Но выглядит, к сожалению, убого.
Windows Forms можно использовать и для кроссплатформенных приложений
Если вас не затруднит ткнуть пальцем, я был бы чрезвычайно благодарен. Гуглится как-то отменно скверно.
Спасибо за статью, это великолепно. Как человек, 30 лет занимающийся GUI разработкой под винду, досыплю еще:
wxWidgets: конкурирует по популярности с Qt. Нативные виджеты FTW.GTK: менее популярно для Windows нежели wxWidgets и Qt. Но его использует, например, GIMP.FLTK: младший брат Qt и GTKTk(без TCL): держится на плаву во многом благодаря Python'овскомуtkinterGlimmer: новый любопытный подход, делающий ставку на Ruby и DSL (да, звучит как безуминка, но они довольно популярны)Honorable mention:
LibUI,Clutter,ImGui
Сорри, ностальгия и не смог удержаться.
Я со своей командой шипнул первое WPF приложение в MS. С одной стороні - ад тормозов и мемиори ликс (как я же тогда прокачался в использовании Sos, спасибо Wintellect за дебаг курсі), с другой стороні - в то время все віглядело очень перспективно. Мне кажется WPF убила некомпетенция разработчиков. Ну и Vista конечно ... єто біл дикий ад (большинство на Windows Server сидело). Visual Studio я так и не смог принять с тех времен. Вообще у MS уже давно проблемі с тех скилами (чего только Azure стоит).
У Silverlight біла своя ".Net" імлементация - политически их мочили все. Єто біла крутая технология!
Я сейчас использую Tauri, мне нравится. И Rust в тему, хотя я давний ценитель C++.
Далее же мы наблюдали показательный пример того, как компания с умнейшими специалистами и огромными ресурсами может в течение тридцати лет творить несуразицу,* оптимизируя продукт не под те задачи. Иначе говоря, это был пример того, как умнейшие люди делают глупые вещи.
Не согласен с утверждением. В данной формулировке получается, что умнейшие люди занимаются хе...й по своей воли. Но, я смотрю на эту проблему с другой стороны, разработчики в MS стали жертвой корпоративщины. Пример, добавление возможности запуска Android приложений на Windows 11 (Windows Subsystem for Android, WSA).
В руководстве, видимо после провала Windows Phone, был следующий гипотетический диалог:
Менеджер: смотрите, Android популярная ОС на телефонах. В мире миллиарды пользователей ОС Android. А давайте забацаем запуск Android приложений на Windows? Это же круто?
Разработчик: приложения с технической точки зрения разработаны под взаимодействие с малым форм-фактором экрана и сенсорным управлением. И зачем запускать Android приложения на Windows, если у пользователя и так есть Android смартфон?
Менеджер: ты ничего не понимаешь в потребностях пользователей, делай!
Итог, Microsoft прекратила поддержку подсистемы Android (WSA) в Windows 11 5 марта 2025 года по причине отсутствия широкого распространения, а работа с магазином приложений Amazon вместо Google Play, ограниченный выбор приложений и технические сложности не привлекли массового пользователя. Казалось бы, что могло пойти не так?
Почему возникла чехарда с UI в .NET? Ответ лежит на поверхности, после трансформации .NET Framework в кросс-платформенный netcore, кому нафиг нужна будет Windows, если UI нативно можно будет запустить на Linux. Это единственное, что держит Windows на плаву.
У меня включена статистика по сайту, материал публикуется сугубо технический, если взять за 100% все операционные системы семейства Windows, то получается следующий результат:
Windows 10 - 50%
Windows 11 - 45.7%
Остальные версии Windows ниже 10 (основная доля Windows 7 и Windows 8.1) - 4.3%
Учитывая окончание поддержки Windows 10 в октябре 2025 года, это полный провал, новая ОС Windows нафиг никому не нужна по доброй воли.
На данный момент работаю на Windows 10 Enterprise 2021 LTSC, даже лицензия куплена. Но далее, прорабатываю переход на Ubuntu. Скорее всего Windows платформа останется для игр Steam, но работа перейдет полностью на Ubuntu.
У Microsoft не было целостной концепции GUI со времён Петцольда