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.
Citarrealmente 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.
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.
Cita de: 0xFer en 24 Mayo 2015, 21:45 PM
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?
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? :-\
Cita de: 0xFer en 25 Mayo 2015, 00:27 AM
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.
Cita de: Eternal Idol en 25 Mayo 2015, 00:04 AM
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.
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.
Cita de: cpu2 en 25 Mayo 2015, 01:19 AMYa 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.
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.
Cita de: Eternal Idol en 25 Mayo 2015, 08:11 AM
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:
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
Cita de: luisferfago en 25 Mayo 2015, 17:58 PM
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.
Hola, creo que es como C y C++, algunas instrucciones de C se ejecutan en C++ :)
Cita de: luisferfago en 25 Mayo 2015, 17:58 PM
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
¿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/)
Cita de: luisferfago en 26 Mayo 2015, 19:41 PM
sí: quiero decir exactamente eso: que esas instrucciones son de 16 bits en toda regla.
Cita de: Eternal Idol en 25 Mayo 2015, 08:11 AM
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:
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).
Cita de: luisferfago en 26 Mayo 2015, 19:41 PMotra 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.
Siguiendo tu logica AL es un registro de 8 bits y por lo tanto la instruccion xor al, al es de 8 bits.
Cita de: luisferfago en 26 Mayo 2015, 19:41 PM¿el prefijo 66h es invalido en 64 bits? te vuelvo a decir: ¿no me digas?
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 d8Supongo que esto ayudara, los opcodes no coinciden con los originales de un 80x86 puro, modo real.
CitarPD. Estrictamente hablando las instrucciones de 16 bits son las que constan de dos bytes.
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.
Cita de: cpu2 en 26 Mayo 2015, 21:10 PMSi 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.
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.
Cita de: cpu2 en 26 Mayo 2015, 21:10 PMSupongo que esto ayudara, los opcodes no coinciden con los originales de un 80x86 puro, modo real.
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.
Cita de: cpu2 en 26 Mayo 2015, 21:10 PMHay 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.
Me referia a que una instruccion de un byte seria de 8 bits ;)
Cita de: cpu2 en 26 Mayo 2015, 21:10 PMFue un malentendido no se ofusquen de esa manera xD.
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.