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:
- DosShutdown s¢lo cierra los archivos abiertos, vac¡a todos
los b£feres del sistema de archivos y desmonta todos los sistemas de archivos;
esto es lo que ocurre al pulsar Ctrl-Alt-Del. Los programas no se cierran
adecuadamente y no se salva el WPS.
- WinShutdownSystem sin embargo, es la API del Presentation
Manager que cierra todas las ventanas, salva el WPS y finalmente llama a
DosShutdown. Exactamente lo que ocurre en el procedimiento de
conclusi¢n del sistema al que est acostumbrado: esto es lo que se ejecuta
al seleccionar "Concluir" desde el men£ emergente del Escritorio o los
respectivos iconos de la Barra de Herramientas o el WarpCenter.
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:
- 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.)
- 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:
- Si seleccion¢ "Reiniciar el WPS", el hilo de cierre
simplemente ejecuta DosExit(EXIT_PROCESS, 0). Como XFolder es
parte del proceso del WPS, y todas las partes del WPS se ejecutan en este £nico
proceso (la segunda copia de PMSHELL.EXE), esto termina con todo
el Workplace Shell. El proceso de interfaz (Shell) del sistema (la primera
copia de PMSHELL.EXE) reinicia el WPS entonces de modo autom tico.
- Si seleccion¢ "Concluir" y "Reiniciar tras concluir",
Concluir eXtendido tambi‚n guarda los archivos INI en disco. Esto es necesario,
ya que DosShutdown, que es llamado despu‚s, tampoco los guarda.
(Supongo que esto es as¡ porque las APIs de los archivos INI pertenecen al
Presentation Manager.) Puesto que las APIs de archivos INI del PM prohiben
simplemente cerrar los perfiles de usuario y sistema (lo que escribe sus datos
en disco para todos los dem s perfiles), XFolder los copia en dos perfiles
temporales, borra los originales, y renombra los perfiles temporales con los
nombres de los originales.
Tras DosShutdown("Liberando sistemas de archivo..."), el sistema se
reinicia a trav‚s de una llamada al controlador DOS.SYS.
Esta funci¢n est documentada en EDM/2 vol. 5, issue 9.
- Si seleccion¢ "Concluir" y NO "Reiniciar tras concluir",
tras DosShutdown, Concluir eXtendido desactiva la lista de
ventanas y entonces simlemente bloquea el sistema llamando a DosEnterCritSec
y permaneciendo en un bucle infinito. Puesto que se han cerrado todos los sistemas
de archivos, no es posible ninguna acci¢n m s, salvo apagar el ordenador o
pulsar Ctrl-Alt-Del.