Что такого сложного в построении 64-битных версий двоичных файлов? - PullRequest
9 голосов
/ 02 октября 2008

Существует множество драйверов и известных приложений, которые недоступны в 64-разрядной версии. Например, Adobe не предоставляет 64-битный плагин Flash Player для Internet Explorer. И из-за этого, несмотря на то, что я использую 64-битную Vista, мне нужно запустить 32-битный IE Microsoft Office, Visual Studio также не поставляются с 64-битным AFAIK.

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

Итак, мой вопрос: что мешает людям собирать 64-битные версии?

Ответы [ 8 ]

16 голосов
/ 02 октября 2008

Если вы начинаете с нуля, 64-битное программирование не так сложно. Тем не менее, все программы, которые вы упоминаете, не новы.

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

  • Правильное выравнивание элементов в структуре. При изменении размеров данных допущения о том, что определенные поля в структуре будут выровнены по оптимальной границе памяти, могут быть ошибочными
  • Длина long целых чисел изменяется, поэтому, если вы передаете значения через сокет в другую программу, которая может быть не 64-битной, вам необходимо провести рефакторинг вашего кода
  • Изменяются длины указателей, поскольку расшифровка написанного кода настолько сложна, что гуру оставил компанию немного сложнее в отладке
  • Базовые библиотеки также должны иметь 64-битную поддержку для правильной связи. Это большая часть проблемы переноса кода, если вы полагаетесь на любые библиотеки, которые не имеют открытого источника
5 голосов
/ 02 октября 2008

Самая большая проблема, с которой я столкнулся при переносе нашего кода C / C ++ на 64-битную версию, - это поддержка сторонних библиотек. Например. в настоящее время есть только 32-битные версии Lotus Notes API, а также MAPI, поэтому вы даже не можете ссылаться на них.

Кроме того, поскольку вы не можете загрузить 32-битную DLL в ваш 64-битный процесс, вы снова обожгетесь, пытаясь загрузить вещи динамически. Мы снова столкнулись с этой проблемой, пытаясь поддерживать Microsoft Access под 64-битной версией. Из википедии:

Jet Database Engine останется 32-разрядная в обозримом будущем. Microsoft не планирует изначально поддержка Jet под 64-битные версии Windows

5 голосов
/ 02 октября 2008

В дополнение к тому, что написано в @ jvasak посте , главное, что может вызвать ошибки:

  • указатели больше, чем целые числа - огромное количество кода предполагает, что размеры одинаковы.

Помните, что Windows даже не позволяет приложению (32-разрядному или 64-разрядному) обрабатывать указатели с адресом выше 0x7FFFFFFF (2 ГБ или более), если только они не были специально помечены как "LARGE_ADDRESS_AWARE", потому что очень много приложений будет рассматривать указатель как отрицательное значение в некоторой точке и падать.

3 голосов
/ 02 октября 2008

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

В Windows установлен WoW64 (Windows в 64-битной версии Windows), а в Linux могут быть доступны 32-битные библиотеки наряду с 64-битными. Оба из них позволяют нам запускать 32-битные приложения в 64-битных средах.

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

Исключениями являются такие вещи, как драйверы устройств, так как они более тесно связаны с операционными системами и не могут работать в 32-битном слое, который предлагают 64-битные операционные системы на базе x86-64 / AMD64 (IA64 не в состоянии это сделать это из того, что я понимаю).

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

Я думаю, что это стратегическая ошибка со стороны Adobe. Необходимость запускать 32-битный браузер для Flash Player неудобна для пользователей, и многие не поймут это решение. Это может привести к опасениям разработчиков по поводу использования флэш-памяти. Самое важное для веб-сайта - убедиться, что каждый может его просматривать, решения, которые отталкивают пользователей, обычно не популярны. Популярность Flash поддерживалась его собственной популярностью: чем больше сайтов использовали ее, чем больше пользователей использовали ее в своих системах, тем больше пользователей использовали ее в своих системах, тем больше сайтов желали ее использовать.

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

Vista выпускается уже около 2 лет, а Windows XP 64-bit была выпущена до этого. На мой взгляд, это слишком долго, чтобы крупные технологии, такие как Flash, не могли быть обновлены, если они хотят удержать свой рынок. Возможно, это связано с тем, что Adobe захватила Macromedia, и это признак того, что Adobe не считает, что Flash является частью их будущего, мне трудно поверить, поскольку я считаю, что Flash и Dreamweaver были главными составляющими того, что они получили от Macromedia. , но тогда почему они еще не обновили его?

3 голосов
/ 02 октября 2008

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

2 голосов
/ 02 октября 2008

Это не так просто, как просто включить переключатель на вашем компиляторе. По крайней мере, если вы хотите сделать это правильно. Наиболее очевидным примером является то, что вам нужно объявить все ваши указатели с использованием 64-битных типов данных. Если у вас есть какой-либо код, который делает предположения о размере этих указателей (например, тип данных, который выделяет 4 байта памяти на указатель), вам придется его изменить. Все это должно быть сделано в любых библиотеках, которые вы используете. Кроме того, если вы пропустите только несколько из них, то в итоге указатели будут сброшены и расположены не в том месте. Указатели - не единственная проблема, но, безусловно, самая очевидная.

1 голос
/ 02 октября 2008

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

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

Для многих приложений преобразование в 64-битную модель памяти на самом деле не дает никаких преимуществ (поскольку им никогда не требуется больше, чем несколько ГБ ОЗУ), и может на самом деле замедлять работу из-за большего указателя размер (делает каждое поле объекта в два раза больше).

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

0 голосов
/ 02 октября 2008

Их Блог о Linux / Flash объясняет, почему еще нет 64-битного Flash Player Некоторые специфичны для Linux, некоторые нет.

...