Pessoal,


Quando uso o Framework.NET tenho recursos RAD... se alterno pra Plataform
SDK, onde passo a usar as bibliotecas nativas do Windows como faço pra
desenhar forms por RAD também ?

"Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com> wrote in
message news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> Pessoal,
>
>
> Quando uso o Framework.NET tenho recursos RAD... se alterno pra Plataform
> SDK, onde passo a usar as bibliotecas nativas do Windows como faço pra
> desenhar forms por RAD também ?

Depende do seu conceito de RAD... Usando a MFC (Microsoft Foundation
Classes) vc tem a opção de criar Dialog Boxes e usá-las com a classe
CFormView. Não é a mesma coisa que o ambiente do .NET, mas poupa algum
trabalho.... Em essência, não há ambiente RAD com C++ e bibliotecas nativas
(Win32).

Especialmente se vc estiver usando o PlatformSDK na sua forma mais pura
(Chamadas de funções), RAD é um recurso que vc não tem!

Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo quando possa
parecer... Com o Visual Studio e MFC vc ainda tem wizards para criar a
tabela de mensagens pra você (basta observar as propriedades da classe
desejada).... O que vc não tem é o recurso de arrastar-e-soltar para colocar
componentes no local desejado da janela (Isso é feito em código!)...

[]s
Fred

Frederico,


Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid Application
Devolopment.

Sou programador FoxPro há sete anos, agora estou querendo aprender C++ por
ser mais rápido, flexível e exigir menos máquina do usuário final.

Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
facilidade, mas notei que tudo que eu estava fazendo era encima do
Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não quero
porque é ainda mais lendo do que as aplicações escritas em FoxPro e exige
ainda mais máquina.

Então instalei a PlatformSDK, configurei tudo e está funcionando, mas sentí
falta dos recursos de arrastar e soltar. Estou disposto a fazer tudo na mão
mesmo, não tem problema, mas não sei por onde começar.

Se você tiver um tutorial que mostre passo-a-passo como fazer um form
simples com um textbox e um command button em C++ 2005 Express pra me indicar
fico agradecido.



"Frederico Pissarra" escreveu:

>
> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com> wrote in
> message news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> > Pessoal,
> >
> >
> > Quando uso o Framework.NET tenho recursos RAD... se alterno pra Plataform
> > SDK, onde passo a usar as bibliotecas nativas do Windows como faço pra
> > desenhar forms por RAD também ?
>
> Depende do seu conceito de RAD... Usando a MFC (Microsoft Foundation
> Classes) vc tem a opção de criar Dialog Boxes e usá-las com a classe
> CFormView. Não é a mesma coisa que o ambiente do .NET, mas poupa algum
> trabalho.... Em essência, não há ambiente RAD com C++ e bibliotecas nativas
> (Win32).
>
> Especialmente se vc estiver usando o PlatformSDK na sua forma mais pura
> (Chamadas de funções), RAD é um recurso que vc não tem!
>
> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo quando possa
> parecer... Com o Visual Studio e MFC vc ainda tem wizards para criar a
> tabela de mensagens pra você (basta observar as propriedades da classe
> desejada).... O que vc não tem é o recurso de arrastar-e-soltar para colocar
> componentes no local desejado da janela (Isso é feito em código!)...
>
> []s
> Fred
>
>
>

Olá Geraldo,

Qual é o problema de performance que você tem com .NET? Como mediu isso?

Acho extremamente improvável que seus problemas estejam relacionados com
a interface gráfica; e portanto não acredito que lhe seja vantajoso fazer
escolhas de "plataforma de desenvolvimento" baseadas nisso. Você pode se
beneficiar das qualidades que gostou ao usar VC++ e WinForms com as funcionalidades
do VS, e ainda assim escrever código nativo gerando um mized-mode assembly
(código gerenciado e nativo no mesmo assembly) de forma transparente em VC++.
Se planejar as interfaces bem não terá custo significativo de interop.

Na verdade, não sei se seus problemas de performance estariam relacionados
à código gerenciado em si, e se esse for o caso, você nem precisa de mixed
mode necessariamente. A não ser que "exigir muita máquina" seja relacionado
a instalação do framework ou uma quantidade mínima (que é absolutamente razoável)
de memória para fazer o Gargabe Collector eficiente, não tenho certeza que
seus problemas de performance estejam relacionados a .NET em si.Se você postar
informações específicas sobre os problemas, alguém pode acabar dando idéias
de como melhorar a performance.

-- Roberto Adlich
Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
direitos.

> Frederico,
>
> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
> Application Devolopment.
>
> Sou programador FoxPro há sete anos, agora estou querendo aprender C++
> por ser mais rápido, flexível e exigir menos máquina do usuário final.
>
> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> facilidade, mas notei que tudo que eu estava fazendo era encima do
> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
> quero porque é ainda mais lendo do que as aplicações escritas em
> FoxPro e exige ainda mais máquina.
>
> Então instalei a PlatformSDK, configurei tudo e está funcionando, mas
> sentí falta dos recursos de arrastar e soltar. Estou disposto a fazer
> tudo na mão mesmo, não tem problema, mas não sei por onde começar.
>
> Se você tiver um tutorial que mostre passo-a-passo como fazer um form
> simples com um textbox e um command button em C++ 2005 Express pra me
> indicar fico agradecido.
>
> "Frederico Pissarra" escreveu:
>
>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
>> wrote in message
>> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
>>
>>> Pessoal,
>>>
>>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
>>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
>>> como faço pra desenhar forms por RAD também ?
>>>
>> Depende do seu conceito de RAD... Usando a MFC (Microsoft Foundation
>> Classes) vc tem a opção de criar Dialog Boxes e usá-las com a classe
>> CFormView. Não é a mesma coisa que o ambiente do .NET, mas poupa
>> algum trabalho.... Em essência, não há ambiente RAD com C++ e
>> bibliotecas nativas (Win32).
>>
>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
>> pura (Chamadas de funções), RAD é um recurso que vc não tem!
>>
>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo quando
>> possa parecer... Com o Visual Studio e MFC vc ainda tem wizards para
>> criar a tabela de mensagens pra você (basta observar as propriedades
>> da classe desejada).... O que vc não tem é o recurso de
>> arrastar-e-soltar para colocar componentes no local desejado da
>> janela (Isso é feito em código!)...
>>
>> []s
>> Fred

Roberto,


Dá uma olhada, por exemplo, no post "API, MFC, C# ou Borland C++ Builder ?"
aqui neste fórum.

Nem precisa alguém falar que há um "custo" pra se instanciar o Framework.NET
porque esse custo é óbvio, além do transtorno do usuário final ter que
instalar. Se você tiver um cliente você vai lá e instala ou explica pra ele
onde obter e instalar, mas se você tiver um sistema que é vendido no país
inteiro choverá ligações pro pessoal do suporte atender... e creia, pode ser
simples como for, o usuário final liga pedindo ajuda sim.

Temos aplicações em ASP.NET que rodam no servidor e o cliente acessa pelo
navegador. Mas com tudo(Framework.NET) rodando na máquina do cliente não
temos ainda. Os equipamentos dos clientes são os mais variados possíveis.

Aplicações em C++ não gerenciado, por serem independentes de outras
parafernalhas e, por tanto, exigirem menos máquina, me parecem a melhor
alternativa.

Os aplicativos que temos são escritos em Visual FoxPro. Nenhum cliente nunca
esperou um minuto enquanto o aplicativo é carregado. Se gerarmos nova versão
em C#, por exemplo, e o cliente tiver que esperar 1 minuto pra, tão somente,
o aplicativo ser iniciado estamos mortos.


"Roberto Adlich dos Santos [MSFT]" escreveu:

> Olá Geraldo,
>
> Qual é o problema de performance que você tem com .NET? Como mediu isso?
>
> Acho extremamente improvável que seus problemas estejam relacionados com
> a interface gráfica; e portanto não acredito que lhe seja vantajoso fazer
> escolhas de "plataforma de desenvolvimento" baseadas nisso. Você pode se
> beneficiar das qualidades que gostou ao usar VC++ e WinForms com as funcionalidades
> do VS, e ainda assim escrever código nativo gerando um mized-mode assembly
> (código gerenciado e nativo no mesmo assembly) de forma transparente em VC++.
> Se planejar as interfaces bem não terá custo significativo de interop.
>
> Na verdade, não sei se seus problemas de performance estariam relacionados
> à código gerenciado em si, e se esse for o caso, você nem precisa de mixed
> mode necessariamente. A não ser que "exigir muita máquina" seja relacionado
> a instalação do framework ou uma quantidade mínima (que é absolutamente razoável)
> de memória para fazer o Gargabe Collector eficiente, não tenho certeza que
> seus problemas de performance estejam relacionados a .NET em si.Se você postar
> informações específicas sobre os problemas, alguém pode acabar dando idéias
> de como melhorar a performance.
>
> -- Roberto Adlich
> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
> direitos.
>
> > Frederico,
> >
> > Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
> > Application Devolopment.
> >
> > Sou programador FoxPro há sete anos, agora estou querendo aprender C++
> > por ser mais rápido, flexível e exigir menos máquina do usuário final.
> >
> > Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> > facilidade, mas notei que tudo que eu estava fazendo era encima do
> > Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
> > quero porque é ainda mais lendo do que as aplicações escritas em
> > FoxPro e exige ainda mais máquina.
> >
> > Então instalei a PlatformSDK, configurei tudo e está funcionando, mas
> > sentí falta dos recursos de arrastar e soltar. Estou disposto a fazer
> > tudo na mão mesmo, não tem problema, mas não sei por onde começar.
> >
> > Se você tiver um tutorial que mostre passo-a-passo como fazer um form
> > simples com um textbox e um command button em C++ 2005 Express pra me
> > indicar fico agradecido.
> >
> > "Frederico Pissarra" escreveu:
> >
> >> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
> >> wrote in message
> >> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> >>
> >>> Pessoal,
> >>>
> >>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
> >>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
> >>> como faço pra desenhar forms por RAD também ?
> >>>
> >> Depende do seu conceito de RAD... Usando a MFC (Microsoft Foundation
> >> Classes) vc tem a opção de criar Dialog Boxes e usá-las com a classe
> >> CFormView. Não é a mesma coisa que o ambiente do .NET, mas poupa
> >> algum trabalho.... Em essência, não há ambiente RAD com C++ e
> >> bibliotecas nativas (Win32).
> >>
> >> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
> >> pura (Chamadas de funções), RAD é um recurso que vc não tem!
> >>
> >> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo quando
> >> possa parecer... Com o Visual Studio e MFC vc ainda tem wizards para
> >> criar a tabela de mensagens pra você (basta observar as propriedades
> >> da classe desejada).... O que vc não tem é o recurso de
> >> arrastar-e-soltar para colocar componentes no local desejado da
> >> janela (Isso é feito em código!)...
> >>
> >> []s
> >> Fred
>
>
>

Olá Geraldo,

A instalação do .NET Framework pode ser automatizada a partir do seu programa
de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
não é uma solução válida para a maioria dos casos.

Os equipamentos de seus clientes podem ser variados, mas isso dificilmente
justifica problemas de compatibilidade ou semelhantes. Os equipamentos que
a MS testa e suporta são, com certeza, mais variados do que o conjunto de
clientes da vasta maioria das software houses.

Ainda assim, deixei explícito no post anterior que 1) instalação poderia
ser um problema para seu caso e 2) a plataforma de hardware de seus clientes
pode nào ser boa o suficiente para .NET. Mas repare que esses problemas que
você cita não podem ser aplicados generica e indiscriminadamente; por exemplo:
E se você tem clientes com plataformas 32 e 64 bits? Não seria mais fácil
estar usando .NET para a maior parte das aplicações? Alguns projetos que
consideraram instalação o grande problema usam soluções como http://www.xenocode.com/
(isso não é uma recomendação).

Meu ponto é lhe ajudar com problemas de performance; na minha experiência
os maiores problemas de performance que vi não foram por causa do framework.
Uma aplicação que leva 1 minuto para carregar, por exemplo, muito provavelmente
tem problemas de projeto e implementação. Na grande maioria dos casos é possível
fazer muito melhor do que isso sem usar as funcionalidades mais avançadas
de .NET, como ngen, por exemplo (já vi cair de 2 minutos para 2 segundos).
E se usar ngen você terá libraries compartilhadas em memória e ainda otimizações
que um compilador/linkeditor jamais farão (cross-assembly inlining, por exemplo),
etc.

C++ é a minha linguagem preferida, mas é uma linguagem onde problemas de
gerenciamento de memória, que acabam se manifestando em performance e confiabilidade,
e de segurança já causaram muito mais impacto a times e produtos do que a
performance em .NET. Pessoalmente, eu lhe aconselharia a levar tudo isso
em conta ao tomar uma decisão com relação a sua plataforma de desenvolvimento.


Não disputo de forma alguma de que em C++ seja mais fácil para desenvolvedores
competentes construir aplicativos mais performantes. O que não acredito ser
genéricamente correto é de que não se possa criar aplicativos com performance
suficiente em .NET. Se você compartilhar um exemplo em que você mediu tais
problemas, eu ou outras pessoas da lista podem lhe ajudar.

-- Roberto Adlich
Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
direitos.

> Roberto,
>
> Dá uma olhada, por exemplo, no post "API, MFC, C# ou Borland C++
> Builder ?" aqui neste fórum.
>
> Nem precisa alguém falar que há um "custo" pra se instanciar o
> Framework.NET porque esse custo é óbvio, além do transtorno do usuário
> final ter que instalar. Se você tiver um cliente você vai lá e instala
> ou explica pra ele onde obter e instalar, mas se você tiver um sistema
> que é vendido no país inteiro choverá ligações pro pessoal do suporte
> atender... e creia, pode ser simples como for, o usuário final liga
> pedindo ajuda sim.
>
> Temos aplicações em ASP.NET que rodam no servidor e o cliente acessa
> pelo navegador. Mas com tudo(Framework.NET) rodando na máquina do
> cliente não temos ainda. Os equipamentos dos clientes são os mais
> variados possíveis.
>
> Aplicações em C++ não gerenciado, por serem independentes de outras
> parafernalhas e, por tanto, exigirem menos máquina, me parecem a
> melhor alternativa.
>
> Os aplicativos que temos são escritos em Visual FoxPro. Nenhum cliente
> nunca esperou um minuto enquanto o aplicativo é carregado. Se gerarmos
> nova versão em C#, por exemplo, e o cliente tiver que esperar 1 minuto
> pra, tão somente, o aplicativo ser iniciado estamos mortos.
>
> "Roberto Adlich dos Santos [MSFT]" escreveu:
>
>> Olá Geraldo,
>>
>> Qual é o problema de performance que você tem com .NET? Como mediu
>> isso?
>>
>> Acho extremamente improvável que seus problemas estejam relacionados
>> com a interface gráfica; e portanto não acredito que lhe seja
>> vantajoso fazer escolhas de "plataforma de desenvolvimento" baseadas
>> nisso. Você pode se beneficiar das qualidades que gostou ao usar VC++
>> e WinForms com as funcionalidades do VS, e ainda assim escrever
>> código nativo gerando um mized-mode assembly (código gerenciado e
>> nativo no mesmo assembly) de forma transparente em VC++. Se planejar
>> as interfaces bem não terá custo significativo de interop.
>>
>> Na verdade, não sei se seus problemas de performance estariam
>> relacionados à código gerenciado em si, e se esse for o caso, você
>> nem precisa de mixed mode necessariamente. A não ser que "exigir
>> muita máquina" seja relacionado a instalação do framework ou uma
>> quantidade mínima (que é absolutamente razoável) de memória para
>> fazer o Gargabe Collector eficiente, não tenho certeza que seus
>> problemas de performance estejam relacionados a .NET em si.Se você
>> postar informações específicas sobre os problemas, alguém pode acabar
>> dando idéias de como melhorar a performance.
>>
>> -- Roberto Adlich
>> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão
>> de quaisquer
>> direitos.
>>> Frederico,
>>>
>>> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
>>> Application Devolopment.
>>>
>>> Sou programador FoxPro há sete anos, agora estou querendo aprender
>>> C++ por ser mais rápido, flexível e exigir menos máquina do usuário
>>> final.
>>>
>>> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
>>> facilidade, mas notei que tudo que eu estava fazendo era encima do
>>> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
>>> quero porque é ainda mais lendo do que as aplicações escritas em
>>> FoxPro e exige ainda mais máquina.
>>>
>>> Então instalei a PlatformSDK, configurei tudo e está funcionando,
>>> mas sentí falta dos recursos de arrastar e soltar. Estou disposto a
>>> fazer tudo na mão mesmo, não tem problema, mas não sei por onde
>>> começar.
>>>
>>> Se você tiver um tutorial que mostre passo-a-passo como fazer um
>>> form simples com um textbox e um command button em C++ 2005 Express
>>> pra me indicar fico agradecido.
>>>
>>> "Frederico Pissarra" escreveu:
>>>
>>>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
>>>> wrote in message
>>>> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
>>>>
>>>>> Pessoal,
>>>>>
>>>>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
>>>>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
>>>>> como faço pra desenhar forms por RAD também ?
>>>>>
>>>> Depende do seu conceito de RAD... Usando a MFC (Microsoft
>>>> Foundation Classes) vc tem a opção de criar Dialog Boxes e usá-las
>>>> com a classe CFormView. Não é a mesma coisa que o ambiente do .NET,
>>>> mas poupa algum trabalho.... Em essência, não há ambiente RAD com
>>>> C++ e bibliotecas nativas (Win32).
>>>>
>>>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
>>>> pura (Chamadas de funções), RAD é um recurso que vc não tem!
>>>>
>>>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo
>>>> quando possa parecer... Com o Visual Studio e MFC vc ainda tem
>>>> wizards para criar a tabela de mensagens pra você (basta observar
>>>> as propriedades da classe desejada).... O que vc não tem é o
>>>> recurso de arrastar-e-soltar para colocar componentes no local
>>>> desejado da janela (Isso é feito em código!)...
>>>>
>>>> []s
>>>> Fred

Roberto,


Obrigado pelos teus esclarecimentos. Achei completamente aceitáveis... acho
que vou ter que fazer alguns testes mesmo.

Ontem andei lendo esse artigo, dá uma olhada:

http://www.1bit.com.br/content.1bit/managed

Esse colega aí do artigo é muito bom, mas pra dominar um negócio difícil
como C++ como ele domina demora alguns anos.



"Roberto Adlich dos Santos [MSFT]" escreveu:

> Olá Geraldo,
>
> A instalação do .NET Framework pode ser automatizada a partir do seu programa
> de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
> diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
> todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
> não é uma solução válida para a maioria dos casos.
>
> Os equipamentos de seus clientes podem ser variados, mas isso dificilmente
> justifica problemas de compatibilidade ou semelhantes. Os equipamentos que
> a MS testa e suporta são, com certeza, mais variados do que o conjunto de
> clientes da vasta maioria das software houses.
>
> Ainda assim, deixei explícito no post anterior que 1) instalação poderia
> ser um problema para seu caso e 2) a plataforma de hardware de seus clientes
> pode nào ser boa o suficiente para .NET. Mas repare que esses problemas que
> você cita não podem ser aplicados generica e indiscriminadamente; por exemplo:
> E se você tem clientes com plataformas 32 e 64 bits? Não seria mais fácil
> estar usando .NET para a maior parte das aplicações? Alguns projetos que
> consideraram instalação o grande problema usam soluções como http://www.xenocode.com/
> (isso não é uma recomendação).
>
> Meu ponto é lhe ajudar com problemas de performance; na minha experiência
> os maiores problemas de performance que vi não foram por causa do framework.
> Uma aplicação que leva 1 minuto para carregar, por exemplo, muito provavelmente
> tem problemas de projeto e implementação. Na grande maioria dos casos é possível
> fazer muito melhor do que isso sem usar as funcionalidades mais avançadas
> de .NET, como ngen, por exemplo (já vi cair de 2 minutos para 2 segundos).
> E se usar ngen você terá libraries compartilhadas em memória e ainda otimizações
> que um compilador/linkeditor jamais farão (cross-assembly inlining, por exemplo),
> etc.
>
> C++ é a minha linguagem preferida, mas é uma linguagem onde problemas de
> gerenciamento de memória, que acabam se manifestando em performance e confiabilidade,
> e de segurança já causaram muito mais impacto a times e produtos do que a
> performance em .NET. Pessoalmente, eu lhe aconselharia a levar tudo isso
> em conta ao tomar uma decisão com relação a sua plataforma de desenvolvimento.
>
>
> Não disputo de forma alguma de que em C++ seja mais fácil para desenvolvedores
> competentes construir aplicativos mais performantes. O que não acredito ser
> genéricamente correto é de que não se possa criar aplicativos com performance
> suficiente em .NET. Se você compartilhar um exemplo em que você mediu tais
> problemas, eu ou outras pessoas da lista podem lhe ajudar.
>
> -- Roberto Adlich
> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
> direitos.
>
> > Roberto,
> >
> > Dá uma olhada, por exemplo, no post "API, MFC, C# ou Borland C++
> > Builder ?" aqui neste fórum.
> >
> > Nem precisa alguém falar que há um "custo" pra se instanciar o
> > Framework.NET porque esse custo é óbvio, além do transtorno do usuário
> > final ter que instalar. Se você tiver um cliente você vai lá e instala
> > ou explica pra ele onde obter e instalar, mas se você tiver um sistema
> > que é vendido no país inteiro choverá ligações pro pessoal do suporte
> > atender... e creia, pode ser simples como for, o usuário final liga
> > pedindo ajuda sim.
> >
> > Temos aplicações em ASP.NET que rodam no servidor e o cliente acessa
> > pelo navegador. Mas com tudo(Framework.NET) rodando na máquina do
> > cliente não temos ainda. Os equipamentos dos clientes são os mais
> > variados possíveis.
> >
> > Aplicações em C++ não gerenciado, por serem independentes de outras
> > parafernalhas e, por tanto, exigirem menos máquina, me parecem a
> > melhor alternativa.
> >
> > Os aplicativos que temos são escritos em Visual FoxPro. Nenhum cliente
> > nunca esperou um minuto enquanto o aplicativo é carregado. Se gerarmos
> > nova versão em C#, por exemplo, e o cliente tiver que esperar 1 minuto
> > pra, tão somente, o aplicativo ser iniciado estamos mortos.
> >
> > "Roberto Adlich dos Santos [MSFT]" escreveu:
> >
> >> Olá Geraldo,
> >>
> >> Qual é o problema de performance que você tem com .NET? Como mediu
> >> isso?
> >>
> >> Acho extremamente improvável que seus problemas estejam relacionados
> >> com a interface gráfica; e portanto não acredito que lhe seja
> >> vantajoso fazer escolhas de "plataforma de desenvolvimento" baseadas
> >> nisso. Você pode se beneficiar das qualidades que gostou ao usar VC++
> >> e WinForms com as funcionalidades do VS, e ainda assim escrever
> >> código nativo gerando um mized-mode assembly (código gerenciado e
> >> nativo no mesmo assembly) de forma transparente em VC++. Se planejar
> >> as interfaces bem não terá custo significativo de interop.
> >>
> >> Na verdade, não sei se seus problemas de performance estariam
> >> relacionados à código gerenciado em si, e se esse for o caso, você
> >> nem precisa de mixed mode necessariamente. A não ser que "exigir
> >> muita máquina" seja relacionado a instalação do framework ou uma
> >> quantidade mínima (que é absolutamente razoável) de memória para
> >> fazer o Gargabe Collector eficiente, não tenho certeza que seus
> >> problemas de performance estejam relacionados a .NET em si.Se você
> >> postar informações específicas sobre os problemas, alguém pode acabar
> >> dando idéias de como melhorar a performance.
> >>
> >> -- Roberto Adlich
> >> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão
> >> de quaisquer
> >> direitos.
> >>> Frederico,
> >>>
> >>> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
> >>> Application Devolopment.
> >>>
> >>> Sou programador FoxPro há sete anos, agora estou querendo aprender
> >>> C++ por ser mais rápido, flexível e exigir menos máquina do usuário
> >>> final.
> >>>
> >>> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> >>> facilidade, mas notei que tudo que eu estava fazendo era encima do
> >>> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
> >>> quero porque é ainda mais lendo do que as aplicações escritas em
> >>> FoxPro e exige ainda mais máquina.
> >>>
> >>> Então instalei a PlatformSDK, configurei tudo e está funcionando,
> >>> mas sentí falta dos recursos de arrastar e soltar. Estou disposto a
> >>> fazer tudo na mão mesmo, não tem problema, mas não sei por onde
> >>> começar.
> >>>
> >>> Se você tiver um tutorial que mostre passo-a-passo como fazer um
> >>> form simples com um textbox e um command button em C++ 2005 Express
> >>> pra me indicar fico agradecido.
> >>>
> >>> "Frederico Pissarra" escreveu:
> >>>
> >>>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
> >>>> wrote in message
> >>>> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> >>>>
> >>>>> Pessoal,
> >>>>>
> >>>>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
> >>>>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
> >>>>> como faço pra desenhar forms por RAD também ?
> >>>>>
> >>>> Depende do seu conceito de RAD... Usando a MFC (Microsoft
> >>>> Foundation Classes) vc tem a opção de criar Dialog Boxes e usá-las
> >>>> com a classe CFormView. Não é a mesma coisa que o ambiente do .NET,
> >>>> mas poupa algum trabalho.... Em essência, não há ambiente RAD com
> >>>> C++ e bibliotecas nativas (Win32).
> >>>>
> >>>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
> >>>> pura (Chamadas de funções), RAD é um recurso que vc não tem!
> >>>>
> >>>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo
> >>>> quando possa parecer... Com o Visual Studio e MFC vc ainda tem
> >>>> wizards para criar a tabela de mensagens pra você (basta observar
> >>>> as propriedades da classe desejada).... O que vc não tem é o
> >>>> recurso de arrastar-e-soltar para colocar componentes no local
> >>>> desejado da janela (Isso é feito em código!)...
> >>>>
> >>>> []s
> >>>> Fred
>
>
>

Geraldo,

Vc tb pode programar em .NET usando C++.... dai vc "ganha" os recursos RAD
que quer.... e ainda "ganha" a possibilidade de misturar unmanaged code com
managed code... (p.ex: alocar memória no heap da aplicação ao invés do
garbage collector!).

[]s
Fred

"Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com> escreveu na
mensagem news:2224FAB3-8F01-4274-ADBA-992E19C41931@microsoft.com...
> Frederico,
>
>
> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid Application
> Devolopment.
>
> Sou programador FoxPro há sete anos, agora estou querendo aprender C++ por
> ser mais rápido, flexível e exigir menos máquina do usuário final.
>
> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> facilidade, mas notei que tudo que eu estava fazendo era encima do
> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não quero
> porque é ainda mais lendo do que as aplicações escritas em FoxPro e exige
> ainda mais máquina.
>
> Então instalei a PlatformSDK, configurei tudo e está funcionando, mas
> sentí
> falta dos recursos de arrastar e soltar. Estou disposto a fazer tudo na
> mão
> mesmo, não tem problema, mas não sei por onde começar.
>
> Se você tiver um tutorial que mostre passo-a-passo como fazer um form
> simples com um textbox e um command button em C++ 2005 Express pra me
> indicar
> fico agradecido.
>
>
>
> "Frederico Pissarra" escreveu:
>
>>
>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com> wrote in
>> message news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
>> > Pessoal,
>> >
>> >
>> > Quando uso o Framework.NET tenho recursos RAD... se alterno pra
>> > Plataform
>> > SDK, onde passo a usar as bibliotecas nativas do Windows como faço pra
>> > desenhar forms por RAD também ?
>>
>> Depende do seu conceito de RAD... Usando a MFC (Microsoft Foundation
>> Classes) vc tem a opção de criar Dialog Boxes e usá-las com a classe
>> CFormView. Não é a mesma coisa que o ambiente do .NET, mas poupa algum
>> trabalho.... Em essência, não há ambiente RAD com C++ e bibliotecas
>> nativas
>> (Win32).
>>
>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais pura
>> (Chamadas de funções), RAD é um recurso que vc não tem!
>>
>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo quando
>> possa
>> parecer... Com o Visual Studio e MFC vc ainda tem wizards para criar a
>> tabela de mensagens pra você (basta observar as propriedades da classe
>> desejada).... O que vc não tem é o recurso de arrastar-e-soltar para
>> colocar
>> componentes no local desejado da janela (Isso é feito em código!)...
>>
>> []s
>> Fred
>>
>>
>>

Complementando esta thread,

Com relação a performance de inicialização da sua aplicação .NET, onde citou
mais de 1 min... vc deve estar se referindo ao "cold boot". Considere o uso
do NGEN.EXE na aplicação (managed) desktop para melhorar este tempo.

--
Fabio Galuppo
fabiogaluppo.blogspot.com


"Geraldo F. Barbosa" escreveu:

> Roberto,
>
>
> Obrigado pelos teus esclarecimentos. Achei completamente aceitáveis... acho
> que vou ter que fazer alguns testes mesmo.
>
> Ontem andei lendo esse artigo, dá uma olhada:
>
> http://www.1bit.com.br/content.1bit/managed
>
> Esse colega aí do artigo é muito bom, mas pra dominar um negócio difícil
> como C++ como ele domina demora alguns anos.
>
>
>
> "Roberto Adlich dos Santos [MSFT]" escreveu:
>
> > Olá Geraldo,
> >
> > A instalação do .NET Framework pode ser automatizada a partir do seu programa
> > de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
> > diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
> > todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
> > não é uma solução válida para a maioria dos casos.
> >
> > Os equipamentos de seus clientes podem ser variados, mas isso dificilmente
> > justifica problemas de compatibilidade ou semelhantes. Os equipamentos que
> > a MS testa e suporta são, com certeza, mais variados do que o conjunto de
> > clientes da vasta maioria das software houses.
> >
> > Ainda assim, deixei explícito no post anterior que 1) instalação poderia
> > ser um problema para seu caso e 2) a plataforma de hardware de seus clientes
> > pode nào ser boa o suficiente para .NET. Mas repare que esses problemas que
> > você cita não podem ser aplicados generica e indiscriminadamente; por exemplo:
> > E se você tem clientes com plataformas 32 e 64 bits? Não seria mais fácil
> > estar usando .NET para a maior parte das aplicações? Alguns projetos que
> > consideraram instalação o grande problema usam soluções como http://www.xenocode.com/
> > (isso não é uma recomendação).
> >
> > Meu ponto é lhe ajudar com problemas de performance; na minha experiência
> > os maiores problemas de performance que vi não foram por causa do framework.
> > Uma aplicação que leva 1 minuto para carregar, por exemplo, muito provavelmente
> > tem problemas de projeto e implementação. Na grande maioria dos casos é possível
> > fazer muito melhor do que isso sem usar as funcionalidades mais avançadas
> > de .NET, como ngen, por exemplo (já vi cair de 2 minutos para 2 segundos).
> > E se usar ngen você terá libraries compartilhadas em memória e ainda otimizações
> > que um compilador/linkeditor jamais farão (cross-assembly inlining, por exemplo),
> > etc.
> >
> > C++ é a minha linguagem preferida, mas é uma linguagem onde problemas de
> > gerenciamento de memória, que acabam se manifestando em performance e confiabilidade,
> > e de segurança já causaram muito mais impacto a times e produtos do que a
> > performance em .NET. Pessoalmente, eu lhe aconselharia a levar tudo isso
> > em conta ao tomar uma decisão com relação a sua plataforma de desenvolvimento.
> >
> >
> > Não disputo de forma alguma de que em C++ seja mais fácil para desenvolvedores
> > competentes construir aplicativos mais performantes. O que não acredito ser
> > genéricamente correto é de que não se possa criar aplicativos com performance
> > suficiente em .NET. Se você compartilhar um exemplo em que você mediu tais
> > problemas, eu ou outras pessoas da lista podem lhe ajudar.
> >
> > -- Roberto Adlich
> > Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
> > direitos.
> >
> > > Roberto,
> > >
> > > Dá uma olhada, por exemplo, no post "API, MFC, C# ou Borland C++
> > > Builder ?" aqui neste fórum.
> > >
> > > Nem precisa alguém falar que há um "custo" pra se instanciar o
> > > Framework.NET porque esse custo é óbvio, além do transtorno do usuário
> > > final ter que instalar. Se você tiver um cliente você vai lá e instala
> > > ou explica pra ele onde obter e instalar, mas se você tiver um sistema
> > > que é vendido no país inteiro choverá ligações pro pessoal do suporte
> > > atender... e creia, pode ser simples como for, o usuário final liga
> > > pedindo ajuda sim.
> > >
> > > Temos aplicações em ASP.NET que rodam no servidor e o cliente acessa
> > > pelo navegador. Mas com tudo(Framework.NET) rodando na máquina do
> > > cliente não temos ainda. Os equipamentos dos clientes são os mais
> > > variados possíveis.
> > >
> > > Aplicações em C++ não gerenciado, por serem independentes de outras
> > > parafernalhas e, por tanto, exigirem menos máquina, me parecem a
> > > melhor alternativa.
> > >
> > > Os aplicativos que temos são escritos em Visual FoxPro. Nenhum cliente
> > > nunca esperou um minuto enquanto o aplicativo é carregado. Se gerarmos
> > > nova versão em C#, por exemplo, e o cliente tiver que esperar 1 minuto
> > > pra, tão somente, o aplicativo ser iniciado estamos mortos.
> > >
> > > "Roberto Adlich dos Santos [MSFT]" escreveu:
> > >
> > >> Olá Geraldo,
> > >>
> > >> Qual é o problema de performance que você tem com .NET? Como mediu
> > >> isso?
> > >>
> > >> Acho extremamente improvável que seus problemas estejam relacionados
> > >> com a interface gráfica; e portanto não acredito que lhe seja
> > >> vantajoso fazer escolhas de "plataforma de desenvolvimento" baseadas
> > >> nisso. Você pode se beneficiar das qualidades que gostou ao usar VC++
> > >> e WinForms com as funcionalidades do VS, e ainda assim escrever
> > >> código nativo gerando um mized-mode assembly (código gerenciado e
> > >> nativo no mesmo assembly) de forma transparente em VC++. Se planejar
> > >> as interfaces bem não terá custo significativo de interop.
> > >>
> > >> Na verdade, não sei se seus problemas de performance estariam
> > >> relacionados à código gerenciado em si, e se esse for o caso, você
> > >> nem precisa de mixed mode necessariamente. A não ser que "exigir
> > >> muita máquina" seja relacionado a instalação do framework ou uma
> > >> quantidade mínima (que é absolutamente razoável) de memória para
> > >> fazer o Gargabe Collector eficiente, não tenho certeza que seus
> > >> problemas de performance estejam relacionados a .NET em si.Se você
> > >> postar informações específicas sobre os problemas, alguém pode acabar
> > >> dando idéias de como melhorar a performance.
> > >>
> > >> -- Roberto Adlich
> > >> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão
> > >> de quaisquer
> > >> direitos.
> > >>> Frederico,
> > >>>
> > >>> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
> > >>> Application Devolopment.
> > >>>
> > >>> Sou programador FoxPro há sete anos, agora estou querendo aprender
> > >>> C++ por ser mais rápido, flexível e exigir menos máquina do usuário
> > >>> final.
> > >>>
> > >>> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> > >>> facilidade, mas notei que tudo que eu estava fazendo era encima do
> > >>> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
> > >>> quero porque é ainda mais lendo do que as aplicações escritas em
> > >>> FoxPro e exige ainda mais máquina.
> > >>>
> > >>> Então instalei a PlatformSDK, configurei tudo e está funcionando,
> > >>> mas sentí falta dos recursos de arrastar e soltar. Estou disposto a
> > >>> fazer tudo na mão mesmo, não tem problema, mas não sei por onde
> > >>> começar.
> > >>>
> > >>> Se você tiver um tutorial que mostre passo-a-passo como fazer um
> > >>> form simples com um textbox e um command button em C++ 2005 Express
> > >>> pra me indicar fico agradecido.
> > >>>
> > >>> "Frederico Pissarra" escreveu:
> > >>>
> > >>>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
> > >>>> wrote in message
> > >>>> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> > >>>>
> > >>>>> Pessoal,
> > >>>>>
> > >>>>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
> > >>>>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
> > >>>>> como faço pra desenhar forms por RAD também ?
> > >>>>>
> > >>>> Depende do seu conceito de RAD... Usando a MFC (Microsoft
> > >>>> Foundation Classes) vc tem a opção de criar Dialog Boxes e usá-las
> > >>>> com a classe CFormView. Não é a mesma coisa que o ambiente do .NET,
> > >>>> mas poupa algum trabalho.... Em essência, não há ambiente RAD com
> > >>>> C++ e bibliotecas nativas (Win32).
> > >>>>
> > >>>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
> > >>>> pura (Chamadas de funções), RAD é um recurso que vc não tem!
> > >>>>
> > >>>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo
> > >>>> quando possa parecer... Com o Visual Studio e MFC vc ainda tem
> > >>>> wizards para criar a tabela de mensagens pra você (basta observar
> > >>>> as propriedades da classe desejada).... O que vc não tem é o
> > >>>> recurso de arrastar-e-soltar para colocar componentes no local
> > >>>> desejado da janela (Isso é feito em código!)...
> > >>>>
> > >>>> []s
> > >>>> Fred
> >
> >
> >

Roberto:

"A instalação do .NET Framework pode ser automatizada a partir do seu
programa
de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
não é uma solução válida para a maioria dos casos."

Só uma correção:
É possível fazer um aplicativo em VC++ unmanaged sem a dependencia das dlls
da versão 8. É uma configuração do projeto. As dependencias ficam apenas das
dlls que qualquer windows tem na system.
Ou seja, é possível "copiar e colar".

Olá Thiago,

Você não deve instalar a ATL/MFC/CRT da versão 8.0 (VS 2005) no System32.
Da mesma forma, você normalmente não deve linkar essas bibliotecas juntos,
se puder evitar.

Qual o objetivo de tudo isso? Versionamento/servicing. Para conseguir versões
lado-a-lado, agora, usa-se o mesmo sistema que .NET: Fusion (que é parte
do OS). Portanto, a forma correta de instalar as novas versões dessas bibliotecas,
é executar o vc80redist.exe (ou sando merge modules dentro do seu programa
de setup; como preferir). Da mesma forma, quando há uma flaha de segurança
identifica, o mesmo poder é adad a administradores para identificar quais
aplicativos funcionam 100% com a bilbioteca que teve um patch, e controlar
como o binding vai ocorre. Comoe em .NET.

Há uma introdução sobre unmanaged assemblies & manifest aqui: http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm.
Manifest é o nome do arquivo que identifica as dependências desse tipo que
o arquivo possui. Se você usa a IDE, não tem que lidar com isso. Se tem um
sistema de build complexo é necessário usar o manifest que linker gera e
possivelmente adicionar com mt.exe, um novoaplicativo nessa versão. (o motivo
para "possivelmente" é que para .exe, ele pode ser carregado do disco, em
vex de um resource).

-- Roberto Adlich
Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
direitos.

> Roberto:
>
> "A instalação do .NET Framework pode ser automatizada a partir do seu
> programa de setup. O setup básico que se cria com Visual Studio faz
> isso. Não é tão diferente de ter que instalar os redistributables para
> MFC/ATL/CRT que são todos assemblies na versão 8.0 (não é só copiar,
> etc). Linkar tudo junto não é uma solução válida para a maioria dos
> casos."
>
> Só uma correção:
> É possível fazer um aplicativo em VC++ unmanaged sem a dependencia das
> dlls
> da versão 8. É uma configuração do projeto. As dependencias ficam
> apenas das
> dlls que qualquer windows tem na system.
> Ou seja, é possível "copiar e colar".

Não estava me referindo a MFC.

Estou me referindo a biblioteca C/C++ e DLLs do windows.
Ou seja, é possível escrever um programa que só dependa de DLLs que estão
presentes no windows. (kernel32.dll user32.dll gdi32.dll ...)
Aí é só "copiar e colar" o exe.

Olá Thiago,

O problema é que até mesmo a CRT (C runtime library) usa o mesmo tipo de
instalação na versão 8! É sempre possível achar atalhos para isso tudo (faz-me
lembrar da mini-CRT--do Pietrick, se não me engano); mas não acho que soluções
como essas, que podem ser úteis para projetos específicos, são o que o Geraldo
precisa, que é escolher uma **plataforma de desenvolvimento**. Não acho que
seja viável escolher não usar nenhuma das bilbiotecas, ou usá-las de maneira
a diminuir o impacto de Fusion, apenas porque o setup parece mais complicado;
pelo menos como uma decisão genérica que afetará todos os seus produtos.
E nesse ponto o setup é muito semelhante a .NET (exceto em tamanho), que
é onde a discussão iniciou.

No fundo, não é preciso atalhos tão complicados ou cenários tão limitados
pare se usar tudo da versão 8.0 com xcopy deployment. Na verdade, em alguns
casos, pode até ser "necessário". Imagine que você precisa instalar um produto
que usa as bibliotecas novas, e portanto precisa instalar esses assemblies
no SxS (side-by-side) cache. Agora imagine que seu programa de instalação
também depende dessas bilbiotecas, que podem não estar instaladas. Como fazer
esse tipo de bootstrapping? Ora, com uma edição manual dos manifest é possível
colocar as dlls dentro da pasta da aplicação. Veja o setup do SQL Server
2005 para um exemplo (veja o manifest na raiz do disco). Ganha-se "xcopy"
deployment, mas perde-se as políticas de controle de versionamento e de atualização.
É por isso que eu não recomendaria isso para qualquer outro cenário que não
seja semelhante a esse.

Outra opção é linkar as coisas junto, o que perde as mesmas flexibilidades.
No fundo, você pode fazer mais do que apenas usar as dlls do windows sem
se preocupar com Fusion mas, em alguns casos, será mais complicado configurar
o build para tal, ou deixará de usar as opções mais recomendáveis.

Eu continuo acreditando que nenhuma dessas opções seria uma boa escolha como
"plataforma de desenvolvimento imposta a todos os produtos e times". Algumas
mudanças não são triviais (como não usar a CRT da MS), e deixar de usar outras
bibliotecas boas, bem documentadas e pelas quais você já pagou também seria
ineficiente, ou o cenário de manutenção e administração dos seus produtos
será menos flexível de que praticamente todos os outros que são desenvolvidos
na mesma plataforma (se não usar Fusion); podendo até levar a falhas de segurança
que necessitariam de patches e releases específicas da sua empresa que poderiam
ser evitadas.

-- Roberto Adlich
Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
direitos.

> Não estava me referindo a MFC.
>
> Estou me referindo a biblioteca C/C++ e DLLs do windows.
> Ou seja, é possível escrever um programa que só dependa de DLLs que
> estão
> presentes no windows. (kernel32.dll user32.dll gdi32.dll ...)
> Aí é só "copiar e colar" o exe.

"Roberto Adlich dos Santos [MSFT]" escreveu:
"O problema é que até mesmo a CRT (C runtime library) usa o mesmo tipo de
instalação na versão 8!"

Você escolhe qual CRT quer usar. Você pode configurar o seu projeto para ter
dependência apenas da CRT que tem em todos os windows.
Na configuração do projeto usa: Multi-threaded (/MT) ou Multi-threaded DLL.
Esta segunda é o CRT que vem no VC++ 8.0 a primeira é a que tem em qualquer
windows.
Eu não quiz entrar na discussão sobre a Pergunta do Geraldo, eu só quis
colocar um parenteses e informar que é possível gerar um exe no VC++ livre de
dependencias. (Dependendo apenas de dlls que vêm no windows)

Olá Thiago,

/MT não significa que você usa as versões antigas. Na verdade elas são a
mesma versão da CRT. O que muda é o formato de distribuição. Se você não
usa a DLL, o que acontece é a ã lib que contém as definições vai ser linkada
junto. Esse é o cenário que comentei antes, em que tudo é linkado, mas você
também perde as funcionalidades de adminsitração de versionamento e facilidade
udpates que eu comentei antes. A lib que é linkada junto no caso de /MT 'libcmt.lib,
e o modo como linker descrobre isso, é porque o compilador coloca a referência
dentro do obj.

Seria impossível a /MT não requrerer nada que não seja lançado com o Visual
studio, pois a CRT tem coisas novas (como por exemplo http://msdn2.microsoft.com/en-us/library/8ef0s5kh.aspx);
e como o SO e as linguagens não seguem o mesmo calendário de lançamento não
haveria onde encontrar essas coisas novas. Para dar uma olhada na diferença
de /Mt e /MD use depends.exe para ver como a segunda opção vai carregar DLL,
e compare a diferença de tamanho para ver como a primeira linkou coisas junto
com seu aplicativo.

Referências sobre as switch do cl.exe (o "driver" dos compiladores c e c++
da MS) e também explicação das várias formas como uma aplicação pode usar
a cRt podem ser encontradas nesses links:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.MD.2c_2f.ML.2c_2f.MT.2c_2f.LD.asp
http://msdn2.microsoft.com/en-us/library/abx4dbyh.aspx

-- Roberto Adlich
Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
direitos.

> "Roberto Adlich dos Santos [MSFT]" escreveu:
> "O problema é que até mesmo a CRT (C runtime library) usa o mesmo tipo
> de
> instalação na versão 8!"
> Você escolhe qual CRT quer usar. Você pode configurar o seu projeto
> para ter
> dependência apenas da CRT que tem em todos os windows.
> Na configuração do projeto usa: Multi-threaded (/MT) ou Multi-threaded
> DLL.
> Esta segunda é o CRT que vem no VC++ 8.0 a primeira é a que tem em
> qualquer
> windows.
> Eu não quiz entrar na discussão sobre a Pergunta do Geraldo, eu só
> quis
> colocar um parenteses e informar que é possível gerar um exe no VC++
> livre de
> dependencias. (Dependendo apenas de dlls que vêm no windows)

Sim, escrevi errado antes na verdade a CRT fica linkado junto!
Tenho um exemplo de exe aqui olhei no depends e só está usando 3 dlls
basicas do windows. Ou seja roda direto.
Não usei as funções novas de strings que inclusive não fazem parte do C /
C++ padrão.

Olá Thiago,

Desculpe Thiago; fiquei meio confuso com esse último post...

> Sim, escrevi errado antes na verdade a CRT fica linkado junto!

Estamos de acordo com o que foi dito antes? Ou ainda há uma diferença de
opinião (com relação a dependências, etc)?

> Tenho um exemplo de exe aqui olhei no depends e só está usando 3 dlls
> basicas do windows. Ou seja roda direto.
> Não usei as funções novas de strings que inclusive não fazem parte do
> C /
> C++ padrão.

Não entendi se você tem uma dúvida de como esse cenário se encaixa nas explicações
anteriores ou não. Você tem um .EXE que foi compilado com /MD, e portanto
deveria referenciar as DLLs de runtime mas depends só mostra DLLs do Windows?


-- Roberto Adlich
Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
direitos.

> Sim, escrevi errado antes na verdade a CRT fica linkado junto!
> Tenho um exemplo de exe aqui olhei no depends e só está usando 3 dlls
> basicas do windows. Ou seja roda direto.
> Não usei as funções novas de strings que inclusive não fazem parte do
> C /
> C++ padrão.

Bom dia Roberto.
Poderia me ajudar com o Visual C++ 2005 Express.
Tenho conhecimento da linguagem, ms já tem 2 semanas q baixei a ferramenta.
Usava o compilador da Borland.
Baixei o Visual C++ 2005 o framework 2.0 e o SDK. Instalei tudo.
Fiz uma aplicação simples para testar. Um form com um botão sem função,
rodei e funcionou normalmente em minha máquina, e pelo disquete na minha
máquina, ms quando tento rodar em outra máquina seja com disquete ou Hd ou
seja máquinas XP com framework 2.0 ou sem o programa não roda, dá erros.
Postei isso no forum em Visual C++ 2005 Express.

Gostaria de saber como faço para rodar um executável compilado com o VC++
2005 Express em outra máquina q não possui a ferramenta, pois fiz um form
simples e só consigo rodar em minha máquina.
Testei em máquina com XP e framework, deu erro e sem o framework tb deu erro
1º - Falha na inicialização do aplicativo devido a configuração incorreta. A
reinstalação do aplicativo pode resolver o problema.
2º - com o framework >> Application has generated an exception that could
not be handled. Process id = 0xfffb306f(-315281), thread
id=0xfffb325f(-314785)

Gostaria tb de saber se existe algum livro, apostila (preferencia portugues)
ou curso desta ferramenta, pois da linguagem já possuo.

Tem como me ajudar?


"Fabio Galuppo" escreveu:

> Complementando esta thread,
>
> Com relação a performance de inicialização da sua aplicação .NET, onde citou
> mais de 1 min... vc deve estar se referindo ao "cold boot". Considere o uso
> do NGEN.EXE na aplicação (managed) desktop para melhorar este tempo.
>
> --
> Fabio Galuppo
> fabiogaluppo.blogspot.com
>
>
> "Geraldo F. Barbosa" escreveu:
>
> > Roberto,
> >
> >
> > Obrigado pelos teus esclarecimentos. Achei completamente aceitáveis... acho
> > que vou ter que fazer alguns testes mesmo.
> >
> > Ontem andei lendo esse artigo, dá uma olhada:
> >
> > http://www.1bit.com.br/content.1bit/managed
> >
> > Esse colega aí do artigo é muito bom, mas pra dominar um negócio difícil
> > como C++ como ele domina demora alguns anos.
> >
> >
> >
> > "Roberto Adlich dos Santos [MSFT]" escreveu:
> >
> > > Olá Geraldo,
> > >
> > > A instalação do .NET Framework pode ser automatizada a partir do seu programa
> > > de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
> > > diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
> > > todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
> > > não é uma solução válida para a maioria dos casos.
> > >
> > > Os equipamentos de seus clientes podem ser variados, mas isso dificilmente
> > > justifica problemas de compatibilidade ou semelhantes. Os equipamentos que
> > > a MS testa e suporta são, com certeza, mais variados do que o conjunto de
> > > clientes da vasta maioria das software houses.
> > >
> > > Ainda assim, deixei explícito no post anterior que 1) instalação poderia
> > > ser um problema para seu caso e 2) a plataforma de hardware de seus clientes
> > > pode nào ser boa o suficiente para .NET. Mas repare que esses problemas que
> > > você cita não podem ser aplicados generica e indiscriminadamente; por exemplo:
> > > E se você tem clientes com plataformas 32 e 64 bits? Não seria mais fácil
> > > estar usando .NET para a maior parte das aplicações? Alguns projetos que
> > > consideraram instalação o grande problema usam soluções como http://www.xenocode.com/
> > > (isso não é uma recomendação).
> > >
> > > Meu ponto é lhe ajudar com problemas de performance; na minha experiência
> > > os maiores problemas de performance que vi não foram por causa do framework.
> > > Uma aplicação que leva 1 minuto para carregar, por exemplo, muito provavelmente
> > > tem problemas de projeto e implementação. Na grande maioria dos casos é possível
> > > fazer muito melhor do que isso sem usar as funcionalidades mais avançadas
> > > de .NET, como ngen, por exemplo (já vi cair de 2 minutos para 2 segundos).
> > > E se usar ngen você terá libraries compartilhadas em memória e ainda otimizações
> > > que um compilador/linkeditor jamais farão (cross-assembly inlining, por exemplo),
> > > etc.
> > >
> > > C++ é a minha linguagem preferida, mas é uma linguagem onde problemas de
> > > gerenciamento de memória, que acabam se manifestando em performance e confiabilidade,
> > > e de segurança já causaram muito mais impacto a times e produtos do que a
> > > performance em .NET. Pessoalmente, eu lhe aconselharia a levar tudo isso
> > > em conta ao tomar uma decisão com relação a sua plataforma de desenvolvimento.
> > >
> > >
> > > Não disputo de forma alguma de que em C++ seja mais fácil para desenvolvedores
> > > competentes construir aplicativos mais performantes. O que não acredito ser
> > > genéricamente correto é de que não se possa criar aplicativos com performance
> > > suficiente em .NET. Se você compartilhar um exemplo em que você mediu tais
> > > problemas, eu ou outras pessoas da lista podem lhe ajudar.
> > >
> > > -- Roberto Adlich
> > > Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
> > > direitos.
> > >
> > > > Roberto,
> > > >
> > > > Dá uma olhada, por exemplo, no post "API, MFC, C# ou Borland C++
> > > > Builder ?" aqui neste fórum.
> > > >
> > > > Nem precisa alguém falar que há um "custo" pra se instanciar o
> > > > Framework.NET porque esse custo é óbvio, além do transtorno do usuário
> > > > final ter que instalar. Se você tiver um cliente você vai lá e instala
> > > > ou explica pra ele onde obter e instalar, mas se você tiver um sistema
> > > > que é vendido no país inteiro choverá ligações pro pessoal do suporte
> > > > atender... e creia, pode ser simples como for, o usuário final liga
> > > > pedindo ajuda sim.
> > > >
> > > > Temos aplicações em ASP.NET que rodam no servidor e o cliente acessa
> > > > pelo navegador. Mas com tudo(Framework.NET) rodando na máquina do
> > > > cliente não temos ainda. Os equipamentos dos clientes são os mais
> > > > variados possíveis.
> > > >
> > > > Aplicações em C++ não gerenciado, por serem independentes de outras
> > > > parafernalhas e, por tanto, exigirem menos máquina, me parecem a
> > > > melhor alternativa.
> > > >
> > > > Os aplicativos que temos são escritos em Visual FoxPro. Nenhum cliente
> > > > nunca esperou um minuto enquanto o aplicativo é carregado. Se gerarmos
> > > > nova versão em C#, por exemplo, e o cliente tiver que esperar 1 minuto
> > > > pra, tão somente, o aplicativo ser iniciado estamos mortos.
> > > >
> > > > "Roberto Adlich dos Santos [MSFT]" escreveu:
> > > >
> > > >> Olá Geraldo,
> > > >>
> > > >> Qual é o problema de performance que você tem com .NET? Como mediu
> > > >> isso?
> > > >>
> > > >> Acho extremamente improvável que seus problemas estejam relacionados
> > > >> com a interface gráfica; e portanto não acredito que lhe seja
> > > >> vantajoso fazer escolhas de "plataforma de desenvolvimento" baseadas
> > > >> nisso. Você pode se beneficiar das qualidades que gostou ao usar VC++
> > > >> e WinForms com as funcionalidades do VS, e ainda assim escrever
> > > >> código nativo gerando um mized-mode assembly (código gerenciado e
> > > >> nativo no mesmo assembly) de forma transparente em VC++. Se planejar
> > > >> as interfaces bem não terá custo significativo de interop.
> > > >>
> > > >> Na verdade, não sei se seus problemas de performance estariam
> > > >> relacionados à código gerenciado em si, e se esse for o caso, você
> > > >> nem precisa de mixed mode necessariamente. A não ser que "exigir
> > > >> muita máquina" seja relacionado a instalação do framework ou uma
> > > >> quantidade mínima (que é absolutamente razoável) de memória para
> > > >> fazer o Gargabe Collector eficiente, não tenho certeza que seus
> > > >> problemas de performance estejam relacionados a .NET em si.Se você
> > > >> postar informações específicas sobre os problemas, alguém pode acabar
> > > >> dando idéias de como melhorar a performance.
> > > >>
> > > >> -- Roberto Adlich
> > > >> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão
> > > >> de quaisquer
> > > >> direitos.
> > > >>> Frederico,
> > > >>>
> > > >>> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
> > > >>> Application Devolopment.
> > > >>>
> > > >>> Sou programador FoxPro há sete anos, agora estou querendo aprender
> > > >>> C++ por ser mais rápido, flexível e exigir menos máquina do usuário
> > > >>> final.
> > > >>>
> > > >>> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> > > >>> facilidade, mas notei que tudo que eu estava fazendo era encima do
> > > >>> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
> > > >>> quero porque é ainda mais lendo do que as aplicações escritas em
> > > >>> FoxPro e exige ainda mais máquina.
> > > >>>
> > > >>> Então instalei a PlatformSDK, configurei tudo e está funcionando,
> > > >>> mas sentí falta dos recursos de arrastar e soltar. Estou disposto a
> > > >>> fazer tudo na mão mesmo, não tem problema, mas não sei por onde
> > > >>> começar.
> > > >>>
> > > >>> Se você tiver um tutorial que mostre passo-a-passo como fazer um
> > > >>> form simples com um textbox e um command button em C++ 2005 Express
> > > >>> pra me indicar fico agradecido.
> > > >>>
> > > >>> "Frederico Pissarra" escreveu:
> > > >>>
> > > >>>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
> > > >>>> wrote in message
> > > >>>> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> > > >>>>
> > > >>>>> Pessoal,
> > > >>>>>
> > > >>>>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
> > > >>>>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
> > > >>>>> como faço pra desenhar forms por RAD também ?
> > > >>>>>
> > > >>>> Depende do seu conceito de RAD... Usando a MFC (Microsoft
> > > >>>> Foundation Classes) vc tem a opção de criar Dialog Boxes e usá-las
> > > >>>> com a classe CFormView. Não é a mesma coisa que o ambiente do .NET,
> > > >>>> mas poupa algum trabalho.... Em essência, não há ambiente RAD com
> > > >>>> C++ e bibliotecas nativas (Win32).
> > > >>>>
> > > >>>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
> > > >>>> pura (Chamadas de funções), RAD é um recurso que vc não tem!
> > > >>>>
> > > >>>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo
> > > >>>> quando possa parecer... Com o Visual Studio e MFC vc ainda tem
> > > >>>> wizards para criar a tabela de mensagens pra você (basta observar
> > > >>>> as propriedades da classe desejada).... O que vc não tem é o
> > > >>>> recurso de arrastar-e-soltar para colocar componentes no local
> > > >>>> desejado da janela (Isso é feito em código!)...
> > > >>>>
> > > >>>> []s
> > > >>>> Fred
> > >
> > >
> > >

Bom dia Roberto.
Poderia me ajudar com o Visual C++ 2005 Express.
Tenho conhecimento da linguagem, ms já tem 2 semanas q baixei a ferramenta.
Usava o compilador da Borland.
Baixei o Visual C++ 2005 o framework 2.0 e o SDK. Instalei tudo.
Fiz uma aplicação simples para testar. Um form com um botão sem função,
rodei e funcionou normalmente em minha máquina, e pelo disquete na minha
máquina, ms quando tento rodar em outra máquina seja com disquete ou Hd ou
seja máquinas XP com framework 2.0 ou sem o programa não roda, dá erros.
Postei isso no forum em Visual C++ 2005 Express.

Gostaria de saber como faço para rodar um executável compilado com o VC++
2005 Express em outra máquina q não possui a ferramenta, pois fiz um form
simples e só consigo rodar em minha máquina.
Testei em máquina com XP e framework, deu erro e sem o framework tb deu erro
1º - Falha na inicialização do aplicativo devido a configuração incorreta. A
reinstalação do aplicativo pode resolver o problema.
2º - com o framework >> Application has generated an exception that could
not be handled. Process id = 0xfffb306f(-315281), thread
id=0xfffb325f(-314785)

Gostaria tb de saber se existe algum livro, apostila (preferencia portugues)
ou curso desta ferramenta, pois da linguagem já possuo.

Tem como me ajudar?

Como faço para simplesmente copiar e colar o executável???

"Thiago R. Adams" escreveu:

> Roberto:
>
> "A instalação do .NET Framework pode ser automatizada a partir do seu
> programa
> de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
> diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
> todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
> não é uma solução válida para a maioria dos casos."
>
> Só uma correção:
> É possível fazer um aplicativo em VC++ unmanaged sem a dependencia das dlls
> da versão 8. É uma configuração do projeto. As dependencias ficam apenas das
> dlls que qualquer windows tem na system.
> Ou seja, é possível "copiar e colar".
>
>

Poderia me ajudar com o Visual C++ 2005 Express.
Tenho conhecimento da linguagem, ms já tem 2 semanas q baixei a ferramenta.
Usava o compilador da Borland.
Baixei o Visual C++ 2005 o framework 2.0 e o SDK. Instalei tudo.
Fiz uma aplicação simples para testar. Um form com um botão sem função,
rodei e funcionou normalmente em minha máquina, e pelo disquete na minha
máquina, ms quando tento rodar em outra máquina seja com disquete ou Hd ou
seja máquinas XP com framework 2.0 ou sem o programa não roda, dá erros.
Postei isso no forum em Visual C++ 2005 Express.

Gostaria de saber como faço para rodar um executável compilado com o VC++
2005 Express em outra máquina q não possui a ferramenta, pois fiz um form
simples e só consigo rodar em minha máquina.
Testei em máquina com XP e framework, deu erro e sem o framework tb deu erro
1º - Falha na inicialização do aplicativo devido a configuração incorreta. A
reinstalação do aplicativo pode resolver o problema.
2º - com o framework >> Application has generated an exception that could
not be handled. Process id = 0xfffb306f(-315281), thread
id=0xfffb325f(-314785)

Gostaria tb de saber se existe algum livro, apostila (preferencia portugues)
ou curso desta ferramenta, pois da linguagem já possuo.

Tem como me ajudar?


"Frederico Pissarra" escreveu:

> Geraldo,
>
> Vc tb pode programar em .NET usando C++.... dai vc "ganha" os recursos RAD
> que quer.... e ainda "ganha" a possibilidade de misturar unmanaged code com
> managed code... (p.ex: alocar memória no heap da aplicação ao invés do
> garbage collector!).
>
> []s
> Fred
>
> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com> escreveu na
> mensagem news:2224FAB3-8F01-4274-ADBA-992E19C41931@microsoft.com...
> > Frederico,
> >
> >
> > Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid Application
> > Devolopment.
> >
> > Sou programador FoxPro há sete anos, agora estou querendo aprender C++ por
> > ser mais rápido, flexível e exigir menos máquina do usuário final.
> >
> > Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> > facilidade, mas notei que tudo que eu estava fazendo era encima do
> > Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não quero
> > porque é ainda mais lendo do que as aplicações escritas em FoxPro e exige
> > ainda mais máquina.
> >
> > Então instalei a PlatformSDK, configurei tudo e está funcionando, mas
> > sentí
> > falta dos recursos de arrastar e soltar. Estou disposto a fazer tudo na
> > mão
> > mesmo, não tem problema, mas não sei por onde começar.
> >
> > Se você tiver um tutorial que mostre passo-a-passo como fazer um form
> > simples com um textbox e um command button em C++ 2005 Express pra me
> > indicar
> > fico agradecido.
> >
> >
> >
> > "Frederico Pissarra" escreveu:
> >
> >>
> >> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com> wrote in
> >> message news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> >> > Pessoal,
> >> >
> >> >
> >> > Quando uso o Framework.NET tenho recursos RAD... se alterno pra
> >> > Plataform
> >> > SDK, onde passo a usar as bibliotecas nativas do Windows como faço pra
> >> > desenhar forms por RAD também ?
> >>
> >> Depende do seu conceito de RAD... Usando a MFC (Microsoft Foundation
> >> Classes) vc tem a opção de criar Dialog Boxes e usá-las com a classe
> >> CFormView. Não é a mesma coisa que o ambiente do .NET, mas poupa algum
> >> trabalho.... Em essência, não há ambiente RAD com C++ e bibliotecas
> >> nativas
> >> (Win32).
> >>
> >> Especialmente se vc estiver usando o PlatformSDK na sua forma mais pura
> >> (Chamadas de funções), RAD é um recurso que vc não tem!
> >>
> >> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo quando
> >> possa
> >> parecer... Com o Visual Studio e MFC vc ainda tem wizards para criar a
> >> tabela de mensagens pra você (basta observar as propriedades da classe
> >> desejada).... O que vc não tem é o recurso de arrastar-e-soltar para
> >> colocar
> >> componentes no local desejado da janela (Isso é feito em código!)...
> >>
> >> []s
> >> Fred
> >>
> >>
> >>
>
>
>

Bom dia Roberto.
Poderia me ajudar com o Visual C++ 2005 Express.
Tenho conhecimento da linguagem, ms já tem 2 semanas q baixei a ferramenta.
Usava o compilador da Borland.
Baixei o Visual C++ 2005 o framework 2.0 e o SDK. Instalei tudo.
Fiz uma aplicação simples para testar. Um form com um botão sem função,
rodei e funcionou normalmente em minha máquina, e pelo disquete na minha
máquina, ms quando tento rodar em outra máquina seja com disquete ou Hd ou
seja máquinas XP com framework 2.0 ou sem o programa não roda, dá erros.
Postei isso no forum em Visual C++ 2005 Express.

Gostaria de saber como faço para rodar um executável compilado com o VC++
2005 Express em outra máquina q não possui a ferramenta, pois fiz um form
simples e só consigo rodar em minha máquina.
Testei em máquina com XP e framework, deu erro e sem o framework tb deu erro
1º - Falha na inicialização do aplicativo devido a configuração incorreta. A
reinstalação do aplicativo pode resolver o problema.
2º - com o framework >> Application has generated an exception that could
not be handled. Process id = 0xfffb306f(-315281), thread
id=0xfffb325f(-314785)

Gostaria tb de saber se existe algum livro, apostila (preferencia portugues)
ou curso desta ferramenta, pois da linguagem já possuo.

Tem como me ajudar?


"Roberto Adlich dos Santos [MSFT]" escreveu:

> Olá Geraldo,
>
> A instalação do .NET Framework pode ser automatizada a partir do seu programa
> de setup. O setup básico que se cria com Visual Studio faz isso. Não é tão
> diferente de ter que instalar os redistributables para MFC/ATL/CRT que são
> todos assemblies na versão 8.0 (não é só copiar, etc). Linkar tudo junto
> não é uma solução válida para a maioria dos casos.
>
> Os equipamentos de seus clientes podem ser variados, mas isso dificilmente
> justifica problemas de compatibilidade ou semelhantes. Os equipamentos que
> a MS testa e suporta são, com certeza, mais variados do que o conjunto de
> clientes da vasta maioria das software houses.
>
> Ainda assim, deixei explícito no post anterior que 1) instalação poderia
> ser um problema para seu caso e 2) a plataforma de hardware de seus clientes
> pode nào ser boa o suficiente para .NET. Mas repare que esses problemas que
> você cita não podem ser aplicados generica e indiscriminadamente; por exemplo:
> E se você tem clientes com plataformas 32 e 64 bits? Não seria mais fácil
> estar usando .NET para a maior parte das aplicações? Alguns projetos que
> consideraram instalação o grande problema usam soluções como http://www.xenocode.com/
> (isso não é uma recomendação).
>
> Meu ponto é lhe ajudar com problemas de performance; na minha experiência
> os maiores problemas de performance que vi não foram por causa do framework.
> Uma aplicação que leva 1 minuto para carregar, por exemplo, muito provavelmente
> tem problemas de projeto e implementação. Na grande maioria dos casos é possível
> fazer muito melhor do que isso sem usar as funcionalidades mais avançadas
> de .NET, como ngen, por exemplo (já vi cair de 2 minutos para 2 segundos).
> E se usar ngen você terá libraries compartilhadas em memória e ainda otimizações
> que um compilador/linkeditor jamais farão (cross-assembly inlining, por exemplo),
> etc.
>
> C++ é a minha linguagem preferida, mas é uma linguagem onde problemas de
> gerenciamento de memória, que acabam se manifestando em performance e confiabilidade,
> e de segurança já causaram muito mais impacto a times e produtos do que a
> performance em .NET. Pessoalmente, eu lhe aconselharia a levar tudo isso
> em conta ao tomar uma decisão com relação a sua plataforma de desenvolvimento.
>
>
> Não disputo de forma alguma de que em C++ seja mais fácil para desenvolvedores
> competentes construir aplicativos mais performantes. O que não acredito ser
> genéricamente correto é de que não se possa criar aplicativos com performance
> suficiente em .NET. Se você compartilhar um exemplo em que você mediu tais
> problemas, eu ou outras pessoas da lista podem lhe ajudar.
>
> -- Roberto Adlich
> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão de quaisquer
> direitos.
>
> > Roberto,
> >
> > Dá uma olhada, por exemplo, no post "API, MFC, C# ou Borland C++
> > Builder ?" aqui neste fórum.
> >
> > Nem precisa alguém falar que há um "custo" pra se instanciar o
> > Framework.NET porque esse custo é óbvio, além do transtorno do usuário
> > final ter que instalar. Se você tiver um cliente você vai lá e instala
> > ou explica pra ele onde obter e instalar, mas se você tiver um sistema
> > que é vendido no país inteiro choverá ligações pro pessoal do suporte
> > atender... e creia, pode ser simples como for, o usuário final liga
> > pedindo ajuda sim.
> >
> > Temos aplicações em ASP.NET que rodam no servidor e o cliente acessa
> > pelo navegador. Mas com tudo(Framework.NET) rodando na máquina do
> > cliente não temos ainda. Os equipamentos dos clientes são os mais
> > variados possíveis.
> >
> > Aplicações em C++ não gerenciado, por serem independentes de outras
> > parafernalhas e, por tanto, exigirem menos máquina, me parecem a
> > melhor alternativa.
> >
> > Os aplicativos que temos são escritos em Visual FoxPro. Nenhum cliente
> > nunca esperou um minuto enquanto o aplicativo é carregado. Se gerarmos
> > nova versão em C#, por exemplo, e o cliente tiver que esperar 1 minuto
> > pra, tão somente, o aplicativo ser iniciado estamos mortos.
> >
> > "Roberto Adlich dos Santos [MSFT]" escreveu:
> >
> >> Olá Geraldo,
> >>
> >> Qual é o problema de performance que você tem com .NET? Como mediu
> >> isso?
> >>
> >> Acho extremamente improvável que seus problemas estejam relacionados
> >> com a interface gráfica; e portanto não acredito que lhe seja
> >> vantajoso fazer escolhas de "plataforma de desenvolvimento" baseadas
> >> nisso. Você pode se beneficiar das qualidades que gostou ao usar VC++
> >> e WinForms com as funcionalidades do VS, e ainda assim escrever
> >> código nativo gerando um mized-mode assembly (código gerenciado e
> >> nativo no mesmo assembly) de forma transparente em VC++. Se planejar
> >> as interfaces bem não terá custo significativo de interop.
> >>
> >> Na verdade, não sei se seus problemas de performance estariam
> >> relacionados à código gerenciado em si, e se esse for o caso, você
> >> nem precisa de mixed mode necessariamente. A não ser que "exigir
> >> muita máquina" seja relacionado a instalação do framework ou uma
> >> quantidade mínima (que é absolutamente razoável) de memória para
> >> fazer o Gargabe Collector eficiente, não tenho certeza que seus
> >> problemas de performance estejam relacionados a .NET em si.Se você
> >> postar informações específicas sobre os problemas, alguém pode acabar
> >> dando idéias de como melhorar a performance.
> >>
> >> -- Roberto Adlich
> >> Esta mensagem é fornecida "como apresentada" sem garantias ou cessão
> >> de quaisquer
> >> direitos.
> >>> Frederico,
> >>>
> >>> Entendo RAD como o recurso de arrastar e soltar, isto é, Rapid
> >>> Application Devolopment.
> >>>
> >>> Sou programador FoxPro há sete anos, agora estou querendo aprender
> >>> C++ por ser mais rápido, flexível e exigir menos máquina do usuário
> >>> final.
> >>>
> >>> Instalei o C++ 2005 Express, fui testar e estava entusiasmado com a
> >>> facilidade, mas notei que tudo que eu estava fazendo era encima do
> >>> Framework.NET, isto é, eu estava escrevendo em C++ .NET e assim não
> >>> quero porque é ainda mais lendo do que as aplicações escritas em
> >>> FoxPro e exige ainda mais máquina.
> >>>
> >>> Então instalei a PlatformSDK, configurei tudo e está funcionando,
> >>> mas sentí falta dos recursos de arrastar e soltar. Estou disposto a
> >>> fazer tudo na mão mesmo, não tem problema, mas não sei por onde
> >>> começar.
> >>>
> >>> Se você tiver um tutorial que mostre passo-a-passo como fazer um
> >>> form simples com um textbox e um command button em C++ 2005 Express
> >>> pra me indicar fico agradecido.
> >>>
> >>> "Frederico Pissarra" escreveu:
> >>>
> >>>> "Geraldo F. Barbosa" <GeraldoFBarbosa@discussions.microsoft.com>
> >>>> wrote in message
> >>>> news:4DED8A2D-7C32-4669-B296-DFE50915C9EB@microsoft.com...
> >>>>
> >>>>> Pessoal,
> >>>>>
> >>>>> Quando uso o Framework.NET tenho recursos RAD... se alterno pra
> >>>>> Plataform SDK, onde passo a usar as bibliotecas nativas do Windows
> >>>>> como faço pra desenhar forms por RAD também ?
> >>>>>
> >>>> Depende do seu conceito de RAD... Usando a MFC (Microsoft
> >>>> Foundation Classes) vc tem a opção de criar Dialog Boxes e usá-las
> >>>> com a classe CFormView. Não é a mesma coisa que o ambiente do .NET,
> >>>> mas poupa algum trabalho.... Em essência, não há ambiente RAD com
> >>>> C++ e bibliotecas nativas (Win32).
> >>>>
> >>>> Especialmente se vc estiver usando o PlatformSDK na sua forma mais
> >>>> pura (Chamadas de funções), RAD é um recurso que vc não tem!
> >>>>
> >>>> Mas, desenvolver em C++ sem ambiente RAD não é tão improdutivo
> >>>> quando possa parecer... Com o Visual Studio e MFC vc ainda tem
> >>>> wizards para criar a tabela de mensagens pra você (basta observar
> >>>> as propriedades da classe desejada).... O que vc não tem é o
> >>>> recurso de arrastar-e-soltar para colocar componentes no local
> >>>> desejado da janela (Isso é feito em código!)...
> >>>>
> >>>> []s
> >>>> Fred
>
>
>

"Daniel Jorge" <DanielJorge@discussions.microsoft.com> escreveu na mensagem
news:BAF3832C-4A95-4DCE-A068-03549B6A93DD@microsoft.com...
> Bom dia Roberto.
> Poderia me ajudar com o Visual C++ 2005 Express.
> Tenho conhecimento da linguagem, ms já tem 2 semanas q baixei a
> ferramenta.
> Usava o compilador da Borland.
> Baixei o Visual C++ 2005 o framework 2.0 e o SDK. Instalei tudo.
> Fiz uma aplicação simples para testar. Um form com um botão sem função,
> rodei e funcionou normalmente em minha máquina, e pelo disquete na minha
> máquina, ms quando tento rodar em outra máquina seja com disquete ou Hd ou
> seja máquinas XP com framework 2.0 ou sem o programa não roda, dá erros.
> Postei isso no forum em Visual C++ 2005 Express.
>
> Gostaria de saber como faço para rodar um executável compilado com o VC++
> 2005 Express em outra máquina q não possui a ferramenta, pois fiz um form
> simples e só consigo rodar em minha máquina.
> Testei em máquina com XP e framework, deu erro e sem o framework tb deu
> erro
> 1º - Falha na inicialização do aplicativo devido a configuração incorreta.
> A
> reinstalação do aplicativo pode resolver o problema.
> 2º - com o framework >> Application has generated an exception that could
> not be handled. Process id = 0xfffb306f(-315281), thread
> id=0xfffb325f(-314785)
>

Daniel, não precisa postar a mesma mensagem 4 vezes pra ter a atenção do
povo... :)

Well... pelo que vc tá relatando parece que vc fez uma aplicação .NET, e não
MFC...
Neste caso, as máquinas onde o seu programa vai rodar precisam ter o .NET
Framework instalado e rodando, senão essas
"exceções que não podem ser manipuladas" vão ocorrer mesmo.... O Visual
Studio 2005 instala o .NET Framework 2.0 (que não acompanha o WinXP)...
experimente instalá-lo (somente o framework 2.0) e vê no que dá...

Se sua aplicação não for .NET você precisa distribuir uma série de DLLs
(MSVCRT e etc) para que a aplicação possa funcionar... Dê uma olhada no MSDN
e procure algo sobre "deploying MFC applications" e o Visual Studio 2005....

[]s
Fred