Некоторые следствия из проекции исполнимых файлов

Упомянув ранее о том, что исполнимые файлы "на исполнение" не "загружаются", а "проецируются" уместно сказать и о том, к чему это приводит. Win32 - преемница Win3.x И имеет в своём составе немалое количество функций, помеченных в MSDN как obsolete, т.е. тех, которые не требуются в новом проектировании. Но они - есть, т.к. существует проблема переносимости прошлого кода в среду современной системы. Это и сбивает с толку программиста. Например, он считает, что есть функция GlobalLock... а функция GlobalLock ничего уже и не делает - нет в системе теперь "глобальной памяти", нет и памяти "перемещаемой". Изменилась вся модель памяти и эти функции теперь - просто рудименты прошлой эпохи. Аналогичное можно сказать и про функции LoadResource/FreeResource, которые "загружают" ресурсы, сопровождающие исполняемый модуль. Во времена DOS так оно и было, и система, с целью экономии дорогой памяти, стремилась всё делать посегментно - вторая стартующая копия программы получала только новый сегмент данных, а сегмент кода - использовался несколькими процессами, и ресурсы загружались в память только по требованию, их можно и желательно было "выгружать", когда они становились не нужны. Сейчас же исполнимый файл "проецируется" в своё адресное пространство. Как во всех предыдущих разделах неоднократно отмечалось - это приводит к расходу ресурса "адресное пространство", но само собой не приводит к точно такому же расходу ресурса "физическая память". А, значит, можно совершенно спокойно полагать, что все ресурсы уже - "загружены автоматически". При этом функция LoadResource по прежнему имеет смысл - она снабжает клиента адресом ресурса в памяти, а вот функция FreeResource смысла уже не имеет, т.к. любая страница физической памяти (а не только та, которая выделена "под ресурсы") будет системой вытеснена совершенно автоматически, если к ней долго не было обращений.