Запуск устаревших 16-разрядных приложений в среде службы терминалов

В сегодняшней статье я хочу воспользоваться возможностью, чтобы рассказать о запуске 16-разрядных приложений DOS в среде службы терминалов Windows Server 2003. Может показаться странным говорить о приложениях, написанных для операционной системы, которая устарела как минимум десять лет назад, но, хотите верьте, хотите нет, существует невероятное количество компаний, которые все еще полагаются на устаревшие приложения DOS для выполнения критически важных задач. Поскольку дело обстоит именно так, а приложениям DOS не нравится хорошо работать в среде терминального сервера, я хотел поговорить о некоторых проблемах, с которыми вы можете столкнуться.

Прежде чем я начну

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

Почему DOS-приложения такие привередливые?

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

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

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

Разница в том, как приложения DOS и Windows используют драйверы устройств, объясняет одну из самых больших проблем при запуске устаревшего приложения DOS в среде тонкого клиента. Подумайте о том, как работают терминальные службы. Приложение фактически запускается в рамках виртуального сеанса на сервере, а затем изображение экрана передается клиенту. Итак, если приложение имеет встроенный набор драйверов, какие драйверы вы выбираете; драйвера подходящие к серверу? Драйвера, которые подходят некоторым клиентам? Каковы шансы, что у древнего приложения будут драйверы, которые будут работать с современным оборудованием?

Вообще говоря, если приложение работает в текстовом режиме, вы, как правило, будете в порядке (с точки зрения драйвера), запуская его в среде тонкого клиента. Приложения в текстовом режиме не требуют видеодрайверов. Если пользователям придется печатать из приложения, вам могут понадобиться драйверы принтера, но многие современные лазерные принтеры обратно совместимы с драйверами многолетней давности.

Если приложение DOS использует графический интерфейс, вы все равно сможете заставить приложение работать. Попробуйте посмотреть, включает ли приложение графический драйвер CGA или EGA. Многие драйверы CGA и EGA, использовавшиеся с приложениями DOS, являются универсальными. Интерфейс может выглядеть не так красиво, как если бы он использовал драйвер с более высоким разрешением, но на данный момент наша цель — просто заставить приложение работать. Косметика на самом деле не является соображением изначально.

Ресурсоемкие приложения

Другая распространенная проблема с запуском старых приложений DOS в среде Windows заключается в том, что, когда DOS была доминирующей операционной системой, большинство приложений не были рассчитаны на многозадачность. Конечно, время от времени существовала программа TSR (программа «Выйти и остаться резидентом»), но это было скорее исключением, чем правилом. Дело в том, что когда программист разрабатывал приложение для DOS, он мог с уверенностью предположить, что приложение не будет использовать системные ресурсы ни с чем, кроме самой DOS и нескольких компонентов DOS, таких как HIMEM.SYS, EMM386.EXE и т. д. Таким образом,, программист имел полную свободу делать все, что хотел. Я сам был разработчиком во времена DOS и знаю из первых рук, что программисты использовали всевозможные маленькие нетрадиционные приемы, чтобы выжать из системы дополнительные ресурсы.

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

Даже если приложение не требует много памяти, некоторые довольно невинные методы программирования могут быть проблематичными в среде службы терминалов. Например, все мы видели программы, которые останавливаются и ждут нажатия клавиши. Во времена DOS команды ввода обычно требовали от пользователя нажатия клавиши ввода, чтобы возобновить работу программы. Часто программисты хотели, чтобы пользователь мог нажать любую клавишу для продолжения, а не нажимать Enter. Для этого программисты использовали функцию INKEY$. Функция INKEY$ представляла собой бесконечный цикл, который опрашивал клавиатуру во время каждого цикла, чтобы определить, была ли нажата клавиша. Как только происходит нажатие клавиши, цикл прерывается, и программа переходит к следующей строке кода.

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

Хорошая новость заключается в том, что есть способ обойти эту проблему. Хотя лично я никогда ею не пользовался, на веб-сайте www.tamedos.com предлагается утилита под названием Tame, предназначенная для того, чтобы процедуры опроса клавиатуры, такие как INKEY$, не доминировали над процессором системы. Windows NT 4.0 Terminal Server Edition включала утилиту под названием DOSKBD, которая в основном делала то же самое, но Microsoft не включала эту утилиту в более новые версии Windows, а версия Windows NT не работает с более новыми операционными системами Windows.

Вывод

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