Comparando Windows 95, 98 y 2000

1. Opciones mejoradas 2. El explorador de Windows 3. Herramienta de búsqueda 4. Propiedades de Pantalla 5. Win98 6. Como funciona win95 / 98 por dentro 7. Ventaja que tiene windows 95 y windows 98 8. Como se trabaja..10. Accesorios multimedia. 11. Multimedia y el panel de control. 12. Memoria Windows

1. Opciones mejoradas Algunas de las herramientas más populares en Windows, como puede ser el caso del "Agregar y quitar programas" han sufrido una profunda y útil reestructuración no ya de imagen, sino también de funciones.

En concreto esta característica nos sigue permitiendo:

• Desinstalar programas
• Gestionar los componentes de Windows NT
• Instalar nuevos programas

Ahora bien el asistente nos ofrece más información de los programas como la posibilidad de ordenar los programas instalados según la frecuencia de uso; algo interesante a la hora de desinstalar programas en determinados entornos.

 Otro de los cambios más llamativos atañe a los cuadros de diálogo para abrir o guardar documentos que han sido totalmente rediseñados. Ahora, al "estilo Outlook", tenemos en la parte izquierda una barra que contiene verticalmente los iconos de Recientes, Mis Documentos, Escritorio, Favoritos, y Entorno de Red para permitir el acceso a los lugares más habituales. Si hemos de buscar en otra localización lo tendremos que hacer por el método tradicional. Conviene apuntar que este procedimiento de trabajo estará presente también en la próxima versión de Office, Office 2000.

Asimismo se han renovado el aspecto de todos los asistentes y en algunos casos como el de hardware son totalmente nuevos. En este caso la función de este asistente se ha ampliado siendo cuádruple en lugar de limitarse a monitorizar o guiar al usuario en la instalación de un dispositivo (que también lo hace). El nuevo asistente permite:

• Ver las propiedades de un elemento de hardware
• Soluciónar problemas relativos al hardware tales como conflictos con las interrupciones, etc.
• Desconectar o soltar un dispositivo en caliente tal como la controladora del disquete o una tarjeta PCMCIA.
• Instalar un elemento de hardware.
• Reparar la instalación de un elemento de hardware

En el aspecto de interfaz Windows NT beta3 se nos ha presentado como una auténtica revolución (agradable en general, y a veces espectacular). Poco a poco iremos viendo otras novedades más técnicas como el aspecto de la gestión de servicios y dispositivos, y lo que atañe a las nuevas herrramientas de administración.

2. El explorador de Windows

Una de los accesorios más importante de todos los sistemas operativos de Microsoft se ve mejorado hasta limites insospechados. Primero, siendo bastante más veloz que los predecesores. Desde el actual explorador de Windows se puede acceder al historial de Explorer con un simple clic, buscar archivos con la nueva utilidad de búsqueda y se añade un nuevo icono llamado carpetas con el que se puede acceder fácilmente a cualquier carpeta del disco duro o del web, pero quizás una de las opciones mas novedosas e importantes es la inclusión en el menú ver de la opción thumbnails (los internautas sabréis de que va) mediante la cual se pueden ver en vez del icono del tipo de archivo gráfico el archivo en si, y una ampliación de la vista de detalles donde se pueden seleccionar las columnas con los detalles que se quieren ver de cada carpeta. Así como siempre tendremos 3 links en la parte izquierda del explorador, el de mi pc, el entorno de red y mis documentos. También se puede personalizar los iconos que se quieren ver en la barra de herramientas como si del mismo IE se tratase, y en el menú de herramientas accedemos a las opciones de carpeta, donde, al igual que en sus predecesores, podemos cambiar el modo de ver los archivos, activar o desactivar el ActiveDesktop, utilizar un clic o dos y la pestaña tipos de archivo, que se mejora en esta versión haciendo mucho mas sencillo asociar tipos de archivos con sus programas de ejecución. A la carpeta mis documentos se le añade un subdirectorio llamado mis dibujos en el cual vemos por defecto el tipo de vista thumbnail, con una imagen de ejemplo la cual, en la parte izquierda del explorador podemos ampliar, reducir, imprimir o ver a tamaño real sin tener que entrar en ningún otro programa de edición gráfica, así como también nos da información extensa acerca del archivo (tamaño de pixels, atributos, fecha de creación, dueño, etc.). También se añaden dos iconos, el mover a y el copiar a donde el usuario (previa selección de archivos o carpetas) puede decidir donde quiere moverlas/copiarlas con un par de clic´s (muy similar a la powertoy Sendto any folder).

3. Herramienta de búsqueda

Otra de las herramientas en las que Microsoft ha echado el resto. Ahora no sólo es una simple herramienta para buscar archivos sino que se erige como uno de los pilares del uso diario del ordenador. Apoyándose en una ventana del IE, podemos buscar archivos por su nombre, por el contenido del texto u otro tipo de búsquedas sin movernos como son las de otros ordenadores o cosas en Internet. Mediante una persiana podemos decidir donde queremos buscar nuestro documento y podemos acceder a un link donde se abre un recuadro donde podemos seleccionar las opciones tales como la fecha, el tipo, el tamaño y otras avanzadas. Una vez encontrados los posibles documentos, que aparecen en una lista, si seleccionamos uno, vemos un preview, las propiedades del archivo y si accedemos al menú contextual a parte de las opciones que aparecen en versiones anteriores del SO aparecen siempre la de Abrir con, y una nueva que viene a abrir la carpeta que contiene dicho archivo. Hemos de recordar que la implantación que esta realizando Microsoft para unificar tareas en la misma herramienta lleva a que en la misma ventana podamos navegar por el disco duro, por Internet, buscar archivos, ver el historial y muchas mas cosas en la misma ventana del explorador, y aunque al principio se hace extraño, uno tarda poco en acostumbrarse a en cualquier ventana pulsar el icono buscar sin tener que ir al menú de inicio para poder buscar cualquier cosa en cualquier sitio o de utilizar un explorador para navegar por Internet/disco duro.

4. Propiedades de Pantalla

La herramienta de propiedades de pantalla se presenta mas cercana a la de W98 que a la de NT, podemos elegir como siempre la imagen de fondo, activar SalvaPantallas, opciones de ahorro de energía (mencionar que esta versión de NT soporta APCI y que puede desactivar discos duros, apagar monitores o el ordenador en si esperando una respuesta de módem, ratón o teclado para volver a funcionar, estados de hibernación, etc). De las opciones son las mismas que en W98 salvo algunos matices (se puede elegir el tipo de transición de los menús, entre el clásico de Windows de persiana y el nuevo de fade que es mucho más estético), también que se oculten los métodos abreviados de teclado hasta que se pulse la tecla Alt, y la pestaña de Ajustes, que es mucho mas profesional que en versiones anteriores y que permite exprimir al máximo las posibilidades de la tarjeta de video, con opciones tales como elegir la frecuencia de refresco, el monitor y aceleraciones de hardware, como también los ajustes de color y diferentes temas para las ventanas

5. Win98

Características.

6. Como funciona win95 / 98 por dentro

Núcleo de Windows 95/98 Sincronización Interna de procesos

El subsistema de Windows de 16 bits (de Windows 3.1) no se diseño en principio para tratar con la posibilidad de expulsión de procesos. En consecuencia existen muchos lugares en los módulos de 16 bits (GDI, Usuario y Kernel) en donde el sistema fallará si se permite que una hebra (thread) de ejecución, ejecute código "reentrante" concurrentemente con otra. Cada sistema operativo, tiene que tratar este problema Windows NT lo gestiona mediante el bloqueo de las hebras que intentan acceder al mismo objeto en momentos críticos. UNIX y OS/2 contienen secciones de código que bloquean cada hebra, pero solo durante una sección critica. Windows 95 / 98 requiere soporte para la multitarea con derecho preferente de las aplicaciones Win32.

Puesto que muchas funciones (API) de 32 bits llaman al código de 16 bits, se plantea el dilema de como tratar el asunto de derecho preferente. Para soluciónar existen varias posibilidades:

* Desarrollar un nuevo subsistema para dar soporte a las aplicaciones de 16bits.

• Utilizar el subsistema de Windows NT (en particular el GDI).

  * Adoptar un enfoque similar al del OS/2 en el que cada aplicación Windows de 16 bits, se ejecuta en una maquina virtual separada. Similar al modo Virtual 8086 del procesador para el soporte Ms-DOS.

  * Utilizar uno o mas "semáforos" del sistema para asegurar que no se puede ejecutar mas de una hebra a la vez dentro del subsistema de 16 bits.

  * Revisar el código antiguo para aplicar la exclusión mutua a recursos del sistema dentro de las secciones criticas apropiadas del subsistema de 16 bits (una tecnica de diseño, llamada "serialización del núcleo").

  Evidentemente la decisión de cómo plantear esto, no es fácil Hay que ver aspectos diversos como compatibilidad, rendimientos, lapsos, esfuerzo de implementación y valor a largo plazo. El problema de la "reentrada" el enfoque se puede reducir a una cuestión de código nuevo, arquitectura nueva o protección del código viejo. Veamos algunos compromisos específicos a tener encuentra antes de tomar una decisión:

  * La naturaleza sin derecho preferente de Windows 3.1 y sus predecesores había significado que algunas aplicaciones dependían por desgracia del orden y la temporización de ciertos mensajes del sistema. Dar preferencia a una de estas aplicaciones en un momento inadecuado podría hacer que el programa fallara. Romper las restricciones de compatibilidad no se podía entonces considerar como opción.

  * Las "retrollamadas" registradas de las aplicaciones constituyen otro aspecto complicado de compatibilidad. Si se utilizase un sistema de semáforos, el procedimiento para establecer correctamente los indicadores apropiados durante una retrollamada a una aplicación de 16 bits podría ser difiil de desarrollar. Este es un problema que sí se puede solventar, pero la solución debe implicar excesivas pruebas.

  * Rescribir por completo los subsistemas de GDI, Usuario y Kernel como código de 32 bites supone un incremento de la memoria requerida para la carga de trabajo del sistema. Los módulos Usuario y GDI requieren solo unos 800 Kbs. La conversión de este código a 32 bits habrían subido los requisitos de memoria en aproximadamente un 40% y habría incrementado entones por encima del mega los requerimientos del GDI. Dado que por desgracia al diseñarse Windows 95, se pensaba que era necesario que se pudiese ejecutar en un ordenador con una memoria de 4 megas (posteriormente se incrementó este requisito), en aquel momento se pensó que esto no era aceptable. Craso error que todavía estamos pagando, ahora en Windows 98 por compatibilidad con win 95, pero en aquella epoca de diseño (año 93-94) era casi impensable un PC con un minimo de 16 megas.

  * Utilizar el subsistema de Windows NT parecía atractivo, pero podría haber requerido demasiad trabajo de adaptcaion para la arquitectura de Windows 95 y mucha mas memoria para ejecutarlo (El codigo de NT, está escrito en C++. mientras que el de win95 / 98, está en C y ensamblador).

* Un problema parecido podría haberse planteado al adoptar la solución de multiples maquinas virtuales utilizada por el OS/2 – se habría necesitado mas memoria en el sistema anfitrion. La solución de OS/2 falla al tratar algunos asuntos criticos de compatibilidad y esto no creo que pueda ignorarse.

Parece entonces que la decisión debe estar clara debido a esto nuevos enfoques. El problema se reduce ahora a descubir como introducir la proteccion (por medio de la exclusion mutua) en el subsistema win 16. El nuevo codigo de 32 bits diseñado para el subsistema Win32, simplemente no tenia este problema. Desde el principio se puede diseñar para dar soporte a un entorno multihebra. Cada una de las posibles soluciónes para la proteccion del viejo codigo hacia concesiones en el tiempo de implementacion frente al impacto global:

* Un solo semáforo que protegiese al subsistema Win16 contra la reentrada podría haber sido la solución mas facil Habría sido rapido de implementar y facil de probar y no habría asociado problemas de compatibilidad. Sin embargo bajo ciertas condiciones podría haber tenido un gran efecto negativo en el rendimiento de la multitarea del sistema.

* Multiples semáforos que guardasen grupos relacionados de funciones Win16 podrian reducir los aspectos adversos de un unico semáforo en las prestaciones de la multitarea. Pero sopesando los beneficions frente al esfuerzo de implementacion y fundamentalmente de prueba este diseño empieza a flaquear como solución convincente. La utilizacion de multiples semáforos para reducir la granularidad de una seccion critica, habría impuesto una sobrecarga de implementacion. En alguna medida se podia incrementar el 10% en la ejecucion de cada API. De nuevo es algo inaceptable proporcionar al usuario un nuevo sistema que sabemos que va a ser desde el principio mas lento de li que era Windows 3.1

* Tambien puede existir una solución intermedia entre el enfoque de un unico semáforo y el de multiples. En esta solución se puede utilizar dos semáforos. Uno para aplicaciones Win16 y otro para los mosulos GDI y Usuraio de 16 bits. Esta disposicion habría permitido llamadas desde codigo de 32 bits al GDI y Usuario de 16 bits siempre que una aplicacion Win16 hiciera algo más. Desafortunadamente esta solución implica una modificacion de unos 100 puntos de entrada dentro de Windows, ademas de requerir la modificacion de las DLLs del sistema y de muchos controladores de dispositivos. Las restricciones de compatibilidad, tambien descalifican esta solución.

* Serializar el subsistema Win16 habría sido la solución mas efectiva. Los recursos compartidos se habrían bloqueado solo brevemente y con ello se minimiza el impacto de rendimiento de la multitarea del sistema. Desafortunadamente las estimaciuones para la implementacion son muy costosas. Si se deicdiese esta solución es casi imposible estimar con precision la escala de tiempos en que se hubiese podido terminar todo el trabajo. Esto condiciona el lanzar un producto en un margen de tiempo fiable.

** Por tanto, la decisión parece clara. Se adoptó la solución de un semáforo unico para Windows 95 (y heredado para Windows 98). El semáforo que protege al subsistema Win16 contra la reentrada se denomina "Win16Mutex". Este semáforo establece siempre que el planificador cede el proceso a cualquier hebra de 16 bits. El establecieminto del semáforo tiene diversas implicaciones:

* Las hebras de la aplicaicon Win32 establecen e inicializan e semáforo cuando pasan por la capa de ajuste entre 16 y 32 (twunk). Una hebra Win32 concurrente bloquea este semáforo mientras otra hebra ejecuta el codigo de 16 bits.

* Una hebra Win32 que no se ajusta al subsistema Win16 nunca puede bloquear Win16Mutex.

* Siempre que el planificador cede el control a una hebra Win16 establece el semáforo. Win16Mutex permanece establecido hasta que la hebra Win16 cede el control.

* El comportamiento de una aplicacion Windows de 16 bits será exactamente igual a su comportamiento en Windows 3.1. Sin derecho preferente y sin cambios en el orden de los mensajes, en la temporizacion o en cualquier otra operación dependiente del sistema.

** Las operaciónes de Win16Mutex justifican una mayor explicacion ya que esta solución tambien tiene desventajas. Establecer Win16Mutex evita que una hebra Win32 entre en el subsistema Win16 sin que esté activa una hebra Win16. Win16Mutex se ha de establecer porque no hay componentes WIn16 reentrantes, como por ejemplo la libreria de dialogos comunes (COMMDLG) que una aplicacion Win16 llama directamente en vez de hacerlo a traves de una entrada al subsistema Win16. Establecer y eliminar Win16Mutex cuando una hebra Win16 entra al sistema no afecta en este caso, por lo que el semáforo tiene que permanecer establecido siempre que una hebra Win16 esté activa. En una operación normal con aplicaciones de 16 bits que funcionan bien (es decir con aplicaciones que regularmente ceden el control cuando deben), los efectos en la multitarea del sistema son minimos. En el peor de los casos, habría un breve retardo cuando se vuelva a dibujar una ventana para una aplicacion Win32. ("brve" indica que está en el orden de microsegundos). Si una apliacion de 16 bits, realmente queda suspendida el sistema se parará gradualmente cuando las hebras Win32 bloqueen Win16Mutex. Cuando el usuario pulsa Ctrl+Alt+Del para abandonar la aplicacion que ha fallado, el sistema reinicializará Win16Mutex como parte de su procedimiento de limpieza y todo seguirá (debería) normalmente. Si una aplicacion de 16 bits, realmente falla -por ejemplo por un fallo de proteccion general- entonces otra vez se inicializará Win16Mutex durante el proceso de limpieza. El semáforo Win16Mutex no es la solución perfecta, no hay duda, pero es la mejor solución que Microsoft podia utilizar para el problema mas obvio causado por las restricciones de compatibilidad de Windows 95.

A la vista de todo lo anterior, se puede argumentar tranquilamente que los diseñadores de Windows 95, eligieron, para su época, la solución correcta. Ignorar las restricciones de compatibilidad habría sido la peor decisión que pudiese haberse tomado. Windows 95/98 ofrece un mecanismo de planificación que es claramente mejor que el de Windows 3.1. Las aplicaciones existentes de 16 bits se deben ejecutar tan bien o mejor que nunca y las aplicaciones Win32 dispondrán completamente de la planificación con derecho preferente y en el uso diario, la combinación de los dos no debería tener un impacto importante en el rendimiento.

* Los componentes del núcleo de 32 y de 16 bits son independientes, por lo que una hebra Win32 que pide una operación potencialmente grande como una E/S a un archivo de disco, no tendrá que llamar al codigo de 16 bits.

* Las llamadas al modulo GDI y Usuario que tienen que tratar de arrebatar al semáforo Win16Mutex son predominantemente las que tienen tiempos de ejecución muy cortos, por lo que las hebras Win32 necesitarán tomar posesión del semáforo tan solo brevemente. Esto significa que las hebras Win32 aisladas rara vez competirán por el semáforo.

* Tanto la "interfaz" de ordenes como el administrador de colas de impresion son aplicaciones 32 bits, por lo que los componentes mas utilizados eludiran el problema.

** Las posibles desventajas de esta solución cuando el usuario ejecuta nezclas de aplicaciones de 16 y 32 bits fueron otro incentivo para los desarrolladores de aplicaciones para centrar sus esfuerzos en las aplicaciones Win32. Algo que no debemos olvidar, si lo que realmente se requiere es un sistema que garantice el derecho preferente tanto con aplicaciones de 16 como de 32 bits, es que Windows NT (y el próximo Windows 2000) es el producto que se debería elegir.