Привет, меня зовут Дейв Пламмер, я бывший разработчик операционных систем Microsoft. Я работал в компании ещё с эпохи MS-DOS и Windows 95. Так получилось, что мне довелось портировать игру Space Cadet, поставлявшуюся в комплекте с Windows. Сегодня я поговорил с разработчиком из Microsoft, который полностью удалил её из операционной системы, чтобы понять, почему это было сделано, а также чтобы оценить перспективы возврата игры. Также я покажу как запустить этот пинбол в Windows 10 и протестирую его работу в новой Windows 11, чтобы проверить, работает ли он спустя почти 25 лет. Сразу должен сказать, что я не занимался графикой, звуком, дизайном стола и разработкой геймплея, даже оригинальный код писал не я. Изначально это была отдельная игра Full Tilt! Pinball, выпущенная Maxis в 1995 году. Я могу лишь похвастаться тем, что взял относительно малоизвестную игру и портировал её на платформу, получившую больше миллиарда пользователей. Изначально я добровольно вызвался портировать игру на Windows NT 4.0.




В оригинальной игре Full Tilt! Pinball было три пинбольных стола: Space Cadet, Skullduggery и Dragon's Keep

Итак, это был 1995 год, я занимался портированием оболочки Win 95 в Windows NT. Оболочка включала в себя меню «Пуск», значки Рабочего стола, папки, общие элементы управления, общие диалоговые окна, в общем, основную часть UI, которую вы видите. Наш вице-президент Джим Олчин хотел включить в комплект Windows NT нечто, способное продемонстрировать новые графические и звуковые API, которые были впервые добавлены в ОС. Естественно, лучшим решением стала бы зрелищная игра с красивым звуком и интересным геймплеем. Это бы позволило избавить Windows NT от имиджа «скучной» системы. Как и пасьянс, эта игра стала почти неотъемлемым символом операционных систем, в комплекте которых она поставлялась. Однажды, когда я работал над портированием оболочки, ко мне подошёл мой руководитель и спросил, было бы мне интересно портировать игру в пинбол из Windows 95 в Windows NT. Задача кажется довольно простой, но я уже знал, что иногда перенос кода с 95 в NT может быть затруднительным. Это зависит от того, как он был написан и какие API использовал. Но я всё равно согласился, потому что любил игры и ухватился за возможность поработать над одной из них, да ещё и получать за это зарплату.


Моей основной специальностью в команде разработки оболочки было устранение проблем, связанных с RISC-процессором MIPS. Все мы совместно работали над тем, чтобы оболочка Win 95 заработала в NT, а я в частности занимался вопросами, возникавшими с MIPS. В те времена Windows работала на нескольких архитектурах, в том числе Intel, MIPS RISC, PowerPC и Alpha AXP. Пользователь мог приобрести версию Windows, скомпилированную для одной из этих архитектур. В нашей команде каждым процессором занимался свой специалист, решавший уникальные для платформы проблемы, и лично я работал с MIPS. На моём рабочем столе даже не было x86 и я запускал NT 3.51 на машине с MIPS, которую использовал как основной инструмент разработки. Я перешёл с 486 сразу на MIPS, полностью миновав этап работы с Intel Pentium. Чаще всего, если нам удавалось заставить работать код на одном из чипов RISC, он с большой вероятностью мог работать на любом из них, однако добиться этого было сложно, потому что эти чипы требовали, чтобы данные находились в 32-битных границах. В архитектуре x86 ценился каждый бит, поэтому большая часть кода для x86 плотно упаковывала переменные в границы байта, что не подходит для RISC.

Как бы то ни было, если бы я заставил игру работать на моей машине с MIPS, то она бы работала и на любой другой. Однако возникло несколько проблем — во-первых, код временами был весьма запутан. Код игры писали не наши разработчики, Microsoft просто купила его, и он был написан не в том стиле, к которому я привык. Отличие игры от операционной системы в том, что игра часто имеет одну версию, а для операционки выпускаются версия за версией, одна поверх другой. Многие игры пишутся по принципу «выпустил и забыл», а удобство поддержки кода и его читаемость не всегда так важны, как скорость работы и сроки выпуска проекта. Сильно поразил меня код звукового движка. Разумеется, я уверен, что с ним всё было в порядке, но написан он был на ассемблере x86. Однако код x86 очень мало бы помог мне при работе с MIPS, PowerPC и Alpha. Операционные системы наподобие Windows на 99,99% состоят из кода на C и C++, а ассемблер используется практически только в слое абстракции оборудования и, возможно, в загрузочном коде. В конце концов, если у вас есть полудюжина целевых процессорных архитектур, вы не будете вручную писать код на ассемблере для каждого из них, а захотите написать его один раз на C. Чтобы игра заработала, мне нужно было вырезать весь код на языке ассемблера и заменить собственным кодом на C, который затем будет скомпилирован в нативный код для каждой платформы.

По счастливому совпадению, за пару месяцев до этого я встречался с командой разработчиков сборников игр Microsoft Arcade, чтобы протестировать их реализацию старой игры Atari для аркадных автоматов под названием Tempest, по которой я был чемпионом мира. Я созвонился с этими ребятами и попросил прислать мне код демо, занимающийся звуком, чтобы заменить им код на ассемблере. Разобравшись с примером на C, я смог создать новый звуковой движок на C++, работавший на всех нужных процессорах. Вскоре после этого мне удалось заставить игру работать достаточно хорошо для того, чтобы можно было её тестировать. Честно говоря, было здорово получать зарплату за игру в пинбол, однако вскоре моя работа над ним закончилась и я приступил к другим проектам.


Tempest из сборника Microsoft Arcade

О пинболе я не вспоминал лет десять, пока не стал волонтёром в школе своего сына, где помогал маленьким детям с их компьютерной лабораторией. Я увидел ребёнка, который вместо того, чтобы выполнять задание, играл в пинбол. Он спросил меня, играл ли я когда-нибудь в него. Я ответил, что не только играл, но и работал над ним в Microsoft. До того момента ни одного ребёнка не впечатляло ничего из того, над чем работал я, потому что, будем откровенны, когда ты в детском саду, то диспетчер задач — это та штука, которую использует твой папа, чтобы починить компьютер, пока ты плачешь как младенец из-за того, что диск с игрой застрял в приводе. До семи-восьми лет дети обычно не пользуются диспетчером задач, поэтому обычно им было незнакомо почти всё то, над чем работал я. Но с пинболом совсем другая история — для многих детей пинбол стал игрой, в которую они играли, потому что это была единственная игра на компьютере. Конечно, это не значит, что игра хороша, просто она действительно была повсеместной, потому что поставлялась с Windows и её можно было найти на любом PC. Сегодня её уже нет, но если у вас есть копия игры, то она вполне запустится на современных системах.

Однако прежде давайте поговорим о причинах того, почему её удалили из Windows. Чтобы выяснить это, я обратился напрямую к Реймонду Чену — разработчику Microsoft, работавшему над всеми версиями Windows с середины 90-х. Оказалось, что точно так же, как мне поручили портировать игру с Windows 95 x86 на 32-битную Windows NT, кому-то нужно было дать задание портировать её с 32-битной Windows на 64-битную, и этим человеком был Реймонд. В своё время у меня было несколько недель для работы исключительно над пинболом, но для Реймонда это была лишь крошечная часть его работы по обновлению всей оболочки до 64 бит. Пинбол с трудом поддавался портированию — при сборке для 64-битной системы система распознавания коллизий работала некорректно — шарик проходил через препятствия, а не отталкивался от них. Очевидно, что в коде оригинала присутствовали какие-то трюки или зависимость от 32-битной компиляции. Реймонд позвал на помощь своего коллегу, но даже потратив достаточно времени, они не приблизились к решению. Когда стало ясно, что из-за пинбола они не уложатся в график работы, то они осознали, что единственный возможный вариант — избавиться от него. Так они и поступили: пинбол не совершил перехода с 32 на 64 бита. Но если никогда не существовало 64-битной версии пинбола, то как же его можно запустить в 64-битной Windows? Это возможно благодаря WoW64. Нативно Windows работает в 64 битах, а 32-битные приложения работают в специальном слое Windows on Windows, обеспечивающем совместимость с 32 битами. Это похоже на то, как мы запускали 16-битные приложения Windows 3.1 в 32-битной Windows, только на следующем логическом этапе. Насколько я знаю, при установке новой копии 64-битной Windows все двоичные файлы в ней являются 64-битными и в ней нет ничего 32-битного, поэтому подсистеме WoW64 запускаться не нужно. То есть она не занимает время при запуске и не потребляет ресурсов, пока не запущены 32-битные приложения. Однако подсистеме WoW64 требуется загрузка, для чего нужны время и ресурсы. Кто-то может возразить, что пинбол не загружается при запуске, поэтому это не важно. Но всё равно странно и непрофессионально было бы выпускать с Windows единственный 32-битный двоичный файл. К тому же, если бы 32-битный файл выпустили с 64-битной Windows, а пользователь отключил бы слой WoW64, то он бы не запустился. Поэтому единственным реальным решением стало бы вложение времени в полное решение проблемы, что, вероятно, не стоило усилий. Во-первых, это древняя игра, и хотя у многих людей она вызывает ностальгию, мне не кажется, что более молодые пользователи ею очарованы. К тому же по сравнению с Windows 11 она графически устарела — нельзя выпускать игру в том же виде, нужно потратиться не только на отладку и кодинг, но и на визуальную смену стиля и графики. К тому же необходимо добавить изменение размеров и масштаба, которые отсутствовали в оригинале.


Автор статьи и Реймонд Чен

Ещё один аргумент против портирования — старую игру по-прежнему можно запускать, хотя есть и юридические тонкости. Я не юрист, но мне кажется, что если у вас есть лицензионные копии Windows XP и Windows 10, то вы можете запустить компонент XP в Win 10, но, может быть, в лицензии чётко говорится, что они ни в коем случае не разделимы. Если у вас есть соответствующая лицензия, то двоичный файл можно найти и онлайн, поэтому откапывать старый CD с Windows XP необязательно. Но имейте в виду, что все найденные мной файлы не подписаны, поэтому могут кишеть троянами. Не стоит им доверять, если вы не можете выполнить двоичное сравнение или сравнить хэш md5. Я бы экспериментировал с ними на изолированной виртуальной машине. При запуске игры заставка открывается на весь экран, но сама игра занимает крошечную часть большого экрана монитора. Кто-то может сказать, что возможность беспроблемной работы старого приложения спустя 25 лет после его выпуска является свидетельством качества портирования. Другие могут сказать, что причиной этого является потрясающая обратная совместимость самой Windows. Как бы то ни было, Space Cadet по-прежнему запускается и в него можно играть в Windows 10.

Глубоко внутри ядра логики пинбола есть кусок кода, который, как мне кажется, никто не понимает полностью. Ну, может быть, его понимает Реймонд, но я точно в нём не разобрался. Он называется стейт-машиной и он почти полностью незадокументирован. Каждый раз, когда код проходит через него, состояние машины изменяется, и это состояние отслеживается в состоянии разбросанных по программе переменных, поэтому очень сложно разобраться, что происходит, но всё работает.

Дополнение: в игре есть режим суперпользователя: обычно в мире систем мы такого не делаем, поэтому пинбол — практически единственный пример такой программы в Windows. Он не делает игрока настоящим суперпользователем, а просто даёт ему новые возможности в игре. Для активации режима начните новую игру, дождитесь падения шарика и наберите на клавиатуре hidden test. После этого вы сможете управлять физикой шарика при помощи мыши и перетаскивать его по полю. Так же есть команды, дающие игроку дополнительные шарики, повышающие его в звании и добавляющие в таблицу рекордов.

Комментарии (115)


  1. v1000
    30.09.2021 09:39
    +9

    Помню читал про эту игру, что ее не добавили в Windows Vista, потому что не смогли скомпилировать на 64 битную версию. Но я не думал, что там настолько все сложно.


    1. Alexey2005
      30.09.2021 17:04
      +21

      А всё потому, что C++, вопреки расхожему мнению, ни разу не кроссплатформенный. Да, на этом языке можно писать кроссплатформенный код, но количество усилий, которые надо для этого прикладывать, вызывает оторопь.
      Даже банальный переход с 32 бит на 64 в рамках той же самой Intel-архитектуры (и той же самой ОС с теми же высокосовместимыми API) привёл к тому, что значительную часть плюсовых программ оказалось проще переписать заново, чем портировать.
      Именно поэтому C++ начал с такой бешеной скоростью терять популярность сразу после появления мобильных платформ — вы поседеете писать такой код, который будет собираться и запускаться на них на всех. А потом появляется ещё одна новая платформа, например WebAssembly, и вновь ад портирования, потому что вот так сходу C++ программа под неё конечно же не соберётся.


      1. quwy
        30.09.2021 22:18
        +3

        Любой нейтивный язык, который палкой не отгоняет программиста от аппаратной платформы, неизбежно будет таким. Причем виртуалка WebAssembly с точки зрения языка -- тоже "аппаратная" платформа.

        Ну и человеческий фактор, конечно. Очень часто программисты забывают, например, что размерность привычных типов данных на другом железе внезапно может оказаться иной.

        А C++ начал терять популярность, потому что после появления действительно массовых мобильных платформ прошли годы, пока под них стало возможно писать на нем код.


        1. drWhy
          01.10.2021 11:28
          -1

          Есть же другая возможность — вместо создания новых языков под новое железо/ОС адаптировать новые платформы под привычный язык — создавать трансляторы, эмуляторы, либо вообще использовать морфинговые процессоры типа Crusoe.
          Миллиарды строк на Коболе ждут своего нового железа. А за ними в очередь становятся мириады строк кода современного, ведь теперешнее железо тоже не вечно.
          А в идеале — создать для каждого языка транслятор во что-то типа UML.


          1. tyomitch
            01.10.2021 12:09
            +2

            Какой смысл создавать новую платформу, чьи возможности будут ограничены старым языком?
            Возьмите для примера какой-нибудь AVX, для которого необходимо писать принципиально иной код, чем для скалярных платформ. Автовекторизация в компиляторах есть, но редко когда справится с кодом, не написанным специально под автовекторизацию.


            1. drWhy
              01.10.2021 12:18

              К примеру для замены мейнфреймов, чей ресурс исчерпан, без необходимости поиска программистов на древнем языке для рефакторинга пока востребованных приложений. Сколько существует платформ для запуска Doom?


          1. napa3um
            01.10.2021 22:16

            Вы придумали LLVM. Какие-то вопросы кроссплатформенности решает, но тоже не серебряная пуля. Потому что языки программирования не только являются генератором исполнимого кода для процессоров, но и способом выражения математических зависимостей между абстракциями прикладной области, не имеющих прямого транзисторного воплощения. И процессоры, будучи даже тьюринг-полными, в реальности эквиваленты друг другу довольно условно - тут с памятью вот так работать, а тут вот так :). В общем, вопрос Универсального Физического Исполнителя Любых Абстрактных Алгоритмов до сих пор полностью не решён и, по-видимому, не решается в общем случае принципиально :).


      1. beeruser
        01.10.2021 03:24
        -2

        но количество усилий, которые надо для этого прикладывать, вызывает оторопь.

        Каких именно усилий?
        После неизбежного процесса перехода на новый процессор/компилятор, где решается бОльшая часть проблем, обычно всё идёт достаточно легко. Но естественно проблемы в новом коде всё-таки иногда встречаются, из-за особенностей платформы, нарушения UB или более агрессивной оптимизации на каком-то компиляторе.

        привёл к тому, что значительную часть плюсовых программ оказалось проще переписать заново, чем портировать.

        Статистику бы посмотреть чтобы ваши утверждения проверить.

        вы поседеете писать такой код, который будет собираться и запускаться на них на всех

        Это ерунда. Достаточно использовать правильные типы (uint32_t, size_t и т.п.), не нарушать UB и всё будет везде собираться и запускаться. Ну почти :)


        1. thecove
          01.10.2021 05:20
          +1

          Каких именно усилий?

          помню мы при порте игры с Win на Android месяц не могли поймать краш.

          В итоге чисто случайно наткнулись на вот такой примерно код:

          uint8_t ptr[ 64 ] = { 0 };

          ......

          *(uint32_t* ) ptr[i] = foo();

          опыта работы с ARM ни у кого не было и про строгое выравнивание адресов памяти по 4 мы понятия не имели..

          а все остальное почему то легко прошло.


          1. wataru
            01.10.2021 17:26

            Достаточно… не нарушать UB

            uint8_t ptr[ 64 ] = { 0 };
            *(uint32_t* ) ptr[i] = foo();```
            
            Теоретически, ваш код мог сломаться при изменении флагов компиляции или даже при обновлении версии компилятора.


        1. DungeonLords
          01.10.2021 11:18

          Не достаточно. Почитайте про integer promotion.


          1. beeruser
            03.10.2021 02:17

            >> Почитайте про integer promotion
            И что с ним не так?

            Смысл написанного мною в том, что как только вы портируете проект, поддерживать его работоспособность не стоит никаких больших усилий и уж совершенно точно седеть там не от чего.


        1. 0xd34df00d
          04.10.2021 05:10
          +4

          не нарушать UB

          Этого достаточно для того, чтобы ваши достаточные условия были нереализуемы на практике.


          1. beeruser
            04.10.2021 10:04
            -1

            Этого достаточно для того, чтобы ваши достаточные условия были нереализуемы на практике.

            С какой это стати?
            Расскажите мне ещё как поддерживать «нереализуемые на практике» мультиплатформенные проекты на C++ ;-)
            Занимаюсь этим последние 20 лет. В пике было 5 процессорных архитектур.

            Я только один UB осознанно игнорирую — это сдвиг отрицательных чисел вправо.
            Никто его не ломает и ломать не будет. Так что «это другое»(с)


            1. 0xd34df00d
              04.10.2021 18:26
              +4

              Потому что UB не ограничивается деталями реализации интов на разных платформах, и на практике оно есть в любом нетривиальном коде (даже если вы пишете его под одну платформу).


              Например, даже сформировать указатель больше чем на один элемент за последним элементом массива (а не обращаться к нему) — UB. То есть, написать


              int arr[5];
              arr + 6;

              — UB, без всяких разыменований. Да, компиляторы этим не пользуются, функцию на один большой nop они не заменяет, но ваше условие «не нарушать UB» перестаёт выполняться.


              Или, например, до C++20 для того, чтобы обращаться к mmapнутому (выровненному, естественно, и так далее) куску памяти как к инту, нужно было нетривиально приседать. Просто написать


              auto mem = mmap(...);
              int& val = *static_cast<int*>(mem);

              недостаточно.


              1. mayorovp
                10.10.2021 00:02

                С mmap и прочим тут всё весело. Формально оно UB, но можно доказать что на любой физической машине, где соблюдается подразумеваемый ABI, код будет работать корректно… при условии что компилятор не знает что делает функция mmap.


                1. 0xd34df00d
                  11.10.2021 01:34
                  +1

                  Тут вопрос в том, что такое подразумеваемое ABI.


                  Если ваша реализация при начале лайфтайма объекта выставляет где-нибудь флаг, а потом при обращении к объекту его проверяет (и делает что-нибудь нехорошее, если он не выставлен), то она будет вполне соответствовать стандарту, и этот код сломается.


                  1. mayorovp
                    11.10.2021 10:50

                    Стандарту-то она соответствовать будет, но системному ABI — нет (если только не выдумать особую ОС специально для победы в споре).


                    Иными словами, приведённый вами код работает корректно на Linux, но при этом не является переносимым (что, в общем-то, очевидно).


                    1. 0xd34df00d
                      11.10.2021 19:20
                      +1

                      Да, работать он будет, и достаточно дружественный к человеку компилятор этот код не сломает. Но вот утверждение о «писать без UB легко и просто» уже ломается.


                      А характеризовать разные UB по их опасности — скользкая дорожка. Знаком с несколькими людьми, которые считали, что проверка this на nullptr и вызов невиртуальных функций, не обращающихся к полям данных в этом случае, на нулевом указателе — это норма, однако ж компиляторы это недавно стали не любить.


              1. cpud36
                10.10.2021 22:16

                Кстати, всегда было интерестно, а что именно нужно сделать, чтобы не было UB в примере с интом. Если не сложно, можете рассказать?


                1. 0xd34df00d
                  11.10.2021 01:41
                  +1

                  Что-то вроде такого (пишу из головы, сорри за возможные опечатки, но идея, надеюсь, понятна):


                  auto mem = mmap(...);
                  
                  // сохраним старое значение
                  char buf[sizeof(int)];
                  memcpy(buf, mem, sizeof(int));
                  
                  // начнём лайфтайм инта в этой памяти
                  auto val = new (mem) int;
                  // кстати, mem походу после этого протухает, c.f. std::launder
                  
                  // восстановим старое значение, которое могло быть затёрто new
                  memcpy(val, buf, sizeof(int));


                  1. mayorovp
                    11.10.2021 10:51

                    О, гонка.


                    1. 0xd34df00d
                      11.10.2021 18:25
                      +1

                      Где?


      1. pprometey
        01.10.2021 05:25
        +1

        Сpp прекрасный кроссплатформенный язык. Проблема не в языке. А в конкретной реализации на нем. Даже в этом примере - не смогли портировать потому что система расчета коллизий была жестко завязана на 32х битную архитектуру, и переписывание заняло бы много времени.


        1. PsyHaSTe
          02.10.2021 21:03
          +6

          Опять возвращаемся к мантре "язык хороший, люди плохие". Ну сори, люди такие какие они есть и сделать с ними ничего нельзя. Нельзя "просто быть внимательным" и "просто не нарушать стандарт" — хотя бы потому, что авторы самого стандарта его целиком не знают. Помню прикол, когда на конференции вместе как раз с членами комитета по сипипи задали вопрос что какой результат будет при компиляции некоторого кода. Надо ли говорить, что мнения зала разделились?.. И это члены комитеты, что уж говорить про простых смертных.


      1. Xadok
        01.10.2021 11:24

        Проблема не в языке, он дает все инструменты писать полностью кросс-платформенный код (или почти полностью), другое дело что разработчики обычно не хотят этого делать и пишут не по стандарту


        1. drWhy
          01.10.2021 11:32
          +1

          Стандарты также преходящи.


        1. 0xd34df00d
          04.10.2021 05:13
          +3

          Разработчики не то что не хотят этого делать, а не могут этого делать, так как C++ — непознаваемый язык с фрактальной сложностью. По крайней мере, я по итогам лет так 18 написания кода на плюсах, из которых лет 13 — коммерческие, решил, что да ну нафиг, жизнь слишком коротка, чтобы зубрить Тору Стандарт и на каждую строчку кода ковырять, имею ли я право вот здесь сделать вот это вот, или это таки будет UB.


    1. Krypt
      30.09.2021 20:34
      +1

      Не могу найти с ходу видео, но вообще её таки портировали. (она появляется в нескольких редакциях Win XP 64). Единственная редакция, XP, где её нет — это версия для Itanium (IA-64, провалившаяся Интеловская попытка сделать x64, сейчас они используют архитектуру разработанную AMD). Похоже разработчик, писавший этот пост работал именно на Itanium -версии Win XP

      edit: А вот кстати нашёл:
      www.youtube.com/watch?v=3EPTfOTC4Jw


      1. tyomitch
        30.09.2021 20:38

        Даже если она есть в составе XP x64, это ещё не свидетельствует о том, что её портировали на x64. Возможно, использовали 32-битный билд, как и для нижеупомянутого winhlp32


        1. Krypt
          30.09.2021 20:43

          Там именно честная x64 версия, если верить автору видео и его декомпилятору


      1. HerrJohan
        30.09.2021 20:47
        +2

        Itanium - это вообще другая архитектура. VLIW, работающая на иных принципах. Помню разработчики под SAP очень нахваливали за быстродействие именно системы на Inanium
        Продвигаемый сейчас Эльбрус - это тоже VLIW процессор


        1. Krypt
          30.09.2021 20:56
          +1

          На самом деле не суть. Суть в том, что только в этой редакции XP нет Пинбола (причём он по ошибке включён в дистрибутив, и после ручной установки он работает нормально, если не считать проблем с графикой)
          www.youtube.com/watch?v=3EPTfOTC4Jw&t=771s


    1. dartraiden
      02.10.2021 00:01
      +1

      Но я не думал, что там настолько все сложно.
      Там настолько сложно, что Чен и Пламмер, в своё время, даже не нашли код, отвечающий за обработку коллизий.
      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


  1. atd
    30.09.2021 09:55
    +31

    > эти чипы требовали, чтобы данные находились в 32-битных границах. В архитектуре x86 ценился каждый бит, поэтому большая часть кода для x86 плотно упаковывала переменные в границы байта

    Эти чипы требовали выравнивания данных по 32-битным границам (4 байта). В х86 такого требования нет, поэтому возможно выравнивание по 8-битным границам (каждого байта).

    Всё-таки для технических переводов надо иметь хотя-бы минимальные представления о чём идёт речь.


    1. tbl
      30.09.2021 10:41
      +3

      Еще могли быть хаки, завязанные на длинах указателей (инициализация указателей, присваивание и обнуление структур, содержащих указатели, работа с массивами структур). Или привязка к тому, что в старом abi инициализируются 4 байта у возвращающейся по ссылке области памяти, а при переносе в 64-битную архитектуру для совместимости оставили инициализацию только этих нижних 4 байт, а в верхних - мусор. Также могут мешать оставленные в коде UB, когда, например, компилятор по своему усмотрению (в зависимости от своей версии и от целевого CPU) может вставить vzeroupper, а может и не вставить, и подобного много. Еще могут боком вылезать bit-twiddling хаки с ротацией битов, которые обычно завязаны на битность платформы.


  1. grokinn
    30.09.2021 10:12
    +4

    Насколько я знаю, при установке новой копии 64-битной Windows все двоичные файлы в ней являются 64-битными и в ней нет ничего 32-битного

    Даже в свежей установке windows присутствует папка Program Files (x86), предназначенная для 32 битных программ, и в этой папке есть несколько папок со словом microsoft в названии, в одной из них, например, браузер edge, в другой internet explorer, так что нельзя сказать, что windows 64 бит поставляется совсем без 32 битных приложений.


    1. nerudo
      30.09.2021 10:40
      +4

      Не надо даже так далеко ходить:

      C:\Windows\winhlp32.exe
      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


    1. ncr
      30.09.2021 11:10
      +3

      Они там не в качестве основного продукта, а для совместимости со сторонним 32-битным ПО, как и все содержимое windows\syswow64. Видимо, подразумевалось «все двоичные файлы, с которыми типичный пользователь взаимодействует через меню Пуск». Но причина достаточно натянута, да.


      1. grokinn
        30.09.2021 11:21

        У меня ссылка на браузер Microsoft Edge из меню Пуск ведет на "C:\Program Files (x86)\Microsoft\Edge\Application"


        1. fmj
          30.09.2021 11:30
          +3

          это не значит, что он x86.

          chrome для amd64 тоже по-умолчанию зачем-то туда ставится.


          1. me21
            30.09.2021 13:52

            Видимо, путь в инсталляторе захардкодили.


          1. quwy
            30.09.2021 22:29
            +3

            Он еще и в профиль ставится, где постоянных исполняемых файлов по-хорошему вообще быть не должно.

            Инсталлятор хрома -- отличный пример того, на что только не идут некоторые, чтобы втюхать свой софт каждому юзеру.


            1. SlimShaggy
              30.09.2021 23:06
              +2

              Он еще и в профиль ставится, где постоянных исполняемых файлов по-хорошему вообще быть не должно.

              А где же тогда должны быть исполняемые файлы конкретного пользователя (который не обязан быть админом и иметь право писать в Program Files)? Для этого в локальном профиле есть стандартная папка %LOCALAPPDATA%\Programs


              1. DirectoriX
                30.09.2021 23:56
                +4

                Нормальные инсталяторы имеют возможность указания пути установки. А чтоб установить Chrome в Program Files (что, вообще-то и надо всем делать (либо просить админа, если прав нет)) — надо качать другой установщик, ссылка на который идёт аж через страницу поддержки.
                В наши дни и так на компьютерах по 5 версий Chromium-движка в виде Electron раскидано, не хватало ещё чтоб они у каждого пользователя были свои, при этом одинаковые…


                1. knstqq
                  01.10.2021 12:07

                  так сейчас почти всегда 1 ноутбук = 1 пользователь. Случаи когда больше одного пользователя — скорее исключение (хоть и популярно, но много меньше)


              1. quwy
                01.10.2021 00:40
                +3

                который не обязан быть админом и иметь право писать в Program Files

                Если юзер не админ, то значит ему не дано право устанавливать софт. А установка в профиль -- это обход корпоративного запрета.

                Для этого в локальном профиле есть стандартная папка %LOCALAPPDATA%\Programs

                Вот только хром ставится в %LocalAppData%\Google, а это немножко другое.

                Запуск бинарников из подобных мест вообще должен быть запрещен, почти вся вирусня начинает свой путь именно из профиля.


                1. SlimShaggy
                  01.10.2021 00:58

                  Если юзер не админ, то значит ему не дано право устанавливать софт. А установка в профиль -- это обход корпоративного запрета.

                  Ну корпорация корпорации рознь, не везде юзерам запрещено ставить софт. Кому надо - настраивают это через групповые политики, но само отсутствие админских прав такого запрета не подразумевает. В конце концов, ничто не помешает пользователю просто скопировать файлы программы в Мои документы.

                  Вот только хром ставится в %LocalAppData%\Google, а это немножко другое.

                  Странно, проверил на компе и ноуте - и там, и там Хром стоит в C:\Program Files (x86)\Google, и я не помню, чтобы делал для этого какие-то дополнительные телодвижения при установке. Причем на ноуте я весь софт ставлю на D: - то есть Хром действительно не дал выбрать директорию установки, но установился при этом не в профиль.


                  1. Lirein
                    01.10.2021 06:25
                    +1

                    Политика AppLocker по умолчанию не даст этого сделать — запуск разрешен только группе BUILTIN\Administrators и Everyone из путей: С:\Windows, C:\Program Files, C:\Program Files (x86). По этому даже Portable программу с флешки запустить не получится. Доступ в Интернет может при этом контролироваться чтобы .msi и .exe скачать было нельзя.
                    Ну и зачастую в реальном энтерпрайзе ещё и DeviceLock/Kaspersky IS работают для блокировки не доверенных переносных устройств.


                  1. fmj
                    01.10.2021 11:15

                    Причем на ноуте я весь софт ставлю на D:

                    на том, смонтированный на букву d?

                    зачем? в чем плюсы?


                    1. SlimShaggy
                      01.10.2021 11:52
                      +1

                      Исторически сложилась у меня такая структура разделов.

                      C: (System), D: (Program), E: (Data)

                      Возможно, в какой-то книжке типа Фигурнова вычитал изначально, а потом привык)


              1. fmj
                01.10.2021 08:40
                +1

                Исполняемые файлы должны быть там, куда обычным пользователям писать запрещено. Иначе, привет малварь.

                Если не ошибаюсь, UWP приложения из winstore ставятся для каждого пользователя в windowsapps, которая расположена в program files.


                1. SlimShaggy
                  01.10.2021 09:03

                  Еще раз: по умолчанию нет запрета обычным пользователям ставить софт, поэтому раньше он ставился куда попало, но начиная с Windows 7 появились новые known folders: FOLDERID_UserProgramFiles (%LOCALAPPDATA%\Programs) и FOLDERID_UserProgramFilesCommon (%LOCALAPPDATA%\Programs\Common).

                  UWP-приложения ставятся службой магазина, которая запущена с правами системы и может писать в Program Files.


                  1. fmj
                    01.10.2021 09:24

                    Еще раз: по умолчанию нет запрета обычным пользователям ставить софт

                    по-умолчанию, нет. но лучше бы он был - в чем смысл устраивать проходной двор из системы - хз.

                    UWP-приложения ставятся службой магазина, которая запущена с правами системы и может писать в Program Files.

                    да, но приложения при этом устанавливаются для каждого пользователя, при этом не нужно устраивать проходной двор в каталоге пользователя.

                    Что плохого в том, чтобы повысить безопасность, ограничив список запускаемого ПО?


                    1. fmj
                      01.10.2021 11:18
                      +1

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


          1. yuryleb
            05.10.2021 13:44

            Не нужен подъем прав до администратора, чтобы туда писать ;)


            1. fmj
              05.10.2021 13:51

              Не нужен подъем прав до администратора, чтобы туда писать ;)

              куда? в /program files(x86) ?


  1. defecator
    30.09.2021 10:38
    +5

    Мне кажется, что такую древность мелкософт мог бы и в опенсорс выложить, нашлись бы энтузиасты, которые бы портировали игрульку на 64 бита


    1. Kuprijan
      30.09.2021 11:00
      +8

      Ну да, лицуха это позволяет, ага. Написано же - это чужой код, который МС сама купила, скорее всего, она не имеет права его выкладывать, максимум, так это наверно звуковой движок, хотя и про него написано, что его он взял с порта игры atari, где, скорее всего, свои лицензии.

      Так что увы и ах, пусть лучше код winXP выложат


      1. alx_mnzr
        30.09.2021 12:43

        На движок antari он просто посмотрел, а свой написал с нуля. Это как требовать от Линуса Торвальдса доказательства прав на minix


      1. burzooom
        30.09.2021 15:19

        и они такие "ребята... тут такое дело.... мы его тоже купили"


      1. RedCatX
        30.09.2021 20:32
        +3

        пусть лучше код winXP выложат

        А зачем вам исходники Windows XP? Что вы будете с ними делать? Если просто полюбопытствовать что там, да как — в сети гуляет утекший код. А если сообществом допиливать её до юзабельности на современном железе, то не факт что найдутся люди способные выполнить такой титанический труд. ReactOS вот например до сих пор не смогли запилить в своё ядро WDDM, и как следствие поддержку современных видеодрайверов, а ведь в случае с ХР придётся делать то же самое… Таким образом, если уж просить исходники винды, то как минимум семерки — её сможет поддерживать на плаву даже не очень большое сообщество особо не напрягаясь.


      1. Oxyd
        30.09.2021 23:06
        +1

        Ну такая-ж байда с исходниками OS/2. Было две петиции к IBM, от комьюнити, с просьбой открыть сорцы. На вторую петицию МежДелМаш отреагировал, со словами, мы-бы и открыли, но там куча кода сторонних компаний, включая Microsoft. Хотя вот код микроядерной OS/2 Warp Connect PowerPC edition, они могли-бы и открыть. И это было бы даже более интересно, чем код классической OS/2.


    1. Psionic
      30.09.2021 11:43
      +4

      Да все еще проще - почему нельзя просто написать аналог "с нуля"? Там не то чтобы Халф-Лайф или Квейк чтоб исходники просить, игровой программист такое сделает за пару вечеров, у меня, наверное, пара недель уйдет - я игры не пишу.


      1. DMGarikk
        30.09.2021 12:41
        +2

        и это будет аналог, а не оригинальная игра, с другой физикой как минимум


      1. alx_mnzr
        30.09.2021 12:45

        И сделать с другой графикой, звуком и названием чтобы не было проблем. И о таком опен-сорс проекте в результате никто и не узнает. А для мелкомягких писать такую игру с нуля просто не за чем.


        1. ad1Dima
          30.09.2021 13:45

          1. The_Kf
            30.09.2021 14:41

            Так это и не Microsoft


            1. ad1Dima
              01.10.2021 05:51
              +1

              Ну как, издатель - Microsoft Studios


              1. KvantVS
                05.10.2021 13:45

                wiki:

                Pinball FX is a pinball machine video game for the Xbox 360. It was developed by Zen Studios.


                1. ad1Dima
                  05.10.2021 15:04
                  +1

                  это как-то противоречит тому, что я написал?


    1. dartraiden
      02.10.2021 00:06

      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


  1. drWhy
    30.09.2021 11:03
    +4

    Видимо Microsoft Equation, потерянный при переходе на 64 бита, также был внедрён энтузиастом с целью избавить Microsoft Office от имиджа скучного приложения.
    Нежелание компании тратить время и ресурсы на портирование стороннего приложения, ставшего привычным инструментом для многих пользователей, печальна но хотя бы понятна. А чем к примеру помешал сборник Clipart, отсутствующий в 64-битной версии? Прямо дискриминация пользователей по признаку разрядности какая-то.


    1. vladkorotnev
      01.10.2021 09:06

      А в чём преимущество MSEquation по сравнению с современным редактором?


      Как по мне, так наоборот, с ним надо было зубрить хоткеи, а в современном достаточно галочкой в настройках включить ввод на ЛаТеХе и писать им не задумываясь.


      Хотя конвертация из Equation в современный вид бы не помешала, а то они все в картинки в старых документах попревращались.


      1. drWhy
        01.10.2021 11:52
        +1

        «Хотя конвертация из Equation в современный вид бы не помешала, а то они все в картинки в старых документах попревращались.»

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

        Вспомнился случай из девяностых, когда после нескольких десятков страниц в общем несложного документа пришлось бежать в магазин докупать модули памяти simm — тогда помогло, кстати.

        А ЛаТеХ — это конечно правильно, Word он не для опусов.


    1. dartraiden
      02.10.2021 00:11

      Нежелание компании тратить время и ресурсы на портирование стороннего приложения
      Исходный код Equation с большой долей вероятности потерян и его невозможно портировать.


      1. drWhy
        02.10.2021 22:27
        +1

        Это был исходно сторонний покупной компонент.


  1. ad1Dima
    30.09.2021 11:39
    -5

    О чем страдания? Пинбол от МС в сторе есть. Заметно донатный, но есть.


  1. tyomitch
    30.09.2021 11:59
    +3

    Изначально это была отдельная игра Full Tilt! Pinball, выпущенная Maxis в 1995 году.

    Full Tilt! Pinball вышла 31 октября 1995.
    Microsoft Plus! for Windows 95, и в составе неё Space Cadet Pinball, вышла 24 августа 1995.

    Судя по тексту, Dave Plummer впервые увидел эту игру уже после выхода обеих версий, и искренне заблуждается по поводу того, которая из них была «изначальной».


  1. DrMefistO
    30.09.2021 12:29
    +5

    Развлечения моего детства. Правда уже не помню, в какой момент там появлялся пинбол.


    1. Kuprijan
      30.09.2021 12:37
      +5

      Ищете немного не там, игры надо искать, или games - хотя я всегда задавался вопросом, почему этот раздел не в развлечениях?..


      1. PowerMetall
        01.10.2021 00:02
        +7

        Я же в свое время долго думал, какое же такое "развлечение" может дать регулятор громкости.

        Долго думал...


        1. drWhy
          01.10.2021 12:02
          +1

          Было же определённым этапом появление «мультимедийных» компьютеров, оснащённых звуковой картой и реже CD-ROM'ом. Возня с поиском, установкой и настройкой драйверов иногда доставляла головную боль (к примеру, часть драйверов была исключительно 16-битной). И бывало довольно обидно, когда к примеру собственно регулятор громкости sndvol.exe исчезал из системы из-за какого-нибудь конфликта, или просто обновления параметров CMOS, а с ним и звук, и вся «мультимедийность». Тогда «развлечения» возобновлялись.


        1. rinac
          05.10.2021 13:45

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


    1. Anterenoire
      05.10.2021 13:45

      Пинбол был в папке Игры, а не в Развлечениях.


  1. poige
    30.09.2021 13:43
    +1

    [Перевод]

    Стилистика перевода такова, что эта плашка угадывается на раз.


  1. homm
    30.09.2021 14:57
    +1

    К тому же, если бы 32-битный файл выпустили с 64-битной Windows, а пользователь отключил бы слой WoW64, то он бы не запустился.

    Вот бы была такая штука, чтобы когда ставить что-то, то все нужно для работы тоже ставилось.


    1. hzs
      01.10.2021 08:34
      +1

      Такая штука называется репозиторий в Linux.
      Что-то ставишь, зависимости сами подтягиваются.


      1. ad1Dima
        01.10.2021 09:15
        +1

        А если пользователь потом удалит зависимости? (как аналог "пользователь отключил слой WoW64")


        1. homm
          01.10.2021 13:39
          +1

          Вот бы можно было спросить пользователя, что удаляя пакет что-то другое перестанет работать и как бы он хотел в этом случае поступить…


          1. ad1Dima
            01.10.2021 14:27
            +1

            Или просто спрятать эту настройку там, где пользователь её не найдёт... oh, wait...


    1. victoriously
      01.10.2021 14:26

      Ну, например дотнет сейчас 10ка определяет сама и автоматически предлагает поставить его. Правда остальное(по типу visual c++) вроде самому доставлять нужно.


  1. ambassador0
    30.09.2021 16:07
    +4

    К слову, на GitHub лежит декомпилированная версия этой игры
    https://github.com/k4zmu2a/SpaceCadetPinball


    1. gxcreator
      30.09.2021 17:12
      +3

      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 in TEdgeManager::TestGridBox


      1. a1batross
        01.10.2021 15:41

        Да, он сделал то, что не сделали Microsoft.

        И выкатили длинное объяснение почему им просто влом. :)


      1. Soukhinov
        05.10.2021 13:45
        +4

        Классно звучит: «Баг потерялся при декомпиляции».


  1. Darkhon
    30.09.2021 20:25

    А по итогу не вполне ясно, в чём проблема. Вот есть инструкция по установке того самого пинбола в Windows 10. И он прекрасно работает. В том числе и в Windows 11. И не испытывает никаких проблем из-за работы в 64-битной системе.


    1. DrMefistO
      30.09.2021 23:33
      +2

      Вы читали статью? Написано же: 64-битный билд, а не система был проблемой. А тащить один 32-битный бинарь в систему тогда не хотели.


  1. enabokov
    01.10.2021 00:29

    Реймонд Чен известный чел. Хороший у него был блог про Windows.


    1. tyomitch
      01.10.2021 09:41
      +1

      Почему «был»? devblogs.microsoft.com/oldnewthing


      1. 0xd34df00d
        04.10.2021 05:33
        +1

        Потому что теперь это блог про плюсовые корутины под WinRT.


  1. mSnus
    01.10.2021 03:23
    +2

    Это очень в духе Майкрософт того времени -- взять хорошую игру, криво портировать, уменьшив максимальное разрешение с 1024х768 до 640x480 и оставив одно поле из трёх (собственно, Space Cadet). И тем гордиться!

    Оригинал и Windows-версия
    Оригинал и Windows-версия

    Кстати, в Вики чётко написано -- была потом 64-битная версия, а история про то, что там был неустранимый баг с отслеживанием касаний -- просто неправда.

    Очень интересное получасовое видео про это можно увидеть тут, посмотрите с 13-й минуты, а потом с 20-й:

    Реймонд Чен, как бы нам ни хотелось ему доверять, то ли просто нагнал, то ли ошибся.

    А настоящая причина - бардак в Майкрософт, где фичи плохо переносили между ветвями разработки для разных платформ. И то, что в 640х480 он, очевидно был просто маленьким на современных экранах. А переделывать всё в нормальное разрешение они уже не могли.


    1. tyomitch
      01.10.2021 09:46

      Это очень в духе Майкрософт того времени — взять хорошую игру, криво портировать, уменьшив максимальное разрешение с 1024х768 до 640x480 и оставив одно поле из трёх (собственно, Space Cadet). И тем гордиться!

      Всё было в точности наоборот: сначала вышел Space Cadet (с одним полем и низким разрешением), и лишь потом — благодаря «раскрутке» в составе Plus! — на Cinematronics обратила внимание Maxis, и они договорились о выпуске расширенной версии.


      1. mSnus
        01.10.2021 10:40

        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.


        1. tyomitch
          01.10.2021 12:02

          Какое отношение эта цитата имеет к вашему комментарию выше: «взять хорошую игру, криво портировать, уменьшив максимальное разрешение и оставив одно поле из трёх»?

          Вот вам комментарий непосредственного разработчика игры:

          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!


  1. usa_habro_user
    01.10.2021 04:23
    +6

    Ну, Микросфот - это просто такой уж... Микрософт (впрочем, наверное, как и любая мегакорпорация). Если вспомнить, сколько они потеряли в целом на проекте Windows Phone (включая покупку Nokia), то игрушка, которую решили выбросить из-за того, что порт на 64 бита с "полпинка" не завелся - это вообще, меньше чем ничто.

    К слову сказать, был у MS такой продукт, Silverlight (который российские разработчики называли "сервелат"), амбициозно задуманный, как конкурент Flash-у (хотя, в принципе, идея была неплохая). Продукт этот сначала существовал в версии для десктопов (и браузеров), затем MS решила использовать его в качестве main API для телефонов Windows Phone 7, а затем даже "портировала" на Xbox 360. Но правильнее будет сказать, не портировала, а написала заново, по white papers! Равно, как и для Windows Phone 7. Над продуктом (кодовая база, по идее, процентов на 90-95 должна быть одной и той же) работало три совершенно разные команды (общим количеством "стопятсот" человек), притом писали все практически с нуля. Я это знаю, поскольку работал тогда с этим плотно (для одного стартапа), и меня вывели (по большому "блату", если так можно сказать) непосредственно на разработчика, который мне и "продал" небольшой "инсайд" (ну, может, сказал, не подумав - но уже "и тех уж нет, и те далече"). Самое смешное, что, хотя и писали по одной и подробнейшей white paper (то бишь по полной спецификации, созданной на основе "десктопной" версии), баги во всех трех реализациях были разные ;)


    1. ad1Dima
      01.10.2021 05:57
      -1

      Самое смешное, что, хотя и писали по одной и подробнейшей white paper (то бишь по полной спецификации, созданной на основе "десктопной" версии), баги во всех трех реализациях были разные ;)

      1) с чего бы им быть одинаковыми, если это не баги самой спецификации?

      2) не знаю что там с xbox (вообще не помню там Silverlight), но вебовый/десктопный SL мало что общего имеет с телефонным. Если там была одна спека, то только на то, как Xaml с объектами визуального дерева соотносится.


      1. usa_habro_user
        01.10.2021 06:04
        +1

        Не понял вашего "посыла": если вам интересны детали, то могу рассказать то, что знаю - но тогда спрашивайте конкретно. Ну, а если у вас проснулся инстинкт "в интернете кто-то не прав", то тут я ничем не могу помочь... Отвечать на столь странные вопросы нет желания - попробуйте, для начала, узнать и переформулировать. На уровне "одна спека" и "баги самой спецификации" я разговаривать не готов.


        1. ad1Dima
          01.10.2021 09:39

          1) Если разные люди действуя по одной и той же инструкции совершают одни и те же ошибки, это означает, что ошибка в инструкции. Странно ожидать, что у такой технически сложной вещи как SDK не будет багов, или то, что они будут разные в разных реализациях

          2) У мобильных приложений и приложений для браузера разное почти всё, начиная от жизненного цикла и навигации, заканчивая доступными ресурсами и интеграциями в окружение. О какой одинаковой на 90% кодовой базе может идти речь? И тем более одной общей спецификации на оба SDK.

          Из общего у Silverlight и Silverlight for Windows Phone только Xaml (который лишь довольно вольно описывает как объект языка должен быть представлен в xml-разметке) и программный интерфейс базовых UI-элементов.


          1. usa_habro_user
            01.10.2021 14:08

            Хотя мой пост был не о достоинствах и недостатках реализаций Silverlight-а на разных платформах, а об определенных "особенностях" менеджмент-решений Microsoft - когда в противовес бизнес-эффективности, да и просто рациональности становятся личные интересы и амбиции - в основных ваших постулатах вы не правы, видимо, из-за недостатка конкретных знаний. Спецификации на фреймворк были написаны хорошо, и реализация этих спецификаций была тоже выполнена прекрасно, но "дьявол крылся в деталях", притом очень тонких.

            Код, написанный для телефона (довольно много кода), работал практически без изменений в браузере и на десктопе; меня самого это изрядно поразило когда-то, но это факт. Разница в работе была проявлялась не всегда (речь идет о воспроизведении видео через custom MediaSource, если точнее, то HLS - когда его "нативная" поддержка даже не планировалась MS, у нас уже все работало), почему, собственно, и возник такой вопрос, на который был получен неожиданный (тогда) ответ.


            1. ad1Dima
              01.10.2021 14:21
              -1

              Вы уж определитесь, вы имеете ввиду весь Silverlight или только медиаплеер? О каком именно десктопе вы говорите? Silverlight на дестктопе этот тот же самый Silverlight, что и в браузере. Но вы его так выделяете, будто говорите о чем-то другом. Опять же, если говорить о медиаплеере, то странно ставить в вину МС, что они делали две разные реализации для разных ОС (NT и CE).

              Если вы писали код, который сам парсит HLS-плейлисты и скачивает с сервера байты, то это не удивительно, что вся его модификация это складывать байты в нужный буфер.


              1. usa_habro_user
                01.10.2021 14:31

                Процитирую вас же:

                не знаю что там с xbox (вообще не помню там Silverlight), но вебовый/десктопный SL мало что общего имеет с телефонным. 

                Это полная ерунда.

                Не нужно цепляться к порядку слов, а "определяться" мне не нужно, я написал именно то, что и хотел написать.

                Дело было вовсе не в медиаплеере, а именно в разной реализации некоторых функций Silverlight. И давайте без ваших домыслов - что именно и как я делал, когда вы еще в детский сад или начальные классы школы ходили (в 2010 году).


                1. ad1Dima
                  01.10.2021 18:27

                  Если так широко судить, то Wpf от Silverlight тоже отличается "реализацией некоторых функций"


    1. Sheti
      02.10.2021 22:13

      Ну SL не так долго просуществовал и помер вместе с Flash. Впрочем и хорошо даже. До сих пор из глубины времён достают диски с этим старым злом и вопросом "почему не работает". А если бы он существовал дольше интерпрайз успел бы наплодить кода.

      Ещё Air доставляет. Вроде давно почил, а диски с приложениями на нём до сих пор есть, как и глюки с установкой.


  1. idinfinity
    05.10.2021 13:44

    Спасибо за материал, было интересно почитать