Что мы можем сделать, чтобы программа работала в будущей архитектуре и ОС?

Question

Я поднял этот вопрос, потому что видел Windows 7 64-битной, способной без проблем запускать несколько 32-битных программ; Конечно, некоторые работают с проблемами, а некоторые отказываются работать вообще.

Я не уверен, почему некоторые 32-битные программы могут нормально работать на 64-битных системах, но для нас, в будущем, скажем, если у нас будет 128-битная архитектура и ОС, выпущенные в будущем, что мы можем сделать в перспективе программирования, если мы хотим, чтобы наша программа могла работать в другой битовой архитектуре? Или это не работа программиста?

Answer 1

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

Не так много, что вы можете сделать, чтобы сделать двоичный код будущим. Строго следуйте опубликованному API и избегайте использования недокументированных документов. Он будет работать, если будущая система его поддержит, и будущая система с большей вероятностью будет поддерживать стандартный API, чем что-либо недокументированное. Это было проблемой со многими ранними программами для Macintosh: вместо использования API (который был неуклюжим для некоторых вещей на ранних этапах), они использовали ярлыки, которые работали в OS 5 или чем-то еще, а не в OS 7.

Этот совет в основном для C и C ++, так как языки, такие как Java, определяют вещи намного лучше. Любая чистая Java-программа должна нормально работать на любой более поздней JVM. (Да, это имеет свои собственные расходы.)

Абстрагируйте все архитектурно-зависимые вещи, которые можете. Используйте типы типа size_t и ptrdiff_t в C и C ++, а не любое целое число.

Если вам нужен тип определенного размера в битах, не задавайте ему такой тип, как int или long. Используйте typedefs. Для этой цели есть заголовок C99 с полезными typedefs, но вы всегда можете иметь что-то вроде typedef int int32_t и при необходимости изменить int позже, в одном очевидном месте, а не разбросанном по программе в труднодоступных местах.

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

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

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

Answer 2

Что вы можете сделать, чтобы ваше программное обеспечение работало на любой новой платформе:

• Если вы используете интерпретируемые языки, вы получаете переносимость при переносе интерпретатора / vm.
• Положитесь на аппаратную эмуляцию.
• Напишите переносимый код и предоставьте средства для его перекомпиляции.

О том, почему 32-битное приложение может работать без изменений в 64-битных системах, если вы говорите о AMD64, это потому, что архитекторы HW имели это в виду и предоставили устаревший режим .

Answer 3

В этой конкретной ситуации от вас, как от разработчика, зависит не двоичная совместимость, а от производителя ОС.

Производитель может игнорировать эту потребность в совместимости, и ваша программа больше не будет работать. Но все будут его ненавидеть.

Так что это не задача программиста.

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

Answer 4

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

1. Взять зависимости от документированных API

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

2. Не зависит от деталей реализации или побочных эффектов

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

3. Не делайте слишком много предположений о платформе Такие вещи, как чрезмерная проверка номера версии операционной системы, могут помешать запуску приложения там, где это возможно. Я не уверен, что это хороший пример этого, но я видел, что многие приложения не работают на Windows Server, потому что они явно проверяли NT 5.1 (Windows XP)

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

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

   В последние годы Microsoft становится все более открытой в отношении публикации новых ресурсов операционной системы на ранних этапах, и предварительные версии Vista были хорошим примером этого. Если вы работаете с Windows, MSDN может стать бесценным ресурсом в этом отношении

Я не уверен, что это именно то, что вы ищете, или даже полезно, но я надеюсь, что это поможет

Answer 5

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

Также вы не можете предсказать, что будет делать поставщик ОС, чтобы испортить свой API. В лучшем случае вы можете только обернуть и скрыть внешний API в свои собственные библиотеки.

Макроопределение или определение типа базовых типов не работает, потому что люди всегда будут использовать макросы или определения типов для всего, и вы вернетесь к той же позиции, в которой находились изначально, где вы не можете различить, каким должен быть новый размер int и что на самом деле должно быть 64 или 32 бита.

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