По поводу быстродействия вайна

ddr=opengl

Директдрав там ровно не при чем, оно 3D.

Ну d3d библиотеки нативные поставь.

Так нативных d3d8 нет, опять же.

i386 с возможностью запуска amd64 из 32-битного едра

Во костылей нагородили.

Ну да, вытягивать полгига зависимостей ради шкайпа (или любой другой i386-only прилаги) - это гораздо круче. Не говоря уже о невозможности запустить 64-битный код при загруженном 32-битном едре в принципе, и сомнительной возможности иметь 32-битный юзерспейс, но 64-битное едро.

В 10.5-10.6 можно было запускать вообще любые приложения, даже не глядя что там внутри (powerpc32, powerpc64, i386 или amd64) - ось хавала все.

Потом Жобс умер и на совместимость решили положить большой и вялый.

И да, как-то так выглядит тестирование этой фичи:

http://rgho.st/6bqz6qrPW

Ты отличай костыли для легаси от костылей для нового ПО.

Вообще я слабо представляю, как это всё работает.

EFI конкретно в этом маке 64-bit only. Прозреваю, что ядро работает под его управлением в compatibility mode, а приложения в зависимости от разрядности.

Да, с 10.8 поддержку 32-битных ядер дропнули. Но веселит именно то, что в отличии от линуксов и бздей (и даже шинды) именно на маке были минимальные проблемы с 386/64 совместимостью.

Жобс умер и на совместимость решили положить большой и вялый

Ну вот в винде легаси свято чтут и ухаживают. Так что от реестра и 96 dpi не могут уже 30 лет избавиться. Надо же выбрасывать говно рано или поздно.

Попробуй позапускать старые игры на винде >=8.

Даже такая банальщина, как KOTOR2 (никаких недокументированных функций уровня ZwKillBillGates(ZPHDRWRPRDLNG *huita), и OpenGL для графики) на десятке попросту падает.

А уж под XP 64 (времен примерно той самой макоси) не запускалось толком вообще нихрена.

В линуксе со свободным ПО никогда проблем с совместимостью не было. Было только с проприетарным.

Ну да, никаких проблем - только выкачать полтонны библиотек под другую архитектуру. Или пересобрать мир/переустановить шиндовслинукс, если захотелось не 386 под 64, а наоборот.

Ты читать умеешь? Я сказал: со СВОБОДНЫМ ПО никаких проблем не было. Свободное ПО не нужно запускать под неродной архитектурой.

Оукей, гугл, найди мне bzip1 иначе чем в виде бинаря.

Заменить на (любое СПО из которого выпилили фичу, потому что патентная паранойя или просто автор мудак).

Ну да, никаких проблем - только выкачать полтонны библиотек под другую архитектуру.

Вы африканский рейнджер со спутниковым интернетом по $5/МБ? Тем более сделать надо один раз. Тем более в развитых пакетных менеджерах может быть флаг, с которым мультилиб-пакеты ставятся одновременно. А вообще этот нонсенс, я понимаю ещё, если бы ваш дистрибьютор i386 в принципе не собирал (как RHEL7).

Оукей, гугл, найди мне bzip1 иначе чем в виде бинаря.

А тебе зачем - сохранились архивы в виде bzip1? Тогда вот: https://web.archive.org/web/19980704181646/http://www.muraroa.demon.co.uk/bun...

Я сейчас проверять не буду, но есть еще одиндва нюанса.

1. Не всегда старый софт собирается современным gcc/шлангом без перелопачивания половины кода.

1.1 Иногда лопатить нужно столько, что это невыгодно по затратам времени (это если дохрена ассемблерных вставок именно под x86, без которых вообще ничего не работает, либо работает очень медленно). То есть, даже собрав его таки с горем пополам пятым гцц, на выходе получаем x86 бинарь, которому нужа как минимум libc, а как максимум - полсистемы соответствующей архитектуры.

Ну и это разархиватор, а архиватора вроде нету вообще, да.

Я сейчас проверять не буду

А я вот проверил, на современной системе (CentOS 7) всё собралось. Там даже IntNative заместо int. Умели же раньше делать!

┌ home :: ~/tmp :: ls
└ d_a % gcc -o bunzip021 -Wall -Wextra bunzip021.c 
bunzip021.c: В функции «arithCodeStartEncoding»:
bunzip021.c:794:42: предупреждение: параметр «bs» не используется [-Wunused-parameter]
 void arithCodeStartEncoding ( BitStream *bs )
                                          ^
bunzip021.c: В функции «arithCodeDoneDecoding»:
bunzip021.c:826:41: предупреждение: параметр «bs» не используется [-Wunused-parameter]
 void arithCodeDoneDecoding ( BitStream *bs )
                                         ^
bunzip021.c: В функции «mySignalCatcher»:
bunzip021.c:2077:34: предупреждение: параметр «n» не используется [-Wunused-parameter]
 void mySignalCatcher ( IntNative n )
                                  ^
bunzip021.c: В функции «mySIGSEGVorSIGBUScatcher»:
bunzip021.c:2087:43: предупреждение: параметр «n» не используется [-Wunused-parameter]
 void mySIGSEGVorSIGBUScatcher ( IntNative n )
                                           ^
┌ home :: ~/tmp :: gcc -o bunzip021 -Wall -Wextra bunzip021.c
└ d_a % ./bunzip021 
BUNZIP-0.21, a block-sorting file decompressor.  14-Sept-97.
bunzip021: I won't read compressed data from a terminal.
bunzip021: For help, type: `bunzip021 --help'.

Ну и это разархиватор

Я об этом и сказал.

1. Не всегда старый софт собирается современным gcc/шлангом без перелопачивания половины кода.

Ты просил исходники - вот они. И они собираются.

архиватора вроде нету вообще, да.

Забавный ты парень. Автор считает, что он нарушил закон, поэтому удалил исходники из сети, а ты надуваешь губки и капризничаешь «хачу заархиватор!!111». Он ради твоего каприза должен был подставляться, ага.

Изначально вопрос был в «проблемы с мультилибом могут возникнуть только с пиписитарным софтом». Не только.

Ну и скажем про пиписитарный - тот же банальный hlds (игровой сервер первой халвы/кс 1.6) до сих пор распространяется только в бинарном виде и только под x86. amd64 версию делали на волне хайпа на «круто-стильно-молодежно» где-то в 2004-2006, потом забили. Ибо все равно все попенсорсные плагины, включая метамод и амикс собирались нормально только под 32 бита.

Изначально вопрос был в «проблемы с мультилибом могут возникнуть только с пиписитарным софтом»

Изначально вопрос был вообще о Wine.

пиписитарный

попенсорсные

Тебе не кажется, что пора лечиться?

плагины, включая метамод и амикс собирались нормально только под 32 бита

Проблема курицы и яйца.

Даже такая банальщина, как KOTOR2 (никаких недокументированных функций уровня ZwKillBillGates(ZPHDRWRPRDLNG *huita), и OpenGL для графики) на десятке попросту падает.

Мимопроходя хочу заметить, что запускал KOTOR2 на десятке некоторое время назад без проблем. Да и какие могут быть проблемы, если они обновляли его год назад примерно?

Я не про стимовский ремастер с модами-шмодами и хайресом, а про оригинал 2005 года. Ремастер на старых видюхах (с GL <3.0) не запускается вообще.

В линуксе со свободным ПО никогда проблем с совместимостью не было.

И потому убунтоидный эмулятор дреамкастла в федоре новее 12 не собирается, а пакеты из 12 версии работают через Ж.

Какой конкретно эмулятор? Он собирается на 32 битах, но не собирается на той же системе, но 64-битной?

А списочек такой огромный... http://www.emu-land.net/consoles/dreamcast/emuls/Linux lxdream-0.9.1 на 64 битной 17 федоре никак у меня не собирался. Для двадцатьвторой федоры пакет с «волшебными» патчами нашаманили, но несколько лет их не было.

Натрави профайлер и посмотри. Может просто реализация какой-нибудь часто используемой игрой функции тормозит.

А на 32-битной собрался?

Уже не помню. Вот сейчас, на 64 битной 17 федоре собрал src.rpm от 22 федоры - собралось, но заработало также плохо как и работал пакет собранный в 12 федоре. В настройках, кнопки «аудио» и «видео» серого цвета, неактивные, соответственно звук с видео глюкодромные и никак это не порегулировать. Как эмулятор работает в убунте-дебиане, хз - нет у меня их. Для сравнения, эмулятор первой соньки pcsxr на том же железе и ОС настраивается и работает хорошо.

В стритфаер 3 дреамкастловский пытался сыграть, когда-то на одноядерниках, под хрюшей, он был хорош.

Кстати, я вообще не понимаю, зачем Apple связалось с x86_32? Первые 64-битные интелы появились как минимум в 2004 году. Apple же объявили о планируемом переходе на Intel только в 2005. Можно было бы сразу на x86_64 переходить.

Так что они сами создали проблему и сами её «героически» решили.

Как только найдешь мне 64-битный Dothan или Core 1 - заходи.

И да, переходить с G5 на Pentium 4 (у которого эта 64-битность была) = менять шило на мыло. Ибо от ноутов на G5 отказались как раз по причине того, что печка и жрет электричество как не в себя.

Такой компании как Apple было по силам решить эту проблему, чтобы сейчас уже не городить костыли. Можно было бы рассмотреть несколько вариантов:

1) Пользоваться AMD

2) Отложить переход на пару месяцев, до выхода Core 2

3) Заставить производителей собирать программы одновременно под 32- и 64-битную архитектуру.

Даже если ничего не сделали тогда, то уже сейчас (прошло больше десяти лет) можно было бы полностью перейти на 64 бита. Как в своё время перешли с powerpc на x86.

А вам Apple, несмотря на полный контроль над всей инфраструктурой, предложила решение из разряда «костыль на костыле и костылём погоняет», а вы радуетесь.

пользоваться амуде

Охрененное решение. Пользоваться я им, конечно же, не буду.

И да, ты тред вообще читал? Речь как раз о том, что все собиралось аж под 4 архитектуры (ppc32, ppc64, x86, x86_64), и работало без траха с мультилибом и прочими костылями вроде тех, что у неготового для десктопа.

Если всё собиралось под x86-64, то нахрена сейчас им 32-битные системы?

Кто сказал «сейчас»? Макось 10.7.5 была выпущена в 2012 году, 10.8 была уже 64 bit only.