· Начало · Отвђтить · Статистика · Поиск · FAQ · Правила · Установки · Язык · Выход · WASM.RU · Noir.Ru ·

 WASM Phorum —› WASM.WIN32 —› Рихтер. Управление памятью. Стек.

. 1 . 2 . >>

Посл.отвђт Сообщенiе


Дата: Май 12, 2004 12:39:32 · Поправил: Oleg_SK

Привет всем!
Вот, прочитал я, что пишет Рихтер о стеке. Очень познавательно! Думал уже, что со стеком все ясно, но не тут то было... Вот, появилось у меня несколько вопросов, ответа на которые я не нашел у Рихтера (может быть, плохо искал?)...

1. Суть вопроса вот в чем: Рихтер прекрасно объяснил то, как Windows управляет памятью, при увеличении размера стека, но с другой стороны, он нечего не сказал о том, что происходит, когда размер стека уменьшается (правда, у него есть намеки на это, но хотелось бы прояснить ситуацию)... Например: допустим, что на определенной стадии выполнения программы ее стеку передано три страницы физической памяти, потом размер стека уменьшился и стал вполне умещаться в две страницы физической памяти. Вопрос: что после этого произойдет с освободившейся страницей памяти? Останется ли она 'переданной' или освободится и перейдет в разряд: зарезервированная? Вопрос не праздный, т.к. хотелось бы знать: можно ли без опасений обращаться для чтения в область освободившейся страницы?

2. Могут ли система свопировать страницы памяти, переданные стеку?

3. Вы обратили внимание на то, что стек в Windows 98 защищен лучше, чем в Windows 2000? Например: если в процессе произойдет stack underflow, то Windows 98 может корректно обработать такую ситуацию, в отличие от Windows 2000... Интересно, как такой баг мог попасть в столь надежную ось? В Windows XP он исправлен?

4. Может быть это глупый вопрос, но хотелось бы знать: как Windows 98 отлавливает обращения 32-битного кода к 16-битному? Не имея ответа на этот вопрос, я не могу точно представить себе то, как Windows 98 работает стеками потоков…

5. У меня в книге видимо опечатка. Дело в том, что на рис. 16-4, который показывает: как выглядит регион стека сразу после его создания под управлением Windows 98, указанно, что есть 16 страниц зарезервированных для перехвата переполнения стека (адрес: 0x00530000). Это, т.н. нижняя часть стека. На рис. 16.5, который показывает: целиком заполненный регион стека потока в Windows 98, этот же блок состоит уже не из 16 страниц, а только из 8. Куда девались остальные 8 страниц из этого блока. Это правильно?

Пока у меня все. Заранее благодарен вам за ответы!

P.S.: Если что, прошу сильно меня не пинать… Я сам знаю, что я - ламер!


Дата: Май 12, 2004 14:15:20

1. останется переданной
2. когда система суспендид процесс она может сбросить в своп все что угодно
4. что ты подразумеваешь под "обращения 32-битного кода к 16-битному"?


Дата: Май 12, 2004 14:31:50 · Поправил: Oleg_SK

Max
Спасибо, за ваш ответ!

2. когда система суспендид процесс она может сбросить в своп все что угодно
То есть, она (ось) может сделать это только в данном случае?

4. что ты подразумеваешь под "обращения 32-битного кода к 16-битному"?
Я имею в виду, обращения из 32-разрядной программы к функциям из 16-разрядных библиотек (DLL). Можно пойти дальше и взять еще, для примера: обращение из 32-разрядной библиотеки (DLL) к функциям из 16-разрядных библиотек (DLL).


Дата: Май 12, 2004 14:57:58 · Поправил: Four-F

1. На 99,99% останется 'переданной'

2. Да. Даже стек ядра. Вот наглядный пример (N/P значит Not Present):
:thread -u 81224410
TID   User TEB  StackBtm  StackTop  StackPtr  Krnl TEB  Process(Id)
0370  7FFDE000  00030000  00070000  BDF17CC8  81223030  Explorer(374)
0384  7FFDD000  N/P       N/P       BDDE7C48  8121A630  Explorer(374)
0398  7FFDC000  00F30000  00F70000  BDEC7CC8  81278030  Explorer(374)
03B8  7FFDB000  N/P       N/P       BE036930  8120E4F0  Explorer(374)
03C0  7FFD9000  N/P       N/P       BE016930  8120C7F0  Explorer(374)
03CC  7FFD7000  N/P       N/P       ED18F930  8120B130  Explorer(374)
03DC  7FFD5000  N/P       N/P       BDF87930  81203850  Explorer(374)
03E4  7FFAF000  N/P       N/P       BDF8FCC4  811FE530  Explorer(374)
03D4  7FFD6000  N/P       N/P       BE261C20  811FE2B0  Explorer(374)
03E8  7FFAE000  N/P       N/P       BE2C1C20  811FA030  Explorer(374)
0424  7FFD4000  N/P       N/P       BE0BA930  811E0030  Explorer(374)
042C  7FFAD000  N/P       N/P       BDD0FC48  811D7030  Explorer(374)
0310  7FFAB000  N/P       N/P       BDEAFC90  811CCDB0  Explorer(374)
0340  7FFA9000  N/P       N/P       BDF57C48  81185570  Explorer(374)
0438  7FFA8000  N/P       N/P       BDCB7CC8  81227030  Explorer(374)
0358  7FFA7000  02020000  02060000  BDCA7CC4  81156630  Explorer(374)
031C  7FFA6000  N/P       N/P       BDC87CC8  8118A990  Explorer(374)
048C  7FFA4000  N/P       N/P       BDBA7CA0  8110A3B0  Explorer(374)
030C  7FFDA000  N/P       N/P       BDD4FCC4  81229030  Explorer(374)


5. Похоже это действительно опечатка. У Рихтера на хомпаге есть страница с опечатками к книге - попробуй там посмотреть. А можно экскримент провести. Напиши тест, который заполняет стек и посмотри. В айсе есть команда query. Или у того же Рихтера в книге есть готовая тулза, показывающая регионы памяти.


Дата: Май 12, 2004 15:11:06

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


Дата: Май 12, 2004 15:14:01

Four-F
Да, я уже понял это, прочитав сейчаc ваш ответ http://www.wasm.ru/forum/index.php?action=vthread&forum=4&topic=5573&page=-1 . Поэтому и убрал свой пост, но вы оказались быстрее...


Дата: Май 12, 2004 15:34:58

Хорошо, ответы получены на вопросы 1,2,5. Их, я думаю, можно считать закрытыми. Остались только вопросы: 3,4. Особенно меня интересует ответ на 4-ый вопрос!


Дата: Май 12, 2004 15:35:15

про 16/32 битные перетасовки
{ Undocumented Kernel32 calls. }
function LoadLibrary16(LibraryName: PChar): THandle; stdcall; external
kernel32 index 35;
procedure FreeLibrary16(HInstance: THandle); stdcall; external kernel32
index 36;
function GetProcAddress16(Hinstance: THandle; ProcName: PChar): Pointer;
stdcall; external kernel32 index 37;
procedure QT_Thunk; cdecl; external kernel32 name 'QT_Thunk';
{ QT_Thunk needs a stack frame. }
{$StackFrames On}
{ Thunking call to 16-bit USER.EXE. The ThunkTrash argument
allocates space on the stack for QT_Thunk. }
function NewGetFreeSystemResources(SysResource: Word): Word;
звиняюсь, что на паскале, разберёшься !!!!


Four-F

!!! МолодцА!!!


Дата: Май 12, 2004 15:39:19

дасми да глянь !! а ф чём , собственно проблема ??? почему 32 сегмент не может обратиться к 16 битному и наоборот ???? В чём траблы ??? Читать хорошенько Зубкова, а лучше интелофские мануалы.


Дата: Май 12, 2004 15:40:22

Four-F
Звиняюсь, сэр


Дата: Май 12, 2004 15:58:05 · Поправил: Oleg_SK

CARDINAL
Насколько я понял, благодаря вашему ответу, снята та часть 4-го вопроса, которая относится к явному подключению 16-разрядной библиотеки. А если 16-разрядная либа указана в импорте программы? Или я чего-то не уловил?

P.S.: Sorry, если вопрос глупый. Я никогда, непосредственно, не имел дела с этим.


Дата: Май 12, 2004 16:03:08 · Поправил: Oleg_SK

CARDINAL
а ф чём , собственно проблема ???
Проблема в том, они немного по разному представляют себе структуру стека. Windows 98 должна отлавливать момент переключения и соответственно корректировать их работу с общим стеком.
Вот я и пытаюсь понять, как она это дело (т.е. переключение) отлавливает.


Дата: Май 12, 2004 19:43:32

> 3. Вы обратили внимание на то, что стек в Windows 98 защищен лучше, чем в Windows 2000?

Не перестаю повторять мастдай - рулит ;-)


Дата: Май 14, 2004 14:14:39

я чего то смутно представляю себе суть, но, по крайней мере хоть что то представляю, в своё время я гулял туда айсом, и обнаружил некую шлюзовую переключалку через int30h, нечто похожее на системный шлюз int2e (NT), просто совет, сходи до туда прогуляйся, насколько я помню , его обработчик лежит где то в недрах кода wmm32.vxd.
по части четвёртого вопроса , обратись к RSDN, я собственно там его выловил когда то , наиболее полное описание. Просто , эти засранцы из M$ по прежнему в своём репертуаре. Засекретили всё, что только можно. Вместо имён функций тока их адреса. Эх, было времечко масдая !!!! Особенно мне нравился ord0001. !!! С её помощью можна было вызвать любую функцию wmm32 или уже загруженного в память vxd, не прибегая к подобным самостоятельным действиям.


Дата: Май 14, 2004 17:55:39

CARDINAL
Мдя... Говорил же: ламер я! Моих скромных знаний не хватает, сейчас, для того, чтобы полностью понять смысл твоего ответа... Предложение: прогуляться туда самому довольно заманчиво. Проблема в том, что я не знаю: как это сделать. Ведь, насколько я понимаю, для того чтобы начать эту прогулку, нужно каким то образом поставить breakpoint на начало процесса загрузки какой-либо импортируемой библиотеки (DLL) в адресное пространство процесса, а затем трассировать процесс загрузки. Верно я думаю или нет? Если да то как это сделать? К примеру, сейчас я абсолютно не понимаю: каким образом можно поставить такой breakpoint. Объясни, пожалуйста, так, как будто объясняешь ребенку:))

. 1 . 2 . >>


Powered by miniBB 1.6 © 2001-2002
Время загрузки страницы (сек.): 0.051