Comments 117
Помню читал про эту игру, что ее не добавили в Windows Vista, потому что не смогли скомпилировать на 64 битную версию. Но я не думал, что там настолько все сложно.
Даже банальный переход с 32 бит на 64 в рамках той же самой Intel-архитектуры (и той же самой ОС с теми же высокосовместимыми API) привёл к тому, что значительную часть плюсовых программ оказалось проще переписать заново, чем портировать.
Именно поэтому C++ начал с такой бешеной скоростью терять популярность сразу после появления мобильных платформ — вы поседеете писать такой код, который будет собираться и запускаться на них на всех. А потом появляется ещё одна новая платформа, например WebAssembly, и вновь ад портирования, потому что вот так сходу C++ программа под неё конечно же не соберётся.
Миллиарды строк на Коболе ждут своего нового железа. А за ними в очередь становятся мириады строк кода современного, ведь теперешнее железо тоже не вечно.
А в идеале — создать для каждого языка транслятор во что-то типа UML.
Возьмите для примера какой-нибудь AVX, для которого необходимо писать принципиально иной код, чем для скалярных платформ. Автовекторизация в компиляторах есть, но редко когда справится с кодом, не написанным специально под автовекторизацию.
Вы придумали LLVM. Какие-то вопросы кроссплатформенности решает, но тоже не серебряная пуля. Потому что языки программирования не только являются генератором исполнимого кода для процессоров, но и способом выражения математических зависимостей между абстракциями прикладной области, не имеющих прямого транзисторного воплощения. И процессоры, будучи даже тьюринг-полными, в реальности эквиваленты друг другу довольно условно - тут с памятью вот так работать, а тут вот так :). В общем, вопрос Универсального Физического Исполнителя Любых Абстрактных Алгоритмов до сих пор полностью не решён и, по-видимому, не решается в общем случае принципиально :).
но количество усилий, которые надо для этого прикладывать, вызывает оторопь.
Каких именно усилий?
После неизбежного процесса перехода на новый процессор/компилятор, где решается бОльшая часть проблем, обычно всё идёт достаточно легко. Но естественно проблемы в новом коде всё-таки иногда встречаются, из-за особенностей платформы, нарушения UB или более агрессивной оптимизации на каком-то компиляторе.
привёл к тому, что значительную часть плюсовых программ оказалось проще переписать заново, чем портировать.
Статистику бы посмотреть чтобы ваши утверждения проверить.
вы поседеете писать такой код, который будет собираться и запускаться на них на всех
Это ерунда. Достаточно использовать правильные типы (uint32_t, size_t и т.п.), не нарушать UB и всё будет везде собираться и запускаться. Ну почти :)
Каких именно усилий?
помню мы при порте игры с Win на Android месяц не могли поймать краш.
В итоге чисто случайно наткнулись на вот такой примерно код:
uint8_t ptr[ 64 ] = { 0 };
......
*(uint32_t* ) ptr[i] = foo();
опыта работы с ARM ни у кого не было и про строгое выравнивание адресов памяти по 4 мы понятия не имели..
а все остальное почему то легко прошло.
Не достаточно. Почитайте про integer promotion.
Этого достаточно для того, чтобы ваши достаточные условия были нереализуемы на практике.
С какой это стати?
Расскажите мне ещё как поддерживать «нереализуемые на практике» мультиплатформенные проекты на C++ ;-)
Занимаюсь этим последние 20 лет. В пике было 5 процессорных архитектур.
Я только один UB осознанно игнорирую — это сдвиг отрицательных чисел вправо.
Никто его не ломает и ломать не будет. Так что «это другое»(с)
С mmap и прочим тут всё весело. Формально оно UB, но можно доказать что на любой физической машине, где соблюдается подразумеваемый ABI, код будет работать корректно… при условии что компилятор не знает что делает функция mmap.
Кстати, всегда было интерестно, а что именно нужно сделать, чтобы не было UB в примере с интом. Если не сложно, можете рассказать?
Сpp прекрасный кроссплатформенный язык. Проблема не в языке. А в конкретной реализации на нем. Даже в этом примере - не смогли портировать потому что система расчета коллизий была жестко завязана на 32х битную архитектуру, и переписывание заняло бы много времени.
Опять возвращаемся к мантре "язык хороший, люди плохие". Ну сори, люди такие какие они есть и сделать с ними ничего нельзя. Нельзя "просто быть внимательным" и "просто не нарушать стандарт" — хотя бы потому, что авторы самого стандарта его целиком не знают. Помню прикол, когда на конференции вместе как раз с членами комитета по сипипи задали вопрос что какой результат будет при компиляции некоторого кода. Надо ли говорить, что мнения зала разделились?.. И это члены комитеты, что уж говорить про простых смертных.
Вы еще не учитываете, что игра изначально делалась для слабых компьютеров и вполне возможно, что там использовались оптимизации вычислений, что-то вроде Камаковского Fast inverse square root - Wikipedia
edit: А вот кстати нашёл:
www.youtube.com/watch?v=3EPTfOTC4Jw
Itanium - это вообще другая архитектура. VLIW, работающая на иных принципах. Помню разработчики под SAP очень нахваливали за быстродействие именно системы на Inanium
Продвигаемый сейчас Эльбрус - это тоже VLIW процессор
www.youtube.com/watch?v=3EPTfOTC4Jw&t=771s
Но я не думал, что там настолько все сложно.Там настолько сложно, что Чен и Пламмер, в своё время, даже не нашли код, отвечающий за обработку коллизий.
nobody at Microsoft ever understood how the code worked (much less still understood it), and that most of the code was completely uncommented, we simply couldn’t figure out why the collision detector was not working. Heck, we couldn’t even find the collision detector!devblogs.microsoft.com/oldnewthing/20121218-00/?p=5803
> эти чипы требовали, чтобы данные находились в 32-битных границах. В архитектуре x86 ценился каждый бит, поэтому большая часть кода для x86 плотно упаковывала переменные в границы байта
Эти чипы требовали выравнивания данных по 32-битным границам (4 байта). В х86 такого требования нет, поэтому возможно выравнивание по 8-битным границам (каждого байта).
Всё-таки для технических переводов надо иметь хотя-бы минимальные представления о чём идёт речь.
Еще могли быть хаки, завязанные на длинах указателей (инициализация указателей, присваивание и обнуление структур, содержащих указатели, работа с массивами структур). Или привязка к тому, что в старом abi инициализируются 4 байта у возвращающейся по ссылке области памяти, а при переносе в 64-битную архитектуру для совместимости оставили инициализацию только этих нижних 4 байт, а в верхних - мусор. Также могут мешать оставленные в коде UB, когда, например, компилятор по своему усмотрению (в зависимости от своей версии и от целевого CPU) может вставить vzeroupper, а может и не вставить, и подобного много. Еще могут боком вылезать bit-twiddling хаки с ротацией битов, которые обычно завязаны на битность платформы.
Насколько я знаю, при установке новой копии 64-битной Windows все двоичные файлы в ней являются 64-битными и в ней нет ничего 32-битного
Даже в свежей установке windows присутствует папка Program Files (x86), предназначенная для 32 битных программ, и в этой папке есть несколько папок со словом microsoft в названии, в одной из них, например, браузер edge, в другой internet explorer, так что нельзя сказать, что windows 64 бит поставляется совсем без 32 битных приложений.
Count of sections 4 │ Machine Intel386
Symbol table 00000000[00000000] │ Tue Jul 14 03:12:29 2009
Size of optional header 00E0 │ Magic optional header 010B
Linker version 9.00 │ OS version 6.01
Image version 6.01 │ Subsystem version 6.01
Entry point 00001600 │ Size of code 00001000
Size of init data 00001400 │ Size of uninit data 00000000
Size of image 00005000 │ Size of header 00000400
Base of code 00001000 │ Base of data 00002000
Image base 01000000 │ Subsystem GUI
Section alignment 00001000 │ File alignment 00000200
Stack 00040000/00002000 │ Heap 00100000/00001000
Checksum 00011963 │ Number of dirs 16
У меня ссылка на браузер Microsoft Edge из меню Пуск ведет на "C:\Program Files (x86)\Microsoft\Edge\Application"
это не значит, что он x86.
chrome для amd64 тоже по-умолчанию зачем-то туда ставится.
Видимо, путь в инсталляторе захардкодили.
Он еще и в профиль ставится, где постоянных исполняемых файлов по-хорошему вообще быть не должно.
А где же тогда должны быть исполняемые файлы конкретного пользователя (который не обязан быть админом и иметь право писать в Program Files)? Для этого в локальном профиле есть стандартная папка %LOCALAPPDATA%\Programs
В наши дни и так на компьютерах по 5 версий Chromium-движка в виде Electron раскидано, не хватало ещё чтоб они у каждого пользователя были свои, при этом одинаковые…
Если юзер не админ, то значит ему не дано право устанавливать софт. А установка в профиль -- это обход корпоративного запрета.
Ну корпорация корпорации рознь, не везде юзерам запрещено ставить софт. Кому надо - настраивают это через групповые политики, но само отсутствие админских прав такого запрета не подразумевает. В конце концов, ничто не помешает пользователю просто скопировать файлы программы в Мои документы.
Вот только хром ставится в %LocalAppData%\Google, а это немножко другое.
Странно, проверил на компе и ноуте - и там, и там Хром стоит в C:\Program Files (x86)\Google, и я не помню, чтобы делал для этого какие-то дополнительные телодвижения при установке. Причем на ноуте я весь софт ставлю на D: - то есть Хром действительно не дал выбрать директорию установки, но установился при этом не в профиль.
Исполняемые файлы должны быть там, куда обычным пользователям писать запрещено. Иначе, привет малварь.
Если не ошибаюсь, UWP приложения из winstore ставятся для каждого пользователя в windowsapps, которая расположена в program files.
Еще раз: по умолчанию нет запрета обычным пользователям ставить софт, поэтому раньше он ставился куда попало, но начиная с Windows 7 появились новые known folders: FOLDERID_UserProgramFiles (%LOCALAPPDATA%\Programs) и FOLDERID_UserProgramFilesCommon (%LOCALAPPDATA%\Programs\Common).
UWP-приложения ставятся службой магазина, которая запущена с правами системы и может писать в Program Files.
Еще раз: по умолчанию нет запрета обычным пользователям ставить софт
по-умолчанию, нет. но лучше бы он был - в чем смысл устраивать проходной двор из системы - хз.
UWP-приложения ставятся службой магазина, которая запущена с правами системы и может писать в Program Files.
да, но приложения при этом устанавливаются для каждого пользователя, при этом не нужно устраивать проходной двор в каталоге пользователя.
Что плохого в том, чтобы повысить безопасность, ограничив список запускаемого ПО?
Не нужен подъем прав до администратора, чтобы туда писать ;)
Мне кажется, что такую древность мелкософт мог бы и в опенсорс выложить, нашлись бы энтузиасты, которые бы портировали игрульку на 64 бита
Ну да, лицуха это позволяет, ага. Написано же - это чужой код, который МС сама купила, скорее всего, она не имеет права его выкладывать, максимум, так это наверно звуковой движок, хотя и про него написано, что его он взял с порта игры atari, где, скорее всего, свои лицензии.
Так что увы и ах, пусть лучше код winXP выложат
На движок antari он просто посмотрел, а свой написал с нуля. Это как требовать от Линуса Торвальдса доказательства прав на minix
и они такие "ребята... тут такое дело.... мы его тоже купили"
пусть лучше код winXP выложат
А зачем вам исходники Windows XP? Что вы будете с ними делать? Если просто полюбопытствовать что там, да как — в сети гуляет утекший код. А если сообществом допиливать её до юзабельности на современном железе, то не факт что найдутся люди способные выполнить такой титанический труд. ReactOS вот например до сих пор не смогли запилить в своё ядро WDDM, и как следствие поддержку современных видеодрайверов, а ведь в случае с ХР придётся делать то же самое… Таким образом, если уж просить исходники винды, то как минимум семерки — её сможет поддерживать на плаву даже не очень большое сообщество особо не напрягаясь.
Ну такая-ж байда с исходниками OS/2. Было две петиции к IBM, от комьюнити, с просьбой открыть сорцы. На вторую петицию МежДелМаш отреагировал, со словами, мы-бы и открыли, но там куча кода сторонних компаний, включая Microsoft. Хотя вот код микроядерной OS/2 Warp Connect PowerPC edition, они могли-бы и открыть. И это было бы даже более интересно, чем код классической OS/2.
Да все еще проще - почему нельзя просто написать аналог "с нуля"? Там не то чтобы Халф-Лайф или Квейк чтоб исходники просить, игровой программист такое сделает за пару вечеров, у меня, наверное, пара недель уйдет - я игры не пишу.
И сделать с другой графикой, звуком и названием чтобы не было проблем. И о таком опен-сорс проекте в результате никто и не узнает. А для мелкомягких писать такую игру с нуля просто не за чем.
А для мелкомягких писать такую игру с нуля просто не за чем.
https://www.microsoft.com/en-us/p/pinball-fx/c4nh02m9x3mm
https://www.microsoft.com/en-us/p/pinball-fx3/9pckbvf3p67h
https://www.microsoft.com/en-us/p/pinball-fx2-vr/9nzqbdd43pkc
Update: Hey everybody asking that the source code be released: The source code was licensed from another company. If you want the source code, you have to go ask them.devblogs.microsoft.com/oldnewthing/20121218-00/?p=5803
Нежелание компании тратить время и ресурсы на портирование стороннего приложения, ставшего привычным инструментом для многих пользователей, печальна но хотя бы понятна. А чем к примеру помешал сборник Clipart, отсутствующий в 64-битной версии? Прямо дискриминация пользователей по признаку разрядности какая-то.
А в чём преимущество MSEquation по сравнению с современным редактором?
Как по мне, так наоборот, с ним надо было зубрить хоткеи, а в современном достаточно галочкой в настройках включить ввод на ЛаТеХе и писать им не задумываясь.
Хотя конвертация из Equation в современный вид бы не помешала, а то они все в картинки в старых документах попревращались.
И это тоже. Вот к примеру человек диссертацию неспешно колупает. Наколупал до состояния, когда 32-разрядный Word при попытках редактирования документа падает. Выход видится в использовании 64-битной версии. А в ней отсутствует редактор, ибо не осилили портировать чужой древний код к релизу (джентельмены выпустили бы патч позднее, хотя скорее десятилетием ранее написали бы свой совместимый). Переход на новую версию редактора как минимум порушит форматирование документа, иногда критично, а исходные изображения могли и не сохраниться.
Вспомнился случай из девяностых, когда после нескольких десятков страниц в общем несложного документа пришлось бежать в магазин докупать модули памяти simm — тогда помогло, кстати.
А ЛаТеХ — это конечно правильно, Word он не для опусов.
Нежелание компании тратить время и ресурсы на портирование стороннего приложенияИсходный код Equation с большой долей вероятности потерян и его невозможно портировать.
О чем страдания? Пинбол от МС в сторе есть. Заметно донатный, но есть.
Изначально это была отдельная игра Full Tilt! Pinball, выпущенная Maxis в 1995 году.
Full Tilt! Pinball вышла 31 октября 1995.
Microsoft Plus! for Windows 95, и в составе неё Space Cadet Pinball, вышла 24 августа 1995.
Судя по тексту, Dave Plummer впервые увидел эту игру уже после выхода обеих версий, и искренне заблуждается по поводу того, которая из них была «изначальной».
Развлечения моего детства. Правда уже не помню, в какой момент там появлялся пинбол.
Ищете немного не там, игры надо искать, или games - хотя я всегда задавался вопросом, почему этот раздел не в развлечениях?..
Я же в свое время долго думал, какое же такое "развлечение" может дать регулятор громкости.
Долго думал...
Представим, что у вас внешние колонки. Тогда сразу понятно, зачем нужно делать потише при "развлечениях"
Пинбол был в папке Игры, а не в Развлечениях.
[Перевод]
Стилистика перевода такова, что эта плашка угадывается на раз.
К тому же, если бы 32-битный файл выпустили с 64-битной Windows, а пользователь отключил бы слой WoW64, то он бы не запустился.
Вот бы была такая штука, чтобы когда ставить что-то, то все нужно для работы тоже ставилось.
Такая штука называется репозиторий в Linux.
Что-то ставишь, зависимости сами подтягиваются.
Ну, например дотнет сейчас 10ка определяет сама и автоматически предлагает поставить его. Правда остальное(по типу visual c++) вроде самому доставлять нужно.
К слову, на GitHub лежит декомпилированная версия этой игры
https://github.com/k4zmu2a/SpaceCadetPinball
On 64-bit bug that killed the game:
I did not find it, decompiled game worked in x64 mode on the first try.
It was either lost in decompilation or introduced in x64 port/not present in x86 build.
Based on public description of the bug (no ball collision), I guess that the bug was inTEdgeManager::TestGridBox
Ну вот :-(
А такой вызов вырисовывался к концу прочтения статьи пойти и разреверсить игру. Все уже украдено до нас...
А по итогу не вполне ясно, в чём проблема. Вот есть инструкция по установке того самого пинбола в Windows 10. И он прекрасно работает. В том числе и в Windows 11. И не испытывает никаких проблем из-за работы в 64-битной системе.
Реймонд Чен известный чел. Хороший у него был блог про Windows.
Это очень в духе Майкрософт того времени -- взять хорошую игру, криво портировать, уменьшив максимальное разрешение с 1024х768 до 640x480 и оставив одно поле из трёх (собственно, Space Cadet). И тем гордиться!
Кстати, в Вики чётко написано -- была потом 64-битная версия, а история про то, что там был неустранимый баг с отслеживанием касаний -- просто неправда.
Очень интересное получасовое видео про это можно увидеть тут, посмотрите с 13-й минуты, а потом с 20-й:
Реймонд Чен, как бы нам ни хотелось ему доверять, то ли просто нагнал, то ли ошибся.
А настоящая причина - бардак в Майкрософт, где фичи плохо переносили между ветвями разработки для разных платформ. И то, что в 640х480 он, очевидно был просто маленьким на современных экранах. А переделывать всё в нормальное разрешение они уже не могли.
Это очень в духе Майкрософт того времени — взять хорошую игру, криво портировать, уменьшив максимальное разрешение с 1024х768 до 640x480 и оставив одно поле из трёх (собственно, Space Cadet). И тем гордиться!
Всё было в точности наоборот: сначала вышел Space Cadet (с одним полем и низким разрешением), и лишь потом — благодаря «раскрутке» в составе Plus! — на Cinematronics обратила внимание Maxis, и они договорились о выпуске расширенной версии.
The look and feel of Full Tilt! Pinball and 3D Pinball are similar, with a few exceptions: The latter contains only the Space Cadet table and only supports 640×480-pixel resolution, while the former supports three different resolutions up to 1024×768 pixels.
Вот вам комментарий непосредственного разработчика игры:
Nice to see there's still interest in our little pinball game from the mid nineties. Cinematronics was founded by David Stafford, Mike Sandige and I in 1994, and Space Cadet was our first published game (Mike was the lead, I was the producer/designer, and a host of others did some coding on it including David, Danny, John Taylor, Jim Mischel and others). Mike is an excellent engineer, so I'd be surprised if his original code was unreadable.
The deal David did with Microsoft was non-exclusive. As Danny noted, we were more interested in the exposure and didn't see much revenue from it. However, it did lead to our relationship and eventual acquisition by Maxis. EA owns the code now, as part of Full Tilt (which included two other tables we built). The sequel, Full Tilt II, got a revamped physics engine designed by Mark Kness that solved the ball/flipper problem.
The code for the game is probably buried somewhere deep in the bowels of EA — I'd be surprised if they even knew where it was. Probably sitting in a cardboard box that hasn't been opened since 1997. Microsoft had rights to continue publishing Space Cadet in future operating systems, so I don't see why they wouldn't have the right to update the code to that end. I may have a copy of the contract still, no doubt also sitting in a box that hasn't been opened since 1997.
Ещё раз: Maxis увидела игру после того, как она была включена в состав Plus!, и выпустила её после выхода Plus!
Самое смешное, что, хотя и писали по одной и подробнейшей white paper (то бишь по полной спецификации, созданной на основе "десктопной" версии), баги во всех трех реализациях были разные ;)
1) с чего бы им быть одинаковыми, если это не баги самой спецификации?
2) не знаю что там с xbox (вообще не помню там Silverlight), но вебовый/десктопный SL мало что общего имеет с телефонным. Если там была одна спека, то только на то, как Xaml с объектами визуального дерева соотносится.
1) Если разные люди действуя по одной и той же инструкции совершают одни и те же ошибки, это означает, что ошибка в инструкции. Странно ожидать, что у такой технически сложной вещи как SDK не будет багов, или то, что они будут разные в разных реализациях
2) У мобильных приложений и приложений для браузера разное почти всё, начиная от жизненного цикла и навигации, заканчивая доступными ресурсами и интеграциями в окружение. О какой одинаковой на 90% кодовой базе может идти речь? И тем более одной общей спецификации на оба SDK.
Из общего у Silverlight и Silverlight for Windows Phone только Xaml (который лишь довольно вольно описывает как объект языка должен быть представлен в xml-разметке) и программный интерфейс базовых UI-элементов.
Вы уж определитесь, вы имеете ввиду весь Silverlight или только медиаплеер? О каком именно десктопе вы говорите? Silverlight на дестктопе этот тот же самый Silverlight, что и в браузере. Но вы его так выделяете, будто говорите о чем-то другом. Опять же, если говорить о медиаплеере, то странно ставить в вину МС, что они делали две разные реализации для разных ОС (NT и CE).
Если вы писали код, который сам парсит HLS-плейлисты и скачивает с сервера байты, то это не удивительно, что вся его модификация это складывать байты в нужный буфер.
Ну SL не так долго просуществовал и помер вместе с Flash. Впрочем и хорошо даже. До сих пор из глубины времён достают диски с этим старым злом и вопросом "почему не работает". А если бы он существовал дольше интерпрайз успел бы наплодить кода.
Ещё Air доставляет. Вроде давно почил, а диски с приложениями на нём до сих пор есть, как и глюки с установкой.
Спасибо за материал, было интересно почитать
Разработчик пинбола для Windows XP рассказал о том, почему игра не появится в Windows 11