Conductor de rally, practicante de otros deportes como skateboarding, snowboarding y motocross, y co-fundador de DC Shoes, Ken Block nos muestra su destreza al volante. Como dice mi amigo Albert,... aprendan a conducir!!
Recopilatorio de noticias, conceptos y otras cosas relacionadas con la Informática.
jueves, 3 de diciembre de 2009
jueves, 29 de octubre de 2009
Consejos en cuanto a la seguridad en GMail
Como motivo del Mes de Alerta de la Ciber Seguridad Nacional, Google publicó un post sobre cómo escoger una buena contraseña (que trataré de traducir en otro momento), pero también deberíamos de tener en cuenta algunos consejos más:
1. Siempre hacer un Sign Out. Siempre, siempre, siempre hacer un sign out cuando se termine de trabajar con GMail, y más si es a través de un equipo público o compartido. Si se te olvida salir de sesión, también puedes hacer login desde otro equipo y hacer un sign out en remoto.
2. Mucho cuidado a la hora de mandar información sensible a través de email. Una vez has mandado el correo, ya no tienes el control sobre él. Aunque el destinatario sea alguien de confianza, dicha información puede estar expuesta fácilmente si su cuenta de correo ha sido comprometida o si su máquina ha sido infectada por un virus. Por regla general, si has de proporcionar información sobre tu tarjeta de crédito o tu cuenta bancaria, hazlo siempre en persona o por teléfono - no mediante email. Y nunca des tu contraseña a nadie. Google jamás te pide que des tu contraseña, número de la Seguridad Social o cualquier información personal de dicha índole - ¡¡así que no la envíes!!
3. Habilitar "Always use HTTPS." El protocolo HTTPS se usa para encriptar la información que se transmite entre los equipos de Internet. Para comprobar que se está llevando a cabo, echa un vistazo en la barra de direcciones al "https" para saber que la conexión entre tu equipo y los servidores de GMail va encriptada. Por defecto se usa HTTPS para el login, pero puedes escoger proteger tu sesión completa usando HTTPS. Si es verdad que esta opción puede hacer que tu sesión vaya más lenta.
4. Atento a los adjuntos inesperados. Aunque GMail escanea los documentos que envíes y recibas, en busca de virus, ningún sistema es infalible, y es por ello de que en caso de duda siempre preguntar al emisor acerca de los documentos enviados.
5. Asegurar que la información para recuperar la cuenta está siempre actualizada. Esta información hace referencia a los datos necesarios para recuperar la cuenta en caso de que se te olvide tu contraseña o si alguien ha accedido a tu cuenta sin autorización. Todo usuario de GMail debe elegir una pregunta de seguridad y su respuesta asociada. No se deberían de escoger preguntas del tipo "¿Cuál es mi color favorito?" ya que la respuesta sería fácil de acertar. También se recomienda proporcionar un email secundario o un número de teléfono móvil, para que te puedan enviar un link para resetear la contraseña en caso de que no puedas acceder a tu cuenta.
Traducido del Official GMail Blog.
1. Siempre hacer un Sign Out. Siempre, siempre, siempre hacer un sign out cuando se termine de trabajar con GMail, y más si es a través de un equipo público o compartido. Si se te olvida salir de sesión, también puedes hacer login desde otro equipo y hacer un sign out en remoto.
2. Mucho cuidado a la hora de mandar información sensible a través de email. Una vez has mandado el correo, ya no tienes el control sobre él. Aunque el destinatario sea alguien de confianza, dicha información puede estar expuesta fácilmente si su cuenta de correo ha sido comprometida o si su máquina ha sido infectada por un virus. Por regla general, si has de proporcionar información sobre tu tarjeta de crédito o tu cuenta bancaria, hazlo siempre en persona o por teléfono - no mediante email. Y nunca des tu contraseña a nadie. Google jamás te pide que des tu contraseña, número de la Seguridad Social o cualquier información personal de dicha índole - ¡¡así que no la envíes!!
3. Habilitar "Always use HTTPS." El protocolo HTTPS se usa para encriptar la información que se transmite entre los equipos de Internet. Para comprobar que se está llevando a cabo, echa un vistazo en la barra de direcciones al "https" para saber que la conexión entre tu equipo y los servidores de GMail va encriptada. Por defecto se usa HTTPS para el login, pero puedes escoger proteger tu sesión completa usando HTTPS. Si es verdad que esta opción puede hacer que tu sesión vaya más lenta.
4. Atento a los adjuntos inesperados. Aunque GMail escanea los documentos que envíes y recibas, en busca de virus, ningún sistema es infalible, y es por ello de que en caso de duda siempre preguntar al emisor acerca de los documentos enviados.
5. Asegurar que la información para recuperar la cuenta está siempre actualizada. Esta información hace referencia a los datos necesarios para recuperar la cuenta en caso de que se te olvide tu contraseña o si alguien ha accedido a tu cuenta sin autorización. Todo usuario de GMail debe elegir una pregunta de seguridad y su respuesta asociada. No se deberían de escoger preguntas del tipo "¿Cuál es mi color favorito?" ya que la respuesta sería fácil de acertar. También se recomienda proporcionar un email secundario o un número de teléfono móvil, para que te puedan enviar un link para resetear la contraseña en caso de que no puedas acceder a tu cuenta.
Traducido del Official GMail Blog.
lunes, 19 de octubre de 2009
10 pautas para ser un buen Administrador de Sistemas
Extraído de #rm-rf.es, a continuación les detallo las 10 pautas (básicamente sentido común):
1. Haz las cosas fáciles.
En el mundo de la administración de sistemas, siempre hay varias formas de resolver un problema o realizar una tarea. Es bueno averiguar todas las formas posibles de abordar una tarea, tanto las complejas como las simples, pero a la hora de realizarla es siempre preferible hacerlo lo más sencillo posible.
2. Realiza copias de seguridad (Backups) periódicamente.
Para un momento a pensar si tienes copias de seguridad de todas las cosas realmente importantes tanto de tus servidores, proyectos personales, ordenador en el que trabajas regularmente… En caso contrario, deja cualquier cosa y haz backups de todo cuanto antes.
Nunca se sabe cuando puede haber un fallo en una máquina y que provoque que el trabajo de mucho tiempo se vaya al traste. Por ello es indispensable mantener copias regulares de toda información relevante e importante. Tarde o temprano te sucederá y desearas tener un backup de los datos perdidos para evitar cualquier catástrofe.
3. Comprueba tus copias de seguridad (Backups) regularmente.
De nada sirve hacer copias de seguridad periódicas si no comprobamos que cuando las necesitemos van a cumplir su función. Planifica comprobaciones de backups periódicamente para verificar que se realizan correctamente y en caso de desastre serán de utilidad.
4. Monitorización.
Una buena monitorización de las máquinas que un administrador de sistemas ha de supervisar es el mejor modo de adelantarte (en la medida de lo posible) a quejas de clientes, usuarios, etc sobre fallos del servicio. Así mismo, hará tu trabajo muchísimo más fácil teniendo controlado en todo momento tus redes, servidores, recursos, etc.
5. Documentación.
Los administradores de sistemas deberían documentar todo lo que realizan en sus sistemas, aunque realmente es prácticamente imposible. No obstante conviene tener una bitácora o base de datos en la que almacenar toda la información relacionada con tareas realizadas, solución a problemas que se han presentado, puede ser muy útil en infinidad de situaciones.
Se destacan los siguientes motivos para documentar:
1. No aprender lo mismo dos veces. A quíen no le ha pasado de arreglar algo, dejarlo pasar, presentarse el mismo fallo al tiempo y no recordar como ha sido solucionado.
2. En caso de que alguien ocupe tu puesto durante un tiempo (ya sea por vacaciones o cualquier otro motivo) o tengas un empleado a tu cargo, tendrá información clara y concisa sobre como solventar problemas comunes, situaciones críticas, etc.
3. Compartir conocimiento es bueno, y en el campo (tan sumamente amplio) de la administración de sistemas mucho más.
4. No malgastes toda la RAM de tu cerebro recordando todo, descarga esa información a un fichero de texto para liberar memoria ;)
6. Planificación y estructuración.
Cuando estés realizando una tarea, manten un orden y planifica cada uno de los pasos a realizar. Esto te ayudará a prevenir los posibles riesgos de cada uno de los pasos y las opciones para evitarlos, solventarlos en caso de que ocurran, etc.
7. Usa más la línea de comandos, y menos la GUI.
Los motivos son muy simples, la línea de comandos suele ser muchísimo más rápida que las interfaces gráficas. Normalmente las GUI evitan que se comprenda el funcionamiento total del sistema, y no hay duda que para tareas repetitivas es lo más rápido y preciso. Decir por supuesto que es mucho más divertido.
8. Automatiza tareas repetitivas.
Sin duda uno de los puntos más importantes. En el momento que veas que diariamente tienes que hacer una tarea una y otra vez, programa un script o una tarea para que se ejecute de forma automática. Te ahorrará tiempo y evitará perder un valioso tiempo con tareas de “monos” que puede usarse para cosas más interesantes.
9. Ayuda a los usuarios y clientes de tus sistemas.
Puede resultar frustrante tener que explicar el funcionamiento de un sistema o la solución de un problema a un cliente con pocas nociones informáticas. Lo ideal es explicar a los usuarios en términos no técnicos cual es el problema, y como ha sido solucionado, para que comprendan que no se ha tratado de un fallo del propio sistema (suele suceder), y que debe revisarse por ejemplo la programación de una aplicación para no alterar el correcto funcionamiento del servicio.
10. Sigue aprendiendo y disfrutando.
No hay duda de que la mayoría de administradores de sistemas disfrutan muchísimo de su trabajo. Esa es la ídea, seguir disfrutando día a día y aprendiendo con ilusión, pues es un trabajo en constante evolución.
1. Haz las cosas fáciles.
En el mundo de la administración de sistemas, siempre hay varias formas de resolver un problema o realizar una tarea. Es bueno averiguar todas las formas posibles de abordar una tarea, tanto las complejas como las simples, pero a la hora de realizarla es siempre preferible hacerlo lo más sencillo posible.
2. Realiza copias de seguridad (Backups) periódicamente.
Para un momento a pensar si tienes copias de seguridad de todas las cosas realmente importantes tanto de tus servidores, proyectos personales, ordenador en el que trabajas regularmente… En caso contrario, deja cualquier cosa y haz backups de todo cuanto antes.
Nunca se sabe cuando puede haber un fallo en una máquina y que provoque que el trabajo de mucho tiempo se vaya al traste. Por ello es indispensable mantener copias regulares de toda información relevante e importante. Tarde o temprano te sucederá y desearas tener un backup de los datos perdidos para evitar cualquier catástrofe.
3. Comprueba tus copias de seguridad (Backups) regularmente.
De nada sirve hacer copias de seguridad periódicas si no comprobamos que cuando las necesitemos van a cumplir su función. Planifica comprobaciones de backups periódicamente para verificar que se realizan correctamente y en caso de desastre serán de utilidad.
4. Monitorización.
Una buena monitorización de las máquinas que un administrador de sistemas ha de supervisar es el mejor modo de adelantarte (en la medida de lo posible) a quejas de clientes, usuarios, etc sobre fallos del servicio. Así mismo, hará tu trabajo muchísimo más fácil teniendo controlado en todo momento tus redes, servidores, recursos, etc.
5. Documentación.
Los administradores de sistemas deberían documentar todo lo que realizan en sus sistemas, aunque realmente es prácticamente imposible. No obstante conviene tener una bitácora o base de datos en la que almacenar toda la información relacionada con tareas realizadas, solución a problemas que se han presentado, puede ser muy útil en infinidad de situaciones.
Se destacan los siguientes motivos para documentar:
1. No aprender lo mismo dos veces. A quíen no le ha pasado de arreglar algo, dejarlo pasar, presentarse el mismo fallo al tiempo y no recordar como ha sido solucionado.
2. En caso de que alguien ocupe tu puesto durante un tiempo (ya sea por vacaciones o cualquier otro motivo) o tengas un empleado a tu cargo, tendrá información clara y concisa sobre como solventar problemas comunes, situaciones críticas, etc.
3. Compartir conocimiento es bueno, y en el campo (tan sumamente amplio) de la administración de sistemas mucho más.
4. No malgastes toda la RAM de tu cerebro recordando todo, descarga esa información a un fichero de texto para liberar memoria ;)
6. Planificación y estructuración.
Cuando estés realizando una tarea, manten un orden y planifica cada uno de los pasos a realizar. Esto te ayudará a prevenir los posibles riesgos de cada uno de los pasos y las opciones para evitarlos, solventarlos en caso de que ocurran, etc.
7. Usa más la línea de comandos, y menos la GUI.
Los motivos son muy simples, la línea de comandos suele ser muchísimo más rápida que las interfaces gráficas. Normalmente las GUI evitan que se comprenda el funcionamiento total del sistema, y no hay duda que para tareas repetitivas es lo más rápido y preciso. Decir por supuesto que es mucho más divertido.
8. Automatiza tareas repetitivas.
Sin duda uno de los puntos más importantes. En el momento que veas que diariamente tienes que hacer una tarea una y otra vez, programa un script o una tarea para que se ejecute de forma automática. Te ahorrará tiempo y evitará perder un valioso tiempo con tareas de “monos” que puede usarse para cosas más interesantes.
9. Ayuda a los usuarios y clientes de tus sistemas.
Puede resultar frustrante tener que explicar el funcionamiento de un sistema o la solución de un problema a un cliente con pocas nociones informáticas. Lo ideal es explicar a los usuarios en términos no técnicos cual es el problema, y como ha sido solucionado, para que comprendan que no se ha tratado de un fallo del propio sistema (suele suceder), y que debe revisarse por ejemplo la programación de una aplicación para no alterar el correcto funcionamiento del servicio.
10. Sigue aprendiendo y disfrutando.
No hay duda de que la mayoría de administradores de sistemas disfrutan muchísimo de su trabajo. Esa es la ídea, seguir disfrutando día a día y aprendiendo con ilusión, pues es un trabajo en constante evolución.
Google Wave
Casi gano una invitación para Google Wave, en el sorteo que hizo Fidoxd. Qué mejor que un video para explicar esto del Google Wave (OJO!!! que dura 1 hora y 20 minutos :P):
jueves, 8 de octubre de 2009
Documental Gracie Jiu Jitsu
Un documental muy bueno y cortito acerca del Gracie Jiu Jitsu A. K. A. Jiu Jitsu Brasileño:
lunes, 28 de septiembre de 2009
Volume Snapshot Service (VSS)
(Volume Snapshot Service o VSS). En español es llamado "Instantánea". Es una característica de algunas versiones de Microsoft Windows, que permite crear respaldos (backups) automáticos o manuales de archivos o carpetas de una unidad de disco duro específica en un momento específico.
Es usado por los servicios NTBackup (de Windows 2000, XP Professional y MCE) y Volume Shadow Copy para crear ficheros de respaldo. En Windows Vista, es usado por la utilidad de respaldo de Windows Vista, la aplicación Restaurar Sistema y la herramienta Versiones Previas.
Gracias a shadow copy es posible crear instantáneas del disco duro, para recuperar los archivos en caso de hayan sido eliminados o alterados.
Más info en: Otro Estúpido blog
Es usado por los servicios NTBackup (de Windows 2000, XP Professional y MCE) y Volume Shadow Copy para crear ficheros de respaldo. En Windows Vista, es usado por la utilidad de respaldo de Windows Vista, la aplicación Restaurar Sistema y la herramienta Versiones Previas.
Gracias a shadow copy es posible crear instantáneas del disco duro, para recuperar los archivos en caso de hayan sido eliminados o alterados.
Más info en: Otro Estúpido blog
martes, 1 de septiembre de 2009
Parking de dominios
Parking de dominios es un proceso donde registras un dominio y lo dejas guardado hasta que estés preparado para usarlo. Que saques un beneficio económico depende de tu criterio. Puede o no que tengas una página por defecto donde caerán tus visitantes potenciales, o si usas un servicio de parking de dominios, caerá en una página con publicidad que te puede generar ingresos.
Referencia: ¿Qué es un parking de dominios?
Referencia: ¿Qué es un parking de dominios?
jueves, 27 de agosto de 2009
miércoles, 26 de agosto de 2009
14 reglas para webs más rápidas
Éstas son las conclusiones a las que llegaba Steve Souders de "Exceptional Performance Team" de Yahoo en su momento (ahora en Google), en una charla que dio sobre la optimización y rendimiento de websites en front end:
1. Hacer pocas peticiones HTTP.
2. Usar un CDN (Content Delivery Network).
3. Añadir cabeceras expirables (Expires).
4. Componentes Gzip.
5. Poner CSS al comienzo.
6. Poner JS al final.
7. Evitar expresiones CSS.
8. Hacer JS y CSS externos.
9. Reducir consultas DNS.
10. Minimizar JS.
11. Evitar redirecciones.
12. Eliminar scripts duplicados.
13. Desactivar ETags.
14. Mantener AJAX cacheable y sencillo.
Aquí está la fuente del artículo.
1. Hacer pocas peticiones HTTP.
2. Usar un CDN (Content Delivery Network).
3. Añadir cabeceras expirables (Expires).
4. Componentes Gzip.
5. Poner CSS al comienzo.
6. Poner JS al final.
7. Evitar expresiones CSS.
8. Hacer JS y CSS externos.
9. Reducir consultas DNS.
10. Minimizar JS.
11. Evitar redirecciones.
12. Eliminar scripts duplicados.
13. Desactivar ETags.
14. Mantener AJAX cacheable y sencillo.
Aquí está la fuente del artículo.
lunes, 17 de agosto de 2009
Ejecutar aplicaciones de 32 bits en Windows de 64 bits
Os dejo con un artículo que explica al detalle dicho funcionamiento en un S.O. Windows de 64 bits:
"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 \Windows\SysWOW64 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 \Windows\System32. Sin embargo, en las versiones de 64 bits de Windows se utiliza la carpeta \Windows\System32 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:\Windows\SysWOW64\cmd.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 \Windows\SYSTEM32 (o \Windows\SYSWOW64), 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.
Servidores COM Out-of-process
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_MACHINE\SOFTWARE. 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_MACHINE\SOFTWARE\WOW6432node.
Obviamente, las aplicaciones de 32 bits no están diseñadas para buscar en la entrada HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432node. 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_MACHINE\SOFTWARE 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.
Reflexión del Registro
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."
Extraído de Club Delphi
"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 \Windows\SysWOW64 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 \Windows\System32. Sin embargo, en las versiones de 64 bits de Windows se utiliza la carpeta \Windows\System32 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:\Windows\SysWOW64\cmd.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 \Windows\SYSTEM32 (o \Windows\SYSWOW64), 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.
Servidores COM Out-of-process
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_MACHINE\SOFTWARE. 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_MACHINE\SOFTWARE\WOW6432node.
Obviamente, las aplicaciones de 32 bits no están diseñadas para buscar en la entrada HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432node. 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_MACHINE\SOFTWARE 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.
Reflexión del Registro
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."
Extraído de Club Delphi
miércoles, 15 de julio de 2009
VPN en Windows
A continuación os remito una página estupenda donde se explica paso por paso los conceptos y configuraciones de una VPN en entorno Windows. Las secciones en las que se divide el artículo son:
Conectar a otro equipo usando VPN
Introducción
Crear una conexión VPN en Windows XP
Crear una conexión VPN en Windows Vista
Problemas al conectar con VPN
Conclusiones
Referencias (interesantes)
Y el enlace: el guille
Conectar a otro equipo usando VPN
Introducción
Crear una conexión VPN en Windows XP
Crear una conexión VPN en Windows Vista
Problemas al conectar con VPN
Conclusiones
Referencias (interesantes)
Y el enlace: el guille
Consola de recuperación de Windows XP
Acerca de la consola de recuperación del XP:
elhacker.net
configuraequipos.com
Esperemos no tener que tirar de ella :P Saludos!!
elhacker.net
configuraequipos.com
Esperemos no tener que tirar de ella :P Saludos!!
viernes, 3 de julio de 2009
Test de la Panasonic HDC SD9
Aquí os dejo un video que he hecho para probar la cámara Panasonic HDC-SD9 y el iMovie 09:
Panasonic HDC-SD9: de un vistazo
Xataka
Especificaciones
Y este es un retoque que ha hecho mi hermano:
SD9 Test from Jay Govind on Vimeo.
Panasonic HDC-SD9: de un vistazo
Xataka
Especificaciones
Y este es un retoque que ha hecho mi hermano:
Panasonic SD 9 Test from Ravi Govind on Vimeo.
Firefox 3.5
Aquí podréis encontrar las mejoras que ofrece la nueva versión del navegador de Mozilla:
Características de Firefox 3.5
Y aquí, un video informativo acerca del mismo tema (en inglés :P):
Características de Firefox 3.5
Y aquí, un video informativo acerca del mismo tema (en inglés :P):
viernes, 5 de junio de 2009
Entrenamiento Jiu Jitsu de Andre Galvao
Un vídeo muy interesante de los ejercicios que realiza el luchador brasileño André Galvao después de una sesión normal de entrenamiento:
Operadores de búsqueda avanzada de GMail
Os dejo un listado con los operadores más comunes que se pueden usar a la hora de realizar búsquedas de correo en la bandeja de entrada de tu GMail. La información está en GMail Help.
Espero que os sea útil!!
Espero que os sea útil!!
lunes, 27 de abril de 2009
Activación de Windows XP
El comando para saber si tu Windows XP está activado es:
%systemroot%\system32\oobe\msoobe.exe /a
Para activar tu copia de Windows XP, o por lo menos intentarlo:
mistrucos.net
inkilino.com
%systemroot%\system32\oobe\msoobe.exe /a
Para activar tu copia de Windows XP, o por lo menos intentarlo:
mistrucos.net
inkilino.com
viernes, 24 de abril de 2009
Operadores de búsqueda Google
Para agilizar las búsquedas, y un poco de conocimiento general, aquí os dejo un par de enlaces interesantes:
Galinus
Operadores de búsqueda de Google
Galinus
Operadores de búsqueda de Google
viernes, 20 de marzo de 2009
Nuestros derechos digitales
He encontrado dos artículos interesantísimos, respecto a la "piratería" y a los derechos de los internautas en España:
1.- Como el gobierno cree que está haciendo una tarea magnífica luchando contra la "piratería", y lo único que está haciendo es favorecer a las empresas y organizaciones metidas en el pastel, se pide en primer lugar, y entre otras cosas, la dimisión del ministro de Cultura, el Sr. César Molina: ¡Molina pírate!
2.- Cómo darse de baja de las operadoras de internet que quieren controlar a los usuarios que usen las redes P2P: Baja ADSL
¡¡¡EL ACCESO A LA INFORMACIÓN DEBERÍA DE SER UNIVERSAL, PARA TOD@S!!!
1.- Como el gobierno cree que está haciendo una tarea magnífica luchando contra la "piratería", y lo único que está haciendo es favorecer a las empresas y organizaciones metidas en el pastel, se pide en primer lugar, y entre otras cosas, la dimisión del ministro de Cultura, el Sr. César Molina: ¡Molina pírate!
2.- Cómo darse de baja de las operadoras de internet que quieren controlar a los usuarios que usen las redes P2P: Baja ADSL
¡¡¡EL ACCESO A LA INFORMACIÓN DEBERÍA DE SER UNIVERSAL, PARA TOD@S!!!
miércoles, 11 de marzo de 2009
Google Apps Status Dashboard
Si quieres saber si alguno de los servicios de Google está caído, o si está bajo mantenimiento, o lo que sea, puedes consultarlo en el Google Apps Status Dashboard. Te muestra un listado de las incidencias producidas en la última semana, e incluye aplicaciones como GMail, Google Calendar, Google Talk o Google Docs.
lunes, 9 de febrero de 2009
Metadatos
Los metadatos, en este caso los pertenecientes a cualquier documento ofimático, sirven para saber más acerca de dicho documento. Esto puede incluir desde información del autor hasta las fechas de creación y modificación, por quién o quiénes fueron realizados esos cambios, en qué impresoras se ha imprimido el documento, etc. Puede que en un entorno personal no tenga gran importancia, pero en un entorno corporativo, a nivel de empresa o de acceso y dominio público esta información puede ser crucial si cae en las manos equivocadas.
Os dejo un interesante artículo de Enrique Rando y Chema Alonso acerca del tema.
Os dejo un interesante artículo de Enrique Rando y Chema Alonso acerca del tema.
jueves, 29 de enero de 2009
Gmail Offline
Google está trabajando en una nueva característica de GMail, que se trata nada más y nada menos que el poder trabajar con tu buzón de correo sin estar conectado a la red.
GMail Offline:
GMail Offline:
martes, 27 de enero de 2009
Street Fighter IV
Street Fighter IV está previsto que salga para mediados/finales de febrero para las consolas Playstation 3 y Xbox 360, e incluso una versión para PC más adelante.
lunes, 12 de enero de 2009
Dispositivos portátiles con Wi-Fi
Después de haber estado y pico sin postear... :P dejo esta interesante lista de la Wkipedia con todos los dispositivos móviles con capacidad de conexión Wi-Fi:
Listado de dispositivos con Wi-Fi
Listado de dispositivos con Wi-Fi
Suscribirse a:
Entradas (Atom)