Cuando están mostrando como establecer la DLL de dbExpress para 64 bits en la nueva propiedad vendorlibwin64 (librería de Win64 del proveedor de base de datos) de la conexión dbExpress (min 8:25 aprox.), justo arriba de esa propiedad viene otra llamada vendorlibosx... !! (librería Mac OS X del proveedor.. etc.)
Claro que no creo que sea una filtración casual... pero ya lo veremos en los próximos vídeos de Sneak Preview del nuevo Delphi.
Que tal Salvador, gusto en saludarte a través de tu bitácora.
ResponderBorrarAhí vienen, poco a poquito los cambios que Delphi necesita, aunque el orden en el que vienen no necesariamente es el que la comunidad demanda. Más bien obedece a las necesidades de mercado. Como sea, cualquier mejora es bienvenida.
Me llama la atención que haya dos propiedades para establecer la biblioteca (por cierto, no "librería") del motor de base de datos. Va a ser interesante estudiar el código fuente de la nueva VCL para comprender el razonamiento que hubo para no dejar solamente la propiedad de siempre (VendorLib).
Un abrazo y saludos a todo el equipo de MetaCode.
Al González. :)
¡Gusto en saludarte Al!
ResponderBorrarDisculpa lo de librería, años de mala costumbre :)
Es cierto, también desearía que Delphi hubiera logrado esto hace cinco años (¡o que Borland no hubiera intentado asesinarlo por la espalda!).
Ahora veremos, compilar nativo a Win32/Win64/MacOSX/(Linux?) es algo que nadie hace realmente bien, si Delphi lo hace, como ya volvió a ser costumbre afortunadamente, entonces puedo decir que ¡Son tiempos emocionantes!
Claro, la verdad es que Nunca es suficiente, y enseguida voy a querer desarrollo a móviles y tabletas ;)
Por lo de las propiedades de biblioteca, tal vez no habría otra forma de hacerlo mas eficiente, desgraciadamente código maquina de 32 bits forzosamente requiere sus dependencias DLL sean también 32 bits por las llamadas a funciones por dirección, memoria compartida, etc. Lo mismo aplica para 64 bits.
¡Saludos de todo el equipo!
Salvador, Al, el razonamiento que yo veo detrás de tener propiedades separadas para las diferentes plataformas es justamente que las dependencias podrían ser (y de hecho generalmente son) diferentes en cada una, pero que podremos utilizar el mismo conjunto de fuentes para compilar para varias de ellas. Al tener la posibilidad de declarar las dependencias para cada plataforma por separado, evitamos tener que realizar ajustes en tiempo de corrida dependiendo de la plataforma para la que ha sido compilado el código.
ResponderBorrarEn lo que a mi respecta, estoy apuntadísimo para la beta... ya veremos si me toman en cuenta. :)
Hola Juan Antonio! Totalmente de acuerdo, ademas de ser obligado hacerlo así, pareciera ser la mas eficiente.
ResponderBorrarQue onda mi buen Jachguate? cuando te vemos por Guanatos de nuevo? No me toco saludarte el año antepasado (estaba en el proyecto de Colima)