Foro de elhacker.net

EI: del Cache de Google:
cache:http://foro.elhacker.net/programacion_cc/codigo_basura_de_gcc-t384404.0.html

---

Hola a todos. A ver a ver cómo empezar...

Antes que nada, me disculpo de la forma cómo hablo ya que no soy muy bueno escribiendo en foros (sí en blogs, por ejemplo el mío). No quiero ofender a nadie.

Bueno, estoy programando un sistema operativo de 32 bits como hobby (No soy un novato más). Estuve como 5 meses leyendo y leyendo (claro, aparte del tiempo que estuve estudiando por mi cuenta asm de 16 bits - no mucho pero me sirvió para hacer un micro-so :P), haciendo pruebas y encontré un manual de paso a paso cómo iniciar un kernel. Bueno ya tengo mi kernel que inicia el GDT, IDT, el teclado, la disquetera, y algunas otras cosas (no menos importantes).

La cosa es que estuve programando y re-programando (volviendo a programar para corregir errores y mejorarlos) algunos drivers básicos (ya saben) y como tenía tanto código cada compilada se comenzaba a demorar más y más en compilar (y nada en ejecutar :D) y se me ocurrió cargar un archivo en la memoria y luego ejecutarlo (call).

Como siempre estuve haciendo pruebas tras pruebas, investigando como loco y cuando me puse a descansar un rato se me vino la solución a la cabeza y listo! pude ejecutar un archivo ensamblado con nasm en mi kernel usando una interrupción del IDT (int 0x80 - mostrar un texto en la pantalla) y todo funciona ok.

Ahora quise que un programa compilado con un lenguaje de alto nivel (C) se pudiera ejecutar en mi kernel y después de 2 días pude lograrlo.. A medias... Lo que pasa es que me ejecuta el código pero cuando termina la ejecución se genera un page fault (excepción) y estuve revisando el por qué, adjunto el código del archivo de C, el linker script, el batch y las imágenes que tengo:


LINKER SCRIPT (los comentarios que ves los agregué al postear)


PROGRAMA EN C (GCC)

BATCH

// Yo mismo lo hice xD


Bueno acá van las imágenes.

1. Aquí veo un código "basura" el cual me parece que mi kernel no lo entiende o no sé que sea :S

CÓDIGO OBJETO OBTENIDO POR GCC. Lo seleccionado es lo que me parece que es el problema.

(http://img526.imageshack.us/img526/3058/objetoprogramahex.png)

2. Aquí se repite el código. Extrañamente se fue al final del archivo binario :¬¬

(http://img69.imageshack.us/img69/7665/programahex.png)


Cuando borro el código seleccionado manualmente en el binario se ejecuta mi programa normalmente.

Por cierto mis primeros lenguajes de programación entre comillas fueron HTML, javascript (tenía 9 años xD), después a los 13 aprendí VB.NET que es el lenguaje que siento que soy muy bueno (llevo años..) y a los 17 (masomenos) aprendí C++ (me adapté al C luego :p) y asm tuve que estudiarlo a la fuerza (obviamente no soy tan bueno pero me defiendo). Todo esto fue por mi cuenta.

No sé si alguien podría ayudarme o darme una pista para poder entender qué cosa es ese código que sobra y cómo podría eliminarlo o no ejecutarlo.

POSDATA: Mi kernel ejecuta desde el indice 0 del archivo (no ejecuta PE ni ELF, sólo binarios)

Gracias por haber leído tal discurso :)

Usando dumpbin del VC++ en test.o:

---

Dump of file test.o

File Type: COFF OBJECT

FILE HEADER VALUES
             14C machine (x86)
               5 number of sections
               0 time date stamp Thu Jan 01 01:00:00 1970
             178 file pointer to symbol table
               E number of symbols
               0 size of optional header
             104 characteristics
                   Line numbers stripped
                   32 bit word machine

SECTION HEADER #1
   .text name
       0 physical address
       0 virtual address
      18 size of raw data
      DC file pointer to raw data (000000DC to 000000F3)
     164 file pointer to relocation table
       0 file pointer to line numbers
       1 number of relocations
       0 number of line numbers
60300020 flags
         Code
         4 byte align
         Execute Read

RAW DATA #1
  00000000: 55 89 E5 83 EC 10 C7 45 FC 00 00 00 00 31 C0 8B  U.å.ì.ÇEü....1À.
  00000010: 5D FC CD 80 C9 C3 90 90                          ]üÍ.ÉÃ..

RELOCATIONS #1
                                                Symbol    Symbol
 Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000009  DIR32                      00000000         A  .rdata

SECTION HEADER #2
   .data name
       0 physical address
       0 virtual address
       0 size of raw data
       0 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0300040 flags
         Initialized Data
         4 byte align
         Read Write

SECTION HEADER #3
    .bss name
       0 physical address
       0 virtual address
       0 size of raw data
       0 file pointer to raw data
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0300080 flags
         Uninitialized Data
         4 byte align
         Read Write

SECTION HEADER #4
  .rdata name
       0 physical address
       0 virtual address
      38 size of raw data
      F4 file pointer to raw data (000000F4 to 0000012B)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40300040 flags
         Initialized Data
         4 byte align
         Read Only

RAW DATA #4
  00000000: 48 6F 6C 61 20 6D 75 6E 64 6F 20 64 65 73 64 65  Hola mundo desde
  00000010: 20 47 43 43 20 28 49 6E 74 65 6C 20 53 79 6E 74   GCC (Intel Synt
  00000020: 61 78 2C 20 70 72 6F 67 72 61 6D 61 2E 65 78 65  ax, programa.exe
  00000030: 29 20 76 32 21 00 00 00                          ) v2!...

SECTION HEADER #5
      /4 name (.eh_frame)
       0 physical address
       0 virtual address
      38 size of raw data
     12C file pointer to raw data (0000012C to 00000163)
     16E file pointer to relocation table
       0 file pointer to line numbers
       1 number of relocations
       0 number of line numbers
40300040 flags
         Initialized Data
         4 byte align
         Read Only

RAW DATA #5
  00000000: 14 00 00 00 00 00 00 00 01 7A 52 00 01 7C 08 01  .........zR..|..
  00000010: 1B 0C 04 04 88 01 00 00 1C 00 00 00 1C 00 00 00  ................
  00000020: 04 00 00 00 16 00 00 00 00 41 0E 08 85 02 42 0D  .........A....B.
  00000030: 05 52 C5 0C 04 04 00 00                          .RÅ.....

RELOCATIONS #5
                                                Symbol    Symbol
 Offset    Type              Applied To         Index     Name
 --------  ----------------  -----------------  --------  ------
 00000020  REL32                      00000004         4  .text

COFF SYMBOL TABLE
000 00000000 DEBUG  notype       Filename     | .file
    test.c
002 00000000 SECT1  notype ()    External     | _inicio
    tag index 00000000 size 00000000 lines 00000000 next function 00000000
004 00000000 SECT1  notype       Static       | .text
    Section length   16, #relocs    1, #linenums    0, checksum        0
006 00000000 SECT2  notype       Static       | .data
    Section length    0, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT3  notype       Static       | .bss
    Section length    0, #relocs    0, #linenums    0, checksum        0
00A 00000000 SECT4  notype       Static       | .rdata
    Section length   36, #relocs    0, #linenums    0, checksum        0
00C 00000000 SECT5  notype       Static       | .eh_frame
    Section length   38, #relocs    1, #linenums    0, checksum        0

String Table Size = 0x18 bytes

  Summary

           0 .bss
           0 .data
          38 .eh_frame
          38 .rdata
          18 .text

---

Idem en el test:

Dump of file test

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               3 number of sections
        5130DE02 time date stamp Fri Mar 01 17:57:38 2013
             A00 file pointer to symbol table
              27 number of symbols
              E0 size of optional header
             307 characteristics
                   Relocations stripped
                   Executable
                   Line numbers stripped
                   32 bit word machine
                   Debug information stripped

OPTIONAL HEADER VALUES
             10B magic # (PE32)
            2.22 linker version
             200 size of code
             400 size of initialized data
               0 size of uninitialized data
        FFC10000 entry point (100010000)
        FFC10000 base of code
               0 base of data
          400000 image base (00400000 to 100011FFF)
            1000 section alignment
             200 file alignment
            4.00 operating system version
            1.00 image version
            4.00 subsystem version
               0 Win32 version
        FFC12000 size of image
             200 size of headers
            F21E checksum
               3 subsystem (Windows CUI)
               0 DLL characteristics
          200000 size of stack reserve
            1000 size of stack commit
          100000 size of heap reserve
            1000 size of heap commit
               0 loader flags
              10 number of directories
               0 [       0] RVA [size] of Export Directory
               0 [       0] RVA [size] of Import Directory
               0 [       0] RVA [size] of Resource Directory
               0 [       0] RVA [size] of Exception Directory
               0 [       0] RVA [size] of Certificates Directory
               0 [       0] RVA [size] of Base Relocation Directory
               0 [       0] RVA [size] of Debug Directory
               0 [       0] RVA [size] of Architecture Directory
               0 [       0] RVA [size] of Global Pointer Directory
               0 [       0] RVA [size] of Thread Storage Directory
               0 [       0] RVA [size] of Load Configuration Directory
               0 [       0] RVA [size] of Bound Import Directory
               0 [       0] RVA [size] of Import Address Table Directory
               0 [       0] RVA [size] of Delay Import Directory
               0 [       0] RVA [size] of COM Descriptor Directory
               0 [       0] RVA [size] of Reserved Directory


SECTION HEADER #1
   .text name
      18 virtual size
FFC10000 virtual address (100010000 to 100010017)
     200 size of raw data
     200 file pointer to raw data (00000200 to 000003FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
60300020 flags
         Code
         RESERVED - UNKNOWN
         RESERVED - UNKNOWN
         Execute Read

RAW DATA #1
  100010000: 55 89 E5 83 EC 10 C7 45 FC 18 00 01 00 31 C0 8B U.å.ì.ÇEü....1À.
  100010010: 5D FC CD 80 C9 C3 90 90                         ]üÍ.ÉÃ..

SECTION HEADER #2
  .rdata name
      38 virtual size
FFC10018 virtual address (100010018 to 10001004F)
     200 size of raw data
     418 file pointer to raw data (00000418 to 00000617)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40300040 flags
         Initialized Data
         RESERVED - UNKNOWN
         RESERVED - UNKNOWN
         Read Only

RAW DATA #2
  100010018: 48 6F 6C 61 20 6D 75 6E 64 6F 20 64 65 73 64 65 Hola mundo desde
  100010028: 20 47 43 43 20 28 49 6E 74 65 6C 20 53 79 6E 74  GCC (Intel Synt
  100010038: 61 78 2C 20 70 72 6F 67 72 61 6D 61 2E 65 78 65 ax, programa.exe
  100010048: 29 20 76 32 21 00 00 00                         ) v2!...

SECTION HEADER #3
.eh_fram name
      38 virtual size
FFC11000 virtual address (100011000 to 100011037)
     200 size of raw data
     800 file pointer to raw data (00000800 to 000009FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
40300040 flags
         Initialized Data
         RESERVED - UNKNOWN
         RESERVED - UNKNOWN
         Read Only

RAW DATA #3
  100011000: 14 00 00 00 00 00 00 00 01 7A 52 00 01 7C 08 01 .........zR..|..
  100011010: 1B 0C 04 04 88 01 00 00 1C 00 00 00 1C 00 00 00 ................
  100011020: E0 EF FF FF 16 00 00 00 00 41 0E 08 85 02 42 0D àïÿÿ.....A....B.
  100011030: 05 52 C5 0C 04 04 00 00                         .RÅ.....

COFF SYMBOL TABLE
000 0000000A DEBUG  notype       Filename     | .file
    test.c
002 00000000 SECT1  notype ()    External     | _inicio
    tag index 00000000 size 00000000 lines 00000000 next function 00000000
004 00000000 SECT1  notype       Static       | .text
    Section length   16, #relocs    1, #linenums    0, checksum        0
006 00000000 SECT2  notype       Static       | .rdata
    Section length   36, #relocs    0, #linenums    0, checksum        0
008 00000000 SECT3  notype       Static       | .eh_frame
    Section length   38, #relocs    1, #linenums    0, checksum        0
00A 00000000 SECT2  notype       External     | rdata
00B 00000000 SECT2  notype       External     | rdata_end
00C 00000000 ABS    notype       External     | __dll_characteristics__
00D 00001000 ABS    notype       External     | __size_of_stack_commit__
00E 00200000 ABS    notype       External     | __size_of_stack_reserve__
00F 00000004 ABS    notype       External     | __major_subsystem_version__
010 00000018 SECT1  notype       External     | text_end
011 00001000 ABS    notype       External     | __size_of_heap_commit__
012 00000000 ABS    notype       External     | __dll__
013 00000000 ABS    notype       External     | __minor_os_version__
014 00400000 ABS    notype       External     | __image_base__
015 00001000 ABS    notype       External     | __section_alignment__
016 00011038 ABS    notype       External     | end
017 00000038 SECT3  notype       External     | bss_end
018 00000038 SECT3  notype       External     | bss
019 00000200 ABS    notype       External     | __file_alignment__
01A 00000038 SECT3  notype       External     | data
01B 00000004 ABS    notype       External     | __major_os_version__
01C 00100000 ABS    notype       External     | __size_of_heap_reserve__
01D 00400000 ABS    notype       External     | ___ImageBase
01E 00000003 ABS    notype       External     | __subsystem__
01F 00000000 SECT2  notype       External     | rodata_end
020 00000001 ABS    notype       External     | __major_image_version__
021 00000000 ABS    notype       External     | __loader_flags__
022 00000000 SECT1  notype       External     | code
023 00000000 ABS    notype       External     | __minor_subsystem_version__
024 00000000 ABS    notype       External     | __minor_image_version__
025 00000000 SECT2  notype       External     | rodata
026 00000038 SECT3  notype       External     | data_end

String Table Size = 0x195 bytes

  Summary

        1000 .eh_fram
        1000 .rdata
        1000 .text

---

De cualquier manera no se como eso pueda afectar, antes esta el codigo (y la sección .rdata tambien) y este termina con un ret por lo cual deberia devolver el control al Kernel ... no me gusta adivinar y sin tener el resto del sistema es lo unico que podemos hacer. ¿Seguro ves el mensaje en pantalla antes de la excepcion? ¿Seguro cargaste el programa.exe en 0x10000, no? Si _inicio no es 0x10000 es facil que se genere una excepcion al acceder a cualquier parte ... la cadena tiene que estar en la direccion de memoria 0x10018 para que funcione ...

_inicio:
  00000000: 55                 push        ebp
  00000001: 89 E5              mov         ebp,esp
  00000003: 83 EC 10           sub         esp,10h
  00000006: C7 45 FC 00 00 00  mov         dword ptr [ebp-4],offset .rdata
            00
  0000000D: 31 C0              xor         eax,eax
  0000000F: 8B 5D FC           mov         ebx,dword ptr [ebp-4]
  00000012: CD 80              int         80h
  00000014: C9                 leave
  00000015: C3                 ret
  00000016: 90                 nop
  00000017: 90                 nop

PD. Esta no es una pregunta sobre C/C++ sino sobre un compilador en particular, nadie mejor que el desarrollador del mismo para responderte con precision.

Sí, el programa se carga en esa dirección de memoria. Uso memmove para mover los datos a esa dirección de memoria. Me muestra el mensaje, y también me parece extraño que se ejecute el otro código (ya que sale con un ret). ¿Alguna idea? Investigaré un poco más mi código en estas horas.

---

EI: juntando mensajes. No escribas mensajes consecutivos, edita.

---

Bueno, estuve revisando y encontré una supuesta solución (no funciona):

gcc -march=i686 -std=gnu99 -ffreestanding -c test.c -masm=intel
strip -R .eh_frame test.o
ld -o test -Tlink.ld test.o
objcopy -S -O binary test ..\programa.exe

¿está bien quitar esa sección? porque ahora no me muestra ningún mensaje. Cualquier noticia vuelvo a publicar.

EDIT:

Quedó así con el ndisasm:


Y adjunto la imagen resultante (archivo final):

(http://imageshack.us/scaled/landing/856/capturawt.png)

Sigo sin comprender por qué tanto código (disculpa la ignorancia) ya que mi código en nasm sólo hice esto:



EDIT 2:

 :o

Y ahora que lo reviso bien el código no me genera ninguna excepción hasta que intento ejecutar el mismo comando. Voy adelantando: mi sistema usa una línea de comandos con múltiples pantallas (eso es lo de menos). Me explico mejor: el comando "ejecutar" (es temporal) ejecuta el programa "programa.exe" con normalidad (sin el strip) hasta que escribo el mismo comando y PAGE FAULT!. Lo más extraño es que funciona normal con nasm, y como ya había mensionado con el gcc pero quitando los supuestos bytes "basura" (garbage)

¿Ejecuta el programa sin problemas una vez? Entonces esta claro que el problema es tu sistema y no los bytes posteriores al ret que nunca se llegan siquiera a ejecutar.

Sí, tienes razón. Estuve revisando y el problema desaparece al quitar el "free" del administrador de memoria. Extraño.. super extraño. Ahí voy a sufrir ya que es muy complejo ese administrador de memoria :S


EDIT 1:

Pero aún así quiero saber qué son esas instrucciones (como dije no soy experto en asm). Por qué el gcc las crea y para qué. Sólo por curiosidad; y ¿está bien quitar la sección con strip?

EDIT 2:

Estoy probando el administrador de memoria con un ejemplo pequeño - usando 100000 bytes de memoria - y no me presenta problemas. Puede ser que la posición de memoria asignada por el programa ejecutable no sea la adecuada o algo así. Esa parte la tengo que estudiar bien. De todas maneras gracias por sacarme de varias dudas.

EDIT 3:

Alaa otro problema: El administrador de memoria parece estar bien. Resulta que todo está bien cuando descomento esta línea:


Que es la que ejecuta los bytes en la variable "programa". No sé que está pasando, en serio; ya probé de todo :(

No son instrucciones, no es codigo, si te fijas es una sección de solo lectura ("Read Only" dice en el output de dumpbin).

Depura instruccion por instruccion hasta ver en cual falla exactamente y ahi mira los registros, la pila, etc..

Acabo de hacer una depuración simple y el error está en call. Depuración simple es para mi por ejemplo:


PSEUDOCÓDIGO:

IMPRIMIR "leer archivo - inicio"
LEER_ARCHIVO
IMPRIMIR "leer archivo - fin"
etc...

Cualquier novedad aviso. Ahora voy a depurar con bochs

EDIT

Luego de corregir un problema que tenía con el bochs y la disquetera he descubierto algo que no tiene mucho sentido.  :o

El error sigue ocurriendo pero cuando imprimo el contenido de la variable con un for y luego ejecuto el programa funciona todo correctamente.

Explicándome mejor:

Al solamente ejecutar el código con call sucede el page fault pero al imprimir la memoria de la variable en los dos casos (antes de copiarla a 0x10000 y después de copiarla) todo funciona normal.


EDIT 2

Una consulta. Por partes del manual que lei vi que se corregían algunos errores como ese page fault aumentando o disminuyendo el registro esp; ¿qué es lo que hace ese registro? no lo entiendo.


¡NOTICIA!

SOLUCIONÉ EL PROBLEMA

_asm pusha
_asm call programa
_asm popa

Pues lo que hice fue poner en el stack a los registros y luego liberarlos. Pero aún no entiendo el por qué :S ¿Alguien sabe la respuesta?

NOTICIA 2:

La solución era:

1. Abrir el archivo
2. Crear un buffer para los datos del archivo (malloc)
3. Leer el archivo y almacenarlo en el buffer
4. CREAR OTRA VARIABLE con la dirección de memoria 0x10000
5. Copiar el contenido del buffer a 0x10000
6. Liberar el buffer (free)
7. Ejecutar 0x10000
8. NO Liberar 0x10000 (no se debe liberar)

Gracias y ahí está la solución por si alguna otra persona como yo (:P) tiene un problema similar xD

Gracias por todo. Problema solucionado


(http://img687.imageshack.us/img687/2917/capturamuy.png)

YEAH  ::)

ESP = EXTENDED STACK POINTER. Es justamente el puntero a la pila (stack).

Por lo que pude entender el problema era que tu Kernel (asumo que esta escrito en C/C++) no contaba con lo que podia pasar en la funcion a la que llamabas por lo que si el compilador usaba algun registro (en este caso deberia ser EBX) para contener un puntero por ejemplo despues al hacer el call programa ese codigo lo cambiaba y entonces ... en fin ... ahora preservas los registros y funciona.


Si tenes ganas de probar podes ver que pasa si en lugar de usar inline assembly usas C:

Comparando el codigo ensamblador de tu Kernel podras ver si usaba EBX y si el compilador decide cambiar las cosas de alguna manera  :silbar:

:o increible gracias :)

Fíjate el la solución 2 ya no uso el pusha ni el popa (aunque no lo dije :P). Creo que el problema fue que nunca liberé la memoria del buffer ya que la moví directamente a 0x10000.

De nada; y bueno, vaya uno saber, sin ver el codigo nada mas se puede adivinar pero si el problema era de memoria tiene sentido que funcionara una vez. Igual la clave esta en que puedas depurar en ensamblador instruccion por instruccion tu codigo, asi vas a ver siempre donde falla exactamente.

Sí eso es lo que pensaba, pero el único debugger que "conozco" (entre comillas) es bochs y la verdad que con mis pocos conocimientos de asm (me confunde muchas instrucciones) no me ayuda mucho. Lo que me ayuda más es el print, es decir voy imprimiendo "estados" como pseudocódigo en la pantalla (obviamente puede fallar cuando se trata de problemas en el administrador de memoria, pero si no hay problemas sí sirve). En el caso del esp, ebp, esi y edi estoy super perdido. La mayoría de los manuales y guías están en inglés y la verdad que yo me confundo cuando es demasiado contenido. No es que no quiera estudiar o algo por el estilo sino que es mucho más sencillo leer información en español hasta incluso testear códigos e ir poco a poco solucionando los problemas a leer un manual inmenso en inglés (que me defiendo pero como digo me confundo si es demasiado). Puedo entender una cosa y es otra o cosas así. Gracias por todo, me diste ánimos ya que me había desanimado. Bueno mientras estaba solucionando ese problema del gcc también creaba un algoritmo para ejecutar programas PE y sí que es más difícil de lo que pensaba.

Ensamblador en teoría es fácil de aprender  porque tiene "pocas instrucciones"(muchas menos que otros lenguajes) pero vamos lo de los registros no es complicado encontrar su uso (los registros son de 16, 32 y 64 bits respectivamente):

• AX/EAX/RAX: se usan como acumulador
• BX/EBX/RBX: se usan como base de indexación (para los arrays)
• CX/ECX/RCX: se usan como contador
• DX/EDX/RDX: para datos y en general
• SI/ESI/RSI: se usa como fuente (apuntando a una cadena) para operaciones con cadenas.
• DI/EDI/RDI: se usa como destino para operaciones con cadenas.
• SP/ESP/RSP: apunta a lo alto de la pila
• BP/EBP/RBP: se usa como puntero base de la pila para mantener la dirección del marco de pila actual.
• IP/EIP/RIP: apunta a la instrucción que se está ejecutando.

De todas maneras puedes hacer uso del manual de intel(no está en español) para encontrar el uso de cualquier registro o instrucción:
http://download.intel.com/products/processor/manual/253666.pdf
Este libro está en español y no está nada mal:
http://foro.elhacker.net/asm/lenguaje_ensamblador_para_computadoras_basadas_en_intelkip_r_irvine_espanol-t364651.0.html

Gracias por la información avesudra pero juraba que las instrucciones estaban dentro de la CPU

Bueno, es la CPU quien las interpreta. Creo que me has entendido mal porque no he dicho que estén fuera  :laugh:

Por cierto bastante interesante el post, que chulo tener tu S.O.

 :laugh:


Está bueno el manual, muy bueno  ;-)

+1

@Avesudra, aprender bien el tutorial basico de ensamblador que estas leyendo

No lo estoy leyendo, quizás no debería haber dicho nada, por eso he puesto lo de "en teoría". Me refería a que las instrucciones de ensamblador son más fáciles de aprender o recordar que todos los nombres de las funciones de la librería math o string de C. Se me ha tomado como un idiota pero vamos prefiero que me lo digan claro a que lo hagan con una sonrisa. Disculpad mi ignorancia.

¡Un saludo!

Sí xD pensé que me estaba equivocando y me pareció gracioso cuando comentaste eso.

Bueno, alguien sabe si no es mucha molestia un manual de modo protegido en español. Me serviría bastante. No importa si es asm (que sea sintaxis intel por favor) o si es C/C++. Gracias.

Sobre todo ejecutar de alguna forma interrupciones de la BIOS mediante out o algo así :P


Para Eternal Idol 7D:

Logré hacer algo interesante con el código que me pasaste:

Antes que nada el pusha y popa son necesarios ya que me mueve la pila creo el programa (esp creo).

_asm pusha
int r = ((int(*)(void))programa)();
_asm popa

pantalla.Escribir("\nEl resultado de la aplicación fue: %i", r);

pusha y popa ponen y sacan todos los registros generales de la pila (por eso decia antes que los preservabas, antes y despues de la llamada tendran el mismo valor de esa manera).

http://css.csail.mit.edu/6.858/2010/readings/i386/PUSHA.htm
http://css.csail.mit.edu/6.858/2012/readings/i386/POPA.htm

¿Que pasa si usas push EBX y POP EBX? ¿Funciona? Si es asi es por lo que te explique antes. Por cierto cuando haces un call tambien se mueve la pila, para poner la direccion de retorno.

PD. Si queres informacion sobre otros temas te recomiendo Google y sino el sub/foro que corresponda asi no desviamos este hilo que esta practicamente resuelto.

ah ok perdon no sabía gracias. Hasta otro hilo :) DECLARO FIN DEL TEMA