jueves, 27 de marzo de 2008

HACER UN ARCHIVO BACH (BAT)

Muchas veces necesitamos hacer una tarea muy repetitiva, o programar una tarea cada determinado tiempo (por ejemplo cuando se enciende el PC). Muchas de estas tareas se ejecutan desde la consola y resulta un poco molesto o aburridor estar digitando esa serie de ordenes para cumplir esta tarea, es por esta y otras razones que uno recurre a los famosos Scripts con los cuales podemos lograr grandes cosas en Linux por ejemplo. En Windows es posible lograrlo también a través de los archivos .bat, que son archivos de texto y sin formato que se ejecutan de manera secuencial línea por línea a través del intérprete de comandos de MS-DOS y/o Windows. A estos archivos recurro muchas veces cuando tengo que digitar muchas ordenes en la consola y me da pereza, ya que con un par de clics puedo hacerlas.

Para hacer una idea de lo que podemos hacer voy a citar un ejemplo de la utilidad de un archivo bat, por ejemplo si necesitamos cheuqear determinados puertos clave en un PC que hace las veces de servidor podriamos invetarnos este código:
Y agregar el archivo al inicio de Windows y asi cada vez que se enciende ese PC podremos saber si estos puertos estan abiertos o no. Ahora bien vamos a ver los comandos necesarios para defendernos a la hora de crear un script en bat, aunque cualquier comando que funcione en la Consola/Símbolo del sistema se puede incluir en un bat, pára mi caso usé netcat.

Voy a tirarme un rápido manual de como hacer archivos bat, batch o archivos por lotes de MS-DOS. Si alguna vez a programado algo en cualquier lenguaje me entenderán como les voy a hablar ;)

Mostrar información en la pantalla
Para mostrar información por pantalla simplemente es necesario usar el comando ECHO, teniendo en cuenta su sintáxis:
ECHO Muestra el estado de ECHO.
ECHO ON Activa el eco de las ordenes.
ECHO OFF Desactiva el eco de las ordenes.
ECHO mensaje Muestra un mensaje por pantalla.
ECHO. Muestra una línea en blanco por pantalla.
Para que en pantalla no salga el prompt del sistema cada vez que se ejecuta una línea de nuestro archivo , es decir algo asi como C:\>WINDOWS por ejemplo, debemos desactivar el eco de las ordenes colocando como primera línea del archivo la orden @ECHO OFF.

Agregando comentarios al código
Al programar es muy util poner comentarios para recordar que función cumple una línea o para servir de referencia a otro programador, para agregar un comentario a un código solo basta usar el comando REM seguido del comentario, o con dos veces 2 puntos o con signos porcentaje:
REM [comentario]

::[comentario]

% comentario %

Ejecutando a otro batch
Podemos llamar a ejecución un archivo bat desde otro, es decir que el uno puede servir de auxiliar del otro por decirlo de alguna manera. para esto usamos el comando CALL:
CALL [archivo.bat]
Una vez un archivo ejecute una llamada con CALL queda en ejecución y le da paso al segundo, una vez este termina de ejecutarse, el archivo principal retoma sui ejecución.

Ejecutando lotes
Los bat se conocen como los archivos por lotes de MS-DOS, y es porque permiten crear pequeños bloques de código (algo asi como lo que llamamos procedimientos en otros lenguajes de programación) entre los cuales podemos ir saltando. Para crear un bloque de código debemos marcarlo con una etiqueta que se define con 2 puntos seguidos del nombre, así por ejemplo:
:opcion1
ECHO Selecciono la opcion 1
GOTO end
Y para ir a otro bloque usamos la instrucción GOTO como vemos en el ejemplo, GOTO brinca a la etiqueta especificada, por ejemplo en el código anterior brincaría a la etiqueta :end. Un ejemplo más claro:
@ECHO OFF
GOTO :opcion1

:opcion1
ECHO Selecciono la opcion 1
GOTO end

:opcion2
ECHO Selecciono la opcion 2
GOTO end

:end

Vemos que :end es una etiqueta por decirlo asi muerta ya que no maneja, asi que al llegar a ella significa terminar la ejecución del código (recordemos que los bat son secuenciales); así que esta es una buena de terminar un programita ;). Por último, los nombres de las etiquetas deben ser de máximo 8 caracteres, por aquello del formato de MS-DOS que los nombres de archivos son 8+3 (nombre + extensión).


Condiciones
Para hacer programas intersantes es necesrio implementar o evaluar condiciones, asi que este pequeño lenguaje bat no le podia faltar la instrucción IF. Con IF podemos lograr muchas cosas:
IF EXIST [archivo] [comando]

Si existe el archivo determinado se ejecuta el comando indicado. para lograr lo contrario, es decir evaluar si no existe el archivo, se ejcuta asi:

IF NOT EXIST [archivo] [comando]

También podemos evaluar si se cumple una condición:
IF cadena1==cadena2 [comando]

Y hacer lo contrario:
IF NOT cadena1==cadena2 [comando]

Algunos comandos arrojan un numero de salida segun la forma en que fueron terminados, por ejemplo el programa X arroja el código cero (0) al cerrarse normalmente, entonces podriamos evaluar esa salida asi:
IF ERRORLEVEL [número] [comando]
Para entender un mejor esto veamos este otro comando.

Seleccionando opciones
Con los bat también podemos listar una serie de opciones y en base a la selección ejecutar un comando, para ellos usamos el comando CHOICE, este no esta en Windows XP pero lo podemos bajar de aqui y copiarlo en la carpeta C:\WINDOWS\System32. Para conocer la sintáxis de CHOCIE lo mejor es ejecutar CHOICE /? y aqui un ejemplo:
echo Rojo
echo Gris
echo Blanco
choice Escoja un color?? /c:rgb /t:i,10
if errorlevel 3 goto rojo
if errorlevel 2 goto gris
if errorlevel 1 goto blanco

:rojo
echo Escojió rojo
goto out

:gris
echoEscojió gris
goto out

:blanco
echo Escojió blanco

Variables
Las variables podemos introducirlas a un bat como parametros al momento de ejcutarlos, un parametro va antecedido de un signo porcentaje seguido de su posición comenzando a contar desde cero. Por ejemplo el código:

ECHO El parámetro uno es %0
ECHO El parámetro dos es %1
ECHO El parámetro tres es %2
Si lo ejecutamos asi:
C:\WINDOWS\> archivo.bat gato perro ave
En pantalla saldría:
ECHO El parámetro uno es perro
ECHO El parámetro dos es gato
ECHO El parámetro tres es ave
Ahora bien solo basta con dejar volar la creatividad y usar los parámetros, un parametro puede ser un archivo por ejemplo.

Ejecutando ciclos
Con FOR podemos ejecutar un comando a un conjunto de archivos o viceversa, o ejecutar un comando varias veces por ejemplo:
FOR IN ( num de veces ) DO
Asi por ejemplo este código:
for %%i in (1 2 3) do echo Mensaje %%i
Las variables en el for están antecedidas por %%. Sin embargo no necesariamente se debe contra desde 1 hasta n, por ejemplo:
for %%i in (2 4 6) do echo Número %%i
Por pantalla se verá:
Número 2
Número 4
Número 6
En incluso se puede aplicar a letras o palabras:
for %%i in ( a b c) do echo Letra %%i
Por pantalla se verá:
Letra a
Letra b
Letra c
Tambíen podemos aplicar un grupo de comandos a un archivo:
for %%i in (type del) do %%i ejem.txt
Este ejemplo muestra por pantalla y luego elimina a ejem.txt


Pausando la ejecución
Para detener por un momento la ejecución de un programa ejecutamos PAUSE, este suspenderá la ejecución de un programa batch hasta que se pulse una tecla para continuar. Al ejecutarse el comando PAUSE se visualiza por pantalla el mensaje:

Presione una tecla para continuar . . .

En caso de no querer mostrar este mensaje por pantalla utilizamos el comando PAUSE de esta manera:

PAUSE > NUL

NUL es un dispositivo nulo o muerto, asi que al enviar la salida de la pantalla a este no se verá nada.


Ya por último...
Con estos comando podemos defendernos, ademá de los que corran en la consola como CLS, DIR, CD, etc... y jugar con sus salidas, con las redirecciones usando <> o etc... inclusive si queremos que nuestro código quede en exe les recomiendo usar la utilidad Bat2exec para convertir un bat a exe. Los bats puede lograr muchas cosas, hasta virus existen en este lenguaje.

COMANDOS EDIT, MKDIR, CHDIR, RMDIR

COMANDO: EDIT (EDITOR)
TIPO
: Externo
OBJETIVO: Inicia el editor del MS-DOS con el que se crean y modifican archivos de texto ASCII.
SINTAXIS: EDIT [[unidad:][ruta]nombrearchivo]

PARAMETRO:
[[unidad:][ruta]nombrearchivo] Especifica la posición y nombre de un archivo de texto ASCII. Si el archivo no existe , MS-DOS Editor lo
creara. Si existe, lo abrirá y presentara su contenido en la pantalla.

COMANDO: MD (MKDIR) (CREAR DIRECTORIO)
TIPO:
Interno
OBJETIVO: Crea una estructura de directorios de varios niveles.
SINTAXIS: MD [unidad:] ruta

PARAMETROS:
unidad: Especifica la unidad en la que será creado el nuevo directorio.
ruta Especifica el nombre y ubicación del nuevo directorio.

EJEMPLOS: Supongamos que desee crear un directorio en el disco de la unidad actual y usar dicho directorio para almacenar toda su información referente a ventas. Escriba el siguiente comando para crear un directorio llamado VENTAS:
md \ventas o simplemente md ventas
Si usted quiere crear un directorio llamado CUENTAS estando en la unidad C en el directorio raíz, escriba lo siguiente:
C:\>md cuentas ¬
Ahora si usted desea comprobar que creo un directorio llamado CUENTAS haga lo siguiente:

C:\>dir ¬
En su pantalla aparecerá algo similar a lo siguiente:
Volumen en la unidad C es ESCI
Directorio de C:\
DOS dir 26754 28/08/94 12:00
WP51 dir 9562 28/08/94 12:00
EWB dir 57156 28/08/94 12:00
SCAN dir 6146 28/08/94 12:00
COMMAND COM 26155 28/08/94 12:00
MARY TXT 8424 16/09/94 14:00
CUENTAS dir 1562 01/12/95 11:00
7 Archivo(s) 16987883 bytes libres

Con lo cual usted se dará cuenta que tiene un archivo llamado CUENTA además de otros directorios y archivos.

COMANDO: CD (CHDIR) (CAMBIAR DE DIRECTORIO)
TIPO:
Interno
OBJETIVO: Presenta el nombre del directorio actual o cambia el directorio actual
SINTAXIS: CD [unidad:] [ruta]
CD [..]
PARAMETRO
[unidad:] [ruta] Especifica la unidad de disco (si no es la unidad actual) y el directorio al que se desee cambiar.
.. Especifica que desea cambiar al directorio padre.
\ Regresa al directorio raíz.
NOTA: El directorio raíz es el mas alto de la estructura de directorios de una unidad de disco determinada.

EJEMPLOS: Para cambiar de su directorio actual al directorio llamado prueba haga lo siguiente:
cd \prueba
Para cambiar de un subdirectorio al directorio padre, escriba el
siguiente comando:
cd ..

COMANDO: RD (RMDIR) (ELIMINAR DIRECTORIO)
TIPO: Interno
OBJETIVO: Elimina un directorio siempre y cuando este vacío.
SINTAXIS: RD [unidad:]ruta

PARAMETRO:
[unidad:]ruta Especifica la posición y el nombre del directorio que desea eliminar.
NOTA: No se puede eliminar un directorio con archivos ocultos o de sistema.

EJEMPLO:
Para eliminar un directorio llamado ARANDA, primero asegúrese que este vacío, y escriba el siguiente comando:
rd aranda
Para eliminar el directorio CUENTAS
C:\>rd cuentas ¬
Para comprobar si eliminó el directorio CUENTAS, escriba lo siguiente:
C:\>dir ¬
El directorio CUENTAS no debe aparecer en la lista.

miércoles, 26 de marzo de 2008

SISTEMA OPERATIVO WINDOWS


Introducción
Con el paso de los años se ha producido una
evolución gradual de la estructura y capacidades de los Sistemas Operativos. Sin embargo, recientemente se ha introducido un cierto número de nuevos elementos de diseño en los nuevos Sistemas Operativos y en las nuevas versiones de los Sistemas Operativos existentes. Estos Sistemas Operativos modernos responden a nuevos desarrollos del hardware y nuevas aplicaciones. Entre estos dispositivos de hardware están las máquinas multiprocesador, incrementos enormes de la velocidad de la máquina, alta velocidad en los enlaces de las redes de comunicación e incremento en el tamaño y variedad de los dispositivos de almacenamiento de memoria. En los campos de aplicación que han influido en el diseño de los Sistema Operativos están las aplicaciones multimedia, el acceso a Internet y páginas Web y la ejecución cliente/servidor.
El porcentaje de cambios en las demandas de los Sistemas Operativos, requiere no solamente las modificaciones y mejoras en las arquitecturas ya existentes, sino nuevas formas de
organización del Sistema Operativo. Muchos de los diferentes enfoques y elementos de diseño se han probado tanto en Sistemas Operativos experimentales como comerciales, y muchos de ellos encajan dentro de las siguientes categorías
Arquitectura Micronúcleo.
Multihilos.
Multiproceso Simétrico.
Sistemas Operativos Distribuidos.
Diseño Orientado a Objeto.
La mayor parte de los Sistemas Operativos hasta hace poco
tiempo se caracterizaban por un gran núcleo monolítico. Gran parte de la funcionalidad que se pensaba debía tener un Sistema Operativo la proporcionaba este gran núcleo, incluyendo planificación, sistema de archivos, redes, controladores de dispositivos, gestión de memoria y muchas cosas más. Normalmente un núcleo monolítico está implementado como un único proceso, con todos sus componentes compartiendo el mismo espacio de direcciones.
La
arquitectura micronúcleo asigna solamente unas pocas funciones esenciales al núcleo, incluyendo espacios de direcciones, comunicación entre procesos (IPC) y planificación básica. Otros servicios del Sistema Operativo los proporciona procesos, algunas veces llamados servidores, que se ejecutan en modo usuario y que el micronúcleo trata como a cualquier otra aplicación. Este enfoque desconecta el núcleo y el desarrollo de servidores. Los servidores pueden estar diseñados para aplicaciones específicas o necesidades del entorno. El enfoque del micronúcleo simplifica la implementación, proporciona flexibilidad y se adapta bien para entornos distribuidos. En esencia, un micronúcleo interactúa de la misma forma con procesos servidores locales y remotos, facilitando la construcción de sistemas distribuidos.

Este trabajo intenta abordar la arquitectura del Sistema Operativo Windows y los servicios que cada uno de sus componentes brinda para llevar a cabo cada una de las categorías antes expuestas.
Visión General de la Arquitectura de Windows.
Un Sistema Operativo serio, capaz de competir en el mercado con otros como Unix que ya tienen una posición privilegiada, en cuanto a resultados, debe tener una serie de características que le permitan ganarse ese lugar. Algunas de estas son:
Que corra sobre múltiples arquitecturas de hardware y plataformas.
Que sea compatible con aplicaciones hechas en plataformas anteriores, es decir que corrieran la mayoría de las aplicaciones existentes hechas sobre versiones anteriores a la actual, nos referimos en este caso particular a las de 16-bit de
MS-DOS y Microsoft Windows 3.1.
Reúna los requisitos gubernamentales para POSIX (Portable Operating System Interface for Unix).
Reúna los requisitos de la
industria y del gobierno para la seguridad del Sistema Operativo.
Sea fácilmente adaptable al
mercado global soportando código Unicode.
Sea un sistema que corra y balancee los procesos de forma paralela en varios
procesadores a la vez.
Sea un Sistema Operativo de
memoria virtual.

La cual está compuesta por una serie de componentes separados donde cada cual es responsable de sus funciones y brindan servicios a otros componentes. Esta arquitectura es del tipo cliente – servidor ya que los programas de aplicación son contemplados por el sistema operativo como si fueran clientes a los que hay que servir, y para lo cual viene equipado con distintas entidades servidoras.
Ya creado este diseño las demás versiones que le sucedieron a Windows NT fueron tomando esta arquitectura como base y le fueron adicionando nuevos componentes.
Uno de las características que Windows comparte con el resto de los Sistemas Operativos avanzados es la división de tareas del Sistema Operativo en múltiples categorías, las cuales están asociadas a los modos actuales soportados por los
microprocesadores. Estos modos proporcionan a los programas que corren dentro de ellos diferentes niveles de privilegios para acceder al hardware o a otros programas que están corriendo en el sistema. Windows usa un modo privilegiado (Kernel) y un modo no privilegiado (Usuario).
Uno de los
objetivos fundamentales del diseño fue el tener un núcleo tan pequeño como fuera posible, en el que estuvieran integrados módulos que dieran respuesta a aquellas llamadas al sistema que necesariamente se tuvieran que ejecutar en modo privilegiado (modo kernel). El resto de las llamadas se expulsarían del núcleo hacia otras entidades que se ejecutarían en modo no privilegiado (modo usuario), y de esta manera el núcleo resultaría una base compacta, robusta y estable.
El Modo Usuario es un modo menos privilegiado de funcionamiento, sin el acceso directo al hardware. El código que corre en este modo sólo actúa en su propio espacio de
dirección. Este usa las APIs (System Application Program Interfaces) para pedir los servicios del sistema.

El Modo Kernel es un modo muy privilegiado de funcionamiento, donde el código tiene el acceso directo a todo el hardware y toda la memoria, incluso a los espacios de dirección de todos los procesos del modo usuario. La parte de WINDOWS que corre en el modo Kernel se llama Ejecutor de Windows, que no es más que un conjunto de servicios disponibles a todos los componentes del Sistema Operativo, donde cada grupo de servicios es manipulado por componentes que son totalmente independientes (entre ellos el Núcleo) entre sí y se comunican a través de interfaces bien definidas.
Todos los programas que no corren en Modo Kernel corren en Modo Usuario. La mayoría del código del Sistema Operativo corre en Modo Usuario, así como los subsistemas de
ambiente (Win32 y POSIX que serán explicados en capítulos posteriores) y aplicaciones de usuario. Estos programas solamente acceden a su propio espacio de direcciones e interactúan con el resto del sistema a través de mensajes Cliente/Servidor.
Capitulo 1
Modo Kernel
1.1 – Capa de Abstracción de Hardware (HAL).
Conocido por sus siglas en
inglés HAL (Hardware Abstraction Layer) es una interfaz entre el hardware y el resto del Sistema Operativo, está implementada como una biblioteca de enlace dinámico (dll) y es responsable de proteger el resto del sistema de las especificaciones del hardware, tales como controladores de interrupción e interfaces de entrada/salida. Esta abstracción hace al sistema más portable ya que el resto del sistema no tiene que preocuparse sobre que plataforma está corriendo. Cada plataforma en que el sistema corre necesita un HAL específico. El diseño intenta que cuando Windows sea portado a una nueva arquitectura de procesador, el HAL sea reescrito para el nuevo procesador, pero el resto del sistema simplemente debe ser recompilado.
Este también suministra la interfaz para el multiprocesamiento simétrico (conocido por sus siglas en inglés SMP). Las versiones Server contienen dos HALs para arquitectura de procesador (Intel, MIPS, PowerPC y and Alpha), el primero es usado para soportar un solo procesador, mientras que el segundo soporta hasta cuatro procesadores.
Para cada procesador físico que existe en
la computadora el HAL representa un procesador virtualizado al microkernel. La idea es que el procesador virtualizado esconda las características especiales del propio procesador al sistema operativo, quiere esto decir que si por ejemplo se tiene dos sistemas multiprocesadores, uno corriendo sobre un procesador Intel y otro corriendo con un Alpha, los HALs en cada sistema serían diferentes, pero los procesadores virtualizados que este presenta al microkernel en ambos casos pudieran ser idénticos. Sobre un sistema SMP (Multiprocesamiento Simétrico) para cada procesador físico en el sistema el HAL representa un procesador virtualizado al microkernel.
A este componente solo pueden acceder componentes del Ejecutor de Windows y nunca se llama por los programas del Modo Usuario. El HAL también intenta ser la única pieza de
software dentro del sistema que se comunique con el hardware, la ventaja de esto es que otros programas no pueden escribir información en el hardware ni accidentalmente, ni intencionalmente y causar una caída del sistema, también impidiendo que programas lean información directamente del hardware.
Aunque
la meta de Windows es que todas las llamadas relacionas con el hardware sean a través del HAL, la realidad es que un número pequeño de llamadas de los drivers y del Kernel bordean al HAL e interactúan directamente con el hardware.
La capa de Abstracción de Hardware conocida por sus siglas en inglés (HAL) es una biblioteca de manipulación de hardware con rutinas suministradas por Microsoft o por el fabricante del hardware. Esta capa queda en el nivel más bajo del Ejecutor de Windows (entre el hardware y el resto del Sistema Operativo), esta esconde las características de la plataforma para que todas las plataformas y arquitecturas parezcan igual al Sistema Operativo, esto permite al SO correr sobre diferentes plataformas con uno o varios procesadores, facilitando además a los drivers de dispositivos adaptarse a distintas arquitecturas de E/S sin tener que ser modificados en gran medida.
1.2 – MicroKernel
Es el responsable de todas las
acciones que se realizan sobre le sistema y casi todas las funciones del sistema pasan a través de él.
El diseño de este componente asigna muchas de las funciones normalmente asignadas al Kernel en los Sistemas Operativos tradicionales a un grupo de programas llamado Ejecutor de Windows, del cual el microkernel es parte, corre en el modo privilegiado y ambos (el ejecutor y el microkernel) se comunican a través de primitivas del sistema operativo a bajo nivel.
La principal tarea de este componente es la planificación de ejecución de hilos (segmento de código perteneciente a un proceso particular). A cada hilo es asignada una prioridad de 0 a 31, este entonces envía hilos a correr en dependencia de su número de prioridad y los permite ejecutarse un tiempo determinado antes de apropiarse de ellos y permitir que otro proceso corra.
Aquí es importante aclarar que el microkernel no planifica la ejecución de procesos, sino que planifica la ejecución de hilos en el entorno de un proceso, este
procedimiento es el que hace posible la multitarea con preferencia al ser el microkernel el que planifica la ejecución de todo el código que corre en el sistema.
En un sistema multiprocesador, una copia del microkernel corre en cada procesador. Estos segmentos del microkernel son usados para mantener la coherencia de los
recursos del sistema que son compartidos ya que son accedidos por los hilos que corren en todos los procesadores.
Este también es responsable de la manipulación de interrupciones del sistema desde dispositivos físicos. Normalmente cuando el sistema es interrumpido, el microkernel se apropia del hilo que este corriendo en ese momento para procesar la interrupción.
El microkernel también manipula las excepciones del procesador, donde estas excepciones ocurren cuando el procesador intenta hacer alguna operación que no se le está permitida, como el intento de escribir en una porción de memoria a la cual no tiene acceso o cuando se divide por cero.
El uso final del microkernel es suministrar un soporte para la recuperación del sistema de una caída de energía. Si el sistema esta equipado con un suministrador de energía ininterrumpible (más conocido por sus siglas inglés UPS) el microkernel es advertido cuando la caída de energía es detectada, entonces este coordina un cierre ordenado del sistema, el cual incluye la advertencia a los
dispositivos de Entrada/Salida de la caída de la energía y permitir entonces restaurarse consecuentemente.
Puesto que el Microkernel está involucrado en la mayoría de las acciones asumidas por el Sistema Operativo, las porciones críticas de este son escritas en
lenguaje ensamblador para garantizar que este pueda correr lo más rápido y eficientemente posible, lo que trae consigo que su optimización sea un factor crítico de funcionamiento cuando el sistema es portado a diferentes arquitecturas.
El microkernel está situado en el
corazón de Windows, trabaja muy estrechamente con el HAL (Nivel de Abstracción de Hardware), este planifica la ejecución de hilos y manipula las interrupciones y excepciones de procesos. El papel de este es mantener a los procesadores lo mas ocupado posible. En sentido general este se encarga de las funciones más básicas de todo el SO, como son:
Ejecución de subprocesos.
Sincronización multiprocesador.
Manejo de las interrupciones de hardware.
1.3 – El Ejecutor de Windows.
El Ejecutor de Windows se encarga de las tareas importantes, las que son de vital importancia para el sistema completo, ya que el microkernel está casi siempre demasiado ocupado para dirigirse directamente.
Una definición clara es que el Ejecutor de Windows provee los fundamentos del sistema operativo que serán suministradas a todas las aplicaciones que corren sobre el sistema. Este incluye servicios como
la Administración de Objetos, de Memoria virtual, de Entrada-Salida y de Procesos.
El Ejecutor de Windows corre exclusivamente en Modo Kernel y es llamado por los subsistemas de ambiente protegido cuando estos necesitan de sus servicios. Debido a la jerarquía de Windows las aplicaciones que corren en Modo Usuario no pueden llamar segmentos del Ejecutor de Windows directamente, sino servicios de
demanda de los subsistemas de ambiente (explicado en capítulos posteriores), como Win32 y POSIX los que a su vez se encargan de llamar los componentes del Ejecutor de Windows.
1.4 – El
Administrador de Objetos.
El Administrador de Objetos (Object Manager) es usado para crear, modificar y eliminar objetos (
tipos de datos abstractos que son usados para representar recursos del Sistema Operativo) usados por todos los sistemas que conforman el Ejecutor de Windows. Este también proporciona información sobre el estado de los objetos a todo el Sistema Operativo.
Los objetos pueden ser cosas concretas, tales como puertos de dispositivos, o pueden ser más abstractos como hilos. Cuando un objeto es creado a este se le da un nombre por el cual otros programas pueden accederle. Cuando un proceso necesita acceder al objeto este solicita un tratamiento de objeto al administrador de objetos. El manipulador de objetos suministra un puntero que es usado para localizar al objeto, así como una información de
control de acceso que dice como se puede acceder a el. Esta información de control de acceso es suministrada por el subsistema de seguridad (tema que se abordará en próximos temas).
Este también se asegura que los objetos no consuman muchos recursos (por lo regular la memoria), manteniendo cuotas para los diferentes tipos de objetos.
Además el Administrador de Objetos se encarga de limpiar objetos huérfanos (objetos que parecen no tener dueño), esto es conocido como recolección de
basura. La carencia de esta facilidad en Windows 3.x era la causa de muchos problemas, ya que cuando un programa colapsaba o manipulaba incorrectamente los recursos del sistema, los recursos consumidos por este no eran devueltos al sistema para que volvieran a estar disponibles produciendo un error por falta de recursos del sistema. De hecho esto era un escape de memoria.
A modo de resumen el Administrador de Objetos se encarga de crear, destruir y gestionar todos los objetos del Ejecutor de Windows.
1.5 – El Administrador de Procesos.
El Administrador de Procesos (Process Manager) es el responsable de crear, quitar y modificar los estados de todos los procesos e hilos. Este también proporciona información sobre el
estado de procesos e hilos al resto del sistema.
Un proceso, por la definición, incluye un espacio de dirección virtual, uno o más hilos, un segmento de código del programa ejecutable, y un conjunto de recursos del sistema. Un hilo es un objeto ejecutable que pertenece a un solo proceso y contiene a un contador del programa que apunta a su posición actual en el segmento de código ejecutable del proceso, dos
pilas, y un conjunto de valores del registro.
El Administrador de Procesos, como todos los miembros del Ejecutor de Windows, juega un papel vital en el funcionamiento del sistema entero. Cuando una aplicación comienza su ejecución, se crea como un proceso lo que requiere una llamada al Administrador de Procesos. Como todo proceso debe tener por lo menos un hilo, el Administrador de Procesos es invocado de nuevo para crear el hilo.
El Administrador de Procesos se usa para manejar los hilos, pero no tiene su propio conjunto de
políticas sobre cómo planificar la ejecución de procesos e hilos. Estas políticas son determinadas por el propio microkernel.
El administrador de Procesos (Process Manager) es el responsable de crear, quitar y modificar los estados de todos los procesos e hilos, así como de proporcionar información sobre el estado de procesos e hilos al resto del sistema.
1.6 – El Administrador de Memoria Virtual.
El Administrador de Memoria Virtual (Virtual Memory Manager o VMM) proporciona la gestión de memoria virtual del sistema. La memoria virtual es un esquema que permite usar los recursos del disco en lugar de la memoria
física del sistema moviendo las páginas al disco cuando estas no están siendo usadas y recuperándolas cuando se les necesitan. Este es un segmento integral de Windows el cual asigna espacios de direcciones de 32 bit a cada proceso sin preocuparse de la cantidad de memoria física del sistema.
A cada proceso se asigna un espacio de memoria virtual de 4GB. De este espacio, los dos giga bites superiores son reservados para el uso del sistema, mientras que los otros dos giga bites restantes son para el uso del proceso. El Administrador de Memoria Virtual es el responsable de traducir las direcciones de memoria del proceso a las direcciones de memoria reales del sistema. Si la dirección de memoria del proceso hace referencia a un segmento de memoria que ha sido paginada hacia el disco, el Administrador de Memoria Virtual recupera la página del disco.
El Administrador de Memoria Virtual se encarga de todo lo relacionado con la
política de gestión de la memoria, determina los conjuntos de trabajo de cada proceso, mantiene un conjunto de páginas libres, elige páginas que se van a pasar a la memoria real, sube y baja páginas entre la memoria RAM y el archivo de intercambio en disco.
1.7 – Servicios de Llamadas a
Procedimientos Locales.
El
Servicio de Llamadas a Procedimientos Locales (Local Procedure Call Facility o LPC) se integran al diseño cliente/servidor de Windows. Este es la interfaz entre todos los procesos clientes y servidores que corren localmente en el sistema.
La estructura del Servicio de Llamadas a Procedimientos Locales es muy similar a la de las llamadas a Procedimientos Remotos (RPC), excepto que esta está optimizada y solamente soporta comunicación entre procesos clientes y servidores localmente. Más específicamente, el LPC es un mecanismo que permite a dos hilos en procesos diferentes intercambiar información.
Recuerde que nosotros dijimos que el subsistema de Win32 es una aplicación que corre en el Modo Usuario y correrá en su propio espacio de memoria. Cuando un programa se quiere comunicar con el subsistema Win32 para solicitar servicios, llama una
función desde la DLL apropiada, esta función entonces usa la LPC para pasar la petición al subsistema de procesos Win32, la que procesa la demanda y realiza la acción pedida y devuelve un mensaje de realización a través de la LPC.
El Servicio de Llamadas a Procedimientos Locales es el módulo que se encarga de recibir y enviar las llamadas de procedimiento locales entre las aplicaciones cliente y los subsistemas servidores.
1.8 – El
Monitor de Seguridad.
El Monitor de Seguridad (Security Reference Monitor o SRM) es el lecho de toda la seguridad dentro del sistema WINDOWS y es el responsable de hacer cumplir todas las políticas de seguridad en la
computadora local.
Este componente trabaja conjuntamente con los subsistemas de tiempo de corrida, proceso de conexión al sistema (conocido como logon process) y control de la seguridad local (local security authority). Cuando un usuario intenta conectarse al sistema su
identidad es verificada, el subsistema de proceso de conexión pide una ficha de acceso de seguridad (conocido por sus siglas en inglés SAT o security access token) del usuario. El SAT contiene una lista de los privilegios de usuarios y grupos. Este se usa como llave para ese usuario durante la sesión de conexión. Siempre que el usuario quiera hacer algo, el SAT es presentado y usado para determinar si el usuario puede realizar las acciones.
Este componente trabaja estrechamente con el Administrador de Objetos. Cada vez que un usuario intenta acceder a un objeto el Administrador de Objetos crea un manipulador para acceder a este y llama al SRM para determinar el nivel de acceso concedido por el manipulador. El SRM usa información contenida en la ficha de acceso del usuario y lo compara con la lista de control de accesos sobre el objeto para ver si al usuario debe concederse el nivel de acceso pedido. De esta forma el SRM tiene el control de la seguridad de acceso de todos los objetos en el sistema.
1.9 – El Administrador de Entrada-Salida.
El Administrador de Entrada-Salida (I/O Manager) es responsable de gestionar
la comunicación entre los distintos drivers de dispositivo, para lo cual implementa una interfaz bien definida que permite el tratamiento de todos los drivers de una manera homogénea, sin que intervenga el cómo funciona específicamente cada uno. Tiene una serie de subcomponentes que son:
Driver del Sistema de Archivos: este se encarga de establecer la comunicación con los drivers de los Sistemas de Ficheros, ya que el sistema permite la coexistencia de múltiples Sistemas de Archivos en diferentes particiones lógicas de la misma unidad física.
El servidor y el redirector de
red.
Los drivers de dispositivo del sistema.
El administrador de caches (Cache Manager): este se encarga de manipular la cache para todo el Sistema de Entrada y Salida. Este es un
método que utilizan los sistemas de archivos para mejorar su rendimiento, donde en lugar de leer y escribir en disco un fichero usado frecuentemente este se almacena en una cache de memoria y la lectura y escritura de estos ficheros se realiza desde memoria. Este componente se encarga de la magia negra que es a menudo necesaria para hacer que varios dispositivos se comuniquen entre si y convivan juntos en un segmento. El Administrador de Entrada-Salida (I/O Manager) es responsable de gestionar la comunicación entre los distintos drivers de dispositivo.
Capitulo 2
Modo Usuario
2.1 – Subsistemas de Ambiente Protegido
Dos de los
objetivos de WINDOWS son personalidad y compatibilidad. Esto ha sido logrado a través de los subsistemas de ambiente protegido.
La personalidad esencialmente significa que WINDOWS expone múltiples conjuntos de interfaces de programas de aplicación (APIs) y puede actuar eficazmente como si fuera un sistema operativo diferente. WINDOWS viene con una personalidad POSIX y OS/2 además de sus personalidades Win32, Win16 y DOS.
En WINDOWS, hay tres subsistemas de ambiente protegido:
El subsistema de Win32
El subsistema de POSIX
El subsistema de OS/2
Aunque algunas veces se muestran las personalidades Win16 y DOS incluidas en una lista de subsistemas de ambiente protegido, ellas realmente son parte del subsistema Win32.
Los subsistemas de ambiente protegido actúan como los mediadores entre las aplicaciones del Modo Usuario y el Ejecutor de Windows.
Recuerde que el Ejecutor de Windows y todos sus componentes viven en el Modo Privilegiado o Modo Kernel, mientras que todos los demás viven en el Modo Usuario, esto incluye todos los subsistemas de ambiente. Cuando una aplicación hace una llamada a un subsistema de ambiente, este es pasado a través de una capa de servicios del Ejecutor de Windows.
Cada subsistema de ambiente guarda huella de sus propios procesos y trabaja independientemente de los otros subsistemas. Cada aplicación sólo puede correr en el subsistema para el cual fue diseñado. Cuando usted inicia una aplicación en WINDOWS, mira el encabezamiento representado por el archivo y determina en cuál subsistema ejecutar la aplicación.
2.2 – El Subsistema Win32
Win32 es el subsistema nativo y primario de WINDOWS. Las bases para este subsistema es el conjunto de APIs de Win32. Muchos de estas API son extensiones directas de sus homólogas Win16.
Este subsistema actúa como un servidor para todos los otros subsistemas de ambiente soportados en WINDOWS, los que actúan como clientes y traducen sus llamadas API hacia las API apropiadas de Win32.
El subsistema Win32 es responsable de toda la entrada y salida. Este posee el control de la pantalla, el
teclado, y el ratón. Cuando otros subsistemas, como OS/2 o POSIX, necesitan beneficiarse de estos dispositivos, ellos piden los servicios al subsistema de Win32.
Algunos de los objetivos que se trazaron para mantener la compatibilidad con las aplicaciones hechas en versiones anteriores fueron:
Permitir que los programas hechos sobre DOS pudieran correr sin modificación.
Suministrar la capacidad para ejecutar la mayoría de las aplicaciones Windows de 16 bits sin modificación
Proteger al sistema y otras aplicaciones de 32 bits de la interferencia de las aplicaciones de 16 bits y DOS.
Permitir a las plataformas RISC (Reduced Instruction set Computer,
microprocesador cuyo número de instrucciones es reducido para lograr una frecuencia más alta de trabajo) ejecutar aplicaciones Windows de 16 bits y DOS.
Suministrar un mecanismo para compartir
datos entre aplicaciones Windows de 32 y 16 bits.
Muchas personas piensan en Windows 3.x como un Sistema Operativo. Técnicamente, no es un verdadero Sistema Operativo, sino una interfaz de usuario que es miembro del DOS, el verdadero Sistema Operativo.
Así que, el primer paso en proporcionar compatibilidad fue crear un ambiente de DOS. El ambiente de DOS en WINDOWS se llama la máquina virtual de DOS (Machine DOS Virtual o VDM). El VDM es una aplicación de modo usuario de 32 bits el cual solicita los servicios del subsistema de Win32 y en ocasiones directamente a la capa de servicios del sistema. Es basado en DOS 5.0.
WINDOWS permite ejecutar tantas aplicaciones de DOS como uno desee, donde cada aplicación corre en su propio VDM. Puesto que los VDMs son nada más que procesos normales bajo WINDOWS, ellos también son multitarea preventiva al igual que otros procesos en el sistema. Por consiguiente, puede decirse que WINDOWS permite la multitarea preventiva de programas de DOS.
Uno de los rasgos adicionales del VDM es que le da 620 KB de memoria "convencional" libre al usuario. Lo milagroso sobre esto es que también da a las aplicaciones de DOS soporte de ratón, red, y
CD-ROM.
El Subsistema Win32 es el más importante, ya que atiende no sólo a las aplicaciones nativas de Windows, sino que para aquellos programas no Win32, reconoce su tipo y los lanza hacia el subsistema correspondiente. En el caso de que la aplicación sea MS-DOS o Windows de 16 bits (Windows 3.11 e inferiores), lo que hace es crear un nuevo subsistema protegido. Así, la aplicación DOS o Win16 se ejecutaría en el contexto de un proceso llamado VDM (Virtual DOS Machine, máquina virtual DOS), que no es más que un simulador de un ordenador funcionando bajo MS-DOS. El subsistema soporta una buena parte del API Win32. Así, se encarga de todo lo relacionado con la interfaz gráfica con el usuario (GUI), controlando las entradas del usuario y salidas de la aplicación.
2.3 – El Subsistema POSIX.
Microsoft prestó mucha
atención a los diferentes estándares de sistemas abiertos cuando Windows NT estaba en vía de desarrollo. Ellos reconocieron el valor de soportar sistemas abiertos como un método para ganar aceptación de su nuevo sistema operativo avanzado dentro del mercado.
Uno de los estándares más frecuentemente citados soportados por Windows es el POSIX (Interfaz de Sistema operativo Portable Basado en Unix), el cual representa la interfaz del Sistema Operativo portable y fue desarrollado por el IEEE (Instituto de Ingenieros en
Electricidad y Electrónica) como un método de proporcionar portabilidad a las aplicaciones hechas sobre plataformas UNIX. No obstante, POSIX se ha integrado en muchos sistemas no UNIX.
Existen muchos niveles de obediencia con POSIX. Estos niveles representan un conjunto de evoluciones de propuestas, aunque no todas han sido aprobadas como estándares.
El subsistema de POSIX requiere un mínimo de servicios que son proporcionados por WINDOWS. Cuando una aplicación de POSIX corre en WINDOWS, el subsistema es cargado y traduce las llamadas API del
lenguaje C, requeridas para soportarlo en llamadas a APIs de Win32 las que son servidas por el subsistema Win32.
Debido a la
naturaleza limitada, el subsistema de POSIX en WINDOWS no suministra soporte para gestión de redes o sistema de seguridad.
El Subsistema POSIX interacciona con el Ejecutor de Windows. Se encarga de definir aspectos específicos del Sistema Operativo UNIX, como pueden ser las relaciones jerárquicas entre procesos padres e hijos (las cuales no existen en el subsistema Win32, por ejemplo, y que por consiguiente no aparecen implementadas directamente en el Ejecutor de Windows).
2.4 – El Subsistema OS/2.
El subsistema de OS/2 está implementado como un subsistema de ambiente protegido, parecido al subsistema POSIX. Este traduce las llamadas API de OS/2 en llamadas a APIs de Win32 que son servidas por el subsistema de Win32.
El subsistema y sus aplicaciones corren en su propio espacio de memoria protegido de 32 bits y constituyen multitarea preventiva unas respecto a otras y respecto a otras aplicaciones que corren en el sistema.
Además de un conjunto de
motores APIs de OS/2, el subsistema implementa muchos APIs gestores de LAN (Red de Área Local), incluyendo tuberías, NETBIOS y mailslots. De esta manera difiere del subsistema POSIX ya que este no posee soporte para gestión de redes.
El Subsistema OS/2 igual que el subsistema POSIX proporciona un entorno para aplicaciones UNIX, este subsistema da soporte a las aplicaciones OS/2. Proporciona la
interfaz gráfica y las llamadas al sistema; las llamadas son servidas con ayuda del Ejecutor de Windows.
Conclusiones
Windows es un sistema que aprovecha la
potencia de los procesadores, ha sido diseñado para adaptarse a las nuevas tecnologías, ofrece compatibilidad con varias plataformas (OS/2, Unix y versiones anteriores a el mismo), soporta el multiprocesamiento simétrico, buen rendimiento y conectividad, seguridad y al no estar encasillado en ningún modelo estandar de Sistema Operativo tiene la capacidad de combinar las ventajas del modelo cliente/servidor, puede correr además sobre múltiples arquitecturas con un mínimo de cambios, permite que varios procesos sean ejecutados simultáneamente en varios procesadores y estos no se apropien de recursos del sistema por tiempo indefinido, sino por tratamiento del sistema.

SISTEMA OPERATIVO MAC

DEFINICION DE (SO) MAC
Mac OS, abreviatura de Macintosh Operating System (Sistema Operativo de Macintosh), es el nombre del primer sistema operativo de Apple para los ordenadores Macintosh. El Mac OS original fue el primer sistema operativo con una interfaz gráfica de usuario en tener éxito. El equipo de Macintosh incluía a Bill Atkinson, Jef Raskin y Andy Hertzfeld.
Hay una gran variedad de puntos de vista sobre cómo fue desarrollado
Macintosh y dónde se originaron las ideas subyacentes. Mientras la conexión entre el proyecto Macintosh y el proyecto Alto en Xerox PARC ha sido establecido en los documentos históricos, las contribuciones iniciales del Sketchpad de Ivan Sutherland y el On-Line System de Doug Engelbart no son menos significantes. Véase Historia de la interfaz gráfica de usuario y Apple vs Microsoft.
Apple quitó importancia de forma deliberada a la existencia del sistema operativo en los primeros años de Macintosh para ayudar a hacer que la máquina pareciera más agradable al usuario y a distanciarla de otros sistemas como
MS-DOS, que eran un desafío técnico. Apple quería que Macintosh fuera visto como un sistema que trabajara nada más con encenderlo

Versiones
La pronta sistema operativo Macintosh inicialmente constaba de dos piezas de software, denominado "Sistema" y el "Finder", cada una con su propio número de versión. [1] System 7.5.1 fue el primero en incluir el logotipo Mac OS (una variación de El original "Happy Mac" cara sonriente Buscador de icono de inicio), y Mac OS 7,6 fue el primero en ser llamado "Mac OS" (para asegurar que los usuarios se identifican todavía con Apple, incluso cuando se utiliza en "clones" De otras empresas).
Hasta la llegada de la posterior
PowerPC G3 basada en sistemas, partes importantes del sistema se almacenan en física ROM en la placa base. El objetivo inicial de esta fue para evitar el uso de la limitada de almacenamiento de disquete s en el apoyo del sistema, dado que los primeros ordenadores Mac no tiene disco duro. (Sólo un modelo de Mac nunca fue realmente usando la ROM de arranque solo, el 1991 Mac Classic modelo.) Esta arquitectura también permitió una interfaz completamente gráfica de OS en el nivel más bajo, sin la necesidad de un texto - Sólo la consola o el modo de línea de comandos. Un fatal error de software, o incluso un hardware de bajo nivel de error descubierto durante el inicio del sistema (por ejemplo, la búsqueda de unidades de disco no funciona), se comunicó a la gráfica de usuario utilizando una combinación de iconos, ventanas de cuadro de alerta, botones, el puntero del ratón, y El distintivo de Chicago fuente de mapa de bits. Mac OS depende de este núcleo del sistema de software en la ROM en la placa madre, lo que más tarde ayudó a garantizar que sólo los ordenadores de Apple con licencia o clones (con la protección de los derechos de autor-ROM de Apple) podría ejecutar Mac OS.
El Mac OS se pueden dividir en dos familias de sistemas operativos:
"Clásico" Mac OS, el sistema que envía con la primera Macintosh en 1984 y sus descendientes, que culminó con
Mac OS 9.
La más nueva
Mac OS X (la "X" se refiere al número romano,diez). Mac OS X incorpora elementos de la OpenStep (por lo tanto también BSD Unix y Mach) y Mac OS 9. Su bajo nivel BSD basado en la fundación, Darwin, software libre / software de código abierto.

"Clásico" Mac OS (1984-2001)
El "clásico" de Mac OS se caracteriza por su total falta de una
línea de comandos, es un sistema operativo completamente gráfico. Anunciada por su facilidad de uso y su multitarea cooperativa, fue criticado por su muy limitada memoria de gestión, la falta de memoria protegida, y la susceptibilidad a los conflictos entre el sistema operativo "Extensiones" que proporcionan funcionalidades adicionales (tales como la creación de redes), o el apoyo a un determinado dispositivo. Algunas extensiones pueden no funcionar correctamente en conjunto, o sólo funcionan cuando se cargue en un orden particular. Solución de problemas de Mac OS extensiones puede ser un proceso de ensayo y error.
El Macintosh originalmente utilizado el
Macintosh File System (MFS), un plano del sistema de archivos con un solo nivel de carpetas. Esta fue rápidamente reemplazada en 1985 por la jerárquica del sistema de archivos (HFS), que había un verdadero directorio árbol. Ambos sistemas de archivos compatibles son otra cosa.
Imagen:Gestor de Extensiones del Mac OS 9.1.png
La mayoría de los sistemas de ficheros usados con DOS, Unix, o en otros sistemas operativos tratar un archivo como una simple secuencia de bytes, lo que requiere una aplicación para saber lo que representó bytes tipo de información. En cambio, el MFS y los archivos HFS dio dos diferentes "horquillas". La bifurcación de datos que figuran el mismo tipo de información, como los demás sistemas de ficheros, como el texto de un documento o de los mapas de bits de un archivo de imagen. La bifurcación de recursos que figuran otros datos estructurados tales como las definiciones de menús, gráficos, sonidos o segmentos de código. Un archivo puede consistir sólo de los recursos con una horquilla de datos vacía, o sólo una horquilla de datos sin recursos tenedor. Un archivo de texto puede contener su texto en la bifurcación de datos y el diseño del estilo de la información en la bifurcación de recursos, de manera que una solicitud que no reconocen el diseño del estilo de la información pueda leer el texto en bruto. Por otro lado, estos tenedores siempre un desafío para la interoperabilidad con otros sistemas operativos; copiar un archivo de un Mac a un no-Mac sistema de despojarla de su bifurcación de recursos.
El OS Classic aún se puede utilizar aplicaciones de Classic y de Apoyo se envió además de OS X con PowerPC (pero no Intel) Macs hasta principios de 2006. Sin embargo, basados en Intel Macintosh no puede ejecutar el sistema clásico o de las solicitudes, ni puede PowerPC modelos que se han actualizado a Mac OS 10,5 Leopard. Clr (())

Mac OS X (2000-presente)
Mac OS X traído estilo Unix gestión de memoria y
multitarea preventiva a la plataforma Mac. Se basa en el núcleo Mach y el BSD la aplicación de UNIX, que se incorporaron en NeXTSTEP, el orientado a objetos del sistema operativo Desarrollado por Steve Jobs 's NeXT. El nuevo sistema de gestión de memoria permite ejecutar más programas a la vez y prácticamente elimina la posibilidad de que un programa falle otro. También es el segundo sistema operativo Macintosh para incluir una línea de comandos (el primero es el ahora suspendido-A / UX, que apoya las aplicaciones de Mac OS clásico en lo alto de un kernel UNIX), aunque es visto nunca a menos que el Lanza un usuario emulador de terminal.
Sin embargo, puesto que estas nuevas características poner mayores exigencias a los recursos del sistema, Mac OS X sólo con apoyo oficial de la
PowerPC G3 y los nuevos procesadores, y ahora tiene incluso mayores necesidades (la necesidad adicional de una función de USB ( 10,3) y más tarde FireWire ( 10,4 )). Incluso en ese caso, se corre un poco lento en los más antiguos sistemas G3 para muchos fines.
En 2008, cada actualización a Mac OS X ya que el original beta pública ha tenido la cualidad de ser atípicos sensiblemente más receptivas a la versión que sustituye, lo contrario a la tendencia De la mayoría de los sistemas operativos.
Durante más de tres años,
Mac OS X ha obtenido más rápido con cada puesta en libertad - y no sólo "más rápido en la experiencia de la mayoría de los usuarios finales", pero más rápido en el mismo hardware. Esta tendencia es algo inaudito entre los sistemas operativos de escritorio contemporáneo.[2]
Construye de PowerPC Mac OS X incluirá una capa de compatibilidad para ejecutar aplicaciones de Mac mayores, el Clásico Medio Ambiente. Esto es una copia completa de los mayores de Mac OS, versión 9,1 o posterior, en un ordenador con Mac OS X proceso. PowerPC Macs buque con OS 9,2, así como OS X. OS 9,2 debe ser instalado por el usuario - que no está instalado de forma predeterminada en todas las nuevas revisiones de hardware en libertad después de la liberación de Mac OS X 10,4. La mayoría bien escrito "clásicos" de las aplicaciones funcionen correctamente bajo este entorno, pero sólo se garantiza la compatibilidad si el software fue escrito no ser consciente de la hardware actual, y únicamente para interactuar con el sistema operativo. El entorno Classic no está disponible en Macintosh basados en Intel debido a la incompatibilidad de Mac OS 9 con el hardware x86, y se eliminó completamente el Mac OS X 10,5.
Los usuarios del Mac OS original en general, actualizado a Mac OS X, pero muchos lo criticaron por ser más difícil y menos fácil de usar que la original de Mac OS, de la falta de ciertas características que no se habían re-implementado en el nuevo sistema operativo, O por ser más lento en el mismo hardware (especialmente mayores de hardware), o de otros, a veces serias incompatibilidades con el sistema operativo de mayor edad. Debido a los conductores (para impresoras, escáneres, tabletas, etc) escrito para el Mac OS de más edad no son compatibles con Mac OS X, y debido a la falta de OS X de Apple soporte para las antiguas máquinas, un número importante de usuarios de Macintosh han seguido todavía Utilizando el Mac OS clásico más edad. Pero en 2005, se ha informado de que casi todos los usuarios de sistemas capaces de funcionar con Mac OS X lo están haciendo, con sólo un pequeño porcentaje todavía correr el Mac OS clásico. ((Fact fecha = Enero 2008))
En junio de 2005,
Steve Jobs anunció en la Conferencia Mundial de Desarrolladores discurso de apertura que los ordenadores de Apple sería la transición de PowerPC a Intel procesadores. En la misma conferencia, Jobs anunció Developer Kits de transición que incluyen versiones beta de software de Apple incluyendo Mac OS X que los desarrolladores pueden utilizar para probar sus aplicaciones como parte de ellos portado para funcionar en los Mac Intel que funcionan con energía. En enero de 2006, Apple publicó los primeros ordenadores Macintosh con procesadores Intel, un iMac y el MacBook Pro, y, en febrero de 2006, Apple publicó un Mac Mini con un Intel Core Solo y Duo Procesador. El Mayo 16, 2006, Apple publicó la MacBook, antes de completar la transición de Intel agosto 7 con el Mac Pro. Para facilitar la transición para principios de los compradores de las nuevas máquinas, Macs con Intel incluyen una tecnología llamada emulación Rosetta, lo que les permite correr (a la reducción de velocidad) pre-existentes de Mac OS X nativo de aplicación Software que fue compilado sólo para Macintosh basados en PowerPC.


Emulación de PowerPC En el momento de desarrollo 68000 emulador de PowerPC apoyo es difícil de justificar no sólo debido a la emulación de código en sí, sino también el gran rendimiento previsto generales de la emulación de un PowerPC, la arquitectura frente a una verdadera Mac basadas en PowerPC. , Que iría demostrar correcta con el comienzo del proyecto PearPC incluso años después, a pesar de la disponibilidad de 7 ª y 8 ª generación de procesadores x86 con similar arquitectura de los paradigmas presentes en el PowerPC. Muchos son también los desarrolladores de aplicaciones crear y liberar ambos 68000 PowerPC versiones Classic y simultáneamente ayudando a negar la necesidad de la emulación de PowerPC. Mac PowerPC usuarios que podrían funcionar tanto técnicamente, obviamente, eligió el más rápido las aplicaciones PowerPC. Pronto Apple ya no era la venta de ordenadores Mac basados en 68000 y de la base instalada comenzó a evaporarse con rapidez. A pesar de la eventual excelente 68000 emulación tecnología disponible que nunca demostró ser aún menor de edad real amenaza para Mac debido a su retraso en la llegada y la inmadurez incluso varios años después de la liberación de mucho más convincentes PowerPC Macs.
La
PearPC emulador es capaz de emular la PowerPC procesadores requeridos por las nuevas versiones de Mac OS (como Mac OS X). Por desgracia, todavía está en sus primeras etapas y, al igual que muchos emuladores, tiende a ser mucho más lento que un nativo sistema operativo.
Durante la transición de PowerPC a los procesadores Intel, Apple cuenta de la necesidad de incorporar un emulador de PowerPC en Mac OS X con el fin de proteger a sus clientes inversiones en el software diseñado para ejecutarse en el PowerPC. La solución de Apple es un emulador llamado
Rosetta. Antes de que el anuncio de Rosetta, la industria observadores supone que cualquier emulador de PowerPC, corriendo sobre un procesador x86 sufriría una pesada pena de rendimiento (por ejemplo, PearPC es de bajo rendimiento). Rosetta es relativamente menor rendimiento pena, por lo tanto, tomó por sorpresa a muchos.
Otro emulador de PowerPC es
SheepShaver, que ha estado con nosotros desde 1998 2002 fue código abierto d con el inicio de portar Para conseguir que se ejecute en otras plataformas. Originalmente no estaba diseñado para su uso en plataformas x86 y requiere un procesador PowerPC real presente en la máquina que se ejecuta en similar a un hipervisor. A pesar de que proporciona apoyo procesador PowerPC, sólo puede ejecutar hasta Mac OS 9.0.4, ya que no emular un unidad de gestión de memoria.
Otros ejemplos son
ShapeShifter (por el mismo programador que concibió SheepShaver), Fusión y iFusion. Este último corrió el Mac OS clásico con un PowerPC "coprocesador" tarjeta aceleradora. El uso de este método que se ha dicho de igual o mayor la velocidad de un equipo Macintosh con el mismo procesador, en especial con respecto a la m68k debido a la serie real de funcionamiento en los Macs MMU trampa Modo, obstaculizar el desempeño.

Clones de Macintosh
Varios fabricantes de ordenadores a través de los años han hecho
Macintosh clones capaz de ejecutar Mac OS, en particular Power Computing, UMAX y Motorola. Estas máquinas normalmente corren diversas versiones del Mac OS clásico. Steve Jobs clon terminó el programa de licencias después de regresar a Apple en 1997.

A / UX
En 1988, Apple publicó su primer sistema operativo basado en UNIX,
A / UX, que es un UNIX sistema operativo con el Mac OS se ven y se sienten. No es muy competitivo para su tiempo, debido en parte al hacinamiento mercado Unix. A / UX había más de su éxito en las ventas a la EE.UU. Gobierno, en que UNIX es un requisito de que el Mac OS no podía ofrecer