Sí, aunque creo que puede ser bastante engañoso y confuso mezclar el segmento y su contenido.

Aquí estamos poniendo ejemplos sencillos para ilustrar ciertos conceptos, pero obviamente, en una situación mas realista, es incorrecto suponer que todos los segmentos van a coincidir. Antes de intentar hacer cualquier cosa con un dato, siempre tenemos que hacer apuntar DS (o ES y usar ASSUME o segment overrides) al segmento que lo contiene. Naturalmente, en el ejemplo anterior, a poco que se toque el código (por ejemplo, haciendo que seg2 sea más grande), el programa puede dar resultados incorrectos. Esto lo aclaro por si alguien que empieza lee esto. En los ejemplos que pondré a continuación, siempre supongo que DS apunta al segmento correcto.

Si tenemos esto:

SEGMENT seg2 WORD
var1 DW ?
ENDS seg2

y var1 está en 0910:0002, decir que seg2 también inicia en esa posición es, como decía al principio, engañoso. Siempre que hagamos referencia a seg2 en el código, el valor que se sustituirá será 0910, nada más. Luego, dando por sentado que hemos hecho, como deberíamos, que DS apunte a seg2, si queremos ver el offset de var, veremos que es 2. Pero si se supone que seg2 (el segmento declarado por TASM) inicia en 0910:0002, la pregunta que surgiría es ¿por qué el ensamblador desperdicia memoria metiendo ese hueco de 2 bytes? Más aún, y siguiendo con ese razonamiento, si seg2 inicia en 0910:0002, y var1 tiene un offset de 2, eso implicaría que la dirección de var1 es 0910:0004, lo cual es incorrecto. La realidad simplemente es que seg2 inicia en el segmento 0910 o, si se quiere, en 0910:0000 (no necesitamos offset, porque, por definición, siempre va a ser 0000) y se superpone con un segmento anterior, y de ahí que var1 se coloque en una posición más alejada, es decir, los datos que contiene, sí que inician en el offset 2. Por eso, como decía al principio, mezclar seg2 con sus datos que contiene puede ser útil como abstracción y para simplificar las cosas, pero es algo inexacto y cuando queremos profundizar un poco, la abstracción se rompe; de ahí que yo prefiera separar los conceptos.

Los segmentos siempre están alineados a un párrafo. Lo que ponemos en CS, DS, etc. no son direcciones de memoria, sino números de segmento, y su dirección se calcula multiplicándolos por 16, (o desplazándolos 4 bits a la izquerda). Por ejemplo, cuando el valor de CS es 0x0020, la dirección real del segmento es 0x00200. Al especificar BYTE, WORD, etc. al definir un segmento, estamos indicando cómo queremos que esté alineada la dirección donde comienzan las instrucciones o datos contenidos en él, pero el segmento en sí siempre estará en dirección múltiplo de 16.

En el ejemplo que pusiste, vemos que ref fue colocado en la dirección 0x07100 (segmento 0x0710) y contiene un sólo byte, por lo que termina en 0x07101. Luego tienes seg1, con alineación WORD, por lo que se busca la primera dirección disponible que sea múltiplo de 2 (en este caso, 0x07102) y ahí se coloca su contenido. Todo esto hace que casi no se desperdicie memoria, pero ¿que pasa con seg1 en sí? Como 0x07102 no es múltiplo de 16, lo que se hace es tomar la dirección múltiplo de 16 inmediatamente anterior. En este ejemplo será 0x07100, lo cual hará que ref y seg1 estén en el mismo segmento "real", pero para que no se superpongan sus datos, el byte de seg1 no tendrá un offset de 0 sino de 2. Y lo mismo pasa con el resto de segmentos que pusiste. Así que esto que habías hecho era correcto:

MOV AX, ref
MOV AX, seg1
MOV AX, seg2

simplemente sucedió que los 3 segmentos, así como cseg, y por ende, CS, apuntaban a la misma dirección. Prueba a alinearlos todos con PARA y verás que AX tendrá valores distintos. O bien, déjalo como está, pero cambia el DB ? de ref por DB 15 DUP(?) y verás que debería quedar en un segmento distinto al resto.

¿Cuál es la razón de usar una cadena? Usando array, vector, o manejo dinámico de memoria te evitas conversiones. Y si quieres imprimir los números por pantalla, en un bucle directamente muestras variable[ i ], y listo. Y nada impide que agregues un cout << "," si quieres separarlos. Si forzosamente quieres poder imprimirlos todos en una sola instrucción y por eso te gustó la idea de la cadena, te va a tomar algo de trabajo, porque el ejemplo de arriba con una cadena, en realidad no te sirve. La línea

    numeros += i;

no está metiendo en numeros los caracteres '0', '1', sino los valores numéricos 0, 1, etc., que no representan caracteres válidos (el 0, por ejemplo, es el nulo, o fin de cadena). Por lo tanto, numeros no es una cadena válida, y no vas a poder imprimirla directamente. La única ventaja que te aportaba el uso de string aquí se pierde, así que no hay razón para hacerlo.

Si aún así en verdad quieres usar una cadena, lo primero es que, como ya te recomendaron, tomes un manual y leas al menos lo básico de string y la STL en general. Aunque hay varias maneras de hacer las conversiones que quieres y no es difícil, no veo mucho sentido a ponerte código de eso, dado que, con poco que lo toques, seguramente te dará problemas y tendrás más dudas que al principio. La STL podrá tener ciertas ventajas, pero no es fácil ni amigable. De hecho, desde el punto de vista de la usabilidad, a muchos nos parece una atrocidad, aunque una vez que agarras un poco de experiencia no es tan mala.

Otra opción menos complicada podría ser la función strtok, pero tiene sus inconvenientes. Puedes buscarla en Google y ver si la quieres usar, pero insisto en que son más recomendables las otras alternativas. Y siempre puedes convertir los números a cadena (mucho más fácil que lo contrario) con la función to_string(). Por ejemplo, esto:

cadena += to_string(vec[i]);

convierte el valor del elemento i de un vector, en un string y lo añade al final de cadena. De esta manera tienes el vector para acceder a los valores individuales, y la cadena para imprimirlos en una sola instrucción (aunque reitero, no es nada difícil y sólo toma un par de líneas imprimir todos los elementos manualmente).

Primero, aclaro que lo de los enlaces simbólicos y junctions no sólo pasa por cuestiones de traducción. En algunos casos Windows los usa para mantener compatibilidad hacia atrás (por ejemplo, "Documents and Settings" apunta a "Users") u otras razones, así que estos problemas de permisos te los encontrarás aún con carpetas cuyo nombre no cambia en la versión en español de Windows.

No sé si entendí bien la pregunta. ¿Por qué tendrías que saltarte "C:\"? Es perfectamente posible leer su contenido. Otra cosa es que alguna subcarpeta te niegue el acceso, pero en ese caso lo que te saltarías sería dicha carpeta, no la raíz.

En todo caso, si ejecutas el comando "dir /al", te mostrará los enlaces que hay dentro de la carpeta actual y a dónde apuntan.

Ten en cuenta que independientemente de esto, va a haber carpetas a las que simplemente no vas a tener acceso porque no tienes los permisos. No te recomiendo que intentes cambiarlos (y de todas formas, por lo general estas carpetas son de muy poco interés) así que lo mejor es saltártelas.

Lo que pasa es que la carpeta "Archivos de programa" en realidad se llama "Program Files", independientemente del idioma de tu Windows. La versión traducida es en realidad un enlace simbólico o (más correctamente, un junction point) y para esa no tienes permisos, pero sí para Program Files. Algo similar pasa con otras carpetas como "Documents and Settings" o "Archivos comunes".

En resumen, no te preocupes por ese error. Ve la forma de saltarte carpetas, y así, aunque tu programa no leerá "Archivos de programa", sí que lo hará con "Program Files", que es lo que en realidad quieres.

Pon algo más de código. En especial los #include y las directivas o declaraciones using que tengas.

Al margen de eso, leer archivos de la manera en que lo estás haciendo está mal. eof() sólo es true después de que se ha intentado leer más allá del fin del archivo. Por lo tanto, tu último getline puede fallar, lo cual hará que la variable leer no tenga un valor válido. De hecho, esto sucederá siempre que tengas un archivo de texto que termine con un caracter de nueva línea.

Aquí una forma correcta de leerlo:

while (getline(archivo, leer)) {
    cout << leer << endl;
}

De esa manera, si getline no fue capaz de leer datos (ya sea porque se llegó al fin del archivo o por otra razón), salimos del bucle.

Lo del modo de sólo lectura en tu caso no aplica. Windows (salvo las versiones PE o Preinstallation Environment, que tú no tienes, o lo sabrías) no puede funcionar en una unidad de sólo lectura, así que si fuera el caso ni siquiera cargaría. Esto suponiendo que hables del disco donde tienes instalado Windows. Si tienes un segundo disco y es ése el del problema, Windows podría funcionar, pero de cualquier forma, al intentar guardar datos te debería mostrar un error, no simplemente hacer como que guarda.

Lo más probable es que sí haya algún tipo de congelador instalado. Prueba lo del msconfig, o si no, hay una herramienta freeware llamada Autoruns que es bastante exhaustiva al mostrate lo que se carga al inicio.

¿Qué ensamblador usas? Porque aunque algunos son bastante especiales y no muy inteligentes (de ahí lo que te comenté de meter opcodes directamente, que es casi a prueba de fallos), tanto TASM como MASM admiten perfectamente llamadas así: call cs:dwoldISR. Sin embargo, debes omitir la palabra far, o no la aceptarán. De cualquier forma, es redundante, ya que el ensamblador lo deduce del operando. Si declaraste dwoldISR como palaba doble:

dwoldISR dd ?

eso automáticamente hará far a la llamada.

¿No será que tu ensamblador usa alguna sintaxis distinta para anteponer el registro de segmento? Me parecería extraño que simplemente no admitiera eso.

Lo malo de codificar directamente direcciones como en el código que pones, es que pueden variar, por ejemplo, entre versiones de DOS o diferentes BIOS. Es posible usar la técnica de meter opcodes y ahí poner la dirección de tu variable dwoldISR, y eso funcionaría bien, pero tendrías que calcular offsets, además de saber los tamaños de cada instrucción, etc. y realmente creo que no vale la pena, sobre todo porque al menos los principales ensambladores admiten las llamadas directamente.

No me viene a la mente ninguna referencia que trate expresamente sobre interrupciones. La mayoría de los libros de ensamblador trataban el tema, aunque casi siempre de forma algo superficial. Creo que esto yo lo aprendí sobre todo de algún manual viejo de Intel, pero no lo recuerdo en este momento. Si me acuerdo de algo, lo posteo.

Probablemente ya sepas esto, pero dado que es un error muy común al trabajar con interrupciones, creo que no está de más preguntar. Antes de este código:

pushf
call far dwoldISR
iret

¿Hiciste que DS apunte al segmento donde se encuentra dwoldISR (que, si estamos en un .COM, normalmente sería CS)? Porque como sabrás, dentro de un manejador de interrupciones no hay forma de saber de antemano los valores de los registros de segmento, salvo CS, naturalmente, así que, o apuntas a DS al segmento correcto o, más simple, agregas un override con CS:

call cs:dwoldISR

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.