El futuro de los UMPC alias ORIGAMI, por el visionario escariotrópico gimnésico

Tras casi un mes usando un UMPC (en conctreto el modelo de Asus), y aparte bugs y fallos del software, que los tiene y mucho (y no precisamente se deben al sistema operativo, sino a las aplicaciones de Asus, sobre todo al driver ACPI y anexos), he llegado a la siguiente conclusión:


Hasta que los UMPC no tengan el mismo comportamiento y rendimiento que una PDA, no tienen futuro alguno.


El que tenga una PDA y un UMPC sabrá a qué me refiero.

Propiedades automáticas en C# 3.0: Reinventando la rueda… poligonal

La nueva versión de C# trae una característica que se conoce como propiedades automáticas, que no es otra cosa que el hecho de poder definir propiedades elementales (es decir, aquellas propiedades sin efectos laterales que solamente son una representación de una variable miembro interna) de forma mucho más sencilla y teniendo que teclear menos código.

La característica la he visto en el blog de Wriju, en concreto esta entrada recientemente colocada. También creo que esto haya sido comentado por aquí, pero no puedo evitar la tentación de decir algo al respecto.

Usando los mismos ejemplos que aparecen en el citado blog, y resumiendo un poco, lo que en C# 2.0 se expresa como:

public class Customer

{

public Customer() { }

 

private int _CustID;

 

public int CustID

{

get { return _CustID; }

set { _CustID = value; }

}    

 

}

En C# 3.0 podría escribirse así:

public int CustID

{

get;

set;

}

Casi nada, la gente de Microsoft ha inventado una rueda poligonal, ya que dicha característica a mi modo de ver viola los conceptos de un lenguaje sintético (igual que lo violaba el C# original) y no hace más que enredar lo que otros chicos, también de Microsoft, han resuelto más que satisfactoriamente con la introducción de una palabra reservada en el lenguaje, y es que en C++/CLI existe lo que se llaman propiedades triviales. Definir una propiedad al estilo C++/CLI es tan sencillo como teclear:

property int CustID;

 

Personalmente pienso que el hecho de no introducir la palabra reservada property dentro del lenguaje C# es un defecto de diseño bastante serio, máxime cuando el lenguaje fue creado en su momento desde cero. De todos modos ignoro si existe alguna limitación o razón para no utilizar dicha palabra en el lenguaje, pero creo que no.

Clases con Clase (C#, nosecuántos)

Hoy vamos a hablar un poco de las clases. Como todo el mundo sabe la herencia sin polimorfismo no es herencia y el polimorfismo sin virtualización, tampoco. Pero puede ocurrir que malinterpretemos cierto comportamiento si no tenemos clara la estructura jerárquica de las mismas, ya que dependiendo del lenguaje que utilicemos la declaración de las mismas podría resultar confusa en algunas situaciones. C# viene en nuestra ayuda forzando nos en cierta medida a especificar el tipo de clase que queremos.


Si queremos crear una clase abstracta, es decir, aquella de la que no se puede instanciar y que meramente nos sirva de base polimórfica, debemos definirla con la palabra abstract; de esta forma el compilador sabe que no debe instanciar de ella y a nosotros nos resulta mucho más fácil identificar el tipo de clase.


También podríamos querer una clase de la cual no se pueda heredar, característica que no suele estar disponible habitualmente en otros lenguajes. En este caso tenemos que sellarla mediante la palabra reservada sealed.


Y todavía tenemos un nuevo tipo de clases cuya finalidad es la de definir un interfaz común. En lenguajes más tradicionales esto se hace teniendo lo que se llama una clase virtual pura, es decir, una clase cuyos miembros están todos asignados a cero. Pero el Net nos lo pone mucho más fácil, ya que nos permite declarar un tipo de clase llamado interfaz mediante la palabra reservada Interface.


Cuando utilizamos la herencia también nos deshacemos de las posibles confusiones a la hora de ocultar o redefinir un método mediante el modificador new, evitando así la posibilidad de tener un nombre de método que queremos nuevo pero que ya existe en alguna clase base. Si sobrescribimos algún método existente sin colocar el modificador el compilador nos avisará, y también lo hará si lo colocamos y dicho método no está en ninguna clase base. Y de igual manera que podemos ocultar un método miembro existente también podemos ocultar el nombre de una clase anidada utilizando el mismo modificador. Si queremos acceder al método culto desde nuestra clase simplemente debemos cualificarlo con su firma completa.


Es típico que la accesibilidad de una clase o de un método sea público, protegido o privado, pero el Net nos amplía las posibilidades añadiendo el acceso a interno y cambiando en cierta medida la definición de acceso público. Ahora un acceso público significa que dicho elemento o clase estará disponible globalmente tanto en el ensamblado en el cual está definida como en cualquier otro ensamblado siempre y cuando incluyamos su espacio de nombre, y el acceso interno indica que dicho elemento sólo estará disponible dentro del ensamblado actual. También podemos definir la accesibilidad protegida e interna simultáneamente.


Nombres de miembro reservados


Como cosa curiosa tenemos que decir algo sobre las propiedades, los eventos y los indexadores. Cuando definimos una propiedad que se llama, por poner un ejemplo, nombre, automáticamente quedan reservados dos nombres de método, a saber, get_hola y set_hola, independientemente de sea dicha propiedad es de sólo lectura o sólo escritura. En C++/CLI la cosa está mucho más clara y nítida, ya que somos nosotros los que directamente definimos los métodos get y set.


Lo mismo ocurre en con los indexadores, y también con los eventos. En el caso de estos últimos los dos nombres de miembros reservados son add_<nombre> y remove<nombre>. También está reservada la firma void Finalize(); utilizada en aquellas clases que dispongan de destructor.


Constantes, elementos estáticos y volátiles


El uso de un elemento estático para que sea compartido entre todas las instancias de la misma clase es ya conocido y ampliamente utilizado, pero dadas las características especiales del C# el uso de este tipo de elementos también se suele utilizar en sustitución de las constantes en aquellas situaciones en las que el uso de un elemento constante en no está definido.


Porque disponemos de elementos definidos como constantes (mediante la palabra reservada const) siempre y cuando éstos sean tipos básicos o clases-valor, y no está permitido el uso de clases referencia constantes. Esto es una limitación del motor de ejecución Net, limitación que podemos soslayar utilizando campus de solo lectura y campos estáticos de solo lectura, aunque me queda por determinar si dichos valores realmente se sustituyen en el código como números mágicos (que es el efecto deseado) o llevan consigo toda la parafernalia de la verificación de tipos en tiempo de ejecución.


Un tipo de solo lectura se declara mediante la palabra reservada readonly y debe ser inicializado en su declaración, aunque hay ciertos tipos que no podrán serlo. En este caso debemos definirlos como estáticos y de solo lectura mediante el uso de las palabras reservadas static readonly, y en este caso podemos realizar su inicialización en el constructor estático o directamente durante la declaración.


Personalmente opino que todo lo de arriba no es más que una deficiencia del lenguaje C#, que muy bien podría haberse solucionado ampliando el uso del preprocesador o la inclusión de las características pertinentes dentro del motor Net.


En contrapartida con todo lo anterior disponemos de las variables volátiles, que deben ser utilizadas para los tipos básicos que sean modificados por varios hilos, evitando así toda la parafernalia de objetor de sincronización y semáforos.


Pasó de un número variable de argumentos


Tradicionalmente se ha permitido que lenguajes de muy alto nivel (y también de muy bajo nivel) permitan alguna forma de pasar un número variable de argumentos en un método. El C# lo soluciona de forma elegante aunque a mi modo de ver bastante limitada.


Si queremos que un método pueda recibir un número variable de argumentos tan sólo debemos especificar en su firma que va a recibir un array de una sola dimensión. La implementación de dicho método deberá recorrer todos y cada uno de sus elementos de la matriz y realizar las acciones oportunas con cada uno de ellos. Dadas las características polimórficas del C# si pasamos un array de objetos podremos convertir fácilmente estos a su tipo real mediante reflexión.


A la hora de llamar a este método podremos hacerlo tanto mediante el uso de un array como por el número de parámetros adecuado como se muestra en el fragmento de código siguiente.


void HazAlgo(params object[] args)
{
  
foreach(object o in args)
    

}

Object[] o=new object[]={1.»dos»,3,»cuatro»};
HazAlgo(o);
HazAlgo(1,»dos»,3,»cuatro»);

El caso de los bytes perdidos

    Hola, ínclito lector. Espero que seas paciente conmigo, ya que tengo que hablarte de algo bastante importante y que seguro te afecta en la misma medida que lo hace a mí. Pero antes de entrar en materia tengo que justificar y explicar algunas cosas, así que espero que leas lo que viene si no con interés porque te resulte ya conocido, sí al menos con cierta condescendencia hacia este penitente del teclado. En fin, vamos allá.

    La unidad básica de información es el bit, que es un uno o un cero, aunque la representación real pueda ser diferente, como un flanco de subida para el uno y uno de bajada para el cero. O al revés. O incluso mediante lógica negativa se puede representar un 1 como ausencia de tensión y un cero como presencia. A nivel lógico no nos importa mucho, ya que de la forma que se represente el contenido de información es el mismo.

    Históricamente los bits se agrupan en bytes, que son 8 bits juntos. No vamos a entrar en muchos detalles en por qué se implementó de esta forma y no, por ejemplo, que 10 bits formaran 1 byte. El hecho, igual que antes, es que a un grupo de 8 bits se le asigna el nombre de byte y dicho byte se trata como la unidad básica de información en informática.

    Con 1 byte podemos representar hasta 255 valores diferentes aparte del cero mediante combinaciones de ceros y unos. Empezando con 00000000b para el cero, siguiendo con 00000001b para el número 1, 00000010b para el 2, 00000011b para el tres hasta 11111111b, que representa el número 255 (o -127, según se mire, pero de nuevo no vamos a entrar en detalles).

    Otra forma de representar un byte es mediante números hexadecimales, es decir, números en base 16, en los que por convención los dígitos válidos son 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. Si nos fijamos un poco observamos que el número binario 11111111b se puede representar como FF en hexadecimal. O como nos gusta a los informáticos: 0xFF.

    Pero lo más curioso del tema es que 28 es el número de valores posibles que caben en un byte, es decir, 28=256 (o sea, 255 más el cero). Si nos damos cuenta el número es 256 y no 250, porque estamos trabajando en números binarios y al hacer la conversión matemática y real es lo que nos da. Y no podemos modificar la matemática porque es así. Lo que sí podríamos hacer es crearnos un sistema numérico en el que 28 fuera 250. Pero no valdría para nuestro universo.

    Siguiendo con el tema, si juntamos dos bytes uno al lado del otro, obtenemos un número que se puede representar con 0xFFFF en hexadecimal o bbbb bbbb bbbb bbbb en binario, en donde cada b representa un uno o un cero. Y su valor máximo, o el máximo número de valores que podemos guardar ahí son 28x28, es decir 28+8=216=65536. Y no 65000. Y son matemáticas casi de escuela primaria.

    Pero adelantemos un poco. ¿Qué ocurre si medimos en cantidad de miles de bytes en lugar de en bytes, subiendo la escala tres órdenes? A poco que uno sea riguroso pensando, deducirá que un kilo-byte son 1024 bytes. Es decir, 1KByte=1024Byte. Veamos por qué.

    Si trabajamos en metros y queremos pasar una cantidad a kilómetros, multiplicamos por 1000, es decir, por 103. En otras palabras, elevamos al cubo la base numérica. Pero lo que en base decimal es fácil, en base binaria no lo es tanto. Y tenemos que sumergirnos en razones históricas sobre el diseño y la arquitectura de los ordenadores. Intentaremos ser breves.

    Tradicionalmente la construcción de computadores ha sido muy cara, y más cara todavía la construcción de memoria. Toda la informática está basada en lo que se conoce como báscula (latch en inglés) lógica, generalmente de tipo D. Una báscula representa 1 bit. 10 básculas, 10 bits. Pero con 10 básculas podemos guardar 210 números diferentes, que son 1024 valores. No 1000 ni 1100. Y en la época en la que se diseñaron los primeros ordenadores, desperdiciar 24 números de cada 1000 era un derroche impensable, aparte de que calculando así obtenemos más ventajas que no son observables a simple vista, pero que están ahí. Como evitarnos lógica física (o sea, electrónica) para evitar esos 24 números que nos sobran.

    ¿Qué ocurre si juntamos un grupo de 8 básculas y las optimizamos para que sean 1 byte (que llamaremos por simplicidad báscula-8) y luego juntamos grupos de 10 básculas-8? Pues que tenemos 1024 formas de almacenar 1 byte. No 1000 ni 1100. Y volvemos al tema anterior del desperdicio de esos 24 números posibles.

    Quizás no sea la combinación perfecta, pero es la que hay. En su momento se decidió por agrupar los bits en atados de 8 para que cupieran exactamente dos dígitos hexadecimales, y luego agrupar dichos atados de 8 bits en atados de 10. Podrían haber agrupado dichas básculas-8 en grupos de 8, pero entonces habría que trabajar en números octales, y estos no presentan las ventajas de los hexadecimales (de hecho en un tiempo se trabajó con ellos, pero rápidamente fueron descartados). También podrían haber agrupado los bits de 10 en 10, pero ocurría lo mismo, los números no cuadraban de forma «mágica».

    Y si agrupamos 10 grupos de 10 básculas-8 por cada báscula-8 en una especie de matriz de dos dimensiones obtendremos 210x210 bytes, es decir, 1024×1024 o lo que es lo mismo, 1.048.576. Y si lo ajustáramos a nuestro formato decimal, ahora estamos perdiendo 48.576 «celdillas mágicas» por un quítame allá esas pajas.

    Hay más razones para estos agrupamientos, como el hecho de que 210 es un número natural dentro del sistema de numeración en base 2, mientras que el número 103 no tiene representación directa. También está el hecho del direccionamiento físico de las líneas de datos y direcciones dentro de un microprocesador y de una memoria, pero vamos a detenernos aquí.

    Así que ocurrió lo que tenía que pasar: 1KByte pasó a ser 1024Bytes, la correlación era instantánea y prácticamente irresistible. Y 1Mbyte = 1024 Kbyte. Y así subiendo de escala.

    Trabajando así tenemos dos ventajas a la hora de fabricar chips de memoria: tenemos una cantidad de celdas extra (y gratis) y encima el proceso de fabricación es más sencillo. El Sistema Internacional de Pesas y Medidas ha protestado, pero no ha regularizado porque es absurdo forzar la escala decimal, absurdo y muy caro en implementación física. Y a fecha de hoy, hablando dentro del mundo de la informática, un kilobytes son 210=1024 bytes, por mucho que algunos rabien.

    ¿Pero qué ocurre cuando vas a una tienda a comprar un chip de memoria para tu ordenador? Llegas al mostrador y pides un módulo de «un giga». ¿Y qué te venden, medido en bytes? Pues 1 GByte = 1024 MByte = 1024×1024 Kbyte = 1024x1024x1024 Byte. O 1 GByte = 210 MByte = 220 Kbyte = 230 Byte. A fin de cuentas, te están vendiendo 1.073.741.824 bytes. Y desde luego si ese módulo llevara 1.000.000.000 seguro que reclamarías esos setenta y tres mil y pico bytes que faltan. Además, fíjate que podrías comprar 512 «megas», no 500, sino 512. O 256, pero no 250.

    Sin embargo, veamos qué ocurre cuando vas a comprarte un disco duro. Llegas a la tienda y pides uno de 120 «gigas». Vas todo contento, lo montas y… descubres que ¡sólo tiene 111,79! ¿Y eso? Te faltan 8,21 GB. ¿Se perdieron por el camino? No, porque cuando lo instalas y lo formateas en una sola partición descubres tus 120 GB. Pero 120 justitos, justitos.

    Vaya. Haciendo cálculos descubres que 120 GB son 128.849.018.880 bytes. Sin embargo tu disco duro sólo tiene 120.000.000.000 bytes. Imagina que compras un módulo de memoria de un «giga» que solo tuviera 1.000.000.000 bytes. Pues es lo mismo.

    ¿Qué está pasando aquí?, te preguntas. La respuesta es fácil: los fabricantes de discos duros han decidido por su cuenta y riesgo que 1 KB son 1000 bytes. Y que 1 MB son 1000 KB. Y ellos te venden un disco duro de 120 de «sus gigas», no de los «gigas» que todos conocemos.

    Si uno va a una tienda y compra una cinta métrica de 1 kilómetro (suponiendo que las haya) le venden una tira de tela que mide 1000 metros. No mide 1024 metros. Porque hablamos de metros, no de bytes. Si las cintas métricas se midieran en bytes, de seguro que los tendría. Y para muestra, los módulos de memoria, que también se miden en bytes.

    Desde luego que yo me siento no solo insultado, sino también robado. Me están vendiendo algo que no es lo que ofrecen. Porque me están vendiendo un disco duro de 111 Gigabytes como si fuera de 120. Y la pérdida aumenta considerablemente conforme aumentan las capacidades. Los 320 «gigas» comprados son en realidad apenas un poco más de 298. ¡Joder, me han quitado casi 22 «gigas»! Por su cara bonita.

    Y esto no sólo ocurre en España, el país de los «pobrecitos habladores», sino que es algo completamente generalizado a nivel mundial. Se aprovechan de nosotros. Y encima nosotros tragamos como tontos. ¿Has comprado un disco duro recientemente? ¿Sí? Pues hala, otro tonto más al bote. Yo la última compra que hice fue de cincuenta. Y pagué sin rechistar (bueno, pagó mi empresa). Y la próxima será de por lo menos cien unidades. Cien veces tonto y cien veces robado. Y los fabricantes de discos duros partiéndose el culo de risa a nuestra costa.

    Pero todavía hay más, al menos en España. Si vas a una tienda y compras un rollo de 5 metros de papel de aluminio que realmente tiene 4,99 el fabricante está cometiendo un delito. Está estipulado en la ley. Los fabricantes de discos duros también la están violando. Te están vendiendo algo de un supuesto tamaño que realmente tiene menos. Y estás pagando por el tamaño total. Delito con todas las palabras de la ley.

    Y no se trata de 10 milímetros. Se trata de magnitudes mayores. Y sin embargo nadie hace nada. Bueno, algunos tontos nos dedicamos a patalear, pero con eso nos quedamos. Aunque al menos no tragamos, por lo que quizás seamos menos tontos que los que compran sin rechistar. O más. Porque encima de tragar, dedicamos dos horas a escribir cosas como estas.

    Además, los fabricantes no pueden excusarse en que siempre ha sido así en los discos duros. Hace unos años los tamaños eran los reales, no como ahora. Simplemente se juntaron y decidieron cambiar las normas unilateralmente. Y creo que eso también es delito. Y nosotros sentados en nuestra silla, felizmente ignorantes de que nos roban nuestra energía (el dinero es trabajo, que al final es un gasto de energía), mientras que ellos se van al Caribe con la modelo de turno con el dinero extra que nos han sacado.

    En fin, que ahí queda dicho. Para quien quiera escuchar.

Forzar la carga de drivers no firmados en Windows Vista x64

Corrección
Para escarnio y pública befa propia, lo escrito más abajo, por desgracia,


no funciona


Y que conste que lo he comprobado. Pero me parece a mi que se trata de la misma opción que arrancar pulsando F8, es necesario ejecutarlo cada vez que queramos que el siguiente reinicio sea con drivers sin firmar… En fin, que en lugar de borrar la entrada la dejo para rechifla propia y ajena.


Ahora el texto original:
En primer lugar decir que la idea o el truco no es mío, sino de un tal John Savill, alias JSI, MVP de Microsoft. La entrada original se puede encontrar aquí; también comentar que el truco lo he visto en los grupos de noticias de Tella, publicado por Peni y confirmado por mi mismo (ya puedo cargar mi WebCam Genius GE111 sin tener que estar presionando F8 cada vez que reinicio Vista –que realmente no son tantas) y por Javier Inglés, otro MVP.


La firma de controladores es una nueva característica que dispone la versión de 64 bits de Windows Vista; con ella se pretende evitar la instalación inadvertida de drivers defectuosos o no deseados, y por extensión cualquier otro software de sistema potencialmente dañino.


El primer paso para habilitarla o deshabilitarla consiste en abrir una consola de comandos con permisos elevados. Para ello nos vamos al menú inicio y buscamos el enlace directo a ella y con el botón derecho del ratón la lanzamos con permisos de administrador.


Para forzar que sólo se carguen drivers firmados debemos teclear en ella lo siguiente:


bcdedit /set nointegritychecks OFF


Y para permitir tanto la carga de drivers firmados como no firmados lo que tenemos que teclear es:


bcdedit /set nointegritychecks ON


Una vez cambiada cualquiera de estas dos opciones sólo tenemos que reiniciar para que nuestro cambio sea efectivo.

Más cosas curiosas sobre el C#

    Voy a comentar más cosas curiosas que estoy descubriéndole al C# y que quizás los expertos del lenguaje vean como obvias, pero que personalmente considero son bastante interesantes. Vamos allá.


La sentencia switch 
    Esta sentencia es muy curiosa (y muy potente, quizás más que su equivalente en C++). Lo más curioso de todo es que se puede utilizar una cadena (del tipo string como valor comparativo. Algo así:


switch(miCad)
{
    case «Hola»: 
        break; 
    case «Adiós»: 
        break; 
    default: 
        break;
}


    Y no es una característica pobre el poder hacer esto, que tradicionalmente se suele hacer mediante la concatenación de condicionales.


    Otra cosa curiosa es la imposibilidad de «caer a través» de un case, lo que si en principio puede parecer una limitación, realmente no lo es, porque existe una forma correcta de «caer» y que, al contrario que con otros lenguajes, no es propenso a cometer errores. Porque amigos, el error más común en una sentencia swtich es que se te olvide un break, y dicho olvido puede causar interesantes efectos laterales no deseados que pueden causar una buena tanda de problemas. Veamos un ejemplo:


switch(f)

    case 1: 
        CasoUno();    //Error, falta break 
    case 2:
        CasoDos(); 
        goto default; 
    case 3: 
        CasoTres(); 
        break; 
    case 4: 
        CasoCuatro(); 
        goto case 2; 
    case 5: 
    default: 
        break;
}


Menuda máquina de estados, está más liada que el pelo de un indigente. En el caso 1 tenemos un error, pues estamos «cayendo» sobre el caso 2. En el 2, tras ejecutar el método, saltamos al caso por defecto. Y finalmente en el caso 4, tras ejecutar el método, volvemos al caso 2. Como cosa curiosa decir que la forma del caso 5 está permitida para agrupar casos con el mismo comportamiento. Muy bonito y muy potente.


Además, los casos no tienen por qué estar ordenados, el compilador ya sabe por cuáles ha pasado y por cuáles no. Menuda gozada.


Alias para espacios de nombres
Con esta característica lo mismo sorprendo a alguien. Seguro. Podemos definir espacios de nombre (namespace) que son alias de otros espacios de nombres. Es un tema curioso y que creo que ni el C++ ni el C++/CLI tienen. Veamos un ejemplo:


namespace N1.N2

    class A{}
}


namespace N3

    using R=N1.N2; 
    class B:R.A{}
}


Observamos que la clase B hereda de la clase A del espacio de nombres N1.N2, pero lo hemos hecho utilizando un alias.


Las reglas de manejo de todo esto están explicadas en las páginas 266 y siguientes del The C# Programming Language que he citado por aquí en otros momentos. Son unas reglas un tanto pejigueras, puesto que no permiten anidación y están limitadas dentro de un espacio de nombres, pero bueno, ahí están para ser utilizadas.


Bloqueos y chequeos
Tenemos dos sentencias que permiten establecer la verificación de los cálculos matemáticos, lo que en ciertas aplicaciones científicas o comerciales pueden ser de gran ayuda. Si colocamos una serie de sentencias dentro de un bloque checked su interior será verificado por el compilador y el entorno de ejecución, generando excepciones en los casos que sea necesario o incluso impidiendo la compilación en los casos en los que la verificación puede comprobarse en tiempo de compilación. Con unchecked hacemos justo lo contrario. Y tenemos estas dos opciones porque podemos decir que nuestro código sea chequeado y tener partes no chequeadas y viceversa en las opciones del proyecto. También hay que tener en cuenta que los bloques verificados se ejecutan más lentos.


Podemos bloquear una variable y ejecutar un bloque de código con dicha variable bloqueada. Es una característica interesante aunque peligrosa si estamos utilizando hilos, porque podríamos bloquear la aplicación indefinidamente si dos hilos bloquean simultáneamente la misma variable, así que hay que andarse con ojo con esta característica, y mejor es utilizar otras opciones de sincronización ofrecidas por el sistema operativo o las bibliotecas de clases.


Me voy
El C# como todo lenguaje que se precie tiene la instrucción goto, aunque aparte del uso ya explicado poco sentido le veo; yo suelo usar goto cuando programo hardware (micros sin sistema operativo, interrupciones físicas, etc.), pero en un lenguaje de alto nivel (o con C/C++ pero en programas de alto nivel) la verdad es que dicha instrucción se desvirtúa.


Usando el uso
Esta característica me gusta poco aunque la considero útil. En mis programas en C++/CLI uso la destrucción determinista, pero en C# no se puede hacer. Para forzar la destrucción de recursos no manejados debemos utilizar la sentencia using, aunque personalmente nunca la he usado… pero no me olvido de cerrar el recurso abierto.


Un ejemplo de libro sobre este uso sería:


Using(TextReader r=File.OpenText(«hola.txt»)) { 
    String s; 
    While((s=r.ReadLine())!=null) { 
        Console.WriteLine(s); 
    }
}


Lo curioso de este ejemplo es que la sentencia while genera un warning en la asignación de s, pero no tiene nada que ver con lo que estamos explicando.

Por fin llegó la cosecha… digo tengo mi ORIGAMI.

Fe de erratas (que no de ratas)
Parece ser que ha habido un fallo de comunicación entre Tella y yo y me comenta que el Samsung tiene las mismas opciones de pantalla que el Asus, y que el Samsung viene con una sola partición.


El Texto Original:
Por fin tengo un ORIGAMI. Bueno, lo tengo desde hace dos semanas, así que ya puedo hablar con conocimiento de causa sobre él. Pero antes os voy a contar la historia de su compra.


El que lea esta bitácora habitualmente recordará una entrada que puse hace tiempo sobre mi intento infructuoso de conseguir un ORIGAMI. Lo cierto es que no ha llovido mucho desde entonces, y parece ser que el retardo sólo venía motivado por la obligatoria adaptación al mercado español que todo aparato debe sufrir, como la traducción de los manuales y la castellanización. Desde hace cosa de dos semanas es habitual ver en muchas tiendas las dos versiones más comunes de estos aparatos: el Asus R2H y el Samsung Q1.


Cansado de pedírselo mi proveedor de hardware y aprovechando un viaje a la capital de las Españas, decidí tomarme un día libre y recorrer unas cuantas tiendas. Y de paso, conocer a algunos impresentables que por aquellas latitudes moran, como Octavio Hernández y José Manuel Tella Llop. Con José quedé a media tarde, y con Octavio para la noche.


Bueno, una vez auto presentarnos, José y yo nos fuimos de tiendas, dimos una vuelta por la fnac y por el corte inglés mientras hablábamos de nuestras cosas; evidentemente, también cayó algún que otro golpecico.


En ambos lugares tenían el Samsung Q1, así que nos dedicamos a cacharrear un poco con él. Ambos quedamos gratamente sorprendidos por el rendimiento del trasto pese a su tamaño y escasas características. Por ejemplo, la carga del acrobat reader 7 apenas tardaba unos segundos, y la pantalla, aunque pequeña, tenía una gran calidad.


Yo quedé en volver al día siguiente, que también lo tenía libre, para adquirir el aparato (más que nada necesitaba ir al banco y sacar la pasta). La tarde y noche continuó desarrollándose a buen ritmo y mejores resultados.


Al día siguiente, tras pasar por caja, el que suscribe se presentó en el centro de Madrid y justo cuando iba a entrar por la puerta de la fnac para comprar el ORIGAMI, lo llama su proveedor de hardware para decirle que el martes recibía el Asus. Tras una conversación bastante insultiva (como tengo confianza con él y le conté lo que estaba a punto de hacer), me di media vuelta y me fui a otros menesteres. Porque la diferencia entre el Samsung en la fnac y el Asus en casa de mi proveedor era de aproximadamente 500 €.


Lo más chocante del caso es que cuando volví a hablar con José me contó que no había podido resistir la tentación y se había comprado el Samsung.


Bueno, pues tras dos semanas de uso de ambos aparatos por parte de José y mía, os voy a contar algunas cosas sobre ellos.


El ORIGAMI
Cuando uno compra uno de estos aparatos conoce de antemano el tamaño de la pantalla por lo que no ha lugar a quejas sobre el, aunque sí sobre su calidad. Parece ser que la pantalla del Samsung es de mayor calidad que la del Asus, ya que en la de éste puede verse la pantalla táctil con una especie de nieve que la recubre. Sin embargo, el Asus soporta más modos de resolución; tenemos la resolución nativa de 800 por 480, y dos más ampliadas de 800 por 600 y 1024 por 768. La ventaja del Asus esta en que dichas resoluciones pueden mostrarse tanto ajustadas al tamaño real de la pantalla como en forma de escritorio virtual en el que la pantalla real es una ventana que se desplaza a lo largo de todo el escritorio. En el Samsung sólo tenemos la segunda opción.


Otro tema un poco delicado es la duración de la batería, con el cacharro a pleno rendimiento apenas aguanta tres cuartos de hora, pero desconectando todos los periféricos y a un brillo de pantalla razonable, la duración se alarga hasta casi las dos horas. Quizá sea éste el peor punto de todos.


El rendimiento está a la altura de las expectativas y a veces lo supera. Enchufado a la red eléctrica o con batería pero al máximo rendimiento la carga de, por ejemplo, Excel, apenas tarda cuatro segundos en ambos modelos, y eso que el Asus sólo tiene 512 MB de RAM mientras que el Samsung llega al giga.


La conexión wi-fi es instantánea, y del bluetooth no puedo decir nada porque todavía no lo he probado. La carga del sistema operativo se hace eterna, pero con las opciones de suspender o de hibernar el encendido del aparato no es demasiado traumático.


Ambos dispositivos traen un disco duro de 60 gigas, y ambos lo traen dividido en dos particiones, una para el sistema operativo y otra para datos.


Más cosas sobre el Asus
Que es el que yo tengo y el que he probado más a fondo. Inicialmente el desempeño del aparato a era desesperante en cuanto a velocidad y a funcionamiento, con algún que otro cuelgue.


Lo primero que hice fue desinstalar toda la morralla del norton con lo que el aparato ganó bastante en rendimiento (Supongo que Symantec pagará a los OEM para que pongan su programa, porque es la única explicación que encuentro para ello). Luego fui mirando todos esos programas chorras que los fabricantes incluyen pensando en que mejoran la experiencia del usuario pero que realmente lo único que hacen es joder la marrana. Al final dejé el Asus Update, el controlador de pantalla de intel sin el cual los modos de pantalla no funcionan correctamente, y el controlador de wi-fi de Asus, que permite apagar y encender tanto el wi-fi como el bluetooth mediante la pulsación de uno de los botones que trae el aparato. También dejé la aplicación de seguridad integrada que permite manejar el ORIGAMI con la huella dactilar.


Tras pasar Windows Update, instalar PerfectDisk y darle un par de pasadas con él, el equipo empezó a funcionar bien de verdad. También le he instalado el Office 2007, y es toda una gozada utilizar el OneNote.


Pero tiene sus pegas. Tras un encendido completo el botón de apagar o suspender no funciona, es necesario suspenderlo por lo menos una vez mediante el menú inicio para que las siguientes suspensiones o hibernaciones se produzcan al pulsar dicho botón. También desaparece a veces el indicador de la batería, lo que me hace pensar que hay algún problema con el sistema de ACPI. Otro detalle más es que, igual que pasa con mi portátil grande, tras diez o doce hibernaciones se le va la cabeza y se hace necesario un reinicio completo (cosa que con mi PC de escritorio no pasa). Otras veces no guarda la configuración de la pantalla. Por lo demás el funcionamiento es impecable. Y me temo que el culpable de todo esto sea el sistema de seguridad de Asus. Ya veremos qué puede más, si pasar el dedo para iniciar la sesión o lo otro.