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-6-comparison-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-en-el-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/8c6f92f4-102d-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).