La máquina virtual NET está podrida por dentro, 1

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).

27 comentarios sobre “La máquina virtual NET está podrida por dentro, 1”

  1. Pues comemé con patatas, pero de verdad no entiendo como encontrando tantos fallos y viendo la mierda que es, trabajas aun con ello???, y peor entre el tiempo que te hace perder y lo que te hace escribir a lo mejor te has equivocado de plataforma???

    Yo por mi parte estoy orgulloso de NET y no pienso cambiar 😉

    Salu2

  2. Joder, pues ahí está.

    Pruébalo. En un x64 compilado con AnyCPU. Y espérate que el siguiente es más gordo todavía. Y no te cuento el de los Timers. Permanece atento.

    ¿Por qué sigo trabajando con ello? Pues porque todo lo demás son mierdas mayores. El C++Builder, digo BDS, digo Turbo, digo CodePlex todavía es peor, y de linux mejor no hablemos…

    Lo único que se salva es Win32 a pelo (y supongo que MFC), pero como que si le digo a mi jefe que voy a tardar tres meses para una faena de 15 días como que me mata.

  3. Bueno…

    Cuando contabas el rollo tan grande que te hacia pasar C++/CLI ahi si te apoyaba un poco, ya que a mi tambien me parace un poco malete el IDE, pero con C# no creo que sea asi.

    Habra que practicarle un exorcismo a los equipos con los que trabajas [:D].

    Un Saludo.

  4. En la demo que has puesto para descarga, basta que inicialices el array de int valor para que no reviente cuando intentas hacer una asignación a un elemento, es decir, cambiar:

    private int[] valor;

    por

    private int[] valor = new int[10]; // Por ejemplo

    Y funciona.

    (Con la voz de la viejecita de poltergeist): La casa está libre de fantasmas

  5. Tio_Luiso, ya sé que poniendo eso funciona.

    Lo que quiero decir es que ese código mal escrito, ejecutado desde el IDE en un Vista x64 compilando el proyecto con AnyCPU

    NO GENERA NINGUNA EXCEPCIÓN

    repito:

    NO GENERA NINGUNA EXCEPCIÓN

    vuelvo a repetir:

    NO GENERA NINGUNA EXCEPCIÓN.

    Al final tendré que comprarme una cámara y grabarlo en video.

  6. Aunque en realidad no probé el código por no tener Windows Vista, IMHO, no tiene mucho que ver la máquina virtual en este problema, puesto que estás compilando para diferentes plataformas (lo cual implica que probablemente haya diferencias en el IL generado) y lo segundo, según afirmas, esto sólo se reproduce dentro del IDE.

  7. No sé si a ti te cueste tanto dinero como a nosotros en la empresa en la que trabajo, el .Net tiene un fallo entre decimal y double que nos costó millones de bolívares, pero lejos de quejarnos y seguir diciendo «oye hay un problema», empezamos a decir, «oye hay un problema y se puede solventar de esta manera».

    No seas parte del problema, forma parte de la solución, entiendo el que no quieras cambiar de plataforma, pero puedes hacer de tu influencia algo positivo.

  8. ¿Perdón? ¿Problema entre Decimal y Double?¿El problema no sería que tu no sabes la diferencia entre ambos tipos y su representación interna?
    Es que hay que joderse

  9. Rafa, cuando me asomo a la ventana… veo la columna de humo que te sale por las orejas… ¿quien ha dicho que NADA de lo que M$ sea perfecto? Ni siquiera está mínimamente cerca. Pero, tal y como dices hay cosas muuuucho peores danzando por ahí. Piénsalo bien, y uso tu mismo ejemplo:
    Win32+MFC= 3 meses.
    .NET= dos semanas de trabajo, una más de testing adicional, incluyendo cabreos varios, y una cuarta para pulirlo y quejarse, videos incluidos…

    Todavía has ahorrado 2 meses!! Y lo mejor: con el cabreo has quemado más energía.. así que .NET te ahorra tiempo y te mantiene en forma…!!

  10. Ufff… yo no tengo muy claro el tema… pero si tengo clara una cosa: El printf no está roto.

    Millones de desarrolladores usan el .Net Framework y su máquina virtual, Rafa tio si tu eres el que más problemas del mundo tiene con ella, o tienes la peor suerte del mundo o no la usas bien.

    Además, ¿es qué tu no metes bugs?. Hay que ser un poquito más humilde hombre…

    Sobre el caso que nos ocupa, puede tratarse de un bug, o de una diferencia entre arquitecturas. Quizá, y estoy elucubrando, la memoria se inicialize de manera diferente en plataform x64 de manera que sea innecesaria la inicialización o vete tu a saber. Pena no tener una máquina de 64 bits para probar cositas…

    Por cierto cualquiera puede reportar un bug a Microsoft…

    Sobre lo de girar la factura, ni te molestes, si no eres proveedor se van a limpiar el culo con ella…

    Salud!!!

  11. Yo quiero ver ese problema de Decimal y Double. Suele ser un problema muy común en programación el usarlo incorrectamente, pero me gustaría verificar que no fuera otra cosa rara.

  12. Si te sulfuras tanto por algo asi creo que te has confundido de profesión…
    ¿Nunca has trabajado con TurboC o TurboPascal? Porque cuando comencé yo era divertidísimo cuando le IDE del pascal te marcaba un error en lineas incorrectas, o petaba también sin decirte nada, o se te escapaban punteros de C. O un JBuilder de Java viejo, cuyas ventanas eran preciosas pero ponte tu luego a adaptar el código para cualquier otro compilador…

    .NET no es perfecto (incluso tiene alguna cosa que no me gusta), y el Visual Studio no será tan inteligente de pillar el 100% de errores que se te generen, pero si no te gusta la plataforma tienes más donde elegir…

    Los timers tienen su cosa, tanto que para DirectX lo mejor es fabricarte uno que llame al SO. Los threads también pueden tener sus movidas y dar un poco de guerra.
    Pero salvo que seas un monstruo de C++, ¿tardarías menos en hacer un proyecto íntegro en C++, por supuesto incluyendo testing? ¿pondrías la mano en el fuego de que no tendría por ejemplo ni un solo bug relacionado con buffers, ni un memory leak?

    Yo hay dias que me dan ganas de tirar el portatil contra la pared, pero igual que cuando hace años me fallaban los programillas en C, con la diferencia de que ahora la productividad está mucho más arriba.

    PD: Hay errores mucho más «terribles». Tu código de demo son pocas líneas y se ve «por donde anda» el error al momento. Managed DirectX 1.0 por ejemplo tiene problemas con la reproducción de Videos sobre texturas, y algunos no provocan cuelges instantáneos (uno por ejemplo hacía que la app. petara al hacer un Dispose() de la ventana al salir de la aplicación).

  13. Rafael tiene toda la razón … aqui todos defendeis al .NET, haber dejaros de historias, todos sabemos que TODOS los lenguajes tienen problemas, nada ni nadie es perfecto, y creo que esto todo lo entendemos, yo entiendo a Rafael y jode y cabrea mucho estar dedicando un huevo de tiempo a encontrar un problema cuando tienes encima del cogote a tu jefe presionandote, si encuentras el fallo y te das cuenta que es de la herramienta pues te cabrea mas.

    Rafael por su parte, además de desahogarse os expone algo que debería ser obvio y además para que ninguno caigais nuevamente y os rompais los cuernos encontrando el fallo.

    Rafael, felicidades, sigue exponiendo los fallos que encuentras e ignora las criticas chorras de esos aferrimos de .NET que para mi no son programadores son simples publicistas que no usan dicho lenguaje para su trabajo.

    Yo por mi parte uso powerbuilder desde hace ocho años y aunque me gusta opino que es una puta mierda ya que por cada build me salen me encuentro errores nuevos que en builds antiguas funcionaban y por ese motivo no voy intentando justificar tontamente lo reconfortante que me resulta mi lenguaje.

  14. Kartones, evidentemente ese bug salió en un programa a medio hacer, con unas 15000 líneas de código ya escritas, y todo porque se me olvidó inicializar una variable.

    Rodrigo, yo también cometo bugs, de hecho el descubrir esto fue por un bug mío. De todos modos no me creo que hayas dicho tu eso: ¿es una diferencia de arquitecturas que la asignación al elemento 3 de un array no lance una excepción? ¿Es que no sabes qué le está haciendo eso a la máquina virtual .NET? Podría estar cambiando cualquier valor de cualquier otro objeto que por allí pasara. ¿Usar mal el .NET en un programa con dos líneas más que el creado por el asistente? En fin, que no ve quien no quiere ver.

    Alex y Rodrigo: ¿Dónde está eso de la multipaltaforma, compila una vez, ejecuta en cualquier lugar?

    Anónimo, el C++Builder es una castaña pilonga, y encima a punto de ser abandonado. ¿Quieres bugs? Graba en debug un array de ushorts y cárgalo en release… Entonces está claro que lo que falla es lo que está encima de Win32.

    Telémaco, te quiero de verdad. Lees mi mente, je je. Aparte de que me lo paso bomba, pero eso no quiere decir que de vez en cuando no me altere… sobre todo cuando la cosa es evidente por sí misma y todavía se siguen cerrando los ojos.

    De todos modos, el asunto que voy a poner como segunda entrega ni necesita x64, ni un proyecto grande, ni nada de nada. Un constuctor estático con un error en el código fuente y poco más. Vamos, 20 líneas.

  15. Gracias Sergio Tarrillo, en efecto el error es ese, un error matemático y no, no fue un error de implementación de tipo de dato como comentan anteriormente, pero no deseo hacer polémica de ello. En cuanto a Java y el Compila una vez y ejecuta donde quieras es completamente falso, se debe compilar en cada lataforma

  16. Juan, en lo de compila una vez y ejecuta donde quieras me refiero al .NET, o eso dice la propaganda de MS (No más compilaciones para cada plataforma o algo así).

    Del Java no puedo decir nada porque lo ignoro todo por completo.

  17. Tras leer los comentarios de esta entrada, me quedo estupefacto ante algunos de ellos.

    Realmente, si Rafael ha encontrado un bug del framework, deberíamos tomar una nota mental y pensar «hay que ser cuidadosos a la hora de hacer tal y cual, porque si no, el framework me va a jugar una mala pasada».

    Y eso no tiene nada que ver con si el código es correcto o no, o con si se usa mal o bien el framework. En este ejemplo el código es incorrecto, pero .NET debería levantar una excepción (que nos puede ayudar a encontrar ese bug). Pero en este caso no lo hace.

    Nos metemos mucho con los talibanes del mundo Linux. No seamos como ellos, por favor. Los bugs en el framework existen. Pueden ser más o menos raros, y si tienes suerte, no te encontrarás con ninguno. Pero hay que reconocer que puede tener fallos, como cualquier otro desarrollo de software.

    Saludos!

  18. Por supuesto que yo al menos tomo nota, y por supuesto que reconozco que tiene fallos. De ayer mismo uno del ASP.NET AJAX RTM (que encima no estaba presente en la beta):
    http://kartones.net/blogs/kartones/archive/2007/02/26/asp-net-ajax-1-0-rtm-bug.aspx

    Yo escribí mi comentario por el tono, porque todo falla (por desgracia), pero puestos a elegir, prefiero el .NET. Aunque a veces se coma con patatas las descripciones de error o te sean de tanta utilidad como que no dijera nada. Parece por este post que el .NET sea un truño y creo que la realidad no es asi.

    PD1: Sorry por explicarme mal, me refería a que si te pones a ojear el código, algo como una no inicialización de variable se puede localizar «a ojo», a que dentro de lo malo (y de la cagada que es que no lo diga el IDE) se puede localizar directamente.

    PD2: Hablando de talibanismo, alguien ha conseguido instalar un Ubuntu 6.10 bajo Virtual PC 2007 final? Porque yo tuve que tirar de VMWare ya que (a pesar de la publicidad de MS) ni en gráfico seguro ni en modo texto se me consigue instalar en el portatil :o)

  19. Pues yo de los entornos que he probado, Visual Studio es de lo mejorcito, para que nos vamos a engañar? que bonito era hacer una interfaz gráfica con el JBuilder y que de pronto todo se trastocara… cosas dignas de un espediente X… además de que era algo que resultaba irritante…. por no decir otra cosa.

  20. Jonás, es que las herramientas de Borland claman al cielo en cuanto a todo. Hace muchos años eran los mejores, pero se han dormido en los laureles (bandazos ideológicos aparte).

  21. MALDITOS CHUPAVeRGAS EN QUE ESTAN PENSANDO, ¿EN QUE EL IDE DE VS ES BONITO??, Y GRATIS ¿QUE BONITO ES PROGRAMAR UN WINDOWS FORM ?, POR QUE CARAJO NO CHAPAN UN EDITOR DE TEXTO Y ENPIEZAN A DEJAR DE DEPENDER DE ELLO, ¿QUE TIENEN MIEDO? ODIO A ESAS PERSONAS QUE DICEN !EL IDE DE VS ES DE LO MEJORCITO! !YO PROGRAMO EN VS2008! ANIMALES, EL QUE TIRA SOLO NECESITA INSTALAR EL NET FRAMEWORK NADA MAS!!!!!!!!!

  22. Bueno es de espera que gente con poco nivel en programacion y experiencia comente esto para empezar les voy a dar una catedra de como es que fuciona .Net a ver si a si eprende un poco y dejan de escribir cosas tan mediocres como el que inicio este pos mierdero en primera .Net se ejecuta bajo un ensamblador orientado a objetos despues que se se convierte en MSIL y se ejecuta en la maquina virtual de .Net que fue creada bajo C# para demostrar un ejercicio de su potencia del lenguaje no como java que su maquina virtual esta hecha en c++ jajaja. A ver si de investigar mamadas te pones aprender a programar como puedo ver eres un programador mediocre que le gusta escribir sus frustraciones al no poder programar
    aprende primero a programar y despues que tu cerebro mierdero lo pueda solucionar te quejas pendejo

  23. Nada, Speed, «catedra-nos» todo lo que quieras, y ya de paso creas un blog y nos vas caterdalizando poco a poco.

    Y de paso te fijas en la fecha del post.

    Y para tu interés te diré que este fallo fue escalado internamente en MS y se llegó a una asombrosa conclusión, que no te voy a explicar ya que eres un experto catedrático y ya deberías saber por qué ocurre eso…

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *