Foto mía actual con una camiseta de Windows 95.
Quizás no crea en la reencarnación de las máquinas, pero sí que una camiseta puede durar, con un poco de cuidado, más que un sistema operativo.
Windows 95, Windows 98, Windows Me, Windows 2000, Windows XP, XP Sp1 y SP2, Vista y yo sigo con la misma camiseta … aunque no con el mismo pelo.
Está visto que el verano recalienta las neuronas (a pesar del mal tiempo que hace en el norte), y uno no puede ya escribir seriamente.
Estaba yo en uno de esos trabajos inspirados en «Los 12 trabajos de Hércules» que me tocan realizar antes de coger vacaciones, cuando me encontré intentando ejecutar en Vista 64bits aplicaciones de 32 bits creadas en Visual Basic 6, y me encontré con algunos problemas para hacerlos funcionar.
Al final conseguí que funcionaran y mientras miraba en Internet intentando buscar solución a los diversos problemas, me encontré con algunos artículos que me enseñaron algunos conceptos que no sabía sobre la manera en que un sistema Windows de 64 bits conseguía que funcionaran en él aplicaciones de 32 bits.
Supongo que la mayor parte de los lectores ya conocerán el funcionamiento de la emulación, pero no me resisto aquí a traducir unos artículos que explican muy bien cómo funciona:
«Las versiones x64 de Windows (entre ellas la reciente de Windows Vista 64 bits) no son capaces de ejecutar código de 32 bits de forma nativa. Como hoy en día la mayor parte de las aplicaciones siguen siendo de 32 bits, las versiones x64 de Windows hacen uso de un emulador conocido como WOW64 para permitir que las aplicaciones de 32 bits funcionen en ellas.
Uno de los problemas con el funcionamiento de código de 32 bits en un sistema operativo de 64 bits es que el OS debe mantener una separación completa del código. Microsoft ha creado una carpeta nueva llamada WindowsSysWOW64 que se utiliza para almacenar las DLL y componentes de 32bits. En las versiones de 32 bits de Windows, los archivos DLL se almacenan normalmente en la carpeta WindowsSystem32. Sin embargo, en las versiones de 64 bits de Windows se utiliza la carpeta WindowsSystem32 para las DLL de 64bits.
Como se puede ver, el emulador WOW64 debe realizar el cambio de dirección del sistema de ficheros para garantizar que el código de 32 y 64 bits siga separado. Pero mantener archivos del DLL separados es solamente el principio. El emulador WOW64 realiza el cambio de dirección del sistema de ficheros para varios componentes clave del sistema operativo de Windows.
Otro lugar en Windows en donde se utiliza el cambio de dirección del sistema de ficheros es en la carpeta de archivos de programa. Casi todas las aplicaciones instaladas copian sus archivos a la carpeta “C:Program Files” dentro de una carpeta propia para la aplicación. En las versiones x64 de Windows, las aplicaciones de 64 bits están instaladas en la carpeta “C:Program Files” y las aplicaciones de 32 bits están instaladas en una carpeta nombrada “C:Program Files (x86)”.
Sin embargo, la carpeta de archivos de programa puede no estar siempre en el mismo lugar en cada microordenador. Por ello, la mayoría de los desarrolladores no hacen referencia dentro sus programas directamente a “C:Program Files” sino que llaman a funciones para obtener el nombre real de esta carpeta en el PC en cuestión.
En las versiones de 32 bits de Windows, la función SHGetSpecialFolder() se utiliza para determinar el nombre y la localización de la carpeta de archivos de programa. Pero en la versión de un S.O. x64, la función mira si la aplicación funciona a 32 bits o a 64 y realiza el cambio de dirección de la carpeta apuntando a la adecuada.
La instalación de una aplicación no es la única vez que se hace referencia a la carpeta de archivos de programa; puede también ser referenciada en el tiempo de ejecución. Aunque hay varias maneras que una aplicación pueda determinar el nombre y la localización de la carpeta de archivos de programa, el empleo de las variables de entorno es lo más utilizado. En una versión de 32 bits de Windows, la variable de entorno %ProgramFiles% contiene la trayectoria a la carpeta de archivos de programa. En una versión x64 de Windows, esta variable de entorno también se utiliza, pero trabaja de una forma diferente.
La regla más importante de la plataforma x64 es que no puedes mezclar de ninguna manera código de 64 y 32 bits. Las variables de entorno se llaman a menudo dentro de ficheros de comandos por lotes (.CMD o .BAT) o por scripts. Siendo éste el caso, ejecutar scripts puede ser un poco peligroso en un entorno de 64 bits. ¿Debe Windows tratar el script como código de 32 bits o como de 64? La respuesta afecta no sólo al contenido de las variables de entorno, sino también que los programas que llame el propio script. Por ejemplo, un script de 64 bits no puede lanzar un proceso de 32 bits (por lo menos no de la manera normal).
Windows consigue solucionar estos problemas ofreciendo dos intérpretes de comandos: uno de 64 bits y otro de 32. Las variables de entorno se establecen de acuerdo al intérprete de comandos utilizado.
Por ejemplo, si se abre una ventana de comandos lanzando el comando CMD.EXE en la ventana “Inicio/Ejecutar …” (Run), Windows abrirá una ventana de comandos de 64 bits. En la mayoría de los casos, la variable de entorno %ProgramFiles% para el entorno de trabajo será fijada a “C:Program Files”. Si se lanza un script, éste podrá ejecutar aplicaciones y comandos de 64 bits, pero no de 32 bits.
En el lado contrario, si se lanza “C:WindowsSysWOW64cmd.exe” en la ventana “Inicio/Ejecutar …”, la ventana de comandos que se ejecuta es de 32 bits. En ese caso, la variable de entorno del %ProgramFiles% será “C:Program Files (x86)”.
Como se puede ver, la localización de la carpeta de archivos de programa se redirige dependiendo de si se está funcionando a 32 ó 64 bits. Pero hay una excepción a esta regla: si una aplicación tiene la referencia a la carpeta de archivos de programa escrita directamente como “C:Program Files”, por ejemplo, se utilizará esta carpeta directamente, sin tener en cuenta el entorno en el que se está trabajando y esto podría dar lugar a diversos problemas, al intentar ejecutar código de 64 bits de algún componente cuando la aplicación es de 32 bits. Afortunadamente esto no es una buena práctica de programación y esperamos no encontrarlo en nuestras aplicaciones.
También en el registro hay una estructura a utilizar cuando se está trabajando a 64 bits y otra a usar cuando se está en 32 bits. Así, dentro de HKEY_LOCAL_MACHINE/SOFTWARE hay una arborescencia llamada Wow6432Node, que será utilizada en lugar de HKEY_LOCAL_MACHINE/SOFTWARE cuando se esté trabajando a 32 bits. Aquí tenemos el mismo funcionamiento y problemas que con las anteriores redirecciones.
Por ejemplo, si lanzamos un cambio del registro haciendo doble-click sobre un fichero .REG, las entradas a añadir o modificar se harán sobre las claves exactas que haya en este fichero y no como relativas a Wow6432Node si estos cambios son para una aplicación de 32 bits.
Si este fichero .REG es ejecutado por una aplicación o una ventana de comandos de 32 bits, los cambios se incluirán en la parte del registro correspondiente a 32 bits.
En resumen, con este sistema empleado por el emulador WOW64, se puede conseguir que la mayor parte de las aplicaciones de 32 bits puedan convivir con las de 64 en un puesto de trabajo que utilice un S.O. de 64 bits. Sin embargo, cuando estas aplicaciones, por alguna mala práctica de programación o por algún truco obligado hacen referencia o utilizan de una forma no estándar las carpetas WindowsSYSTEM32 (o WindowsSYSWOW64), Program Files (o Program Files (x86)) o el registro, puede haber problemas que impidan su correcta ejecución.
El registro de Windows es un archivo que contiene a mayoría de los datos de la configuración del sistema operativo de Windows. El registro contiene una variedad enorme de información, pero los datos de la configuración en que el emulador WOW64 está más interesado son una lista de todos los objetos del Component Object Model (COM) que han sido registrados por el sistema operativo.
COM proporciona una manera para que las aplicaciones (archivos .EXE) y las bibliotecas (archivos .DLL) puedan hacerse accesibles a cualquier otra aplicación o fichero de comandos que cumpla las normas COM. COM permite que alguien con habilidades de programación mínimas pueda escribir una aplicación o un script que interactúe con Windows. La persona que escribe la aplicación o el script puede hacerlo sin tener que aprender un lenguaje de programación tal como C++, y sin tener que aprender todos los interfaces de programación de Windows (APIs).
Windows se diseñó de manera que todos los objetos COM disponibles estuvieran dentro del registro. Para garantizar que el código de 32 bits esté aislado totalmente del código de 64 bits, los objetos COM de 32 y 64bits se almacenan en dos partes distintas del registro.
En lenguaje de Microsoft un servidor COM es un objeto que hace disponible su funcionalidad a través de COM. Las aplicaciones y scripts que hacen uso de esa funcionalidad se llaman clientes COM.
Cuando se habla de un servidor COM in-process se refiere generalmente a las bibliotecas (archivos .DLL), porque éstas se ejecutan como parte del mismo proceso que las aplicaciones y scripts que los llamaron. Un servidor COM out-of-process es un objeto COM (generalmente un fichero ejecutable) que se ejecuta en un proceso distinto que la aplicación o script que lo llamó.
Cuando una aplicación intenta registrar un objeto COM, el emulador WOW64 pondrá las entradas correspondientes en la sección apropiada del registro, dependiendo de si el objeto COM es un objeto de 64 o de 32 bits.
Cuando una aplicación o un script que se supone que son de 32 bits intentan cargar un objeto COM en el proceso, el emulador WOW64 redirecciona el registro para estar seguro que la aplicación o script lee la porción del registro que refiere a objetos COM de 32 bits. Si el registro no contiene una referencia a una versión de 32 bits del objeto COM solicitado, WOW64 dirá a la aplicación que no existe el objeto, aunque exista una versión 64 bits disponible. La misma cosa sucede si una aplicación de 64 bits solicita un objeto COM. Windows comprobará la parte del registro correspondiente a 64 bits para saber si hay una referencia al objeto y no hará caso de cualquier objeto COM de 32 bits.
La manera que WOW64 vuelve a dirigir peticiones de servidores COM in-process es bastante directa. Pero las cosas funcionan diferentemente para los servidores COM out-of-process. La redirección del registro todavía hace falta, pero esto es solamente una parte del proceso.
Las llamadas a un servidor COM out-of-process son la excepción a la regla de mantener separados el código de 32 bits y el de 64.
Aislar el código de 32 bits es normalmente un requisito porque no puedes mezclar código de 64 bits y de 32 dentro de un proceso. Pero cuando son servidores COM out-of-process, el objeto COM está funcionando en un proceso totalmente distinto del del código que lo llamó. Esto significa que la aplicación puede funcionar con código de 32 y llamar a un objeto COM de 64 bits, o viceversa.
Ya que la aplicación y el objeto COM están funcionando en procesos distintos, es fácil ver que sería posible que funcionaran ambos en el mismo sistema. ¿Pero cómo puede la aplicación comunicarse con un objeto COM si uno está funcionando en 32 bits y el otro en 64? Aunque la aplicación y el objeto COM no puedan interactuar directamente uno con otro porque estén funcionando en procesos distintos, pueden comunicarse con Remote Procedure Calls (RPCs).
Los ordenadores que funcionan en una versión x64 de Windows utilizan la redirección del registro para conseguir el funcionamiento de aplicaciones de 32 y 64 bits. Esta redirección del registro evita que las aplicaciones sobre-escriban la configuración de las de 64 bits, pero permite todavía que las aplicaciones y los archivos DLL que utilicen arborescencias escritas a mano continúen funcionando.
Las claves del registro relacionadas con las aplicaciones están instaladas generalmente en la clave HKEY_LOCAL_MACHINESOFTWARE. En una versión x64 de Windows, esta entrada se utiliza exclusivamente para almacenar los datos de la configuración relacionados con las aplicaciones de 64 bits. Los datos de configuración relacionados con aplicaciones de 32 bits se almacenan en la clave del registro HKEY_LOCAL_MACHINESOFTWAREWOW6432node.
Obviamente, las aplicaciones de 32 bits no están diseñadas para buscar en la entrada HKEY_LOCAL_MACHINESOFTWAREWOW6432node. El emulador WOW64 intercepta las llamadas del registro de las aplicaciones de 32 bits y, de forma transparente, vuelve a dirigir estas llamadas al lugar apropiado dentro del registro de Windows.
La entrada HKEY_LOCAL_MACHINESOFTWARE a menudo contiene algo más que los datos de la configuración para las aplicaciones. En ella se almacenan los datos de configuración relacionados con cosas tales como la incrustación y vinculado de objetos o las llamadas remotas (RPCs). Por ello, las llamadas a las llaves secundarias debajo de esta entrada también se redirigen.
Así visto, la redirección del registro parece bastante potente. Incluso así, algunas funciones de Windows que se puede pensar que están garantizadas, por ejemplo la vinculación e incrustación de objetos y las asociaciones de ficheros por la extensión, no funcionarían correctamente si la redirección simple fuera el único mecanismo usado. Por ello, las versiones x64 de Windows utilizan también otra técnica conocida como reflexión del registro.
Esta técnica copias claves específicas y valores del registro entre las dos vistas del registro (una de 32 bits y otra de 64 bits) para mantenerlas sincronizadas. El reflector es inteligente y copia datos del COM activo para los servidores locales entre las vistas del registro, pero no los datos in-process, porque el mezclar datos in-process de 32 con 64 bits no se permite en un Windows de 64 bits.»
Artículos originales:
<MODE masoquista ON>
Mi parte masoquista ha querido que me dedique este fin de semana a una labor dolorosa (supongo que habré sido un chico malo).
Estos días disfruto creando (más bien mejorando, pues está ya hecha) una aplicación web que utilizo personalmente en cada momento para organizar mi trabajo (y mi vida). Pequeños retoques por aquí y allá, que me cuestan un cuarto de hora y que hacen que la aplicación sea todavía más bonita y más eficaz. Un placer.
Pues no. Este fin de semana va a ser diferente y voy a cambiar el diseño de la base de datos, y después voy a cambiar todas mis SQL por procedimientos almacenados y después voy a …. Quizás un trabajo necesario para poder seguir adelante más rápidamente pero, un suplicio para un fin de semana que debe ser para disfrutar. ¡Maldita lluvia, siempre presente! ¡Maldito sol, siempre ausente!
Bueno, pues si después de todos los cambios de mis formularios y módulos para adaptarme al nuevo diseño de la base de datos, no había tenido ya suficiente castigo, cojo el primer formulario (tiene una GridView asociada a un SqlDataSource) y sustituyo las SQL por procedimientos almacenados y empiezo a probar: la visualización va bien, creo un nuevo registro a la primera, pero al borrar o actualizar una línea de la grid me encuentro con el error: «La función o procedimiento xxx tiene demasiados argumentos«.
Y no hay manera de evitarlo: repaso los argumentos creados para la Delete y la Update, pero están bien; busco en Internet y no encuentro una buena solución; programo unos eventos _Deleting y _Updating y tampoco consigo evitar el error; hago debug con estos eventos y puedo ver que realmente tengo 5 parámetros en la Delete, cuando yo sólo he creado uno.
Al final descubrí que el causante de la creación fantasma de los parámetros no deseados es el argumento de la SqlDataSource llamado ConflictDetection, que puede tener dos valores (CompareAllValues u OverwriteChanges) y yo tenía puesto el primero, que hace, para evitar conflictos al borrar o modificar un registro, comparar todos los valores y no sólo la clave que yo he puesto como parámetro del procedimiento almacenado y por eso crea automáticamente parámetros para poder comparar más campos, que naturalmente yo no había añadido a mi procedimiento almacenado.
Así que si queremos utilizar procedimientos almacenados en un SqlDataSource con los parámetros que nosotros queramos y sólo con ellos, deberemos poner ConflictDetection=»OverwriteChanges«.
Quizás la buena práctica sea en estos casos comparar todos los valores en caso de conflicto, pero si queremos ser dueños de nuestros procedimientos almacenados debemos tener en cuenta este argumento ConflictDetection.
Supongo que, para aumento de mi humillación, esto será ya conocido por todo el mundo y con este artículo no haré mas que demostrar mi poco nivel.
Ni siquiera ha levantado mi moral el leer el artículo 10 razones para salir con un Geek.
<MODE masoquista OFF>
Sí, no es LINQ, pero algunos todavía trabajamos con SQL, ¿no?.
Supongamos que tenemos una tabla de tareas a realizar, agrupadas en lista
s y queremos renumerar las tareas que pertenezcan a una determinada lista de tareas en función de ciertos campos.
El nuevo orden va en el campo [Order], como es natural, y queremos ordenar por los campos Status (Desc), Urgent (Desc) y el mismo [Order].
Al final, después de buscar una solución y que varias no me funcionaran en todos los casos, he encontrado una solución para renumerar según las premisas anteriores las tareas de una determinada lista (ListId). Como no soy un experto de base de datos creo que se puede mejorar.
Este es el procedimiento almacenado, que renumera perfectamente usando la nueva función de Sql Server 2005 Row_number():
«Hemos cerrado el mes de Abril con 118.116 visitas y 215.362 páginas vistas. Unas excelentes cifras para un mes de solo treinta días y con las vacaciones de Semana Santa y el puente de Mayo de por medio.»
Estas son unas cifras estadísticas que puestas en su contexto indican el elevado tráfico que experimenta esta comunidad Geeks.ms y, sobre todo, marcan la evolución ascendente en estos meses del número de usuarios a los que llega nuestra voz.
Puestos a utilizar estadísticas, podríamos también saber cuantos post se realizan al mes, qué media de comentarios tienen. No aparecen ahora estas cifras, pero sería relativamente fácil conseguirlas. Es cuestión de saber sumar.
Sin embargo, sería más interesante saber cuantos de los post que escribimos son aprovechados por los lectores y cuantos de ellos son aprovechados en su trabajo real, qué proporción son utilizables para la propia comunidad geek.ms y cuál lo son para los lectores que se nos acercan. Esto es más difícil saberlo.
La mayor parte de los temas que se tratan son sobre versiones beta de productos que no han salido al mercado todavía. ¿Esto es válido para el lector que se nos acerca?. Muy posiblemente, hoy, en el mundo de la Web 2.0 donde la versión beta es eterna, sí. Y necesario para no quedarse atrás en este mundo de evolución contínua y acelerada.
Y después de este rollo, unas pequeñas muestras (no son aplicaciones ni código, pero … son fáciles de ver) de cómo aprovechar los post de otras personas que van abriendo camino.
Como muestra el reciente post de El Bruno «Windows Live Writer – AddIn para trabajar con imagenes desde Community Server«, llevado a la práctica mostrando una foto que reside en este servidor y que es de un evento de este invierno de Artalde.NET:
Y otra muestra de una foto residente en Flickr y que fue obtenida a la salida de dicho evento:
Los días 4 y 5 de Junio se celebrará en Madrid el ReMIX 07, que «es el principal evento de Microsoft para los diseñadores web y los desarrolladores más vanguardistas, con dos días de duración, …. y que ofrece (SilverLight) una riqueza sin precedentes que permitirá llevar las aplicaciones de Internet a un nivel superior».
Ya me he apuntado y espero no perdérmelo.
Aunque este evento se va a celebrar en el Círculo de Bellas Artes de Madrid, me gustaría saber el número de asistentes que forma parte del grupo de diseñadores y de éstos, el número de diseñadores que no tienen ya relación con empresas de informática.
Como geek que soy, encerrado en mi burbuja virtual, la parte técnica de las aplicaciones que desarrollo es la parte que domino y la que hago bien (creo). Desarrollo mi creatividad creando código eficiente y bello (técnicamente). El aspecto visual de la aplicación queda en un segundo o tercer término, sólo por encima de la documentación. Esto nos sucede, creo, a la totalidad de los geeks.
En mi caso particular, por una extraña mutación, puedo sentir la belleza externa de las cosas, y, aunque no pueda crear toda la que quiera, sí puedo sentirla y, sobre todo, puedo notar su ausencia. Así, puedo sentir dolor cuando leo un magnífico artículo técnico en un formato desdichado y puedo aguantar hasta el final la lectura de un torpe artículo en una página con un diseño cuidado.
Hoy en día, no es muy difícil tener un nivel de presencia digno en Internet, incluso para nosotros los geeks. Por ejemplo, este blog donde usted está leyendo este artículo tiene diversos skins o temas y cada blogger puede elegir uno de ellos para su blog particular.
Pero con la llegada de .NET 3.0, de WPF, de SilverLight, etc., las posibilidades de mejorar el aspecto visual de nuestras aplicaciones y páginas web ha crecido exponencialmente y nosotros, los geeks, no vamos a poder dar el salto esta vez. Necesitamos poner un diseñador en nuestras vidas. Algunas empresas ya dispondrán en su nómina de diseñadores profesionales, pero nosotros, como individuos «individuales» y solitarios tenemos un problema para que nuestras utilidades, ensayos, prácticas, aplicaciones, Widgets, Gadgets, etc. sean dignos en el nuevo aspecto visual que se nos exige.
Por ello, quisiera que Microsoft (que es la que nos ha creado este problema) nos ayude en este trance amargo.
No tengo una solución, pero puedo comenzar una tormenta de ideas:
Estaba probando y filosofando sobre la nueva generación de productos que utilizan .NET Framework 3.0, y que dentro de poco tiempo inundarán nuestras pantallas, pero la cruda realidad de mi trabajo «de día» me devolvió al mundo real:
Alguien dijo: Una prueba más de la obsolescencia de VB6 (y de su pronta y necesaria eliminación sin reconversión de nuestra empresa) es que VB6 32 bits no se puede instalar en Vista de 64 bits.
Y ahora tengo que demostrar que puedo instalar VB6 de 32 bits en un sistema de 64 bits aunque quizás nunca se instale Vista de 64 bits en nuestra empresa y aunque quizás pudiera existir un VB6 de 64 bits.
La cosa empieza un poco mal con la instalación de VB6 porque el programa acmboot.exe que forma parte del proceso de instalación es un programa de 16 bits y da un mensaje de error y aborta la instalación.
Un poco de búsqueda en Internet y con acmboot.exe y 64 como palabras mágicas encuentro en Google el siguiente post de Alberto DeLuca con la solución para VS6.
Siguiendo sus intrucciones, hago lo siguiente (VB6 y VS6 difieren un poco en los ficheros de instalación):
Si queremos tener un VB6 actualizado tendremos que instalar también el SP6. Bueno, este es otro problema, pues el programa de instalación setupsp6.exe dice que nos aclaremos si queremos 32 bits (nuestro SP6) o 64 bits (Vista 64) y que hablemos con nuestro proveedor, que no nos deja seguir adelante con la instalación.
Como no puedo aceptar esta derrota, y aunque la estructura de los ficheros del SP6 es bastante distinta de la del VB6 original, tengo todavía en mente el truco de Alberto. Así que cambio el nombre al fichero sp698vbo.stf por acmsetup.stf, lanzo el acmsetup.exe y, ¡milagro!, la instalación del SP6 se realiza suavemente hasta llegar al final.
Y ya tengo VB6 de 32 bits, con SP6 de 32 bits, funcionando en Windows Vista de 64 bits, que es lo que quería demostrar.
A veces me siento como los 300, defendiendo el paso de las Termópilas, ganando combate tras combate, pero viendo venir el ejército sin fin de los persas.
¡Hola a todos!
Antes de nada, agradecer a R.Corral la oportunidad de formar parte de esta comunidad y de disfrutar leyendo sus post sobre la metodología Agil, sobre todo.
El primer post es siempre difícil. Por un lado el miedo a no estar a la altura de los geeks a los que tanto admiro. Por otro lado, sobre qué tema escribir en el que pueda aportar algo. Ya llevo un mes dándole vueltas: reconversión de aplicaciones VB6 a VB.NET, portales multilenguaje, webparts, … Otra vez me he quedado retrasado … no puedo escribir nada de .NET Framework 3.0 ni los nuevos WF, WCF, WPF.
No tengo más remedio que tirarme al abismo… ¡YA!
Como nadie me conoce y nadie me marcará para contar mis historias secretas me voy a presentar: