Почему так сложно создавать 64-битные версии программного обеспечения?

Question

Какие все аспекты необходимо учитывать при проектировании вашего программного обеспечения в 64-битной среде, и почему не будет работать тот же код, что и 32-битном и 64-битном (когда речь идет о приложениях)?

Драйверы, очевидно, являются другим чудовищем, отсутствие 64-битных драйверов является печально известной проблемой практически для всего оборудования.Что такого особенного в этой области, что почти невозможно найти драйверы?

Почему так сложно создавать 64-битные версии программного обеспечения?

Редактировать: Давайтезабудьте об основных недостатках старого, глючного программного обеспечения с магическими числами и т. д. и подумайте, что вы создадите программное обеспечение самостоятельно, чтобы быть совместимым с обоими.Какие аспекты вы должны принять во внимание, и есть ли вещи, которые вы просто не можете преодолеть с нынешним дизайном компилятора?Все недостающие 64-битные программы не могут быть просто потому, что людям нравится код с магическими числами ?!:)

Заключение : Кажется, все дело в человеческой лени и исторических причинах, а не в технических причинах.

Answer 1

Одна конкретная причина, почему это может быть трудно, состоит в том, что размеры указателя будут отличаться. Вместо указателя, занимающего 32 бита, указатель теперь будет занимать 64 бита.

Это проблема, если программное обеспечение где-то вводит указатель в int через reinterpret_cast в C ++ (что может произойти в каком-то действительно низкоуровневом коде), и это работает, потому что размер int и указатель были одинакового размера. В основном код предполагал определенный размер указателя.

Другой способ, который может откусить назад, - это если код полон магических чисел, таких как 4 вместо sizeof(void*) или 0xffffffff вместо INT_MAX или что-то подобное.

64-разрядная версия программного обеспечения может отсутствовать, если она зависит от библиотеки или функции, недоступной в 64-разрядной версии. У вас не может быть приложения, которое является 32-битным и 64-битным. Например, в Windows есть функция с именем SetWindowLong, которая может принимать только 32-битные данные, поэтому она не очень полезна для 64-битных программ, если необходимо передать указатель на функцию. Вот почему есть функция SetWindowLongPtr, которая может обрабатывать до 64 бит в 64-битных программах и 32 бит в 32-битных программах.

Обратите внимание, что Internet Explorer по умолчанию работает на 32-разрядных версиях даже в 64-разрядных окнах, поскольку подавляющее большинство подключаемых модулей для него доступны только в 32-разрядных версиях. Ярким примером этого является Adobe Flash Player , который доступен только в 32-разрядной версии. Так что, по-видимому, даже для такой крупной компании, как Adobe, портирование для 64-битных систем не всегда может быть тривиальным.

Могут быть затронуты операции битшифтинга. Например, битовое смещение 0x80000 влево на 10 раз в 32 бита дает 0x0, а битовое смещение 0x80000 влево на 10 раз в 64 бита дает 0x200000000.

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

Циничная сторона меня говорит, что компании используют это как способ реализации запланированного устаревания - заставляют или поощряют людей обновлять / покупать новейшие продукты!

Answer 2

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

В основном эти низкоуровневые функции затрудняют независимость архитектуры.В языках более высокого уровня, таких как Python и C #, это намного проще.

Answer 3

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

Проблема в том, что много и много программного обеспечения написано без учета передовой практики. Заставить его работать, как правило, единственное, о чем думает типичный программист, не обращая внимания на дальнейшие проблемы. Типичное объяснение таково: зачем пользоваться хорошими практиками, если клиент не видит код, и он работает? Зачем тратить больше времени на то, что уже работает?

Драйверы здесь немного другие. Разные архитектуры могут по-разному обрабатывать вещи низкого уровня. У x86 и amd64 в Windows есть еще одна проблема: Microsoft установила более строгие стандарты для драйверов amd64 - производители оборудования не заботятся о выпуске драйверов для старого оборудования, которое соответствует более строгим требованиям (опять же: зачем беспокоиться? Заказчик обычно уже покупает новое оборудование с новыми 64-битными системами, а если нет, мы все равно заставим его сделать это, не предоставив драйверов). Опять же, драйверы с открытым исходным кодом очень часто работают на amd64 и x86.

У меня есть звуковая карта, которая довольно хорошо работает в системах x86 и amd64 в Linux, но не работает с amd64 Windows именно из-за этой проблемы. Поэтому было невозможно написать драйвер для amd64 для него; аппаратная компания просто не хотела.

Итак, окончательный ответ на ваш вопрос: деньги.