From C# going to c++

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I still wait, but you know, all major companies, like Sony, canon, Philips,
Nokia and many others still write software for their products in
c++/MFC/win32 , although there are no legacy codes there for many of their
new applications and their only target platforms is mainly Win XP (was not
.net platform free?!)

You think Google would code its Google Earth, Google Talk, Picasa, Google
Desktop and other products in C# if .Net Framework was preinstalled on
Windows XP ?

Most of the Google apps support Windows, MacOS X and Linux.

With that requirement I can understand that they did consider
alternatives to .NET (and Mono for MacOS X and Linux).

I am so Cynic on this issue. I don't think any of these big companies will
ever write their commercial products in .net ( except for some small
utilities list "Disk-to-Phone) by SonyEricsson)

How many really big new desktop apps has been created within
the last 6 years ?

My guess is: not many.

We know that .NET apps are doing very well as replacement for
VB6 client apps.

We know that ASP.NET are doing very well in business web sites.

Arne

 

[Ben Voigt [C++ MVP]]

What GUI library do you want to code against ? Win32 API ? MFC ?

There are a lot MFC code out there.

But I would consider .NET and WPF a much more future proof
route than MFC.

No evidence supporting that. Microsoft has indicated a commitment to
maintaining and improving MFC.

WPF will be faster than the raw Win32 API for graphics intensive things,
unless you want to code against DirectX yourself.

 

[Ben Voigt [C++ MVP]]

And who were the main targets of this technology?

Database-intensive line-of-business web apps.

 

[Ben Voigt [C++ MVP]]

I can't decide if you really mean this, or are being sarcastic. At the
risk of looking foolish, I'll go with "really mean it" for $200.

The reason is that most people can do more in 15 minutes with WinForms and
.Net than they could in several days worth of Win32 programming (or even
Java and a good GUI toolkit, or, heck VB6). .Net has taken all the really
common use cases for development and made them very easy to use.This
evolution has taken place over 10+ years, and is very far along.

That's a case for reusing a higher level library, yes. Not for using the
..NET runtime.

There's a reason application like VB (3,4,5,6), Delphi, C++ Builder, and
MFC all did so well - it's because Win32 is a slow and painful environment
to work in. Why anyone would choose to code against a "C" API in this day
and age is a mystery to me.

C APIs are incredibly friendly to a huge number of languages. They also
tend not to break binary compatibility because you upgraded the compiler.
Try writing a C# 2.0 plugin for a .NET 1.1 application... I think straight
Win32 API still wins in some scenarios, .NET can still manage to do it, but
no longer any less programming effort.

Creating fancy windows? Adding Skins to an application? Click-Once
Deployment? Adding Menu's and Toolbars? Adding a Office Style Ribbon? MDI?
SDI? Animations? Office Automation? File I/O? Socket I/O? Windows
Services? Database Access? All of these are much easier to code in .Net
over Win32. The difference is so vast between the two, that coding in
Win32 is no longer cost effective.

All of the above I might agree with except I/O. Pure Win32 beats .NET by a
handsome margin in the area of usability there, because .NET doesn't allow
completion functions to be run sequentially on the main thread. Sure, some
applications have multiple independent users, but anything where the
connections are coupled doesn't benefit from being forced into using thread
queues.

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

No evidence supporting that. Microsoft has indicated a commitment to
maintaining and improving MFC.

And why do you think they have found it necessary to do that ?

Because everybody is convinced that MFC has a great future ahead
or because everybody is expecting that MFC could go the way of VB6
as soon as MSO are redone in .NET ?

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=970938&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1080803&SiteID=1

shows some status.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

C APIs are incredibly friendly to a huge number of languages. They also
tend not to break binary compatibility because you upgraded the compiler.
Try writing a C# 2.0 plugin for a .NET 1.1 application... I think straight
Win32 API still wins in some scenarios, .NET can still manage to do it, but
no longer any less programming effort.

It is not obvious to me that there are any difference in
compatibility.

..NET 1.1 code is expected to always work with 2.0

..NET 2.0 code is not expected to always work with 1.1

Win32 API in Win 2000 is expected to always work in 2003.

Win32 API in Win 2003 is not expected to always work in 2000.

Arne

 

[Ben Voigt [C++ MVP]]

It is not obvious to me that there are any difference in
compatibility.

.NET 1.1 code is expected to always work with 2.0

.NET 2.0 code is not expected to always work with 1.1

Win32 API in Win 2000 is expected to always work in 2003.

Win32 API in Win 2003 is not expected to always work in 2000.

Arne

That's a huge difference in compatibility. In one case you are talking
about the toolchain, in the other case about the API.

C++ code compiled in VC++ 2005 on Win2003 will run just fine on Win2000,
even if it uses new C++ features introduced in the newer compiler, as long
as you stick to the rather large subset of Win32 functions available in
Win2000.

You can't, however, use VS2005 and the new C# compiler to build code that
will run on .NET 1.1, whether you use the new classes or not. More to the
point, even if the user has .NET 2.0, you can't use C# 2.0 to build a plugin
for an application built with .NET 1.1 -- you can't tell the C# 2.0 compiler
to emit metadata that the old app can understand. Multiple versions of the
C runtime happily coexist in the same process, while multiple .NET runtimes
do not.

 

[nobody]

Good points!

..NET just has many flaws too.

That's a huge difference in compatibility. In one case you are talking
about the toolchain, in the other case about the API.

C++ code compiled in VC++ 2005 on Win2003 will run just fine on Win2000,
even if it uses new C++ features introduced in the newer compiler, as long
as you stick to the rather large subset of Win32 functions available in
Win2000.

You can't, however, use VS2005 and the new C# compiler to build code that
will run on .NET 1.1, whether you use the new classes or not. More to the
point, even if the user has .NET 2.0, you can't use C# 2.0 to build a
plugin for an application built with .NET 1.1 -- you can't tell the C# 2.0
compiler to emit metadata that the old app can understand. Multiple
versions of the C runtime happily coexist in the same process, while
multiple .NET runtimes do not.