Что такого особенного в СОЗДАНИИ 64-битных версий двоичных файлов?

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще одна причина, по которой многие компании не приложили усилий для создания 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 подпитывалась его собственной популярностью: чем больше сайтов использовало его, тем больше пользователей использовали его в своих системах, чем больше пользователей использовали его в своих системах, тем больше сайтов были готовы его использовать.

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

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

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

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

The Jet Database Engine will remain 32-bit for the foreseeable future. Microsoft has no plans to natively support Jet under 64-bit versions of Windows