February 2007 - Artículos

Generalmente cuando trabajo con gráficos suelo pintar sobre el área cliente de la propia ficha, pero esta vez he tenido que hacerlo por narices en un panel.

Activar el sistema de doble buffer de una ficha es muy sencillo, tenemos que cambiar su estilo y aplicarlo. Algo así: 

this.SetStyle(ControlStyles.OptimizedDoubleBuffer | ControlStyles.ResizeRedraw | ControlStyles.AllPaintingInWmPaint,true);
this.UpdateStyles();

El primer valor de ControlStyles indica que se va a activar el doble buffer, el segundo que se genere un evento de pintado cuando se redimensione el panel (este valor no es obligatorio pero me hace falta a mi),  y el tercero que todo el pintado se va a realizar en evento Paint (habitualmente el sistema primero pinta el fondo automáticamente en otro evento y luego llama al de pintado).

Pero lo que con una ficha es algo trivial con un Panel es imposible ya que dichos métodos son protegidos y no tenemos acceso a ellos. La solución políticamente correcta consiste en heredar del panel para tener acceso a los miembros protegidos del mismo, pero entonces quitamos la posibilidad de trabajar en el editor visual (a no ser que te crees un componente propio basado en un panel, pero es casi peor el remedio que la enfermedad).

Pero como el menda es bastante políticamente incorrecto, buscando por aquí y por allí ha encontrado un método alternativo mucho más fácil que el anterior, método que consiste en llamar a dichas funciones protegidas mediante el uso de la reflexión (y aquí es donde uno agradece ciertos aspectos del .NET):

 

//Activating DoubleBuffer techniques. We must do it with reflection because Panel.SetStyle is a protected member.
MethodInfo m=typeof(Panel).GetMethod("SetStyle",System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
Object[] parameters=new Object[2];
parameters[0]=
new ControlStyles();
parameters[0]=
ControlStyles.OptimizedDoubleBuffer | ControlStyles.ResizeRedraw | ControlStyles.AllPaintingInWmPaint;
parameters[1] =
new bool();
parameters[1] =
true;
m.Invoke(m_pnlGuachindeil, parameters);
m =
typeof(Panel).GetMethod("UpdateStyles", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
m.Invoke(m_pnlGuachindeil,
null);

Siendo justos deberíamos controlar si el valor de m es válido, pero como este código va prefijado si algo falla es que debemos terminar, así que dejamos la salida, el lanzamiento de la excepción y la captura de la misma al sistema (eso si lo hace, cosa que no siempre ocurre como hemos podido ver en alguna entrada anterior).

con 4 comment(s)
Archivado en: ,

Esta entrada va a ser muy cortita. Es una pregunta dejada al aire, por si alguien la quiere recoger...

Existe la estructura RectangleF, que es un rectángulo con sus coordenadas marcadas en coma flotante.

Existen infinitud de métodos que permiten dibujar y operar con dichas estructuras como elementos de delimitación (DrawString, DrawImage, DrawEllipse, etc, etc...)

Entonces, ¿por qué no existe un método Invalidate que nos acepte un RectangleF?

Evidentemente existe un workaround, y es crear una región a partir de un RectangleF pero ya tenemos que trastear con asignaciones de memoria dentro de lugares en los que cuanto más rápido vayamos, mejor.

miControl.Invalidate(new Region(miRectangleF));

con 7 comment(s)
Archivado en: ,

Ya lo dijo no sé quién: la condición humana consiste no estar nunca contento. O dicho de otra forma mucho más políticamente incorrecta, los programadores están intentando hacer programas cada vez más robustos frente a los usuarios, y el universo está haciendo usuarios cada vez más manazas, y por desgracia, de momento quién gana es el universo.

Antes windows era inseguro, o eso se decía, ahora windows es más seguro, o eso se dice. Antes la gente se quejaba porque se les instalaban virus, troyanos y demás fauna maliciosa, sin caer en la cuenta de que la culpa de que eso ocurriera en del propio usuario, o como dice alguien que conozco, el problema está entre la silla y el teclado. Y esto nadie puede discutirlo.

Porque señores, salvo excepciones, todos esos bichitos que pueden convivir en nuestros ordenadores no se instalan solos, sino que requiere la intervención activa del usuario; como poco has de navegar por lugares peligrosos, aceptar cosas que no deberías o instalar toda la mierda que venga en los cds de regalo.

O mejor el típico mensaje de correo cadena en el que se promete un video porno sadomasoquista con un teléfono móvil tremendamente interesante (el vídeo, no el teléfono), el último chiste sobre Bill Gates o el programa de apuestas que te va jubilar.

Pero siempre, siempre, está la intervención del usuario que decide aceptar e instalar. Y que nadie me vengan con cuentos chinos sobre cosas que se instalan solas o que mágicamente aparecen en el escritorio de tu ordenador.

La solución a ello es bien sencilla, y consiste en encontrar un método que impida la instalación automática mediante una simple pulsación de tecla de cualquier software, así como la necesidad de implementar algún sistema activo para que cuando se vaya a realizar una acción potencialmente crítica en un equipo el usuario sea consciente de que se está metiendo en camisa de once varas.

La solución clásica de windows y de la mayoría de los sistemas operativos consiste tener al menos 2 tipos de cuentas: aquellas en las que es posible realizar cualquier acción y otras en las que se impida activamente el poder destrozar cualquier cosa. Pero este modelo tiene una contrapartida en equipos de escritorio y para usuarios avanzados, y es que hay que estar continuamente cambiando de usuario ante ciertas tareas, lo que a veces resulta bastante tedioso y pesado.

Linux lo soluciona mediante la promoción automática del programa previo introducción de la clave de acceso de administrador; y muchas distribuciones vienen preparadas para no tener que hacer otra cosa más que introducir dicha clave.

Windows Vista lo soluciona de una manera similar pero mucho más elegante y sencilla. Es lo que se llama UAC. Mediante este sistema cuando vamos a hacer una tarea potencialmente peligrosa la pantalla se oscurece y windows nos pregunta si realmente queremos realizar tal acción. Un simple clic de ratón o la pulsación de una flecha y enter aceptan la acción, pero lo importante es que de ninguna manera podemos ignorar que vamos a realizar una acción potencialmente peligrosa. No valen justificaciones como que " no me he dado cuenta de que el mensaje preguntaba eso", " no me ha dicho nada", " es que estaba pensando en otra cosa".

El cambio de contexto que se produce dentro del ordenador es tan brutal que no deja lugar a dudas de que se va a realizar una acción peligrosa, y quizá sea eso lo que disguste en gran medida la mayoría de la gente, pero es una efectiva forma de llamar la atención. Sería equivalente a vivir en una cueva hace un millón de años y estar comiéndonos una chuleta tan tranquilamente, levantar la vista, y ver a un león acechándonos.

Pero lo queremos todo, queremos que nuestro windows sea seguro pero no queremos tomar medidas para ello, somos unos inconformistas de tomo y lomo, incapaces de ver lo que tenemos delante de las narices, y menos aún comprender que el único modo de evitar que cometamos pifias por nuestra propia estupidez es disponer de un sistema parecido al UAC. Y si Windows Vista te pregunta continuamente cada vez que abres o cambias de sitio uno de tus documentos ve pensando en hacer un curso de informática para enterarte de algunas cosas...

Quizás no sea el el mejor sistema de todos, pero lo prefiero por encima del de Linux, no veas lo que jode estar todo el día que tecleando una clave de acceso cada diez minutos. Porque Señores, si no se han dado cuenta, el funcionamiento bajo Linux es ese.

Estamos tan embebidos en nuestra propia estulticia que somos incapaces de reconocer una buena idea aunque provenga de lo que algunos llaman el lado oscuro de la informática; porque a ver una cosa, señores, todos esos que os quejais de que el UAC es como una mosca cojonera, despotricais por tener que mover el ratón unos centímetros o por pulsar dos teclas, decidme, ¿existe otra manera más sencilla de hacerlo? Al que no le guste que proponga una idea mejor.

Es muy bonito eso de despotricar de forma descerebrada sin detenerse ni un segundo a pensar las tonterías que se están diciendo. Cualquiera con dos dedos de frente se da cuenta de que es la única forma de evitar que el usuario compulsivo (por no decir tonto) se vea cogido en sus propias redes. No me refiero a la forma en que el UAC lo hace, sino a la necesidad de tener que preguntarle al usuario si está seguro de la tontería que va a cometer. Y la forma en que el UAC lo hace es, a mi modo de ver, la mejor de todas las posibles dentro de un entorno doméstico.

Y si no estáis de acuerdo, proponed una mejor.

Esto ya clama al cielo. Al que me contradiga me lo como con patatas. Estoy hasta los mismísimos del .NET. Así de claro, y dado que por aquí hay filtro de contenidos, la VM .NET es una p*t* m**rd* pinchada en un palo. Así de sencillo. Y lo voy a demostrar con esta serie de artículos. A ver si se espabilan de una vez. Y a ver si aprenden a hacer las cosas bien. [Por cierto, si convenzo a mi jefe voy a girar una factura de una mañana completa mía a Microsoft, por la pérdida de tiempo que me ha ocasionado esto].

 A ver. Tomemos el siguiente código en C#:

Retangle[] m_arrowsRect=null;
float
xx = m_toppersRect[iTopper].Width / m_bitmap.Width * k_originalArrows[0].X;
float yy = m_toppersRect[iTopper].Height / m_bitmap.Height * k_originalArrows[0].Y;
m_arrowsRect[0] =
new RectangleF(xx + k_originalArrows[0].X, yy + k_originalArrows[0].Y, m_arrows[0].Width, m_arrows[0].Height);
m_arrowsRect[1] =
new RectangleF(xx + k_originalArrows[1].X, yy + k_originalArrows[1].Y, m_arrows[1].Width, m_arrows[1].Height);
m_arrowsRect[2] =
new RectangleF(xx + k_originalArrows[2].X, yy + k_originalArrows[2].Y, m_arrows[2].Width, m_arrows[2].Height);
m_arrowsRect[3] =
new RectangleF(xx + k_originalArrows[3].X, yy + k_originalArrows[3].Y, m_arrows[3].Width, m_arrows[3].Height);

Compilemos con AnyCPU y ejecutemoslo dentro de un evento SizeChanged en de una ficha. Ejecutemos en un Vista x64. ¿Qué ocurre? Pues nada, que el código llega a la primera asignación de m_arrowsRect y termina la ejecución del método sin más, sin excepciones ni nada.

Ahora compilemos con x86. ¿Qué ocurre? Se lanza una excepción en la primera asignación de m_arrowsRect.

m_arrowsRect no es una variable local (aunque lo haya puesto aquí por simplicidad), sino un miembro de la ficha. Cuando llegamos a Paint, el valor siguie siendo nill, en AnyCPU la aplicación se ejecuta sin pintar la parte que se corresponde a m_arrowsRect, pero no peta. En x86 sí, como es lógico.

Sin comentarios. Mañana, más.

ADDENDA
Para quien quiera probarlo: aquí un proyecto de demo. Este desde fuera del IDE peta, pero desde dentro funciona sin disparar las excepciones. En un Vista RTM x64 con el IDE ejecutando en modo Administrador.

NUEVA ADDENDA

Quizás escriba mal, pero creo que el tema está lo suficientemente claro: el código mal escrito, ejecutado en un Vista x64 desde el IDE y compilado con AnyCPU

NO GENERA NINGUNA EXCEPCIÓN

Y debería generar una, tal como lo hace si se compila con x86.

Y AHORA EN VIDEO
Pues es, lo he grabado en vídeo. El problema es que no se ve muy claro (es una cámara de fotos, no tengo otra cosa), pero se puede ver cómo no falla en AnyCPU y cómo falla en x86... Sinceramente estoy hartito de las risas bajo manga, como si no me enterara de qué va la cosa. Pero ahí está, fallando y grabado en vídeo. El que quiera está invitado a venir a verlo.

Aps, el vídeo, aquí. He puesto dos más en los que se ve algo más claro: aqui y aquí (está partido porque se me ha ido el dedo del botón de la cámara).

con 27 comment(s)
Archivado en: ,,

Primero una inconsistencia
O mejor dicho, una supuesta inconsistencia. C# no permite que existan métodos globales, de hecho ni siquiera permite la existencia de variables globales estáticas; A lo más que llega es a permitir miembros estáticos de una clase, sin necesidad de que ésta haya sido instanciada. Personalmente digo: menos mal.

Porque si no, las fichas y las clases deberían tener infinidad de propiedades o métodos compartiendo referencias a otras fichas y otras clases, conformando un maremágnum de elementos cruzados y poseídos entre sí, ofusfcando en gran medida el modelo de objetos.

Pero todo programa (digo ensamblado) ha de tener un punto de entrada, y el C#, violando en cierta manera sus propias reglas, exige la existencia de un elemento global no estático. Ese punto de entrada es main, que debe ser un método miembro estático con una firma concreta.

Técnicamente hablando no estamos violando ninguna regla del C#, pero como es al uso en otros marcos de trabajo, el punto de entrada de la aplicación debería ser una clase heredada de, por poner un ejemplo y sin salirnos mucho de las propias especificaciones del lenguaje, Application.

Que conste que no estoy criticando ni quejándome de esto, pero desde mi punto de vista, que en un lenguaje de programación orientado a objetos tan puro como quiere ser el C#, el punto de entrada de una aplicación sea un método estático global deja un poco que desear.

Y la nueva versión del lenguaje todavía es menos pura (léase LINQ), así que sigo sin entender por qué no permiten ni variables ni métodos globales, máxime cuando la base de LINQ consiste en casi eso (Y en C++/CLI es algo habitual).

Y ahora las consistencias
O mejor dicho, un punto muy fuerte. El último párrafo del capítulo tres del libro The C# Programming Languaje dice (y cito textualmente):

"The ordering of side effects is preserved with respect to volatile reads and writes ($10.4.3). Additionally, the execution environment need not evaluate part of an expression if it can deduce that that expression's value is not used and that not needed side efects are produced (incluiding any caused by calling a method or accessing a volatile field). When program execution is interrupted by an asynchronous event (such as an exexcption thrown by another thread), it is not guaranteed that the observable side effects are visible in the original program order."

La última frase del párrafo es evidente por sí misma, y si quieres garantizarlo, utiliza una sección crítica o un bloqueo. Yo me refiero al tema de los efectos laterales en las evaluaciones de las expresiones. En otros lenguajes una vez que se conoce si la expresión es cierta o falsa, no continúa evaluandose.

Al parecer en C#, si el resto de la expresión contiene o pudiera ocasionar algún efecto lateral, ésta se produciría de igual modo. Esta es una característica muy potente a la que no estamos acostumbrados los programadores de sistemas, aunque aunque sí lo estemos en relación al tema de las variables volátiles. Personalmente pienso que disponer de esta característica requiere que se le dé cierto grado de inteligencia al compilador y al entorno de ejecución; ésta sería una ventaja de lo que yo llamo " entorno interpretado".

con 5 comment(s)
Archivado en:

Como todo lenguaje de programación que se precie, C# dispone de de un preprocesador para permitir ciertas tareas que no serían posibles (o muy difíciles) sin él. Aunque técnicamente hablando no es un preprocesador, ya que dichas directivas se procesan simultáneamente durante el análisis léxico.

Y el título de esta entrada tiene una explicación: comparado con el de otros lenguajes de programación, el preprocesador de C# es un juguete; eso no quiere decir que no se puedan hacer las mismas cosas que con, por ejemplo, C++, sino que hay que hacerlas de forma diferente.

Definir una constante
Mientras que en otros lenguajes podemos definir una constante y asignarle un valor, o sólo definirla, en C# sólo podemos hacer esto último, con lo que se elimina cualquier posibilidad de sustitución de macros, tokenización, creación de funciones o la simple sustitución de un número mágico por su equivalente predefinida. C# permite que muchas de estas tareas se puedan realizar de forma más segura (y más complicada también) aprovechando que se trata de un lenguaje interpretado (no hay nada nuevo bajo el sol, y el uso del p-code se viene utilizando desde tiempos inmemoriales, quien recuerde el clipper sabrá de que estoy hablando. De hecho, a nivel teórico no existe mucha diferencia entre el basic tradicional y los modernos lenguajes .NET. Estamos hablando de un código fuente que se transforma en una serie de símbolos binarios que un motor de ejecución ha de interpretar).

Compilación condicional
Basadas en las constantes anteriormente citadas se permite lo que se conoce como compilación condicional. Dado que con el preprocesador no se puede asignar un valor a una constante, la compilación condicional sólo puede comprobar la existencia de dicha constante.

La compilación condicional puede llegar a ser enormemente útil en ciertas situaciones; desde diferenciar una construcción de depuración o final, hasta la inclusión de según qué codigo en según qué situaciones.

Un ejemplo que englobe lo visto hasta ahora podría ser el siguiente:

#define HOLA
#if HOLA
...
#elif ADIOS
...
#else
...
#endif
#undef HOLA

Nada más sencillo ni más elemental. Primero definimos la constante HOLA, luego si dicha constante está definida entramos dentro de #if HOLA, si no está definida continuamos la cadena, y en el momento en el que entremos en uno de los if, ya no se siguen evaluando más condicionales, por lo que si estuviera definido tanto HOLA como ADIOS, el compilador no entraría en en bloque ADIOS.

Directivas de diagnóstico
Aunque no suelen ser muy utilizadas en el desarrollo normal (personalmente recomiendo encarecidamente su uso junto a la compilación condicional para evitar situaciones un tanto kafkianas), sí que son enormemente útiles en el mundo de la metaprogramación. Disponemos de dos directivas,

#warning Esto es un aviso
#error Esto es un error.

La primera línea nos imprimirá un aviso como si se tratara de un aviso generado por el compilador, y la segunda un error con las mismas características que los errores del compilador.

Directiva de región
Estas son nuevas en los lenguajes .NET, y se utilizan para agrupar lógicamente bloques de código para simplificar la lectura del mismo. Personalmente las utiliza muy a menudo y me resultan muy utiles para agrupar algoritmos, separar secciones y en general presentar un código mucho más legible y bonito.

Directivas de línea
Quizás las menos utilizadas de todas, y al igual que las de diagnóstico sólo suelen utilizarse en la metaprogramación. Su función, que quizá parezca un tanto sin sentido, es la de cambiar u ocultar los números de línea del fichero de texto, para forzar los que nosotros queramos.

#line 100
#line default
#line hidden

La primera directiva cambia el número de línea por 100, la segunda restaura los números de linea y la tercera los oculta (es decir, si se produce un error o un aviso, esta información aparecerá sin número de línea). La directiva central también sirve para restaurar el estado oculto.

Conclusión
Aunque muy pobrecitas, las funciones del pseudo preprocesador de C# se muestran suficientes, pero por un justo aprobado. Lo que más echo en falta es el poder definir constantes. Ya sé que existe su equivalente dentro de una clase, pero no es lo mismo. A veces son necesarios valores globales a toda la aplicación, lo que obliga a meterlas dentro de una clase, y ya sabemos que el .NET no trabaja muy fino con los elementos estáticos. La verdas es que con el diseño del .NET y del C# se han lucido en algunos aspectos, y este es uno de ellos. En fin.

con 13 comment(s)
Archivado en:

Recientemente he comprado en Amazon el libro "THe C# Programming Language" de Hejlsberg y otros, que parece ser es el libro de cabecera del lenguaje de programación C#. Ya casi ni me acordaba, pero la mejor forma de entender un lenguaje de programación es verlo escrito en el formato BNF con pequeños comentarios aclaratorios. Así es como yo aprendí en mis tiempos mozos el lenguaje C, y el C++ no porque el libro de Stroustrup lo explica todo con palabras y ejemplos.

Nada más comenzar con el libro, hay una cosa que me ha llamado enormemente la atención, y es el uso de la arroba en el código fuente. Quizá a quien lea esto, programador avezado en las lides del C#, la resulte obvio y hasta elemental. De hecho, el uso junto a una cadena literal ya lo conocía y suelo utilizarlo muy a menudo.

La arroba delante de un literal cadena
Es sin duda el uso más común, y el más útil de los dos usos que podemos darle a la arroba dentro del código fuente, y se utiliza para interpretar literalmente el contenido de la cadena, es decir, si una cadena tiene una arroba justo antes de las comillas de apertura, la cadena se interpretará literalmente sin prestar atención a códigos de escape, saltos de línea, o cualquier otro símbolo que está contenga y que pudiera hacer protestar al compilador o hacer que éste interpretara de forma especial dichos símbolos. Pongamos un ejemplo sacado del libro:

string a= "Hello \t World";
string b=@"Hello \t World";

Estas dos lineas de codigo harán que las variables contengan (o más bien apunten a un área de la memoria que contenga, ya que son referencias a un objeto):

a -> Hello     World
b -> Hello \t World

La forma para un literal cadena literal (valga la redundancia) viene como anillo al dedo para especificar rutas a ficheros sin tener que utilizar los tendente a error códigos de escape, y un uso más avanzado podría ser la creación de código fuente (es decir, tener un programa que genere codigo fuente para hacer otro programa).

La arroba delante de una palabra reservada
Este es el uso que me ha llamado enormemente la atención. Hablando básicamente podemos tener un nombre de variable o cualquier otro elemento dentro de un código fuente que sea una palabra reservada, pero sin serlo. Es decir, el siguiente código fuente es perfectamente válido:

class @class
{
    public static void @static(bool @bool)
    {
        if(@bool)
            System.Console.WriteLine("true");
        else
            System.Console.WriteLine("false");
    }
}

Este código aparece al final de la página 53 del libro y nos dice que tenemos una clase llamada "class" con un miembro estático llamado "static" que recibe una variable de tipo lógico con el nombre "bool".

Personalmente no encuentro utilidad a esta característica, ni siquiera para metaprogramación, y lo único que hacen es ofuscar el codigo, pero está presente y se puede utilizar.

Más curiosidades
¿Algún programador de C de los de la vieja escuela recuerda los "trigraphs"? Supongo que sí, que no seré yo el único dinosaurio que usaba editores para el codigo fuente que no permitían introducir símbolos especiales. Borland tenía una utilidad para que, una vez escritos dichos trigráficos con un editor normal, fueran traducidos a los símbolos adecuados para que el compilador no protestara. Bueno, pues el C# trae un rico conjunto de su equivalente, pues podemos indicar en cualquier lugar del código fuente (ya sea dentro de una variable, de una palabra reservada, o en cualquier otro lugar), mediante la codificación UNICODE y utilizando la propia nomenclatura de UNICODE, virtualmente cualquier carácter un símbolo que consideremos necesario.

con 4 comment(s)
Archivado en:

Me resulta bastante triste confirmarlo, pero el sistema de reconocimiento de voz de Windows Vista tienen varios agujeros de seguridad, alguno de ellos bastante serio.

La siguiente lista resume las cosas que he podido realizar y no deberían haber funcionado:

  • Abrir una consola de comandos y teclear dentro de ella.
  • Borrar todos los documentos del usuario activo.
  • Vaciar la papelera de reciclaje independientemente del número de ventanas abiertas.
  • Borrar correos situados en carpetas estándar de windows mail, como la bandeja de entrada, y luego vaciar la carpeta de elementos eliminados.
  • Ejecutar comandos potencialmente destructivos sin tocar el teclado o el ratón.
  • Redireccionar el navegador web a una dirección que pudiera contener un posible exploit o fallo de seguridad.
  • Pulsar un botón inserto en una página web que, por ejemplo, copiara el código de un script malicioso al portapapeles, primer paso para aprovechar alguno de los otros fallos.
  • Éste no lo he probado, pero creo que se podría ejecutar una consola de comandos con permisos de administrador en aquellos equipos en los que se entrase sin clave de acceso (lo que es habitual en miles de hogares).
  • Este tampoco lo he probado, pero mostrando la rejilla del ratón se puede pulsar en cualquier lado independientemente de la resoución del ordenador.

La solución a todo esto pasa por obligar a que cualquier comando realizado en el navegador, en la consola de comandos, o en el escritorio requiera mantener pulsada una tecla mientras se habla o aceptar el comando mediante la pulsación de una, como en el UAC.

con 33 comment(s)
Archivado en: ,,

Originalmente pensé poner el título "-Eres una chica lista, Gay Deceiver. -Eso se lo dirás a todas". Pero entiendo que la referencia quizás no pueda entenderse correctamente ya que, aparte de tratarse de un libro bastante antiguo, hoy en día es casi imposible de encontrar si no es bajándolo de internet. (De todos modos, dejo al sufrido lector que intente adivinar a que novela me estoy refiriendo).

Como ya os habréis imaginado, voy a hablar del sistema de dictado de voz de Windows Vista. Sólo por él, ya vale la pena comprar el nuevo sistema operativo de Microsoft, incluso si es necesario actualizar alguna pieza de tu ordenador. O incluso comprar un equipo nuevo.

Hasta que me llegue la nueva versión retail para mi ordenador principal y de trabajo, he instalado una Home Premium en mi sufrido portátil, aunque sin activar, ya que la versión instalada pertenece a otro ordenador en el que si la he activado. De todos modos, si no me da mucha lata, quizás compre una licencia para éste. Pero aún no lo sé seguro, ya que cuando comience a usar mi equipo principal otra vez para todo, no sé si valdrá la pena gastarme dinero en el portátil.

El sistema de dictado es una gozada, la única forma de verlo bien que va es usarlo, y para usarlo, tienes que pasar por caja, pero te aseguro que vale la pena, sobre todo cuando llevas un rato usándolo y el sistema aprende de ti. Generalmente, cuando se equivoca, si sigues los pasos adecuados para corregir, aprenderá a partir de esa pronunciación difícil y ya no volverá a equivocarse en lo mismo.

Por ejemplo, podrás decir Windonsmai para referir te al windows mail, el sistema de reconocimiento podrá escribir cualquier cosa, le dices que corrija, y la próxima vez que pronuncies windonsmai, será capaz de escribir correctamente Windows Mail. Y todo ello en perfecto castellano.

El supuesto fallo de seguridad.
Las malas lenguas se hacen eco de que el sistema de reconocimiento de voz de Windows Vista presenta un fallo de seguridad garrafal, qué consiste en que una supuesta web pudiera pronunciar una secuencia de frases que el micrófono capturaría y ejecutaría, pudiendo causar algún destrozo en el sistema.
En primer lugar, sería absurdo que alguien se levantara de su asiento sin apagar el micrófono, es decir, no dijera "dajar de escuchar" antes de dejar el ordenador sólo.

En segundo lugar, los comandos de voz no funcionan cuando se intenta algo crítico en el ordenador, como en la pantalla de elevación de privilegios, por lo que aunque se pronunciara la secuencia correcta, sería completamente imposible causar algún destrozo.

No todo es de color de rosa.
Por supuesto no sería yo si no me quejara, pero ahora no me quejo ni de mi ordenador ni de Windows Vista, si no que me quejo de mi mismo.

Y es que cuando me pongo a dictar me pongo nervioso, se me traba a la lengua, y no doy pie con bola. O peor aún: cuando voy a dictar, me quedo en blanco y no sé qué decir. Y es una situación muy grave, porque si no fuera tan nervioso, tardaría mucho menos a dictar que a escribir.

A ver si me acostumbro.

Cambiando un poco de tema, sigo pensando que el windows mail es un juguete, tiene los mismos fallos que la versión anterior, y alguno más. Tengo un grupo de noticias que tiene más de 175000 mensajes y el programa no puede con ellos. El internet explorer también se cae a veces él solo, y el rendimiento en General, al menos en este portátil, es bastante pésimo, pero también lo era con windows xp, así que imagino que en mi ordenador principal (un AMD de 64 bits de doble núcleo y con dos gigabyte de memoria) el rendimiento será más que aceptable, sobre todo si le pongo la versión de 64 bits.

Por cierto, todo esto lo escrito dictando en el bloc de notas.

Tras una tarde, un rato por la noche y casi una mañana usando el Windows Mail casi ininterrumpidamente, he llegado a las siguientes conclusiones generales:

  • Tarda una barbaridad a arrancar, incluso segundas veces.
  • Es muy lento en la carga de carpetas con muchos correos.
  • A veces se queda "pillado", y luego vuelve a responder.
  • La importación de correos desde Outlook Express no es muy fina.
  • Pierde correos, he perdido un árbol de correos de una misma persona que estaba en la bandeja de entrada. (Una inspección de la carpeta correspondiente mostraba que los ficheros .eml estaban en el disco, pero incluso al volverlos a arrastrar al Windows Mail seguían sin aparecer en la lista, pero si los abria a mano sí que se veían. Fue tras importar).

Y las particulares:

  • La tecla de "siguiente mensaje sin leer" en el OE era Ctrl-U, ahora es Ctrl-N, y Ctrl-U es "Nuevo mensaje". ¿Cuándo dejarán de marear cambiando las teclas rápidas en cada versión?
  • Al pulsar Ctrl-N, si ya no quedan sin leer en esa carpeta, te pregunta si quieres avanzar. Le dices que sí y el Ctrl-N deja de funcionar porque el programa pierde el foco, por lo que hay que hacer clic con el ratón en la ventana del mensaje.
  • Debido al fallo anterior, no puedo comprobar si sigue queriendo saltar aun cuando quedan mensajes sin leer en la carpeta actual.
  • Cuando llegas al final de las carpetas, si quedan mensajes sin leer en carpetas susperiores, te dice que no hay mensajes sin leer.
  • En el visor de sucesos hay cientos de errores con algo de que ha excedido los 4 Kb de no se qué.

Aps, y por cierto, hace un rato el ordenador se ha bloqueado y se ha apagado él solo. Tenía abiertos el Windows Mail y dos ventanas del IE, y estaba a desfragmentando con el desfragmentador del Vista. No ha sido una pantalla azul ni un fallo de la batería, ya que el portátil estaba conectado a la red. Y tampoco un sobrecalentamiento. Es la primera vez que me pasa en este cacharro en los dos años que lo tengo.

Como conclusión: El Windows Mail arrastra los mismos bugs que el Outlook Express y encima trae alguno nuevo.

con 59 comment(s)
Archivado en: ,

Para aquel que no lo sepa, FUD es el acrónimo de Fear Uncertainty Doubt en inglés, y es uan expresión que se utiliza cuando alguien dice algo que no es cierto con la intención de causar daño. Pero si a uno le confirman bien confirmado, y encima se asegura por doble partida con referencias de buena mano, pues a veces expresa lo que no tiene que expresar.

1.-Windows Vista
También está de moda ahora en estos blogs emitir una lanza en defensa del nuevo Windows Vista. Hay varios blogs que están emitiendo su defensa, todas ellas a mi modo de ver plenamente justificadas y cabales, así que, pese a parecer el malo de la película, me sumo a las alabanzas.

Recientemente escribí una entrada aquí quejándome de las licencias enormemente restrictivas que Vista va a tener. Realmente continuo ignorando la certeza de si todo lo que dije es cierto o no, pero hay cosas que, vistas con mis ojos y contadas nuevamente por gente desinteresada, no son ciertas.

Lo que puedo afirmar que contradice mis anteriores afirmaciones es:

  • Las versiones OEM se pueden instalar las veces que se quiera sobre el mismo equipo.
  • Si cambias un componente importante en una versión OEM, y vista se niega a activarse, te lo activan con la típica llamada telefónica y sin ponerte pegas.
  • Puedes tener tantas copias instaladas como quieras de el mismo Vista en el mismo ordenador.

Por cierto, tal y como se prometió, el Vista se instala en unos 20 minutos (al menos en un portátil). 

Estoy a la espera de recibir un paquete retail de la Ultimate en inglés, paquete que irá instalado en mi ordenador principal. Intentaré meter tanto la versión de 32 como la de 64, a ver qué pasa. Ya contaré.

2.-Microsoft Live Mail Desktop
También en otra entrada me quejaba amargamente de este software también en fase beta. Curiosamente, y es una cosa que ni por asomo me esperaba, la gente de Microsoft se puso en contacto conmigo para ver si les podía dar más detalles sobre mis problemas con el programa (un consumo de memoria y disco salvajes).

Poca información es la que les pude ofrecer porque lo había desinstalado, pero el contacto siguió, volví a probar otra versión más moderna, y el comportamiento de esta fue bastante mejor.

Y todavía probé una nueva más. Esta funcionó bastante mal, y fue cuando me enteré de que habían retrasado la salida del Live Mail Desktop porque habían detectado ciertos problemas con ciertas configuraciones.

Sin perder el contacto con la gente de Microsoft, y sin dar tampco mucha lata, quiero pensar que mis acciones ayudaron a sacar un producto mejor y más estable.

3.-Bug en Visual Studio 2005SP1
En este blog existe otra entrada más también bastante polémica, y es la del bug con el fondo de la ficha que se corrompe solo... Pues ya no ocurre. Alguna actualización de acá a ahora lo ha solucionado... Esperemos que la de los constructores estáticos y las interrupciones también lo sea pronto.