Microsoft Windows NT está diseñado para ejecutar aplicaciones escritas para diversos sistemas operativos existentes, como Microsoft MS-DOS, OS/2, POSIX y Microsoft Windows 3.x, así como aplicaciones escritas para Windows 95 y Windows NT. Esto se logra gracias a los subsistemas de entorno, que emulan los entornos de los distintos sistemas operativos.
Windows NT permite el uso de aplicaciones a través de subsistemas de entorno. Un subsistema de entorno proporciona servicios de interfaz de programación de aplicaciones (API, Application Programming Interface) a las aplicaciones escritas para un entorno o sistema operativo específico.
Un subsistema de entorno de Windows NT es un intermediario entre una aplicación diseñada para un entorno de sistema operativo específico y los servicios ejecutivos. El subsistema de entorno convierte las instrucciones de una aplicación específicas para un entorno en instrucciones que pueden ejecutar los servicios ejecutivos. Existen dos subsistemas de entorno de Windows NT para utilizar aplicaciones diseñadas para otros entornos operativos: el subsistema POSIX y el subsistema OS/2. Estos subsistemas reciben todas las peticiones de funciones procedentes de las aplicaciones con las que son compatibles. Un subsistema puede ejecutar la petición o transferirla a los servicios ejecutivos de Windows NT.
En ocasiones se hace referencia al subsistema Win32 como subsistema cliente- servidor, CSR o CSRSS. Este subsistema admite aplicaciones para Win32, MS-DOS y Windows 3.x, y los subsistemas de entorno. El subsistema Win32 también se encarga de las funciones de tratamiento de errores, del cierre de aplicaciones y de las aplicaciones de consola (no escritas para la interfaz gráfica de usuario de Windows).
El subsistema de seguridad es compatible con el proceso de inicio de sesión. No es compatible, sin embargo, con otras aplicaciones.
Los servicios ejecutivos de Windows NT realizan funciones básicas de sistema operativo para todos los subsistemas y residen en el modo núcleo. Esto proporciona estabilidad al sistema operativo, ya que ninguna aplicación o subsistema tiene acceso directamente a los servicios ejecutivos. De este modo, un mal funcionamiento de un componente de modo usuario (como una aplicación o un subsistema de entorno) no puede impedir el funcionamiento de un componente del modo núcleo.
Todas las peticiones de E/S relacionadas con la interfaz de usuario se encaminan al componente Administrador de ventanas y GDI Win32 de los servicios ejecutivos, que es el encargado de la presentación en pantalla. Esto proporciona una interfaz gráfica de usuario común para todas las aplicaciones.
El subsistema se basa en los servicios ejecutivos para producir entornos que satisfagan las necesidades específicas de las aplicaciones clientes. De este modo, las funciones comunes de los sistemas operativos se implementan una sola vez en los servicios ejecutivos, en lugar de duplicarse en cada subsistema. Esto reduce el esfuerzo necesario para programar nuevos subsistemas y facilita su mantenimiento.
Las aplicaciones basadas en Win32 pueden aprovechar al máximo las siguientes características de Windows NT:
Subprocesos múltiples para mejorar el rendimiento del sistema
Compatibilidad con las tecnologías OLE/Microsoft ActiveX y OpenGL
Conjunto de API Microsoft DirectX para Windows NT
Las aplicaciones basadas en Win32 aprovechan la capacidad de proceso multitarea y la fiabilidad inherente de Windows NT.
Las aplicaciones para Win32 pueden ejecutar simultáneamente múltiples subprocesos, o unidades de ejecución de un proceso. Por ejemplo, un programa de instalación basado en Win32 se puede descomponer en tres subprocesos:
Uno que descomprime archivos
Uno que copia archivos
Uno que modifica los archivos de configuración del sistema
Los subprocesos son completamente independientes unos de otros. Se ejecutan al mismo tiempo, por lo que mantienen un alto rendimiento del sistema.
Cada una de las aplicaciones basadas en Win32 se ejecuta en un espacio de direcciones de 2 gigabytes propio. De esta manera, una aplicación para Win32 nunca puede dañar la memoria que utiliza otra aplicación para Win32. Dicho de otra forma, si falla una aplicación para Win32, las otras aplicaciones para Win32 no se ven afectadas.
Windows NT es compatible con las API OLE/ActiveX y OpenGL.
Tanto ActiveX como OLE se basan en el modelo de objetos de componentes (COM, Compoinent Object Model). Este modelo proporciona el mecanismo de enlace de objetos a bajo nivel que permite que los objetos se comuniquen entre sí. En la taba siguiente se compara OLE con ActiveX.
| Características | OLE | ActiveX |
| Función | Proporciona a las aplicaciones servicios como la vinculación o la incrustación para la creación de documentos compuestos. | Permite incrustar controles en sitios Web y responder interactivamente a eventos. |
| Optimización | Optimizado para su uso e integración en aplicaciones de escritorio. | Optimizado en cuanto al tamaño y la velocidad. |
| Alcance | Windows NT incluye versiones de OLE de 16 y 32 bits. También admite la interoperabilidad entre aplicaciones OLE basadas en Win16 y Win32. | Agrega innovaciones para Internet, como presentaciones incrementales y conexiones asíncronas. |
OpenGL (lenguaje de gráficos) es una interfaz de software estándar para la creación de gráficos en dos y tres dimensiones. OpenGL permite que las aplicaciones creen gráficos de alta calidad en color de forma independiente de los sistemas de ventanas, sistemas operativos y hardware. OpenGL bajo Windows NT admite el modo VGA de 16 colores. En esto se diferencia de otras versiones de OpenGL, como las de los equipos UNIX y X WindowsSystem, que necesitan al menos 256 colores.
Windows NT incluye varios protectores de pantalla 3D que son ejemplos de aplicaciones OpenGL. Estos protectores utilizan más tiempo de CPU que los protectores de pantalla normales, por lo que su uso en un servidor de archivos, de impresión o de aplicaciones puede afectar al rendimiento.
DirectX es un conjunto de API de bajo nivel diseñadas específicamente para aplicaciones de alto rendimiento, como los juegos. DirectX está diseñado para proporcionar una respuesta de alta velocidad. en tiempo real, a la interfaz de usuario.
Los tres componentes de DirectX incluidos en Windows NT 4.0 son:
API DirectDraw: DirectDraw para Windows NT 4.0 es compatible con una interfaz de programación de aplicaciones de 32 bits para acelerar los dibujos. A diferencia de DirectDraw para Windows 95, DirectDraw para Windows NT no se comunica directamente con el controlador de vídeo ni con ningún componente hardware. Todas las llamadas de DirectDraw se realizan a través de GDI. DirectDraw logra su alto rendimiento mediante un nivel sobre el hardware de vídeo que permite el acceso, sin distinguir entre dispositivos, al hardware acelerador de gráficos.
API DirectSound: DirectSound proporciona el acceso, sin distinguir entre dispositivos, al hardware de aceleración de audio. Ofrece características como la mezcla en tiempo real de canales de audio y el control de efectos de volumen y panorámicos durante la reproducción. Las llamadas de DirectSound se comunican directamente con el Administrador de E/S.
API DirectPlay: DirectPlay simplifica la comunicación entre equipos, al permitir que los programas DirectX se ejecuten a través de una red o un módem.
Windows NT es compatible con aplicaciones basadas en MS-DOS mediante una máquina virtual de DOS en NT (NTVDM). Una NTVDM también admite aplicaciones para Win16 en un entorno emulado de Win16 en Win32 (WOW, Win16 o Win32).
Las aplicaciones basadas en MS-DOS se ejecutan en una aplicación para Win32 que se conoce como la máquina virtual de DOS en NT (NTVDM, NT Virtual DOS Machine). La NTVDM proporciona un entorno simulado de MS-DOS para aplicaciones basadas en MS DOS.
Cada aplicación basada en MS-DOS tiene su propia NTVDM. Cada NTVDM tiene un solo subproceso y su propio espacio de direcciones, de modo que si una NTVDM falla, ninguna otra NTVDM se ve afectada. En la tabla siguiente se describen los componentes principales de una NTVDM.
Ntvdm.exe: Se ejecuta en modo núcleo. Proporciona la emulación de MS-DOS y administra la NTVDM.
Ntio.sys: Equivale al Io.sys de MS-DOS.
Ntdos.sys: Equivale al Msdos.sys, el núcleo de MS-DOS.
IEU: En los equipos basados en RISC, un componente adicional de la NTVDM. La Unidad de ejecución de instrucciones (IEU. Instruction Execution Unit) emula a un microprocesador Intel 80846.
La NTVDM utiliza controladores de dispositivo virtuales (VDD, Virtual Device Drivers) para permitir que las aplicaciones basadas en MS-DOS tengan acceso al hardware del sistema.
Muchas aplicaciones basadas en MS-DOS intentan tener acceso directamente al hardware. En el modelo de arquitectura de Windows NT, las aplicaciones que se ejecutan en modo usuario no tienen acceso directo al hardware. Los controladores de dispositivo virtuales interceptan las llamadas de la aplicación al hardware e interactúan con el controlador de dispositivos de Windows NT de 32 bits. Este proceso de comunicación con el hardware es transparente para la aplicación.
Windows NT proporciona controladores de dispositivo virtuales para el mouse (ratón), teclado, impresora y puerto serie (COM). Los controladores de dispositivo virtuales se cargan en todas las NTVDM según los valores almacenados en el registro. La información sobre los VDD se encuentra en la siguiente ruta de acceso del Registro:
HKEY_LOCAL_MACHINE
\System
\CurrentControlSet
\Control
\VirtualDeviceDrivers
Si desea personalizar una NTVDM para una aplicación basada en MS-DOS, puede cambiar la configuración en el Archivo de información de programa (PIF, Program Information File) de la aplicación. Para crear y modificar archivos PIF, en el Explorador de Windows NT, haga clic con el botón secundario del mouse en el nombre de archivo de la aplicación. Si desea crear un PIF (un acceso directo) para una aplicación, haga los cambios oportunos en el cuadro de diálogo Propiedades y, a continuación, haga clic en Aceptar.
Los archivos PIF de Windows NT son similares a los de Windows 3.x, con dos opciones adicionales: Nombre del archivo Autoexec y Nombre del archivo Config. Estas dos opciones permiten especificar los archivos Autoexec y Config que se deben utilizar con una aplicación. Los controladores o archivos ejecutables de MS-DOS que intenten el acceso directo a un dispositivo para el que no exista un VDD fallarán. Windows NT protege el sistema al impedir estos accesos.
Cuando se inicia una aplicación para MS-DOS, se inicia una nueva NTVDM y se ejecutan sus archivos Autoexec y Config. Los archivos predeterminados, Autoexec.nt y Config.nt, se encuentran en raíz sistema\System32. Los cambios en Autoexec.nt o Config.nt tienen efecto cuando se guardan los archivos y se reinicia la aplicación.
Si desea especificar unos archivos Autoexec y Config diferentes para una aplicación MS-DOS específica, en el archivo PIF de la aplicación, en la ficha Programa, haga clic en Windows NT. En el cuadro de diálogo Configuración de PIF para Windows NT, modifique el PIF para especificar unos archivos Config y Autoexec distintos en cada aplicación. Los archivos PIF se pueden crear para las aplicaciones para MS-DOS al modificar las propiedades predeterminadas de las aplicaciones.
Windows NT admite los mismos comandos del archivo Autoexec que admite MS-DOS 5.0. Después de la versión 5.0 no se agregó a MS-DOS nada que Windows NT necesite o que no tenga ya integrado. Si se utiliza en el archivo Config un comando no compatible con Windows NT, se pasará por alto. Si desea más información acerca de los comandos compatibles, busque en el archivo de Ayuda de Windows NT, el tema "Novedades o diferencias con respecto a MS-DOS".
Win16 en Win32 (WOW) es un programa de 32 bits en modo usuario de Windows NT que permite que las aplicaciones Win16 se ejecuten en un entorno Win32. Al ser el propio Windows 3.x un programa basado en MS-DOS, las aplicaciones para Win16 requieren una NTVDM. Los componentes de WOW funcionan en el contexto de esta NTVDM.
Los componentes del entorno WOW son:
Wowexec.exe: Proporciona la emulación Windows 3.1 para NTVDM.
Wow32.dll: Proporciona la parte de Biblioteca de vínculos dinámicos (DLL, Dynamic-Link Library) del nivel de emulación de Windows 3.1.
Aplicación para Win16: La aplicación de 16 bits que se ejecuta en WOW.
Krnl386.exe: Una versión modificada del núcleo 386 de Windows 3.1 para equipos con procesadores Intel x86, que convierte muchas operaciones en servicios de Win32.
User.exe: Una versión modificada del programa User.exe de Windows 3.1, que convierte las llamadas a la API en servicios de Win32.
Gdi.exe: Una versión modificada del programa Gdi.exe de Windows 3.1x, que convierte las llamadas a la API en servicios de Win32.
Los controladores de dispositivo virtuales de 16 bits para Windows 3.x (VxD) no son compatibles con WOW. Las aplicaciones basadas en Win16 que dependen de esos controladores pueden no funcionar correctamente bajo Windows NT.
WOW convierte mediante thunking las llamadas de 16 bits en llamadas de 32 bits. Cuando una aplicación llama a una función de Windows 3.x, WOW intercepta la llamada y pasa el control a la función equivalente de Win32, Como consecuencia de ello, las aplicaciones para Windows 3.x utilizan funciones de Win32.
Si la función de Win32 necesita devolver algún valor a la aplicación que hizo la llamada, debe convertirse nuevamente de 32 a 16 bits. Aunque estas conversiones producen procesos adicionales, cualquier perjuicio que pudieran representar se ve compensado por la ganancia en velocidad al ejecutar instrucciones de 32 bits.
WOW proporciona el entorno multitarea con asignación no prioritaria para el que están diseñadas las aplicaciones para Win16.
De forma predeterminada, se inicia una única NTVDM cuando se inicia la primera aplicación Win16 y, a partir de entonces, todas las aplicaciones Win16 se ejecutan en esa NTVDM.
El entorno WOW tiene las siguientes limitaciones:
Si una aplicación para Win16 falla, puede afectar a todas las demás aplicaciones Win16 que se ejecuten en la misma NTVDM. Por ejemplo, si una aplicación para Win16 no libera el microprocesador, las demás no tendrán acceso a él, ya que WOW proporciona un entorno multitarea con asignación no prioritaria. Otras aplicaciones para Windows NT seguirán teniendo acceso al microprocesador, pero será necesario cerrar la aplicación para Win16 que ha fallado para que las demás aplicaciones para Win 16 puedan tener acceso al microprocesador.
No existe memoria compartida entre las aplicaciones que se ejecutan en WOW y las demás aplicaciones que se ejecutan bajo Windows NT. Las aplicaciones para Win16 no pueden hacer llamadas a archivos de DLL de 32 bits, y las aplicaciones de Windows NT no pueden hacer llamadas a archivos de DLL de Win16.
Las aplicaciones para Win16 se pueden configurar, aplicación a aplicación, de forma que se ejecuten en sus propios espacios de memoria, para crear así múltiples máquinas virtuales de DOS en NT (NTVDM).
Cuando se configura una aplicación Win16 para que se ejecute en su propio espacio de memoria, se crea una nueva NTVDM cada vez que se inicia la aplicación. Dentro de esta nueva NTVDM se inicia un nuevo entorno de aplicación WOW. Cada aplicación Win16 configurada para ejecutarse en su propio espacio de memoria crea otro nuevo entorno de aplicación WOW dentro de otra nueva máquina virtual de DOS.
Hay varias ventajas en ejecutar las aplicaciones para Win16 en NTVDM separadas:
Fiabilidad: un fallo en una aplicación Win16 no afectará a ninguna otra aplicación Win16.
Interoperabilidad: si las aplicaciones Win16 siguen las especificaciones OLE y de intercambio dinámico de datos (DDF., Dynamic Data Exchange), podrán interoperar con otras aplicaciones en espacios de memoria separados.
Multitarea en asignación prioritaria: si hay varias aplicaciones basadas en Win16 que se ejecutan en un espacio de memoria compartida, una aplicación que esté ocupada impide que las demás se ejecuten, Cuando se ejecuta cada aplicación Win16 en su propio espacio de memoria, todas las aplicaciones se pueden seguir usando incluso cuando una esté ocupada.
Multiproceso: es posible la multitarea y un auténtico multiprocesamiento de las aplicaciones Win16 en los equipos multiprocesador. Si todas las aplicaciones basadas en Win16 se ejecutan en un espacio de memoria compartida, sólo una de ellas se está ejecutando en un momento dado. Por tanto, incluso en los sistemas multiprocesador, sólo puede ejecutarse una aplicación Win 16 a la vez, por lo que estas aplicaciones no aprovechan ninguno de los microprocesadores adicionales del sistema. Sin embargo, si cada aplicación Win16 se configura de forma que se ejecute en un espacio de memoria separado, podrá ejecutarse simultáneamente con otras aplicaciones si el sistema tiene suficientes microprocesadores disponibles.
También hay posibles inconvenientes en la ejecución de las aplicaciones para Win16 en NTVDM separadas:
Consumo adicional de memoria: al iniciar múltiples aplicaciones basadas en Win16 en sus propios espacios de memoria se incrementa el uso de recursos del sistema. Cada aplicación Win16 que se inicia en su propio espacio de memoria inicia otra NTVDM y otro entorno de aplicación WOW. Este incremento adicional es aproximadamente de 2 MB de espacio en el archivo de paginación y 1 MB de RAM por cada espacio de memoria independiente que se utilice. Según la cantidad de memoria RAM instalada en el equipo, este incremento podría afectar al rendimiento del sistema.
Falta de interoperabilidad: las aplicaciones Win16 que no cumplen esos estándares, o que utilizan memoria compartida para intercambiar datos, no funcionarán correctamente en espacios de memoria independientes. Para que esas aplicaciones funcionen correctamente, deben ejecutarse en el entorno de aplicación de máquina virtual de DOS y WOW compartido predeterminado.
Una vez iniciados, la NTVDM y el entorno de aplicación WOW predeterminados (compartidos) permanecen abiertos, incluso cuando todas las aplicaciones Win16 que se ejecutaban con ellos se han cerrado. Puede utilizar el Administrador de tareas para cerrar la NTVDM y el entorno de aplicaciones WOW compartidos, y así recuperar recursos del sistema.
Sin embargo, cuando se inicia una aplicación Win16 en un espacio de memoria separado, se inician una NTVDM y un entorno de aplicación WOW adicionales. Al cerrar la aplicación Win16, su NTVDM y su entorno de aplicación WOW también se cierran. La NTVDM predeterminada no se ve afectada.
Los métodos con los que puede iniciarse una aplicación para Win16 en su propia máquina virtual de DOS son:
En la línea de comandos: Escriba start /separate [ruta_de_acceso]aplicación_ejecutable
En el menú Inicio: Haga clic en Ejecutar. En el cuadro Abrir, escriba [ruta_de_acceso]aplicación_ejecutable y, después, active la casilla de verificación Ejecutar en espacio de memoria separado.
Si la casilla de verificación Ejecutar en espacio de memoria separado aparece atenuada, la aplicación no es para Windows de 16 bits o el sistema no puede encontrarla.
Desde un acceso directo: Cree un acceso directo y, en la ficha Propiedades del acceso directo, haga clic en la casilla de verificación Ejecutar en espacio de memoria separado.
Por asociación de archivos: En el menú Ver del Explorador de Windows NT, haga clic en Opciones. En el cuadro de diálogo Opciones, pase a la ficha Tipos de archivo y seleccione la aplicación de Win 16 que desee modificar. Haga clic en Editar. Haga doble clic en open. Modifique la línea de la acción open para incluir el modificador /separate mediante la siguiente sintaxis:
cmd /c start /separate ruta_de_acceso\Aplicación_ejecutable %1
La asociación de archivos también puede establecerse desde la interfaz de comandos con los comandos ftype y assoc.
Cada aplicación basada en Win16 se ejecuta en la máquina virtual de DOS compartida o en su propia máquina virtual de DOS.
Para configurar una aplicación Win16 de modo que siempre se inicie en una máquina virtual de DOS separada, cree un acceso directo para esa aplicación. Haga clic con el botón secundario del mouse en el acceso directo y, a continuación, haga clic en Propiedades. En el cuadro de diálogo Propiedades, haga clic en la ficha Acceso directo y active la casilla de verificación Ejecutar en espacio de memoria separado. Cada vez que se inicie la aplicación con el acceso directo, se usará automáticamente una máquina virtual de DOS separada.
Sólo las versiones de Windows NT para Intel x86 son compatibles con las aplicaciones para OS/2 en un subsistema OS/2. Los equipos basados en RISC sólo pueden ejecutar aplicaciones para OS/2 si se trata de aplicaciones enlazadas, y en tal caso, se ejecutan en una máquina virtual de DOS. Las aplicaciones enlazadas se escriben para funcionar en MS-DOS o en OS/2.
En los equipos basados en Intel x86, Windows NT es compatible con las aplicaciones para OS/2 1.x basadas en caracteres directamente a través del subsistema OS/2. En dichos equipos, las aplicaciones enlazadas siempre se ejecutarán en el subsistema OS/2, ya que el subsistema OS/2 es más rápido que una máquina virtual de DOS. Para hacer que una aplicación enlazada se ejecute en una máquina virtual de DOS, utilice el comando forcedos.
No existe un subsistema OS/2 en equipos RISC. Por tanto, las aplicaciones para OS/2 no se pueden ejecutar en ellos. La única excepción son las aplicaciones enlazadas. Todas las plataformas de Windows NT son compatibles con aplicaciones para MS-DOS en una máquina virtual de DOS, de forma que si un equipo no tiene un subsistema OS/2, la aplicación enlazada se ejecutará en una máquina virtual de DOS en NT.
La información de configuración del subsistema OS/2 se almacena en dos claves del registro de Windows NT:
HKEY_LOCAL_MACHINE
\System
\CurrentControlSet
\Control
\Session ManagerSubsystems
y
HKEY_LOCAL_ MACHINE
\Software
\Microsoft
\OS/2 Subsystem For NT
Después de que Windows NT establece una configuración inicial del subsistema OS/2, la configuración se puede cambiar.
Cuando se inicia el subsistema OS/2, Windows NT lee la información de configuración del subsistema en el registro de Windows NT, según los archivos Config.sys y Startup.cmd.
La primera vez que se inicia el subsistema OS/2, el registro no contiene la información de configuración necesaria. Windows NT Workstation busca en el archivo Config.sys si se trata o no de un archivo de configuración de OS/2 y, en caso afirmativo, agrega su información al registro.
Las sesiones de aplicaciones para OS/2 utilizan el archivo Startup.cmd, si existe alguno, para configurar el subsistema OS/2 para esa sesión. Algunos valores del archivo Config.sys de OS/2 se pueden agregar al archivo Config.sys.
Si desea información sobre opciones de configuración específicas, vea la Ayuda de referencia de comandos de Windows NT.
Al igual que las máquinas virtuales de DOS, el subsistema OS/2 puede configurarse modificando las opciones del archivo Config.sys. Sin embargo, la versión para OS/2 del archivo Config.sys ni existe realmente como un archivo. La información de este archivo se almacena en el Registro. Cuando un programa para OS/2 (incluido el subsistema OS/2) pide el archivo C:\Config.sys, Windows NT intercepta esa petición y recupera la información del registro. Por ello, cuando se utiliza un editor de texto de OS/2 para modificar Config.sys, el subsistema OS/2 obtiene la información de configuración del Registro y la . almacena en un archivo temporal llamado Config.sys. Cuando se guarda el archivo, el subsistema OS/2 actualiza el Registro, pero no el archivo C:\Config.sys.
Los cambios surten efecto después de que Windows NT se apaga y se inicia de nuevo.
Si el editor de texto empleado para modificar Config.sys no es un editor de OS/2, aparecerá el archivo Config.sys en lugar de la configuración para OS/2 almacenada en el Registro.
Para ejecutar aplicaciones de Presentation Manager para OS/2 1.x de 16 bits en Windows NT es necesario emplear un subsistema complemento. El subsistema complemento de Windows NT para Presentation Manager está diseñado para ayudar en la migración de OS/2 a Windows NT. No se incluye en ninguna versión de Windows NT y debe adquirirse por separado.
El subsistema complemento de Windows NT para Presentation Manager es un subsistema OS/2 alternativo que sólo es compatible con equipos basados en Intel x86.
Como un subsistema alternativo, los archivos siguientes se reemplazan o agregan a la instalación de Windows NT:
Os2.exe, Os2srv.exe, Os2ss.exe y Netetapi.dll.
Controlador de dispositivo de Windows NT: Pmntdd.sys.
Archivos DLL de 16 bits para OS/2 (como Pmwin.dll, Display.dll, Pmgre.dll y otros).
Pmshell.exe, que es el escritorio de Presentation Manager y que se inicia en primer lugar.
Pmspool.exe, el administrador de impresión de Presentation Manager, que inicia Pmshell.
Pmcpl.exe, el Panel de control de Presentation Manager.
Algunas aplicaciones de ejemplo de Presentation Manager.
Cuando se inicia la primera aplicación Presentation Manager de una sesión de Windows NT, se crea un escritorio separado para las aplicaciones de Presentation Manager. El escritorio de Windows NT y los escritorios de Presentation Manager no están integrados.
POSIX es un estándar para las distintas versiones del sistema operativo UNIX y otros sistemas similares. POSIX permite que los programadores de software diseñen aplicaciones que cumplan con el U.S. Federal Information Processing Standard 151.
El subsistema POSIX consta de los siguientes componentes:
Psxss.exe: el principal componente del subsistema. Se inicia cuando se carga la primera aplicación POSIX.
Posix.exe: un programa basado en Windows NT (32 bits) que controla las comunicaciones entre el subsistema POSIX y los servicios ejecutivos. Se carga una copia para cada aplicación POSIX que se inicia,
Psxdll.dll: comparte espacio de direcciones con cada aplicación POSIX y controla las comunicaciones entre la aplicación y Psxss.exe.
Las aplicaciones POSIX interactúan directamente con el subsistema POSIX. POSIX se comunica con los servicios ejecutivos de Windows NT para las operaciones de E/S por pantalla. Para conservar la memoria, POSIX no se carga hasta que haya una aplicación POSIX en ejecución. POSIX admite hasta 32 aplicaciones POSIX concurrentes.
POSIX.1 es una biblioteca de funciones que se ejecutan como llamadas al sistema. El sistema de archivos de Windows NT (NTFS, Windows s NT File System) es el único compatible con POSIX.1 en Windows NT. Cualquier aplicación POSIX que requiera acceso a los recursos del sistema de archivos debe tener acceso a una partición NTFS. Dos de las características de NTFS que POSIX.1 requiere son:
Distinción entre mayúsculas y minúsculas en los nombres: NTFS distingue entre mayúsculas y minúsculas en los nombres de directorios y archivos.
Vínculos múltiples: permite que un archivo tenga más de un nombre.
Las aplicaciones POSIX que no tienen acceso a los recursos del sistema de archivos se pueden ejecutar en cualquier sistema de archivos compatible.
Windows NT se puede ejecutar en múltiples plataformas hardware. Esto significa que los temas relacionados con la compatibilidad de plataformas con Windows NT deben tenerse en cuenta cuando se selecciona una aplicación. Las aplicaciones compatibles con una plataforma hardware pueden tener compatibilidad de origen o compatibilidad binaria. Además, algunas aplicaciones OS/2 no son compatibles con plataformas de Windows NT que no usan procesadores Intel x86.
Una aplicación con compatibilidad de origen debe compilarse nuevamente para cada plataforma hardware. Por ejemplo, la versión Win32 de Microsoft Word para Windows sólo se ejecuta en la plataforma hardware para la que se ha compilado. Aunque hay muchas aplicaciones Win32 disponibles para todas las plataformas hardware compatibles con Windows NT, muchas otras aplicaciones para Win32 son específicas para la plataforma basada en procesadores Intel x86.
Una aplicación con compatibilidad binaria puede ejecutarse en cualquier plataforma hardware compatible con Windows NT, sin que sea necesaria una nueva compilación.
Muchos usuarios que migran a Windows NT usan aplicaciones escritas para MS-DOS y Windows 3.x. Todas esas aplicaciones contienen instrucciones para el procesador Intel x86. Uno de los objetivos de Windows NT es lograr la compatibilidad binaria de las aplicaciones existentes con todos los equipos que ejecutan Windows NT, incluidos los que no tienen compatibilidad integrada con instrucciones para Intel x86.
Para alcanzar este objetivo, las versiones de Windows NT desarrolladas para equipos no basados en Intel x86 contienen código que emula instrucciones de un Intel 80486. Cuando una aplicación para MS-DOS o Windows 3.x se ejecuta en un equipo basado en RISC, cada instrucción se emula con una o más instrucciones del lenguaje máquina nativo del microprocesador. La emulación de tales instrucciones consume tiempo y ralentiza la ejecución de la aplicación. Sin embargo, la pérdida de rendimiento es pequeña ya que un equipo basado en RISC es varias veces más rápido que un Intel 80486.
Las aplicaciones basadas en Windows 3.x y en MS-DOS tienen compatibilidad binaria en todos los equipos compatibles con Windows NT.
Ninguna aplicación basada en MS-DOS o en Windows 3.x que tenga acceso directamente al hardware es compatible con Windows NT en cualquier plataforma.
En los equipos basados en Intel, el subsistema OS/2 de Windows NT es compatible con las aplicaciones para OS/2 1.x basadas en caracteres. Las aplicaciones basadas en OS/2 tienen compatibilidad binaria en todos los equipos con procesador Intel x86. Al no existir un subsistema OS/2 en los equipos RISC con Windows NT, las únicas aplicaciones OS/2 que pueden ejecutarse en ellos son las enlazadas. Las aplicaciones enlazadas están diseñadas para ejecutarse en OS/2 y MS-DOS con un mismo archivo ejecutable. Las aplicaciones OS/2 enlazadas pueden ejecutarse en equipos RISC con Windows NT porque se ejecutan en modo MS-DOS, en una máquina virtual de DOS.
Win32 y POSIX son interfaces de programación de aplicaciones portables. Las aplicaciones que se escriben para esas API tienen compatibilidad de origen en todas las plataformas hardware de Windows NT.
Una de las ventajas de Windows NT es la posibilidad de compartir datos entre las aplicaciones. Todas las aplicaciones basadas en Windows NT pueden compartir datos a través del Portapapeles de Windows NT. Las aplicaciones basadas en Windows 3.x y en Win32 pueden compartir datos mediante DDE y OLE. Este nivel de interoperabilidad es posible ya que todos los subsistemas dependen del subsistema Win32 y del servicio ejecutivo Win32 para las interacciones del usuario.
Los usuarios de procesos distribuidos buscan una infraestructura de aplicación común para crear aplicaciones con múltiples componentes que se ejecutan en diversas plataformas. Hay tres bloques fundamentales con los que se construyen esas aplicaciones:
Comunicaciones (uso de llamadas a procedimientos remotos)
Nombres
Seguridad (comunicaciones de llamada a procedimiento remoto autenticadas)
El Modelo de objetos de componentes distribuido (DCOM) integra esos tres bloques para proporcionar un transporte de componentes de software que funcionen unos con otros a través de una red.
DCOM utiliza llamadas a procedimientos remotos (RPC, Remote Procedure Call) y las funciones de seguridad de Windows NT, como los permisos, para permitir que las aplicaciones se comuniquen a través de redes. Además, DCOM proporciona un modelo de programación para programadores de software que se puede usar para crear aplicaciones distribuidas.
Un ejemplo de aplicación DCOM es un servicio de información de cotizaciones de bolsa. Mediante DCOM, el servidor distribuye el precio de las acciones a los clientes de la red. Una segunda conversación DCOM toma esos datos y los compara con las normas bursátiles almacenadas en un objeto en un tercer equipo. Por ejemplo, es posible crear una regla que especifique cuándo se deben comprar unas acciones determinadas. Si el precio cae por debajo de cierto nivel, se enviará una notificación de compra. El resultado de la comparación entre datos y normas crea una recomendación de compra que se muestra en la pantalla de un cuarto equipo. DCOM proporciona la infraestructura que conecta los objetos distribuidos para que los clientes reciban la información que necesitan.
DCOM utiliza las mismas herramientas y tecnologías que el Modelo de objetos de componentes (COM). COM es la base de OLE y es el estándar por el que los componentes de software utilizan otros componentes, o son utilizados por ellos. De este modo se integra la funcionalidad de aplicaciones diversas. DCOM es OLE en una red; es decir, COM con un cable más largo. Se trata de un transporte rápido para las aplicaciones distribuidas creadas con COM.
Las aplicaciones COM (OLE) existentes pueden utilizar DCOM. Para ello requieren algunas modificaciones menores en la configuración del sistema, pero ninguna en el código de la aplicación en sí. El modelo de programación es idéntico a las tecnologías ActiveX, de modo que la integración puede hacerse directamente. Pruebe las aplicaciones OLE existentes antes de ponerlas en funcionamiento con DCOM.
DCOM incluye las características siguientes:
Distribución: Ejecutar aplicaciones en una red, incluso a través de Internet.
Activación remota: Iniciar una aplicación mediante una llamada a un componente, a diferencia de RPC.
Seguridad: Controlar la seguridad de inicio, acceso y contexto. Los administradores usan la seguridad de Windows NT para establecer permisos para las aplicaciones DCOM y los modifican para la ejecución local y remota.
Herramienta de configuración DCOM: Configurar aplicaciones de 32 bits para comunicarse a través de una red y establecer las propiedades de la aplicación.
Las llamadas a procedimientos remotos (RPC) constituyen la base de las comunicaciones e interoperabilidad entre los distintos servicios DCOM. RPC permite que una aplicación ejecute procedimientos en un equipo remoto. En una aplicación DCOM, un programa usa la red como un medio para ejecutar componentes individuales en otros hosts en ubicaciones remotas.
Por ejemplo, una aplicación cliente ejecuta una llamada a un "código de etiqueta" que ocupa el lugar de un procedimiento local. El "código de etiqueta" utiliza las funciones de comunicación y conversión de datos de una biblioteca RPC para ejecutar la rutina solicitada en un proceso de un servidor remoto.
El código de etiqueta es un fragmento de código diseñado para emular una rutina local cuando la rutina reside en realidad en un equipo remoto.
DCOM utiliza llamadas a procedimientos remotos para permitir a las aplicaciones existentes interactuar en múltiples equipos a través de una red. El proceso siguiente describe el flujo de una llamada de una aplicación cliente a un objeto del servidor.
Una aplicación cliente inicia una RPC.
La etiqueta de RPC del cliente empaqueta la llamada y entonces la biblioteca RPC en tiempo de ejecución transmite el paquete al servidor.
La biblioteca de RPC en tiempo de ejecución del servidor recibe el paquete y lo reenvía a su etiqueta de RPC, que lo convierte en una llamada a procedimiento remoto,
Se ejecuta la llamada al procedimiento remoto.
La etiqueta de RPC del servidor empaqueta el resultado del procedimiento y, entonces, la biblioteca RPC en tiempo de ejecución transmite el paquete al cliente que ejecuta la aplicación.
La biblioteca RPC en tiempo de ejecución del cliente recibe el paquete y lo reenvía a la etiqueta del cliente, que a su vez desempaqueta los datos para la aplicación cliente.
DCOM se instala durante la instalación de Windows NT. Puede utilizar el cuadro de diálogo Propiedades de Configuración COM distribuida para activar DCOM y establecer sus propiedades. Para tener acceso a esta herramienta escriba dcomcnfg en el símbolo del sistema. Dcomcnfg.exe se encuentra en la carpeta raíz_sistema\System32.
Las opciones de configuración de DCOM disponibles en el cuadro de diálogo Propiedades de Configuración COM distribuida son:
Aplicaciones: Ver las aplicaciones actuales y establecer las propiedades de cada una de ellas. Para ver y configurar las propiedades, seleccione la aplicación y haga clic en Propiedades. Aparecerán las fichas siguientes:
General describe las propiedades de la aplicación DCOM, el nombre y tipo de aplicación (así como si se encuentra en el equipo local o en otro equipo de la red), y la ruta de acceso.
La ficha Localización se utiliza para buscar el equipo correcto para una aplicación dada. Un administrador puede, mediante esta ficha, preparar aplicaciones para que se ejecuten en el equipo que contiene los datos, en un equipo local o en algún otro equipo en la red.
Seguridad se utiliza para establecer los permisos siguientes: Acceso para permitir o denegar a usuarios o grupos el acceso a la aplicación; Inicio para permitir o denegar a los usuarios o grupos la capacidad de iniciar la aplicación; y Configuración para permitir a los usuarios o grupos ver o modificar la configuración de la aplicación almacenada en el registro.
Identidad contiene las opciones de cuenta de usuario que permiten al administrador especificar los permisos que deben utilizarse para ejecutar el objeto. Las opciones son Usuario interactivo, Usuario que inicia o Este usuario. La opción Este usuario permite especificar una cuenta de usuario o de servicio.
Propiedades predeterminadas: Activar DCOM en el equipo local y establecer las propiedades de comunicación predeterminadas, como Autentificación predeterminada y Nivel de representación predeterminado. Las propiedades de Autentificación predeterminada definen la seguridad a nivel de paquetes para las comunicaciones entre aplicaciones. El Nivel de representación predeterminado especifica el nivel de permisos que concede una aplicación cliente a una aplicación servidora para realizar tareas de procesamiento en su nombre.
Seguridad predeterminada: Establecer los permisos de seguridad predeterminados para Acceso, Inicio y Configuración.
Los equipos en los que se ejecutan la aplicación cliente y la aplicación servidora deben estar configurados para DCOM. En el equipo que actúa como cliente es necesario especificar la ubicación de la aplicación servidora que se va a iniciar o a la que se va a tener acceso. En el equipo en que se ejecuta la aplicación servidora hay que especificar la cuenta de usuario con permiso de acceso o de inicio de la aplicación, y la cuenta de usuario que se utilizará para ejecutarla.
Este tema presenta las herramientas que permiten que los administradores y usuarios administren aplicaciones bajo Windows NT.
La interfaz de comandos de Windows NT (Cmd.exe), ubicada en la carpeta Programas del menú Inicio, inicia una interfaz de 32 bits en modo carácter para Windows NT y todos sus subsistemas. Al iniciarse una interfaz de comandos no se inicia ninguna máquina virtual de DOS (NTVDM). Sólo se inicia una máquina virtual de DOS cuando se inicia una aplicación basada en MS-DOS.
En la interfaz de comandos, un usuario puede realizar las siguientes tareas:
Iniciar aplicaciones, incluidas las de Windows NT (basadas en Win32), Windows 3x (basadas en Win16), MS-DOS, OS/2 1.x basadas en caracteres o POSIX.
Iniciar cualquier archivo por lotes con la extensión .bat o .cmd.
Ejecutar cualquier comando de Windows NT.
Administrar o usar los recursos de la red.
Cortar y pegar información entre aplicaciones, incluso en el caso de aplicaciones que se ejecutan en subsistemas distintos.
Mezclar comandos de los distintos subsistemas (por ejemplo, la canalización entre MS-DOS y una aplicación POSIX).
Use el programa Consola del Panel de control para configurar los valores predeterminados de cualquier instancia de la interfaz de comandos que esté ejecutando el usuario que ha iniciado la sesión. Estos valores de configuración se almacenan para cada usuario en el registro en la siguiente ubicación:
HKEY_CURRENT_USER
\Console
Cada usuario puede así configurar los valores predeterminados de la interfaz de comandos.
Para configurar una interfaz de comandos que se esté actualmente en ejecución, en la esquina superior izquierda de la ventana Cmd.exe, haga clic en el icono MSDOS. Haga clic en Propiedades y utilice el cuadro de diálogo Propiedades de "Interfaz de comandos" para configurar la interfaz de comandos de alguna de las siguientes formas:
Aplicar las propiedades sólo a la ventana actual.
Las opciones elegidas sólo se aplicarán a la ventana de interfaz de comandos actual. Si se inicia otra ventana de interfaz de comandos, tendrá la configuración predeterminada.
Modificar el acceso directo utilizado para abrir esta ventana.
Si la interfaz de comandos se ha abierto con un acceso directo, es posible modificar las opciones de configuración de ese acceso directo. Todas las interfaces de comandos iniciadas con él utilizarán la configuración modificada, y las iniciadas con el botón Inicio o al ejecutar Cmd.exe, usarán la configuración predeterminada.
Windows NT asigna prioridades a las aplicaciones y distribuye el tiempo de proceso entre ellas. La prioridad base se puede modificar para aumentar o disminuir el rendimiento del sistema.
Los niveles de prioridad van de 0 a 31. La prioridad base normal es 8. Las aplicaciones críticas del sistema utilizan niveles más altos, mientras que otras pueden tenerlos más bajos.
Prioridad 0-15: Aplicaciones dinámicas: aplicaciones de usuario y la mayor parte de las funciones del sistema operativo que no son vitales para el rendimiento del sistema y se pueden almacenar en el archivo de paginación.
Prioridad 16-31: Aplicaciones en tiempo real, como el núcleo, que no pueden almacenarse en el archivo de paginación.
En un sistema operativo multitarea con asignación de prioridad, como es Windows NT, el micronúcleo programa la ejecución de los subprocesos en el microprocesador por orden de prioridad e interrumpe los subprocesos en ejecución en favor de los que tengan una prioridad mayor. Para mejorar el rendimiento se puede aumentar o disminuir la prioridad de los procesos que compiten entre sí. Para iniciar una aplicación cambiando su prioridad base, tiene las opciones siguientes:
| En la interfaz de comandos, escriba | Efecto en la prioridad base |
| start /realtime aplicación_ejecutable | Establece 24 como prioridad base |
| start /high aplicación_ejecutable | Establece 13 como prioridad base |
| start /normal aplicación_ejecutable | Establece 8 como prioridad base |
| start /low aplicación_ejecutable | Establece 4 como prioridad base |
Usar el comando start para ejecutar una aplicación con mayor prioridad puede reducir el rendimiento, ya que otras aplicaciones tendrán menos tiempo de entrada/salida. Ésta es la causa por la que sólo usuarios con privilegios de administrador pueden utilizar la opción /realtime.
Windows NT cambia automáticamente las prioridades de las aplicaciones. Para mejorar el rendimiento del sistema, puede modificar manualmente la prioridad relativa de las aplicaciones en primer y segundo plano con la opción Mejora de la ficha Rendimiento del programa Propiedades del sistema, en el Panel de control. En la tabla siguiente se describen estas opciones.
| Opción | Respuesta | Valor en el registro |
| Ninguna | La prioridad de la aplicación en primer plano no cambia. Todas las aplicaciones de primer y segundo plano conservan los niveles de prioridad base. Utilice el valor Ninguno cuando todas las aplicaciones tengan la misma importancia para la tarea que se está realizando. Por ejemplo, la ejecución de una aplicación administrativa en un servidor de aplicaciones no debería ralentizar el rendimiento de los clientes conectados al servidor. | 0 |
| Intermedia | La prioridad de la aplicación en primer plano aumenta en una unidad. Las aplicaciones en segundo plano mantienen la prioridad base. Puede usar esta opción en las situaciones que no sean críticas. Por ejemplo, un juego necesita una respuesta más rápida mientras se comprueba la ortografía de un archivo. | 1 |
| Máxima | La prioridad de la aplicación en primer plano aumenta en dos unidades. Las aplicaciones de segundo plano conservan sus niveles de prioridad base. Utilice este valor para ejecutar una aplicación importante que deba recibir el máximo tiempo de procesador posible, al mismo tiempo que permite que las aplicaciones de segundo plano tengan el mínimo acceso a los recursos del sistema. Por ejemplo, un archivo con datos críticos debe recibir el máximo tiempo de CPU para procesar sus cálculos matemáticos, mientras se envía otro archivo a una cola de impresión. | 2 |
En Windows NT 4.0 se utiliza la programación quantum (división del tiempo) para ajustar el tiempo de respuesta en primer y en segundo plano. El Monitor del sistema no muestra estas prioridades ni sus cambios. Sin embargo, sí pueden observarse en la siguiente ubicación del registro:
HKEY_LOCAL_MACHINE
\SYSTEM
\CurrentControlSet
\Control
\PriorityControl
\Win32PrioritySeparation
El Administrador de tareas es una herramienta de Windows NT que proporciona datos acerca de los procesos actuales. Utilice el Administrador de tareas para controlar y asignar prioridades a las aplicaciones y procesos, y para presentar datos de rendimiento del sistema.
Posibilidades del Administrador de tareas
El Administrador de tareas ofrece las siguientes posibilidades:
Muestra las aplicaciones y procesos en ejecución, incluidos los procesos de 16 bits.
Muestra las medidas de rendimiento más utilizadas para los procesos, como el tiempo de procesador, tamaño de memoria física, tamaño de memoria virtual, fallos de paginación, prioridad base y número de subprocesos.
Muestra curvas gráficas y valores instantáneos de uso de procesador y memoria del equipo.
Establece la afinidad del procesador para una aplicación, cambia la prioridad base de un proceso y activa un depurador.
El cuadro de diálogo Administrador de tareas de Windows NT contiene tres fichas, sus funciones son:
Ficha Aplicaciones: Muestra el estado de los programas o tareas que hay en ejecución en el equipo. Utilice las opciones de la ficha Aplicaciones para finalizar una aplicación, pasar a una ventana de aplicación o iniciar una nueva aplicación.
Ficha Procesos: Muestra información sobre los procesos que se están ejecutando en el equipo. En el menú Opciones, seleccione Mostrar tareas de 16 bits para incluir estas tareas en la tabla de procesos.
Ficha Rendimiento: Supervisa el rendimiento del sistema, incluido el uso del microprocesador y de la memoria.
Puede iniciar el Administrador de tareas de una de las siguientes formas:
Presione CTRL+MAYÚS+ESC.
Haga clic con el botón secundario del mouse en la barra de tareas de Windows NT y, a continuación, haga clic en Administrador de tareas.
Presione CTRL+ALT+SUPR y, a continuación, haga clic en Administrador de tareas.
En los equipos con múltiples microprocesadores, el micronúcleo de Windows NT distribuye el procesamiento por todos ellos según la prioridad. A menudo, los subprocesos de un mismo proceso se ejecutan en más de un microprocesador. Windows NT utiliza un algoritmo llamado afinidad suave para distribuir la carga de los microprocesadores. Esto significa que cuando es posible, Windows NT reasigna los subprocesos al mismo procesador en que se han ejecutado anteriormente, pero Windows NT no hará esperar a los subprocesos en el caso de que ese procesador esté en uso.
Es posible limitar la ejecución de una aplicación a uno o más microprocesadores. Es lo que se conoce como afinidad dada. Para seleccionar los microprocesadores que debe usar un proceso, en la ficha Procesos del administrador de tareas, haga clic con el botón secundario del mouse en el nombre del proceso, a continuación, haga clic en Establecer afinidad y, después, en uno o varios de los procesadores de la lista. La opción Establecer afinidad sólo es visible en los equipos con múltiples microprocesadores. Aunque es posible reservar un microprocesador para un subproceso específico, normalmente al hacerlo se reducirá el rendimiento general, ya que los demás subprocesos sólo podrán utilizar los microprocesadores restantes.
Cuando está en ejecución el Administrador de tareas, aparece en la barra de tareas, frente al botón Inicio, un medidor de uso de CPU que indica el rendimiento del sistema. Cuando el cursor se coloca sobre este icono, la información sobre herramientas indica el porcentaje de uso de CPU. La barra de estado situada en la parte inferior de la ficha Rendimiento también muestra datos de rendimiento. Muestra el número total de procesos, el uso del procesador y el uso de la memoria del sistema.