Искусственное ограничение поддержки ОС

Zelya > Не хочу цитировать большую цитату. Так на стол же можно и по другому посмотреть. Он типа идеален. Но блин. По нему гр****ные муравьи маршируют. Надо бы что-нибудь придумать, чтобы избавиться от них. А вот этот ящик чего-то туговато идёт. Да и вообще, ящики можно чуть переделать. Ну а покрытие всё-таки не очень. Можно стеклом покрыть (его гораздо проще чистить). Ну и так далее. Тем более, софт "немного" сложнее стола и там можно найти куда больше мелочей, которые можно улучшить.

А что касается их лаж, то тут... Твой пост скорее подтверждает моё мнение. Хоть и у них не всё так гладко было, а до Win 3.1 (3.0?), винды вообще не пользовались какой-либо популярностью, у них всё равно происходил определённый захват рынка вместе с добавлением удобств. Но... Вин 95 порвал Вин 3,1, 98-ой порвал 95-ый и так далее. Но до XP. Но так чтобы принципиально (ну почти) новая ось полностью провалилась, такого со-времён Win 3.1, не было. Да ещё настолько что XP только только уходит из горизонта.

С этим согласен, только подобные эксперименты обычно очень плохо заканчиваются. Даже для лидеров.

Offtop

Не хотел писать, но всё-таки напишу. С gudleifr лучше не спорь. Уж очень он любит это дело. Да ещё и в крайне сомнительном ключе.

SubV

Ну да. Но XP постепенно уходит в прошлое. Да и он не тот уже. Но тут скорее... Разработчики не очень горят желанием быстро обновлять свои Визуал Студио.

 

А вы поинтересуйтесь, например, почему один и тот же код, использующий вычисления с плавающей точкой и скомпилированный с поддержкой SSE2 и без - дает разные результаты? Напомню, что в x64 команды SSE2 используются автоматически. Так что перенос 16- и 32-разрядного кода в x64 - не всегда тривиальная задача (особенно если часть констант в старой программе была заранее просчитана и объединена в таблицу, а другая часть считается на лету, при помощи FPU).

 

А ME кого порвал?

 

на него все будет глючить.
Им было пофиг, им ДОС нес золотые яйца.

Мммм. Ну, 98-й не то чтобы очень то и порвал. Линолиум вобще провалился. Вобще-то они от 95-го мало чем отличаются, 98-й - это "война браузеров", а Ме - это просто наглая проба состричь бабла. ХР тоже богат на неоднозначные решение. То, в какой спешке, после провала Ме, к 2000-ке прикручивали новый нескучный стиль, и как это сказалось на прожорливости, меня огорчает. Да, сейчас ХР, конечно вылизали за десять-то с гаком лет. То тогда это смотрелось уныло.

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

 

Не понял, что Вы называете "другими" языками. Вопрос-то ставился изначально: какая ОС больше ориентирована на использование разных языков в программировании? (Кстати, понимая "другие" как win-в-лоб-неприемлимые: да, видел).

1. Винда этого не смогла - см. DirectX. До этого "возврата в прошлое" игр под Винду практически не было.
2. А зачем "с нуля" - если ОС умеет рисовать окна, то зачем заставлять это делать пользователя (ср. с Tcl/Tk).

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

Вообще-то, без "фичи переполнения" половина операций сравнения не работает. И то, что размер данных часто не важен в офис-программах, не отменяет его значения в системном программировании. (Я, например, сейчас не вижу ясного пути решения переноса на Win-64 своего Forth. Хотя, надеюсь, что совместимость с Win-32 проживет хоть и меньше, чем с Win-16, но на мой век хватит).

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

 

Первый пень - это было исключение, ошибка в таблице, которую довольно быстро устранили. Вплоть до появления 128-битного ALU формулы, использующие плавающую точку, считались одинаково на всех процессорах x86. Теперь же есть существенная разница, как компилировать код: 32 бита без поддержки SSE2, с поддержкой, или же x64. Во всех этих случаях формулы с плавающей точкой будут давать разные результаты. Поэтому я и говорю, что адаптация старого кода под новую архитектуру может быть нетривиальной задачей.

Пример. Берем всем известный mp3-кодек LAME. Компилируем его в стандартном 32-битном варианте, получаем на выходе именно то, что задумали разработчики (см. спектрограммы). Всё бы хорошо, но код медленный.

Включаем поддержку SSE2, компилируем. Кодирование в mp3 значительно ускоряется (т.к. использованы векторные команды), но результирующий mp3 отличается от "канонического". И это видно на спектрограмме. (Большая часть сторонних билдов LAME собрана именно с поддержкой SSE2). Компилируем x64 - получаем третий результат.

А еще есть AVX (256- и 512-разрядные команды), используемые в новых процессорах. Как они влияют на точность вычислений - толком пока еще никто не интересовался. Но массовое применение AVX начнется еще не завтра, а вот проблемы, связанные с конвертацией старого кода под x64 (SSE2) встают уже сегодня.

 

Чувствуется, чувствуется, что кое-кто Visual Studio не видел ни разу в жизни.

 

Steel Rat, чувствуется, кто-то не видел ничего другого...

 

Уважаемые знатоки gudleifr, SubV и Zelya, прекращайте бесплодные споры на тему кто виноват и займитесь лучше делом продемонстрировав всем свои накопленные познания в конкретной игре "Mission Kellogg's" ("MK") . Я её кое-как сумел установить и даже запустить в Windows 7 32 Bit. Сразу возникла первая проблема: в ней не отображаются пункты меню. Но это ещё можно вытерпеть, как-то обойти и попасть на первый уровень "MK". А вот дальше начинаются вылеты с ошибкой типа Visual C++ Runtime Error. На ОС установлен Microsoft Visual C++ 2008. Если вам нужна ссылка на игру, вот она: http://3dsl.game-host.org/site/download.php?mirror=4021 Извиняюсь за возможный оффтоп в топике.

 

"(гнусаво) Спасибо, я уже заимел" ((L) В.Савченко "Похитители сутей") - юзаю win2k и напоролся на эту проблему ещё года 3 или 4 назад.

Ну дык Билли ж сам признавался четверть века назад, что "не хочет быть BIOSописателем" и будет всячески стараться, абы "форточки" устаревали чемпобыстрее и вынуждали постоянно переходить на всё более свежие. :-(

Фигово то, что пишет и компилирует - один, а не хочет - другой. :-(

 

gudleifr, ах, как ты меня уел! Я то видел, а вот ты вижуалку всё равно нет. =)

 

Мы говорили о не-джаве для Линукса. На Винде выбор поболее будет.

Согласен, до DirectX кастомная отрисовка была адом адским.

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

Это всякие поощрения от Майкрософта, что мол, мы проверили и таки-да, оно работает в Вин 95?

Вобще-то, как раз работает. Сравнение это переход нуля, а вылезет там 4 млрд, 65 тыс, или же 255 - побоку.

Важные системные функции, которые пишет программист уж никак не живут внутри WinAPI. Если Вы используете хардкорные битовые операции, переполнения и прочие чудеса платформенной зависимости, то именно Ваш код будет слабым местом при переносе на другую систему. Чем качетсвеннее код, тем меньше таких потенциальных дыр. Не скажу, что WinAPI идеальный и не имеет подобного барахла, но его крайне мало. Если уж совсем упрстить, то, например, мы имеем функцию Increase (я ее выдумал, не нужно меня разоблачать ), которая увеличивает int-овое значение на единичку. Стало быть, в 16-ти битной испостаси
Increase(65535) = 0
А в 32-х битной
Increase(65535) = 65536
Но если Вы используете Increase(65535) и надеетесь получить 0 - то это проблема только Вашего кода, ибо такой подход неграмотный. Поэтому, при перекомпиляции на 32-бита, винить в глючности можно только Вас. Хотя, иногда МС, вынуждена идти на встречу таким горе-разработчикам (если подобные дыры часто используются в популярных продуктах), вводя функцию IncreaseEx для 32-битных значений, а в старую дописывая костыль.

Не знаю в чем там проблема (т.е. дейстивтельно не знаком, а не отрицаю проблемы), но не забываем, что в 64-битной архитектуре повыпилили пару костылей из x86 времен 80-х, что могло сказаться на переносе Форта.

Даже если так. Это был мой ответ на Вашу фразу:

А я утверждаю, что оба способа удержаться на плаву равноценны.

 

Steel Rat, "да, я это слышал. Только что. От тебя. (с)"

 

Я абсолютно согласен. Но просто сейчас мы обсуждали изменчивость/стабильность WinAPI, конечно, железячные проблемы скажутся на ней. Но они скажуться кругом, на Винде, на МакОСи, на КолибриОС, на голом асме без оси. Это уже совсем другая тема.

 

И почему же? Промежуточные результаты хранятся в регистрах разного размера?

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

Но вообще с плавающей точкой давно пора сделать однозначно, всегда и везде, одинаково интерпретируемые результаты. Менять корректность на скорость неправильно, по-моему.

 

Gipsy_King_87,
Та Вы ж знаете, трындеть - не баги фиксать. Если б хотелось что-то чинить, мы б тут не переписывались

 

Враки.

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

поощрения, это, когда дают, а не когда грабят.

Через "фичу переполнения". Посмотрите описания ассемблерных кодов операций сравнения.

Начиная с этого места - полная фигня.

Фигня даже по меркам остальной фигни.

А это один способ. Программист гордится не "владением искусством программирования", а фитюлько-ерундицией.
...

Давайте бросим шокировать друг друга знанием основ программирования и вернемся к теме.

1. Принимали ли MS специальные меры по вынуждению перехода на новые ОС путем нарочно введенной несовместимости между версиями? Принимали.

2. Принимали ли MS специальные меры по вынуждению перехода на него путем нарочно введенной несовместимости с другими ОС? Принимали.

3. Принимают ли MS специальные меры по вымогательству денег за счет выборочной поддержки старых программ? Принимают.

4. Принимают ли MS специальные меры по ограничению Win-программирования путем сокрытия документации и предоставления ущербных средств программирования? Принимают.

 

Zelya

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

Тут смешно немного:

...вот фак! Не помню точных размеров переменных. Но можно воспользоваться typedef-ом. Ну типа у нас int 32-х битный? Ок, "typedef int int32", или ещё что. int стал 64-ёх битным, а short - 32-х? Без проблем. Меняем только строчки с "typedef"-ами.
Могут быть ещё неприятности, но... По-моему, просто стоит учитывать подобные вещи при написании программ. Да и удобство в портировании, никогда не бывает лишним.

Ещё забавно, что... Вот сейчас спорим, но нынче вроде просто мана небесная, на фоне старых времён.

 

gudleifr,
Говоря "игры для PC" всегда подразумеваются "игры под Windows". Nuff said.

 

+65537!