Barrapunto

A lo mejor es un formato propietario.
¿Qué extensión tiene?
Aprovechando que es puente si quieres puedes enviarlo y probamos a ver que se puede sacar.
Si hay varios ficheros envía uno pequeño.
Lo que hace el aburrimiento.

Si crees que puede ser un formato conocido, lo que tienes que usar es "file", un comando que te dice el tipo de un archivo mirando su estructura.

Aunque probablemente use un formato propio en cuyo caso estás jodido, pues es muy difícil y costoso llegar a sacar los datos mediante ingeniería inversa. Pero si aún así quieres echar un vistazo al contenido del archivo, no debes usar un editor de texto como gedit, sino un editor hexadecimal como hexedit.

A mi me pasó eso no hace mucho. Por suerte pude averiguar con el "cliente" que estaba hecha con QBasic ... de ahí llegué a la conclusión que estaba hecha con QBasic 1 o 2 y usaba un formato de archivos propio que desde QBasic 3 o así ya ni se usaba.
Había herramientas (todavía) de pago para convertir esos archivos a DBase, pero al final pude obrar para recuperar 4 datos que eran los que realmente le interesaban.
Aparte de los formatos propios de QBasic y Turbo Pascal para guardar arrays, las primeras versiones del DBase eran muy populares también en MSDOS.
Desafortunadamente si no son "DBase" no creo que exista una técnica mágica para sacar ese formato. Aún así, te recomiendo hecharle un vistazo (binario) al EXE, a ver si averiguas algo desde ahí.

si el programa msdos te permite imprimir los datos que necesitas exportar, sólo necesitarás una impresora virtual que te guarde esa impresión en un archivo de texto. Luego ya es coser y cantar.

Lo primero es colgar el fichero o una parte inicial para que podamos echar un vistazo.

Será cosa del puente, pero, hasta los pobrecitos habladores tienen ganas de echarle la vista a uno de esos ficheros para pasar el rato.

¿1991? Yo voto por Clipper (dbase compilado)

Ayudaría un mensaje de error (parametros incorrectos, ficheros no encontrados) o saber si utiliza algún "runtime library".

La versión bruta: Cambiar datos en un registro, localizar cambios y mirar formato en hexadecimal.

Por entonces lo que más se usaba en la gestión de PYMEs eran las bases de datos DBase III (BB.DD. en ficheros .dbf, y los índices en ficheros .dbx). Si te encuentras con dbf + .ndx seguro que se trata de una aplicación en Clipper (por entonces lo más usado en España era el Clipper Summer '87; los .dbf eran compatibles con DBase III, pero los índices tenían otro formato -no es un problema de interoperatibilidad, pues eran regenerables vía "reindex"-).

Amigos, tal y como comenta alguien más arriba, la forma más práctica, rápida y eficaz de obtener esa información es simplemente imprimiéndola.

Al ser una aplicación de gestión tiene que tener por narices, a no ser que sea rematadamente mala, una función de impresión de listados de los distintos maestros que la componen.

Si es así, es tan fácil como volcar un listado de cada maestro a una impresora virtual (hay muchos programas al efecto), y desde ahí, con un sencillo script, filtrar la información hacia un formato más o menos legible e importarlo en la aplicación destino.

Esto lo he hecho infinidad de veces sobre aplicaciones antiguas DBase/Clipper, hacia programas ERP de pelajes variados. Es sólo cuestión de adaptar el formato a la aplicación de destino y fuera.

En serio, dejad de mirar formatos de archivo y ponerse a hacer ingeniería inversa...

Saludos.

En esa época, aparte de Clipper y dBase como te han dicho, se daba mucho el uso de Btrieve, que eran unas rutinas residentes y que daban acceso a ficheros indexados en Basic, C, etc..

Para detectarlo, mira si en autoexec.bat tienes algo como btrieve, btrv o similar. Si es así puedes estar un poquito j*d*d*, pues se solían usar técnicas de codificación de algunos datos (fechas, números) para ocupar menos. ADEMAS tendrías que escribir un programa que exportase los datos a "algo". Necesitarías la estructura del fichero. Pero se puede hacer.

Si es Clipper y ves cosas raras en los archivos, te puede ayudar buscar valkyrie Clipper en Google }:-)

Luego habían cosas extrañas como crystal boriar... Pero por lo menos, como te han preguntado, si dices que extensión tienen los archivos...

En aquellos años, yo trabajaba desarrollando software para una empresa de tirada nacional. Aunque es cierto que se hacian muchas cosas en Clipper o Dbase, aun quedaban/quedabamos muchos que usabamos los sistemas antiguos de ficheros de acceso directo. Se trata de ficheros planos, con un registro tras otro, y registros de longitud fija. Para leerlos, basta con saber la longitud del registro y el numero de registro a que quieres acceder: de ahi el nombre de fichero de acceso aleatorio.
Estos ficheros se usaban como alternativa a los ficheros de acceso secuencial, en los que era necesario comenzar por el principio y seguir leyendo los registros de uno en uno hasta llegar al que querias. Este segundo tipo de archivos era muy utilizado por los programadores en Cobol, ya que les permitia tener una estructura de registros variable, y el tamaño de cada registro era diferente (esto lo se por referencias y mi informacion no es del todo fiable).
Para los archivos de indice, Btrieve era el sistema mas popular, ya que se ocupaba de almacenar tambien los datos. A mi, personalmente, nunca me gusto, y en mi empresa utilizabamos unas rutinas ISAM que se llamaban FABSPC. Lo que nos convencia para decantarnos por ellas era que no se ocupaban para nada del fichero de datos: simplemente, tenias las operaciones de insertar clave, borrar clave y recuperar clave (basicamente) y te daba un numero de registro que es el que debias usar para hacer las mismas operaciones en tu fichero de datos. Eso significa que, a partir del fichero de datos, puedes regenerar el de indices y no era necesario incluirlo en las copias de seguridad (tener en cuenta que, en aquellos tiempos, muchas maquinas usaban discos flexibles de 5.25 y 360 Kb por disco).
Otro problema adicional, es la codificacion de los datos dentro del fichero: cuando se trataba de guardar un numero entero, no se guardaban los 6 bytes que corresponden a un entero y su signo (-32768,32768), sino que se guardaban los dos bytes que ocupa en memoria (los discos duros eran muy pequeños y muy caros: en 1986 compre un disco de 10 Mb por 150.000 pesetas). Problema que se hace mucho mas peliagudo cuando se trata de numeros en coma flotante y considerando que cada programador se buscaba la vida como podia.
Tambien recuerdo un colega que usaba un lenguaje muy muy raro, en el que los datos se almacenaban en el propio fichero ejecutable. Realmente pintoresco.
En cualquier caso, ayudaria mucho ver que ficheros se usan: nombre y extension, y sobre todo, ver que diferentes extensiones se asocian al mismo fichero.
Suerte, y si quereis que el viejo Gandalf le eche un vistazo, me lo decis.

Completamente de acuerdo: Todo es hablar el precio. Presupuesto mediante, y facturando a razón de 80 euros/hora, no tengo inconveniente en recordar los viejos tiempos (todavía recuerdo las interrupciones de la BIOS y DOS del libro de Peter Norton, y los dramas de los segmentos de 64KB y demás atrocidades del ensamblador del 8086, you insensitive clod).