Foro de elhacker.net

Me salen dos errores cuando trato de instalar masm32 en mi computadora windows 8 de 64 bits

los errores son los siguientes:
inc2l.exe: No se encuentra el ordinal 202 en la biblioteca de vínculos dinámicos C:\WINDOWS\AppPatch\AcLayers.dll

inc2l.exe: No se encuentra el ordinal 200 en la biblioteca de vínculos dinámicos C:\WINDOWS\AppPatch\AcGenral.dll

Se instala y todo pero no sé si eso traerá problemas cuando ya esté programando  :-[


También cuando trato de ensamblar el siguiente código:

.model small 
.486 
.stack 64 
.data 
CR equ 13 
LF equ 10 
cadena db 'Hola Mundo 32 bits!$',CR,LF 
.code 
inicio: 
mov eax,@data 
mov ds,eax 
 
mov eax,0900h 
lea edx,cadena 
int 21h 
 
mov eax,4c00h 
int 21h 
 
end inicio 
 

me sale el siguiente error:
/z2
"as.obj"
"as.exe"
NUL
LINK : warning LNK4044: unrecognized option "z2" ignored
LINK : error : segment referene in fixup record
as.obj : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

ya traté de ensamblar otros código y el error es el mismo ahora quisiera saber si esos errores al ensamblar son por culpa del error al momento de instalar el masm  :-\

No hay problema en general por esos errores al instalar.

El codigo no tiene sentido, es de 16 bits en realidad, por mas que le pongas 32. La interrupcion 21h es de MS-DOS, tenes que trabajar en su lugar con la API de Windows (GetStdHandle, WriteFile, etc.), mira los ejemplos de MASM32.

Ahora lo hice con TASM pero para ensamblar y ejecutar el programa estoy utilizando DosBox, estoy muy confundido con todo esto  :(, siempre voy a tener que utilizar el DosBox para ejecutar mis programas?

Este es el código que me corre bien y todo:

.model small
.stack 100h
cr equ 13
lf equ 10
.data
texto db 'hola$',cr,lf
 
.code
mov ax, seg texto
mov ds,ax
lea dx,texto
mov ah,9
int 21h
mov ah,4ch
int 21h
end
 

realmente estoy confundido con el tema de los bits, en un lugar alguien dice 16 bits luego en otro lugar 32 bits y en otro 64 bits y me hago espagueti  :(, no sé cómo empezar.

Como te dijeron arriba, estas usando un esquema por asi decirlo obsoleto usas llamadas al viejo DOS, no estoy familiarizado con estos sistemas pero se ve a leguas de que no es logico programar en 16 bits y con llamadas a DOS.

16 bits para modo real, y si funciona en DosBox es porque lo esta emulando.


Depende de tu CPU podras trabajar en 32 bits o en 64 bits, si es x64 en ambos modos, son casi similares las dos arquitecturas, por ejemplo en x64 tienes registros adicionales de calculo general r8-r15, y la arquitectura es algo distinta pero para eso tienes que informarte mejor.

Un saludo.

Si usas el TASM y codigo de 16 bits si, los Windows de 64 bits no soportan programas de 16 bis, es codigo obsoleto a esta altura.

Entonces debo olvidarme de aprender a programar a 16 bits?  sería mejor a 32 bits no? :-\

Si es lo mas aconsejable, tienes chinchetas en este mismo subforo hablando de libros, documentacion etc... Seguramente eres nuevo en esto, y habras acabado en un manual viejo, y de hay el code en 16 bits y con llamadas al DOS.

Ya te recomendaron una forma de empezar bien.


A lo mejor lo entendi mal @EI, pero enserio no se puede colocar code en 16 bits? No me refiero a las llamadas a DOS, si no a instrucciones y demas.

Un saludo.

otra duda, mientras de más bits sea la arquitectura es más tedioso de programar?  :-\

Realmente solo he programado ensamblador para micro controladores de 8 bits

Pueden recomendarme algún libro para orientarme mejor?  :P

Depende del enfoque que le des, no tiene porque ser mas complicado/tedioso, creo a ver leido y recuerdo algo, una de las razones por el cambio a x64 fue para tener/administrar mas memoria RAM. Pero eso no viene al caso.

Tambien tienes registros de 128 bits, depende de tu CPU de 256 bits y hasta los hay ya de 512 bits en los Intel mas actuales, ojo son CPU's de 64 bits, pero con registros por asi decirlo especiales para realizar otro tipo de calculos. Y hay mas aun...

El programa sera todo lo tedioso que tu quieras.


Sobre el libro tienes chinchetas y demas, sera mejor que esperes a que alguien te recomiende algo enfocado a Windows, si no quieres que te recomiendo algo puro ASM, me mandarias a la playa... ;D

Un saludo.

P.D: Tambien lo que quieras programar si es con API, no tiene porque suponerte mas problemas.

El S.O. no cambia a modo real una vez iniciado asi que el procesador no ejecuta instrucciones de 16 bits. No se para que uno lo podria querer igualmente  :silbar:

http://en.wikipedia.org/wiki/Virtual_8086_mode#64-bit_and_VMX_support

Si claro, me explique mal, yo te entendi de que no se podia poner instrucciones en 16 bits, se utiliza el prefijo 66 con los 16 bits, no son los opcodes originales de 80x86, es como un x86 pero con el prefijo, pense de que Windows x64 no toleraba ese tipo de cosas, me extrañaba por eso pregunte.

Un saludo.

mov    ax, 1234h
xor     bx, ax
...

¿Así que estas instrucciones de 16 bits no se ejecutan en el procesador (de 32, de 64)?
Vaya, vaya, ... no me digas.

Por poner un ejemplo: Windows Home 64 bits con procesador Intel 64 bits:
Depura el Notepad.exe (un ejecutable de 64 bits) y poco muy poco, pero verás algunas intrucciones, como esta:

xor    al, al
ret

Hola, creo que es como C y C++, algunas instrucciones de C se ejecutan en C++ :)

¿Queres decir que esas instrucciones que trabajan con registros de 16 u 8 bits son de 16 bits? Las instrucciones dependen del modo de ejecucion.

Abro el WinDbg de 32 bits y el notepad idem.

!dh notepad
eb notepad+address of entry point 0x1f
g

Repetir con el WinDbg de 64 bits y notepad idem.

Edito con otro ejemplo el opcode 048h en 16 bits es DEC AX, en 32 bits DEC EAX (como decia el amigo cpu2 si queres hacer DEC AX le antepones el operand-size prefix 066h) y en 64 bits es invalido.

sí: quiero decir exactamente eso: que esas instrucciones son de 16 bits en toda regla.

otra cosa es que el procesador no conmute a modo real para ejecutarlas, claro.
pero no digas que esas instrucciones no son de 16 bits porque están operando con registros de 16 bits.

¿el prefijo 66h es invalido en 64 bits? te vuelvo a decir: ¿no me digas?

foto: notepad.exe de 64 bits, depurado con el WinDbg, en Windows Home 64 bits con procesador Intel 64 bits:

http://postimg.org/image/p3o3xva3j/ (http://postimg.org/image/p3o3xva3j/)

Bien, el procesador en modo long no es capaz de ejecutar el DEC E/AX (opcode 048h) o POP DS (opcode 0x1F). Por lo tanto el procesador en modo long ejecuta instrucciones de 64 bits (si, aunque sea capaz de acceder a los registros legacy).


Siguiendo tu logica AL es un registro de 8 bits y por lo tanto la instruccion xor al, al es de 8 bits.
 

Y yo te voy a decir lo que tendria que haberte dicho en tu primer mensaje: BAJATE DEL CABALLO, NO HAY MUCHA DISTANCIA. Ahora si, aprende a leer con atencion, nadie dijo que el prefijo fuera invalido, el opcode si lo es por lo explicado anteriormente. Tu ejemplo solo demuestra mi punto, la instruccion de 16 bits es 085h, 0C0h y es TEST AX, AX, el prefijo se necesita en 32 bits ya que de otra manera esa MISMA e IDENTICA instruccion seria TEST EAX, EAX. Las instrucciones dependen del modo de ejecucion y seria bueno que lo entendieras antes de volvera responder.

PD. Estrictamente hablando las instrucciones de 16 bits son las que constan de dos bytes.

Creo que este tema se esta desviando y hay un malentendido.

Si las instrucciones trabajan con 16 bits, si las son, pero en realidad no son las originales de un 80x86, como dije anteriormente. Eso es lo que intento decir @EI y se malinterpreto, por eso le pregute para que pudiera aclarar el tema.

El prefijo 66h esta reservado, simplemente para que se sepa de que se esta trabajando con 16 bits, y el prefijo 48h para 64 bits pero no dejan de ser iguales todas simplemente que con prefijos:

mov rbx, rax      48 89 c3
mov ebx, eax      -- 89 c3
mov bx, ax        66 89 c3
 
test rbx, rax     48 85 d8
test ebx, eax     -- 85 d8
test bx, ax       66 85 d8

Supongo que esto ayudara, los opcodes no coinciden con los originales de un 80x86 puro, modo real.


Hay excepciones como por ejemplo xchg, tambien serian dos bytes en 64 bits pero con el prefijo indicado, con 16 igual con su prefijo, y por ultimo el 32 bits pues con el byte solo.

Fue un malentendido no se ofusquen de esa manera xD.

Un saludo.

Claro, no son las mismas por lo que ya mencione anteriormente: las instrucciones dependen del modo de ejecucion, el procesador las interpreta de acuerdo al modo de ejecucion.


Hay mas excepciones como la que mostre del opcode DEC de un byte o la instruccion AAA (037h), esas son instrucciones de 16 bits y 32 bits (segun el modo de ejecucion), no son de 64 bits.


Me referia a que una instruccion de un byte seria de 8 bits ;)


Uno puede tener un mal dia, dos veces seguidas en dias consecutivos vomitando esa pedanteria indica que estamos ante un pobre individuo. Hasta aca llegamos con el tema.