К чему я все это веду.

Очень часто, в 99% книг, можно встретить такое высказывание: "...Виртуальное (линейное) адресное пространство процесса составляет 4Гб..."

В одном предложении - сразу 2 ошибки, причем непростительные. Первая ошибка - ВИРТУАЛЬНОЕ и ЛИНЕЙНОЕ адресные пространства - взаимосвязаны, но это НИ В КОЕМ СЛУЧАЕ НЕ ОДНО И ТО ЖЕ!

Вторая ошибка: А ЧЕМУ ЖЕ СОБСТВЕННО, РАВНО ВИРТУАЛЬНОЕ АДРЕСНОЕ ПРОСТРАНСТВО ПРОЦЕССА? Действительно ли 4 Гб? Давайте разберемся...

Как известно, при создании процесса сегм. регистры загружаются такими значениями: CS = X, DS=SS=FS=GS=ES=Y, т.е. CS отличается от всех остальных (что не удивительно - попробуйте загрузить в сегм. регистр кода селектор сегмента данных или наоборот - #GP гарантировано). Поэтому имеем такую картину: ДВА РАЗНЫХ СЕЛЕКТОРА! Какой вывод мы должны сделать из этого? Может, он покажется шокирующим, но это факт - ВИРТУАЛЬНОЕ АДРЕСНОЕ ПРОСТРАНСТВО ПРОЦЕССА В ОС WINDOWS = 8 Гб!!! Т.е. процесс использует 8Гб виртуального адресного пространства из доступного 64 терабайтного! А если бы значения в DS, SS, FS, GS, ES также различались??? Ну что ж, тогда виртуальное адресное пространство процесса в ОС Windows составляло бы 24 Гб (6 сегм. регистров x 4 Гб)!

Итак, ВИРТУАЛЬНОЕ адресное пространство процесса в Win - 8 Гб! А все потому, что мы имеем ДВА РАЗНЫХ СЕЛЕКТОРА, а ведь именно они и участвуют в ФОРМИРОВАНИИ ВИРТУАЛЬНОГО АДРЕСНОГО ПРОСТРАНСТВА, оспорить это невозможно...

Замечание: на самом деле, в ОС Win, при создании процесса в сегм. регистр FS кладется ОТЛИЧНОЕ от DS, SS, GS, и ES значение, и этот регистр указывает на некоторую структуру (сегмент с базой 7FFDE000h и лимитом FFFh), связанную с процессом (структура TEB - Thread Information Block). Данная структура используется при структурной обработке исключений SEH и содержит кучу другой полезной инфы о процессе. Но все дело в том, что размер этой структуры - всего 4 Кб, поэтому его в расчет не берем, чтоб еще больше все не запутать. Но на самом деле, это надо учесть, поэтому вирт. адр. пр-во процесса в ОС Win составляет 8Гб + 4Кб.

А как же обстоит дело с линейным адресным пространством? Здесь все еще проще: линейное адресное пространство процесса ТЕОРЕТИЧЕСКИ могло бы составлять максимум от процессорного - 4 Гб, но т.к. верхние 2 Гб ОС Win NT защищены от доступа на уровне СТРАНИЦ, то получается, что ЛИНЕЙНОЕ АДРЕСНОЕ ПРОСТРАНСТВО ПРОЦЕССА В ОС Win NT = 2 Гб. В Win 9x - чуть больше, 3 Гб.

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

Например, при создании процесса исключения НЕ ВОЗНИКНЕТ при формировании процессором любого из следующих ВИРТУАЛЬНЫХ АДРЕСОВ:

(а это, как мы знаем, 8Гб + 4Кб адресов, а теоретически могло быть и 24 Гб), значит, все эти адреса ВХОДЯТ в виртуальное адресное пространство процесса.

НО ИСКЛЮЧЕНИЕ ВОЗНИКНЕТ (!) при формировании ЛЮБОГО ЛИНЕЙНОГО АДРЕСА, БОЛЬШЕГО 2 ГБ (в NT) и большего 3 Гб (в 9x). Следовательно, та часть ЛИНЕЙНЫХ адресов, при формировании которых ВОЗНИКНЕТ #GP - НЕ ВХОДЯТ В ЛИНЕЙНОГО АДРЕСНОЕ ПРОСТРАНСТВО ПРОЦЕССА, а другие - ВХОДЯТ. В этом соль и это важно ПОНЯТЬ и ОСОЗНАТЬ.

Еще заблуждения:

Во многих книгах можно прочитать что то типа: "...считать данные из страницы", или " сбросить страницу в файл подкачки". Это некорректно. На самом деле, страница - это блок линейного адресного пространства. Страница НЕ МОЖЕ СОДЕРЖАТЬ ДАННЫХ. Данные содержатся в СТРАНИЧНОМ ФРЕЙМЕ (страничный фрейм - это блок физического адресного пространства). Т.е. нужно говорить " считать данные из страничного фрейма".

Таких тонкостей - море. Только до конца разобравшийся в них может считаться специалистом.