Странная любовь разработчика, или Как я перестал беспокоиться и полюбил Windows

Это эссе о том, как обращаться с ощущением «на каждом окружении может сломаться», которое сопровождает разработку Windows-приложений. Это не статья про то, как вызывать API.

DLL, COM, 32-bit / 64-bit, права доступа, DPI, распространение. Почему Windows вообще тащит на себе эти поводы для тревоги — и как превратить эту тревогу в проектирование, тесты и наблюдение. Если нужно унести что-то практическое, достаточно таблицы «тревога / проектное решение / как проверить» в главе 6.

1. Сначала вывод

Когда разрабатываешь приложения для Windows, поводов для беспокойства много.

Запустится ли это на данном ПК? Будет ли работать в окружении без прав администратора? Не сломается ли из-за разницы между 32-bit и 64-bit? Пути с японскими символами, длинные пути, сетевые диски, старые DLL, COM-компоненты, ActiveX, принтеры, последовательная связь, антивирусы, Windows Update.

Стоит только начать об этом думать — и беспокойству не будет конца.

Но в какой-то момент я стал смотреть на это иначе.

Возможно, это не недостаток, а свидетельство того, что Windows тащила на себе реальную работу.

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

Именно этот хаос и делает Windows интересной — и именно поэтому, как разработчику, с ней стоит иметь дело.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 14, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Разработка Windows-приложений даёт много поводов для беспокойства

В разработке Windows-приложений недостаточно того, чтобы «код был правильным».

Он работает в локальном окружении. Он работает на компьютере разработчика. Он работает даже на тестовой виртуальной машине.

И всё же нет никакой гарантии, что он заработает на компьютере заказчика.

Например, случается следующее:

• Не удаётся найти DLL
• Не установлена среда выполнения Visual C++
• Не совпадает версия .NET Framework
• Не удаётся загрузить 32-bit DLL из 64-bit процесса
• Повреждена регистрация COM
• Путают 32-bit и 64-bit версии regsvr32.exe
• Код, рассчитанный на текущий каталог, ломается под управлением Планировщика заданий
• Попытка записи в Program Files вызывает ошибку прав доступа
• AppData\Roaming и AppData\Local используют не по назначению
• Приложение падает при японских именах пользователей или японских именах папок
• Не удаётся открыть файл из-за слишком длинного пути
• Работает на подключённом сетевом диске, но не работает через UNC-путь
• Интерфейс ломается в средах с высоким DPI
• На нескольких мониторах смещаются расчёты координат
• Результат печати меняется в зависимости от драйвера принтера
• USB-устройства, камеры, измерительные приборы и последовательная связь не распознаются в зависимости от окружения
• Антивирус блокирует часть обработки
• После Windows Update поведение меняется

Если перечислить всё это подряд, немного кружится голова.

Проблемы, которые в веб-приложении остаются заперты между браузером и сервером, в Windows-приложении расползаются по всему компьютеру. Файловая система, реестр, профили пользователей, принтеры, устройства, сеть, политики безопасности, установщики, среды выполнения.

Приложение не просто «работает поверх ОС» — его ставят внутрь рабочей среды.

Именно поэтому разработка Windows-приложений сложна. Но списывать всё это на «Windows просто плохая» — значит, на мой взгляд, упускать суть.

На всё это опирается сложность реального мира.

3. Windows — ОС для реальной работы

Windows — не операционная система только ради новейших технологий.

Заводы, больницы, госучреждения, школы, лаборатории, вещание, поверочное оборудование, терминалы на ресепшене, терминалы печати документов, склады, магазины, бухгалтерия, расчёт зарплаты, управление запасами. В таких местах и сегодня работает множество компьютеров с Windows.

И там есть не только новейшие веб-сервисы.

Есть макросы Excel. Есть Access. Есть старые приложения на VB. Есть бизнес-приложения на .NET Framework. Есть постоянно работающие приложения, написанные на C++. Есть COM-компоненты. Есть ActiveX. Есть подключения ODBC. Есть драйверы принтеров. Есть сканеры штрихкодов. Есть измерительные приборы с последовательной связью. Есть SDK от производителей оборудования.

Более того, ничто из этого не существует само по себе.

Люди работают с этим, печатают документы, меняют USB-устройства, кладут CSV-файлы в общие папки; ночью выполняются пакетные задания, а на следующее утро работа начинается заново. Всё это живёт внутри одного непрерывного процесса.

Windows — не просто основа, чтобы запускать приложения. Это платформа, которая принимает повседневную работу на местах, существующие активы, периферию и даже человеческие привычки.

Поэтому она иногда выглядит устаревшей. Иногда — сложной. Иногда возникает вопрос, зачем то или иное вообще до сих пор существует.

Но это также значит, что старое здесь не выбрасывали небрежно.

4. Обратная совместимость как форма любви

Если бы целью было лишь сделать ОС красивой, было бы проще отрезать старые механизмы.

Удалить старые API. Удалить старые среды выполнения. Удалить старые экраны настроек. Считать, что старые приложения попросту больше не работают.

Сделав так, можно было бы, пожалуй, упростить архитектуру. Возможно, документация стала бы короче. Возможно, разработчикам стало бы чуть легче.

Но за этим стоят бизнес-приложения, которые перестанут работать. Оборудование, которое остановится. Предприятия, которые окажутся в затруднении.

Обратная совместимость Windows технически действительно доставляет хлопоты. Есть WOW64 (Windows 32-bit On Windows 64-bit) — чтобы 32-bit приложения работали на 64-bit Windows. Реестр и DLL могут выглядеть по-разному для 32-bit и 64-bit кода. Есть структура, которая на первый взгляд сбивает с толку: C:\Windows\System32 — это 64-bit сторона, а C:\Windows\SysWOW64 — 32-bit.

COM (Component Object Model — механизм Windows, через который приложения обмениваются компонентами) тоже доставляет хлопоты. Просто положить DLL недостаточно — иногда нужна регистрация. Регистрация выполняется на уровне пользователя или на уровне машины? Это 32-bit COM или 64-bit COM? Нужны ли права администратора?

С .NET Framework то же самое. Сегодня есть возможность использовать новый .NET, например .NET 8 или .NET 9. Но на местах до сих пор работают приложения на .NET Framework 4.x. Это не просто «устарело» — это значит, что данная версия много лет поддерживала реальную работу.

Обратная совместимость — не просто красивое понятие. Скорее, это тяжёлая ответственность.

Продолжать двигать старое — значит нести технический долг. Но в то же время это и честность: не останавливать работу тех, кто системой пользуется.

Я думаю, именно в этом и есть то, за что Windows можно любить.

5. Windows — ОС, устроенная как геологические слои

В Windows технологии каждой эпохи наслаивались друг на друга, как геологические пласты.

Win32. COM. ActiveX. Windows Forms. WPF. .NET Framework. UWP. WinUI. Windows App SDK. MSIX. PowerShell. Windows Terminal. WSL.

У каждой была своя эпоха появления, свои сильные стороны и места, где её использовали.

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

Например, даже разрабатывая приложение на WPF, при печати можно столкнуться с проблемами GDI (Graphics Device Interface — давно существующий в Windows механизм отрисовки и печати) и драйверов принтеров. Даже написав код на C#, если SDK поставщика — нативная DLL, приходится иметь дело с P/Invoke (Platform Invoke — вызов функций нативной DLL из C#) и с разрядностью. Даже создавая новые экраны, порой приходится сохранять существующие COM-компоненты или интеграцию с Excel.

Windows — это не идеально выстроенный сад. Она скорее похожа на огромный город, который снова и снова достраивали и перестраивали.

В нём есть широкие проспекты. Есть подземные переходы. Есть старые переулки. Есть новые небоскрёбы.

В нём легко заблудиться. Но в глубине этих переулков и сегодня выполняется важная работа.

Эту «летопись пристроек» — уже не как эссе, а как конкретную хронологию — я разбираю в статье Почему Windows стала такой: эволюция глазами разработчика. Там от Windows 95 до Windows 11 собраны изменения глазами разработчика. Если нужно понять, какой слой когда лёг, читайте её.

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

6. Превратить хлопоты в проектирование

В заголовке сказано «перестать беспокоиться».

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

Перестать беспокоиться — значит превратить беспокойство в проектирование.

Например, если тревожит вопрос запуска, проверку запуска делают дымовым тестом (smoke test).

Start-Process .\MyApp.exe

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

Если тревожат DLL, проверяют зависимости. Если нужна среда выполнения Visual C++, решают, включать ли её в установщик или явно указать как обязательное условие. Если используются нативные DLL, не оставляют неопределённым соотношение x86 / x64 / AnyCPU.

Если тревожит COM, оформляют порядок регистрации в виде инструкции и воспроизводят его с нуля на тестовом компьютере.

# Пример регистрации 64-bit COM DLL
C:\Windows\System32\regsvr32.exe .\SomeComponent64.dll

# Пример регистрации 32-bit COM DLL
C:\Windows\SysWOW64\regsvr32.exe .\SomeComponent32.dll

Если тревожат права доступа, избегают решений, которые работают только с правами администратора. Пользовательские настройки кладут в AppData, общесистемные — в ProgramData. Избегают решений, которые пишут логи в Program Files.

Если тревожат пути, в тесты включают японские символы, пробелы, длинные имена папок и UNC-пути.

New-Item -ItemType Directory -Path "C:\テスト 用\とても長いフォルダー名\さらに深いフォルダー" -Force

Если тревожит DPI, проверяют при 100%, 125%, 150% и 200%. На нескольких мониторах смотрят, не ломается ли всё при переходе между экранами с разным масштабом. У WinForms, WPF и WinUI подход к поддержке DPI разный, поэтому проверку проводят отдельно для каждой технологии интерфейса.

Если тревожат память и handle, используют Application Verifier, WinDbg, ProcDump, Process Explorer и подобные инструменты. Если тревожат сбои, сохраняют журнал событий, дампы и логи приложения.

Get-EventLog -LogName Application -Newest 20

Либо, в более новых окружениях, журнал событий проверяют так:

Get-WinEvent -LogName Application -MaxEvents 20

Если тревожат дефекты, которые не воспроизводятся на месте, повышают детализацию логирования. «Произошла ошибка» — этого недостаточно. Какой файл пытались открыть? Какое устройство искали? От имени какого пользователя выполнялось действие? В какой путь пытались записать? Какую DLL не удалось загрузить?

Превратить беспокойство в то, что можно наблюдать.

В разработке Windows-приложений это чрезвычайно важно.

Если собрать сказанное на одном листе, получится так.

Левый столбец этой таблицы — тот же список тревог. Когда рядом есть два правых столбца, тревога превращается в работу.

7. «Работает на компьютере заказчика» — конечная цель

То, что всё работает в среде разработки, важно. То, что тесты проходят в CI, важно. То, что всё работает на чистой виртуальной машине, важно.

Но для Windows-приложения последним препятствием всегда остаётся вопрос: «а работает ли это на компьютере заказчика?»

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

Поэтому важен и способ распространения.

Достаточно ли просто передать exe? Нужен ли MSI? ClickOnce? MSIX? Можно ли распространять через winget? Пойдёт ли это через внутреннюю систему распространения? Нужен ли автономный установщик? Требуется ли подпись кода? Не заблокирует ли приложение SmartScreen или антивирус?

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

В разработке Windows-приложений программное обеспечение не заканчивается на поставке. Оно должно запускаться в среде заказчика — и сегодня, и завтра.

8. Почему я всё же люблю Windows

У Windows есть неудобные стороны. Это факт.

DLL. COM. Реестр. UAC. DPI. Принтеры. Среды выполнения. 32-bit / 64-bit. Сетевые диски. Длинные пути. Японоязычные среды. Защитное ПО. Windows Update.

Если перечислять неудобства, им нет конца.

Для ясности: UAC — это User Account Control (контроль учётных записей пользователей), DPI — Dots Per Inch (настройка масштаба экрана). И то и другое — другой способ сказать, что «приложение не замыкается само на себе».

Но большая часть этих хлопот происходит от того, что Windows очень долго тащила на себе реальную работу.

Она не выбрасывает старые активы, но при этом впитывает новые технологии; у неё есть и графический интерфейс, и командная строка; она принимает и локальные приложения, и веб, и периферию, и рабочие терминалы, и личные компьютеры, и корпоративные.

Это не единая красивая философия.

Но это сила.

И для разработчика это стоит того, чтобы с этим работать.

Создавать программное обеспечение, которое надёжно работает на Windows, — это не просто вызывать API. Это значит читать ограничения реальной среды, понимать существующие активы, находить уязвимые места, тестировать, наблюдать и исправлять то, что нужно исправить.

Это неброская работа. Но она имеет ценность.

9. Итог

В разработке Windows-приложений поводам для беспокойства нет конца.

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

Поэтому я не считаю Windows просто устаревшей операционной системой.

Это огромная, сложная, немного неуклюжая платформа, которая продолжает работать, находя компромисс с реальностью.

И создавать программное обеспечение, надёжно работающее на ней, до сих пор представляет большую ценность.

Перестать беспокоиться.

Но это не значит терять бдительность.

Превратить беспокойство в проектирование, тесты и наблюдение.

Так, шаг за шагом, я и полюбил Windows.

Ссылки по теме

• Application Verifier - Overview - Microsoft Learn
• High DPI Desktop Application Development on Windows - Microsoft Learn
• Setting the default DPI awareness for a process - Microsoft Learn
• Running 32-bit Applications - Microsoft Learn
• Maximum Path Length Limitation - Microsoft Learn
• MSIX documentation - Microsoft Learn
• Version compatibility in .NET Framework - Microsoft Learn

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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