Si, porque hoy Windows es el sistema operativo mas utilizado y 99% de los desarrolladores Delphi desarrollan para Windows.

Podemos retomar Kylix si, estamos esperando el crecimiento de Linux en Desktop.

Hola,

¿Pero cómo se entiende esa frase con la que has dicho antes de que Delphi no quiere atarse a una tecnología? Habría que precisar ninguna tecnología, siempre dentro de Windows...

Eso podría verse de otro modo: "vamos a apoyar a Kylix, queremos que el escritorio de Linux avance". Son dos formas distintas de verlo, supongo. Aunque también supongo que si alguna vez hay mercado suficiente... como otras empresas, CodeGear también le entraría a Linux, vamos, digo yo...

Una cosa Andreano... no te pido que me respondas, pero, tampoco quiero dejar de preguntar, ¿qué hubiera sido de Kylix si hubiera pasado a ser un proyecto de código abierto? ¿Se han hecho estimaciones a este respecto? ¿No hubiera podido por ahí CodeGear sacarle algún rendimiento? Sobre todo, lo digo, porque ahora mismo parece que no le está sacando ninguno en absoluto...

Hola,

solamiente CodeGear no es suficiente para cambiar el mercado de Desktop, seria necesario un cambio de mercado en general, de muchas empresas que tienen poder de influencia en el mercado, juntas para que esto pase.

Sobre su pregunta se Kylix como un proyecto abierto, en mi opinión no tañeríamos excito, Eclipse hoy es un standard de IDE para otras plataformas, nosotros utilizamos Eclipse para JBuilder y ahora para 3rd Rail.

Gracias por tu respuesta... Yo trabajo en una empresa donde la mayoria de los clientes son ganaderos, por lo cual, los vendedores deben ir muy lejos a realizar sus pedidos, seguramente un desarrollo nativo para PDAs sería una gran solución para mejorar el tiempo de respuesta a nuestros clientes, ya que no tendran que esperar para llegar a sus respectivas oficinas a digitar dichos pedidos previamente tomados en papel, ademas supongo que tendrian mas tiempo para ir a buscar nuevos clientes :).

Entendido... Winfowms, no esta mas.
 

Bueno, ya me quedo claro... DELPHI WINFORMS.NET, no va mas.

Adreano... Hay una duda que me invade.

Que ventaja yo tengo al USAR VCL.NET, con respecto a la VCL normal??? (obviamente VCL.net va sobre el framework, es decir, necesita un intererprete, de modo que tiene una ligera desventaja contra el VCL nativo. entonces.

¿Que factores podrían hacer que yo elija VCL.NET, sobre VCL???

Saludos.

Hola,

La VCL .NET se pensó (si no me equivoco, y según recuerdo de lo que leí hace tiempo) como una especie de transición al ".NET puro". Era una forma de envolver el .NET Framework en una especie de VCL, de modo que fuera, supuestamente, más sencillo migrar a .NET.

Ahora bien, si vas a utilizar .NET... si quieres desarrollar para esa plataforma, puedes usar Delphi .NET (entre otros lenguajes), directamente, contra el .NET Framework, no tienes porqué usar la VCL .NET, incluso tal vez no sea ni aconsejable.

¿Ventajas de la VCL frente a la VCL .NET? Bueno. La VCL también es una especie de envoltorio... del API de Win32. Pero la VCL produce código nativo, no código que tenga que interpretar ninguna máquina virtual (el Common Lenguage Runtime de .NET).

Ahora bien, se supone que el API de Win32 está condenado a desaparecer... y con él la VCL, si bien esto no va a pasar mañana ni pasado. Windows Vista, por ejemplo, parece que soporta sin problemas el API de Win32. ¿Y qué pasará en el futuro? ¿Habrá un Windows .NET? Eso leí alguna vez...

Si bien yo pienso que sería un suicidio por parte de Microsoft dejar de soportar el API de Win32 en uno de sus sistemas operativos, lo cierto es que una cosa no quita la otra: quizás todas las innovaciones no vayan a Win32. Quizás los tiros vayan por .NET (de algún modo es la apuesta de futuro), quizás...

Interrogante
 

Hasta ahi, vamos bien, eso si lo sabia... eso lo tengo claro.

Usé el mismo razonamiento que tu, al iniciar el proyecto que emprendimos en mi empresa... pero ahora, existe un problema... RAD STUDIO 2007 no trae .NET de forma nativa, si no solo con VCL.NET... de modo que jamas podremos llevar nuestro desarrollo a .NET 2.0 nativo. sin VCL.NET.

Por eso preguntaba... (PREGUNTA PARA TODOS) si solo nos dejaron esas opciones... en que casos yo preferiria usar VCL.NET a usar VCL nativa. o por que razones posibles una persona preferiria usar VCL.NET a VCL (queda como sobreentendido que uno esta sobre el .NET framework) ???

Eso si que no lo sabia.. voy a leer un poco mas al respecto.

Gracias DEC, por contestar.

¡Hola a todos!

Básicamente, creo que las dos principales razones serían:

1. Integración (compatibilidad / conectividad) con otros sistemas o tecnologías basadas en .NET.

2. Asegurar más tiempo de vida, soporte y mejoras al software desarrollado, bajo el entendido de que .NET seguirá más que vigente cuando la API Win32 comience a ser etiquetada como obsoleta.

Y es que hay algo aquí que muchos no saben o ignoran a medias, y es que la VCL tradicional, al igual que muchas bibliotecas de clases y funciones "nativas" de las herramientas de programación de los últimos 10 o 20 años, encapsulan a las funciones de la API de Windows (Win32). Muchas de las maravillas que amamos de la VCL se deben a esos miles de funciones que Microsoft creó cuando la POO estaba en pañales. Y algunos de sus respectivos compiladores generan código máquina, caracterizado a veces con el término "ensamblador", el cual es ejecutado tal cual por un chip procesador.

Ahora, muchas de esas bibliotecas, en sus más recientes versiones, en lugar de encapsular llamadas a la API Win32, encapsulan a las clases de la "nueva API", conocida como .NET, y sus compiladores generan código de máquina virtual caracterizado con el término "ensamblados", los cuales quedan justo a un paso de ser código máquina-hardware. Por lo cual requieren un intérprete (término políticamente incorrecto por la mala fama de lentas que se ganaron aquellas herramientas que no generaban ejecutables auténticos, como Quick Basic, FoxPro y casi todos los lenguajes baratos de Microsoft de hace 15 años).

Como ya el hardware es muy rápido, la prioridad de conectividad / compatibilidad / integración pasa a tomar el primer lugar por encima de la antigua prioridad #1 que era la velocidad y ahorro de espacio. Antes los programadores se preocupaban por ahorrar hasta el último byte de memoria, porque 640 KB de RAM era como una cubeta de agua en las Dunas de Samalayuca, y 16 MHz de velocidad ameritaban resucitar a Albert Einstein para hacer de aquella función de búsqueda un endemoniado comparador de bits sin desperdicio de una sola instrucción de CPU.

Era obligado que algún día la hasta entonces eterna prioridad #2: facilidad para hacer e integrar software, se convertiría en lo más importante. Y es cuando surgen propuestas que antes hubieran parecido descabelladas o utópicas, como hacer programas independientes del sistema operativo (Java, .NET*) o ensamblables con programas hechos en otros lenguajes (.NET), o mejores APIs totalmente orientadas a objetos (Java, .NET).

Así pues, estos son los tiempos en que las tecnologías comienzan ese juego de coqueteo llamado "me conecto contigo, entiendo tu idioma". Después de todo, ¿quién quiere quedarse fuera de una fiesta, donde todos parecen estar pasándolo bastante bien? No se trata de alabar a Microsoft, no será gracias a esa empresa que algún día pueda tomar un teléfono celular y enviar un mensaje escrito a Japón sin problemas y con traducción automática. Falta más apertura* para llegar a ese punto. Pero el camino está iniciado. Java lo viene intentando, pero tiene una enorme desventaja en comparación a .NET: te obliga a usar un sólo lenguaje.

Muchos no simpatizan con .NET por llevar el desangelado estigma MS, pero ¿qué tal si .NET fuera de la compañía que más nos simpatiza (CodeGear, Google, Sun, Sistemas GH...)? .NET está irremediablemente destinado a abrirse, como sucede con toda tecnología útil que alcanza cierto nivel de aceptación, considerando que será el reemplazo lógico de la popular y aprovechada hasta la médula API Win32. Yo no pongo las manos en el fuego por él (ese puesto lo tiene Delphi) pero al día de hoy comienzo a interesarme en clavarle una bandera.

Un abrazo ensamblado.

Al González. :)

*.- La apertura tecnológica estandarizada de la que siempre he hablado. El futuro es el consenso, sin marcas, sin propiedad, sin imposiciones de mercado. Lo correcto antes que las ventas. Una nueva ISO que sustituya al manipulado organismo actual.

Muchas Gracias Al Gonzáles...

Me parece muy buena justificación de VCL.NET sobre VCL.

gracias nuevamente.

Saludos.

Una aclaracion:

Delphi.NET trae .NET nativo. La VCL.NET es un "wrapper" alrededor de la Win32 (para pintar controles rapidos, sin GDI+/Winforms) y las funciones normales que lo acompañan. Pero nada impide usar .NET de forma directa y es algo que se por experiencia propia en mi esfuerzo por desarrollar http://sourceforge.net/projects/mutis/

Que bien todo me a quedado muy claro, de hecho la pregunta que planteo radaalvaro tambien y por consecuencia las respuestas, tambien me ayudaron bastante a entender el "porque" de elegir .NET por encima de Win32... pero ahora tengo otra duda, si yo instalo mono en mi Linux, ¿Puedo correr aplicaciones creadas en Windows bajo la plataforma .NET?, bueno, gracias por vuestro interes en el asunto ;) :).

Algo que no tiene la VCL win32 y la VCL.NET si tiene
 

Con la VCL.NET puedes desarrollar aplicaciones dirigidas por modelos usando el framework ECO aquí unos videos de como hacerlo

ECO VCL.NET development with CodeGear RAD Studio
http://video.codegear.com/RADStudio/...COIVIntro.html
ECO IV development
http://video.codegear.com/RADStudioD...O/ECODemo.html

Por lo que sé, si una aplicación funciona en Mono también funciona en .NET, pero lo contrario no siempre es cierto. :(

1. ¿Cuando uno hace codigo en VCL.NET queda parecido a una aplicación Win32 pero bajo .NET o eso queda en APS.NET?

Queda con el mismo look and feel de Win32 pero es una app tipo .net

2. ¿Una aplicacion creada en VCL.NET puede correr en un navegador de internet?

Si usas los componentes Intraweb o la exportas como activex si puedes ejecutarla en un navegador.

sin embargo lo ideal es que uses file->New->ASP.Net web application.

3. Si ya quitaron Winforms, ¿Entonces que es esa opcion que yo veo en el RAD Studio que esta en File|New|Vcl Forms Application - Delphi for .NET?

Es para crear una aplicacion DELPHI VCL NET , no Winforms.

4. Si al hacer aplicaciones en VCL.NET no compila a .NET puro, entonces ¿Como puedo hacer aplicaciones para .NET puro usando DELPHI for .Net?

Las aplicaciones VCL.NET si son .NET "puro".


Saludos, espero haber clarificado en algo tus dudas

Lo siento Jhonny no me habia dado cuenta que te habian respondido.

Saludos

1. Una aplicacion VCL.NET tiene la misma interfase que una aplicación Win32, mas abajo esta corriendo sobre .NET

ASP.NET es para generar solamente aplicación WEB.

2. No
RAD STudio trae la version de IntraWeb para .NET, que tu puedes ejecutar una aplicacion IntraWeb sobre .NET


3. Esta opción es para crear aplicaciones VCL.NET

WinForms no es productivo para el desarrollo Delphi, la VCL.NET es mucho mejor.

4. Aplicaciones VCL.NET son .NET puro, asi como las aplicaciones WinForms en Delphi.NET, VB.NET o C# son .NET puro, WinForms y VCL.NET tiene o que llamamos pinvoke que son llamadas directo a las apis Win32

Las aplicaciones VCL.NET corren sobre .NET, el grande diferencial de .NET está en ASP.NET, que es fácil desarrollar aplicaciones para WEB, RAD Studio 2007 trae total soporte a ASP.NET 2.0 que tiene muy buenos recursos.

Este mes vamos a tener "Delphi Revolutions Day en Mexico y Guadalajara - 16 y 18 de Octubre" donde vamos hacer el lanzamiento de RAD Studio 2007.

Le invito a participar e conozer todas las novedades de RAD Studio.

El registro está disponible en http://dn.codegear.com/es

Saludos,

Andreano Lanusse
CodeGear Product Line Manager & Evangelist Leader Latin America
Blog: http://blogs.codegear.com/andreanolanusse
Exemplos: http://cc.codegear.com/Author/38483

Gracias rruz ;).

Podría ser la lenguaje, mas no, porque los nuevos recursos que creamos para Delphi .NET también hacemos para Delphi Win32.

En mi opinión desarrollo para escritorio recomiendo Win32, no recomiendo .NET.

La ventaja de tener la VCL es que su cliente exige que su aplicación sea .NET , tu tienes como compilar en .NET facilmente un proyecto VCL Win32.

No me convence RAD Studio
 

RAD Studio parece que es una herramienta fantástica, pero sólo sirve para Windows. A ver si en "beyond commodore" sacan una versión de Delphi multiplataforma porque la mayoría de los grandes servidores no se basan en Windows, sino en HP-UX, Solaris, AIX, aunque esto no quiera decir que no hayan AS/400, Windows o Linux, por ejemplo. Esto quiere decir, que el número de desarrolladores de JAVA continuará por delante de Delphi (entre otras razones).

SMTZ, Java y Delphi, tienen sus áreas de acción. Si bien Java, es multiplataforma y esta es su mas grande ventaja, pero cuando alguien quiere desarrollar algo complejo, resulta que uno pasa la vida programando muchisimas líneas de código. Para hacer algo, que con Delphi se haria en menos tiempo, por que Delphi es un RAD, obviamente, como una gran mayor parte de los lenguajes de programación. Delphi esta avocada a desarrollar sobre la plataforma más difundida hasta ahora (Windows).Por otro lado, la versión de Delphi para LINUX (Kylix), empezo a volverse inviable por diferentes factores... imaginate hacer que el lenguaje pueda generar aplicaciones para AS/400, le iria peor que con KYLIX.Saludos.