¿Por qué es tan difícil crear un Delphi de 64 bits?
compiler-construction 64bit (8)
Allen Bauer, de Embarcadero, también dijo recientemente que tenían que implementar el soporte de excepciones de manera completamente diferente para 64 bits "debido a diferencias en la excepción ABI en Win64".
Internet está lleno de desarrolladores que solicitan un Delphi de 64 bits y usuarios del software Delphi que solicitan 64 versiones.
- delphi 32bit: 1.470.000 páginas
- delphi 64bit: 2.540.000 páginas :-)
Es por eso que me he estado preguntando por qué Embarcadero aún no ofrece esa versión.
Si fue fácil de hacer, estoy seguro de que ya se habría hecho hace mucho tiempo. Entonces, ¿cuáles son exactamente las dificultades técnicas que Embarcedero necesita superar?
- ¿Es el compilador, el RTL / VCL o el IDE / Debugger?
- ¿Por qué el cambio de 32 bits a 64 bits es más complicado de lo que fue para Borland cambiar de 16 bits a 32 bits?
- ¿El equipo de FPC enfrenta problemas similares cuando agregaron soporte de 64 bits?
- ¿Estoy supervisando algo importante cuando creo que crear un Delphi de 64 bits debería ser más fácil que Kylix o Delphi.Net?
He oído que querían una reescritura completa del compilador sin perder la compatibilidad con versiones anteriores. Teniendo en cuenta que no hay una descripción de sintaxis completa del idioma (lo he pedido, pero no lo han hecho, así que puse el mío a disposición del público en general). Puedo imaginar que la documentación no es tan completa como lo querían. Entonces probablemente estén intentando invertir su propio código de ingeniería inversa.
Soy un firme defensor de Delphi, y creo que 2009 y 2010 son excelentes lanzamientos (comparable con el sólido # 7). Pero la falta de soporte de 64 bits los va a matar al final.
Volviendo a la pregunta, el mayor problema debería ser el compilador. El cambio de 16 a 32 bits fue más fácil porque había menos legado (Delphi 2 tenía 32 bits y el lenguaje Object Pascal era mucho más simpeler de lo que es ahora). No estoy seguro acerca de Pascal gratuito. Tal vez su código era fácil de portar. Tal vez perdieron cierta compatibilidad con versiones anteriores. Para estar seguro, puedes preguntarles.
Los problemas reales no son técnicos. Borland / CodeGear primero, luego Embarcadero, muestran que no les gusta mantener más de una versión de Windows de Delphi. Retrasaron el conmutador Unicode hasta que pudieron descartar por completo el soporte del sistema operativo Ansi. En realidad, tendrían que admitir tanto un compilador / biblioteca de Win32 como un compilador / biblioteca de 64 bits porque hay una combinación de sistemas operativos Windows de 32 y 64 bits. Creo que están intentando retrasarlo tanto como sea posible para evitar mantener los bits de 32 bits tanto como pudieran. El compilador Delphi se hizo bastante viejo y difícil de mantener, pero deciden reescribirlo apuntando a sistemas operativos que no son de Windows, y estoy seguro de que el controlador iba a portar algunas herramientas de base de datos de Embarcadero a plataformas de 32 bits que no son de Windows, ignorando las necesidades reales de los clientes de Delphi. y retrasar de nuevo el compilador de 64 bits y la biblioteca en un intento multiplataforma hecho de nuevo intentando cortar las esquinas para entregarlo rápidamente, y con ello condenados a fallar una vez más. Obstinadamente, no quieren cambiar a un ciclo de publicación de dos años porque quieren dinero en efectivo fresco cada año, a pesar de que cada vez es más difícil lanzar mejoras realmente bien hechas en un ciclo tan corto, y se necesitaron casi cuatro años para solucionar los problemas introducidos con Cambios de Delphi 2005 A su vez, tienen que poner a los desarrolladores a trabajar en traer mejoras "menores" para justificar las actualizaciones, en lugar de trabajar en cosas de 64 bits completamente.
Para las cosas que había leído en los foros, creo que la principal demora fue que el compilador de 32 bits no se podía adaptar fácilmente a 64 bits, por lo que tuvieron que escribir un nuevo compilador con una estructura que permitiera trasladarlo a los nuevos plataformas fácilmente. Esa demora es bastante fácil de entender en ese campo.
Y lo primero que el nuevo compilador tuvo que hacer es dar soporte a la versión actual de Windows de 32 bits antes de apuntarla a 64 bits, por lo que la demora adicional también es fácil de entender.
Ahora, en el camino hacia el soporte de 64 bits, Embarcadero decidió apuntar a MacOSx de 32 bits, y esa decisión es algo que algunas personas no entienden en absoluto. Personalmente creo que es una buena decisión de marketing para el punto de vista del negocio de Embarcadero (espere, no digo que el soporte de 64 bits sea menos importante , lea atentamente, no estoy hablando de importancia sino de comercialidad). Esa es una demora extra muy controvertida en el camino a 64 bits (además Embarcadero dice que tienen equipos que trabajan en paralelo, en los hechos hay una demora, al menos para problemas de versiones -marketing nuevamente-).
También es bueno tener en cuenta que FPC no es un producto comercial, por lo que pueden agregar / eliminar características más fácilmente que Delphi.
Sé que está preguntando por los problemas técnicos, pero creo que el departamento de marketing podría ser el problema más importante ... Estoy seguro de que se emocionan mucho más ante la perspectiva de nuevos mercados que atraigan a nuevos clientes y así logren cambiar las prioridades. Un problema (en mi opinión) es el mal historial: hemos visto kylix y delphi.net en el pasado que fueron ambos ehm kylixed. Me imagino que los nuevos clientes esperarán y verán si está por quedarse y eso a su vez podría decidir que el embarcadero lo deje prematuramente.
Dicho esto: sin duda hay algunos problemas y consideraciones de diseño para x64 y solo espero que el equipo de Embarcadero comparta sus ideas sobre ellos y debata con la comunidad (para evitar problemas como lo que hemos tenido sobre el cambio Unicode).
Si no fuera por la limitación en las extensiones de shell (tengo una que se carga en Windows Explorer), probablemente nunca me importaría 64. Pero debido a esta limitación, la necesito, y la necesito ahora. Entonces probablemente tendré que desarrollar esa parte en Free Pascal. Es una pena, aparte de esto, hay algunas aplicaciones que realmente se beneficiarían de 64. OMI, la mayoría de los usuarios están bebiendo coolaid o están enojados por haber sido engañados para comprar algo que sonaba genial pero que se convirtió en un dolor de cabeza. Conozco a un tipo que está contento de ejecutar Win7 / 64 por lo que tiene suficiente memoria RAM para ejecutar una copia completa de XP en una máquina virtual, que no necesitaría si hubiera obtenido Win7 / 32 como le dije también. : - <
Creo que todo el mundo ha sido engañado por los fabricantes de HW, en particular los distribuidores de RAM, que de otro modo tendrían un mercado muy blando.
De todos modos, volviendo a la pregunta que nos ocupa ... estoy atrapado entre una roca y un lugar duro. Mis clientes me están exigiendo, debido a una decisión de arquitectura de M $ (no permitiendo archivos DLL de 32 bits en Windows Explorer) y problemas de percepción (64 bits debe ser el doble de 32, o quizás 32 deben ejecutarse en el "núcleo de penalización" o algo así). Así que estoy siendo motivado por una motivación en gran parte "artificial". Y por lo tanto, debo proyectar eso en Embarcadero. Pero al final, la necesidad de soporte de 64 bits en Delphi es IMO, principalmente basada en BS. Pero van a tener que responder, al igual que yo.
Supongo que lo más cercano que he visto a una "respuesta" a su pregunta desde el punto de vista de Embarcadero se resume en este artículo sobre el futuro del compilador Delphi por Nick Hodges.
Ya hay un Delphi de 64 bits (Object Pascal). Se llama Free Pascal . Entonces, aunque no tengo dudas de que es difícil, no es "tan difícil" que no sea factible. Por supuesto, no puedo especular sobre Embarcedero.