Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Насчет сегментов. Или вы неправы или неправы авторы многочисленных руководств по программированию на ассемблере для Windows. одно из руководств "Современные процессоры Intel IA-32 в ПК" flat memory model Способ организации памяти, при котором программа оперирует с единым непрерывным адресным пространством, называемом линейным адресным пространством. Код, данные и стек программы размещаются в этом пространстве. то же самое написано в учебнике г-на Юрова (который позиционируется как учебник для ВУЗов и по идее должен быть проверен на предмет лажи): "Модель памяти flat обозначает плоскую модель памяти. в соответсвии с этой моделью, компилятор создает программу, которая содержит один 32-битовый сегмент для данных и кода программы... в программе с плоской моделью памяти используется адресация программного кода и данных типа near." Видимо, подобный учебник прочитал и ErV, поэтому imho он правильно в общем написал, ведь прикладная прога под Windows не работает со всеми этими GDTR,LDTR и селекторами, смысл Windows как раз в том, что она абстрагирует прогу от всего этого, предоставляя ей пресловутые 4Gb адресного пространства и регистры общего назначения для работы. Собственно, о защищенном режиме прикладному программеру под Windows практически ничего знать и не надо. О нем надо знать самим разработчикам Windows и драйверов. Опять же по аналогии мне более близкой: com проги под DOS тоже имели всего один сегмент, где варились стек, данные и код. Поэтому больше 64kb было низя юзать. com формат был по сути такой же моделью flat, как прикладная прога современных виндов. Разумеется, в сильно уменьшенном виде :-) ErV, как я понимаю, дизассемблировал прикладные виндовые проги, поэтому вправе был ожидать "никакой фигни с сегментами" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2006, 22:59 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
опять же - мы не говорим о нулевом кольце: автор явно дизассемблировал не драйвера или ядро Windows :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2006, 23:01 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
--null--который позиционируется как учебник для ВУЗов и по идее должен быть проверен на предмет лажиНе смешите меня :) Хотя в данном случае учебник и не врет. Он только не упоминает что flat-модель, это всего лишь модель. Одна из многих. --null--Собственно, о защищенном режиме прикладному программеру под Windows практически ничего знать и не надо. О нем надо знать самим разработчикам Windows и драйверов.Верно. Но если ErV начал диззасемблировать программы - прийдется ему читать учебники по защищеному режиму, по внутренней структуре процессора и тд и тп. --null--Опять же по аналогии мне более близкой: com проги под DOS тоже имели всего один сегмент, где варились стек, данные и код. Поэтому больше 64kb было низя юзать.??? Почему "низя"? Зя! Вполне себе зя. Вызываешь функцию ДОС, запрашиваешь себе кусок памяти и усе. Нету больше вашего flat'а :) Это только при старте *.com ей операционкой выделялся кусок памяти равный размеру файла и сегментные регистры устанавливались на этот кусок. А дальше хоть всю память себе захапай, хоть в extended хоть в expanded лезь, никаких проблем совершенно. Кстати, даже в виндах прикладная программа запрашивая память у ОС может получить новый кусок памяти в другом дескрипторе, смотри например функции GetProcessHeap() и HeapAlloc(). Вот они, дескрипторы в чистом виде. Полез в кучу другого процесса - нету больше flat-модели. И все законно и просто :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2006, 23:24 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
GetProcessHeap() и HeapAlloc(). - но тут выражаясь терминологией uniх код будет работать "в режиме ядра". То есть потроха эих функций написаны системными программистами и в общем к прикладной программе не относятся, верно? Собственно прога на Windows с точки зрения асма я так понимаю - прикладной код, постоянно вызывающий различные API. Эти API естественно лезут "унутрь". :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2006, 23:34 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Потроха этих функций совершенно ни причем. С точки зрения прикладной программы, как только я получил хендл какой-нибудь кучи (через GetProcessHeap() или даже через CreateHeap()) у меня уже появился набор дескрипторов которые моя прикладная программа должна помнить и уметь обращаться к тому или другому. Дизассемблируй кусок программы работающий с двумя-тремя кучами одновременно и увидишь то самое жонглирование сегментами которого по мнению учебников в Windows нету :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 00:51 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Почему - у меня был дизассемблер, который выделял вызовы API и не показывал их код, если не нужно. Так как известно, что они делают - для того чтобы разобраться в проге должно быть достаточно прикладного кода. Весь вопрос - для чего делается дизассемблирование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 09:43 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
White OwlС точки зрения прикладной программы, как только я получил хендл какой-нибудь кучи (через GetProcessHeap() или даже через CreateHeap()) у меня уже появился набор дескрипторов которые моя прикладная программа должна помнить и уметь обращаться к тому или другому. Дизассемблируй кусок программы работающий с двумя-тремя кучами одновременно и увидишь то самое жонглирование сегментами которого по мнению учебников в Windows нету :)что ты народ смущаешь, на тёмную сторону силы склоняешь? Врёшь ведь. Ты сам-то дизассемблировал? Вроде бы выделение памяти под кучу основывается на VirtualAlloc. Функции работы с кучами - это просто логическая надстройка над VirtualAlloc (поддержка структуры кучи, рост кучи и т.п.). Никакого гимора с сегментами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 12:26 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
бжлзд. Выдержка из дизасма, с адресами, с кодами. Где префиксы смены сегмента? ------------------ - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 12:30 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
дизассемблер какой-то шибко вумный. На самом деле так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 12:44 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
White Owl maXmoнеа, низачот :) возможно, ты путаешь с lds и les(бум лбом об стол) И ведь действительно путаю... Прошу прощения, наврал я. Иех, пора в отпуск... Или снова плотно заняться ассемблером? :) ErVИ вообще - если я что-то вдруг ляпнул, разве так трудно вкратце объяснить в чем проблема?Дескрипторы в защищеном режиме это практически те же самые сегменты в реальном. С двумя различиями: 1) куски памяти адресованые сегментами реального могут перехлестываться а память адресованая через дескрипторы в защищеном не может. 2) процесс в реальном режиме может обращаться к любому сегменту, а на процесс в защищеном наложены некоторые ограничения. Но со всех остальных точек зрения сегменты и дескрипторы это одно и тоже. Они даже хранятся в одних и тех же регистрах процессора :) Нельзя говорить что в "проге под винду, соответственно, никкой фигни с сегментами", там этой фигни намного больше на самом деле. Под виндой ты имеешь точно такой же доступ к сегментным регистрам и точно так же можешь в свой проге жонглировать их содержимым. И точно так же как и в реальном режиме надо всегда учитывать что у тебя лежит в DS, а что в ES. И сегмент данных далеко не всегда равняется сегменту кода. А чаще всего это два разных сегмента (или вернее дескриптора если пользоваться терминологией защищеного режима :) Знаешь, я был изначально в курсе насчёт всего этогго. :) Просто, когда я имел в виду "нет никакой фигни с сегментами" - имелась в виду, что не обязательно строго выписывать префикс сегментного регистра (по типу - CS:$0004) - так как сегмент всё равно один и CS и DS указывают именно на него. Сама винда, без сомнения, использует несколько (если не несколько тысяч :))разных дескрипторов (полагаю, один или более - на программу ил исполняемый файл), и как раз загоняется с ними по-черному. Но в программе, написанной под винду с этим нет нужды париться, так как "черную работу" берет на себя ОС. Просто всё, что относиться к сегментам и защищенному режиму, имеет довольно отдаленное отношение к lea eax, [eax+0]. (кстати, ещё версии есть насчёт того, что это?(склоняюсь к мысли, что это глюк компилятора)) Соответственно, не было причины все это упоминать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 15:19 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
возможно, в оригинале было Код: plaintext ------------------ - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 15:33 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
maXmoвозможно, в оригинале было Код: plaintext ------------------ - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm Знаешь, если честно, я не очень хорошо помню :(, кажется штук восемь функций WinAPI подряд, действительно несколько строковых. (что-то типа того, что вызывается GetWindowText - узнается длина строки, выделяется память, затем опять GetWindowTex но уже в новый буфер. Или аналогичная фишка с GetVolumeInformation) Факт, что этот "ляп" я реально видел несколько раз. (попробую листинги поискать...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2006, 15:49 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Всем участникам дискусии -- на курсы повышений квалификации :) Кто-нибудь здесь про страничную организацию памяти вообще слышал?? Изначально память в x86 адресовалась сегментно. Начиная с 80286 был введен механизм защиты, основанный на сегментах и тогда же появились все эти LDT, GDT, IDT. Пользуйтесь ими из под защищенного режима, созданного самостоятельно или через DPMI в досе, но это бесперспективно. Для создания модели памяти flat необходимо создавать огромные сегменты, но при этом теряется преимущество защиты, так как вся память оказывается доступна всем для всего. А маленькие сегменты возвращают все недостатки доса. В 80386 появилась страничная модель виртуализации памяти. То есть логическая страница через механизм TLB отображается на физическую страницу. Аттрибуты защиты у страниц персональные. Именно поэтому каждому процессу в win32 выделется сразу виртуальные 2Гб,которые по мере необходимости проецируются на страницы физической памяти. Манипуляция LDT итп производится только при старте системы, все выставляется от 0 и до конца памяти и более не используется, все манипуляции идут на уровне каталога страниц и таблиц страниц. Работа диспетчера памяти подробно описана хотя бы в Соломон, Руссинович: "Внутренее устройство Microsoft Windows". Специально для White Owl , процитирую оттуда: Руссинович Куча -- область зарезервированного адресного пространства размером в одну и более страниц, из которой диспетчер куч может выделять память меньшими порциями То есть созданы они для преодоления гранулярности выделения памяти квантом в одну страницу у функций вроде VirtualAlloc. Если же стартует программа Dos, то ntvdm переводит на квант времени ее функционирования процессов в режим V86 (виртуальный 8086). Программа получает кажущийся 1 Mb в начале адресного простанства. При необходимости эмулируется также EMS и XMS, но это все видимость, создаваемая драйверами ядра. Кстати, в ядре механизм работы принципиально не отличается, существует специальное системное страничное адресное пространство, в котором и работают элементы нулевого кольца. ________________________________________________________ Глюк - это высокоорганизованная система не поддающихся определению частиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2006, 22:07 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Кстати, сами по себе сегментные регистры используются, но это не играет существенной роли, так как память плоская. Например регистр FS указывает на начало структуры SEH (обработка исключений) процесса. ________________________________________________________ Глюк - это высокоорганизованная система не поддающихся определению частиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.06.2006, 22:19 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Кто-то говорил (кажется) насчет того, что прога, работающая с дровами, будет общаться с дескрипторами. Что-то я в DDK не видел об этом упоминания. 2 White Owl Как я помню, функции выделения памяти (GlobalAlloc), работы с кучей возвращают тебе HANDLE - т.е. число, которое фиг знает что обозначает (хотя на практике - наверняка указатель на что-то, по типу того, как HINSTANCE - указатель на начало загруженной программы, где нахордится EXE-заголовок.). Как я помню (я их не юзал, пардон, если ошибаюсь), его надо залочить, чтобы что-то с ним делать, а процедура залочивания возвращает тебе обычный указатель в пределах FLAT модели. Если ошибаюсь, поправьте. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 12:30 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
2 ErV: видимо действительно HANDLE кучи это указатель в какой-то внутренней таблице диспетчера памяти (как и все хендлы). Активно развивавшийся бред про дескрипторы наверно теперь исчезнет. ________________________________________________________ Глюк - это высокоорганизованная система не поддающихся определению частиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 15:38 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Юров-то хоть прав? А то обидно за мужика, учебник же писал :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 15:40 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
Юров пишет совершенно правильно, что прикладные проги не мучаются с сегменатами и используют единую плоскую модель. Код: plaintext Глюк - это высокоорганизованная система не поддающихся определению частиц ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 15:48 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
ой ли? А чо тогда в cs и ds разные значения? ------------------ - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 16:00 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
кстати да, я это тоже замечал в отладчике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 16:03 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
maXmoой ли? А чо тогда в cs и ds разные значения? ------------------ - А как в Интеpнете pаботать? - Сначала нужно узнать, что вам нужно rtfm Ну естественно они разные, так как секции кода и данных загружаются по разным адресам и логично установить сегментные регистры на соотв. секции. Но обращаться к данным по CS (Write-Protect аттрибут для кода установлен на уровне страниц, где размещен код), вам никто не мешает, только смещение надо правильное поставить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 17:59 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
LelikkНу естественно они разные, так как секции кода и данных загружаются по разным адресам и логично установить сегментные регистры на соотв. секции.Значит ядро все же сегментами заморачивается? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 18:26 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
White Owl....Зя! Вполне себе зя. Вызываешь функцию ДОС, запрашиваешь себе кусок памяти и усе. Нету больше вашего flat'а :) Это только при старте *.com ей операционкой выделялся кусок памяти равный размеру файла и сегментные регистры устанавливались на этот кусок. А дальше хоть всю память себе захапай, хоть в extended хоть в expanded лезь, никаких проблем совершенно..... усё верно но маленьчкий нюанс... перед вызовом "функции доса" - нуна вызвать ышо одну функцию (переаллокации памяти) - дабы "подтянуть" хвост отведённого сегмента под COM модель (по умолчанию от PSP и до упора). Иначе Вам досик вернёт аутлуп... прошу прощения, что вякнул - но досик же :) ... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 19:12 |
|
||
|
Вопрос по Ассемблеру.
|
|||
|---|---|---|---|
|
#18+
White Owl LelikkНу естественно они разные, так как секции кода и данных загружаются по разным адресам и логично установить сегментные регистры на соотв. секции.Значит ядро все же сегментами заморачивается? :) Давайте еще раз пройдемся по материалу (документации-то по этому вопросу кот наплакал, официальной тем более): 1) Сегментация памяти как была в x86, так и осталась, архитектура такая. Сегментацию обойти нельзя, так как нельзя исполнять код с неизвестно чем в CS. 2) В защищенном режиме процессов со времен 80286 также использует сегментацию, от этого опять никуда не деться. Сегментация задается таблицами LDT и GDT , и соответственно регистрами GDTR, LDTR итд. 3) Сегментация обеспечивает защиту на уровне сегментов, подкачку на уровне сегментов итд. И ИМЕННО ЭТО И НЕ ИСПОЛЬЗУЕТСЯ! Вот что имеют в виду, говоря про то, что сегменты не используются. 4) При инициализации процесса естесвенно создается LDT процесса, но в ней создаются только сегменты кода/данных пользователя и тоже для пространства адресов ядра выше 2Gb. ДАЛЕЕ НИКАКИХ манипуляций с ними не проводится, они были созданы для удовлетворения требований архитектуры. Проецирование памяти, ЗАЩИТА, управление подкачкой, отображение DLL на адресное пространство, работа с динамической памятью (кучи, VirualAlloc) -- все это работает только на основе МЕХАНИЗМА СТРАНИЧНОЙ ТРАНСЛЯЦИИ. Все, больше никто не меняет сегменты, "ни приложение, ни ядро с ними не заморачивается" (приложение о них и не знает даже). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2006, 19:23 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=33780887&tid=1346778]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
45ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
1ms |
| others: | 262ms |
| total: | 394ms |

| 0 / 0 |
