Comments 41
Зачем нужны старые бинари? Чтобы что? Всё есть в исходниках, а та малая часть софта, что поставляется в бинарях, чаще всего всё равно завязана на сервер, и работать перестанет уже после обнов на пару минорных версий.
В винде совместимость критически важна, поскольку исходники софта никто не шарил никогда, даже бесплатного, это большая редкость. В линуксах оно или есть в репе, или лежит на гитхабе - скачал и пересобрал, или лежит на сайте вендора в виде какой-нибудь из бинарных сборок.
Играть в старые игры, например. Исходники - это хорошо, но их еще собрать надо, далеко не всякому пользователю это под силу.
можно подумать что старые исходники соберутся на новой системе с новыми библиотеками без проблем, например есть PAC (аналог mobaxterm), вот только на более менее новых системах для него один вариант AppImage
Старому софту нужные старые библиотеки, иногда - старые компиляторы и т.п. Потому собрать старый софт - если это что-то уровня офисного пакета, а не "хелло ворлд" - может быть очень сложной задачей.
Если я найду файл в формате .exe, которому 20 лет, я по-прежнему смогу запустить его на современной Windows.
Это какой-то сомнительный тезис. Он верен только для очень простого ПО, действительно состоящего из одного exe. Любая более сложная программа требует окружения, которое и создаёт инсталлятор. Даже portable версии всё равно нуждаются как правило в каких-то дополнительных папках и файлах, без которых работать не будут.
Инсталлятор и будет тем самым одиноким exe, вы его запустите, а потом саму программу...
Если этот бинарь в Вынь11 последней редакции запустится (так как там уже и 16бит приложения отменяют и прочие старости), если система безопасности винды не даст по рукам (а во времена 9х и линолеума про безопасность и разграничения доступа и не слыхивали).
Если этот инсталлятор не совсем кастомный (а в те годы очень любили закостылепедить что-то мегаупоротое).
Если приложуха не костылит на ВыньАПИ (а что бы без тормозов, там гоняли кучу грязных хаков), или нестандартную графику.
Система безопасности работает одинаково как для старых, так и для новых ехе. Она зависит не от ехе, а от системы как бы.
Кастомный инсталлятор - это обычное приложение, которое обычно наоборот менее всего зависит от чего-то стороннего при запуске.
win16 отвалилось с переходом на 64 бита. А инсталяторы нередко были win16 даже у программ под win32, потому могут не ставиться. Если же выковырять программу мимо установщика, то вполне реально запустить.
А от системы безопасности винды помогает установка не в програм файлс, а в стороннюю папку с коротким именем на латинице.
Какой линолеум? Двадцать лет назад вышла Vista. Так что, речь тут идёт о приложениях, написанных под XP SP2. Как раз одним таким приложением я пользуюсь в Win11 каждый день. Правда, ему не 20 лет, а 22 года. И оно тащит много зависимостей — WebView1 (IE6) через GUID, например.
P.S. Ниже ещё смешнее. Цива 1, которую я помню в детсаду на 286 (загрузка-заставка знатно тормозила), написанная под DOS, и выпущенная в сентябре 1991 — оказывается, двадцатилетней давности. Большая поломка совместимости действительно была, но в 2001 году, когда все с 9x переезжали на XP. Игры на Build'е запускались с глюками, да и вообще, досовские игры под саундпластырь. Только было это не 20, а 25 лет назад.
Недавно запустил на Win11 Visual C++1.5, 2.0, 4.2. Это 1993-1999г выхода примерно
Работает, компилируется, траблы только с пошаговым отладчиком.
Пусть автор статьи запустит файл civ.exe (из Civilization 1 или 2) под Win10 или 11.
ReactOS? Молодежь не слышала?
В Linux можно выполнять системные вызовы напрямую. Для этого нужно просто заполнить несколько регистров и сделать прерывание системного вызова.
В Windows системные вызовы напрямую не выполняются. Вместо этого требуется делать динамические привязки к библиотекам, которые уже будут выполнять системные вызовы за вас.
Вообще-то в Linux в большинстве случаев системные вызовы делаются не напрямую, а через библиотеки типа glibc, musl и тому подобные. И как раз несовместимостью этих библиотек во многих случаях и вызваны проблемы с запуском старых бинарников.
А в wine проблем с совместимостью всё ещё хватает (первое, что сходу вспомнилось — это авторизация в лаунчере Battle.net от Blizzard). И зачастую, чтобы запустить ту или иную игру или старое Win-приложение, нужно чётко знать, какие библиотеки нужно доустановить с помощью winetricks. А без этого знания остаётся только сидеть и смотреть на невнятные сообщения об ошибках.
А разве статическая линковка библиотек при сборке не решит эту проблему? Ладно, glibc, не получится, но musl кажется можно?
следует создать такой дистрибутив Linux, который по умолчанию выполняет двоичные файлы Windows через Wine.
Непонятно зачем доя этого дистрибутив. Устанавливаем любой линукс с любой графической оболочкой, устанавливаем из менеджера пакетов Wine. Всё, экзешники запускаются дабл-кликом. Задача выполнена?
Есть прекрасный проект DOSBIAN к сожалению только для Raspberry. Если бы родить аналогичный для x86, это бы позволило устанавливать винды под Linux и использовать всё накопленное обеспечение.
Из забавного, на Windows 10, х32 (22h2, x86-32 ЦП) прекрасно запускается Office '97 через встроенную NTVDM (х86-16) и даже обеде старый софт.
Интересно, работает ли это с Wine, надо будет проверить... Как помню, там только х64 и х32 версии работают. Хотя не исключаю возможности запуска программ под старые архитектуры. По крайней мере на Windows 11 есть опенсорсная реализация ntvdm под х16, а для х32 есть нативная реализация запуска (тем более, что многие старые компоненты в системе всё ещё х32).
Linux же остаётся хорошей вещью, своего рода конструктором, который надо аккуратно и относительно долго собирать-подгонять под себя и своё железо.
В теории всё выглядит хорошо, а как на практике быть с разными «сквозностями»? Это не возражение, а вопрос, ответ на который меня очень интересует, ибо я очень хотел бы безболезненно свичнуться с Микрософта, но не уверен, что это сейчас реально.
Вот пример. Если нажать Ctrl + O, программа под Windows может превратить эту комбинацию клавиш в вызов ::GetOpenFileName(). Но что произойдёт дальше? В, так сказать, нативном Windows я увижу диалог от Explorer'а, а это значит, что:
Для видеофайлов будут отображаться thumbnail'ы, сгенерированные K-Lite Codec Pack.
Для редких форматов графики будут отображаться thumbnail'ы, сгенерированные просмотровщиком.
Каждая папка, куда я зайду, будет отображаться в соответствии с настройками из
desktop.ini. Вообще-то, для большинства папок у меня нет никаких настроек (я же не совсем сумасшедший… так, 🤏), но есть небольшой набор папок (библиотеки того-сего), которые мне удобно настроить один раз, чтобы потом с удобством открывать десятки раз в день.Для путей используется сквозной кеш: если я введу строку с текстом пути, открывая файл в Фотошопе, она запомнится, и я смогу выбрать её, загружая файл в Firefox.
Можно дважды кликнуть по заголовку, и диалог раскроется на весь экран. И это maximized-состояние Explorer потом запоминает, независимо от приложения, где мы нажали
Ctrl+O, что очень удобно: когда я ищу файл, чтобы его открыть, мне почти никогда не интересен контекст (окно приложения) и его смело можно перекрыть. А вот искать файл при помощи большого окна куда удобнее.В табличном представлении (Details) видно те колонки, которые ты выбрал сам. Некоторые из них добавляются плагинами к Explorer. Немного пошаманив, можно добиться, чтобы заголовки колонок отображались в любом представлении (с thumbnail'ами), что удобно для сортировки.
Наконец, почти в каждом приложении при открытии файла слева можно видеть одни и те же (сквозные) букмарки, включая крайне удобные Recent items и Recent places. Которые настраиваются в базовом приложении файлового менеджера (то есть, в Explorer).
Если через Wine приложение покажет немаксимизируемое (или вообще с неизменяющимся размером) окно, которое не отображает папки так, как я хочу, и не поддерживает букмарки и всё остальное, что перечислено выше… Формально-то оно, конечно, будет бинарно совместимо, но только юзеру от этого не легче.
Идеально было бы воспользоваться опытом Android: там операция выбора файла стандартизирована, и любое приложение может зарегистрироваться в качестве провайдера такой услуги. Ты ставишь себе какой-нибудь Root Explorer, а потом указываешь, что остальные приложения должны выбирать файлы с его помощью. Если бы так был устроен Windows, вы могли бы назначить файловым менеджером, например, FAR, потом выбрать в Блокноте Open… и увидеть окно FAR'а для выбора файла. Но Windows устроен иначе, а FAR (как и любой файловый менеджер под винду) просто не поддерживает режим выбора файла за невостребованностью.
Что делать со всем этим? И это только один маленький пример — выбор файлов в приложениях. А их ещё много. Интересно было бы послушать тех, кто пытался на практике порешать подобные задачи.
Идеально было бы воспользоваться опытом Android: там операция выбора файла стандартизирована, и любое приложение может зарегистрироваться в качестве провайдера такой услуги
А чтобы было ещё веселее, можно вспомнить, что Explorer — не такая простая штука, как кажется на первый взгляд. Например, его file dialog поддерживал кастомизацию на колбеках, а в результате можно было добавить, скажем, выбор символа делиметра при выгрузке в текстовой файл:
Это стандартный диалог, но расширяемый из колбека конкретного приложения.
Почему я говорю, что стандартизация операции выбора файла — идеальный вариант? Да потому, что это позволит перенести ответственность за все нужные фичи со слоя совместимости (WINE) на отдельное приложение.
Однако, если вы стандартизируете операцию выбора файла, мало будет уговорить окружающих писать файловые менеджеры под ваш стандарт. Надо ещё, чтобы они все поддерживали кастомизацию на колбеках от древнего проводника времён Win98, потому что без этого некоторые приложения не смогут экспортировать данные с нужным делиметром. Соответственно, правильно было спроектировать это дело так:
Слой совместимости (WINE) поддерживает стандарт операции выбора файла.
Приложение в системе (файловый менеджер) регистрируется как имплементирующее этот стандарт.
При запуске Windows-приложения слой совместимости видит, что приложению нужна кастомизация диалога, и проверяет, поддерживает ли зарегистрированное приложение такую фичу (скорее всего, нет, потому что новое приложение будет написано так, что диалог выбора в нём будет страницей HTML или сценой OpenGL ES, а для кастомизации нужна поддержка хендлов).
Слой совместимости отдаёт свою, референсную имплементацию диалога, чтобы обеспечить работу кастомизации.
И знаете что? Я не понимаю, кто и на какие деньги будет всё это писать! Поэтому я не очень верю в такие идеи, как описаны в статье. Но, повторюсь, интересно почитать, если кто-то с этим сталкивался на практике.
Я писал несколько программ на Паскале лет как раз 20 назад. Под 7-кой мои экзешники уже не запускались(((
Понадобится немного модифицировать семейство системных вызовов «exec», чтобы диспетчеризация зависела от типа исполняемого файла.
Не нужно ничего модифицировать — в ядре уже имеется механизм binfmt_misc, позволяющий запускать чужеродные бинарники. Например, я использовал его вместе с qemu для сборки модулей ядра для ARM-одноплатника (очень не хотелось возиться в кросс-компиляцией).
Юзкейс «запускать исполнимые файлы Windows через Wine при помощи binfmt_misc» настолько очевиден, что приводится как пример в man binfmt.d и википедии. Это никакая не панацея, а скорее финальный штрих, которой можно сделать для удобства, когда все остальные проблемы с совместимостью уже решены.
Немного отстали от жизни, уже превратили, добро пожаловать в Twister OS, работает на Raspberry Pi. В дистрибутив интегрирован эмулятор Box86 и Box64 для запуска x86 приложений и Wine.
И зачем нам пятый велосипед, когда уже четыре есть?? Уже многие выше писали, что запуск старых приложений на современной Винде зачастую невозможен. Уже молчу про разработчиков, какие-нибудь nvidia выпиливают 32 битную cuda из последних видеокарт, тут уже не то что софт не позволяет запускать старые приложение, а железо. Также в современной повседневной жизни не случается нужды запуска старых приложений (исключением может быть только старые игры, но они тоже уже по железным причинам не запустятся (glide, например, нужен)), такие вещи нужны для старых дров для станков на заводе, где до сих пор стоят древние компы на XP. Если брать любой маль-мальски популярный дистрибутив или ответвление от debian, arch или rhel, то с софтом проблем нет. А ещё похожее на описание из статьи есть в zorin, где предустановлен wine или при запуске не поддерживаемого приложения предлагаются аналоги.
Полностью поддерживаю!
Был такой старый анекдот
Эпоха борьбы с компополитизмом. Приходит Рабинович устраиваться на работу. Кадровику поступило негласное указание евреев не брать, но прямо об этом сказать нельзя. Вот кадровик и мучается:
— Э-э-э... м-м-м... ну, как бы это вам.... ну-у-у...
— Да вы не переживайте так, я русский!
— Русский? Ну вот и идите тогда. С такой фамилией я уж лучше еврея возьму!
Я к тому, что если мне нужен будет вот прямо Windows-Windows, то в качестве такового я уж лучше возьму Windows. А для всего остального есть Cinnamon (почти как в рекламе).
Если я найду файл в формате .exe, которому 20 лет...
Ну запустите NN например? Пукан не слипся?
Статья лютый бред. Последние форточки что использовал были 3.1. Потом ось пополам. потом линукс. Более нестабильного кала чем окна нет. Рядом пукнуть страшно. Обновления - лоторея.... У меня mageia и pclinuxos. Уже шесть лет работают, уже успел пару раз диски сменить, а они живы. Линукс для работы, работать в винде лютый мазохизм.
Да... нытье очередного аналнытика
Как превратить Linux в Windows