Hola.

Soy nuevo en este foro y me gustaria hacer una pregunta.
He estado intentando desde hace una semana esto y sinceramente me frustra no hallar la manera. Lo que estoy intentando es hacer una llamada a una funcion que esta fuera del segmento por defecto (en modo real, es decir, real-mode tipo 8086), es decir, lejana (o far), desde el lenguaje de programacion C y no logro hacerlo. He utilizado ensamblador integrado (lo cual el compilador codifica como una llamada near, y me refiero a instrucciones tipo call es:[bx], por ejemplo), una locura de conversiones de tipos de punteros a funciones y hasta he intentado hacer el programa en su totalidad en emsablador como resultado de mi frustracion pero he terminado peor al haberlo "terminado" sin encontrar un ensamblador para 16 bits. ¿a alguien se le ocurre alguna solucion a mi problema?

posdata: Si alguien sabe de un ensablador para 16 bits (tipo TASM preferiblemente), se lo agradeceria.

Muchas gracias de antemano.

Por curiosidad... que compilador de C te genera un .COM para 16 bits? ( Asumo que generas un .COM, no lo sé)

Con Flat  Assembler puede generar código para 16 bits.

https://flatassembler.net/


Incluso puede que tu respuesta la encuentres aquí.

https://board.flatassembler.net/topic.php?t=11055


Espero haberte ayudado.

saludos.

No sé si entendí bien lo que quieres, pero si ya tienes el puntero far y necesitas el offset y el segmento, lo puedes hacer así:

unsigned int segmento = (unsigned int)((unsigned long)puntero_far >> 16);
unsigned int offset = (unsigned int)((unsigned long)puntero_far & 0xFFFF);

Si lo quieres es lo opuesto:

// Editado: la funcion que deseas llamar no recibe parametros:
 
//puntero_far = (void far (*)(int))(((unsigned long)segmento << 16) + offset);
puntero_far = (void far (*)())(((unsigned long)segmento << 16) + offset);

Como los tamaños de los tipos varían de un compilador a otro, puede que necesites cambiar long por algún otro tipo que ocupe 32 bits, y poner __far en lugar de far.

En cuanto a tu pregunta original, C no tiene concepto de punteros near, far, modelos de memoria, ni nada por el estilo, por lo que todo esto depende totalmente del compilador. Lo más cercano a Open Watcom que usé es el Watcom C normal, pero hace mucho de eso, y además no sé qué tanto difieran, pero el código que pones tendría que funcionar. En general, usar la palabra "far" (o __far, o cualquier otro equivalente en el compilador que se use) ya debería bastar para llamar a estas funciones. No sé cuál sea el problema aquí, pero yo vería si el Open Watcom no hace algo "raro" al usar __far. Lo mejor en estos casos es checar el ensamblador generado por el compilador, ya sea mediante algún flag, si lo tiene, o desensamblando el ejecutable.

A diferencia de los punteros near, los far son más simples: los 2 bytes más significativos contienen el segmento, y los 2 menos significativos el desplazamiento. Las operaciones que hago en el código que puse son simplemente extraer los el conjunto de dos bytes que interesen, para obtener sus componentes; o bien, juntarlos en un único número de 4 bytes, para generar el puntero far.


Bueno, en realidad no estoy haciendo una rotación (de hecho, C no proporciona operadores para eso) sino un simple desplazamiento a la derecha. Con esto, como decía arriba, obtengo el valor los 2 bytes más significativos. Multiplicar por 0x10 daría un resultado completamente diferente. La operación a nivel de bits equivalente a esa muliplicación sería (puntero_far << 4). La operación aritmética equivalente al desplazamiento que hago sería dividir entre 0x10000 (65536). De cualquier forma, las operaciones a nivel de bits, además de que suelen ser más eficientes que las aritméticas, en estos casos me parece que hacen más explícito lo que se quiere hacer.

Pasé por alto un mensaje anterior. ¿Esás generando un archivo COM? Porque si es así, a eso se debe el error. Los COM no pueden hacer llamadas far, dado que están limitados a un sólo segmento. Aunque sí que hay forma de acceder a datos en otros segmentos (teniendo que calcularlos manualmente, y directamente en ensamblador, no en C), no es así con las llamadas far. Lo normal sería que el linker diera error, diciendo que el archivo contiene referencias reubicables (relocatable), pero es posible que algunos simplemente conviertan las llamadas far a near, o directamente ignoren el problema y las dejen far, lo cual ocasionará que el programa falle durante la ejecución.

Pasa que los COM están muy limitados y una de las pocas razones para usarlos era su simpleza, que era lo que quise decir arriba, cuando comenté que los punteros far eran más simples que los near (en realidad me quería referir a los COM y los EXE, pero entre que borraba y cambiaba mi mensaje, se me quedó mezclado). Obviamente, tanto como más simples no, es sólo que incluyen el segmento y no va implícito CS, como en los far. Como sea, lo que sucede con los COM es que al ejecutarlos, se cargan en memoria tal cual están en el disco, todo en un sólo segmento, y sin las reubicaciones que tienen lugar con los EXE. Esto hacía que, entre otras cosas, fuera mucho más rápido cargar los COM, pero con desventajas, como el tener sólo un segmento. Sin embargo, no es tan simple, ya que, como había comentado antes, sí que hay formas de acceder a datos más allá, pues nada impide que cargues valores en DS ó ES, por ejemplo, pero obviamente no se puede modificar directamente a CS.


Hace ya mucho que no programo nada en 16 bits y puede que se me escape algún detalle o me confunda en algún punto, pero en esencia así es como funciona:

Como bien intuyes, no es que el sistema operativo impida a estos archivos hacer llamadas far durante la ejecución, sino que, como normalmente éstas implican código reubicable, los linkers se quejan y no permiten generar archivos COM. Podrías intentar forzar esto usando un "truco" muy común, que es meter tú mismo los opcodes de la operación. Por ejemplo, en la parte de tu código donde quieras la llamada, usas un DB con el valor del opcode para la llamada far deseada, e inmediatamente después un par de DW con los valores de segmento y desplazamiento, si los sabes.

Dicho todo lo anterior, y respondiendo a tu última pregunta, los EXE no tienen ninguna de estas limitaciones, así que te recomiendo que no te compliques con los COM. De esta manera, puedes hacerlo desde C, y en este caso, el compilador sí que debería hacer lo que pides. E independientemente del compilador que uses, si permite generar COM, obviamente debe poder hacer EXE de 16 bits.

---

Edito: Cuando escribí el mensaje, tal como puse, no estaba seguro de estar recordando bien, y como me quedó la duda, el sábado me puse a revisar códigos viejos que tenía con esa información. Aunque lo dicho arriba en general es más o menos válido, van algunas puntualizaciones.

Lo que mencioné sobre meter opcodes manualmente, yo lo llegué a usar para saltarme limitaciones de los ensambladores que no admitían llamadas en modo inmediato, pero en general, no lo necesitarías. El asunto de los linkers quejándose del código reubicable (y el hecho de que un compilador de C difícilmente generaría COM con llamadas far válidas) sigue siendo correcto; sin embargo, trabajando directamente en ensamblador, sí podrías hacer las llamadas far sin problemas, siempre que no quieras usar nombres de procedimientos definidos en otros segmentos (lo que ocasionaría los errores de reubicación), sino usando directamente el segmento y desplazamiento.

De todas maneras, generar EXE de 16 bits sería lo más recomendable, ya que de esa manera lo podrías hacer desde C.