Esta funci¢n me ha exigido pensar mucho, porque realmente no hay documentaci¢n en ninguna parte sobre lo que ocurre durante el proceso normal de conclusi¢n del sistema.

OS/2 por omisi¢n conoce dos APIs diferentes de conclusi¢n:

El problema es que no hay ninguna funci¢n "a medio camino" entre estas dos. Si se llama a DosShutdown no se salvan los datos del WPS. Y si se llama a WinShutdownSystem se obtiene el procedimiento habitual de conclusi¢n sin m s posibilidad de intervenir. De modo que, b sicamente, tuve que programar un WinShutdownSystem completamente nuevo, que paso a explicar a continuaci¢n. Esto fue bastante dif¡cil, porque IBM no explica casi nada de lo que realmente sucede durante WinShutdownSystem.

Nota: en XFolder, las rutinas "Concluir eXtendido" y "Reiniciar el WPS" comparten el mismo c¢digo; s¢lo difieren en lo que ocurre despu‚s de que se cierren todas las ventanas. Por tanto, utilizar‚ el t‚rmino "Concluir eXtendido" en las siguientes explicaciones para ambas funciones indistintamente, salvo que indique lo contrario.

Concluir eXtendido est  integrado en el WPS y se apoya fuertemente en las sustituciones de clases de XFolder. No he puesto el c¢digo de Concluir eXtendido en un archivo .EXE aparte de modo intencionado, por dos razones: primera, Concluir eXtendido necesita acceder a datos internos del WPS, que s¢lo est n disponibles en el contexto del SOM; segunda, quiero evitar que la gente intente utilizar Concluir eXtendido de forma separada, porque podr¡a da¤ar gravemente el WPS. Con m s detalle, Concluir eXtendido se apoya en la sustituci¢n de la clase XFldObject y en el hilo de trabajo de XFolder, que cooperan para mantener la pista de los datos internos del WPS.

Para entender lo que Concluir eXtendido hace ahora, es necesario comprender c¢mo maneja el WPS sus objetos internamente. Cada objeto que es relevante para el WPS en alg£n punto, ya sea al poblar una carpeta, al pedir sus caracter¡sticas, iniciar un programa o cualquier otra cosa es -- en la terminolog¡a del WPS -- "despertado" por el sistema, lo que significa que existe en memoria como un objeto del SOM.

S¢lo muy raramente el WPS pone otra vez "a dormir" ning£n objeto, lo que liberar¡a la memoria asociada y almacenar¡a los datos del objeto en disco. Esto tiene dos consecuencias:

  1. Siempre hay muchos m s objetos despiertos en el sistema de lo que ud. podr¡a pensar, porque la mayor¡a de ellos no son visibles. Incluso despu‚s de cerrar una carpeta abierta, los objetos de su interior permanecen despiertos; esto acelera el proceso de repoblaci¢n de la carpeta cuando se abre por segunda vez. Como resultado, sin embargo, el WPS consume m s y m s memoria con cada carpeta que abra. (Si ha activado el archivo de registro de Concluir eXtendido, podr  ud. ver cu ntos objetos despiertos salva el Concluir eXtendido; normalmente son varios cientos de objetos, a£n cuando el Concluir eXtendido no guarda todos los objetos despiertos, sino s¢lo los descendientes de WPFolder y WPAbstract. En la p gina "Propiedades internas" del cuaderno de propiedades del escritorio puede ver cu ntos objetos despiertos hay en este momento.)
  2. A veces, un cambio en los datos del objeto s¢lo tiene efecto en el objeto SOM en memoria, pero no se guarda siempre en disco o los archivos OS2.INI / OS2SYS.INI. ste es el motivo por el cual a veces el WPS tiene problemas si se hacen cambios muy extensos, como mover una carpeta con muchos objetos abstractos, y no se concluye adecuadamente: los datos f¡sicos en disco y el registro que el WPS mantiene de ellos no coinciden.
Para esto es para lo que Concluir eXtendido necesita la clase XFldObject, que sustituye a WPObject. Cada vez que se despierta un objeto, el WPS llama varios m‚todos (entre ellos wpInitData y wpObjectReady). XFldObject se sobrepone a ‚stos y pasa la direcci¢n del objeto en memoria al hilo de traabjo de XFolder que actualiza adecuadamente una lista interna de XFolder de todos los objetos despiertos actualmente. Hasta donde s‚, no hay ning£n otro sistema para averiguar qu‚objetos est n despiertos actualmente; al menos no hay una API documentada que permita enumerarlos.

Ahora, una vez que se ha iniciado y confirmado Concluir eXtendido , ‚ste inicia dos hilos para el siguiente procedimiento de conclusi¢n, que se ejecutan de modo paralelo a los hilos comunes del WPS: el "hilo de cierre" principal, con la cola de mensajes para la ventana de estado, y el "hilo de actualizaci¢n", que supervisa la lista de ventanas de OS/2 y env¡a mensajes al hilo de cierre principal si hay que actualizar la ventana de estado. De modo que cerrar todas las ventanas abiertas actualmente es un proceso bastante complejo de interacci¢n entre estos dos hilos: el hilo de cierre cierra una ventana y se duerme hasta que el hilo de actualizaci¢n detecta un cambio en la lista de ventanas (lo que significa que la ventana se ha cerrado con ‚xito) y env¡a un mensaje de vuelta al hilo de cierre, que se encarga de cerrar la siguiente ventana, hasta que se han cerrado todas las ventanas.

Cuando se han cerrado todas las ventanas, el hilo de actualizaci¢n finaliza y se sale. Ahora el hilo de cierre recorre la lista de objetos despiertos actualmente (la cual se describi¢ antes) y fuerza que se salven sus datos a disco llamando al m‚todo wpSaveImmediate de cada objeto. sto s¢lo se hace con los descendientes de WPAbstract y WPFolder, porque seg£n mi experiencia, todas las otras clases salvan sus datos de forma sincronizada. (Intent‚ guardar todos los descendientes de WPFileSystem una vez, y esto provoc¢ que se crearan un mont¢n de atributos extendidos para cada archivo que el WPS hab¡a despertado. Adem s, el proceso de conclusi¢n se hizo eterno.)

Finalmente, dependiendo de qu‚ se deseara, el hilo de cierre realiza una de las siguientes acciones: