Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
exeption 09.05.02 14:10
Автор: fly4life <Александр Кузнецов> Статус: Elderman
|
Встретился такой код:
mov si,0ffffh
mov WORD ptr [si],0 ;<-любое число
(Virtual mode)
В W98 режима выдается Прога выполнила недоп. опер и т.д(GP -Fault), в 2000 есесно вылетает без вопросов.
В реальном (в чистом досе) тоже вылетает без вопросов.
Вопрос: какое исключение генерируется в ДОСе?
|
|
exeption 09.05.02 23:25
Автор: :-) <:-)> Статус: Elderman
|
> Встретился такой код:
> mov si,0ffffh
> mov WORD ptr [si],0 ;<-любое число
>
> (Virtual mode)
>
> В W98 режима выдается Прога выполнила недоп. опер и т.д(GP
> -Fault), в 2000 есесно вылетает без вопросов.
> В реальном (в чистом досе) тоже вылетает без вопросов.
> Вопрос: какое исключение генерируется в ДОСе?
Исключение 13 (GPF) сгенерит 386+ на эот код в реальном режиме.
А если регистр SS
mov si,0ffffh
mov WORD ptr SS:[si],0
тогда - исключение 12 (Stack Fault)
|
| |
странный exсeption для реального режима 13.05.02 20:59
Автор: fly4life <Александр Кузнецов> Статус: Elderman
|
Веселые исключения для реального режима. Я о таких не слышал, нигде в документации я их не видел.
Но еще очень странно, что они генерятся не всегда, и в память ничего не пишется. По моим наблюдениям, генерятся только после запуска определенных приложений, TLINK, TD в их числе. Что они делают, что процессор начинает вырабатывать GP в реальнов режиме?!
|
| | |
странный exсeption для реального режима 14.05.02 20:29
Автор: :-) <:-)> Статус: Elderman
|
> Веселые исключения для реального режима. Я о таких не
> слышал, нигде в документации я их не видел.
> Но еще очень странно, что они генерятся не всегда, и в
> память ничего не пишется. По моим наблюдениям, генерятся
> только после запуска определенных приложений, TLINK, TD в
> их числе. Что они делают, что процессор начинает
> вырабатывать GP в реальнов режиме?!
Они всегда генерятся в реальном режиме. Результат зависит от обработчика исключения. TLINK, TD тут скорее всего не причем.
Открываем Ральфа Брауна и смотрим Int 0C, 0D
INT 0D C - CPU-generated (80286+) - GENERAL PROTECTION VIOLATION
Desc: the CPU generates this interrupt when it detects a protection violation
which does not fit under any other category having a separate
interrupt
Notes: called in real mode when
an instruction accesses a memory operand extending beyond offset
FFFFh (i.e. WORD at FFFFh or DWORD at FFFDh or higher) in segment
CS, DS, ES, FG, or GS
INT 0C C - CPU-generated (80286+) - STACK FAULT
Desc: this interrupt is generated in protected mode on a stack overflow or
underflow, or if an inter-level transition or task switch references
a stack segment marked "not present"; it is generated in real mode
on accessing a word operand at SS:FFFFh
Проверить очень просто
#include <dos.h>
#include <stdio.h>
#include <stdlib.h>
void interrupt Int0D(...)
{
printf("Int 0Dh\n");
exit(0);
}
void main()
{
setvect(0xD, Int0D);
asm mov ax, ds:[0xFFFF]
}
---
При запуске в чистом ДОС выводится
Int 0Dh
Никаких TD, TLINK перед этим я не запускал :-))
C Int 0C аналогично.
|
| | |
странный exсeption для реального режима 14.05.02 01:05
Автор: Killer{R} Статус: Незарегистрированный пользователь
|
> Веселые исключения для реального режима. Я о таких не
> слышал, нигде в документации я их не видел.
> Но еще очень странно, что они генерятся не всегда, и в
> память ничего не пишется. По моим наблюдениям, генерятся
> только после запуска определенных приложений, TLINK, TD в
> их числе. Что они делают, что процессор начинает
> вырабатывать GP в реальнов режиме?!
Переводят процессор в v86("виртульнай") режим.
|
| | | |
странный exсeption для реального режима 14.05.02 01:18
Автор: fly4life <Александр Кузнецов> Статус: Elderman
|
> Переводят процессор в v86("виртульнай") режим.
Была такая идея,но для чего TLINKу переводить процессор в защищенный режим, а потом еще и в виртуальный? Зачем столько геморроя для линковки, когда это проще сделать в реальном?
|
| | | | |
В реальном однако памяти маловато 14.05.02 04:03
Автор: Dr.Golova Статус: Незарегистрированный пользователь
|
|
|
| | | | | |
В реальном однако памяти маловато 14.05.02 11:19
Автор: fly4life <Александр Кузнецов> Статус: Elderman
|
Для TKINKа я думаю 640к хватит.
Даже если переходит таким извращенным способом, то ведб все равно возвращается. Неужели исключения защищенного режима после этого будут работать в реальном?
Може попытаться еще сгенерировать и Page Fault :) ?
|
|
exeption 09.05.02 21:42
Автор: + <Mikhail> Статус: Elderman
|
> Встретился такой код:
> mov si,0ffffh
> mov WORD ptr [si],0 ;<-любое число
>
> (Virtual mode)
>
> В W98 режима выдается Прога выполнила недоп. опер и т.д(GP
> -Fault), в 2000 есесно вылетает без вопросов.
> В реальном (в чистом досе) тоже вылетает без вопросов.
> Вопрос: какое исключение генерируется в ДОСе?
Poprobui postavit exception handler i posmotret`.:
class Exception
{
private:
unsigned int m_n;
public:
Exception( unsigned int n ) : m_n( n ) {}
~Exception() {}
unsigned int GetNumber() { return m_n; }
};
void trans_func( unsigned int, EXCEPTION_POINTERS* pe)
{
throw Exception(pe->ExceptionRecord->ExceptionCode);
};
int main(int argc, char* argv[])
{
::_set_se_translator(trans_func);
try
{
_asm
{
mov si,0ffffh
mov WORD ptr [si],0 ;<-любое число
}
}catch(Exception e)
{
unsigned int i;
i = e.GetNumber();
}
}
|
| |
exeption 14.05.02 01:39
Автор: Sidor Статус: Незарегистрированный пользователь
|
Я бы с большим наслаждением посмотрел, как этот код будет работать
под ДОС в реальном режиме!
Такая искл. ситуация обычно не происходит в действительном режиме, но может быть вызвана созданием ситуации, где операнд частично выходит за
ограничение 64К сегмента. Так шо , всё-таки, проц генерит int 0Dh . А там
в обработчике скорее всего int 20h какой-то.
|
| | |
exeption 14.05.02 01:57
Автор: fly4life <Александр Кузнецов> Статус: Elderman
Отредактировано 14.05.02 02:03 Количество правок: 1
|
> Я бы с большим наслаждением посмотрел, как этот код будет
> работать
> под ДОС в реальном режиме!
>
> Такая искл. ситуация обычно не происходит в
> действительном режиме, но может быть вызвана созданием
> ситуации, где операнд частично выходит за
> ограничение 64К сегмента. Так шо , всё-таки, проц генерит
> int 0Dh . А там
> в обработчике скорее всего int 20h какой-то.
Ни фига!
1) не кажется ли тебе, что для РЕАЛА это исключение странно. В досе оно используется для LPT2.
2) Если оно (исключение 0dh,0ch) генерится, то тачка вешается, и остается молиться богам CTRL+ALT+DEL или RESET
3) Если ниче не генерится, то по этому адресы все равно ничего не записывается и прога работает дальше!
|
| | | |
exeption 14.05.02 22:56
Автор: the_unforg Статус: Незарегистрированный пользователь
|
> Ни фига!
> 1) не кажется ли тебе, что для РЕАЛА это исключение
> странно. В досе оно используется для LPT2.
> 2) Если оно (исключение 0dh,0ch) генерится, то тачка
> вешается, и остается молиться богам CTRL+ALT+DEL или RESET
> 3) Если ниче не генерится, то по этому адресы все равно
> ничего не записывается и прога работает дальше!
Однако ж, в TurboC++ 3.0 ежели где-нить сделать что-то типа такого:
int *a;
....
*a = 1;
т.е. null pointer assignment, то при запуске это ведет себя двояко:
Вариант 1)как правило при завершении работы вылетает сообщение null pointer assignment, и все ОК, работаем дальше,
Вариант 2) GPF, причем не в виде "синего экрана смерти", а просто появляется строка такого вида: Exception 13 (General Protection Fault) at address ...., и все, висим.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
