Alcances y Limitaciones

En esta parte del manual se da a conocer las futuras versiones de los sistemas operativos de Microsoft sus alcances y las limitantes que tendrán cada uno de los sistemas esperando que los usuarios tengan una visión a futuro de las opciones que habrá en el mercado y elijan la mejor opción que cubra sus necesidades

Alcances.

Windows "Longhorn" Server.

Windows "Longhorn" Server es el nombre en clave dado por Microsoft para los futuros sistemas operativos de servidores. Será el sucesor de Windows Server 2003, y posiblemente sea llamado Windows Server 2007 - Se sabe que Microsoft intenta mantener la forma de llamar a sus productos para servidores por el año, y la fecha de salida estimada para Longhorn Server es 2007.

Longhorn Server será el equivalente en servidores a Windows Vista (anteriormente también conocido con el nombre en clave "Longhorn"), y seguramente compartan muchas de las mismas funciones, como también otras especiales para usuarios de alto nivel. Se espera que Windows Server 2007 use WinFS, un subsistema de almacenamiento de Windows que fue eliminado de Windows Vista por las presiones del tiempo y que seguramente sea incorporado como una parte de Windows Vista Service Pack 1. Es una relación similar a la establecida entre Windows XP y Windows Server 2003 (nombres en clave "Whistler" y "Whistler Server", respectivamente).
Microsoft anunció el lanzamiento de la versión Beta 1 del Servidor Longhorn el 27 de julio de 2005.

Windows "Vienna".

Windows "Vienna" (antes conocido como Blackcomb) es el nombre en clave de Microsoft para el sucesor de Microsoft Windows Vista y su "Servidor Longhorn", originalmente anunciado en febrero del año 2000, pero desde entonces ha sido retrasado y replanificado.

El nombre en clave "Blackcomb" originalmente fue asignado a una versión de Windows que se planeó que sucediera a Windows XP (nombre en clave "Whistler"; ambos llamados así después del informe Whistler-Blackcomb) en las versiones cliente y servidora. A pesar de esto, en agosto de 2001, el lanzamiento de Blackcomb fue retrasado muchos años y Vista (originalmente llamado en clave "Longhorn", después del informe Whistler-Blackcomb) fue anunciado como un producto intermedio. Desde entonces, el estado de Vienna ha sufrido muchas alteraciones y manipulaciones de las versiones previas y parece que el desarrollo de Vienna será deshechado completamente, para convertirse en una versión sólo para servidores. La verdad es que parece que Vienna todavía está planeado como una versión para cliente y servidor, con fecha de lanzamiento para el 2011 (aunque no se ha publicado ninguna fecha firme del lanzamiento todavía).


Limitaciones.

• No se admite la creación de subprocesos.

• Win32s utiliza el mecanismo nonpreemptive de programación de versión 3.1 de Windows.

• Los procesos de 32 bits se deberían iniciar desde una aplicación de 16 bits a través de 4b WinExec() o Int 21. LoadModule() no inicia un proceso de 32 bits.

• Las aplicaciones Win32-based no pueden usar el EM_SETHANDLE o los mensajes EM_GETHANDLE para tener acceso al texto en un MultiLine editan control. Estos mensajes permiten que comparta identificadores de memoria local entre una aplicación y un USER.EXE. En Win32s, el montón local de una aplicación es 32 bits conque User.exe no puede interpretar un identificador local. Para leer y escribir texto de control de edición de multilínea, una aplicación debería utilizar WM_GETTEXT y WM_SETTEXT. El texto para controles de edición de multilínea se almacena en el montón local de 16 bits en DGROUP asignado por Windows versión 3.1 del código auxiliar cargado Win32s.exe antes de que se cargue cada aplicación basada en Win32. Esto significa que el tamaño de texto de control de edición está limitado a algo menos 64 K.

• Los procesadores de enlace CBT no copian de nuevo los contenidos de estructuras conque se pierde todo el cambio.

• Las aplicaciones Win32-based no deberían llamar a través del retorno de SetWindowsHook(). SetWindowsHook() devuelve un puntero al enlace siguiente de la cadena. Para llamar a esta función, la aplicación debería llamar a DefHookProc() y pasar un puntero a una variable para que dónde se almacene esta dirección. Puesto que Win32s simula el enlace antiguo API en cuanto a lo nuevo, SetWindowsHook() pasa de nuevo realmente un identificador de enlace, no un puntero a función.

• El entero de recurso identificador debe ser valores de 16 bits.

• PostMessage() y PeekMessage() no hacen estructuras de procesador. Estas funciones no asignan espacio al repack estructuras porque no hay forma de conocer cuándo que libera el espacio.

• Los mensajes de aplicación privada no deberían utilizar la palabra alta de wParam. Win32s utiliza Windows para entregar mensajes de ventana. Para mensajes desconocidos, wParam se trunca para realizar caber en 16-bits. Por lo tanto, las aplicaciones basadas en Win32 no deberían colocar cantidades de 32 bits en el wParam de mensajes privately-defined desconocidos a la capa de procesador.

• Después de llamar a FindText(), una aplicación no puede tener acceso directo a la estructura FINDREPLACE. Cuando una aplicación llama a la función común de diálogo FindText(), pasa una estructura FINDREPLACE. El cuadro de diálogo FindText() se comunica con la ventana propietaria mediante un mensaje registrado en el que señala el lParam a la estructura. Los procesadores repack esta estructura en lugar para que a menos que la aplicación procese el mensaje registrado, no debería utilizar la estructura tratando.

• Crear subclase de una ventana que posee unos cuadros de diálogo comunes FindText() no funciona. El procesador FindText() repack la estructura FINDREPLACE en lugar. Esto significa que no pueden propietarios de subclase de cuadros de diálogo FindText() sin cuatro bytes probables del final de la estructura que desechan de 16 bits procedimientos de ventana de 32 bits porque el FINDREPLACE de 32 bits es más grande cuatro bytes que la versión de 16 bits. Para propietarios de 32 bits del cuadro de diálogo, también hay problemas. Siempre que el código de 16 bits podría hacer referencia a la estructura, debe estar en el formato de 16 bits. Cuando finaliza el cuadro de diálogo FindText(), la estructura debe estar sin embargo en formato de 32 bits para que la aplicación pueda leer los valores finales. Se indica a su propietario acerca de el que está el cuadro de diálogo se destruye enviando que se estableció el mensaje commdlg_FindReplace con el FR_DIALOGTERM mordido en el campo Indicador de la estructura FINDREPLACE. Después de enviar este mensaje, el cuadro de diálogo FindText() ya no hace referencia a la estructura conque el procesador commdlg_FindReplace lo deja en formato de 32 bits. El problema se produce cuando se ha creado la subclase del propietario. Una vez que el mensaje se haya movido al lado de 32 bits, la estructura no se reconvertirá a 16-bits. Suponga que la subclase del propietario de cuadros de diálogo fue creada por un procedimiento de ventana de 16 bits para el que creó una subclase un procedimiento de ventana de 32 bits a vez. Cuando se envía un mensaje al propietario, primero irá a 32 bits, 16-bits entonces de nuevo 32 bits al procedimiento original de ventana:

1. 16 -> 32 mensaje enviado a subclasser de 32 bits (estructura repack a 32 bits)

2. 32 -> 16 mensaje enviado a subclasser de 16 bits (estructura no repack)

3. 16 -> 32 mensaje enviado a WndProc original de 32 bits (estructura no repack)

El subclasser de 16 bits no puede interpretar los parámetros message ya que están en formato de 32 bits. Entre pasos 2 y 3, la estructura no es repack porque está ya en formato de 32 bits.