Windows Y Los Pc En General

[Tecnho]

Antes de comenzar a conocer el sistema operativo Windows y la programación en él, bueno es conocer su historia. Conocer sus raíces permite, muchas veces, entender algunos tópicos que Windows ha ido heredando de su antecesor: MS-DOS. También es bueno conocer qué hace un computador antes de cargar cualquier sistema operativo.

A pesar que Windows NT no haya estado inspirado en MS-DOS, los equipos x86 tienen una BIOS diseñada para MS-DOS, en especial los equipos con procesadores 386 y 486. Así, se verá cómo Windows NT debe tratar, muchas veces, con una BIOS diseñada para MS-DOS y superar las restricciones que esto impone.

En este caso se analizará brevemente lo que hace un PC con procesador x86 antes de cargar cualquier sistema operativo. Luego, desde DOS hasta llegar a Windows NT 5.0, se verán las principales características de cada uno de los sistemas operativos que han surgido en el camino.

El PC desnudo

Antes que el usuario cargue algún sistema operativo, el PC realiza el POST (Power On Self Test), que determina los dispositivos disponibles, y busca un disco de arranque. Estas funciones son realizadas por un conjunto de instrucciones incorporadas en la máquina mediante una ROM. En este sentido, no existe una cosa que se pueda llamar un "PC desnudo", debido a que siempre hay algún tipo de software en el sistema.

Tradicionalmente, la ROM se basaba sobre un chip programado en fábrica. Las actualizaciones de ROM eran realizadas físicamente reemplazando el chip. Los fabricantes han optado hoy en día por la flash memory, un tipo de memoria no volátil que puede reescribirse por el computador usando una utilidad especial.

Direcciones reservadas de hardware

El PC IBM original se basaba en el procesador 8088 de Intel. Este soportaba hasta 1 MB de memoria. En su tiempo, esto era un enorme rango de memoria.

Una característica común de los PCs anteriores era que se conectaba lógicamente el adaptador de video a la memoria del computador. El contenido de la pantalla era para la aplicación como un área de almacenamiento. En vez de escribir a la pantalla como si fuera un dispositivo, el programa podía simplemente mover datos a la posición del buffer y esos datos aparecerían en la pantalla. Es decir, IBM tuvo que entregar parte de ese megabyte a las direcciones de los dispositivos de entrada y salida.

Debido a que 1 MB parecía ser mucho más grande de lo necesario, IBM entregó una solución: la división de tres áreas de 128 KB cada una desde la parte superior del rango de direcciones. Esto deja 640 KB para los programas del usuario, ó 10 veces la cantidad de memoria que sería soportada en la tarjeta madre del primer PC.

Inmediatamente más allá del área usuario, el primer área del sistema de 128 KB (representado en amarillo en la figura anterior) se utiliza para comunicarse con el adaptador de video. El uso de esta área es estándar para el modo VGA (25 x 80 caracteres ó 640 x 480 puntos con 16 colores). Todos los adaptadores de video soportan el modo VGA y todos los sistemas operativos parten en este modo. Para soportar un modo como el SVGA (mayor resolución, más colores y más velocidad) la programación es diferente para cada adaptador por vendedor y modelo. Windows, OS/2, o Unix deben cargar un driver (controlador) específico para la tarjeta.

El área de 128 KB (representado de rosado en la figura anterior) justo por debajo del límite de 1 MB se reservó para las instrucciones de la ROM. El primer PC usaba 64 KB de esta parte superior, pero varias máquinas modernas utilizan esta área de manera completa. La ROM del sistema incluye las instrucciones de POST (visto anteriormente), el soporte para la BIOS, y alguna vez se incluyó una copia de Microsoft Basic.

El lector puede estar preguntándose el por qué se copian las instrucciones de la ROM en la RAM y la razón es que los chips de memoria ROM son relativamente lentos, de manera que un computador (486 o superior) copia las instrucciones de la ROM en los 128 KB de RAM estándar (la tarjeta madre luego bloquea esta área con el objeto de que no sea cambiada por un programa normal).

Los 128 KB del medio (representados de azul en la figura anterior) es la proyección del bus de entrada y salida. Las tarjetas adaptadoras conectadas a la máquina pueden proveer código de inicialización en ROM que aparecerá en este rango de direcciones. Por ejemplo, una tarjeta de video proveerá el código de inicialización para activar y establecer los modos correctos de video. Un adaptador SCSI proveerá código de inicialización para instalar discos duros (incluyendo el disco de arranque si no existiesen otros discos presentes). Cualquier parte de esta área que no sea usada puede convertirse mediante versiones modernas de DOS en UMB (Upper Memory Blocks) para almacenar drivers de dispositivos y otras rutinas de soporte.

Los computadores modernos tienen más de 1 MB de memoria, pero deben acomodarse a la arquitectura del PC original otorgando 640 KB de memoria para programas, saltándose luego las tres áreas de 128 KB para el hardware, y comenzando nuevamente con la memoria para programas luego del primer MB. La fragmentación producida entre las direcciones que se encuentran desde los 640 KB y 1024 KB es la diferencia fundamental entre un PC y cualquier otro sistema.

Antes de cargar al sistema operativo, la rutina de inicialización prepara a la máquina para ejecutar DOS. En 1980, IBM y Microsoft trabajaron en un conjunto común de reglas para atar la ROM con DOS. Existen varias tablas DOS que son llenadas por la ROM antes que DOS arranque. Otros sistemas operativos (OS/2, NT) actualmente no utilizan las mismas tablas, pero pueden usar los valores originalmente almacenados ahí para descubrir información sobre los dispositivos instalados.

[Tecnho]

BIOS

Después que las pruebas de arranque han sido ejecutadas y el sistema está cargado, la ROM aún sigue siendo importante debido a que contiene el soporte básico de entrada y salida (BIOS). La BIOS provee un conjunto de rutinas que el sistema operativo o los programas de aplicación pueden llamar para manipular el monitor, teclado, discos duros, discos flexibles, puertos COM o impresoras.

Durante el desarrollo del primer PC, IBM hizo un trato con Microsoft. La administración directa de las tarjetas adaptadoras podría ser manejada sólo por programas que IBM proveía con la ROM del computador. DOS sería escrito para utilizar estos servicios. De esta manera, si IBM decidía cambiar el hardware, éste podía embarcar nuevos modelos de chips con cambios en la BIOS y no requería que Microsoft cambiara el sistema operativo.

DOS aún tiene que ser cambiado para soportar diferentes diseños de teclado, diskettes de 3 ½ pulgadas y otros cambios de hardware. Por otro lado, esto ha sido generalmente fácil con las nuevas generaciones de hardware para simplemente emular adaptadores, en vez de forzar un cambio en la BIOS. Por ejemplo, todos los controladores de discos duros utilizados en los PCs de hoy en día tienen la habilidad de emular la tarjeta ST506, la cual IBM embarcó en su primer computador XT. La emulación evita cambios en la BIOS.

Las llamadas a la BIOS pueden ser atrapadas antes que ellas lleguen a la ROM. Ellas pueden ser atrapadas por otra ROM ubicada en otras tarjetas adaptadoras, por los controladores de dispositivos, y por otras rutinas residentes.

La llamada a la BIOS es importante como una interfaz y una parte del diseño subsecuente del sistema. Sin embargo, se puede decir que la BIOS se diseñó con dos limitaciones que afectarán a cada sistema que la use (en particular, DOS y Windows 3.1):

Buffers en los primeros 640 KB: La BIOS estándar del sistema y (aún peor) las extensiones de ROM provistas por las tarjetas adaptadoras en el área de direcciones del sistema de los 128 KB del medio, soportan sólo direcciones reales dentro del primer megabyte de RAM. Para precisar, la mayoría de los dispositivos reciben datos directamente desde la CPU, así la mayoría de las rutinas de la BIOS no dependen de la localización física de los datos en la RAM. Sin embargo, algunos dispositivos, utilizan técnicas más eficientes, como las formas de acceso directo a memoria (DMA o BUS MASTER). Otros dispositivos (particularmente los adaptadores de LAN) esperan generar una interrupción y luego recibir datos desde un manejador de interrupciones. En cualquier caso, el uso de la programación de la BIOS estándar puede depender de los datos residentes en los buffers que se encuentran en los 640 KB del área de usuario. Mientras los programas DOS y Windows pueden usar una variedad de técnicas creativas de extensión de memoria para utilizar los otros megabytes de memoria presentes en la máquina, el I/O generalmente involucra el movimiento de los datos del usuario entre las direcciones de memoria más altas y preasignar buffers en algún lugar de los 640 KB de abajo. El mover datos agrega un gran costo al sistema.

I/O Sincrónico: Un programa desea leer un registro desde disco. La BIOS envía el requerimiento al adaptador del disco, entonces luego se queda en un ciclo preguntando "¿Está listo?", No; "¿Está listo?", No…Después de 15 a 30 milisegundos la respuesta finalmente es "Sí" y el computador puede regresar a hacer el trabajo útil. Esto no es un gran problema para el procesador de textos del usuario, pero esto es un límite fatal para un archivo o un disco de base de datos que debe poder realizar I/O asincrónico. Este el porqué los servidores departamentales deben estar basados en algún tipo de sistema avanzado (OS/2, NT, Unix o Netware) que no hagan uso de la BIOS. Nótese que Novell Netware captura el mercado para servidores PC, al entregar un sistema operativo especializado que evita la BIOS y es multitarea para PCs potenciados por un procesador 286 cuando Microsoft e IBM tenían sólo servidores basados en DOS.

DOS

Las aplicaciones que corren bajo DOS tienen todos los privilegios del sistema. Ellas pueden acceder a cualquier almacenamiento, cambiar las funciones de control de la CPU, y utilizar cualquier dispositivo de hardware. Esto permite que los programas extiendan el sistema operativo DOS con funciones adicionales, como el útil programa DOSKey, pero también permite que los virus dañen la máquina.

Aunque DOS 6.x se distribuye en 4 ó 5 discos, el espacio está lleno con programas de utilidad que comprimen datos, realizan respaldos, y verifican la existencia de algún virus. El sistema operativo DOS mismo está contenido en un par de archivos ocultos llamados IO.SYS y MSDOS.SYS en las versiones de DOS realizadas por Microsoft, e IBMBIO.SYS e IBMDOS.SYS, para las versiones de DOS hechas por IBM bajo licencia Microsoft.

Los servicios de DOS son solicitados cuando una aplicación llama a la interrupción INT 21. Esta instrucción busca un punto de entrada del administrador de servicios de DOS en una tabla de hardware y salta a la rutina en el módulo MSDOS.SYS o IBMDOS.SYS.

En otros sistemas operativos, una aplicación debe realizar una llamada al sistema (system call) para requerir servicios, como, por ejemplo, en UNIX. Los programas de aplicación DOS corren con total privilegio; de esta manera, un programa puede hacer cualquier cosa que desee si tiene la suficiente lógica de programa para manejar el hardware directamente. Los servicios de DOS proveen, en cambio, un conjunto conveniente de servicios útiles que los programas solicitan debido a que ellos no quieren lidiar con detalles.

DOS = Sistema de Archivos FAT

El soporte de la BIOS para un disco duro (INT 13) provee un acceso crudo (RAW) a los datos. A través de la BIOS cada unidad de disco se ve como un único gran archivo. DOS maneja la FAT (File Allocation Table) o Tabla de Asignación de Archivos, que divide al disco en subdirectorios y archivos. La mayoría de los servicios DOS ofrecidos a los programas se relacionan con el acceso a los archivos en disco (abrir, cerrar, leer, escribir, renombrar, eliminar, crear directorio, eliminar un directorio, listar un directorio). Es por eso el nombre de DOS (Disk Operating System) o Sistema Operativo de Disco.

Existen algunos programas que se "saltan" a los servicios de DOS e interpretan la FAT por ellos mismos. Norton Disk Doctor y algunas utilidades que pueden examinar y reconstruir la FAT son ejemplos de ellos. Los programas de respaldo usualmente proveen su propio soporte a nivel de hardware para los discos duros y los discos flexibles, con el objetivo de evitar las limitaciones impuestas por DOS/BIOS y poder realizar I/O de forma asincrónica en segundo plano. Un buen programa de respaldo estará escribiendo el último bloque de datos al diskette, comprimiendo el bloque actual, y leyendo el próximo bloque desde el disco, todo ocurriendo al mismo tiempo. Esto no es posible con los servicios estándares de DOS/BIOS, pero el hardware lo permite y un programa hábil puede acceder al hardware directamente.

DOS también asigna almacenamiento en el área del usuario. Además de los 640 KB, DOS puede ser configurado para utilizar el hardware de administración de memoria 386 para "completar" áreas no usadas de los 128 KB, que es el rango de dirección de hardware (desde C0000 hasta DFFFF, utilizando notación hexadecimal). Esto se convierte en los Bloques de Memoria Superior (Upper Memory Blocks o UMB) y se utiliza para cargar dispositivos y otras rutinas residentes.

Las restantes funciones de DOS son de mantención. Por ejemplo, hay servicios que solicitan o fijan la hora o la fecha. DOS mismo provee muy poca cantidad de funciones. Es posible cargar otros programas que provean servicios adicionales (video, mouse, red, compresión, etc.). DOS fue capaz de sobrevivir por 15 años debido a su simpleza y facilidad de extensión.

Drivers y TSR’s

DOS puede extenderse mediante controladores (drivers) de dispositivo, rutinas residentes (TSR’s), y por shells (comúnmente denominados intérpretes de comandos). Los drivers de dispositivo son cargados utilizando las sentencias DEVICE del archivo CONFIG.SYS. Así, es posible cargar un controlador para un CD-ROM bajo MS-DOS. Las rutinas residentes pueden cargarse en cualquier instante, aunque comúnmente son instaladas por rutinas en el AUTOEXEC.BAT. Un shell se "rapta" la interfaz de usuario y carga otro programa. El ejemplo más común de shell es Windows 3.1.

Agregar soporte para un CD-ROM, para un adaptador de red, PCMCIA, caché de disco, y algunas otras características útiles pronto causará que la cantidad de espacio que queda para los programas DOS se hace poco. DOS adquirió algunos trucos para extender su vida. Poner la mayor parte del sistema operativo en los primeros 64 KB después del primer megabyte ayudó un poco. La creación de los UMB utilizando el hardware de administración de memoria 386 para reproyectar los 128 KB reservados para las tarjetas adaptadoras pero no utilizados ayudó otro poco.

Sin embargo, no hay suficiente espacio en DOS para cargar el cliente Novell, el cliente Windows NT, el protocolo TCP/IP para Internet, soporte para la COM, para los drivers de los dispositivos SCSI, para el sistema de archivos de CD-ROM, y todo el resto de la maraña de la vida moderna. Un usuario típico de DOS poseía diferentes configuraciones para cada evento, y reiniciaba el equipo para seleccionar la configuración antes de cargar ciertos programas. (¿Suena familiar el desactivar DOSKey para correr algún juego?). Después de hacer esto por un tiempo, el usuario estaba listo para mudarse a un sistema operativo real.

DOS depende de la BIOS, de manera que hereda las dos limitantes. Los buffers deben estar en el área de 640 KB. Las operaciones de I/O son sincrónicas, de manera que la CPU está completamente amarrada cuando cualquier disco está procesando un requerimiento.

Para mantener al sistema pequeño y simple, DOS carece de una sofisticada administración de memoria y de programas, que sería ideal poder cargarla bajo demanda. Si un programa DOS necesita un servicio, el soporte para ese servicio debe haber sido previamente cargado. Los niños aprendieron que antes de jugar un juego debe existir un mouse, por eso ellos deben primero cargar MOUSE.COM en la memoria.

Una vez que el soporte ha sido cargado, la única manera de descargarlo es reiniciar el sistema. Si un usuario levanta DOS con solamente el mínimo soporte, existe una chance que los programas no tendrán las funciones que necesitan para correr. Los usuarios DOS solucionan este problema manteniendo docenas de configuraciones especializadas, y cada una optimizada para ejecutar un paquete distinto. Reinicar DOS cada vez que se desea cambiar de programa se hace aburrido e incentiva al usuario a desear un real sistema operativo.

[Tecnho]

Windows 1.0 / 2.0

Si bien Microsoft seguía desarrollando DOS, sabía que tarde o temprano había que dar un vuelco. Windows fue esta alternativa y que será el tema en el que se centrará este estudio desde aquí en adelante.

En primer lugar se verá una muy pequeña reseña de lo que fueron Windows 1.0 y Windows 2.0. En realidad, Windows, como interfaz de usuario estable, como sistema estable y como éxito comercial llegó en la versión 3.0 y es ahí, en la versión 3.x donde se ahondará más en estas versiones de 16 bits de Windows.

Windows 1.0

Primera versión de Microsoft Windows, lanzada el 20 de Noviembre de 1985. Tomó un total de 55 programadores para desarrollarlo y no permitía ventanas en cascada, solamente en mosaico.

Microsoft comenzó el desarrollo del "ADMINISTRADOR DE INTERFAZ", que posteriormente derivó en Microsoft Windows en Septiembre de 1981. La interfaz inicial tenía menús ubicados en la parte inferior de la ventana y la interfaz sufrió un cambio en 1982 cuando se diseñaron los ahora comunes menús desplegables.

Esto ocurrió después de Apple Lisa, un experimento de Apple por llevar una interfaz gráfica al usuario. Sin embargo, ocurrió antes de Macintosh. Windows prometía una interfaz gráfica fácil de usar y la utilización de gráfica independiente del dispositivo, así como el soporte de multitarea.

Las siguientes fueron las principales características de Windows 1.0:

• Interfaz gráfica con menús desplegables, no había ventanas en cascada y soporte para mouse.

• Gráficos de pantalla e impresora independientes del dispositivo.

• Multitarea cooperativa entre las aplicaciones Windows.

Windows 2.0

Segunda versión de Microsoft Windows, lanzada en 1987. Windows 2.0 que tenía más características que Windows 1.0, tales como iconos y ventanas traslapadas. Cuando se lanzó Windows/386, Windows 2.0 fue renombrado como Windows/286.

Nacen aplicaciones como Excel, Word for Windows, Corel Draw!, Ami y PageMaker.

Las siguientes fueron las principales características de Windows 2.0:

• Ventanas traslapadas.

• Archivos PIF para aplicaciones DOS.

Windows/386

En 1987 Microsoft lanzó Windows/386. A pesar de ser equivalente a su hermano Windows/286, mientras corrían aplicaciones Windows, Windows/386 proveía la capacidad de ejecutar múltiples aplicaciones DOS simultáneamente en memoria extendida.

La siguiente fue la principal característica de Windows/386:

• Múltiples máquinas virtuales DOS con multitarea.

Windows 3.0

Una completa reconstrucción de Windows con muchas nuevas facilidades, tales como la habilidad de direccionar más allá de 640 KB. Fue lanzado en 1990, y vendió más de 10 millones de copias.

Las siguientes fueron las principales características de Windows 3.0:

• Modo estándar (286), con soporte de memoria grande (large memory).

• Modo Mejorado 386, con memoria grande y soporte de múltiples sesiones DOS.

• Se agregó el Administrador de Programas y Administrador de Archivos.

• Soporte para Red.

• Soporte para más de 16 colores.

• Soporte para cajas de selección, menús jerárquicos y los archivos. INI privados para cada aplicación empezaron a cobrar más valor.
  **
  Windows 3.1**

Una versión de Windows con muchas mejoras a Windows 3.0. Incluye soporte para fuentes True Type y OLE. Esta versión fue testigo de la pérdida del modo real, lo cual significa que no corre en procesadores Intel 8086.

Las siguientes fueron las principales características de Windows 3.1:

• No hay soporte para el modo Real (8086).

• Fuentes TrueType.

• OLE - Object Linking and Embedding.

• Capacidad para que una aplicación reinicie la máquina.

• Soporte de API de multimedia y red.

Como anteriormente se dijo, Windows 3.x fue en realidad la primera versión estable de este nuevo entorno y los subsiguientes sistemas operativos Windows heredan muchas cosas de este Windows 3.x. Por tal motivo vale la pena estudiar las aplicaciones y su comportamiento en Windows 3.x.

Aplicaciones en Windows 3.x

Si alguien compraba un PC en 1994, probablemente venía con Windows 3.1 instalado. Cuando la máquina arrancaba, primero se cargaba alguna versión de DOS 6.x incluyendo los drivers desde CONFIG.SYS y las rutinas residentes en el AUTOEXEC. En particular, los drivers de DOS HIMEM, y EMM386 proveen la administración básica de RAM por sobre el primer megabyte y SMARTDRV provee un caché de disco para mejorar el rendimiento de I/O. La última sentencia del AUTOEXEC.BAT, usualmente iniciaba Windows.

Windows depende de los drivers de DOS y de la BIOS para soportar discos flexibles, discos duros y CD-ROM. La función primaria de Windows es proveer la interfaz WIMPS (Windows, Icons, Mouse, Pointer, Scroll-Bars). Para llevar a cabo esto, la mayoría del código de Windows consiste en rutinas de manejo de botones, cajas, menús, listas desplegables, y otros componentes de las cajas de diálogo. Este código es tan grande que no puede calzar en los 64 KB de DOS. Windows está, por lo tanto, forzado a explotar la RAM de manera completa.

Los drivers HIMEM y EMM386 proveen una muy primitiva administración de memoria, Windows debe agregar su propio método con algoritmos mucho más sofisticados. En particular, los programas y bibliotecas de Windows tienen que cargarse y ejecutarse en las direcciones por sobre el primer megabyte.

Windows provee algún soporte para dispositivos, pero éste se concentra en los dispositivos que tienen mayor efecto en la interfaz de usuario. Durante la instalación de Windows, un usuario selecciona un tipo de adaptador de video (incluyendo resolución, el número de colores, y la taza de refresco), un tipo de teclado, y un tipo de mouse. Windows continúa remitiéndose a DOS para administrar los sistemas de archivos y los dispositivos de disco.

Para el programa de aplicación, Windows es una gran colección de subrutinas para dibujar cajas y texto en la pantalla o en una página de una impresora. Existen también colecciones más pequeñas que cargan programas, asignan almacenamiento, administran cronómetros (temporizadores o timers) y el puerto COM.

Para Windows, el programa de aplicación aparece como una subrutina que deberá llamarse cuando el usuario mueve el mouse en un área particular de la pantalla y hace clic sobre un botón, o presiona una tecla. Windows pasa la información a la subrutina de la aplicación sobre estos eventos, y la aplicación llama a otras rutinas para cambiar la pantalla como respuesta al evento.

Cualquiera que haya escrito un programa sabe que un error en una subrutina hará caer al programa que la llama. Sin alguna distinción formal entre los programas y el sistema, Windows es vulnerable a errores en cualquier programa que éste ejecute.

Las limitaciones de Windows eran claras desde el inicio. La solución era también entendida por todos los que eran familiares con Mainframes, minicomputadores VAX, o UNIX. Definitivamente, el computador necesitaba un sistema operativo "real" que pudiera controlar estos programas, aislarlos uno de otros y aislarlos de los bloques donde se controla el sistema y donde el daño real podría ocurrir. En 1985, IBM y Microsoft comenzaron el desarrollo de un sistema mejor, y en 1988, lanzaron la primera versión de OS/2. Tenía prácticamente la misma interfaz de Windows, pero ejecutaba cada aplicación en su propia y aislada porción de memoria, y mantenía una limpia y protegida interfaz entre aplicación y sistema.

Mientras tanto, Microsoft continuó desarrollando Windows y lanzó la versión 3.0 durante el verano (en el hemisferio norte) de 1990. Aunque carecía de la integridad estructural de OS/2, corría más rápido y utilizaba menos memoria. Las aplicaciones fueron eventualmente depuradas de manera que se ejecutaran bien la mayor parte del tiempo. El éxito de Windows 3.0 marcó un hecho importante: Demostró que los usuarios están fuertemente influenciados por la apariencia y el costo, y dan poca consideración a la estructura basal.
**
Administración de Memoria en Windows 3.x**

Windows provee dos esquemas de administración de memoria. El Modo Estándar, el cual fue diseñado para las capacidades del chip 286, donde los programas eran divididos en sectores. Cada sector es de una longitud variable de hasta 64 KB. Los sectores pueden residir en la memoria extendida o pueden ser intercambiados a un archivo de disco. Este ordenamiento tiende a ahorrar memoria, pero provee una masiva carga de mantención en la CPU para administrar y mover los sectores por la memoria.

En un sistema 386/486/Pentium, Windows corre en modo Enhanced (Mejorado). La memoria se divide en páginas de 4 KB. Los sectores de programas o de bibliotecas son redondeados hasta lo más cercano a 4KB y luego son trozados en páginas. El redondeo tiende a utilizar más memoria, pero las páginas son intercambiables y pueden ser asignadas, liberadas, y reutilizadas. La memoria puede ser lógicamente extendida utilizando un archivo de disco. Una máquina de 8 MB de RAM y un archivo de disco de 8 MB puede tratarse como si tuviera 16 MB de memoria lógica en la cual se almacenan librerías y programas.

Aunque aún hay millones de 286 en uso, las últimas versiones de los programas de Windows no correrán en ellas. Debido a que requieren al menos un procesador 386 y 4 ó más megabytes de RAM.

Bibliotecas de Enlace Dinámico

Colecciones de rutinas útiles que realizan funciones comunes pueden ser reunidas en Bibliotecas de Enlace Dinámico o Dynamic Link Libraries (DLL’s). Una DLL es simplemente una forma de módulo EXE sin un punto de entrada principal. Contiene partes de programas, pero no es por sí misma una aplicación. Las rutinas que están en una DLL son "exportadas" por sus nombres. Estas rutinas son agregadas a una tabla que permite a los otros programas llamar a la rutina y requerir su servicio.

En el ejemplo de la figura anterior, la DLL Funcion.dll tiene rutinas que realizan ciertas tareas. Una de ellas se llama FuncionX. Un programa separado llamado Programa.exe llamará a FuncionX. Funcion.dll tiene la rutina FuncionX y la exporta. Programa.exe llama a la rutina FuncionX y, por lo tanto, la importa.

Mientras DOS requiere que un servicio esté cargado antes que pueda ser utilizado por otro programa, Windows contiene la administración más sofisticada de memoria y programas necesaria para cargar módulos en demanda. Este es el por qué una DLL es Dinámica. En este ejemplo, cargar el programa Programa.exe provocará que Windows localice y cargue el módulo Funcion.dll al mismo tiempo. Si más de un programa utiliza rutinas de Funcion.dll, solamente una copia será cargada en memoria y ella será compartida. Cuando todas las aplicaciones terminan, Windows liberará el almacenamiento que Funcion.dll ocupó. Si se necesita nuevamente, una copia nueva puede cargarse en el disco.

Las herramientas de programación construyen dos tipos de módulos. Un programa o utilidad normal es un archivo EXE. Una biblioteca es un archivo DLL. Sin embargo, una vez que se construye un módulo de biblioteca se puede renombrarla como otro tipo de archivo y sigue siendo una biblioteca. Windows posee un número de categorías de DLL con calificadores especiales:

• EXE: Para hacerlo más confuso, Windows (en su versión 3.x) llama a sus tres módulos DLL’s más importantes (USER, GDI, y KRNL386) con la extensión EXE, que es normalmente utilizada por los programas. Ellas no son programas, son sólo DLL’s con un mal nombre.

• DRV: Durante la instalación de Windows, el usuario selecciona un tipo particular de teclado, mouse, monitor, e impresora. Las DLL’s que contienen el soporte para un tipo particular de dispositivo general usualmente tienen la extensión DRV. A este tipo de DLL se le conoce como driver o controlador. Durante el desarrollo del texto se utilizarán indistintamente los términos driver y controlador.

• VBX: Visual Basic Extension. Son controles personalizados de Visual Basic. Hoy en desuso.

• OCX: Son el remplazo de VBX, aunque su función es la misma que la anterior. Hoy en día se les llama Controles ActiveX.

Un ambiente genérico de Windows 3.1 tendría tres categorías de rutinas de DLL. Las tres bibliotecas claves que tienen los servicios de aplicación más importantes son los tres módulos, mal nombrados, EXE (USER, GDI, y KRNL). Windows luego tiene los drivers para el teclado, monitor, mouse. Los drivers de la tarjeta de sonido e impresora son opcionales.

La última categoría de módulos retiene el tipo de archivo DLL. Ellos residen usualmente en el directorio \WINDOWS\SYSTEM, aunque pueden estar en cualquier lugar del PATH. Proveen soporte para interfaces adicionales de programas. NETAPI provee rutinas asociadas con los servidores de red. OLE provee las convenciones de Microsoft para que los programas de aplicación cooperen editando documentos compuestos. ODBC es un soporte genérico para acceder a varias bases de datos. WINSOCK provee el acceso a Internet (Winsock no se muestra en la Figura 1-4).

Una DLL exporta rutinas que el programa de aplicación llama directamente. La rutina de la DLL corre como una extensión del programa de aplicación. En una CPU 386 o mejor, Windows corre en modo Mejorado, utilizando administración de memoria más avanzada para entregar algún aislamiento y protección contra errores de los programas. Esto provee una barrera lógica entre las aplicaciones y algún componente de Windows (como las DLLs), particularmente a aquellos que acceden a memoria en el nivel de hardware, esquivando la administración de memoria. Las funciones supervisoras de Windows por el otro lado de esta barrera pueden ser extendidas por un tipo de DLL llamado VxD o Driver de Dispositivo Virtual. Los VxD’s fueron originalmente diseñados para administrar dispositivos, pero también son utilizados para extender los servicios del sistema.

Eventos

Una aplicación llama a una rutina de una DLL para solicitar un servicio de Windows. Todas las aplicaciones Windows pueden también exportar una de sus propias subrutinas para administrar eventos.

Cualquier programa Windows es manejado por eventos. El evento puede ser el clic que el usuario hace con el mouse, o el presionar una tecla en el teclado, o el fin de algún período de tiempo. Cada programa Windows provee una rutina administradora de eventos para recibir y manejar tales eventos. Windows llama a la rutina de Administración de Evento de la misma forma en que una aplicación llama a una DLL de Windows para solicitar un servicio. En algunos lenguajes, el Administrador de Eventos es provisto por el lenguaje y el evento es traducido en una llamada a una rutina de Visual Basic o a un método de C++.

Debido a que las aplicaciones pueden estar interconectadas, y las ventanas aparecen dentro de ventanas, existen varias rutinas administradoras de eventos que podrían posiblemente recibir un mismo evento. La regla de Windows es comenzar con el administrador de eventos para la ventana "on top" o la que está por sobre todo el resto de ventanas, luego, el evento viaja hasta uno de los administradores que reconoce y acepta el evento.

Aunque Windows puede ejecutar varias aplicaciones a la vez, cada programa tiene una opción de ejecutarse cuando su rutina de manejo de eventos es llamada, y se detiene cuando retorna al sistema de Windows después de manejar el evento. Si esto toma mucho tiempo, el usuario ve un puntero con un reloj de arena como una indicación que la aplicación está ocupada. Un programa no puede realizar una operación larga y complicada sin apoderarse de la CPU y de la interfaz de usuario.

[Tecnho]

Buffers del Sistema

Windows 3.1 utiliza los servicios de la BIOS, DOS y los drivers de dispositivos de DOS. Cuando hay que realizar I/O a una red, Windows se convierte en una aplicación DOS ordinaria y realiza una solicitud estándar de servicio. Sin embargo, las reglas de DOS requieren que cualquier buffer de datos resida en el primer megabyte de la memoria. Por lo tanto, Windows asigna buffers en los primeros 640 KB de almacenamiento, y mueve datos entre los buffers de la aplicación en la memoria de Windows y el área de DOS, haciendo que una aplicación tome algo más de tiempo en su terminación.

SYSTEM.INI

Cualquier lanzamiento de Windows tiene solamente una copia de los módulos de USER, GDI y KRNL386. Existen muchos drivers de monitor, mouse y tarjetas de sonido. El acceso a la red puede ser provisto por Novell, NT, IBM, Banyan, u otros servicios. Los diferentes dispositivos o redes se soportan por diferentes módulos DLL.

Cuando Windows arranca, lee el archivo C:\WINDOWS\SYSTEM.INI. Este archivo contiene la configuración establecida durante la instalación o modificada subsecuentemente por Windows Setup o por el Panel de Control. Las sentencias en el archivo SYSTEM.INI le dicen a Windows qué módulos usar para una función específica del sistema.

Display.drv=s3flat.drv

Shell=progman.exe

Network.drv=

Language.dll=langeng.dll

Esta cita del SYSTEM.INI le dice a Windows que utilice un driver para el chip S3, cargar el Administrador de Programas (progman.exe) como shell para Windows. Dice que no hay soporte instalado para red, y hay un usuario que habla inglés, ya que el lenguaje es dado por langeng.dll (language english). Estos parámetros estándares son ampliamente entendidos y mantenidos por el programa SETUP y por la mayoría de las utilidades. Otros parámetros son agregados para soportar dispositivos no usuales, procesamiento especial, o aplicaciones avanzadas. No es poco razonable decir que SYSTEM.INI tiene la misma función para Windows que CONFIG.SYS tiene para DOS.

Los problemas vienen a SYSTEM.INI cuando Windows es "actualizado" a través de sus versiones. Debido a que algunas sentencias pueden ser agregadas a este archivo para soportar un adaptador de comunicaciones ISDN o un compilador del lenguaje ADA, no existe una actualización que pueda alguna vez identificar cada una de las sentencias en el archivo. Una actualización cambiará las sentencias estándares, como "display.drv=", que puede entender. Ignorará sentencias de la forma:

[386Enh]

DEVICE=MWAVE.386

DEVICE=VMWGames.386

Esta secuencia particular agrega un driver de dispositivo de hardware para uno de los módems o tarjetas de sonido Mwave de IBM. También agrega soporte de manera que algunos juegos DOS diseñados para una tarjeta SoundBlaster puedan correr en una tarjeta Mwave de IBM. Estos drivers funcionan en Windows 3.1 y no serán eliminados hasta que se actualice a Windows 95. Los drivers no funcionarán en el sistema avanzado y las sentencias deben ser eliminadas manualmente.

Cuando Windows es actualizado, la nueva versión puede alterar las anteriores sentencias del SYSTEM.INI que logra entender. Cuando encuentra una sentencia no reconocible por la actualización, generalmente la ignora. Quizás el extraño driver corra en el nuevo sistema. Si no, el usuario final tendrá que editar SYSTEM.INI y eliminar las sentencias manualmente.

Nuevas versiones del mismo código proveniente del mismo distribuidor actualizarán adecuadamente archivos de configuración anteriores. Sin embargo, los cambios que Microsoft hizo desde Windows 3.1 a Windows 3.11 o desde el viejo y plano Windows a Windows para Trabajo en Grupo tomó tiempo en que sea entendida. La versión original de OS/2 para Windows no se instalaría sobre 3.11 o WFWG, y tomó varios meses antes de que IBM produjera un parche para habilitar la instalación.

VxD en Windows 3.x

Un programa de aplicación se ve a sí mismo como una colección de segmentos. Esta realidad física en un 386, es que el programa ha sido particionado en páginas de 4 KB dispersas a través de almacenamiento extendido. Esto es importante para el sistema, debido a que las páginas son más fáciles de asignar, administrar, y controlar. Las tablas de asignación de memoria en la CPU ocultan la realidad de las páginas y permiten que al programa pensar que está ocupando una gran y contigua área de memoria.

Windows puede ser extendido al instalar nuevos módulos DLL. Una rutina DLL, sin embargo, es llamada directamente por un programa de aplicación y hereda el comportamiento del llamante. En particular, la DLL no está atenta a que, al igual que el programa, ha sido partida en pequeñas páginas de 4 KB. Esto no importa, porque los programas de Windows no dependen de una vista a nivel de hardware de la memoria.

Sin embargo, si un programa Windows administra un dispositivo de hardware, entonces, puede que necesite una vista precisa y física del sistema. Los dispositivos ordinarios reciben datos de uno o dos bytes a la vez del programa que se ejecuta en la CPU. Dispositivos de alto rendimiento (controladores de disco, adaptadores de LAN, y tarjetas de sonido por ejemplo) a menudo soportan DMA (Acceso Directo a Memoria) o soportan BusMaster donde el driver simplemente apunta a la ubicación del buffer del hardware y el dispositivo transfiere bytes como sea necesario hacia y desde la memoria. Para soportar DMA, el driver debe acceder a las tablas de administración de memoria para localizar las páginas regadas que forman parte de ese buffer. Una rutina que provee este soporte en Windows se llama VxD.

La fórmula más simple es decir que los VxD’s sirven para Windows la misma función que los drivers de dispositivos sirven para DOS, OS/2, o Unix. Una gran cantidad de tiempo administran tarjetas adaptadoras, discos, cronómetros, o puertos de comunicaciones. Ocasionalmente, extienden los servicios estándares del sistema con alguna función adicional que requiere acceso al hardware físico o a las tablas de administración de memoria. El VxD es el único componente de Windows que tiene acceso a una visión a nivel hardware del computador como la RAM y dispositivos de I/O que generan interrupciones y a una visión a nivel de aplicación como los segmentos, páginas, y una cola de eventos. El VxD puede mover datos entre los buffers de la aplicación y los buffers de memoria real. Puede convertir interrupciones de hardware en eventos.

La sección previa mostró sentencias que instalan al VxD MWWAVE.386 para el módem o tarjeta de audio Mwave. Tal tarjeta tendrá un chip de Procesador de Señal Digital, RAM, y un sistema operativo incorporado. Los programas son cargados en la tarjeta para reproducir sonido grabado, sintetizar música, o realizar las funciones de modem. El chip DSP (Digital Signal Processor) genera interrupciones, por defecto en la IRQ 15.

La mayoría de las tarjetas de sonido opera con alguna forma de DMA. Una aplicación Windows carga algún sonido grabado desde un archivo *.WAV en un buffer. Este luego pasa la dirección del buffer y su longitud a la lógica DMA de la tarjeta de sonido. La tarjeta reproduce el sonido en segundo plano, mientras Windows despliega información o fotos en la pantalla. Cuando el buffer se haya acabado, se genera una interrupción para permitir que el programa cambie de buffer. El programa de aplicación puede creer que está construyendo bufferes en segmentos de 64 KB, pero el hardware ve los datos regados en pedazos más pequeños de 4 KB. El VxD MWAVE.386 se encarga de los buffers fragmentados, administra el DMA, y maneja las interrupciones.

Una vez que los VxD’s fueron creados, los programadores encontraron que eran una útil manera de embaucar cualquier restricción de la arquitectura de Windows. Algunos programas de respaldo utilizan un VxD para maximizar el rendimiento. Visual C++ tiene un VxD para ayudar a su ambiente de desarrollo de programa.

Ha habido una tendencia general en Windows 3.x para expandir el número de rutinas VxD y la cantidad de los servicios Windows que proveen. Windows 3.11 contiene rutinas VxD para manejar el adaptador de red, protocolos de red, I/O de disco, y el sistema de archivos FAT.
**
Windows for Workgroups 3.11**

Windows 3.x utiliza los servicios de DOS, los drivers de dispositivo de DOS, y la BIOS para acceder a los archivos de disco y algún otro dispositivo de hardware. Debido a que DOS y BIOS solamente operan con bufferes por debajo del primer megabyte, esto usualmente involucra mover datos entre la memoria de Windows por sobre el primer megabyte y el área de 640 KB de DOS. Windows, entonces, tiene que retornar al modo de ejecución ordinario para hacer la llamada a DOS o a la BIOS utilizando la instrucción INT. Los resultados luego tienen que retornar al programa de aplicación que corre en la memoria de Windows.

Windows no utiliza los servicios de DOS para el monitor, mouse o teclado. Su uso de estos dispositivos es muy complicado como para ser soportado por un driver de DOS. Windows for Workgroup 3.11 da el próximo gran paso al mover la E/S de disco IDE y la mayoría del soporte de red lejos del ambiente de DOS y lo lleva al control de Windows. Windows 95 (Chicago) completará el proceso al mover la mayoría de la E/S restante (discos SCSI y soporte de CD-ROM) hacia Windows, eliminando la dependencia de los drivers de dispositivo de DOS.

Un programa de aplicación necesita leer un archivo de disco. Bajo Windows 3.1, el requerimiento sería pasado a DOS a través de la interfaz de la instrucción INT 21. Si el archivo estuviera en un disco duro local, DOS interpretaría la FAT, localizaría el directorio y luego al archivo, y leería los sectores de disco utilizando llamadas de BIOS. Si el archivo estuviera en la red, el requerimiento sería pasado a los drivers de dispositivos de DOS y a las rutinas residentes que representan el Redirector de Red Microsoft o de Red Novell. Ellos, a su vez, se van a la tarjeta adaptadora de red, y a través de la red, al archivo.

Cuando un requerimiento de archivo se procesa en Windows for Workgroup (WFWG) 3.11, el sistema chequea si el acceso a disco de 32 bits y si el soporte de disco está instalado. Tal soporte está disponible para la mayoría de las configuraciones de escritorios con discos duros IDE. Cuando éste es el caso, Windows contiene un driver que manipula el hardware de disco directamente sin utilizar DOS o la BIOS. En particular, Windows debe ser capaz de interpretar la estructura de directorio de la FAT, administrar al área de caché de disco, y traducir el requerimiento en valores de hardware tales como cilindros, pista y sector.

El soporte de disco de WFWG 3.11 reemplaza cualquier soporte provisto por DOS o la BIOS. En particular, cualquier almacenamiento asignado por SMARTDRV para el cache de disco es ignorado. Windows provee sus propios bufferes VCACHE. Por lo tanto, SMARTDRV no deberá usarse en sistema que ejecuten WFWG con soporte de archivo de 32 bits.

WFWG 3.11 incluye la capacidad de realizar E/S de disco asincrónica. En teoría, una aplicación puede comenzar un requerimiento de disco, e ir a realizar otro trabajo hasta que se complete. Sin embargo, ninguna aplicación utiliza esta interfaz, y no sería utilizada sino hasta que llegue Windows 95 con la posibilidad de realizar multihilos.

WFWG 3.11 también soporta drivers de LAN de 32 bits internos para las tarjetas de red LAN más populares y para algunos protocolos específicos de red. Si el usuario de la estación de trabajo se conecta a otro grupo de trabajo y servidor NT utilizando NetBIOS, o utiliza Internet a través de TCP/IP, entonces toda la actividad de red sobrepasará a DOS. Si se utiliza un servidor Novell, el soporte LAN será instalado en DOS como una rutina residente y WFGW seguirá el mismo camino plano que Windows 3.1

[Tecnho]

Windows 95

Cuando Microsoft anunció Windows 95 lo describió como un sistema operativo de 32 bits. En realidad, Windows 95 es un híbrido que mezcla código de 16 bits y código de 32 bits. Lo importante es que provee un ambiente en el cual pueden correr aplicaciones de 32 bits.

Cuando Windows 3.x corre en un 386, 486, o Pentium, algo de la administración de memoria y del soporte de E/S de disco corrían ya en 32 bits en Windows 3.11. A estos elementos se les llamó drivers de dispositivos virtuales o VxD. Inicialmente los módulos VxD eran utilizados para la administración de la memoria y para manejar unos pocos dispositivos como módems y tarjetas de sonido.

Windows 3.x utilizaba los servicios de DOS para otros dispositivos, como los discos duros, CD-ROMs, y tarjetas de red. Windows for Workgroup otorgó una opción para llevar el soporte de red (excepto para Novell) hacia VxD de 32 bits. El soporte de disco, al menos para los drivers estándar IDE, también pudo habilitarse a través de VxD de 32 bits.

¿Quién primero?

Un sistema WFWG comienza cargando un sistema real de DOS, incluyendo sus drivers de dispositivos. Luego WFWG arranca y carga sus VxD’s. Cuando se realiza una solicitud para un dispositivo sin soporte nativo de Windows, se pasa hacia DOS donde pueda ser procesado por un driver de dispositivo DOS.

Cuando Windows 95 arranca, el Administrador de la Máquina Virtual (VMM) de Windows se inicializa (un enfoque más detallado sobre VMM se encuentra en Parte II: Arquitectura de Windows) y carga los módulos VxD que antes eran drivers de dispositivos Windows. Existen drivers VxD para discos IDE y SCSI y para el sistema de archivos extendido VFAT (Virtual FAT). El soporte de red carga soporte para Windows NT y Novell. Debido a que este soporte corre como un VxD, éste puede cargarse por sobre el primer megabyte de memoria RAM. A pesar que los VxDs soportan aplicaciones Windows, también soportan programas de DOS que se ejecutan bajo control del VMM. Por lo tanto, el shell de comandos en Windows 95 (COMMAND.COM) tendrá acceso a características extendidas (como el nombre largo de archivos) que los drivers de DOS no soportarían.

Sin embargo, aún existen dispositivos ocasionales que sólo tienen drivers de dispositivos DOS. Windows 95 debe mantener la compatibilidad, para ello la VMM crea una "Máquina Virtual de DOS" (DVM). En esta DVM se cargan todos los drivers mencionados en el archivo CONFIG.SYS, y cualquier rutina residente mencionada en el archivo AUTOEXEC.BAT. Posteriormente, cuando Windows 95 recibe una solicitud para un dispositivo que no tenga soporte nativo VxD, utiliza un Proyector de Modo Real (RMM – Real Mode Mapper) para pasar el requerimiento hacia DOS donde los viejos drivers puedan procesarla (sincrónicamente y utilizando buffers en el área de 640KB).

Para más detalles sobre Windows 95, consultar Parte II Arquitectura de Windows, sección Arquitectura de Windows 95

Windows 98

Windows 98, el siguiente escalón en la familia de sistemas operativos Windows de escritorio. De cierta forma es la continuación que se podía esperar de Windows 95.

Como era obvio predecir, esta nueva versión continúa soportando 32 bits en su total dimensión aunque todavía se debe esperar para que se incorpore toda la funcionalidad de seguridad presente en los 32 bits y que hoy es una característica de la familia NT.

Desde el punto de vista del usuario común, Windows 98 no trae nada nuevo. Microsoft no ha hecho cambios relativamente importantes en la interfaz, por lo que, si un usuario sabe usar Windows 95, también sabe usar Windows 98. Se puede decir que la interfaz de Windows 98 es la interfaz que deja Internet Explorer 4.0 cuando se le instala en Windows 95 con la opción "Actualización de Escritorio", que es una versión mejorada de la interfaz nativa de Windows 95.

Así como para un usuario común, Windows 98 será familiar, para un programador Windows también, hasta que abra el velo que cubre a Windows 98 y descubra lo que hay en esta nueva versión de Windows:

• Modelo de Driver Win32 (Win32 Driver Model o WDM).

• Soporte para Múltiples Monitores.

• Tecnología de administración de poder OnNow.

• Soporte para USB.

Cavando Más a Allá de la Superficie

Con Windows 98, no hay que preocuparse por la compatibilidad que tengan las aplicaciones escritas para sistemas operativos Windows anteriores a Windows 98. Todas las aplicaciones escritas para Windows 95 correrán en Windows 98 pero, si se mira más de cerca a este nuevo sistema operativo, se pueden encontrar nuevas características que las aplicaciones pueden tomar.

Una de las cosas que los programadores adorarán de Windows 98 y de Windows NT 5.0 (que se encuentra en una fase Beta al momento de escribir este texto), es el soporte de Win32 Driver Model, abreviado WDM, que consiste en un modelo de drivers únicos que permite a los desarolladores escribir un único driver que corra en Windows 98 y en Windows NT. Para que esto se haga realidad Microsoft copia servicios del Kernel de NT a Windows 98 vía un driver de dispositivo virtual que en la práctica es un archivo llamado NTkern.VXD. Este nuevo método permitirá que Windows 98 maneje los mismos drivers de NT y el mismo método mantiene soporte para las tarjetas existentes.

Para más detalles sobre Windows 98, consultar Parte II Arquitectura de Windows, sección Arquitectura de Windows 98.

Windows NT 3.51 y 4.0

DOS fue escrito en 1980 para la familia de procesadores Intel 8086. En 1985 IBM y Microsoft realizaron un acuerdo para desarrollar un nuevo sistema operativo para el chip de CPU 286. La versión 1.0 de OS/2 no fue lanzada sino hasta 1988, y por entonces el 386 se estaba haciendo popular. Se hizo claro que el hardware estaba cambiando muy rápido con relación al desarrollo de software. De manera que en 1988 decidieron hacerlo de nuevo, IBM y Microsoft decidieron comenzar a trabajar simultáneamente en dos productos.

OS/2 versión 2 sería un refinamiento evolutivo de sistemas previos, actualizado para las nuevas características de hardware del 386. Continuaría el soporte a las aplicaciones y a los drivers de dispositivos desarrollados para el sistema previo. Esto se convirtió en el IBM OS/2.

OS/2 versión 3 se basaría sobre Nueva Tecnología. Este sería escrito desde cero y se desarrollaría un sistema basado sobre los mejores principios de ingeniería de software. En un principio sería para CPUs Intel, pero sería portable a otros chips de CPU. Esto se convirtió en Windows NT.

Microkernel

Unix rápidamente se fragmentó en "sectas". Los programas escritos por BSD no corren en UNIX SVR4. Así, hay UNIX SunOS, AIX, Ultrix, OSF, Linux, NextStep, USL, y una docena más. Todos los sistemas UNIX comparten un conjunto común de servicios, pero cada uno tiene características únicas que producen dependencias de los programas.

El Microkernel era una idea desarrollada para reunir a la comunidad UNIX. Un conjunto rico de servicios del sistema operativo (libre de toda idiosincrasia) que está contenido en un pequeño y puro kernel del sistema. Los programas de aplicación no acceden a los servicios del kernel directamente. En cambio, realizan las solicitudes a través de subsistemas programados para duplicar la personalidad de un sistema UNIX particular.

Los desarrolladores del microkernel de UNIX, dicen que el microkernel de NT es muy grande como para ser un microkernel. Sin embargo, NT no soporta "personalidades". Las nuevas aplicaciones Windows 32 bits corren bajo el control del subsistema Win32. Existe un estándar subsistema POSIX con capacidades limitadas y una emulación poderosa de UNIX.

Para más detalles sobre Windows NT, consultar Parte II Arquitectura de Windows, sección Arquitectura de Windows NT 4.0.
**
Windows 2000 (NT 5.0)**

Al momento de escribir estas líneas Windows NT 5.0 se encuentra aún en etapa de desarrollo y Microsoft ha anunciado un cambio de nomenclatura para su sistema NT. Así, Windows NT 5.0 se pasa a llamar Windows 2000.

Hasta la versión 4.0 Windows NT se comercializaba en tres versiones: Workstation, Server, y Advanced Server. Desde Windows 2000, también se pierde la nomenclatura Workstation y Server, siendo la siguiente:

• Windows 2000 Professional anteriormente NT Workstation.
• Windows 2000 Server anteriormente NT Server.
• Windows 2000 Advanced Server anteriormente NT Advanced Server.
• Windows 2000 Datacenter Server. Producto nuevo y que es el nuevo y más poderoso sistema operativo de Microsoft con posibilidad de hasta 16 procesadores simétricos y 64 GB de memoria física.

Actualmente existe la versión Beta 2, a la que lamentablemente aún no tiene acceso el público y sólo se distribuye entre grandes empresas con el fin que sea evaluado. Dentro de las características nuevas que incluye, se pueden citar:

• Real soporte para Plug and Play.

• Servicios de Directorio

• Mayor integración con Internet e Intranet.

En la Parte II Arquitectura de Windows se verá un poco más a fondo la estructura de Windows NT 5.0. Sin embargo, se hace notar que esta información entregada sobre Windows NT 5.0 puede estar susceptible a cambios ya que como se dijo recién, esta nueva versión del poderoso sistema operativo de Microsoft se encuentra aún en una versión Beta y la arquitectura final puede ser diferente a la arquitectura de esta versión de evaluación, que está en manos de 250.000 analizadores por el mundo según fuentes de la propia Microsoft, que además estima que Windows NT 5.0 se comenzará a comercializar en 1999.

Windows CE

Microsoft Windows CE es una plataforma de sistema operativo para un amplio rango de dispositivos computacionales móviles. La plataforma Windows CE hará posible que nuevas categorías de dispositivos que no sean PCs puedan comunicarse unos con otros, compartir información almacenada en PCs basados en Windows, y conectarse a Internet. Los primeros productos basados en Windows CE, los Handheld PCs (PC de bolsillo), comenzaron a embarcarse dentro de Estados Unidos en Noviembre de 1996.

Windows CE es un sistema operativo nuevo, compacto y portable, construido desde las bases para posibilitar el desarrollo de un gran número de dispositivos comerciales y hogareños, incluyendo Pcs de Bolsillo (Handheld PC), "wallet PC", dispositivos inalámbricos tales como teléfonos celulares inteligentes, y la próxima generación de consolas de video juego incluyendo reproductores de DVD.

El sistema operativo Windows CE es un sistema de 32 bits, multitarea y multihilado que tiene una arquitectura abierta, otorgando un soporte a una variedad de dispositivos.

Windows CE hace posible que se generen nuevas categorías de productos que pueden "hablar" unos con otros, compartir e intercambiar información con PCs basados en Windows, y comunicarse con una amplia variedad de sistemas empresariales o con Internet para el acceso al correo electrónico y a la World Wide Web.

Como ya se ha dicho antes, Windows CE es compacto, ofreciendo alto rendimiento en configuraciones limitadas de memoria; escalable, ya que soporta un rango de productos multimedia y que son móviles; portable, ya que posibilita a los fabricantes que opten por un microprocesador en particular; y tiene una administración de poder incorporado.

Para más detalles sobre Windows CE, consultar Parte II Arquitectura de Windows, sección Arquitectura de Windows CE.

[Tecnho]

Bueno he recopilado información para el que no sepa de donde vienen los tiros de pc y windows que sepa algo se que es muy largo pero bueno si teneis un rato de esos de aburrimiento aqui teneis buena lectura que puede ser de interes.

Saludos.

[cobito]

El hilo tiene buena pinta, pero ahora no tengo tiempo de leerlo. Cuando termine de exámenes las semana que viene lo leeré.

Por cierto, hace tiempo hice un hilo con imágenes de casi todas las versiones de Windows que han salido. Las imágenes las capturé yo y tienen el copyleft de Hardlimit, así que si quieres puedes usarlas para completar tanto este hilo como el el otro que has creado sobre Windows.

[Tecnho]

valla pues no lo habia visto tio he hecho dos, ya puedes perdonar.