VB6 все еще работает в 2026 году, но риск скрыт в сборке

Если приложение на VB6 запускается в Windows 11, это доказывает только один узкий факт: текущий исполняемый файл находит достаточно компонентов среды выполнения для старта. Это не доказывает, что приложение можно заново собрать, исправить, установить на чистый компьютер или восстановить после отказа диска. Это разные возможности, а большинство давно работающих систем на VB6 проверили лишь первую.

Опасная дата наступит не тогда, когда Windows откажется запускать EXE. Она наступит, когда перестанет загружаться последний компьютер с нужным компилятором, пакетом обновлений, файлами OCX, библиотеками типов, состоянием реестра, версией исходного кода, проектом установщика, драйвером базы данных и знаниями оператора. Тогда изменение одного правила может превратиться в проект по восстановлению. Работающее приложение нужно считать доказательством, которое пора сохранить, а не доказательством отсутствия проблемы.

Поддержка среды выполнения не означает поддержку разработки на VB6

Microsoft по-прежнему поддерживает основные компоненты среды выполнения VB6 в поддерживаемых версиях Windows, но не поддерживает IDE VB6. Это различие объясняет, почему старые приложения продолжают работать, хотя обслуживать их с каждым годом сложнее. В документе Microsoft о поддержке Visual Basic 6.0 целью совместимости для существующих приложений назван принцип It Just Works. В том же документе сказано, что разработка в IDE не поддерживается с 2008 года, а приложения на VB6 рекомендуется заменить современными технологиями.

Объем поддержки уже, чем предполагают многие руководители. Microsoft исправляет в среде выполнения серьезные регрессии и критические проблемы безопасности, которые затрагивают существующие приложения. Компания не обещает, что старый установщик, сторонний элемент управления, заброшенный поставщик доступа к данным или компилятор заработает на каждом будущем компьютере. Microsoft отдельно рассматривает основные файлы среды выполнения в составе Windows, поддерживаемые дополнительные файлы для распространения вместе с приложением, неподдерживаемые файлы и сторонние компоненты, за которые отвечают их поставщики.

Поэтому успешная проверка совместимости с Windows не закрывает инженерный вопрос. Она показывает, что этот двоичный файл с этим набором зависимостей работал во время теста. Она ничего не говорит о том, способен ли исходный код снова породить тот же файл. Скомпилированное приложение может годами работать стабильно, а возможность его изменить тем временем незаметно исчезает.

При аудите я использую четыре отдельных статуса: запускается, устанавливается, собирается и понятно команде. Первый означает, что уже установленная копия стартует. Второй означает, что приложение можно поставить из контролируемого комплекта на чистый поддерживаемый образ Windows. Третий означает, что контролируемый исходный код дает отслеживаемый двоичный файл. Четвертый означает, что команда знает внешние системы, форматы файлов и бизнес-правила, от которых зависит приложение. Если назвать все четыре состояния словом поддерживается, аудит скроет именно тот риск, который должен обнаружить.

EXE зависит не только от MSVBVM60.dll

Обычный исполняемый файл VB6 зависит от 32-разрядной среды выполнения, регистрации COM, элементов ActiveX, поставщиков доступа к данным, конфигурации вне репозитория и особенностей компьютера. Фактический набор часто шире списка из файла проекта: код VB6 создает объекты по ProgID, загружает расширения по соглашению, запускает вспомогательные программы и читает пути из реестра или INI-файлов.

Начните с границы скомпилированного приложения. VB6 обычно создает 32-разрядный машинный код или p-code, а файлы среды выполнения остаются 32-разрядными. В 64-разрядной Windows процесс работает через WOW64. Любой загружаемый внутрь процесса DLL или OCX должен иметь совместимую 32-разрядную сборку. Зарегистрированная под похожим именем 64-разрядная замена не подходит 32-разрядному клиенту COM. Разрядность входит в контракт интерфейса, даже если исходный код о ней не говорит.

Затем учтите идентичность COM. Проекты VB6 ссылаются на библиотеки типов и компоненты по GUID, версии и идентичности класса. Реестр связывает эти идентификаторы с физическим сервером. Копирование OCX рядом с EXE не обязательно регистрирует компонент, а регистрация неправильной версии способна исправить одно приложение и сломать другое. Настройки двоичной совместимости проекта также определяют, сохранит ли пересобранный DLL идентификаторы классов и интерфейсов для клиентов. Неосторожная сборка может завершиться без ошибок, но лишить доступа все клиентские программы.

Доступ к данным добавляет еще один слой. Приложения могут применять ADO, DAO, RDO, DSN ODBC, базы Jet, фирменные клиенты баз данных или имена поставщиков, составленные во время выполнения. Строка подключения в исходном коде составляет лишь часть зависимости. Системные DSN, псевдонимы, клиентские библиотеки, сертификаты и учетные записи служб могут полностью находиться вне системы управления версиями. Региональные настройки иногда меняют разбор десятичных чисел, литералов дат и порядок сортировки. Драйверы принтеров могут менять разбиение отчетов на страницы. Старые настольные программы часто превращают состояние рабочего места в состояние приложения.

Наконец, проверьте файлы, которые кажутся неважными: .vbp, .vbw, .res, .frx, .ctl, .ctx, .dsr, .pag, сценарии установщика и двоичные файлы совместимости. Форма без соответствующего .frx может потерять встроенные изображения или данные элементов управления. Проект со ссылкой на DLL двоичной совместимости на диске разработчика способен создать новые идентификаторы COM после исчезновения файла. Одного исходного кода недостаточно для архива сборки.

Windows 11 сохраняет остров 32-разрядной совместимости

Приложения VB6 работают в современной 64-разрядной Windows, потому что Microsoft поставляет и тестирует основные компоненты среды выполнения, а Windows предоставляет WOW64 для 32-разрядных процессов. Это целенаправленная работа над совместимостью, а не возвращение VB6 в число современных платформ разработки. У среды выполнения, IDE и каждого внешнего компонента разные владельцы и статусы поддержки.

WOW64 также объясняет несколько запутанных путей. Обращение 32-разрядного процесса к системному каталогу могут перенаправить, а 32-разрядная регистрация COM видна через отдельное представление реестра. Администратор, который применяет 64-разрядный regsvr32 к 32-разрядному OCX, получает ошибку или регистрирует компонент не в том контексте. В 64-разрядной системе 32-разрядный инструмент регистрации обычно лежит в SysWOW64, несмотря на название. Эта историческая путаница испортила немало окон обслуживания.

Не копируйте случайные DLL в системные каталоги, пока программа не запустится. Так вы меняете глобальное состояние компьютера, но не фиксируете владельца файла, выбранную версию и способ повторить результат. Упакуйте именно те распространяемые зависимости, на распространение которых у вас есть право, установите их предсказуемо и проверьте на чистом образе. Если приложению нужен неподдерживаемый сторонний элемент управления, запишите его как ограничение миграции. Поддержка основной среды выполнения на него не распространяется.

Установка на сервер требует еще одной проверки. Документ Microsoft ограничивает указанную поддержку Windows Server 64-разрядными выпусками и исключает Server Core для VB6. Если настольный EXE работает через WOW64 в полной установке сервера, это не означает, что ему место в образе Server Core без графической оболочки. Поддерживаемую границу хоста нужно записать в документации по развертыванию приложения.

Составьте реестр зависимостей по фактическим данным

Полезный реестр зависимостей объединяет статические ссылки, состояние компьютера и наблюдаемое поведение. Ни одного из этих источников недостаточно. Файлы проекта показывают объявленные ссылки, реестр показывает их разрешение на машине сборки, а наблюдение во время работы находит поздно связанные объекты и внешние процессы. Сохраните все три источника, пока проверенный компьютер еще работает.

Выполните на машине сборки следующие команды PowerShell и сохраните результаты вместе со снимком исходного кода:

Get-ChildItem -Recurse -Include *.vbp,*.mak |
  Select-String -Pattern '^(Reference|Object)=' |
  ForEach-Object { '{0}:{1}:{2}' -f $_.Path,$_.LineNumber,$_.Line } |
  Set-Content declared-com-references.txt

Get-ChildItem -Recurse -Include *.vbp |
  ForEach-Object { Get-FileHash $_.FullName -Algorithm SHA256 } |
  Export-Csv project-hashes.csv -NoTypeInformation

Get-CimInstance Win32_Product |
  Select-Object Name,Version,Vendor |
  Export-Csv installed-products.csv -NoTypeInformation

Первый файл содержит каждую объявленную строку Reference= или Object= с исходным файлом и номером строки. Второй дает хеш каждого файла проекта. Список установленных продуктов неполон, поскольку не все зависимости используют Windows Installer, но он создает точку для сравнения. Не запускайте Win32_Product многократно на рабочих компьютерах: команда может начать проверку целостности установленных пакетов. Здесь нужен однократный сбор данных на изолированной машине сборки.

Добавьте метаданные каждого реально используемого DLL и OCX: исходный путь, хеш SHA-256, версию файла и продукта, подписанта, архитектуру, источник лицензии и право распространения. Экспортируйте нужные разделы 32-разрядной регистрации COM только после разрешения каждого GUID из проекта. Запишите версии клиентов баз данных, драйверы ODBC и DSN, переменные среды, шрифты, региональные параметры, драйверы принтеров, запланированные задачи, сетевые ресурсы и учетные записи служб. Секреты должны храниться в специальном хранилище, а не в реестре зависимостей. В реестре укажите имя секрета и владельца, но не копируйте значение.

Затем проследите за показательным сеансом с помощью монитора файлов и реестра. Проверьте запуск, вход, обычную транзакцию, импорт, экспорт, отчеты, печать, обработку ошибки и завершение. Сравните наблюдаемые обращения к файлам, реестру, сети и процессам с объявленным перечнем. Любой поздно связанный ProgID, вспомогательный EXE, сетевой диск или доступный для записи каталог установки, который появляется только во время работы, внесите в реестр.

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

После смерти последней машины сборки исходного кода недостаточно

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

Первый симптом обычно возникает при срочном изменении. Меняется налоговое правило, адрес сервиса, сертификат, политика паролей базы данных или формат файла. Инженер ставит IDE в виртуальную машину, открывает проект, закрывает несколько окон об отсутствующих ссылках, заменяет недоступный элемент управления и успешно компилирует проект. Новый EXE запускается, поэтому его отправляют в эксплуатацию. Позже редко используемая форма падает из-за другой сериализации свойств в замененном компоненте, либо клиент COM не может создать пересобранный класс с новой идентичностью интерфейса. Успешную компиляцию приняли за совпадение поведения.

Лицензированные элементы ActiveX еще сильнее затрудняют восстановление. Некоторым нужны записи лицензии времени разработки для загрузки в IDE, хотя готовое приложение работает с лицензией среды выполнения. Поставщик мог закрыться, активация могла исчезнуть, а копирование установленного OCX может нарушить лицензию или пропустить данные реестра. Инженерный прием не заменит юридических прав. Установите владельца и условия распространения, пока сохранились закупочные документы и память сотрудников.

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

Декомпиляция подходит для аварийного восстановления, а не для замены управления версиями. Двоичные файлы с машинным кодом теряют имена и структуру, p-code дает другие возможности, но ни один вариант не восстанавливает надежно комментарии, сценарии сборки, исходные формы и замысел разработчика. Иногда удается вернуть достаточно поведения для исследования дефекта. Не стройте план модернизации на надежде превратить двоичный файл обратно в исходный проект.

Сохраните сборку до изменения приложения

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

Соберите следующие материалы в один контролируемый комплект:

1. Полную версию репозитория, включая ресурсы форм, исходники установщика и ссылки двоичной совместимости.
2. Установочные носители, пакеты обновлений, распространяемые элементы управления, подтверждения лицензий и контрольные суммы.
3. Инвентаризацию компьютера и ограниченно доступный образ проверенной рабочей станции.
4. Точные команды, порядок проектов, символы условной компиляции и действия упаковки.
5. Хеши рабочих двоичных файлов и подписанную запись о том, какая сборка где установлена.

Теперь выполните чистую выгрузку и сборку в изолированной виртуальной машине. Не включайте сеть, если она не нужна для задокументированного входного компонента. Сравните выходные файлы, экспортированные интерфейсы COM и содержимое установщика. Полное совпадение байтов может быть невозможно из-за временных меток и метаданных компилятора, поэтому заранее определите критерий равенства. Как минимум проверьте версии файлов, зависимости, идентичность классов и поведение в приемочных тестах.

Ведите небольшую запись для каждой попытки. Подойдет JSON, CSV или подписанный текст, но в нем должны быть версия исходного кода, идентификатор образа среды, хеши инструментов и зависимостей, команды, оператор, время, хеши результатов и итог тестов. Цель заключается в отслеживаемости. Через шесть месяцев другой инженер должен точно определить источник EXE, не спрашивая создавшего его человека.

Не подключайте спасенную виртуальную машину к обычной корпоративной сети под видом непрерывности работы. Неподдерживаемая IDE и старые сторонние установщики увеличивают поверхность атаки, а старые клиенты баз данных могут требовать протоколы, которые давно пора отключить. Изолируйте сборку, передавайте входные и выходные файлы через контролируемый канал, проверяйте артефакты, удалите постоянные учетные данные и журналируйте доступ. Это даст время, но не сделает неподдерживаемый набор инструментов безопасным.

Возраст сам по себе не определяет срок миграции

Приоритет приложения на VB6 зависит от возможности восстановления, давления изменений и последствий отказа, а не от года создания. Две программы, скомпилированные в один год, могут требовать противоположных решений. Справочник только для чтения на изолированном компьютере иногда можно оставить в защищенном контуре. Клиент для ввода заказов с еженедельными изменениями правил и прямой записью в рабочую базу может потребовать замены до следующей функции.

Сначала оцените восстановление. Может ли команда установить выпущенный пакет на чистый поддерживаемый образ Windows? Может ли она собрать установленную версию из чистой выгрузки? Учтены ли все элементы управления, лицензии и поставщики доступа к данным? Умеет ли выпускать версию больше одного человека? Ответ нет на вопрос о чистой сборке повышает срочность даже при отсутствии дефектов, потому что срок следующего изменения неизвестен.

Затем измерьте давление изменений. Считайте реальные запросы, для которых требуется менять код, а не общее недовольство. Обновления сертификатов, API, налоговых правил, требований аутентификации, базы данных и форматов файлов расходуют ресурс одной и той же слабеющей цепочки инструментов. Очередь функций имеет значение, но обязательное внешнее изменение с заданной датой важнее. Приложение может быть функционально закончено, а окружающие системы все равно заставят его менять.

Последствия нужно выразить через конкретные отказы. Что произойдет, если приложение сутки не запускается, неверно считает, теряет транзакцию или не устанавливается после замены компьютера? Назовите ручной резервный процесс и проверьте его на текущем объеме. План восстановления, который зависит от ушедшего сотрудника или нераспечатанной коробки с дисками, нельзя честно оценить.

Воздействие угроз безопасности тоже меняет ответ. Локальный инструмент для чтения контролируемых файлов несет иной риск, чем клиент, который принимает документы из интернета, подключается к базе с широкими правами или требует устаревшие сетевые протоколы. Не объявляйте любое ПО на VB6 небезопасным только из-за языка. Проследите входные данные, привилегии, зависимости и сетевые пути. Неподдерживаемая IDE должна находиться в изолированной среде сборки независимо от места работы приложения.

Я записываю решение вместе с владельцем, датой доказательств и условием пересмотра, а не ставлю неопределенный красный статус. Изоляция может оставаться приемлемой до конца поддержки основной ОС, невозможности продлить лицензию, отказа чистой сборки или объявления несовместимого изменения конкретной интеграцией. Проверяйте эти условия. Так можно избежать и панической переписи, и более частой ошибки, когда временное исключение продлевают бесконечно без ответственного за риск.

Сравнение затрат должно учитывать не только часы разработчиков. Добавьте хранение старых образов, закрытые сетевые зоны, редкие знания о компонентах, ручное развертывание, восстановление после происшествий и задержку бизнес-изменений. В стоимость замены включите сверку данных, параллельную работу, обучение, переключение и вывод из эксплуатации. Честная оценка все равно может оправдать изоляцию. Нельзя убирать труд по поддержке старой системы лишь потому, что он проходит по эксплуатационному, а не проектному бюджету.

У реальных путей выхода разные риски

Есть пять обоснованных путей. Выбор зависит от частоты изменений, эксплуатационного воздействия и объема наблюдаемого поведения. Оставить как есть можно считать решением, только если срок жизни EXE ограничен, сборку можно восстановить, хост контролируется, а бизнес принимает план на случай отказа. Работа по инерции решением не считается.

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

API перед системой на VB6 может уменьшить прямой доступ к базе и дать новым клиентам стабильную границу. Подход работает, если старая программа уже предоставляет вызываемые бизнес-операции или управляется через контролируемый адаптер. Он плохо работает, когда автоматизация зависит от времени отклика интерфейса, модальных окон, общих файлов или глобального состояния компьютера. Автоматизация интерфейса годится как временный мост с указанной датой удаления, а не как архитектура интеграции.

Постепенная замена переносит по одной ограниченной функции. Она снижает риск развертывания, когда границы модулей реальны и команда может одновременно запускать старый и новый пути. Если границы существуют только на схеме, годы уйдут на двойную запись, COM-interop, дублирование правил и сверку. Выбирайте этапы вокруг наблюдаемых бизнес-транзакций, а не вокруг каталогов с исходниками.

Полная переработка оправдана при сильной связанности системы, разрушающейся сборке, изменении эксплуатационной модели целевой архитектурой или слишком высокой цене одновременной поддержки двух систем. Обычно возражают, что новая реализация потеряет скрытые бизнес-правила. Это правда, если команда считает исходный код спецификацией и тестирует только обычные случаи. Переработку можно обосновать, когда записанное поведение, данные и пограничные случаи образуют исполняемый эталон для сравнения.

Я не советую автоматический построчный перенос. Он популярен, потому что кажется ограниченным по масштабу и дает измеримый процент готовности. Обычно он переносит глобальное состояние, зависимость от настольного интерфейса и случайное поведение базы в новый язык, а затем добавляет слой COM-interop там, где перенос не удался. Получается старая архитектура, которую сложнее исследовать из-за изменения привычной семантики выполнения. Сохраняйте поведение, а не прежнюю структуру файлов и форм.

Записанное поведение становится контрактом миграции

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

Компактный тест на совпадение может выглядеть так:

{
  "case": "invoice-credit-partial",
  "input": {"invoice_id": 4812, "amount": "37.50"},
  "expected": {
    "status": "partially_credited",
    "ledger_delta": "-37.50",
    "document_type": "credit_note"
  }
}

Название случая менее важно, чем происхождение. Запишите, из какого рабочего сценария он получен, удалите персональные данные, версионируйте набор и обеспечьте повторяемость сравнения. Возьмите обычные и неудобные случаи: пустые строки и null, региональные десятичные знаки, високосные даты, дублированные отправки, тайм-ауты, частичные отказы и повторные попытки. Приложения VB6 часто выражают обработку ошибок через порядок событий и общее состояние, поэтому проверяйте последовательности, а не только отдельные операции.

Одни эталонные тесты могут сохранить ошибки. Классифицируйте расхождения как намеренное исправление, безвредное различие представления, пропущенное поведение или дефект теста. Владелец продукта должен утвердить намеренные изменения: инженер не может по коду определить, случайно ли появилось странное бухгалтерское правило. Храните исходный результат рядом с утвержденным новым ожиданием, чтобы решение можно было проверить.

Рабочий трафик дает лучшее покрытие, чем придуманные модульные тесты, если его можно записать законно и безопасно. CodeHero применяет систему проверки совпадения на записанном рабочем трафике и обновляет архитектуру вместо буквального переноса исходного кода. Принцип не зависит от поставщика: сохраните реальные запросы пользователей, очистите их, воспроизведите и сравните устойчивые эффекты.

Выбирайте целевую систему по ее границам

Целевая система должна следовать границам развертывания, отказов и владения, а не моде на языки. Настольное приложение, которое в основном проверяет ввод и обращается к центральной базе, может стать клиентом TypeScript с сервисами и Postgres. Для модуля с большим объемом вычислений может подойти небольшой числовой модуль на Rust. Транзакционный сервис с понятной конкурентностью и эксплуатацией можно написать на Go. Это проектные выводы, а не автоматическая замена синтаксиса VB6.

Сначала нарисуйте текущую границу выполнения. Отметьте работу на компьютере пользователя, работу рядом с базой, интеграции со строгим порядком вызовов и результаты, которые должны сохранить побайтовую совместимость для следующих систем. Решите, где находятся идентификация, авторизация, повторы и журнал аудита. Если два новых компонента должны разделять транзакцию базы данных и развертываться вместе, название «отдельные сервисы» добавит сетевой отказ, но не независимость.

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

Если системе нужно быстро уйти с VB6, CodeHero читает все дерево исходного кода, переписывает его на Go, Rust и TypeScript с Postgres там, где это уместно, и выполняет каждый проект менее чем за 30 дней. Независимо от выбора этого пути или своей команды требуйте одинаковые доказательства: воспроизводимую исходную базу, явные архитектурные решения и результаты сравнения с записанным поведением.

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