Terminología y conceptos básicos de Windows

---

Este capítulo presentará los conceptos básicos de Windows, estos conceptos son para facilitar la comprensión de las partes internas de Windows, para comprender los conceptos básicos y algunos términos de Windows por adelantado.

API de Windows

La interfaz de programación de aplicaciones de Windows (interfaz de programación de aplicaciones, API) es la interfaz de programación del sistema en modo usuario de la familia de sistemas operativos Windows. Antes del lanzamiento de Windows de 64 bits, la interfaz de programación para Windows de 32 bits se conocía como API Win32. Esto es principalmente para diferenciarlo de las API de Windows de 16 bits anteriores. La mayor parte de la API de Windows ahora se llama API Win32, que se refiere a las interfaces de programación de Windows de 32 y 64 bits.

Estilo API de Windows

La API de Windows contenía inicialmente solo funciones de estilo C. Actualmente, miles de funciones de este tipo están disponibles para los desarrolladores. El día que nació Windows, el lenguaje C era la elección más natural, porque se puede decir que es el mínimo común denominador de muchos lenguajes (es decir, también se puede acceder al lenguaje C a través de otros lenguajes), y el lenguaje C es lo suficientemente bajo como para exponer los servicios del sistema operativo. Pero la desventaja del lenguaje C es la gran cantidad de funciones y la falta de consistencia de nombres y agrupación lógica (como los espacios de nombres de C++). Una consecuencia de estas dificultades es que algunas API más nuevas usan un mecanismo de API diferente: el modelo de objeto componente (COM).

COM se desarrolló originalmente para permitir que las aplicaciones de Microsoft Office se comunicaran e intercambiaran datos entre documentos (como incrustar una tabla de Excel en un documento de Word o una presentación de PowerPoint). Esta capacidad también se conoce como vinculación e incrustación de objetos (OLE). OLE se implementó originalmente utilizando un antiguo mecanismo de mensajería de Windows llamado intercambio dinámico de datos (DDE). DDE tenía algunas limitaciones inherentes, por lo que se desarrolló un nuevo método de comunicación: COM. De hecho, COM originalmente se llamaba OLE2, lanzado oficialmente alrededor de 1993.

COM se basa en dos principios fundamentales:

1. Primer principio: los clientes pueden comunicarse con objetos (a veces llamados objetos de servidor COM) a través de interfaces. Una interfaz es un "contrato" bien definido que consta de una serie de métodos lógicamente interrelacionados, agrupados según el mecanismo de programación de la tabla virtual. Este también es un método común para que los compiladores de C++ implementen la programación de tablas virtuales. Esto permite la compatibilidad binaria, evita problemas de manipulación del compilador e investiga estos métodos con muchos lenguajes (y compiladores) como C, C++, visual basic, .net, delphi, etc.
2. El segundo principio: la implementación de componentes se puede cargar dinámicamente sin vincularse estáticamente al cliente.

El término servidor COM generalmente se refiere a la biblioteca de vínculos dinámicos (biblioteca de vínculos dinámicos, DLL) o archivo ejecutable (ejecutable, EXE) que se utiliza para implementar la clase COM. COM también proporciona funciones importantes relacionadas con la seguridad, la ordenación, los modelos de subprocesamiento y más. La introducción detallada a COM no se elaborará aquí. Si está interesado, puede consultar el libro Essential COM escrito por Don Box.

tiempo de ejecución de Windows

Windows 8 agrega una nueva API y un tiempo de ejecución compatible llamado Windows Runtime (a veces denominado simplemente WinRT, pero no es lo mismo que Windows RT, la versión basada en ARM del sistema operativo Windows). Windows Runtime consta de servicios de plataforma y está destinado principalmente a desarrolladores de aplicaciones de Windows (anteriormente conocidas como aplicaciones metropolitanas, aplicaciones modernas, aplicaciones inmersivas y aplicaciones de la Tienda Windows). Las aplicaciones de Windows pueden ejecutarse en dispositivos de diferentes tipos y tamaños, desde pequeños dispositivos IoT hasta teléfonos, tabletas, computadoras portátiles, computadoras de escritorio e incluso dispositivos como Xbox one y HoloLens.

Desde la perspectiva de la API, WinRT se basa en COM, con varias extensiones agregadas a la infraestructura COM básica. Por ejemplo, WinRT puede usar metadatos de tipo completo (almacenados en archivos WINMD, basados ​​en el formato de metadatos de .NET) para ampliar un concepto similar en COM denominado biblioteca de tipos. Desde la perspectiva del diseño de la API, es más restringida que las funciones clásicas de la API de Windows y proporciona espacios de nombres, jerarquías, nombres coherentes y patrones de programación.

Las aplicaciones de Windows se adhieren a un nuevo conjunto de reglas, que es muy diferente de las aplicaciones ordinarias de Windows (ahora llamadas aplicaciones de escritorio de Windows o aplicaciones clásicas de Windows).

La relación entre las distintas API y aplicaciones no es tan sencilla. Las aplicaciones de escritorio pueden usar un subconjunto de la API de WinRT y las aplicaciones de Windows pueden usar un subconjunto de la API de Win32 y COM. Para obtener detalles específicos de esta parte, consulte la documentación de MSDN La API WinRT no es una nueva API "nativa", sino algo similar a .NET que usa la API tradicional de Windows.

.NET Framework

.NET Framework es parte de Windows. La siguiente tabla enumera las versiones de .NET Framework que se instalan de forma predeterminada en Windows. Las versiones más recientes de .NET Framework también se pueden instalar en versiones anteriores del sistema operativo Windows.

versión de Windows	Versión de .NET Framework
ventanas 8	4.5
Windows 8.1	4.5.1
ventanas 10	4.6
Windows 10 versión 1511	4.6.1
Windows 10 versión 1607	4.6.2

.NET Framework consta de dos componentes principales:

1. Tiempo de ejecución de lenguaje común (CLR). Este es el motor de tiempo de ejecución de .NET, que incluye un compilador justo a tiempo (justo a tiempo, JIT) que traduce las instrucciones del lenguaje intermedio común (CIL) en la voz de la máquina de la CPU del hardware subyacente, el recolector de elementos no utilizados, la verificación de tipo, la seguridad de acceso al código y más. Se implementa como un servidor en proceso (DLL) COM que utiliza las funciones proporcionadas por la API de Windows.
2. Biblioteca de clases de .NET Framework (biblioteca de clases de framework, FCL). Esta es una gran colección de tipos utilizados para implementar la funcionalidad que las aplicaciones de cliente y servidor suelen requerir, como servicios de interfaz de usuario, redes, acceso a bases de datos y más.

Al proporcionar las funciones anteriores junto con nuevos lenguajes de programación de alto nivel (C#, Visual Basic, F#) y herramientas de soporte, .NET Framework puede ayudar a los desarrolladores a aumentar el volumen de ventas de desarrollo de las aplicaciones de destino y mejorar la seguridad y la confiabilidad. La relación directa entre .NET Framework y el sistema operativo Windows se muestra en la siguiente figura:

Servicios, Funciones y Rutinas

En la documentación de usuario y la documentación de programación de Windows, muchos términos tienen diferentes significados en diferentes contextos. Por ejemplo, la palabra "servicio" puede hacer referencia a una rutina invocable en el sistema operativo, un controlador de dispositivo o un proceso de servidor. Los significados de los diferentes términos se enumeran a continuación:

• Funciones de la API de Windows. Una subrutina en la API de Windows que está expuesta y se puede llamar. Como CreateProcess, CreateFile, GetMessage.
• Servicios del sistema nativo (o llamadas al sistema). Servicios de bajo nivel que no están expuestos en el sistema operativo pero que se pueden llamar desde el modo de usuario. Por ejemplo: la función CreateProcess de Windows llama a NtCreateUserProcess, un servicio del sistema interno, para crear un nuevo proceso.
• Funciones (o rutinas) de soporte del kernel. Dentro del sistema operativo Windows, una subrutina que solo se puede llamar desde el modo kernel. Por ejemplo: un controlador puede llamar a la rutina ExAllocatePoolWithTag para asignar memoria del montón del sistema de Windows.
• Servicio de Windows. Un proceso iniciado por el Administrador de control de servicios de Windows. Por ejemplo, el servicio del Programador de tareas que se ejecuta en modo de usuario también puede admitir el comando schtasks
• Bibliotecas de enlaces dinámicos (DLL). Las subrutinas a las que se puede llamar están vinculadas a un archivo binario que una aplicación que usa la subrutina puede cargar dinámicamente. Por ejemplo, Msvcrt.dll y Kernel32.dll (una de las bibliotecas del subsistema API de Windows). Los componentes y aplicaciones del modo de usuario de Windows hacen un uso intensivo de las DLL. La ventaja de las DLL sobre las bibliotecas estáticas es que las aplicaciones pueden compartir DLL, y Windows garantiza que solo exista en la memoria una copia de la misma DLL utilizada por varias aplicaciones.

proceso

Aunque los programas y procesos parecen similares en la superficie, existen diferencias fundamentales. Un programa es una secuencia estática de instrucciones, mientras que un proceso es un contenedor que contiene un conjunto de recursos que se utilizarán para ejecutar una instancia del programa. Desde el más alto nivel de abstracción, un proceso de Windows puede contener los siguientes elementos:

1. Un espacio privado de direcciones virtuales. Un rango de direcciones de memoria virtual disponibles para el proceso.
2. un programa ejecutable. Define el código inicial y los datos que se asignarán al espacio de direcciones virtuales del proceso.
3. Una lista de identificadores abiertos. Los identificadores se asignan a varios recursos del sistema. Los ejemplos incluyen semáforos, objetos de sincronización y archivos a los que pueden acceder todos los subprocesos de un proceso.
4. un contexto de seguridad. Un token de acceso que se utiliza para identificar un usuario relacionado con el proceso, un grupo de seguridad, un privilegio, un atributo, un reclamo, una capacidad, un estado de virtualización de control de cuenta de usuario (UAC), una sesión, una identidad de estado de cuenta de usuario restringida y también contiene el identificador del contenedor de la aplicación y la información relacionada del espacio aislado.
5. Un ID de proceso. Un identificador único que forma parte internamente del identificador de ID de cliente.
6. Al menos un hilo de ejecución. Sin embargo, es posible crear procesos "vacíos".

Muchas herramientas pueden ayudarnos a ver (o incluso modificar) procesos e información de procesos. A continuación intentaremos demostrar.

Use el Administrador de tareas para ver la información del proceso

En Windows, puede usar la tecla de método abreviado Ctrl+shift+esc para abrir el administrador de tareas, o hacer clic con el botón derecho del mouse en la barra de herramientas para abrir el administrador de tareas.

En la pestaña de proceso, se muestran cuatro columnas de información por defecto: CPU, memoria, disco y red. Después de hacer clic con el botón derecho en el encabezado de la tabla, puede optar por mostrar más información de la columna u ocultar parte de la información mostrada. La información que se puede mostrar incluye el nombre del proceso, el ID del proceso, el tipo, el estado, el editor y la línea de comandos. Algunos procesos se pueden expandir para mostrar las ventanas visibles de nivel superior creadas por ese proceso.

Puede ir a la pestaña Detalles, donde también se muestra la información del proceso, pero de forma más compacta. La ventana creada por el proceso no se mostrará aquí, pero se proporcionarán más columnas de diferentes tipos de información.

De manera similar, en la información detallada, también puede hacer clic con el botón derecho en el encabezado y seleccionar Establecer información de columna para mostrar más información sobre el proceso.

Aquí debemos centrarnos en el papel de varios valores de opciones:

• "Subprocesos": Muestra el número de subprocesos que posee cada proceso.
• "Handle": muestra el número de identificadores de objetos del núcleo abiertos por el bloqueo interno del proceso.
• "Estado": muestra el estado de ejecución actual del proceso, como en ejecución, suspendido, etc.

proceso principal

Cada proceso también apunta a su propio proceso principal (el proceso principal puede ser el proceso creador, pero no siempre es así). Si el proceso principal ya no existe, esta información ya no se actualizará. Por lo tanto, es posible que un proceso apunte a un proceso principal inexistente. Pero esto no causará ningún problema, porque la operación de cualquier proceso no depende de si la información del proceso principal es válida o no. El explorador de procesos tiene en cuenta la hora de inicio del proceso principal para evitar que los procesos secundarios se adhieran a los ID de proceso reutilizados.

La mayoría de las herramientas no muestran el ID del proceso padre o creador del proceso. Podemos usar el Monitor de rendimiento para consultar el ID del proceso de creación para obtener esta información. Muestre el árbol de procesos mediante la herramienta Tlist.exe en Herramientas de depuración para Windows con el modificador /t. (Tlist.exe se cambió a TaskList (Tasklist.exe) en el nuevo Windows 10 y la opción .t ya no es compatible)

Aquí usamos el explorador de procesos en el paquete sysinternals proporcionado por MS para mostrar información de procesos más detallada. (Descripción y enlace de descarga de esta herramienta: https://learn.microsoft.com/zh-cn/sysinternals/downloads/ )

El explorador de procesos de sysinternals puede mostrar información de subprocesos y procesos más detallada que otras herramientas similares, y también puede mostrar o implementar algunas funciones únicas:

1. Procese tokens de seguridad, como listas de rentas y privilegios y estado de virtualización.
2. Resalte los cambios en las listas de procesos, subprocesos, DLL y identificadores.
3. Servicios Una lista de servicios dentro del proceso de hospedaje, incluidos el nombre para mostrar y la descripción del servicio.
4. Una lista de otros atributos del proceso, como la política de mitigación y el nivel de protección del proceso.
5. Procesos y detalles del trabajo incluidos en el trabajo.
6. El proceso que aloja la aplicación .NET y los detalles relacionados con .NET, como las listas de dominios de aplicaciones, los ensamblados cargados y los contadores de rendimiento de CLR.
7. El proceso que aloja Windows Runtime (el proceso inmersivo).
8. La hora de inicio de procesos y subprocesos.
9. Lista completa de archivos mapeados en memoria (no solo DLL).
10. La capacidad de suspender un proceso o subproceso.
11. La capacidad de terminar un hilo específico.
12. Identifique fácilmente los procesos que consumen la mayoría de los recursos de la CPU durante un período de tiempo.

Nota: El Monitor de rendimiento puede mostrar la utilización de la CPU para un conjunto específico de procesos, pero no puede mostrar automáticamente información sobre los procesos creados después de que se inició una sesión del Monitor de rendimiento, solo los formatos de salida binarios creados manualmente pueden contener dicha información.

Process Explorer también ayuda a los usuarios a acceder fácilmente a la siguiente información en un solo lugar:

1. Árbol de procesos con la capacidad de colapsar partes del árbol.
2. Abra identificadores en el proceso, incluidos los identificadores sin nombre.
3. Lista de DLLs en el proceso.
4. Actividad de subprocesos en el proceso.
5. Pilas de subprocesos en modo de usuario y en modo kernel, incluidos los nombres a los que se asignan las direcciones mediante Dbghelp.dll proporcionado por las herramientas de depuración para Windows.
6. Detalles del administrador de memoria, como confirmaciones de memoria máxima, límites de paginación de memoria del kernel y límites de grupo de memoria no paginada.

hilo

Un subproceso es una entidad dentro de un proceso que Windows programa para su ejecución. Sin hilos, el programa de un proceso no puede ejecutarse.

Un hilo consta de los siguientes elementos básicos:

1. Una lista de contenidos de registros de CPU que representan el estado del proceso.
2. Dos pilas: una para subprocesos que se ejecutan en modo kernel; la otra para subprocesos que se ejecutan en modo usuario.
3. Un área de almacenamiento privado denominada almacenamiento local de subprocesos que utilizan los subsistemas, las bibliotecas en tiempo de ejecución y las DLL. (almacenamiento local de subprocesos, TLS)
4. Un identificador único llamado ID de subproceso.

Además, los subprocesos a veces tienen su propio contexto de seguridad, también conocido como token, que las aplicaciones de servidor multiproceso utilizan principalmente para imitar el contexto de seguridad del cliente al que se sirve.

La combinación de registros volátiles y no volátiles y áreas de almacenamiento privado forman el contexto del hilo. Porque esta información es diferente en Windows que se ejecuta en computadoras con diferentes arquitecturas. Entonces, en esencia, esta estructura está relacionada con una arquitectura específica. La función GetThreadContext de Windows nos da acceso a esta información dependiente de la arquitectura (también conocida como bloque CONTEXT). Además, cada subproceso tiene su propia pila (señalada por la sección de registro de pila en el contexto del subproceso).

Cambiar el proceso de ejecución de un subproceso a otro requiere la participación del programador del kernel, lo que puede ser una operación costosa, especialmente cuando dos subprocesos deben cambiar entre sí con frecuencia.Para reducir la sobrecarga, Windows implementa dos mecanismos:

• fibra
• Subprocesos de programación en modo de usuario (UMS)

fibra

Las fibras permiten que las aplicaciones programen directamente la ejecución de sus propios subprocesos sin recurrir al mecanismo de programación basado en prioridades incorporado de Windows. Las fibras también se denominan comúnmente hilos ligeros. En términos de programación, las fibras son invisibles para el kernel porque las fibras se implementan en modo de usuario a través de Kernel32.dll. Para usar fibras, primero debe llamar a la función ConvertThreadToFiber de Windows, que convierte un hilo en una fibra en ejecución. La fibra recién convertida puede crear más fibras a través de la función CreateFiber. (Cada fibra puede tener su propio conjunto de fibras). Pero, a diferencia de los subprocesos, las fibras no pueden comenzar a ejecutarse hasta que se seleccionen manualmente llamando a la función SwitchToFiber. La fibra recién creada continuará ejecutándose hasta que salga o se vuelva a llamar a la función SwitchToFiber y se seleccione otra fibra para ejecutar. Los detalles sobre las funciones de fibra se pueden encontrar en la documentación del SDK de Windows.

Subprocesos de programación de modo de usuario

Disponible solo en Windows de 64 bits, los subprocesos de programación en modo de usuario (UMS) tienen un propósito básico similar al de las fibras, pero evitan la mayoría de las desventajas de las fibras. Los subprocesos de UMS tienen su propio estado de subproceso de kernel y, por lo tanto, son visibles para el kernel, por lo que varios subprocesos de UMS pueden emitir llamadas al sistema de bloqueo y compartir o competir por recursos. Alternativamente, cuando dos o más subprocesos UMS necesitan realizar operaciones en modo de usuario, también pueden cambiar periódicamente los contextos de ejecución (un subproceso otorga derechos de ejecución a otro subproceso), y este proceso se puede realizar en modo de usuario sin la participación del planificador. Desde el punto de vista del núcleo, el mismo subproceso del núcleo todavía se está ejecutando en este punto, nada ha cambiado. Cuando una operación realizada por un subproceso UMS necesita ingresar al kernel (como una llamada al sistema), puede cambiar a su propio subproceso de modo kernel dedicado (este proceso se denomina cambio de contexto dirigido, cambio de contexto dirigido). Aunque los subprocesos UMS simultáneos aún no pueden ejecutarse a través de múltiples procesos, se ajustan a un modo prioritario, por lo que no son completamente cooperativos.

Aunque los subprocesos tienen sus propios contextos de ejecución, e incluso cada subproceso en un proceso comparte el espacio de direcciones virtuales del proceso, todos los subprocesos en un proceso pueden leer y escribir acceso completo al espacio de direcciones virtuales del proceso. Sin embargo, un subproceso no puede hacer referencia inadvertidamente al espacio de direcciones de otro proceso, a menos que el otro proceso programe parte de su propio espacio de direcciones privado en un área de memoria compartida (llamado objeto de asignación de archivos en la API de Windows), o a menos que un proceso tenga permiso para abrir otro proceso para usar funciones de memoria entre procesos, como las funciones ReadProcessMemory y WriteProcessMemory (el proceso debe ejecutarse con la misma cuenta de usuario, no en un AppContainer u otro tipo de sandbox, y a menos que el proceso de destino tenga algún tipo de mecanismo de protección, es accesible por predeterminado).

Además de un espacio de direcciones privado y uno o más subprocesos, cada proceso también tiene su propio contexto de seguridad y una lista de identificadores abiertos para objetos del kernel, como objetos de sincronización, como archivos, áreas de memoria compartida, mutex, eventos y semáforos.

En la figura, VAD se refiere al descriptor de dirección virtual, que es una estructura de datos utilizada por el administrador de memoria para rastrear las direcciones virtuales utilizadas por los procesos.

El contexto de seguridad de cada proceso se almacena en un objeto llamado token de acceso. Un token de acceso de proceso contiene la identidad de seguridad y las credenciales de un proceso. De forma predeterminada, un subproceso no tiene su propio token de acceso, pero puede obtener un token que le permita suplantar el contexto de seguridad de otro proceso (incluido un proceso en un sistema Windows remoto) sin afectar a otros subprocesos en el proceso (más información sobre seguridad de procesos e subprocesos más adelante).

Operación

Windows proporciona una extensión del modelo de proceso denominada "trabajos". La función principal de un objeto de trabajo es administrar y operar un conjunto de recursos como un todo. Un objeto de trabajo se puede usar para controlar ciertas propiedades y colocar restricciones en uno o más procesos con los que está asociado un trabajo. Además, la información básica de la cuenta se puede registrar para todos los procesos asociados con el trabajo y para todos los procesos asociados con el trabajo pero terminados después de la asociación. Hasta cierto punto, el objeto de trabajo compensa la falta de Windows en el árbol de procesos estructurado y, en muchos casos, es más poderoso que el árbol de procesos como Unix.

Memoria virtual

Windows implementa un sistema de memoria virtual basado en un espacio de direcciones plano (lineal), para que cada proceso pueda "sentir" que puede obtener un espacio de direcciones privado enorme. La vista lógica que proporciona la memoria virtual para la memoria puede no ser coherente con el diseño físico. En tiempo de ejecución, el administrador de memoria puede (con la ayuda del hardware) traducir direcciones virtuales. Asigne inmediatamente a la dirección física donde se almacenan realmente los datos Al controlar el proceso de protección y asignación, el sistema operativo puede garantizar que los procesos no se afecten entre sí y no sobrescriban los datos del sistema operativo.

Dado que la cantidad de memoria física en la mayoría de los sistemas operativos es mucho menor que la cantidad total de memoria virtual requerida para que se ejecute un proceso, el administrador de memoria necesita convertir algunos contenidos de la memoria, es decir, paginarlos en el disco. La paginación de datos en el disco libera memoria física para que la utilicen otros procesos o el propio sistema operativo. Cuando un subproceso necesita acceder a una dirección virtual que está paginada en el disco, el administrador de memoria virtual vuelve a cargar la información relevante del disco a la memoria física.

No es necesario ajustar específicamente las aplicaciones para aprovechar los beneficios proporcionados por la paginación, porque el soporte de hardware permite que el administrador de memoria pague sin el conocimiento o la asistencia del proceso o subproceso. Entre la memoria virtual utilizada por los dos procesos, una parte todavía está mapeada en la memoria física (memoria física RAM) y la otra parte se ha paginado en el disco. Tenga en cuenta que los bloques contiguos de memoria virtual pueden asignarse a bloques no contiguos de memoria física. Estos bloques también se denominan páginas y el tamaño predeterminado de cada página es de 4 KB.

El tamaño del espacio de direcciones de la memoria virtual varía para cada plataforma de hardware. En un sistema X86 de 32 bits, el máximo teórico de la cantidad total de espacio de memoria virtual es de 4 GB. De forma predeterminada, Windows asigna la mitad inferior de este espacio de direcciones (de 0x00000000 a 0x7FFFFFFF) al proceso como almacenamiento privado exclusivo del proceso y la mitad superior (de 0x80000000 a 0xFFFFFFFF) como memoria protegida del sistema operativo. La mitad inferior de la asignación cambia para reflejar el espacio de direcciones virtuales del proceso que se está ejecutando actualmente, pero la mitad superior de la asignación (principalmente) siempre consta de la memoria virtual del sistema operativo. Las opciones de inicio compatibles con Windows, como el modificador de aumento de usuario en la base de datos de configuración de arranque, permiten que los procesos que ejecutan programas con etiquetas especiales usen hasta 3 GB de espacio de direcciones privadas, dejando solo 1 GB para el sistema operativo.Este enfoque permite que las aplicaciones, como los servidores de bases de datos, mantengan la mayor parte de su contenido en el espacio de direcciones del proceso, lo que reduce la necesidad de asignar un subconjunto de vistas de bases de datos al disco, lo que mejora el rendimiento operativo general.

En la siguiente figura se muestran dos diseños de espacio de direcciones virtuales típicos compatibles con Windows de 32 bits.

Aunque 3 GB de espacio de direcciones virtuales es mejor que 2 GB, aún no es suficiente para mapear bases de datos muy grandes. Para resolver este problema en los sistemas de 32 bits, Windows proporciona un mecanismo denominado Extensión de ventanas de direcciones (AWE), que permite que las aplicaciones de 32 bits asignen hasta 64 GB de memoria física y luego asigne vistas o ventanas a su propio espacio de direcciones virtuales de 2 GB. Aunque AWE transfiere la carga de administración de la relación de mapeo de memoria virtual a memoria física al desarrollador, cumple con la demanda de acceso directo a más memoria física, y el número específico incluso supera el límite superior que el espacio de direcciones de proceso de 32 bits puede acomodar al mismo tiempo.

Windows de 64 bits proporciona un espacio de direcciones más grande para los procesos porque las longitudes de direcciones de 64 bits pueden acceder hasta 2 a la potencia de 64 (16 EB, 1EB = 1024 PB, 1PB = 1024 TB, 1TB = 1024 GB).

modo kernel y modo usuario

Para evitar que las aplicaciones del usuario accedan o modifiquen datos importantes del sistema operativo, Windows utiliza dos modos de acceso al procesador (de hecho, el procesador que ejecuta Windows puede admitir más modos). Los dos modos son el modo de usuario y el modo kernel:

1. Modo de usuario: el código de la aplicación se ejecuta en modo de usuario.
2. Modo kernel: el código del sistema operativo se ejecuta en modo kernel. El modo kernel es el modo de ejecución del procesador que permite el acceso a toda la memoria del sistema y las instrucciones de la CPU.

Algunos procesadores usan términos como nivel de privilegio de código o nivel de anillo para distinguir entre diferentes modos. Pero también hay procesadores que usan un modo supervisor similar (modo supervisor) y un modo de aplicación para distinguir.

Si bien cada proceso de Windows tiene su propio espacio de memoria privado, el sistema operativo en modo kernel y el código del controlador del dispositivo comparten el mismo espacio de direcciones virtuales. Cada página en la memoria virtual tiene una etiqueta que indica qué modo de acceso debe usar el procesador para leer o escribir la página. Solo se puede acceder a la memoria en el espacio del sistema desde el modo kernel, mientras que se puede acceder a todas las páginas en el espacio de direcciones del usuario desde el modo usuario o el modo kernel.

Las páginas de solo lectura (páginas con datos estáticos) no se pueden escribir en ningún modo. Además, para los procesadores que admiten la protección de memoria no ejecutable, Windows marcará los datos contenidos en la página como no ejecutables, lo que evita que se ejecute código involuntario o malicioso en el área de datos (requiere que se active la prevención de ejecución de datos (prevención de ejecución de datos, DEP)).

Windows no brinda protección para la memoria privada del sistema de lectura/escritura utilizada por los componentes que se ejecutan en modo kernel. En otras palabras, una vez en modo kernel, tanto el sistema operativo como el código del controlador del dispositivo pueden acceder a toda la memoria del espacio del sistema y pueden eludir los mecanismos de seguridad de Windows para acceder a varios objetos. Debido a que el sistema operativo Windows tiene una gran cantidad de código que se ejecuta en modo kernel, los componentes que se ejecutan en modo kernel deben diseñarse y probarse cuidadosamente para garantizar que no violen los mecanismos de seguridad del sistema ni causen inestabilidad en el sistema.

Esta falta de protección también hace que sea necesario ser más cauteloso al cargar controladores de dispositivos de terceros, especialmente los controladores de dispositivos de terceros no contienen firmas digitales.Una vez que ingresa al modo kernel, el controlador puede acceder por completo a todos los datos del sistema operativo. Esta es también una de las razones por las que Windows 2000 comenzó a implementar el mecanismo de firma del controlador. (Además del mecanismo de firma, Windows proporciona un verificador de controladores para probar controladores y encontrar errores, que se explicarán más adelante, enlace: https://learn.microsoft.com/zh-cn/windows-hardware/drivers/devtest/devcon-examples#example-8-list-all-driver-files )

A través del monitor de rendimiento que viene con Windows 10, puede observar el cambio actual entre el modo kernel y el modo de usuario y la comparación que consume mucho tiempo.

hipervisor

En los últimos años se han producido cambios importantes en el modelo de desarrollo de aplicaciones y software, como la aparición de los servicios en la nube y la ubicuidad de los dispositivos del Internet de las Cosas. Estas nuevas tendencias empujan a los proveedores de sistemas operativos y hardware a encontrar formas de virtualizar los sistemas operativos invitados a través del hardware del host de una manera más eficiente.Por ejemplo, puede ser necesario alojar múltiples inquilinos a través de un servidor, ejecutar 100 sitios web aislados con un servidor e incluso permitir que los desarrolladores prueben docenas de sistemas operativos diferentes sin comprar hardware dedicado. Los usuarios plantearon mayores requisitos de velocidad, eficiencia y seguridad de la tecnología de virtualización, lo que a su vez dio origen a nuevos modelos informáticos y teorías de software. De hecho, parte del software actual, como Docker, es compatible con Windows 10 y Windows Server 2016, y puede ejecutarse en contenedores para obtener un entorno de máquina virtual totalmente aislado, ejecutando así la misma pila de aplicaciones o marco para realizar la innovación del modelo de máquina huésped/anfitrión.

Para proporcionar dichos servicios de virtualización, casi todas las soluciones modernas utilizan un hipervisor, un componente especial con muchos privilegios que virtualiza y aísla todos los recursos de una computadora, desde la memoria virtual y física hasta las interrupciones de dispositivos e incluso dispositivos PCI y USB. Hyper-V es uno de esos hipervisores, y la funcionalidad de cliente de Hyper-V en Windows 8.1 y versiones posteriores está habilitada por esta tecnología.

En Windows 10, Microsoft ofrece una serie de nuevos servicios para la seguridad basada en la virtualización (VBS) mediante el hipervisor Hyper-V:

1. Guardia del dispositivo. Via Hypervisor Code Integrity (HVCI) proporciona una garantía de firma de código más sólida que el uso de KMCS solo, y proporciona políticas de firma personalizadas para código de modo de usuario y modo kernel para sistemas operativos Windows.
2. Hiperguardia. Protege las estructuras de datos críticos y el código relacionado con el kernel y el hipervisor.
3. Credential Guard (protección de credenciales). Credenciales y secretos para evitar el acceso no autorizado a cuentas de dominio y se pueden usar junto con mecanismos de autenticación biométrica.
4. Guardia de aplicaciones. Proporciona un mecanismo de espacio aislado más sólido para el navegador Microsoft Edge.
5. Host Guardian y Shielded Fabric. Las máquinas virtuales se pueden proteger de las amenazas a la infraestructura con un TPM virtual (v-TPM).

firmware

Los componentes de Windows dependen cada vez más de la seguridad del sistema operativo y del kernel del sistema, que depende de la protección proporcionada por el hipervisor.

Esto crea un problema: luego asegúrese de que el componente del hipervisor se pueda cargar de manera segura y verifique su contenido. Por lo general, esto es responsabilidad del cargador de arranque, pero el cargador de arranque en sí necesita recibir el mismo nivel de comprobaciones de validación, lo que complica la relación de confianza entre los diferentes componentes.

Entonces, ¿cómo garantizar que el proceso de arranque sea confiable y no se vea afectado a través de la cadena raíz de confianza? En los sistemas Windows 8 y posteriores modernos, esto se logra a través del firmware del sistema, pero solo si se utiliza un sistema certificado basado en UEFI.

Como requisito de Windows y parte del estándar UEFI, el Arranque seguro debe proporcionar garantías y requisitos sólidos para la calidad firmada del software relacionado con el arranque. Este proceso de verificación garantiza que los componentes de Windows se carguen de forma segura desde el principio del proceso de arranque. Además, técnicas como la inyección del Módulo de plataforma segura (TPM) también pueden medir todo el proceso de arranque y proporcionar las pruebas correspondientes (pruebas locales o remotas).

Servicios de terminal y multisesión

Servicios de Terminal Server se refiere a la capacidad de Windows para brindar soporte para múltiples sesiones de usuario interactivas a través de un solo sistema. Los usuarios remotos pueden usar Servicios de Terminal Server de Windows para establecer sesiones en otras computadoras, iniciar sesión en el servidor y ejecutar aplicaciones. Luego, el servidor transmite una interfaz gráfica de usuario (GUI) al cliente, y el cliente envía la entrada del usuario al servidor. (Al igual que el sistema X Window, Windows permite cargar aplicaciones específicas en el sistema del servidor y la pantalla de visualización se envía de vuelta al cliente remoto, pero no es necesario transmitir todo el escritorio al extremo remoto)

La primera sesión suele ser la sesión de servicio, la sesión 0, que contiene el proceso de alojamiento del servicio del sistema. La primera sesión establecida en la computadora a través de un inicio de sesión físico en la consola es la Sesión 1, y las sesiones posteriores se conectan posteriormente a través del programa Conexión a escritorio remoto (Mstsc.exe) o Cambio rápido de usuario.

La versión del cliente de Windows permite que solo un usuario remoto se conecte a la computadora, y si alguien ya ha iniciado sesión en la consola en el momento de la conexión, la estación de trabajo está bloqueada. Es decir, la computadora utilizada para la conexión remota no puede admitir que varias personas la usen al mismo tiempo.

Los sistemas Windows Server admiten dos conexiones remotas simultáneas. Esto es para facilitar la administración remota; por ejemplo, es posible que las herramientas de administración utilizadas no requieran que los usuarios inicien sesión en la computadora que se administra. Se pueden admitir sesiones remotas adicionales si se cuentan con las licencias necesarias y se configuran como un servidor de terminal.

Objetos y manijas

En el sistema operativo Windows, un objeto del kernel hace referencia a una única instancia en tiempo de ejecución de un tipo de objeto definido estáticamente. Un tipo de objeto consta de un tipo de datos definido por el sistema, funciones que realizan operaciones en ese tipo de datos y un conjunto de propiedades de objeto.

Si necesita desarrollar aplicaciones de Windows, puede encontrar muchos conceptos, como procesos, subprocesos, archivos, objetos de eventos, etc. Estos objetos se basan en los objetos subyacentes creados y administrados por Windows. En Windows, un proceso es en realidad una instancia del tipo de objeto de proceso y un archivo es una instancia del tipo de objeto de archivo.

Las propiedades del objeto son campos de datos en un objeto que definen partes del estado del objeto. Por ejemplo, un objeto de tipo proceso contendrá el ID del proceso, la prioridad de programación base, el puntero para acceder al objeto del token, etc. a través de atributos. Los métodos de objeto son los medios por los cuales un objeto del sistema operativo se puede utilizar para leer o cambiar las propiedades del objeto. Por ejemplo, el método Open de un proceso puede aceptar un identificador de proceso como entrada y devolver un puntero a un objeto como salida.

La diferencia más esencial entre los objetos y los datos ordinarios es que la estructura interna de los objetos es opaca. Los servicios de objetos deben llamarse para obtener datos almacenados en el objeto o para colocar datos externos en el objeto, pero no pueden leer ni cambiar directamente los datos dentro del objeto. Esta diferencia separa efectivamente la implementación subyacente de los objetos del código que simplemente los usa, lo que permite un fácil acceso y cambios en la implementación del objeto en cualquier momento.

Con la ayuda del administrador de objetos, un componente del núcleo, los objetos tienen la capacidad de facilitar las siguientes cuatro tareas importantes del sistema operativo:

• Proporcione nombres legibles por humanos para los recursos del sistema
• Compartir recursos y datos entre procesos
• Proteja los recursos del acceso no autorizado
• Seguimiento de referencias, mediante el cual el sistema reconoce cuando un objeto ya no está en uso para que pueda ser liberado automáticamente.

No todas las estructuras de datos en el sistema operativo Windows son objetos. Solo los datos que deben compartirse, protegerse, nombrarse o ser visibles para los programas en modo usuario deben colocarse en objetos.

seguridad

Windows se ha diseñado pensando plenamente en la seguridad y puede cumplir con varios requisitos formales de calificación de seguridad del gobierno y la industria, como los criterios comunes para la especificación de evaluación de seguridad de tecnología de la información (CCITSE). Lograr una calificación de seguridad aprobada por el gobierno puede hacer que el sistema operativo sea más competitivo en el campo relevante. Por supuesto, muchas de estas características pueden beneficiar a cualquier sistema multiusuario:

Las principales características de seguridad de Windows incluyen lo siguiente:

1. Se proporciona discreción para todos los objetos del sistema que se pueden compartir, como archivos, directorios, procesos, subprocesos, etc., y se enfatiza la protección de la aplicación.
2. Realice auditorías de seguridad y rendición de cuentas para los principales o usuarios y las acciones que inician.
3. Autenticación de usuario al iniciar sesión.
4. Evite que los usuarios accedan sin autorización a los recursos que otros usuarios han desasignado, como la memoria o los discos libres.

Windows proporciona tres formas de control de acceso para objetos:

• Control de acceso discrecional. Este mecanismo de protección es lo primero en lo que piensa la mayoría de la gente cuando piensa en la seguridad del sistema operativo. De esta forma, el propietario de un objeto (como un archivo o una impresora) puede ejecutar o denegar el acceso a otros. Cuando un usuario inicia sesión, puede obtener una serie de credenciales de seguridad, también llamado contexto de seguridad. Cuando un usuario intenta acceder a un objeto, el sistema compara su contexto de seguridad con la lista de control de acceso deseada para determinar si el usuario está autorizado para realizar la operación solicitada. En Windows Server 2012 y Windows 8, este mecanismo de control discrecional se mejora aún más con el control de acceso basado en atributos (Control de acceso dinámico). Sin embargo, una lista de control de acceso para un recurso no tiene que identificar usuarios y grupos individuales, también puede identificar los atributos o notificaciones que se requieren para permitir el acceso al recurso, como "Nivel de permiso: Alto secreto" o "Antigüedad: 10 años". Al obtener automáticamente dichos atributos mediante el análisis de esquemas y bases de datos SQL con la ayuda de Active Directory, este modelo de seguridad más elegante y flexible puede liberar a las organizaciones del tedioso trabajo de administrar manualmente grupos y jerarquías de grupos.
• Control de acceso privilegiado. También es un mecanismo necesario cuando el control de acceso discrecional no puede satisfacer completamente las necesidades. Este enfoque garantiza que otros aún puedan acceder a los objetos protegidos cuando el propietario no está disponible. Por ejemplo, si un empleado deja la empresa y un administrador necesita una forma de acceder a un archivo al que anteriormente solo podía acceder ese empleado, el administrador puede tomar posesión del archivo en Windows y luego administrar el acceso al archivo según sea necesario.
• Mecanismo de integridad obligatorio. Este mecanismo es necesario cuando se requieren controles de seguridad adicionales para los objetos protegidos a los que accede la misma cuenta de usuario. Este mecanismo se usa en muchos lugares, como el mecanismo de espacio aislado proporcionado para las aplicaciones de Windows, el aislamiento proporcionado por Internet Explorer en modo protegido a través de la configuración del usuario y la protección de objetos creados por cuentas de administrador elevadas contra el acceso de cuentas de administrador no elevadas.

A partir de Windows 8, el sistema utilizará un espacio aislado llamado appcontainer para alojar aplicaciones de Windows.Esta tecnología puede aislar entre diferentes appcontainers y entre appcontainers y procesos de aplicaciones que no son de Windows. El código en un contenedor de aplicaciones puede comunicarse a través del intermediario y, a veces, con otros contenedores de aplicaciones o procesos, a través de contratos bien definidos proporcionados por Windows Runtime.

Varios mecanismos de seguridad están completamente integrados en la interfaz API de Windows. El subsistema de Windows implementa un modelo de seguridad basado en objetos de forma similar al sistema operativo:

• Establece el descriptor de seguridad de Windows para objetos compartidos de Windows para evitar el acceso no autorizado.
• Cuando una aplicación intenta acceder por primera vez a un objeto compartido, el subsistema de Windows verifica los permisos de la aplicación.
• Si pasan los controles de seguridad, el subsistema de Windows permite que la aplicación continúe accediendo.

formulario de inscripción

Cualquiera que haya usado el sistema operativo Windows debe haber oído hablar o incluso haber usado el registro. Cuando se trata de los principios internos de Windows, es inevitable mencionar el registro, porque la base de datos del sistema del registro contiene

• Información necesaria para automatizar y configurar el sistema
• Configuración de software a nivel del sistema que controla cómo se ejecuta Windows
• base de datos de seguridad
• Información de configuración del usuario, como el protector de pantalla utilizado

El registro también brinda acceso a datos volátiles en la memoria, como el estado actual del hardware del sistema (qué controladores de dispositivo están cargados, qué recursos utilizan los controladores). También hay contadores de rendimiento de Windows. Los contadores de rendimiento no se encuentran realmente en el registro, pero se puede acceder a los detalles de los contadores de rendimiento a través del registro.

Si bien muchos usuarios y administradores de Windows nunca tendrán que lidiar con el Registro directamente (porque la mayoría de las opciones de configuración se visualizan y modifican a través de herramientas administrativas estándar), el Registro sigue siendo una fuente útil de información sobre las funciones internas de Windows, que contiene muchas configuraciones que pueden afectar el rendimiento y el comportamiento del sistema. (La clave raíz de configuración a nivel del sistema HKEY_LOCAL_MACHINE del registro, denominada HKLM)

Unicode

Windows es una gran diferencia con la mayoría de los otros sistemas operativos: la mayoría de las cadenas de texto en Windows se almacenan y procesan como cadenas Unicode de 16 bits de ancho (técnicamente usando UTF-16LE). Unicode es un estándar internacional de conjuntos de caracteres que define valores únicos para la mayoría de los conjuntos de caracteres conocidos del mundo, proporcionando codificaciones de 8 bits, 16 bits o incluso 32 bits para cada carácter.

Debido a que muchas aplicaciones manejan cadenas ANSI de 8 bits (un byte), muchas funciones de Windows pueden aceptar parámetros de cadena a través de dos puntos de entrada:

• Una versión Unicode (caracteres de 16 bits de ancho)
• Una versión ANSI (carácter estrecho de 8 bits)

Si llama a versiones de caracteres estrechos de las funciones de Windows, puede haber un ligero impacto en el rendimiento porque los parámetros de cadena de entrada deben convertirse a caracteres Unicode antes de que el sistema pueda procesarlos, y los parámetros de salida se convierten de Unicode a ANSI para la salida a la aplicación. Por lo tanto, si necesita ejecutar versiones anteriores de servicios o códigos en Windows y los códigos relacionados están escritos en cadenas ANSI, Windows convertirá los caracteres ANSI a Unicode para su propio uso, pero Windows nunca convertirá los datos en el archivo Depende de la aplicación decidir si los datos deben almacenarse en Unicode o ANSI.

Abra Kernel32.DLL a través de la herramienta Dependency Walker y podrá ver las interfaces de funciones que contiene, incluidas las interfaces de funciones CreateFileA y CreateFileW, que son las interfaces de funciones emparejadas proporcionadas para diferentes tipos de cadenas.
(Enlace de descarga de la herramienta Dependency Walker: http://dependencywalker.com/ )

Resumir

Este artículo solo organiza y registra los principales conceptos y términos del sistema operativo Windows, para facilitar el aprendizaje posterior del kernel y los controladores de Windows. Al leer este artículo, puede tener una cierta comprensión y familiaridad con la estructura general del sistema operativo Windows y algunos términos profesionales, y los detalles específicos deben estudiarse y comprenderse en profundidad.