Download ARQUITECTURA DE WINDOWS CE 6.0

ARQUITECTURA DE WINDOWS
CE 6.0
Cristian Monjo, Lluc Febrer y Guillem Sans
ÍNDICE
0.ÍNDICE
1. INTRODUCCIÓN
1.1. ¿Qué es Windows CE 6.0?.............................................................................................pg3
1.2. Características………………………………………………………………………………….pg3
1.3. ¿A qué dispositivos está destinado?...............................................................................pg6
2. ARQUITECTURA WINDOWS CE 6.0…………………………………………………………………..pg9
3. SISTEMA DE ARCHIVOS………………………………………………………………………………pg17
4. DRIVERS DE DISPOSTIVOS…………………………………………………………………………..pg19
5. ADMINISTRACIÓN DE ENERGÍA……………………………………………………….…………….pg21
6. SEGURIDAD………………………………………………………………………………..…………….pg23
7.ADMINISTRACIÓN DE REDES………………………………………………………….……………..pg25
8. DESARROLLO DE LA ISO DEL SISTEMA OPERATIVO WINDOWS CE 6.0……………………pg27
9. CONCLUSIÓN………………………………………………..…………………………………………..pg30
10. REFERENCIAS…………………………………………………………………………..……………..pg29
1. INTRODUCCIÓN.
1.1. ¿Qué es Windows CE 6.0?
Windows CE 6.0 fue lanzado el 1 de noviembre del 2006 y es la evolución de Windows CE 5.2
también conocido por su versión comercial Windows Mobile 6. Windows CE es la base de la familia
de sistemas operativos destinados a satisfacer las necesidades de los usuarios de dispositivos
informáticos pequeños y móviles, típicamente alimentados por baterías y con un uso unipersonal,
llamados dispositivos empotrados y que suelen ser PDAs, Pocket PC y Smartphones…
Por los dispositivos a los que va enfocado Windows CE 6.0, y las funcionalidades de estos, no se
trata de un Sistema Operativo como los que habíamos visto hasta ahora, donde se exigían unos
requisitos técnicos mínimos y a partir de ahí, podíamos tener un equipo con mejores o peores
prestaciones, pero siempre con las mismas funcionalidades. Ya que todos los dispositivos tenían una
arquitectura de hardware idéntica.
Windows CE deberá correr en dispositivos muy distintos entre ellos. Des del punto de vista de
hardware como de software, pues algunos servirán para controlar un horno de microondas o un
cepillo de dientes. Mientras que otros, serán prácticamente ordenadores personales, pero de
reducidas prestaciones y con una interfaz simplificada. Los hallaremos con pantallas de todos los
tamaños y colores, e incluso táctiles, algunos con botones, otros con teclados, algunos se tendrán
que poder atar a una muñeca y otros deberán viajar por el espacio…
Por estos y otros motivos que iremos viendo a lo largo de este documento, Windows CE 6.0, es un
sistema operativo con una arquitectura modular y una gran compatibilidad con el hardware que hay
en el mercado. Algo que consigue gracias al sistema de drivers ofrecido, así como sus capacidades
multiprocesador y soporte para 64bits. Windows CE 6.0, también deberá tener un núcleo muy
robusto y potente, sobretodo administrando la memoria y manejando los procesos e hilos de
ejecución utilizando prioridades, para así poder trabajar en tiempo real, un requisito que para algunos
dispositivos empotrados es completamente indispensable, como por ejemplo un sistema de frenado
automático para un automóvil.
Por otro lado, Windows CE 6.0, al trabajar sobre dispositivos móviles que normalmente se
alimentarán por batería, deberá administrar bien la energía para ofrecer una buena autonomía a la
vez que proporciona una buena conectividad y una correcta administración de redes.
Finalmente, para que Windows CE 6.0 tenga éxito, es muy importante facilitar el desarrollo tanto del
propio sistema operativo como de las aplicaciones de este, o al menos esto parece pensar la gente
de Microsoft, que ofrece facilidades nunca vistas con este objetivo.
1.2. Características
Multiprocesador
Como en anteriores versiones de Windows CE, WCE 6 soporta una gran variedad de procesadores
para ser implementado en el máximo número de dispositivos que pueda haber, haya o habrá en el
mercado: soporta ARM, X86, PowerPC, MIPS, Xscale y Renesas SuperH. Que como podemos ver
en la figura 1, en el año 2002 representaban un total del 65% de las ventas de procesadores a nivel
mundial.
Figura 1: Datos de ventas en % de procesadores del 2002
También debemos tener en cuenta que es normal encontrarnos con dispositivos empotrados que
disponen de más de un procesador y que además no suelen ser iguales, al contrario de lo que pasa
con los PCs, donde es frecuente el uso de multiprocesador (o multinúcleo), pero donde siempre son
copias idénticas los unos de los otros.
Sistema operativo en tiempo real
Un sistema operativo en tiempo real tiene que generar respuestas a las entradas externas en un
tiempo acotado y suficientemente corto para garantizar el correcto funcionamiento del sistema. Si no
fuera así, en la mayoría de los casos, el dispositivo no serviría para nada, y podría llegar a tener
consecuencias fatales para según qué sistemas, como por ejemplo en el radiocontrol de una sonda
espacial o en un dispositivo quirúrgico. Para conseguir este objetivo, el sistema operativo debe estar
diseñado específicamente para ello.
Microsoft intentó desarrollar su primer sistema operativo en tiempo real a partir de otros que no lo
eran, como Windows NT y Windows 3.1. Estos “intentos”, denominados Winpad y Pulsar fracasaron
ya que, o bien no proporcionaban los tiempos de respuesta necesarios, o lo hacían a un precio
demasiado alto.
Se pueden clasificar los sistemas en tiempo real como “suaves” o como “duros”: Soft real time
systems / Hard Real Time systems. Consideraremos suaves aquellos sistemas, donde las tareas
críticas reciben una prioridad más alta que las demás y donde normalmente se obtiene el tiempo de
respuesta necesario. Como por ejemplo controlando un aparato multimedia, donde no pasa nada si
perdemos un frame o una sílaba en una película.
Consideraremos duros, aquellos sistemas en tiempo real donde la respuesta a una tarea prioritaria
se ha de dar en un tiempo determinado o en caso contrario causará un fallo en el sistema. Por
ejemplo, en el sistema de control de un vehículo, donde si el tiempo de respuesta es demasiado
grande podemos colisionar contra otro objeto. En todo caso Windows CE 6.0 es un sistema operativo
en tiempo real duro y puede satisfacer las necesidades de las implementaciones más exigentes en
este aspecto.
Arquitectura modular
Además de las anteriores características, Windows CE 6.0 está desarrollado como un conjunto de
módulos independientes, como si fueran las piezas de una especie de LEGO que nos permiten
implementarlo en cualquier tipo de dispositivo, llegando hasta el punto de la incredulidad o incluso de
poner en duda la necesidad de dicha implementación. En todo caso, la arquitectura de Windows CE
6.0 permite meterlo en prácticamente cualquier cosa que se nos ocurra y le ofrece al fabricante que
elija implantar este sistema operativo en su dispositivo empotrado, el placer de personalizarlo a su
gusto y riesgo, ya que Microsoft solo garantiza un número limitado de versiones probadas, que
coinciden con las diferentes versiones comerciales del sistema operativo Windows CE 6.0 y que aún
no han salido al mercado. Aún así, la limitación es nula, pues además de ofrecer una plataforma de
desarrollo del sistema operativo y un entorno de programación para desarrollar las aplicaciones para
Windows CE 6.0, como novedad, en la última versión de Windows CE 6.0 Microsoft ofrece una
licencia shared code que proporciona a su propietario el código fuente del sistema operativo.
De momento Microsoft ha alcanzado acuerdos comerciales con las siguientes compañías para que
monten Windows CE 6.0 en sus dispositivos: AT&T, Chunghwa Telecom, Dopod International Corp.,
Orange, HP, HTC, iMate, LG Electronics, Motorola Inc., Palm Inc., Samsung, en Sprint, Telefónica,
Toshiba, Verizon Wireless y Vodafone.
Peso del sistema operativo
Windows CE 6.0 tiene un peso mínimo de 540K y puede alcanzar un máximo de 40MB,
dependiendo de los “módulos” que elijamos en la versión del sistema operativo. Como los
dispositivos empotrados no suelen llevar disco duro, Windows CE 6.0 se puede arrancar desde una
memoria flash.
Para que nos hagamos una idea, en su versión más básica (540K), Windows CE 6.0 incluye
únicamente lo indispensable para su funcionamiento y está destinada a probar las capacidades de
los dispositivos más limitados, para luego añadir alguna funcionalidad específica, ya que no incluye
ningún elemento del catálogo de Windows CE 6.0 ni soporte para la pantalla.
En su versión más completa (40MB), Windows CE 6.0 ofrece una atractiva interfaz gráfica así como
una versión adaptada de office con soporte para sincronización con Exchange 2007, el reproductor
Windows Media Player, mensajería instantánea y soporte para VoIP…
1.3. ¿A qué dispositivos está destinado?
Windows CE 6.0 está destinado a solventar las necesidades de cualquier dispositivo empotrado.
Desde un cepillo de dientes a los robots enviados por la NASA a Marte, pasando por cámaras de
fotos, hardware, electrodomésticos, y por supuesto Smartphones y PDAs.
Sistema empotrado
Entendemos por sistema empotrado la traducción del inglés de Embedded System, que también
podemos encontrar como sistema integrado, embedido o incrustado. En este artículo, nos
referiremos a él como sistema empotrado. Un sistema empotrado, es un sistema informático
construido dentro de otro sistema, generalmente más grande que este, con una función específica
que suele complementar a la del sistema en el que va empotrado.
Un sistema empotrado tiene unos requisitos de memoria y procesador reducidos, a la vez que los
dispositivos empotrados donde se instalan estos sistemas, también tienen sus capacidades
reducidas respecto a otros de mayor tamaño, como pueden ser ordenadores de sobremesa o
supercomputadores. En cualquier caso, este es el talón de Aquiles para los programadores de
aplicaciones para este tipo de dispositivos, ya que hacerlas correr con el hardware disponible no
siempre es tarea fácil.
Ejemplos de dispositivos empotrados
Para más aclaración adjuntamos en las figuras 2,3,4 y 5 ejemplos de dispositivos empotrados todos
ellos funcionando bajo Windows CE.
En la figura 2 podemos ver un dispensador de gasolina que funciona con Windows CE. Está
conectado a la red de servidores de la gasolinera y dispone de funciones de mantenimiento
automatizadas además de publicidad programable.
Figura 2: Dispensador de gasolina WCE
En la figura 3 podemos ver un robot utilizado en automoción que utiliza Windows CE para su
funcionamiento con un procesador X86.
Figura 3: Robot automoción WCE
En la figura 4 podemos ver un dispositivo, en este caso un PDA de Acer, con una versión de
Windows CE.
Figura 4: PDA Acer con Windows Mobile
Y por último en la figura 5 podemos ver la instalación de una versión de Windows CE en un Fiat 500.
Esta versión de Windows CE denominada automotive està destinada a hacer las funciones de manos
libres y reproductor de música a la vez que nos permite recibir y escuchar los mensajes que
recibimos en el dispositivo mientras conducimos.
Figura 5: Windows Mobile en Fiat 500 2. ARQUITECTURA DE WINDOWS CE 6.0
Para desarrollar el primer Windows CE, Microsoft comenzó desde cero, pues sus intentos anteriores
de desarrollar un sistema operativo para dispositivos empotrados, basados en Windows NT y
Windows 3.1 fueron poco menos que desastrosos. Aun así, el nuevo sistema operativo se basó en la
API win32 para mayor comodidad de los desarrolladores, ya fuesen del nuevo sistema operativo o de
las aplicaciones que correrían sobre él. Pero añadiendo solo aquello estrictamente necesario, para
optimizar el sistema y adaptarse a las limitaciones de memoria y procesado de los dispositivos
empotrados. A pesar de que ha llovido mucho desde aquella primera versión de Windows CE, la
premisa de ahorro y eficiencia continúa siendo vigente y se ha ido mejorando la arquitectura para
ceñirse más y más a ella.
En la figura 6 podemos ver la estructura que sigue la arquitectura de Windows CE 6.0. Observamos
una gran separación entre el espacio de usuario y el espacio del Kernel, que es el núcleo del sistema
operativo.
Del espacio de usuario, forman parte las aplicaciones que están por encima de la Shell del sistema
operativo, los servicios ofrecidos por el sistema y los drivers en modo usuario. Por debajo de estos
últimos tenemos los CoreDLL, winsock, commctrl, wininet y commdlg. Que nos resultaran familiares
por su semejanza con los componentes de la arquitectura de Windows de escritorio.
El espacio del Kernel, abarca los siguientes componentes: Kernel.DLL, sistema de archivos, GWES,
redes, device.DLL, drivers, kcore.DLL, oal.DLL, bootloader y hardware. Que en el siguiente apartado
veremos con más detalle.
Figura 6: Arquitectura Windows CE 6.0
Kernel
El Kernel es la parte principal del sistema operativo y se ocupa de la gestión de los procesos, hilos de
ejecución y la administración de la memoria, así como de proporcionar los drivers de los
componentes más básicos. En la figura 7 podemos ver un pequeño desglose de su arquitectura
subdividida por las interfaces DLL y de procesado, que controlan las llamadas de las funciones y
gestionan los “traps” que se comunican con el Kernel , respectivamente. Y una descripción de las
librerías más importantes.
Figura 7: Arquitectura del Kernel de Windows CE 6.0 FileSys.DLL: Da soporte al sistema de archivos y se comunica con los drivers del sistema.
GWES.DLL: Es el subsistema encargado de los gráficos, ventanas y eventos.
Device.DLL: Drivers para los dispositivos.
KCCOREDLL.DLL: Las llamadas de las APIs utilizan esta DLL para comunicarse con los servicios
del Kernel como podemos ver en la figura 8.
Además también hay DLL específicos para los servicios de red.
Windows CE 6.0 utiliza un 10% de las APIs de Windows de escritorio. Lo que en la práctica significa
que podemos recompilar las aplicaciones para Windows CE e instalarlas en un ordenador con
Windows de escritorio sin problemas, pero que al revés, habría que cruzar los dedos y tener mucha
suerte para que funcionara.
Figura 8: Llamadas al sistema en Windows CE6.0 Administración de la memoria virtual en Windows CE 6.0
La cantidad de memoria virtual se mantiene igual que en las anteriores versiones de Windows CE.
Disponemos de un espacio de memoria virtual de 32 bitsÆ 4GB, distribuidos en 2 bloques de 2GB
cada uno. Y en los que, como bien sabemos, se almacena el Kernel del SO, código y datos de las
aplicaciones y objetos como el sistema de archivos o el registro.
El primer bloque de 2GB, es para el direccionamiento de usuario y a su vez se reparte en 4 grandes
bloques como podemos ver en la figura 9. Los primeros 256MB - menos el primer MB que hace de
separación entre los dos bloques de 2GB - denominados Shared System Heap ( Pila compartida del
sistema) otorgan permisos de escritura y lectura para los componentes del SO ( Kernel y servidores
del Kernel ) mientras que sólo permiten la lectura por parte de los procesos de usuario. Se trata de
una optimización del sistema que permite a un proceso obtener datos de un servidor del Kernel sin
tener que hacerle una llamada directa y así se puede compartir este espacio entre el Kernel y el
proceso activo.
Los segundos 256 MB denominados RAM Backed Mapfiles, están mapeados en un lugar fijo, para
garantizar la compatibilidad con aplicaciones que utilizan RAM- backed map files para las
comunicaciones cruzadas entre procesos, donde varios procesos mapean vistas de la misma
dirección de la memoria virtual.
El tercer bloque, denominado Shared User DLLs contiene todos los DLLs del sistema:
Entremezclando el código y los datos. Se utiliza el mismo mapeo para todos los procesos, así que si
cargamos el mismo DLL en múltiples procesos, estos, accederán a la misma dirección de memoria.
Las páginas de datos son únicas para cada proceso, mientras que las páginas de código son
compartidas por los procesos. Por último, tenemos un bloque final denominado Process space de 1
GB de tamaño que coincide con el tamaño máximo por proceso, que contiene el código y los datos
ejecutables.
Figura 9: Distribución de la memoria virtual de usuario.
El segundo gran bloque de 2GB es para el direccionamiento del Kernel de Windows CE. Su
distribución es algo más compleja que el primer bloque tal como se puede observar en la figura 10.
En primer lugar tenemos la System Trap Area que contiene la Máquina virtual específica de la CPU
y la página de datos del Kernel. A continuación, el espacio de memoria virtual propio del Kernel que
está dividido en 2 bloques de 256MB. El primero de ellos dependiente del soporte por parte de la
CPU que en algunos casos puede desactivarlo, por ejemplo con las CPUs SHx. En todo caso el
espacio de memoria virtual del Kernel es compartido por todos los servicios y drivers que estén
cargados en él. Seguidamente, tenemos un pequeño bloque de 128MB para almacenar objetos, este
almacenamiento está destinado al sistema de archivos de la memoria RAM y registro basado en
RAM. Después hay otro bloque de 128MB donde están los XIP DLLs del Kernel para el mismo Kernel
y los servidores y drivers que tenga cargados. Los XIP DLL son aquellos propios de las aplicaciones
y se cargan al ejecutarse estas. Para acabar el último GB está destinado al mapeo estático de la
memoria física, contiene 2 bloques de 512Mb el primero de los cuales es no caché, lo que significa
que no pasa a través del caché de la CPU para acceder a la memoria física y el último está
cacheado, con lo que accede directamente a la memoria física a través de la caché de la CPU.
Figura 10: Distribución de la memoria virtual del Kernel. Una configuración típica de un dispositivo empotrado puede tener la configuración del ejemplo de la figura 11. Donde podemos ver un mapeo típico de memoria virtual a memoria física. Figura 11: Mapeo de la memoria Virtual a la física en 1 dispositivo con 32MB Flash ROM y 64MB RAM. Procesos e hilos de ejecución
El sistema de gestión de procesos e hilos de ejecución de Windows CE 6.0, se ha ido heredando de
padres a hijos dentro de la familia de Windows CE y es originario de Windows NT. Así que su
principal característica es la de permitir a un proceso, la ejecución de más de un hilo de ejecución al
mismo tiempo, ahorrando así memoria del sistema. Afortunadamente no todo es de los tiempos de
Windows NT y esta versión de Windows CE, proporciona 2 GB de memoria virtual por proceso,
hasta un máximo de 32000 procesos y un número máximo de hilos de ejecución, que dependerá de
la memoria física instalada en el sistema.
Figura 12: Diagrama de estados de un hilo de ejecución.
Para aquellos que no estén familiarizados con los hilos de ejecución, la figura 12 es un buen ejemplo
de su funcionamiento, donde se puede ver la transición entre los diferentes estados: running (en
ejecución), suspended (en la CPU esperando a ser ejecutado), sleeping (bloqueado durante un
periodo de tiempo determinado), blocked ( bloqueado a la espera de algún recurso) o terminatted
(Ejecución finalizada).
Para controlar estos estados y ofrecer el preciado tiempo de respuesta acotado que nos permite
decir que Windows CE es un sistema operativo Hard Real Time. Windows CE 6.0 tiene una
programación preemtiva para los procesos e hilos de ejecución que permite “jugar” con 256 niveles
de prioridad, que van del 0 al 255 y donde el 0 es el más prioritario y se ejecutará hasta terminar por
completo. El resto de niveles, implicaran a los procesos tener que competir para ser ejecutados, ya
que cada prioridad por encima de 0 tiene asignado un tiempo de ejecución limitado y variable de
entre 1ms i 100ms, y en caso de empate entre prioridades, se desempata aleatoriamente a favor de
uno de los procesos.
Las prioridades del 0 al 96 están reservadas para drivers en tiempo real alto, muy exigentes. Del 97
al 152 para los drivers por defecto de dispositivos basados en Windows CE. Del 153 al 247 para
drivers en tiempo real bajo (poco exigentes ). Y del 248 al 255 para prioridades que no requieran
tiempo real. En la figura 13 podemos ver un ejemplo donde tenemos 3 hilos de ejecución: thread 1
prioridad 0 y thread 2 y 3 misma prioridad y se puede ver el comportamiento del sistema ante este
escenario.
Figura 13: Ejemplo de la prioridad entre hilos de ejecución. Seguramente, más de uno se haya percatado que por muchos niveles de prioridad y tiempos de
ejecución variables que implemente Windows CE 6.0, se puede dar el caso, que un hilo de ejecución
con menor prioridad, bloquee un recurso que necesita uno de mayor prioridad, de forma que se
invertiría la prioridad asignada a estos hilos originalmente. Para solucionar este problema, Windows
CE 6.0 permite al hilo de ejecución con menor prioridad, heredar la prioridad del de mayor prioridad
hasta que libere el recurso bloqueado. Además, el programador de hilos de ejecución, puede cambiar
su programación para adaptar el resto de hilos de ejecución al nuevo escenario resultante y así evitar
una indeseable inversión de prioridad. En la figura 14 podemos ver un ejemplo donde el hilo de
ejecución con menor prioridad (thread 3) está bloqueando un recurso que necesita el hilo de
ejecución de mayor prioridad (thread1) y como se comporta Windows CE 6.0 ante este
contratiempo.
Figura 14: Ejemplo de comportamiento en caso de inversión de prioridad.
Para que la comunicación entre procesos sea tan completa como lo es la gestión de prioridades,
Windows CE soporta tanto el modelo de memoria compartida como el de paso por mensajes,
pudiéndose compartir pilas en la memoria entre varios procesos. También hay mapeo de los archivos
en memoria y se pueden usar punteros para acceder directamente a ella. Windows CE 6.0 utiliza
MSMQ (Microsoft Message Queing) para las comunicaciones entre diferentes servicios, que es un
componente de Windows que permite enviar y recibir mensajes entre aplicaciones o servicios. Y por
si hay que poner un poco de orden, para la gestión de interrupciones el Kernel dispone del Interrupt
Service Handler (ISH) que es el encargado de decidir que ISR llamar en cada momento. El uso de
Interrups Service Routine (ISR) junto con los Interrup Service Thread (IST) permite administrar las
tareas de forma óptima y acotar la latencia de las interrupciones como se puede ver en la figura 15.
Donde el ISR manipula las tareas básicas de interrupción iniciando las IST y esperando de nuevo
nuevas ISR independientemente de la IST llamada.
Figura 15: Manejo de ISR y IST por parte del ISH del Kernel de Windows CE.
3. SISTEMA DE ARCHIVOS.
FileSys.DLL proporciona soporte al sistema de archivos y se comunica con los drivers del sistema de
archivos (FSD). Windows CE 6.0 soporta 2 tipos de sistemas de archivos, los controlados por el FSD
o los Sistemas de archivos registrados. Junto con Windows CE se proporcionan FSDs para varios
sistemas de archivos tal como podemos ver en la figura 16: Catálogo del sistema de archivos y
manipulación del almacenamiento.
ITEM DEL CATALOGO
DESCRIPCIÓN
Compression
Es una API que comprime los datos en el
sistema de archivos de la RAM y la ROM.
Database Support
Una API que proporciona soporte para bases de
datos.
Bit-Based
Característica que permite identificar los
cambios ocurridos en una base de datos o el
sistema de archivos e la RAM para replicarlos en
la máquina de escritorio. Utiliza 4 bits por objeto
para sincronizar los datos.
RAM & ROM FileSystem
Driver del sistema de archivos capaz de leer en
la RAM y ROM.
ROM- only FileSystem
Driver del sistema de archivos que sólo permite
leer en la memoria ROM.
Hive-Based Registry
Sistema de registro que almacena datos dentro
de ficheros que se pueden guardar en cualquier
sistema de archivos.
RAM-based Registry
Sistema que almacena todos los datos del
registro en el object store.
Storage Manager
Es responsable de todos los ítems de
almacenamiento externo como sistemas de
archivos, filtros de sistemas de archivos y
particionamiento.
Binary Rom Image FileSystem
Permite cargar una parte de la imagen de un
sistema operativo en la RAM para su ejecución.
CD/UDFS File System
Driver del sistema de archivos que permite
CDFS, UDFS y que lee DVD y CD.
EDB Database Engine
Es un API proporciona funcionalidades
avanzadas como acceso para múltiples
usuarios, ordenes múltiples y propiedades clave.
FAT FileSystem
Driver del sistema de archivos que da soporte
para el sistema de archivos FAT.
Extended FAT File System
Driver del sistema de archivos para ExtFAT.
Partition Driver
Un driver que interpreta las particiones en un
dispositivo de almacenamiento.
Storage Manager Control Panel Applet
Aplicación del panel de control que permite al
usuario manipular dispositivos de
almacenamiento.
Transaction Safe FAT
Se asegura de que el direccionamiento de la
tabla FAT no es corrompido a causa de una falta
de energía.
System Password
API que nos proporciona autenticación para el
dispositivo de forma que no pueda ser usado por
usuarios no autorizados.
Release Directory File System
Funcionalidad que da soporte para el RDFS.
Silent FATFS UI
Construye el DLL para dispositivos sin interfaz
gráfica.
Figura 16: Catálogo del sistema de archivos y manipulación del almacenamiento Tal como se puede ver en el catálogo Windows CE 6.0 proporciona soporte para los distintos
soportes físicos que podemos encontrar en el mercado, como discos magnéticos, tarjetas de
memoria, DVD, CD y por supuesto memoria RAM y ROM.
4. DRIVERS DE DISPOSITIVOS
La gran variedad de hardware sobre el que funcionará Windows CE 6.0 requiere de algo más que los
drivers que incluye, que no son pocos, junto con interfaces específicos para flujos de datos y drivers
de muestra como base para los desarrolladores. Por lo que Windows CE 6.0 además acepta tanto
drivers por capas ( MDD y PDD) como monolíticos.
MDD significa Model Device Driver. Estos drivers, se basan en modelos, pues contienen un código
que es común para todos los drivers de un determinado tipo. Llaman a funciones PDD para acceder
al hardware, conectándose a la capa PDD para definir las funciones DDSI (Device Driver Service
Providor interface), que el MDD espera llamar de la capa PDD. Los MDD también proporciona al SO
las funciones DDI ( Device Driver Interface) y pueden conectarse con múltiples PDDs sin requerir
cambios en la mayoría de los casos, pues en caso de no ser así tendríamos problemas para
migrarlos a futuras versiones. Los MDDs pueden contener cualquier IST.
PDD significa Platform Dependent Driver. El código es específico para una plataforma concreta. Así
que dependiendo de la plataforma de hardware, deberán ser modificados. Están específicamente
diseñados para trabajar con implementaciones de los MDDs. Al contrario que los drivers monolíticos
exponen las funciones DDSI que llama el MDD.
Los Drivers monolíticos son una combinación de MDD y PDD en un solo driver.
Ahora que ya sabemos cómo es cada tipo de driver debemos aprender a utilizarlos
convenientemente. Usando drivers por capas sólo tendremos que modificar el PDD, pero un driver
por capas añade sobrecarga a las llamadas del sistema, porque los MDD tienen que realizar
llamadas a los PDD. Por su lado, drivers monolíticos optimizan el rendimiento, ya que al estar todos
en uno no se tienen que realizar llamadas entre ellos. Así que, además de ser más simples, también
son más eficientes. Pero como contrapartida los drivers monolíticos son más difíciles de migrar a
futuras versiones de Windows CE, porqué este sistema operativo utiliza en su mayor parte drivers
divididos en MDD y PDD. En todo caso ya sea usando drivers monolíticos o por capas podemos
basar la implementación en el código fuente de los drivers de muestra que se incluyen en Windows
CE que en alguna ocasión nos ahorrará un buen trabajo.
El Device Manager, hace el papel de director de orquestra, es el componente responsable de
manipular los drivers de dispositivos y sus interfaces, decidiendo en todo momento qué drivers cargar
y utilizando el registro del SO para encontrarlos. El Device Manager de Windows CE 6.0 tiene la
misma configuración básica que el de Windows de escritorio, pero con un espacio mucho más
limitado que debe tenerse muy en cuenta a la hora de añadir entradas. Sus componentes son:
•
Devcore: funcionalidad del núcleo de Device Drivers.
•
Iorm: Proporciona la funcionalidad de entrada/salida y por lo tanto es un componente
obligatorio que no nos podemos ahorrar.
•
Pmif y nopmif: Proporciona la interfaz para los puntos de entrada de los DLLs
Además del Device manager también cargan drivers el FIle System y el GWES.
Finalmente, si no hemos tenido suficiente con los drivers expuestos hasta ahora, también existe el
User Mode Driver que nos permite cargar un driver intermedio en modo usuario. Estos drivers no
pueden acceder directamente al hardware pero pueden dar más estabilidad en algunos tipos de
driver. Además, hay un reflector en el Kernel que permite que un driver en modo usuario trabaje
como si fuera en modo Kernel. En la figura 17 tenemos un pequeño esquema del funcionamiento de
los drivers en Windows CE 6.0.
Figura 17: Funcionamiento de los drivers en Windows CE 6.0.
5. ADMINISTRACIÓN DE ENERGÍA.
La administración de energía es un punto crítico para los sistemas que se alimentan por batería. En
el caso de los dispositivos empotrados, la mayoría o al menos, los más vendidos como teléfonos y
agendas utilizan este sistema de alimentación. Este concepto, que apareció con los primeros
ordenadores portátiles, parece condenado a la vida eterna, ya que por mucho que aumenta la
tecnología y la capacidad de las baterías, parece que el consumo de los equipos electrónicos lo hace
incluso más rápido. Para ofrecer la máxima autonomía, podemos ver en la figura 18 que Windows
CE 6.0 utiliza un complejo sistema de administración de energía que controla el dispositivo en todo
momento y que deberemos configurar con cuidado si no queremos que los usuarios acostumbrados
a las máquinas de sobremesa que siempre están consumiendo y rindiendo al 100% lo encuentren
demasiado incómodo.
Figura 18: Estados de consumo y transiciones. Power-on reset: Al reiniciar un dispositivo que previamente estaba encendido el sistema limpia la
memoria RAM e inicializa el sistema de archivos.
Cold boot: Arranque en frío. Arranque del sistema cuando este está apagado.
Warm boot: Después de arrancar el sistema este limpia la memoria RAM.
On-To-Idle: Transición des de un estado de uso intensivo del procesador a uno de bajo consumo.
Idle-to on: Paso de bajo consumo a alto consumo. El contrario que el anterior.
On-to suspend: Transición a un estado en el que el procesador está apagado. Se llama a la función
power_down del device manager.
Suspend to on: Transición des de un estado en el que el procesador está apagado a uno de alto
consumo. Se llama a la función power_on del Device manager.
On-To critical off: Transición cuando se detecta un nivel críticamente bajo de la batería.
Para más aclaración, en la figura 19 podemos ver la arquitectura del sistema de administración de
energía. La DLL encargada de la administración de la energía controla la cola de notificación y los
drivers, además de intercomunicarse con las APIs de administración de energía que recogen la
información de las aplicaciones y los drivers a través de sus respectivas APIs.
Figura 19: Arquitectura del sistema de administración de energía de Windows CE 6.0
6. SEGURIDAD.
Como todos sabemos, estamos en la era de Internet, y en consecuencia en la era de la seguridad
informática, ya que además de todo lo bueno de Internet, al contrario de lo que pasa con las
personas, los virus y otros ataques viajan a través de la red de redes a la velocidad de la luz, no
duermen nunca y no conocen ni fronteras ni leyes. Por lo que la seguridad ha pasado en pocos años
a ser algo anecdótico a ser uno de los pilares de cualquier sistema operativo que se considere
mínimamente serio.
El módulo de seguridad de Windows CE 6.0 controla el acceso al dispositivo, lo protege de procesos
e hilos de ejecución no autorizados, proporciona almacenamiento seguro de datos y del sistema de
archivos y securiza las conexiones de red e Internet. Para ello utiliza 4 herramientas básicas:
Autenticación, autorización, encriptación y repudio. Esta arquitectura, permite securizar los datos y
comunicaciones de la red de una empresa sin alterarla ni añadir ningún hardware adicional, aunque
por supuesto un antivirus está más que recomendado.
En la figura 20 podemos ver la arquitectura detallada del módulo de seguridad. Las aplicaciones
interactuan con el sistema operativo Windows CE 6.0 a través de Winsock, que diferencia entre las
conexiones seguras y las no seguras, Wininet que utiliza tanto portocols seguros como no seguros, la
DLL de seguridad, la API de criptografia y la API de almacenamiento protegido. De esta forma es
establece una especie de filtro entre la aplicación y el núcleo del sistema operativo protegiéndolo en
todo momento. Figura 20: Arquitectura del módulo de seguridad. Características
Teniendo en cuenta que la mayoría de dispositivos que implementarán Windows CE son
Smarthphones y PDAs, uno de los principales riesgos es perder el dispositivo y por ende el acceso
por parte de un tercero a la información contenida en el mismo. Aunque la mayoría soñamos con un
sistema que además de recuperar los datos que tengamos en el dispositivo desintegre buena parte la
fisionomía del usuario no autorizado, Windows CE 6.0 se limita a implementar una contraseña fuerte
para evitar este tipo de accesos no deseados. Además, si se repiten muchos logins incorrectos el
dispositivo nos hace esperar un tiempo de back-off cada vez más largo, e incluso se puede llegar al
punto de borrar completamente los datos del dispositivo remotamente. También se encriptan los
datos de la tarjeta de memoria en caso de existir esta. Custom Local Authentication Subsystem (LAS)
y Local Authentication Plug-in (LAP) nos permiten autenticación vía hardware o software de otros
fabricantes.
Otro punto importante es garantizar la seguridad de los datos mientras transmitimos la información.
Para las comunicaciones entre el dispositivo y el servidor de correo se utiliza SSL con cifrados de
128 y 256 bits. También soporta information rights management protection for email. Y los protocolos
de cifrado disponibles están certificados por el estándar federal de los EE.UU (FIPS) y son: AES,
DES, 3DES, SHA-1, RSA. Este sistema sería el equivalente a un furgón de Prosegur lleno de
pistoleros, que la verdad es que para un usuario sin licencia para matar debería ser más que
suficiente.
Para el acceso no autorizado a la red local, se utiliza un cliente de autenticación flexible: SSL TLS,
Exchange ActiveSync, Certificate-based, RSA SecurID-protected. Además existen políticas de
seguridad para controlar el acceso “por aire” al dispositivo que permiten por ejemplo bloquear el
Bluetooth discovery mode. Las políticas de acceso también controlan las aplicaciones que
ejecutamos en el dispositivo ya sea por certificados , tamaño o por criterio del usuario o directamente
prohibiendo ciertos archivos por su procedencia. Lo que supone un sistema de aduanas de lo más
habitual hoy en día.
En el tema de los virus, Office Mobile no soporta macros de forma que los virus no pueden utilizarlos
para dañar el dispositivo. Además de tener un estricto control de la ejecución de aplicaciones y
descarga de archivos adjuntos trabajando con certificados. En este aspecto, Windows CE 6.0 se
enfrenta a una leyenda urbana, que insinúa que para ser el hombre más rico del mundo, Bill Gates
tuvo que vender la seguridad de sus sistemas operativos Windows al diablo, condenándolos a ser el
objetivo numero 1 de todos los hackers, crackers y similares…
Recomendaciones
Como es habitual Microsoft hace una serie de recomendaciones para garantizar la seguridad del
sistema: Usar autenticación mutua, no almacenar credenciales ni contraseñas en el dispositivo y en
su lugar utilizar smart cards para ello. Utilizar la autenticación pass through y por supuesto un
protocolo de autenticación fuerte y no contraseñas en texto plano.
7. ADMINISTRACIÓN DE REDES.
De bien poco nos serviría un Smartphone si no pudiéramos descargar el correo, o una PDA si no la
pudiéramos sincronizar con nuestra antena GPS. En general, los dispositivos empotrados son
dispositivos pequeños de capacidades limitadas, por lo que es habitual encontrarnos con que se
tienen que comunicar, además de con el dispositivo al que van empotrados, a algún servidor o en el
caso de dispositivos de uso personal, a Internet para sincronizar con las aplicaciones de escritorio y
comunicarse con un PC de sobremesa.
Windows CE 6.0 incluye una suite completa del protocolo TCP/IP para garantizar la comunicación
con Internet y redes inhalámbricas, junto con los programas habituales para su administración y
gestión como son ping, ipconfig, netstat, tracert, ping route, ipv6). Paralelamente podemos
establecer comunicaciones a través de IR, de muy corto alcanze. O incluso conectar con redes
token ring aparte de Ethernet. Además, ofrece soporte para las APIs Winsock (las aplicaciones
acceden a la pila TCP/IP a través de esta API) , WinInet ( manipula todas las comunicaciones entre
las aplicaciones y WinSock), NetBios (interfaz para acceder a servicios de red) y WinHTTP ( interfaz
de alto nivel para el protocolo http 1.1). Finalmente como interfaces físicas disponemos de red, FIR,
puerto serie y puerto IR.
En cuanto a servicios, dispone de cliente DHCP y DNS. Y ofrece DNS extended WQuerying and
update, que nos permite mantener actualizado el nombre de nuestro dispositivo en un servidor DNS.
También soporta Dial-up con RAS (Remote Access service) y PPP ( point to point protocol). Puede
conectar con una impresora de red e incluye un agente SNMP para su gestión remota y
monitorización. Y por supuesto soporte para WAN. En la figura 21 podemos ver la arquitectura de red
y TCP/IP de Windows CE 6.0 con una cómoda separación por capas que nos permite ver de qué
forma establece las comunicaciones el sistema operativo.
Figura 21: Arquitectura de redes de Windows CE 6.0. 8. DESARROLLO DE LA ISO DE WINDOWS CE 6.0
Como ya hemos comentado antes, una de las ventajas de Windows CE 6.0 es que podemos crear
nuestra versión personalizada a partir de los componentes independientes que forman el sistema
operativo. Platform Builder Tools es la herramienta ofrecida por Microsoft para construir nuestro
propio Kernel de Windows CE. Esta herramienta se integra en el entorno de desarrollo Visual Studio
2005 o 2008. Se puede hacer tanto por interfaz gráfica (GUI) como por comandos (CLI). Además,
dispondremos del código fuente del SO para poder realizar modificaciones directamente sobre él.
Una vez desarrollado el Kernel, este, se puede “debugar” con el emulador que ofrece el Platform
Builder o descargar directamente en el dispositivo y ser probado in situ. Platform Builder también nos
permite cargar BSPs y drivers y finalmente crear el SDK de nuestra configuración personalizada para
pasarlo a los desarrolladores para que puedan desarrollar el software sin tener que conocer nuestros
drivers a fondo y las primitivas del SO.
El emulador nos permite incrementar nuestra productividad y reducir el tiempo de desarrollo del la
ISO del SO pues si tuviéramos que probar cada modificación el dispositivo final perderíamos mucho
tiempo con esta tarea. En la figura 22 podemos ver los pasos a seguir para desarrollar el Kernel.
Primero deberemos elegir una plantilla de diseño, que modificaremos para obtener nuestro propio
diseño de SO, seleccionando o deseleccionando los componentes que configuraremos
posteriormente y finalmente pasaremos al constructor que nos dará la imagen para descargar en el
dispositivo empotrado.
En la figura 22 vemos el algoritmo que sigue Platform Builder para construir la imagen del SO: Este
proceso está dividido en 4 fases, fase de compilación, fase de generación del sistema, fase de
construcción de la copia de lanzamiento y finalmente la fase de creación de la ISO descargable.
Figura 22: Pasos para crear una imagen de Windows CE 6.0. Por si esto no fuera suficiente Microsoft nos ofrece tutoriales virtuales guiados paso a paso para desarrollar la ISO de Windows CE 6.0. Los conocimientos necesarios para realizarlos son prácticamente nulos de forma que cualquiera independientemente de su nivel como programador pueda iniciarse en esta plataforma. A continuación podemos ver algunas capturas del funcionamiento de Platform builder en uno de estos tutoriales. En la figura 23 vemos un esquema del sistema de construcción del sistema operativo. En la figura 24 podemos ver Visual Studio 2005 ejecutando Platform builder para desarrollar una ISO del sistema operativo Windows CE 6.0. Y en la figura 25 vemos el Platform Builder cargado en el laboratorio virtual de Microsoft. Figura 23: Sistema de construcción ISO Windows CE. El objetivo de los distintos archivos de construcción, es poder controlar esta construcción en todo momento. Definen que código está en el Kernel, donde se carga este código en la memoria e instala el registro, sistema de archivos y datos en el dispositivo por primera vez. Hay 4 tipos de archivo en el código fuente: Archivos de directorios, que nos indican subdirectorios adicionales donde se encuentra el código fuente; archivo Makefile que contiene las variables necesarias para compilar y enlazar el código fuente; Definición modular, que define una librería ejecutable o de enlace dinámico. Y los archivos fuente que contienen las macro variables necesarias para construir el código fuente (includes y librerías). Figura 24: Visual Studio 2007 ejecutando Platform builder para desarrollar una ISO del sistema operativo Windows CE 6.0. Figura 25: Platform Builder cargado en el tutorial de Microsoft. 9. CONCLUSIÓN.
A lo largo de este artículo hemos visto con detalle las características de la última versión del sistema
operativo Windows CE, la 6.0. Microsoft ha demostrado estar a la altura y nos ofrece un producto
depurado que ha corregido las deficiencias que podría tener hasta el momento y que ofrece mejoras
importantes que, seguro, el desarrollador sabrá valorar.
Mantiene su arquitectura modular y soporte para múltiples tipos de procesador, que nos permite
adaptarla una variedad de dispositivos, que seguramente no imaginaríamos que puedan estar
funcionando bajo Windows. Gracias al complejo sistema de gestión de procesos e hilos de ejecución,
ofrece un tiempo de respuesta que lo convierte en un sistema operativo en tiempo real duro, lo que
significa que puede satisfacer las necesidades de hasta las aplicaciones más exigentes en este
aspecto. Y todo esto con un peso en memoria muy flexible, pero que sobretodo tiene la cualidad de
poder ser muy pequeño.
Se han mejorado sustancialmente aspectos importantes de la arquitectura del sistema operativo
como la administración de la memoria virtual que ha visto muy ampliada su capacidad, para
satisfacer los requerimientos de las aplicaciones de última generación.
Hemos visto los tipos de sistema de archivos que utiliza y su catálogo completo, haciéndonos a la
idea de hasta dónde puede llegar este sistema operativo. En cuanto a drivers sabemos los tipos de
drivers que podemos utilizar y su esquema funcionamiento.
También hemos podido examinar el funcionamiento del sistema de administración de energía,
percatándonos de que la administración de la energía ha recibido la atención que se merece, y que
se tiene muy en cuenta que estos dispositivos se alimentarán mayormente de baterías de capacidad
limitada.
La interconexión está completamente al día para garantizar que ningún dispositivo que corra
Windows CE 6.0 se sienta apartado de los demás, ofreciendo todas las conexiones inalámbricas
disponibles en el mercado y el soporte para los protocolos de red necesarios para sacarles provecho.
Por último hemos destinado una parte de este artículo a la plataforma de desarrollo de Windows CE
6.0 que nos permite construir un sistema operativo completamente personalizado, que ha mostrado
unas facilidades y herramientas muy competitivas destinadas a atraer la atención de los
desarrolladores de todos los niveles.
Finalmente podemos decir que Windows CE 6.0 es un buen producto y que no parece ser que
Microsoft se vaya a echar atrás en su conquista del mercado de los dispositivos empotrados y pronto
veremos la versión comercial de este sistema operativo en nuestros dispositivos personales.
Esperemos que a la hora de la verdad demuestre lo que parece ser y cumpla con las expectativas.
NOTA: Conviene no confundir Windows CE 6, con Windows Mobile 6 que en realidad está basado en
Windows CE 5.2.
10. REFERENCIAS.
Webs y documentación de referencia.
http://www.tecnologiahechapalabra.com/datos/soluciones/tecnologias/articulo.asp?i=1252 (
http://blogs.msdn.com/jasonlan/archive/2007/03/18/windows-mobile-5-0-vs-windows-mobile-6comparison-document.aspx
http://gizmodo.com/gadgets/cellphones/windows-mobile-5-vs-6-compared-table-style-245389.php (
http://www.esmiblog.com/index.php/2007/02/08/xda-orbit-con-windows-mobile-5-vs-iphone/ (WM5 vs
http://josemarq.wordpress.com/2007/07/17/analizando-el-windows-mobile-6-version-smartphone-enel-htc-s710/
http://www.celularis.com/software/windows-mobile-6-1.php
http://gospel.endorasoft.es/windows-mobile/seguridad-windows-mobile/ejecucion-aplicaciones.html
http://www.microsoft.com/spain/prensa/noticias/octubre_07/n19.mspx
http://www.microsoft.com/technet/solutionaccelerators/mobile/maintain/SecEntMessaging/8c6f92f4102d-4b51-be3f-0938f6f26927.mspx?mfr=true
http://www.microsoft.com/technet/solutionaccelerators/mobile/deploy/deployexchange2007/b59a6880
-ce6c-46dc-b427-f0f8b9dc3ff6.mspx?mfr=true
http://www.cio.com/article/28692/Microsoft_Windows_Mobile_A_First_Look
http://www.fortunecity.com/skyscraper/fatbit/607/wince/wince.html
http://www.atc.us.es/asignaturas/astr/DetallesTemario.html#_Toc178391146
www.Microsoft.com
Documentación asignatura PSEM (EPSC).