Джонсон Харт - Системное программирование в среде Windows

• Автоматизированное проектирование механических (Mechanical Computer-Aided Design, MCAD) и электронных (Electronic Computer-Aided Design, ECAD) устройств.Для проектирования сложных сборочных узлов требуется наличие более 3 Гбайт памяти, а проектирование микросхем предъявляет к памяти несоизмеримо более высокие требования.

• Базы данных и хранилища данных.Использование файлов с размерами в несколько сотен Гбайт не является чем-то необычным, и возможность доступа к виртуальным адресным пространствам сопоставимых размеров значительно упрощает обработку таких файлов.

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

Потребность в 64-битовой адресации диктуется теми же факторами, которые делают столь желательными и необходимыми файлы гигантских размеров (свыше 4 Гбайт), и теперь, когда имеются достаточно мощные микропроцессоры Itanium, AMD64, а также процессоры, использующие технологию 64-разрядного расширения, вполне естественно ожидать, что Windows должна будет эволюционировать для удовлетворения этих запросов. Использование 64-разрядных ОС существенно в тех случаях, когда Windows отводится заметная роль в прикладных корпоративных и профессиональных системах.

Тем не менее, многие 32-разрядные приложения смогут работать нормально и на новой платформе, и на первом этапе для их переноса не надо будет ничего предпринимать. Для таких персональных приложений, как Microsoft Office или Adobe PageMaker, в течение некоторого времени переход к 64-битовой адресации, по-видимому, не потребуется. Следовательно, Windows будет поддерживать обратную совместимость.

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

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

• Основные поставщики UNIX-систем предоставляют 48– и 64-разрядные микропроцессоры с начала 90-х годов прошлого столетия.

• Основные поставщики UNIX-систем поддерживают 64-разрядные API на протяжении примерно того же периода времени.

• Сообщество пользователей UNIX остановилось на выборе в качестве стандарта так называемой модели LP64, отличающейся от модели Р64, принятой в Win64, о чем далее еще будет говориться.

• Переходы от 32 к 64 битам всегда осуществлялись сравнительно простым, если не сказать — тривиальным образом, и можно ожидать, что то же самое будет наблюдаться и при переходе от Win32 к Win64.

Переход от 16-разрядных версий Windows к 32-разрядным начался в начале 90-х годов прошлого столетия с появлением Windows NT, и набрал ускорение после того, как использование Windows 95 стало обычным делом. Каким бы соблазнительным ни казалось предположение о том, что нас ожидает повторение той же истории, рассматриваемые нами ситуации отличаются в нескольких аспектах.

• Windows NT и Windows 95 были первыми из широко используемых "реальных" операционных систем для PC в том смысле, что обе системы поддерживали обмен страницами по запросу, потоки, вытесняющую многозадачность и множество других возможностей, которые были описаны в главе 1.

• Хотя API Win32 значительно расширил полезное адресное пространство, что делает и Win64, усовершенствования этим не ограничивались. Неуклюжие и устаревшие, несмотря на свою популярность, модели расширенной памяти были заменены другими. Аналогичная модель расширенной памяти (не описывается в данной книге) была введена и в Windows 2000, однако общие последствия этого шага в данном случае были не столь существенными.

• В API Win32 было введено множество новых функциональных возможностей, чего нельзя сказать о Win64.

Что касается мира PC, в котором возникла Windows, то можно утверждать, что первоначальная 16-разрядная модель Intel x86 (фактическое адресное пространство которой является 20-битовым) просуществовала в течение более десяти лет, и столько же времени уже существует и 32-разрядная архитектура. Однако переход к Win64 и 64-разрядному программированию, вообще говоря, происходит медленнее, чем происходил аналогичный переход к 32 битам. Вместе с тем, в обоих случаях переход миникомпьютеров и серверов на следующий уровень осуществлялся, по крайней мере, за 10 лет до того, как это начинало происходить с PC. Тогда вполне естественно задаться вопросом о том, следует ли ожидать перехода серверов или PC к 128 битам в будущем. Берусь утверждать, что любое расширение такого рода произойдет не раньше, чем через 10 лет, исходя из одной лишь величины 64-разрядного адресного пространства.

Предсказания — вещь ненадежная, однако, воспринимая это серьезно лишь наполовину, можно напомнить о часто цитируемом законе Мура, согласно которому отношение "стоимость/производительность" уменьшается вдвое каждые 18 месяцев. В свою очередь, быстродействие и емкость устройств каждые 18 месяцев примерно удваиваются. Применяя эти рассуждения к адресному пространству, можно ожидать, что дополнительный бит адреса нам будет требоваться через каждые 18 месяцев, откуда следует, что 64-разрядная модель будет исправно служить еще целых 48 лет (то есть почти столько же времени, сколько насчитывает вся история современных компьютеров). Оправданы ли такие неформальные выводы, которые встретились мне в одном из официальных источников, покажет время, однако в прошлом запросы к ресурсам PC возрастали гораздо быстрее, чем утверждается в приведенном прогнозе.

В зависимости от выбора способа представления таких стандартных типов данных С, как указатели и целочисленные типы данных (long, int и short), a также от того, вводятся или не вводятся нестандартные типы данных, возможны несколько вариантов модели 64-разрядного программирования. Напомним, что в стандарте ANSI С размеры типов данных не определяются строго, хотя и требуется, чтобы размер данных типа long int был не меньше размера данных типа int, а размер данных типа int был не меньше размера данных типа short int.

Цель состоит в том, чтобы ввести единое определение Windows API (то есть, общее для Win32 и Win64), благодаря чему можно будет использовать единый базовый исходный код. Использование этого единого определения может потребовать внесения некоторые изменений в исходный код, но эти изменения должны быть сведены к минимуму.