Mensajes

https://en.wikipedia.org/wiki/Program_Segment_Prefix

Hay algo que no me queda muy claro... se supone que ORG se utiliza para especificar el desplazamiento dentro del desplazamiento en el acceso a la memoria (datos). Sin embargo, ¿solo datos? ¿o añade este valor a otros tipos de referencias tambien?
...
¿que es lo que sucede cuando se ensambla la linea de codigo:
?

Codigo tambien; _oldISR seria 0409h de otra manera (aunque no podrias enlazarlo con tlink como .COM sin el ORG 0100h). Usa TD hookTSR.com y podras ver:

Si Windows carga los archivos COM identicamente como se encuentran en el archivo, ¿no se estaria especificando 100h unidades "extra" al direccionamiento, al especificar ORG 100h?

No. Un .COM es un archivo sin siquiera una misera cabecera asi que se carga tal cual es, MS-DOS pone antes el PSP: "Since it lacks relocation information, it is loaded by the operating system at a pre-set address, at offset 0100h immediately following the PSP, where it is executed (hence the limitation of the executable's size): the entry point is fixed at 0100h." https://en.wikipedia.org/wiki/COM_file

En realidad Windows emula los ejecutables de 16 bits   https://en.wikipedia.org/wiki/Virtual_DOS_machine#Windows_NTVDM

¿a que te refieres con "al menos para aprender"?

Me referia los comentarios de Michael Petch como: There is a difference between writing a bootloader from an academic perspective and targeting a particular VM/emulator/physical hardware but the shortcuts academics seem to take and teach doesn't necessarily make for the most portable mechanism. Anyone who is looking to write a real bootloader will know not to make any assumptions because they understand the ramifications. I should note that in PCDOS 2.1 not only did they explicitly set all the registers that included CS and they would do equivalent FAR JMP to a local label 0x0000:0x7C00+offset to set CS to 0.

[or]

¿para que sirve precisamente la instruccion ORG?
Se que delimita el origen del programa en la generacion de archivos COM pero, ¿a que se refiere esto precisamente? ¿No es el registro CS dependiente unicamente del cargador del sistema?

En el manual de TASM que te deje antes hay una explicacion. Un uso habitual - al menos para aprender - era este:
https://stackoverflow.com/questions/5611047/why-do-we-give-org-7c00-at-the-start-of-a-boot-program

Lo mismo respecto a la instruccion LEA...

LEA es un opcode y MOV es otro:
https://c9x.me/x86/html/file_module_x86_id_153.html
https://c9x.me/x86/html/file_module_x86_id_176.html

LEA se puede usar de mas maneras que tu ejemplo (alguna esta en el link de abajo de donde viene la siguiente cita), para el mismo:
"Another form of the MOV instruction is MOV reg,immdata which means read the immediate data (i.e. constant) immdata into register reg. Note that if the addr in LEA reg,addr is just a constant (i.e. a fixed offset) then that LEA instruction is essentially exactly the same as an equivalent MOV reg,immdata instruction that loads the same constant as immediate data."

https://stackoverflow.com/questions/1699748/what-is-the-difference-between-mov-and-lea

Tu programa debe tener un bug pero esto que nos pedis es para sacar la bola de cristal y adivinar.

Hablando de depuradores... no se si sea mas adecuado hacer un nuevo tema pero ¿existe una manera de que un depurador -o un depurador en si que- tenga permisos de ring 0? (me refiero a acceder a la memoria, escribir en puertos, etc...).

Si pero se necesitan dos maquinas (con una sola penas podes ver), la depurada puede ser virtual, y configurar el SO de la maquina depurada para que habilite el depurador de modo Kernel:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-kernel-mode-debugging-in-windbg--cdb--or-ntsd

No hay codigo para depurar pero si simbolos (PDBs en un servidor publico de Microsoft).

De esto puedo intentar deducir un monton de cosas aunque no se utilizar WinDbg.

Si vas a trabajar en Windows es el depurador por excelencia.

¿Entonces existe un solo manejador de excepcion el cual se encuentra en 053h:0?

No, es una cadena, por eso se usa la estructura, lee el enlace que deje antes. Si el primero de la lista retorna que no manejo el error entonces el proceso de la cadena continua llamando al siguiente.

Imagino que esta es la estructura... ¿por que termina en 0ffffffffh? es decir ¿no deberia tener un tamano fijo? 

La estructura tiene un tamaño fijo, son dos campos, el primero es un puntero a una estructura de su mismo tipo (para hacer la cadena; es una simple lista) y el segundo es el puntero al manejador, como decia el tamaño es fijo, dos punteros, dos DWORDs, 8 bytes (todo esto en 32 bits).

Bueno este debe ser el manejador... esto explica por que no podia repetirlo las veces que queria sin utilizar la pila.

Si, ese es el manejador de mi ejemplo (el que llama a ExitProcess), si simplemente lo pusiera en fs:[0] el codigo de Windows lo usaria como un puntero a la estructura y por eso fallaria.

[006ff930]

Es que no se pone un puntero a funcion ahi sino un puntero a una estructura que apunta a la estructura que estaba ahi anteriormente en su primer campo y tiene otro campo mas que es el puntero al manejador. Y asi es como se construye la cadena de manejadores.

Mas informacion en el archivo:
https://web.archive.org/web/20041011152640fw_/http://www.spiff.tripnet.se/~iczelion/Exceptionhandling.html

Y si depuramos con el WinDbg el siguiente ejemplo:

Código (asm) [Seleccionar] Expandir

.386
.model flat, stdcall

includelib kernel32.lib
ExitProcess PROTO stdcall :DWORD

.code
main:
int 3
assume fs:nothing

MOV ESI, OFFSET handler
PUSH ESI
PUSH DWORD PTR FS:[0]
MOV DWORD PTR FS:[0], ESP

xor eax, eax
mov eax, dword ptr [eax]
ret


handler:
invoke ExitProcess, 1
ret
end main

Podemos ver que al principio:
dd fs:0 l1
0053:00000000  006ff930

dd 006ff930 l2
006ff930  006ff948 77a788c0

u 77a788c0 l1
ntdll!_except_handler4:
77a788c0 8bff            mov     edi,edi

dd 006ff948 l2
006ff948  ffffffff 77a853d2

u 77a853d2 l1
ntdll!FinalExceptionHandlerPad50:
77a853d2 90              nop

Y no seguimos que ffffffff debe ser el señalador de fin de cadena.

Ahora ejecutamos nuestro programa hasta MOV DWORD PTR FS:[0], ESP

dd fs:0 l1
0053:00000000  006ff8d0

dd 006ff8d0 l2
006ff8d0  006ff930 008d101a ;en rojo la ultima estructura que existia hasta entonces

u 008d101a
seh+0x101a:
008d101a 6a01            push    1
008d101c e801000000      call    seh+0x1022 (008d1022)
008d1021 c3              ret


u 008d1022
seh+0x1022:
008d1022 ff2500208d00    jmp     dword ptr [seh+0x2000 (008d2000)]

dps 008d2000 l1
008d2000  754a4f20 KERNEL32!ExitProcessImplementation

https://en.wikipedia.org/wiki/2020_coronavirus_pandemic_in_Singapore
https://en.wikipedia.org/wiki/Singapore#Climate

El Covid-19 se descontrolo en Singapur donde hace calor siempre, promedio de maxima entre 30 y 32 durante todo el año, asi que mejor no apostar al clima como salvador por un cambio de estacion, es posible que ralentice la expansion del contagio pero no lo detiene por si solo.

Hace un mes ya se veia venir que lamentablemente el calor por si solo no iba a detener por completo la infeccion.

No se hacen tareas; leete esto mejor:
http://archive.worldofdragon.org/browse/downloads/Books/6809%20Assembly%20Language%20Programming%20-%20Leventhal%20%281981%29.pdf