Подгрузка в память системных библиотек
Читал в Рихтере, что системные (user32.dll, kernel32.dll, ntdll.dll и прочие) библиотеки существуют в памяти в единственном экземпляре, которые "разделяются" приложениями.
Объясните пожалуйста, каким именно образом они разделяются?
Мне на ум приходит только то, что они проецируются в верхние 2 Гб системной виртуальной памяти (начиная с 0х80000000 до 0хFFFFFFFF). :confused:
И еще вопрос. Эти верхние системные 2 гб памяти одинаковы для всех выполняемых приложений? Т.е. верхние системные 2 гб памяти как бы "общие" для всех процессов?
з.ы. если понадобится, могу найти эту цитату из Рихтера
Объясните пожалуйста, каким именно образом они разделяются?
Мне на ум приходит только то, что они проецируются в верхние 2 Гб системной виртуальной памяти (начиная с 0х80000000 до 0хFFFFFFFF). :confused:
И еще вопрос. Эти верхние системные 2 гб памяти одинаковы для всех выполняемых приложений? Т.е. верхние системные 2 гб памяти как бы "общие" для всех процессов?
з.ы. если понадобится, могу найти эту цитату из Рихтера
Там же у Рихтера написано, каким образом они разделяются.
Глава 17: http://rosigma.com/91.aspx
Дополнительно посмотри здесь:
http://msdn2.microsoft.com/en-us/library/aa366785(VS.85).aspx
Глава 17: http://rosigma.com/91.aspx
Дополнительно посмотри здесь:
http://msdn2.microsoft.com/en-us/library/aa366785(VS.85).aspx
О'кэй как любит говорить Рихтер :)
Тока что до меня дошла идея самому глянуть адрес, по которому библиотеки загружаются (замечаю за собой, что, в последнее время, я стал очень ленивый, нефига не делаю и тока задаю вопросы :) )
Системные библиотеки, используемые разными приложениями загружены по одинаковым адресам в пользовательской части виртуального адресного пространства.
Т.е. при создании процессов снова и снова в них проецируются системные DLL ?
Тока что до меня дошла идея самому глянуть адрес, по которому библиотеки загружаются (замечаю за собой, что, в последнее время, я стал очень ленивый, нефига не делаю и тока задаю вопросы :) )
Системные библиотеки, используемые разными приложениями загружены по одинаковым адресам в пользовательской части виртуального адресного пространства.
Т.е. при создании процессов снова и снова в них проецируются системные DLL ?
Ооо...до меня доперло :)
При первом проицировании системной библиотеки в память происходит фактическое ее копирование в ОЗУ. Но, когда потом вызывается какое-то приложение(использующее функции уже заргуженной dll), то происходит проецирование в виртуальную память этой dll, а физическая память не выделяется - вместо этого "связывается" уже находящийся в ОЗУ код с только что выделенным виртуальным пространством.
Если бы одно из приложений попыталось изменить что-то в "совместной" памяти, то был бы использован механизм копирования при записи (WRITECOPY)... (хотя это в принципе невозможно. Страницы с кодом защищены READONLY)
Так?)
При первом проицировании системной библиотеки в память происходит фактическое ее копирование в ОЗУ. Но, когда потом вызывается какое-то приложение(использующее функции уже заргуженной dll), то происходит проецирование в виртуальную память этой dll, а физическая память не выделяется - вместо этого "связывается" уже находящийся в ОЗУ код с только что выделенным виртуальным пространством.
Если бы одно из приложений попыталось изменить что-то в "совместной" памяти, то был бы использован механизм копирования при записи (WRITECOPY)... (хотя это в принципе невозможно. Страницы с кодом защищены READONLY)
Так?)
Цитата: Аццкий программер
Ооо...до меня доперло :)
При первом проицировании системной библиотеки в память происходит фактическое ее копирование в ОЗУ. Но, когда потом вызывается какое-то приложение(использующее функции уже заргуженной dll), то происходит проецирование в виртуальную память этой dll, а физическая память не выделяется - вместо этого "связывается" уже находящийся в ОЗУ код с только что выделенным виртуальным пространством.
При первом проицировании системной библиотеки в память происходит фактическое ее копирование в ОЗУ. Но, когда потом вызывается какое-то приложение(использующее функции уже заргуженной dll), то происходит проецирование в виртуальную память этой dll, а физическая память не выделяется - вместо этого "связывается" уже находящийся в ОЗУ код с только что выделенным виртуальным пространством.
Здесь правильно.
Цитата: Аццкий программер
Если бы одно из приложений попыталось изменить что-то в "совместной" памяти, то был бы использован механизм копирования при записи (WRITECOPY)...
Здесь тоже правильно.
Цитата: Аццкий программер
(хотя это в принципе невозможно. Страницы с кодом защищены READONLY)
А вот здесь не верно. Это возможно.
На этом основан механизм перехвата API вызовов.
В т.ч. http://forum.codenet.ru/showthread.php?t=32978
Цитата: Green
Здесь правильно.
Здесь тоже правильно.
А вот здесь не верно. Это возможно.
На этом основан механизм перехвата API вызовов.
В т.ч. http://forum.codenet.ru/showthread.php?t=32978
Здесь тоже правильно.
А вот здесь не верно. Это возможно.
На этом основан механизм перехвата API вызовов.
В т.ч. http://forum.codenet.ru/showthread.php?t=32978
Цитата:
А вот здесь не верно. Это возможно.
На этом основан механизм перехвата API вызовов.
На этом основан механизм перехвата API вызовов.
да, точно. WriteMemoryProcess(..) может изменять флаги защащенных страниц, если имеет соответсвенный маркер доступа. Из того же Рихтера :)
Спасибо, разобрался :)