как заставить приложение использовать 32 битные библиотеки
Используем 32битные библиотеки в 64битных программах
Можно ли использовать 32битные библиотеки в 64битных программах? Скорее нет. А если очень нужно? Тогда скорее да!
Для одного проекта мне нужно работать с 32битными проприетарными библиотеками. Под виндой нет проблем — компилируем все в 32 бита и вперед. Но под линуксом дела обстоят хуже. Собирать все в 32 бита и цеплять в RPM 32битные версии свободных библиотек некрасиво, более того у меня есть API для плагинов. Совсем не хочется заставлять юзеров ставить ради несчастного плагина 32битный компилятор. Поэтому я решил сделать переходник из кота в мышь, который будет вызывать функции из 32битных библиотеке в отдельном процессе. Сначала я хотел сделать его на питоне, но скомпилировать питон в бинарник у меня не получилось. Потом добрые люди на IRC канале PyPy подсказали мне, что можно использовать libffi прямо из C! Дальше дело за малым.
В итоге получилась программа runso32. Она работает в двух режимах. В первом режиме в аргументах командной строки задается библиотека, функция, строка описания параметров и собственно сами параметры. На данный момент поддерживаются параметры типа int, unsigned int, double, указатель и последовательность байтов (буфер). Программа вызывает функцию, печатает возвратное значение и завершается. Второй вариант — интерактивный. Программа читает команды из стандартного ввода или файла. Сначала регистрируются все интересные нам функции. Потом каждая запись, начинающаяся с «CALL», вызывает функцию с заданным номером. в интерактивном режиме перед тем как отправить буфер необходимо указать его длину. В интерактивном режиме все все величины отсылаются в бинарном формате Little Endian
После того как мы определились какие функции нам нужны, можно сделать 64бит библиотеку. Вызов каждой функции будет отсылать в runso32 идентификатор нужной функции и параметры и получать из runso32 результат. Таким образом, мы как бы вызываем функции из 32бит библиотеки в 64бит приложении. Это происходит хоть и с задержкой, но практически незаметно для остальной программы.
Загрузка 32 bit DLL в 64 bit DLL
в своем предыдущем посту я озадачивался вопросом о том, как можно прикрутить DLL файл в проект visual studio, для доступа к функциям библиотеки. Получил очень хороший ответ, разобрался в нем и реализовал небольшое консольное приложение для тестирование функциональности DLL.
Как же в последствии выяснилось, библиотека существует только в 32 разрядном виде и возможностей генерирования у разработчиков этой библиотеки, ее в 64 bit не существует в принципе.
По моему заданию мне нужно разработать 64 bit DLL (своего рода компонентный блок типа блока из simulink), в котором будут реализована вся функциональность 32 битной предоставленной мне библиотеки.
То есть как ни крути, а грузить ее в 64 битный процес надо.
Несколько дней курил мануалы на просторах msdn, stackoverflow и других ресурсов, но так и не нашел реализованного решения, в виде небольшого примера как это делается.
Так как в большинстве статей, говориться о том, что это сделать невозможно, задача интеграции разных процессов очень нетривиальна. Именно поэтой причине и вынес данный вопрос в отдельную тему, надеясь, что она будет интересной и остальным участникам.
Может кто-нибудь из форумчан сталкивался с подобной задачей и имеет некоторые наработки в ней?
чтобы тотчас же применить на практике теоретический рецепт.
Регистрация DLL через regsrv32 в 64 bit
Доброго. Есть ли отличия от семерки? Есть реально рабочая DLL которая работает в Win32(7,XP). В 8.
NAudio.dll не работает в Wi7 и Win8.1 64 bit
Добрый день Всем! В VB2005 на XP 32 bit писал программку по обработке звуковых данных с.
Обясните мне, если Windows 32 bit, процессор 64 bit, то работает ли 2-ое ядро?
Обясните мне, если ОС Windows 32 bit, процессор 64 bit, все программы установлены разумеется 32.
Не проще будет написать приложение-обёртку и общаться с ним по любому удобному IPC?
Добавлено через 49 секунд
Проглядел по диагонали статью по ссылке, там как раз об этом и говорят.
Не проще будет написать приложение-обёртку и общаться с ним по любому удобному IPC?
Добавлено через 49 секунд
Проглядел по диагонали статью по ссылке, там как раз об этом и говорят.
Соберите библиотеку под платформу x64.
Для ее клиентов это будет наилучшим вариантом, чем всякие грабли в
виде суррогатных процессов, IPC и прочего.
Последовательность вызовов в этом случае будет такой: клиент (64-бит), загрузив
64-битную dll-ку, будет вызывать оттуда некоторые функции, но реально эти функции
будут всего лишь «заглушками», которые сериализуют данные и передают вызов в
32-битный процесс, в который загружена настоящая 32-битная dll. В этом процессе
вызываются настоящие функции и выполняется реальная работа, после чего параметры
сериализуются обратно, в вызывающий процесс, и в итоге клиент получает результат.
Все так, как если бы он загружал настоящую 64-битную dll, если бы она существовала.
Последовательность вызовов в этом случае будет такой: клиент (64-бит), загрузив
64-битную dll-ку, будет вызывать оттуда некоторые функции, но реально эти функции
будут всего лишь «заглушками», которые сериализуют данные и передают вызов в
32-битный процесс, в который загружена настоящая 32-битная dll. В этом процессе
вызываются настоящие функции и выполняется реальная работа, после чего параметры
сериализуются обратно, в вызывающий процесс, и в итоге клиент получает результат.
Все так, как если бы он загружал настоящую 64-битную dll, если бы она существовала.
Как на 64-битной Windows запустить программы в режиме совместимости
Если в новой 64-битной Windows старая 32-битная программа не запускается или работает неправильно, вы можете запустить ее в режиме совместимости. CHIP расскажет, как это сделать.
Современные компьютеры в большинстве случаев поставляются с установленной операционной системой Windows 10 64 bit. Даже бюджетные модели уже имеют 3 и более Гбайт оперативной памяти, что позволяет задействовать системе всю мощь 64-битной разрядности обработки данных.
Подробнее о преимуществах 64 bit над 32 bit Windows вы можете прочитать в нашей статье «Преимущества перехода на 64 бита».
Но, как бы не была привлекательна 64-разрядная система, зачастую пользователь просто не имеет в своем распоряжении 64-битной программы, с которой он давно работает и которая его полностью устраивает, т.к. производитель ее просто не выпустил. Как правило, такие программы устанавливаются в Windows в отдельную папку \Program Files (x86) и их запуск осуществляется в 32-разрядном режиме.
Если в процессе запуска программа выдает ошибку или вообще не запускается, а в Windows 32 bit она работала без проблем, есть шанс запустить ее в специальном режиме, который разработчики назвали «Режим совместимости».
Для этого в Windows 7 щелкните правой кнопкой мыши на ярлыке нужной программы, а затем выберите в контекстном меню «Свойства». В открывшемся окне перейдите на вкладку «Совместимость» и установите флажок «Запустить программу в режиме совместимости с …» и в выпадающем списке укажите вариант системы для запуска.
Нажмите кнопку «OK». После этого попробуйте запустить вашу программу.
Кроме того, в контекстном меню Проводника также имеет смысл попытаться автоматически решить задачу, кликнув по строке «Исправление неполадок совместимости» — в Windows 7.
В Windows 10 при настройке запуска в совместимом режиме на вкладке «Совместимость» имеется отдельная кнопка «Запустить средство устранения проблем с совместимостью». После чего вам предложат либо использовать рекомендованные параметры, либо провести диагностику программы.
Если и после этого программа не запустилась, то стоит подойти к проблеме более основательно и попробовать варианты, указанные на официальном сайте Microsoft.
Более радикальным методом запуска программы является ее установка и использование в виртуальной машине с установленной Windows 7 32 bit. Подробнее, как установить и настроить виртуальную машину вы можете почитать в нашей статье «Как создать и настроить на ПК виртуальную ОС?».
Особенности внедрения DLL и установки хуков в Modern-приложениях Windows 8/10
Для чего вообще нужно внедрять свои DLL-ки в чужие процессы и устанавливать там хуки? Для того, чтобы понять какие функции будет вызывать это приложение, с какими параметрами и что эти функции вернут. Таким образом мы можем понять внутреннюю логику работы этого приложения, узнать к каким файлам оно пытается получить доступ, какие данные пересылает по сети, мы можем добавить в него логирование, профилирование, отладить баг, получить из приложения некоторые данные или наоборот — добавить в его интерфейс что-нибудь нужное нам. Хуки использует известная утилита Spy++ для работы с окнами приложений, DirectX-отладчики вроде RenderDoc, некоторые утилиты от SysInternals, программы типа ApiMonitor и т.д.
Некоторое время назад я писал вводные статьи об использовании хуков на примерах библиотек Microsoft Detours и madCodeHook (если вы совсем не знакомы с хуками — это то, с чего можно начать). Описанных там техник достаточно для работы с обычными приложениями, но время не стоит на месте и вот сегодня у нас уже есть Metro Modern-приложения, входящие в комплект Windows 8 и Windows 10, а также распространяющиеся через Microsoft Store программы сторонних производителей. К примеру, новый браузер Spartan — это Modern-приложение. Внедрение DLL в эти процессы имеет свои особенности и на первый взгляд может даже показаться невозможным, но это не так. В этой статье я расскажу, как мы можем залезть внутрь Modern-приложения и установить в нём хуки в своих коварных целях.
32-битные и 64-битные приложения
Операционная система Windows бывает 32-разрядная и 64-разрядная. Соответственно, Modern-приложения тоже могут быть 32-битные либо 64-битные. При загрузке приложения в магазин Microsoft разработчик собирает обе версии (плюс еще, возможно, ARM), а Windows уже сам решает, какую загрузить пользователю. Отсюда следует очевидный вывод, что DLL-ка, которую мы будем внедрять в Modern-приложение, тоже должна быть в двух вариантах. Менее очевидный вывод в том, что приложение, которое будет «забрасывать» нашу DLL-ку в чужой процесс, тоже должно быть соответствующей битности. Нам ведь нужно запустить внутри чужого процесса поток, который загрузит нашу библиотеку и вызовет из неё какую-то функцию. Делается это через вызов CreateRemoteThread(Ex), а вот уже она требует одинаковой битности вызывающего и вызываемого процессов (а иначе как передавать адреса?).
Доступ к внедряемой DLL
Как вы, возможно, знаете, Modern-приложения живут в своих песочницах, откуда они имеют доступ только к своей папке и некоторым другим доступным для них (ограниченным) ресурсам ОС. К примеру, Modern-приложение не может вот просто так взять и открыть любой файл с диска. Для нас это означает то, что попытавшись заставить чужое приложение подгрузить нашу библиотеку в своё адресное пространство — мы получим ошибку доступа. Это можно легко увидеть, воспользовавшись, к примеру, утилитой ProcMon.
Что же делать? Разрешить доступ к файлу внедряемой библиотеки для Modern-приложений. Для этого есть системная утилита icacls. Вот эта команда открывает доступ к файлу на диске для всех Modern-приложений:
Теперь ошибки доступа у нас не будет.
Линковка DLL-ки
Но не всё так просто. DLL-ка может иметь зависимости. И даже если вам кажется, что их нет — возможно, вы забываете о зависимости от VC++ Runtime Library. По умолчанию созданная в Visual Studio С++ библиотека предполагает динамическую линковку с рантайм-библиотекой С++. Это означает, что когда какое-то приложение захочет загрузить вашу библиотеку — функция LoadLibrary() первым делом увидит, что вам необходима, к примеру, библиотека msvcp90r.dll и попытается её найти, что вобщем-то, получится если речь идёт об обычном (не Modern) приложении и наличии соответствующего VC++ Redistribution Package. Что касается Modern-приложений, то порядок поиска DLL-ок совсем другой. Если коротко: будучи вызванной из Modern-приложения, LoadLibrary() не найдёт библиотеки VC++ Redistribution Package, даже если они до этого были успешно установлены.
Первые два способа крайне некрасивы (а без аккаунта администратора и невозможны), третий — сработает, но влияет на глобальную конфигурацию ОС, что тоже может быть чревато последствиями. Так что самый простой вариант — статическая линковка (ключи /MTd и /MT на вкладке Code Generation).
Цифровая подпись
Решив все вопросы с доступом к файлу DLL-ки может показаться, что у нас всё получилось — ProcMon не показывает никаких ошибок доступа. Но инъекция всё равно не работает — DLL-ка не появляется в списке загруженных модулей процесса. Что же пошло не так? На этот вопрос нам даёт ответ просмотр Windows Event Viewer.
Операционная система не хочет загружать нашу DLL-ку, поскольку она не подписана. В этом месте мне стало тревожно, поскольку я уж было подумал, что все модули, загружаемые в Modern-приложение, должны быть подписаны цифровой подписью одного издателя (разработчика). Но, к счастью, это не так. Windows требует от DLL-ки просто наличия валидной цифровой подписи, но не требует её соответствия подписи автора приложения. Т.е. мы можем взять подписанную DLL-ку от Хрома и забросить её в Spartan. Что же делать нам? Получить сертификат и подписывать нашу DLL-ку.
Да, это серьёзно усложняет работу. Но ведь в принципе, если мы разрабатываем нормальный продукт, а не какие-нибудь вирусы\трояны\малвари\кейлоггеры\локеры — у нас не будет проблем с получением сертификата и его использованием для подписи DLL-ки. Вообще, я считаю эту защиту одной из самых серьёзных шагов Microsoft по защите пользовательских данных и изоляции Modern-приложений в песочнице. Фактически от желающего пробросить мостик к приложению требуют предъявить документы и идентифицироваться, а это остановит 99% скрипт-киддисов.
Права доступа на канал связи
Ок, теперь наша DLL-ка внедрена в чужой процесс, она может вешать хуки на разные системные функции, делать что-то полезное, но… Сама она живёт в той же песочнице, что и родительский процесс, то есть ни передать данные «наружу», ни получать команды «извне» она не может, ведь для этого нужно создать канал связи, на который она по умолчанию не имеет прав. Как решать эту задачу я уже отдельно рассказывал вот в этой статье, а здесь просто упоминаю в качестве пункта, о котором важно не забыть.
Поддержка 32-битных приложений в 64-разрядной версии Windows
Поддержка 32-битных приложений в 64-разрядной Windows
Появление 64-разрядных Windows вызвало немало вопросов. Поддержка 32-битных приложений, драйверов и всего того, что рассчитано на архитектуру x86. Установка и особенности использования программ. Вводимые ограничения для 32-разрядных приложений. Поддержка старых режимов и многое другое. Все это никак не могло остаться в стороне. Ведь, пласт 32-разрядного наследия слишком велик, и в 64-битной среде его мало чем можно заменить, даже сейчас.
В этой статье приводится обзор подсистемы Windows на Windows 64 (WOW64) и ее методов, которые позволяют Windows поддерживать 32-битные приложения на 64-битной системе.
Примечание: Первая попытка внедрить 64-разрядные системы была достаточно провальной. Жесткие ограничения и отсутствие реальных преимуществ давало о себе знать. На тот момент, даже драйвера под 64-разрядные системы было достаточно сложно найти. Не говоря уже о программах, на которых хоть как-либо была бы заметна разница. Снятие ограничения на 3Гб оперативной памяти, безусловно, сегодня сильное преимущество, но на тот момент это больше напоминало красивый слоган.
Устройство поддержки 32-битных приложений в 64-разрядной Windows
Windows 32 на Windows 64 (WOW64)
WOW64 эмулирует 32-битную Windows
В Windows 64, 32-битные приложения выполняются в эмулированной 32-разрядной операционной системе, которая называется Windows 32 на Windows 64, или WOW64 для краткости. Основной задачей WOW64 является перехват и обработка всех системных вызовов от 32-разрядных приложений.
Для каждого перехваченного системного вызова, WOW64 создает 64-разрядный системный вызов, превращая 32-битные структуры данных в подходящие 64-битные. В последствии, 64-битный системный вызов передается ядру операционной системы для обработки. Все полученные выходные данные 64-битного вызова будут преобразованы и переданы в том формате, на которое приложение рассчитывало. Другими словами, реальные запросы к ядру системы всегда 64-битные. Подсистема WOW64 лишь выступает в качестве посредника, приобразуя данные в подходящие форматы.
Как и 32-битные приложения, WOW64 выполняется от имени пользователя, так что ошибки, которые могут происходить во время преобразования системных вызовов, будут происходить на уровне пользователя. И никак не затронут 64-битное ядро операционной системы.
Тот факт, что WOW64, как и 32-битное приложение, выполняется в режиме пользователя, объясняет причину отсутствия поддержки 32-битных драйверов. Если говорить другими словами, то, для корректного запуска, драйверам требуется режим ядра, который не может обеспечить WOW64. Поэтому, если у вас 64-разрядная Windows, то все драйвера должны быть 64-битными.
Эмулятор WOW64 состоит из следующих 64-разрядных библиотек:
Примечание: Это единственные 64-разрядные библиотеки, которые загружаются в 32-разрядный процесс.
Wow64.dll загружает 32-битную версию (x86) Ntdll.dll и все необходимые 32-битные библиотеки, которые в основном остались без изменений. Однако, некоторые их этих 32-разрядных библиотек все же были изменены, чтобы корректно исполняться в WOW64. Как правило, такие изменения были сделаны из-за того, что они используют оперативную память вместе 64-разрядными компонентами системы
Управление файлами и настройками реестра в WOW64
В дополнение к функциям перехвата и обработки системных вызовов, интерфейс WOW64 так же должен гарантировать, что файлы и параметры реестра 32-битных приложений будут храниться отдельно от файлов и ключей реестра 64-разрядных программ. Для достижения этой цели WOW64 использует два механизма. Перенаправление файлов и реестра, а так же дублирования ключей реестра. Перенаправление поддерживает логическое представление данных и отображает их так, как если бы приложение запускалось в 32-разрядной Windows. Дублирование ключей реестра гарантирует, что изменение ряда параметров, которые не зависят от разрядности, будут доступны как 32-битным, так и 64-битным приложениям.
Перенаправление файлов
Перенаправление файлов позволяет гарантировать, что файлы и каталоги 32- и 64-битных приложений будут храниться отдельно и не мешать друг другу.
Файлы 32-разрядных приложений, по умолчанию, устанавливаются в:
32-разрядные системные файлы устанавливаются в:
Для 64-разрядных приложений, файлы устанавливаются в:
Механизм перенаправления WOW64 гарантирует, что запросы от 32-разрядных приложений к каталогам «C:\Program Files» и «C:\WINDOWS\SYSTEM32» будут перенаправлены на соответствующие каталоги для 32-битных версий.
Однако, существует одна проблема с перенаправлением файлов. Пользователи и разработчики должны быть в курсе этой особенности.
Многие 64-разрядные приложения все еще используют 32-битный режим и процедуры. И не учитывают это при создании инсталлятора. Для того, чтобы приложение было установлено правильно. т.е. в «C:\Program Files», программа установки должна сделать системный вызов к операционной системе, чтоб система приостановила механизм перенаправления файлов Wow64. А после установки сделать другой системный вызов, чтобы снова включить перенаправление. Если производить установку без остановки перенаправления, то программа будет установлена в «C:\Program Files (x86)». Классическим примером данной ошибки является 64-разрядная версия FireFox 3.5 под кодовым названием «Shiretoko», которая устанавливается в «C:\Program Files(x86)\Shiretoko». Конечно, Firefox по-прежнему будет нормально функционировать. Единственное, что вы не сможете сделать, так это изменить иконку приложения.
Примечание: Возможно, сейчас эту ошибку в Shiretoko уже исправили. Тем не менее, в ранних версиях было именно так.
Перенаправление реестра
Ключи реестра, специфические для 32-разрядных приложений, будут перенаправлены из ветки:
Так же, иногда, можно встретить записи реестра в другой ветке (хотя это необычно):
Такой подход позволяет 32- и 64-битным приложениям нормально сосуществовать, без проблем с перезаписью настроек друг друга.
Дублирование реестра
Некоторые перенаправленные ключи и значения реестра необходимо дублировать. Это означает, что если 32-разрядное приложение вносит изменения в перенаправленном разделе реестра, то эти изменения необходимо так же применять и для веток 64-разрядных приложений. В данном случае действует принцип «кто последний, тот и прав». Например, если вы установите три приложения, привязывающие себя к одному и тому же расширению файла, то ассоциация с расширением файла должны быть с последним приложением.
В результате этих действий, по двойному щелчку на файле с расширение XYZ в проводнике Windows должно открыться приложение, которое было установлено на 3-ем шаге. Ведь, именно оно последним ассоциировало себя с расширением.
Все это происходит прозрачно для 32-битных приложений в Wow64, которая самостоятельно перехватывает обращения и дублирует необходимые параметры и ключи реестра. Другими словами, 32-разрядные приложения могут выполнятся стандартным образом, необходимые изменения за них внесет Wow64.
Существует ряд ограничений подсистемы WOW64
Некоторые, но не все, 64-битные функции доступны 32-разрядным приложениям
Wow64 позволяет 32-разрядным приложениям использовать некоторые функции и возможности 64-битных систем. Например, при правильной настройке, такие приложения смогут использовать до 4Гб оперативной памяти. Доступ к другим функциям ограничен из-за особенности устройства 64-битных систем. Например, 64-битная ОС Windows поддерживает 64-битные логические операции. Тем не менее, 32-битные приложения не будут иметь доступ к ним, они смогут использовать только 32-битные логические операции.
Примечание: Основной причиной ограничений служит разница в представлении данных 32- и 64-битных приложений. 32-разрядное приложение попросту не рассчитано на 64-разрядные типы данных.
Нельзя смешивать между собой код (Code Injection) 32-битных и 64-битных приложений
В 64-битной ОС Windows нельзя запускать 32-битный код в 64-разрядном процессе, как и нельзя запускать 64-битный код в 32-разрядном процессе. Приложения, использующие инъекции кода (Code Injection) для добавления функциональности в существующие приложения, как правило, будут выдавать ошибки.
Этот факт объясняет, почему большинство 32-битных расширений оболочки Windows не запускаются под 64-разрядной Windows. Большинство таких расширений используют инъекцию кода (Code Injection) для встраивания в проводник Windows
WOW64 не поддерживает 16-разрядные инсталляторы
WOW64 обеспечивает поддержку 16-битных инсталляторов Microsoft, путем замены инсталлятора на совместимую 32-битную версию. Тем не менее, эта поддержка не распространяется на сторонние продукты. Так что, если вам нужно использовать старую программу, то, скорее всего, придется искать эмулятор или портативную версию.
Дополнительные возможности для запуска 32-битных приложений в Windows 64
Windows Virtual PC
Windows Virtual PC это бесплатное программное обеспечение, которое позволяет запускать несколько операционных систем на одном компьютере. Virtual PC обеспечивает специальную среду исполнения, которая поддерживает устаревшее оборудование и программное обеспечение, которое не будет определяться и запускаться в Windows 7. Все запущенные операционные системы под Virtual PC будут выполняться в виртуальной машине. Это означает, что запущенные операционные системы не будут знать о том, что они запущены в другой системе.
Системные требования и набор функциональности существенно различается между версиями Virtual PC и версиями Windows. Так что, прежде чем пытаться использовать Virtual PC, необходимо проверить, что программа поддерживает как вашу операционную систему, так и те ОС, которые будут на ней запущены. Например, одна из последних версий уже не поддерживает версии Windows ниже Windows XP SP3.
Режим Windows XP (XPM)
Режим Windows XP это конкретная и урезанная реализация Windows Virtual PC, которая поставляется с предустановленной копией Windows XP Professional SP3. Этот режим доступен только в версиях Enterprise, Ultimate и Professional Windows 7 64-бит.
Несмотря на то, какие возможности был бы должен представлять этот режим, многие, кто использовал XPM, настоятельно советуют использовать этот режим только в качестве последнего средства. По сравнению с другими продуктами виртуализации, производительность разочаровывает, а конфигурация по умолчанию вызывает ряд вопросов безопасности.
Примечание: К некоторым более дательным настройкам режима совместимости все же можно обратиться. Более подробную информацию вы можете найти в обзоре Как запустить старые программы на Windows 7 / Vista? (см. Microsoft Application Compatibility Toolkit).
Мультизагрузка ОС Windows
Вы можете установить более одной версии Windows на одном компьютере, с помощью мультизагрузчика. Например, установить 32-разрядную и 64-разрядную версии Windows рядом друг с другом. Каждая операционная система устанавливается на отдельный раздел диска, а менеджер загрузки устанавливается на разделе по умолчанию. Менеджер загрузки позволяет выбрать и запустить операционную систему, которую вы хотите сейчас использовать.
Хоть, вы и не можете одновременно использовать больше одной операционной системы, эта функциональность является достаточно полезной. По сравнению с виртуальными машинами, такой способ не имеет никаких проблем с совместимостью и такие системы гораздо легче настраивать и обслуживать. Кроме всего прочего, установив 32-разрядную версию рядом с 64-битной, вы сохраните возможность запускать 16-битные приложения.
Подытоживая сказанное о поддержке 32-бит в 64-разрядной Windows
Большинство 32-разрядных приложений будут вполне счастливо себя чувствовать в Windows 64. Основными исключениями будут:
Некоторые приложения смогут запускаться с ограничениями. Это так же касается деинсталляторов, программ для очистки реестра и программ для тюнинга, так как они имеют доступ только к той части реестра, которую им показывает Wow64.
Если вы никак не можете запустить 32-битное приложение, то рассмотрите вариант с виртуализацией или мультизагрузкой нескольких операционных систем.
Какие приложения быстрее 32-битные или 64-битные?
Этот вопрос звучит достаточно часто. Но, нет никакого общего правила или коэффициента умножения, поскольку все зависит от задач и используемых функций процессора.
Если сравнивать 32- и 64-разрядные приложения в своих родных средах, то 32-битное приложение, как правило, использует меньше памяти, чем эквивалентное 64-разрядное приложение. Это происходит потому, что 64-битные версии используют 64-битные структуры данных, которые занимают вдвое больше места. Дополнительный размер напрямую влияет на время запуска и закрытия программы, а так же на другие виды операций, связанных с доступом к дисковым накопителям. Обычно, это означает, что 32-разрядные приложения будут выполняться быстрее. Тем не менее, использование 64-битными программами особенностей 64-разрядного процессора потенциально позволяет приложению выполняться на 25% быстрее, по сравнению с 32-битными программами.
Кроме того, необходимо помнить, что запуск 32-битного приложения на 64-разрядной Windows означает запуск Wow64, поэтому анализ производительности на 32-битном процессоре можно отложить в сторону. Запуск Wow64 означает не только затраты на преобразование вызовов, но и учет механизмов перенаправления и дублирования, которым требуются не только процессорное время, но и оперативная память. Поэтому, возможно, 32-разрядное приложение будет выполняться быстрее 64-битного, но оно однозначно будет выполняться медленнее, чем при эквивалентном запуске на 32-битном процессоре.
И самое главное, вы всегда должны понимать, что увеличение размера регистров процессора, а именно это и обозначают цифры 32 и 64, никак не влияет на саму задачу. Если задача не зависит от объема или диапазонов значений, то увеличение разрядности не будет играть почти никакой роли. Другими словами, от того что вы сложите продукты в большой холодильник, продуктов не станет больше и быстрее они не охладятся.
Теперь, вы знаете ряд особенностей запуска 32-битных приложений на 64-разрядных Windows. А так же что такое Wow64 и какие ограничения он накладывает на 32-разрядные программы.