Unmanaged Visual C++ 2005 questions

[Olaf Baeyens]

The new Visual C++ 2005 is coming out in a theater near you.
Just a few questions:

* How will the users that use my program upgrade to the .NET framework 2.0?
My current users already refuse to install the v1.x framework since they
clame it is too complicated.

* Can we still compile pure unmanaged C++ executables so that our users do
not need to install a .NET framework? With VC++ 2003 it could, but since
Microsoft is pushing to .NET (I love .NET) the resulting executable might
expect the .NET all the time from now on even when no managed extensions are
used.

 

[Jochen Kalmbach [MVP]]

Hi Olaf!

The new Visual C++ 2005 is coming out in a theater near you.

Nov 2005...

* How will the users that use my program upgrade to the .NET framework 2.0?
My current users already refuse to install the v1.x framework since they
clame it is too complicated.

You have the same problem for XP...
(maybe it will be integrated with SP3...)

But most systems have it already installed (most software has integrated
the dotNet.msm in their setup (like ATI-Video-Drivers...)

* Can we still compile pure unmanaged C++ executables so that our users do
not need to install a .NET framework? With VC++ 2003 it could, but since
Microsoft is pushing to .NET (I love .NET) the resulting executable might
expect the .NET all the time from now on even when no managed extensions are
used.

You can still develop unmanaged code.

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Olaf Baeyens]

The new Visual C++ 2005 is coming out in a theater near you.

Nov 2005...

Around the 7th.

You have the same problem for XP...
(maybe it will be integrated with SP3...)

If I look at how happy people are to install SP2, then I doubt it that SP3
will be installed if I ship my program.
One of the people here managed to delay the SP2 install by 6 months. Untill
he went on holiday and I took over his machine (I am IT too). I still don't
understand all the fuzz he had of not installing it. I think it is some kind
of scare of the unknown.

But most systems have it already installed (most software has integrated
the dotNet.msm in their setup (like ATI-Video-Drivers...)

It is getting better, but most users we have simply refuse to install it and
it is not really a mass product we create (yet), so harder to push the .NET
framework installation as requirement. For 2 years I have been advocating
this .NET but I am only one and they are many. :-(

But it is good that ATI and VB programmers use .NET now, that means that
users somehow are forced by others to install it, so my installation will
become simpler in time. Hopefully in my lifetime. ;-)

You can still develop unmanaged code.

I was expecting this, but I could not find this on the information I have
seen.
So buying it will not get the people scared that I want to go all the way
for the .NET thing.

 

[Jochen Kalmbach [MVP]]

Hi Olaf!

It is getting better, but most users we have simply refuse to install it and
it is not really a mass product we create (yet), so harder to push the .NET
framework installation as requirement. For 2 years I have been advocating
this .NET but I am only one and they are many. :-(

ATI has *integrated* the dotNET-Framework in their setup. So the user
does *not* recognise that it will be installed

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Guest]

* Can we still compile pure unmanaged C++ executables so that our users do
not need to install a .NET framework? With VC++ 2003 it could, but since
Microsoft is pushing to .NET (I love .NET) the resulting executable might
expect the .NET all the time from now on even when no managed extensions are
used.

Since MS support for VC++ 6.0 will soon lapse, VC++ 8.0 and all future
releases for many years to come had **better** support unmanaged code,
because there's a mighty lot of it out there that must still be maintained!!!
Also, MS is itself writing Longhorn in unmanaged C/C++, isn't it? It's my
understanding that Avalon, Indigo, etc., are not written in .NET.

 

[Carl Daniel [VC++ MVP]]

Since MS support for VC++ 6.0 will soon lapse, VC++ 8.0 and all future
releases for many years to come had **better** support unmanaged code,
because there's a mighty lot of it out there that must still be
maintained!!! Also, MS is itself writing Longhorn in unmanaged C/C++,
isn't it? It's my understanding that Avalon, Indigo, etc., are not
written in .NET.

Avalon and Indigo are managed code. If not 100%, then nearly so. Many of
the new parts of Visual Studio 2005 (e.g. all of the Team System stuff) is
managed code.

The core OS is and always will be native C and C++.

But yes, native code development will be supported forever. Afterall, the
CLR itself is unmanaged code, and they'll always need tools to build that.

-cd

 

[Guest]

I suppose I misinterpreted Scoble's remarks in
http://channel9.msdn.com/ShowPost.aspx?PostID=72074

The parts of Avalon that Longhorn relies on are not managed, as far as I know.

Maybe I was assuming that Longhorn "relies on" more of Avalon than it
actually does, since (originally) Avalon, Indigo, and WinFS were declared the
"Three Pillars of Longhorn". Now, apparently, it's less of a "pillar" than
an attached ornament? So how much of Avalon is written in C/C++, and how
much is written in C#? Anyway, the part of Avalon that Longhorn **does**
rely on is unmanaged, it seems. And of course, as you say the code base of
Longhorn is itself unmanaged, since it's built starting with Windows 2003.
It will be a long time, if ever, before Windows is unmanaged code, I'm sure
we all agree. If that made sense, then Solaris would be written in Java.

Wil