• Artículo

[Archivo de boletines ^][< Volumen 1, Número 2][Volumen 1, Número 4 >]

Boletín de Systems Internals Volumen 1, Número 3

http://www.sysinternals.com
Copyright (C) 1999 Mark Russinovich

19 de junio de 1999 - En este boletín:

  1. NOVEDADES DE SYSTEMS INTERNALS

    • SDelete v1.1
    • Strings v2.0
    • LoggedOn
    • Filemon v4.13
    • DebugView/EE v3.1
    • "Dentro de las redes NT"
    • "NT Internals" de junio
    • Estado de actualización de NTFrob
    • Cosas no tan nuevas

  2. NOTICIAS DE INTERNALS

    • Publicación de Numega DriverStudio
    • SDK de la plataforma de junio disponible
    • Protector de archivos del sistema (SFP) Win2K
    • Cerrar archivos abiertos desde la red

  3. PRÓXIMAMENTE

    • Una API de Win2K increíble

PATROCINADOR: WINTERNALS SOFTWARE

El Boletín de The Systems Internals está patrocinado por Winternals Software, en la Web en http://www.winternals.com. Winternals Software es el principal desarrollador y proveedor de herramientas avanzadas de sistemas para Windows NT/2K. Los productos de Winternals Software incluyen FAT32 para Windows NT 4.0, ERD Commander (funcionalidad de disco de arranque para Windows NT) y NTRecover.

Winternals Software anuncia el lanzamiento de las ediciones Regmon y Filemon Enterprise. Estas utilidades proporcionan toda la funcionalidad del software gratuito Filemon y Regmon, y agregan estas características eficaces:

  • ver la actividad del Registro y del sistema de archivos que tiene lugar en sistemas remotos de Win9x/NT
  • registrar la salida en un archivo en tiempo real
  • copiar las líneas de salida en el Portapapeles
  • resaltar las líneas que coincidan con un filtro
  • ver la salida de diferentes equipos simultáneamente
  • imprimir la salida directamente en una impresora
  • recuperar fácilmente las 5 últimas selecciones de filtro

Obtenga información sobre pedidos y precios en http://www.winternals.com.

Hola a todos:

Bienvenido a la tercera edición del boletín de Systems Internals. El boletín tiene actualmente 4400 suscriptores.

En el último boletín señalamos cómo Microsoft ha terminado con lo que se conocía como la pantalla azul de la muerte, en su avance a Windows 2000 (Win2K). La nueva pantalla azul Win2K no tiene la información de volcado de memoria de pila y controlador cargado que está presente en la pantalla azul de las versiones anteriores de Windows NT. Le pregunté si cree que la información que Microsoft ha quitado es útil y desearía más bien que hayan dejado las cosas como estaban. La respuesta fue prácticamente unánime, con cada uno de los encuestados (excepto uno) preguntándose por qué Microsoft se fue por el denominador común más bajo. Esta es una opinión típica, enviada por Tony Lavinio:

Así que, en otras palabras, esta es la respuesta del cliente en la que Microsoft está basando su decisión:

"No lo entiendo, así que debe ser malo; cámbienlo."

¿Por qué mejor no quitan toda la pantalla y ponen un mensaje que diga "Desconecte, vuelva a conectar y comience de nuevo? ¿Por qué están quitando una de las pocas pistas que tenemos para saber qué es lo que no está funcionando?

Al menos antes, si se trataba de la detección de un virus, un desfragmentador o un controlador de buggy, teníamos un punto de partida para empezar a buscar.

Si esta herramienta solo ayuda a 1 de nosotros entre 10 000, con la amplia base de implementación de NT, entonces sí vale la pena. Especialmente considerando que ese .01 % apoya a una buena parte del otro 99,99 %.

¿Quién fue el disidente solitario? No sería sorprendente que haya sido alguien de Microsoft encargado de llenar los informes de bloqueo de la pantalla azul. Esta es su enfoque con respecto al cambio, lo que confirma la especulación de Tony en cuanto a las razones para hacerlo:

Trabajo en el grupo de instalación de NT en PSS en MS (que controla la solución de problemas de la pantalla azul). Puedo asegurarle que la mayoría de las personas con las que hablo no saben qué hacer con la información de la pantalla azul 4.0. Estoy seguro de que si viera una parada 0xA con NAIFILTR.SYS en toda la pila, sabría que debe actualizar el antivirus, pero la mayoría de las personas no hacen esa conexión y realmente no se dan cuenta de que el código de parada y los parámetros les son útiles. Probablemente está decisión sea molesta para la gente que entiende cómo interpretar los datos de la pantalla azul, pero desafortunadamente representan una minoría.

Como dije en el último boletín, creo que Microsoft debería seguir adelante con la pantalla azul 4.0 de NT, manteniendo la lista del controlador cargado y el volcado de pila. También creo que podrían mejorar la pantalla azul si proporcionan más información, no menos. Por ejemplo, ¿por qué no mostrar el nombre del proceso que se estaba ejecutando al momento del bloqueo? O bien, ¿hay más llamadas a BugCheck que pasen la dirección del error y no solo la dirección que produjo un error? Una razón importante por la que PSS se encontró con tantos clientes que no saben de la pantalla azul es que Microsoft nunca escribió documentación sobre cómo leerla. Por lo tanto, Microsoft es en parte responsable de la ignorancia del usuario.

Si quiere saber más sobre cómo se producen las pantallas azules y qué hay en la pantalla azul (NT 4.), consulte mi artículo de diciembre de 1997, "Inside the Blue Screen", de Windows NT Magazine (puede acceder a la versión en línea desde http://www.sysinternals.com/publ.htm).

Como de costumbre, por favor pase el boletín de noticias a los amigos a quienes considere que podría interesarles.

Gracias

-Mark

NOVEDADES DE SYSTEMS INTERNALS

SDELETE V1.1

En el último boletín presenté SDelete, una utilidad de eliminación segura que puede usar para destruir irreversiblemente los datos de los archivos, así como para limpiar el espacio libre de un disco de los datos eliminados anteriormente. La primera versión de SDelete no podía sobrescribir de forma segura los nombres de los archivos que eliminaba. El nombre de un archivo a menudo revela información confidencial y el uso de SDelete para eliminar un archivo con un nombre revelador podía dejar esa información expuesta. Para solucionar este bucle, he actualizado SDelete para no solo sobrescribir de forma segura los datos de los archivos, sino también los nombres de archivo. SDelete elimina de forma segura un nombre de archivo al cambiar el nombre del archivo 26 veces, reemplazando cada letra del nombre del archivo por letras sucesivas del alfabeto, de la "A" a la "Z".

Descargue SDelete v1.1 con el código fuente completo en http://www.sysinternals.com/sdelete.htm.

STRINGS V2.0

Los archivos ejecutables y los archivos DLL suelen tener cadenas incrustadas en ellos que pueden revelar valores del Registro no documentados y mensajes de error que sugieren una funcionalidad no documentada. Desafortunadamente, la mayoría de los archivos DLL y EXE del sistema Windows NT/2K están escritos para que usen cadenas de caracteres Unicode, mientras que las herramientas tradicionales de búsqueda de cadenas como Grep solo extraen cadenas ASCII. Escribí la primera versión de la utilidad Strings hace unos años para examinar archivos binarios para cadenas de caracteres ASCII o Unicode. Lo he usado muchas veces en mis investigaciones internas de NT para ayudar a averiguar las cosas que Microsoft no documenta.

Sin embargo, las cadenas siempre tenían un error importante, que era su incapacidad de tomar una expresión comodín como especificador de archivo para que pudiera examinar varios archivos en una sola captura. Quería esta característica para que, dado el nombre de un valor del Registro, por ejemplo, pudiera determinar fácilmente qué archivos DLL del sistema hacen referencia a él.

Por último, he actualizado Strings para que tome los nombres de archivo comodín completos, así como para directorios de Recurse. Si especifica una expresión comodín, Strings prefija automáticamente las líneas de salida con el nombre del archivo en el que se encuentra una cadena, por lo que puede hacer algo parecido a esto:

strings *.dll | grep SafeBoot

Ver la salida de esta expresión (una versión de Grep está disponible en las utilidades Posix del Kit de recursos de Windows NT) le informa de qué archivos DLL del sistema comprueban la clave del Registro SafeBoot en Windows 2000. Las cadenas también son muy útiles para ver qué nuevos valores del Registro usan los archivos DLL del sistema Win2K, los controladores y los ejecutables. Por ejemplo, he usado Strings para comparar los valores del Registro a los que se hace referencia en la pila TCP/IP NT 4.0 SP4 (tcpip.sys) con aquellos a los que hace referencia la pila TCPIP de Windows 2000. Estos son aproximadamente la mitad de los valores que son nuevos en la pila TCPIP de Win2K (todos los cuales asumo que se encuentran en HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters):

ReservedPorts
DefaultGatewayMetric
InterfaceMetric
TempLeaseExpirationTime
TempIpAddress
TempMask
DhcpDefaultGateway
TcpWindowSize
TcpInitialRTT
TcpDelAckTicks
EnableTrafficControl
EnableTOSetting
MaxNormLookupMemory
MaxSendSegments
MaxFreeConnections
MaxFreeTWTcbs
FFPFastForwardingCacheSize

No esperaré a que Microsoft documente todos los nuevos parámetros de configuración de la pila.

Puede descargar Strings v2.0 en http://www.sysinternals.com/misc.htm.

LOGGEDON

¿Alguna vez ha querido saber quién ha iniciado sesión en un sistema NT remoto? Si es así, querrá descargar LoggedOn. LoggedOn es una utilidad sencilla que le indicará qué usuarios han iniciado sesión interactivamente en el equipo local o en uno remoto, así como qué usuarios han iniciado sesión a través de conexiones de recursos (por ejemplo, un recurso compartido de archivos o impresoras). Este es el ejemplo de salida de LoggedOn:

C:\>loggedon main

LoggedOn v1.0 - Logon Session Displayer
Copyright (C) 1999 Mark Russinovich
Systems Internals - http://www.sysinternals.com

Users logged on locally:
MAIN\Administrator

Users logged on via resource shares:
MAINDOM\MARK

Windows NT y Win2K no proporcionan una API que puedan usar las aplicaciones para determinar quién ha iniciado sesión en un equipo, pero LoggedOn lo determina examinando las claves del Registro que se cargan en el árbol del Registro de HKEY\USERS de un sistema. Los perfiles de cualquier usuario que haya iniciado sesión de forma interactiva se cargan en esta clave y los perfiles tienen nombres que identifican el SID (Id. de seguridad) de la cuenta de usuario asociada del perfil. Por ejemplo, si abre Regedit y busca en HKEY_USERS verá algo parecido a:

HKEY_USERS\.DEFAULT\S-1-5-21-734676951-386466661-1233803906-500

Aquí, solo un usuario ha iniciado sesión de forma interactiva. Puede saber si se trata del administrador de dominio o local porque el RID (Id. relativo) es 500, que es el RID que NT se reserva para las cuentas de administrador.

Mediante el uso de las API que permiten que un sistema examine el Registro de otro sistema, LoggedOn lee la clave HKEY_USERS de un equipo remoto y convierte los SID que encuentra en nombres de cuenta. Para determinar quién ha iniciado sesión mediante el recurso compartido, LoggedOn usa la API de NET, que se documenta en el SDK. La herramienta de línea de comandos de NET usa ampliamente la API de NET. Un efecto secundario al usar LoggedOn para acceder al Registro de un sistema remoto es que la cuenta en la que ejecuta LoggedOn siempre aparecerá con la sesión iniciada en un sistema remoto a través de un recurso compartido en la salida de LoggedOn.

Puede descargar LoggedOn con el código fuente completo en http://www.sysinternals.com/misc.htm.

FILEMON v4.13

Acaba de publicarse Filemon v4.13, una actualización que refleja los cambios en el controlador del archivador de Windows NT y corrige un error que introduje accidentalmente en el controlador 4.12. El controlador de filtro 4.13 tiene estos cambios:

  • usa el tipo de sincronización del Recurso para proteger algunas de sus estructuras de datos internas
  • controla el nuevo IRP de Win2K, IRP_MJ_PNP_POWER

El tipo de sincronización del Recurso está prácticamente sin documentar en los kits de desarrollo de controladores de dispositivos (DDK) de Windows NT 4.0 y Win2K. La Guía de diseño ni siquiera menciona los recursos, aunque sus funciones se documentan en la referencia de la sección "Rutinas de soporte ejecutivo". Los recursos son un mecanismo útil para proteger las estructuras de datos que pueden leerse simultáneamente por diferentes subprocesos, pero que requieren acceso exclusivo por un subproceso durante una actualización. Por lo tanto, son bloqueos de lector/escritor adquiridos para el acceso compartido por lectores y acceso exclusivo por escritores. Los controladores del sistema de archivos usan muchos recursos, por lo que sentí que era adecuado actualizar Filemon para usarlos cuando corresponda.

Filemon v4.13 también controla la nueva IRP, IRP_MJ_PNP_POWER, para que sea un controlador de filtro compatible con la alimentación y listo para usar cuando se ejecuta en Win2K. El único requisito de un controlador de filtro del sistema de archivos para controlar IRP de este tipo es pasarlos a los dispositivos del sistema de archivos a los que está asociado el filtro.

Puede descargar Filemon v4.13 con el código fuente completo en http://www.sysinternals.com/filemon.htm.

DEBUGVIEW/EE V3.1

DebugView/EE es un monitor de salida de depuración versátil que puede usar para capturar la salida de depuración local o remota generada por programas Win32 o controladores de dispositivos en modo kernel en Win95, Win98, WinNT y Win2K. Su utilidad es limitada en entornos en los que el usuario experimenta bloqueos mediante un controlador de dispositivo; sin embargo, toda la salida de depuración que DebugView capture antes del bloqueo se pierde. La versión más reciente de DebugView/EE soluciona este problema en Windows NT/2K. Si un usuario captura la salida del modo kernel generada por un controlador de dispositivo y el usuario ha configurado NT para guardar un volcado de memoria, DebugView/EE puede extraer la salida de depuración del archivo de volcado cuando se reinicia el sistema. Seleccione en el menú Editar|Procesar volcado de memoria de DebugView/EE para hacer que examine un volcado de memoria para la salida de depuración. Esta característica permite a los usuarios devolver un archivo de texto que contiene la salida de depuración que generó el controlador hasta el momento del bloqueo.

Descargue DebugView/EE v3.1 en http://www.sysinternals.com/debugview.htm.

"INSIDE NT NETWORKING"

Mi columna de marzo de 1999 para Windows NT Magazine "NT Internals" ya está en línea. Obtenga información sobre la arquitectura de red de NT de arriba abajo, incluidas las API que implementa, cómo las pilas de protocolos interactúan con las API y cómo los proveedores de hardware escriben controladores de red para que trabajen con los controladores de protocolo. Además, descubra algunas características nuevas de las redes de Win2K, incluida la compatibilidad con NDIS y ATM deserializadas.

Lea "Inside NT Networking" y otras columnas de NT Internals anteriores en línea en http://www.sysinternals.com/publ.htm.

"NT INTERNALS" DE JUNIO

La entrega de junio de mi columna para Windows NT Magazine es "Inside EFS, Part 1". En este artículo se describe la arquitectura del Sistema de cifrado de archivos (EFS) de Microsoft y se le guía por los pasos que sigue EFS cuando cifra un archivo. EFS proporciona una instalación de cifrado transparente para las unidades NTFS de Win2K y Microsoft la desarrolló específicamente para abordar la capacidad de nuestra herramienta NTFSDOS para leer archivos NTFS sin tener en cuenta su seguridad. Esta columna estará disponible en línea en tres meses.

Hace dos boletines, hablé sobre cómo las API de EFS necesarias para realizar copias de seguridad y restaurar archivos cifrados no están documentadas. Desafortunadamente, estas API siguen sin estar documentadas en la edición actual de MSDN. Sin embargo, se me ha informado de que Microsoft está enviando la documentación, que está marcada como "Confidencial de Microsoft", a sus asociados y proveedores de software de copia de seguridad. Además, David Golds, Administrador de programas de los sistemas de archivos en Microsoft, presentó una charla sobre las mejoras del sistema de archivos para Win2K en la reciente conferencia de Microsoft TechEd en Dallas. En la presentación, para las diapositivas que puede consultar en línea en http://www.teched99.com/slides/1-337.ppt, menciona que las API de copia de seguridad no están documentadas, pero que puede solicitarle directamente a él la documentación. Desafortunadamente, su dirección de correo electrónico no aparece en las diapositivas.

Visite http://www.winntmag.com para obtener información sobre la suscripción a Windows NT Magazine.

ESTADO DE ACTUALIZACIÓN DE NTFROB

NTFrob es una utilidad que publiqué hace un par de años que le permite configurar con precisión las longitudes cuánticas de los procesos en primer plano y en segundo plano en NT 4.0. NTFrob modifica las estructuras de datos internas en el kernel de NT, por lo que es muy específica del Service Pack. Desde el lanzamiento del Service Pack 5 de NT 4.0 me ha abrumado la cantidad consultas en las que me preguntan cuándo voy a publicar NTFrob v1.5, la actualización para el SP5. La respuesta es que la actualización está próxima: estoy esperando a que Microsoft proporcione a los suscriptores de MSDN el SP5, incluida la información de depuración. Necesito la información de depuración para actualizar NTFrob para los nuevos Service Packs.

Puede descargar NTFrob para NT 4 SP0-4 en http://www.sysinternals.com/ntfrob.htm.

COSAS NO TAN NUEVAS

Hace unos meses he lanzado un monitor de puerto paralelo y de serie Win9x/NT/2K en Systems Internals. Portmon permite ver exactamente cómo interactúan las aplicaciones con puertos en serie y paralelos, incluidos los datos que envían y reciben. Puede usarlo para observar las sesiones de acceso telefónico, las conexiones de serie de laplink o la actividad de la impresora. Portmon ha sido un gran éxito y recientemente obtuvo 5 estrellas de la Biblioteca de software de Ziff-Davis, la clasificación más alta posible. Otras herramientas de Systems Internals que han ganado 5 estrellas incluyen Regmon, NTFSDOS y BlueSave.

Descargue Portmon en http://www.sysinternals.com/portmon.htm.

NOTICIAS DE INTERNALS

PUBLICACIÓN DE DRIVERSTUDIO

NuMega Labs de CompuWare ha lanzado DriverStudio, un kit de herramientas completo para desarrolladores de controladores de dispositivos Windows 9x/NT/2K. Incluye SoftICE 4.0, BoundsChecker para Drivers, VtoolsD, DriverAgent, DriverWorks, FieldAgent para Drivers y, en el futuro, agregará TrueTime para Drivers y TrueCoverage para Drivers. Como dije en el último boletín, este es un kit de herramientas indispensable para los desarrolladores. NuMega también ha lanzado un sitio web orientado al desarrollador de controladores de dispositivos denominado "Driver Central" - http://www.numega.com/drivercentral/default.asp.

PUBLICACIÓN DEL SDK DE LA PLATAFORMA DE JUNIO

Ahora puede descargar la versión de junio del SDK de la plataforma de Microsoft en http://www.msdn.microsoft.com/developer/sdk/platform.asp.

PROTECTOR DE ARCHIVOS DEL SISTEMA (SFP) DE WIN2K

Una de las mayores quejas de los administradores de sistemas NT y los usuarios es el "infierno DLL" de NT. El infierno DLL es el resultado de muchas aplicaciones que actualizan archivos DLL del sistema de claves con versiones del conjunto de productos. Las aplicaciones normalmente hacen esto para poder garantizar el funcionamiento correcto, sin embargo, cuando reemplazan un archivo DLL, muchas veces interrumpen otras aplicaciones mediante la instalación de versiones incompatibles o incluso "actualizan" un archivo DLL a una versión anterior.

Microsoft ha solucionado los problemas de control de versiones de DLL en Win2K con la introducción del Protector de archivos del sistema (SFP). En realidad, su nombre cambiará pronto a Protector de archivos de Windows (WFP), pero hasta la versión Beta 3 (compilación 2031) sigue siendo SFP. SFP se implementa en un archivo DLL denominado sfc.dll que el proceso de Winlogon (winlogon.exe) carga cuando se inicia el sistema. SFP incluye una lista integrada de aproximadamente 3000 archivos DLL del sistema Win2K estándar, ejecutables (.exe), archivos de instalación (.inf), controladores (.sys) y archivos de fuentes (.fon) que se instalan en 30 a 40 directorios diferentes. Cuando SFP inicializa, ejecuta una operación de directorio de cambio o notificación en cada directorio que contenga los archivos que protege. Cuando detecta alteraciones con un archivo, aparece un cuadro de diálogo que informa al usuario actual, escribe un evento en el registro de eventos y reemplaza el archivo modificado por una copia de seguridad almacenada en %systemroot%\system32\dllcache. Si falta el archivo de copia de seguridad que busca SFP en dllcache o también se ha alterado, SFP recupera una nueva copia del medio de instalación de Win2K.

Para ver qué archivos protege SFP, puede usar la utilidad Strings mencionada en otro lugar de este boletín para volcar los nombres de cadena Unicode incrustados en %systemroot%\system32\sfc.dll.

Las únicas utilidades que pueden actualizar los archivos del sistema son hotfix.exe, los Service Packs (update.exe), las instalaciones de actualización y el servicio de actualización de Win2K. ¿Cómo omiten estas herramientas el SFP? Lo deshabilitan temporalmente llamando a la función exportada sfc.dll SfcTerminateWatcherThread y garantizan que refleje las actualizaciones en el subdirectorio dllcache. Debe tener en cuenta que Win2K requiere que Microsoft firme digitalmente todos los archivos del sistema, por lo que generalmente no es posible actualizar un archivo del sistema con una versión arbitraria propia.

Los programas Win32 pueden observar los cambios en un directorio mediante las API FindFirstChangeNotification y FindNextChangeNotification de Win32. Sin embargo, estas API simplemente informan a una aplicación de que algo ha cambiado, pero no le indican a la aplicación qué es exactamente lo que ha cambiado. Por lo tanto, se requiere una aplicación para examinar un directorio completo y determinar qué archivos o subdirectorios pueden haber cambiado. SFP usa la API nativa de NT para realizar una solicitud de notificación de cambio en la que NT le indica exactamente qué archivos o subdirectorios cambian en los directorios supervisados. La función que usa SFP se denomina NtNotifyChangeDirectoryFile y, al igual que el 90 % de la API nativa de NT, no está documentada. Busque un applet en Systems Internals en un futuro próximo que muestra cómo usar NtNotifyChangeDirectoryFile.

Mi columna "NT Internals" de septiembre, "Inside Win2K Reliability Enhancements, Part 2" describe SFP con más detalle.

CIERRE DE ARCHIVOS ABIERTOS DESDE LA RED

Una de las preguntas más frecuentes que recibo de los visitantes de Systems Internals es "¿Cómo puedo cerrar archivos que los usuarios han abierto desde la red?" Si un usuario tiene un archivo o directorio abierto de forma remota, no es posible eliminar, cambiar el nombre o actualizar el archivo o directorio localmente. Una pregunta similar es: "¿Cómo puedo ver qué archivos han abierto los usuarios desde la red?" Ambas preguntas se responden con la utilidad de línea de comandos Net que viene con Windows NT/2K. Para ver qué archivos se abren simplemente escriba "net file". Obtendrá una lista de nombres de los archivos abiertos, los identificadores de nombre de archivo correspondientes y los nombres de los usuarios que tienen archivos abiertos. Para cerrar uno de los archivos que ve abierto, escriba net file <id> /close. Para ver los archivos abiertos localmente, puede usar las herramientas NTHandle o HandleEx.

Las API que subyacen a la funcionalidad de visualización y cierre de archivos del comando de Net se documentan en el SDK de la plataforma y en la biblioteca MSDN. Use la API NetFileEnum para enumerar los archivos abiertos y la API NetFileClose para cerrar un archivo abierto. Las API permiten enumerar los archivos abiertos en servidores remotos, algo que el comando Net no permite.

NTHandle está disponible en http://www.sysinternals.com/nthandle.htm. HandleEx está disponible en http://www.sysinternals.com/handleex.htm.

PRÓXIMAMENTE

UNA API DE WIN2K INCREÍBLE

Win2K presenta una nueva API denominada AWE (Extensiones de ventana de direcciones) que las aplicaciones que consumen mucha memoria pueden usar para acceder directamente y administrar grandes cantidades físicas de RAM, incluso de más de 3 GB, el límite superior de RAM que una aplicación de Windows NT puede abordar en su espacio de direcciones virtuales. De hecho, si un sistema x86 tiene PSE (extensiones de tamaño de página) y más de 4 GB de RAM, la aplicación puede usar AWE para aprovechar toda la memoria del equipo. Por lo tanto, esta API es ideal para aplicaciones que demandan memoria, como servidores web y servidores de bases de datos. La próxima vez le diré cómo usar las API, tanto desde aplicaciones Win32 como desde controladores de dispositivo.

Mientras estoy en el tema de las aplicaciones que demandan memoria: esta es una sugerencia para cualquier persona que escriba una aplicación que almacene en caché los archivos (como un servidor web). El Administrador de caché de Windows NT divide su memoria caché en ranuras de 256 KB denominadas "vistas". Si un archivo con un tamaño inferior a 256 KB se almacena en caché, el Administrador de caché debe seguir asignando al archivo una ranura completa de 256 KB, lo que significa que se desperdicia parte de la memoria virtual de la memoria caché. Por lo tanto, generalmente es más eficaz en cuanto a rendimiento almacenar en caché los archivos de menos de 256 KB de tamaño en la memoria virtual de su propia aplicación y confiar en el sistema de archivos para que almacene en caché los archivos de más de 256 KB de tamaño. IIS 5.0 usa este truco.

Gracias por leer el Boletín de Systems Internals.

Publicado el sábado, 19 de junio de 1999. 7:14 pm por ottoh

[Archivo de boletines ^][< Volumen 1, Número 2][Volumen 1, Número 4 >]