🚀 go-pugleaf

Cymoril sin patas <ceinalem@thegym.net> wrote:

> Plas plas plas. Tas lucido, t�o. Como se nota que eres del GUI de
> Valladolid.
> De todas formas, me ha surgido una "peque�a" duda que igual me sabes
> responder.
> Aunque nunca llegu� a usarlo intensamente, bajo DJGPP (el gcc de DOS,
> por si alguien no lo sabe) permit�a usar ensamblador con la horrorosa
> sintaxis de AT&T, emulando las interrupciones bajo modo protegido. Mi
> pregunta es, � conmutaba a modo V86 o inclu�a c�digo sustituyente el
> propio compilador? (esta es de nota, eh !)

Los programas de DJGPP son en modo protegido nativo usando lo que se llama
un extensor de DOS.
Los extensores de DOS son programas que se encargan de realizar una interfaz
entre tu programa de modo protegido y el DOS en modo real o V86, de tal
manera que llamas a las interrupciones de manera similar a como lo har�as en
modo real , pero est�s en modo protegido (puedes tener segmentos de
diferente tama�o y pueden comenzar en cualquier punto de la memoria, existen
mecanismos de protecci�n de memoria y swap...
Los extensores no usan toda la capacidad de este modo que proporciona a
un SO, como son mecanismos especiales para multitarea, diferentes niveles de
privilegio, etc.
Estos, como ampliaci�n del DOS que es monotarea no requieren proporcionar
protecci�n entre aplicaciones (para que si solo hay una) o multitarea.
Los extensores funcionan "dando saltitos" entre modo real/V86 y modo 
protegido. Si se recibe un evento de hardware (por ejemplo una pulsaci�n de
teclado), saltan a la interrupci�n de DOS para ejecutar la interrupci�n
correspondiente como si hubiese estado trabajando en DOS todo el rato.
Algo similar ocurre con tu aplicaci�n en modo protegido, solo que traduce
tu llamada en formato "modo protegido" a formato cl�sico para ejecutarla
Para hacer estos saltitos se suele seguir este procedimiento:
Si estamos en V86, buscamos posibles interfaces para conmutar a modo
protegido:
Si disponemos de VCPI lo usamos para conmutar a modo protegido colocando
nuestras propias estructuras de control y hacediendo al m�ximo nivel de
privilegio (Ring 0)
Si no disponemos de VCPI, usamos los servicios DPMI delegando en control del
sistema en el servidor DPMI, funcionando al nivel de privilegio que quiera.
En este caso no cogemos el control, pero se nos proporcionan los servicios
para hacer las mismas cosas.
Si no hay DPMI, no se usar modo protegido (o sea que olvidate de correr el
Quake aqu� ;)
Si estamos en modo real usamos los mecanismos normales para conmutar a modo
protegido.

Es por esto que...
Con VCPI, podemos coger el control y saltar a modo protegido aunque
estuviesemos en V86.
Con DPMI, podemos usar modo protegido de una manera controlada y limitada de
manera que puede haber un SO encima que nos controle.
Es por eso que Linux/dosemu y Dos bajo Win proporcionan servicios DPMI (lo
necesario para correr el DOOM :) pero no VCPI.
Loadlin por ejemplo requiere VCPI (o estar en modo real, claro) pues necesita 
coger el control para arrancar el kernel de Linux. Es por esto por lo que no
se puede arrancar bajo una ventana de DOS.
Y cuando se est� en V86 y hay servicios VCPI?
Cuando se carga un controlados de memoria expandida...
Ah, pero �No sabiais que al cargar el EMM386 estais YA en modo protegido?
Cuanto tiempo enga�ados �verdad?
Pues si. La memoria que  los controladores de memoria expandida colocan en
los huecos existentes entre los 640Kb y 1024Kb, no est�n realmente  alojados
all�.
Al estar en modo protegido se pueden usar los mecanismos de memoria virtual,
de manera que los programas no acceden directamente a memoria f�sica sino
memoria l�gica que puede estar recolocada a nuestro antojo en bloques de 4Kb
sobre memoria f�sica.
Por eso, al ejecutar una interrupci�n antes de cargar el controlador de
memoria expandida, se realiza r�pidamente , pero despu�s resulta mucho m�s
lento ya que realmente se ejecuta la de modo protegido que tiene que
comprobar los valores de la llamada para volver a V86 para simular la
llamada que hiciste como si hubieras estado en modo real...
Ah. Por si no lo sab�ais el kernel de Win9x es el kernel de W311 para modo
protegido el cual no es m�s que un extensor de DOS avanzado que permite
varias tareas de V86 simult�neas y permite cargar Driver al estilo DOS pero
en modo protegido (VXD) que les permite capturar las interrupciones desde
modo protegido antes de simularlas en modo V86. A base de sustituir la BIOS
de disco por un driver VXD correspondiente, las de video, etc,etc...
vienvenidos a Win95!!
Eso si... de 311 a W95 han permitido que se puedan cargar aplicaciones en
modo protegido de 32 Bits (o... Lo que hacia el DOS4GW antes de Windows...)
O sea, chapuza total...
Quien no se lo crea que lea el libro "al descubierto Win95" (creo que era
este) que lo saqu� un dia de la biblio y me dej� de piedra...
 

> De todas formas, si mucho no me equivoco, se tiene que poder acceder a
> la bios de la tarjeta de v�deo para averiguar si es VESA o no (de una
> forma un poco bestia, claro). De hecho hay alg�n programa como Scitech
> Display Doctor para linux que por lo menos hace algo parecido.

Ya lo he comentado... Bajo V86 (el kernel de Linux provee una funci�n para
crear tareas de este tipo).
Tambi�n se puede a lo mejor mapeando las ROMs y analizando su contenido...
En eso si que ya no tengo ni idea...
De todas maneras me parece que el scitech usa sus propios drivers para
emular una VESA 2.0 o 3.0. Puesto que son sus drivers vete tu a saber como
lo hacen.

> Muschas grasias por la lecci�n de modo protegido.

De nada... Que por lo menos sirva de algo mis horas perdidas con el
ensamblador...
Por cierto... tambi�n es util para crear exploits del tipo buffer overflow
pero esa es otra historia que debe ser contada en otra ocasi�n. ;)

> P.D. Tras haber le�do tu art�culo, ahora s� porqu� Ciri no lleg� a
> sacar nunca 2M para Windows 95 ...

En efecto...De hecho yo pill� el kit de construcci�n de drivers para Win
(DDK) para ver si ser�a factible hacerlo como Dios manda y entonces me di
cuenta que Linux es el futuro (DIOS!!! Que caos para hacer un maldito
driver)

Un saludo..