Programa en C++

¿Y cuál fue el nuevo aporte? tal parece que el post era más bien un alarde
de conocimiento, que alguna ayuda para la persona que preguntó, que yo creo
no entendió ni media palabra de lo que escribiste.

Volviendo al tema. Si en tiempos de DOS renombrabas un archivo BIN hecho
para el procesador 8088 en uno con extensión COM, se te ejecutaba
perfectamente, ya que era el propio sistema el que construía el PSP, así es
que no tiene nada que ver que el BIN no debe asumir la presencia del PSP.
eso principalmente porque la extensión BIN no es una extensión ejecutable
reconocida por MS-DOS (si en un BIN renombrado a COM existe un CALL 0000h,
el programa terminaba dado que el PSP que se construyó contiene una llamada
INT 20h en la posición 0).

Ahora, te recuerdo que antiguamente existía un programa que venía con MS-DOS
que se llamaba EXE2BIN... que lo único que hacía era transformar un EXE a un
COM (plop!!)

Ahora bien, como norma general, o estandarización, una persona utiliza la
extensión BIN para indicar información binaria, utilizándose en forma masiva
para crear programas que se carguen en (EEP)ROM. De hecho, cuando yo estaba
en la universidad, y cargaba mis programas en EEPROM, nunca se me ocurría
ponerle al archivito una extensión distinta a BIN.

Después de toda esta discusión, espero que el amigo que preguntó ya se haya
dado cuenta que ese archivo con extensión BIN no necesariamente sea
"ejecutable". Es imprescindible saber para qué plataforma fue compilado. Por
ejemplo, yo cuando hacia programas en C usando un compìlador cruzado
Hi-Tech, generaba archivos BIN para un sistema basado en algún
microcontrolador, por ejemplo, el 8051, el cual, obviamente no era posible
ejecutarlo en un PC con 80x86.

Salu2
Jaime

Ok, un bin es una imagen binaria. Si hablamos de DOS, bins y coms eran
código prisioneros del segmento a la hora de la carga, lo que los
diferenciaba de los exes (los "MZ" disponen de header y relocation).

A mi me parece que lo que diferenciaba a un bin de un com era
precisamente el hecho de que un bin no debían asumir la presencia del
PSP. Es más, el loader no reconocía a los bins...

Un bin era por ejemplo un boot sector o un bootstrap (ambos ORG 0). Uno
también podía escribir o usar aplicaciones que los cargara (pienso en
los PRG de DBase y su LOAD/CALL, que te permitía usar un módulo de este
tipo, por ejemplo, si necesitabas hookear int 23h ó escribir una rutina
de ratón), y lo común en estos casos era exigir un ORG 0.

Claro está que cualquiera puede guardar un fichero de cualquier
naturaleza, y mandarle bin como extensión...

Hernán (27)
Quilmes (ar)

"Jaime Stuardo" escribía,

¿Y cuál fue el nuevo aporte? tal parece que el post era más bien un alarde
de conocimiento, que alguna ayuda para la persona que preguntó, que yo creo
no entendió ni media palabra de lo que escribiste.

Volviendo al tema. Si en tiempos de DOS renombrabas un archivo BIN hecho
para el procesador 8088 en uno con extensión COM, se te ejecutaba
perfectamente, ya que era el propio sistema el que construía el PSP, así es
que no tiene nada que ver que el BIN no debe asumir la presencia del PSP.
eso principalmente porque la extensión BIN no es una extensión ejecutable
reconocida por MS-DOS (si en un BIN renombrado a COM existe un CALL 0000h,
el programa terminaba dado que el PSP que se construyó contiene una llamada
INT 20h en la posición 0).

No veo como se resuelve el problema de las direcciones efectivas, que en
virtud del rename bin -> com quedarían todas automáticamente desplazadas
256 bytes hacia atrás. Digo,

mov ax, entry_point
call ax
cuelgue

mov bx, dirección_de_una_variable
mov ax, w[bx]
ahora ax contiene el valor de un word hubicado 256 bytes antes

Ok, talvez sea un programa que no apele a ellas...

Ahora, te recuerdo que antiguamente existía un programa que venía con MS-DOS
que se llamaba EXE2BIN... que lo único que hacía era transformar un EXE a un
COM (plop!!)

Un falso exe. O, mejor dicho, un innecesario exe, talvez. Un verdadero
exe, no.

Ahora bien, como norma general, o estandarización, una persona utiliza la
extensión BIN para indicar información binaria, utilizándose en forma masiva
para crear programas que se carguen en (EEP)ROM. De hecho, cuando yo estaba
en la universidad, y cargaba mis programas en EEPROM, nunca se me ocurría
ponerle al archivito una extensión distinta a BIN.

El viejo Isaacson generaba por defecto archivos con extensión bin, si el
fuente comenzaba con un org 0.

Después de toda esta discusión, espero que el amigo que preguntó ya se haya
dado cuenta que ese archivo con extensión BIN no necesariamente sea
"ejecutable". Es imprescindible saber para qué plataforma fue compilado. Por
ejemplo, yo cuando hacia programas en C usando un compìlador cruzado
Hi-Tech, generaba archivos BIN para un sistema basado en algún
microcontrolador, por ejemplo, el 8051, el cual, obviamente no era posible
ejecutarlo en un PC con 80x86.

Salu2
Jaime

Hernán (27)
Quilmes (ar)

Parece que no comprendes muy bien el tema de la ejecución de programas con
extensión COM.

Es claro que las instrucciones en assembler que pones fuerzan que exista un
offset de 256 bytes.. pero ahora estamos hablando de algo totalmentre
distinto. Es el sistema operativo el que construye el PSP y él
automáticamente carga el programa desde la posición 100h. Si tu observaras
el archivo COM utilizando herramientas como HexEditor, UltraEdit o alguno
parecido, verás que la primera instrucción que existe en el archivo es la
primera instrucción que se ejecuta. Como verás, la posición 0 del archivo
COM es la posición 100h en memoria cuando se ejecuta.

Respecto al EXE2BIN... ¿de dónde sacas que es un falso EXE? mira... para que
ese programa funcione, el EXE debe tener las siguientes características:

1.- El archivo EXE debe tener MZ en su header
2.- La referencia a SS:SP en el header debe ser 0000:0000
3.- La referencia a CS:IP debe ser 0000:0100 o 0000:0000 (para device
drivers)
4.- El número de ítems en la tabla de reubicación debe ser 0.

Si bien es cierto, no todos los EXE se pueden convertir, sí existe un gran
número de ellos que sí pueden, sin ser, como lo llamas tú, falsos EXE's

Salu2
Jaime



<Hernán> wrote in message news:

"Jaime Stuardo" escribía,

>¿Y cuál fue el nuevo aporte? tal parece que el post era más bien un

alarde

>de conocimiento, que alguna ayuda para la persona que preguntó, que yo

creo

>no entendió ni media palabra de lo que escribiste.
>
>Volviendo al tema. Si en tiempos de DOS renombrabas un archivo BIN hecho
>para el procesador 8088 en uno con extensión COM, se te ejecutaba
>perfectamente, ya que era el propio sistema el que construía el PSP, así

es

>que no tiene nada que ver que el BIN no debe asumir la presencia del PSP.
>eso principalmente porque la extensión BIN no es una extensión ejecutable
>reconocida por MS-DOS (si en un BIN renombrado a COM existe un CALL

0000h,

>el programa terminaba dado que el PSP que se construyó contiene una

llamada

>INT 20h en la posición 0).
>

No veo como se resuelve el problema de las direcciones efectivas, que en
virtud del rename bin -> com quedarían todas automáticamente desplazadas
256 bytes hacia atrás. Digo,

mov ax, entry_point
call ax
cuelgue

mov bx, dirección_de_una_variable
mov ax, w[bx]
ahora ax contiene el valor de un word hubicado 256 bytes antes

Ok, talvez sea un programa que no apele a ellas...

>Ahora, te recuerdo que antiguamente existía un programa que venía con

MS-DOS

>que se llamaba EXE2BIN... que lo único que hacía era transformar un EXE a

un

>COM (plop!!)
>

Un falso exe. O, mejor dicho, un innecesario exe, talvez. Un verdadero
exe, no.

>Ahora bien, como norma general, o estandarización, una persona utiliza la
>extensión BIN para indicar información binaria, utilizándose en forma

masiva

>para crear programas que se carguen en (EEP)ROM. De hecho, cuando yo

estaba

>en la universidad, y cargaba mis programas en EEPROM, nunca se me ocurría
>ponerle al archivito una extensión distinta a BIN.
>

El viejo Isaacson generaba por defecto archivos con extensión bin, si el
fuente comenzaba con un org 0.

>Después de toda esta discusión, espero que el amigo que preguntó ya se

haya

>dado cuenta que ese archivo con extensión BIN no necesariamente sea
>"ejecutable". Es imprescindible saber para qué plataforma fue compilado.

Por

>ejemplo, yo cuando hacia programas en C usando un compìlador cruzado
>Hi-Tech, generaba archivos BIN para un sistema basado en algún
>microcontrolador, por ejemplo, el 8051, el cual, obviamente no era

posible

>ejecutarlo en un PC con 80x86.
>
>Salu2
>Jaime
>

Hernán (27)
Quilmes (ar)

"Jaime Stuardo" escribía,

Parece que no comprendes muy bien el tema de la ejecución de programas con
extensión COM.

Entiendo que si tomo un archivo bin a org 0 y lo renombro a com, el
loader cargará el archivo en CS:0100, haciendo que todas las direcciones
efectivas queden desfasadas.

Entiendo que este tipo de archivos requieren ser cargados en la posición
específica para la que fueron creados. Y en ninguna otra.

Entiendo que BIN es la extensión típica para los archivos a cargar en
CS:0000.

Entiendo que puedo estar completamente equivocado y estimo cualquier
ayuda que pueda recibir para corregirme en mi error...

Es claro que las instrucciones en assembler que pones fuerzan que exista un
offset de 256 bytes.. pero ahora estamos hablando de algo totalmentre
distinto. Es el sistema operativo el que construye el PSP y él
automáticamente carga el programa desde la posición 100h. Si tu observaras
el archivo COM utilizando herramientas como HexEditor, UltraEdit o alguno
parecido, verás que la primera instrucción que existe en el archivo es la
primera instrucción que se ejecuta. Como verás, la posición 0 del archivo
COM es la posición 100h en memoria cuando se ejecuta.

Respecto al EXE2BIN... ¿de dónde sacas que es un falso EXE? mira... para que
ese programa funcione, el EXE debe tener las siguientes características:

1.- El archivo EXE debe tener MZ en su header
2.- La referencia a SS:SP en el header debe ser 0000:0000
3.- La referencia a CS:IP debe ser 0000:0100 o 0000:0000 (para device
drivers)
4.- El número de ítems en la tabla de reubicación debe ser 0.

De eso hablaba precisamente. De un com/bin/sys disfrazado de exe. Cuando
la herramienta que no podía crearlos directamente, el exe2bin venía al
rescate.

Un sys es requerido a ser cargado en CS:0000 pero su primer byte no es
código ejecutable (como sí es de rigor en los com), sino una pequeña
cabecera que contiene, entre otras pocas cosas, el punto de entrada
(strategy handler, si mal no recuerdo su nombre).

Si bien es cierto, no todos los EXE se pueden convertir, sí existe un gran
número de ellos que sí pueden, sin ser, como lo llamas tú, falsos EXE's

Salu2
Jaime

Hernán (27)
Quilmes (ar)

"Tristeza não tem fin, felicidade sim."