Report from MVP Summit
Joseph M. Newcomer
discussions starts up...
Microsoft has admitted they have not publicized well their commitment to MFC and native
code, but it is there and they will make this more apparent in the future. .NET has not
killed MFC, nor is there anything in the plans through the next two releases to kill MFC
and native code. Rather the opposite: there is a commitment to support them and enhance
them. The technical people feel that the perception that MFC is dead is the result of
poor publicity, not anything rooted in any fact visible within Microsoft or the
development groups.
We gave a lot of feedback, and made it clear that the "fit and finish" aspects of making
the IDE usable and consistent are really important. This will have little impact on the
next release (it is too far along to change anything in its schedule, apparently) but
should ideally have some serious impact on the next release + 1. That's about the best
commitment we could get...that they'll think really hard about this for the next release +
1. We had interesting technical discussions with various people, but I'm not sure I can
talk about anything that was discussed in any detail due to NDA considerations. A lot of
what we saw was labeled "Microsoft Confidential" and I'm taking that seriously.
One thing I was told we are allowed to say is that there is a continuing commitment to
support and enhance native code support and MFC in particular.
So ideally the "MFC is dead" discussions are dead. For the next several years, at least!
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Nobody
With each advent of a new language, it does not "completely" make the
previous language inferior.
C# and VB does not make MFC inferior. It is just makes it easier to program
with.
Assembly has not gone away.
C has not gone away.
Java, VB and C# just make it easier to code C++ and MFC. (Garbage collection
and such)
The same way C makes it easier to code Assembly,
and C++ makes it easier to code C.
There will always be the performance -vs- release time trade-off issues.
Time to release will always win.
There is always time to release patches and fixes.
Look at where the Jobs are going these days.
Compare C, C++, MFC, Borland, with C#, Java, SQL, VB and "Fortran".
There is just less need for it.
Tom Serface
Tom
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:7ftrv2dr1rti783cu...@4ax.com...
Tom Serface
No one ever said MFC was "easy", just that it was useful. It certainly has
a niche and I'm glad to see Microsoft back on that bandwagon again.
Tom
"Nobody" <Nob...@yahoo.com> wrote in message
news:uz0KoVda...@TK2MSFTNGP06.phx.gbl...
David Webber
> Please just reference this message the next time one of those insane "MFC
> is dead"
> discussions starts up...
Thanks for the reassurance!
Dave
--
David Webber
Author MOZART the music processor for Windows -
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mzusers/mailinglist.htm
Pete Delgado
> is dead"
> discussions starts up...
>
> Microsoft has admitted they have not publicized well their commitment to
> MFC and native
> code, but it is there and they will make this more apparent in the future.
> .NET has not
> killed MFC, nor is there anything in the plans through the next two
> releases to kill MFC
> and native code. Rather the opposite: there is a commitment to support
> them and enhance
> them. The technical people feel that the perception that MFC is dead is
> the result of
> poor publicity, not anything rooted in any fact visible within Microsoft
> or the
> development groups.
Le Roi Est Mort, Vive Le Roi!
-Pete
David Ching
"Steve Teixeira and Bill Dunlap: Visual C++ Today and Tomorrow"
at http://channel9.msdn.com/ShowPost.aspx?PostID=281987
This was the same video I posted about a little over a week ago. The same
presenters met with the MVP's last week and said much the same thing, but in
more depth. We also saw some pretty cool demos. In order to not divulge
NDA information, I just watched the above video again and took notes.
The video said:
Why is C++ still relevant?
* Native apps with large C++ codebases, which are still being innovated on
(code not "dead")
* Performance counts - e.g. virus scanner is better suited to native code
than managed code.
* Multi-platform support, if app needs to run on other OS's besides
Windows. Standards conformance is important to these people.
What is the mindset of C++ developers regarding new languages?
* C++ developers understand the machine at a fundamental level; they are
the ones who can "can write the garbage collector".
* C++ developers love their language, BUT
* C++ developers can learn other languages easily, because C++ is one of
the hardest languages to learn.
* C++ developers don't hesitate to go to C#, Perl, or another "easier"
language which is better suited to the task.
* C++ developers are want to "extend" their C++ apps to use, e.g. WPF
(Windows Presentation Foundation aka Avalon).
But they don't necessarily want to program WPF in C++. They are
comfortable using C#.
What is the new Microsoft C++ strategy to cater to these developers?
* Strategy: Focus on straight native C++ development + interop into
managed code. Don't try to match C# feature-for-feature
in Unmanaged development.
* First steps, already shipping -- It Just Works and C++/CLI language
enhancements.
* MFC and IE were "sick" for 4-5 years, but no longer. Microsoft message
"could have been done better." Now message is, "Both
native and managed code are great and can exist simultaneously."
* Aero/shell extensions are examples of modern native C++ development.
Big investment in MFC, will "love what we're doing with
native libraries".
* Tighter communication with Windows team. "Walk hand in hand with them"
to match API's with wrappers, etc. 7,000 new Windows
API's in Vista that are all native.
* Will not match C# feature for feature. e.g. Linq will not be
programmable in C++/CLI.
May be some opportunities for some interop with C++ in the future.
New Features in Orcas (aka Visual Studio 2007, now in CTP on MSDN)
* "Marshalling library". Convert, e.g. System::String <--> CString/STL
string. "One little template-based call". Supports a bunch of different
types.
* STL-CLR. Bring STL container library and use it for .NET development.
* Fully support native Vista deployment, e.g. wrappers around Vista + XP
controls, new Spy++, etc.
* DevXpress refactoring engine - partnership with DevXpress for Orcas
release.
Features in Orcas+1 (next version of Visual Studio after Orcas)
* Modernize dev environment. Modernize Compiler front-end, which is 30
year old code written with resource-scarce mentality to conserve memory,
decrease
build times. Result is, front-end can't support what C#/VB type dev
experience. Also, C++ problem is harder because native environment is more
complex,
C++ is more complex than managed equivilents. New front-end is
essential.
* There are lots of huge (millions of lines of code) legacy codebases that
needs Intellisense/Refactoring, but even more. These problems haven't beeen
solved
in other C++ environments either. Need to catch up with advanced in
C#/VB, plus "blaze new trails" in giving tools to grok huge legacy C++
codebases.
Compiler front-end being revamped to support this, as well as multi-core
CPU development, as well as "type safety/memory safety". Go beyond /GS and
safe
string libraries. "Fat pointers", etc. looked at by Herb Sutter which
allows type casting but in a safer way.
* TR-1: Next C++ language standard, may be Orcas+1 or later.
* Multi-core: need to make languages more "functional" to ease multi-core
development. Linq is one of first attempts at doing this.
MY VIEWPOINT
The MVP Summit was a terrific experience, especially the 1.5 days we spent
in the VC++ building with many of the developers and product Managers. In
addition to Bill and Steve (both of whom had Borland roots with me), I was
pleased to chat with Ronald Laermans who is now the PUM of Visual Studio. I
got to meet David W., Mihai, Nish, Carl D., and Joe, along with Mike Dunn
(who wrote a terrific WTL tutorial on CodeProject), and a bunch of others.
The whole environment was very encouraging but forthright (we didn't hold
back both our praise and our criticisms), and I was pleased there was no
trace of ego by anyone.
Given that the headline was "MFC and native code is making a comeback" I
wondered how this would jive with my new focus on learning .NET. As many of
you know, I am still selling myself as a native C++/MFC expert but am
"quietly" learning .NET so I can further add these skills to my toolset.
Would I be persauded that MFC is still where it will be at 5 years from now?
To my surprise, I walked away with a new rededication to learning .NET.
The reason is, I am an ISV and consultant that writes small to medium sized
programs. I don't have huge legacy codebases, nor am I concerned with
multi-platform. All the innovations in my space are in the managed
environment, and have been for the past several years. I will be a great
fan of the new interop and IDE stuff going into Orcas and Orcas+1, but
mostly I think I will be better served in the Managed world, especially
since the Performance and library requirements are slowly going away. If
not now, than in the next 2 years.
But still, unmanaged/MFC remains by bread and butter for awhile longer.
-- David
http://www.dcsoft.com
Joseph M. Newcomer
technologies and see all kinds of reasons to use them. One does not preclude another.
Just because C# exists, there is no reason to move to it unless there is a valid reason to
do so (rewriting code for the sake of rewriting code serves little useful purpose). MFC
solves real-world problems, and it has a lot of value. C# solves a set of real-world
problems. Java solves a set of real-world problems. What point are you making here?
(The last I looked, by the way, 'Borland' was not a language. SQL is a query language and
is unrelated to any of the other languages, and in fact is often embedded in them. I'm
not sure why "Fortran" is quoted; why not "Java" and "C#" with quote marks also?)
joe
Daniel James
> * TR-1: Next C++ language standard, may be Orcas+1 or later.
I think there's a misunderstanding here on somebody's part. TR1 is a
library extension that can be implemented on today's C++. Microsoft could
ship that *today* if they wanted by licensing the code from their library
supplier (Dinkumware). Although TR1 is new to C++ a lot of it simply
extends C++ to cover things that are already in the ISO C99 standard.
See: http://www.dinkumware.com/tr1.aspx
If it isn't in Orcas a lot of people will be justifiably disappointed.
The next C++ language standard -- C++0x (that is, the new standard to be
presented to ISO and agreed in 200x, where we all hope x will be 9 and not
A) -- is another thing entirely. Orcas+1 is the earliest you could expect
to have that.
Cheers,
Daniel.
David Ching
news:VA.0000104...@nospam.aaisp.org...
Thanks Daniel, you know far more about C++ standards than I do. I might
have gotten it wrong from the video.
http://msdn2.microsoft.com/en-us/vstudio/aa948851.aspx has a nice feature
set of Orcas. But due to the fact all the links are in .XPS format I did
not read them.
-- David
Nobody
developed.
I don't know the market trend for MFC and whether it has risen or fallen or
stayed the same in the past 5 to 10 years.
This is the best I can come up with.
http://www.dedasys.com/articles/language_popularity.html
VCPP
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:tPCLh.4095$Qw....@newssvr29.news.prodigy.net...
| In addition to Joe's comments, much can be gleaned from the public video
|
Your main points from the video & views are very well articulated and
useful.
I am still not convinced if C#/.Net/MC++ give the flexibility, speed and
power to develop real world applications.
But MFC is always left behind in UI by MS.
I wish WPF and other new stuff is easily usable
with MFC and native code.
David Ching
news:Pf_Lh.86$u03...@newssvr21.news.prodigy.net...
>
> Your main points from the video & views are very well articulated and
> useful.
>
> I am still not convinced if C#/.Net/MC++ give the flexibility, speed and
> power to develop real world applications.
Thank you! For sure, .NET is not as flexible or as fast as native, but
depending on what you are doing, it is more powerful in that simple things
are truly simple, which leaves more time to develop more real world depth.
I think with Win9x/ME thankfully not even in the rear view mirror anymore,
Win2K being phased out, and WinXP SP2 and Vista the only OS's we have to
worry about, assuming things like the .NET Framework 3.0 being installed
won't be out of the question, so we are now entering the sweet spot for
.NET, much like Windows 3.0 (first mass deployed protected mode Windows
broke the 640 KB barrier and GP faults replaced random memory overwrites
that hung the entire PC) marked the start of the sweet spot of Windows. And
the trajectory moving forward will make this even more so. So, the time to
start switching is now (or at least start integrating some parts of the .NET
framework into existing apps using C++/CLI).
> But MFC is always left behind in UI by MS.
> I wish WPF and other new stuff is easily usable
> with MFC and native code.
>
It's not just Microsoft that is leaving MFC but 3rd parties like component
developers and sites like CodeProject. There are far more UI controls for
.NET than for MFC now.
Like them, I certainly am not emboldened to stay in native if the main focus
of C++ is to have more tools to grok millions lines of code (useless to me),
increase standard conformance (useless to me), or to perpetuate hopelessly
complex libraries like STL (useless to me). MFC is no longer meant to be
the best way to develop Windows apps that are not huge (and pre-existing).
I see no reason to stay in C++ except if you have entrenched legacy code,
and lots of it.
OTOH, native code continues to enjoy performance and predictability, a
mature framework that is a real framework (i.e. has things like
document/view and not just a RAD canvas), a much better redist story, and
better resource localization. The question is, what will it be like in 5
years? Will C# and .NET get these features, or will C++ get the features of
.NET (like properties, delegates, clean syntax, etc.) It's clear the
managed camp are getting the lion's share of resources at Microsoft and are
making the most gains. I'm betting C# and .NET will pick up its missing
pieces faster than native will.
I still plan to write lots of native code involving things like hooks. But
I can't see where MFC offers any advantage for UI's.
There is a version of WPF called WPF/E (the /E is "everywhere) which I
believe is callable from native. Not sure about this.
-- David
Tom Serface
See comments below...
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:vy2Mh.16358$bb1....@newssvr17.news.prodigy.net...
> Thank you! For sure, .NET is not as flexible or as fast as native, but
> depending on what you are doing, it is more powerful in that simple things
> are truly simple, which leaves more time to develop more real world depth.
So it improves the programmer's productivity, perhaps, but not necessarily
the programmer's program.
> I think with Win9x/ME thankfully not even in the rear view mirror anymore,
> Win2K being phased out, and WinXP SP2 and Vista the only OS's we have to
> worry about, assuming things like the .NET Framework 3.0 being installed
> won't be out of the question, so we are now entering the sweet spot for
> .NET, much like Windows 3.0 (first mass deployed protected mode Windows
> broke the 640 KB barrier and GP faults replaced random memory overwrites
> that hung the entire PC) marked the start of the sweet spot of Windows.
> And the trajectory moving forward will make this even more so. So, the
> time to start switching is now (or at least start integrating some parts
> of the .NET framework into existing apps using C++/CLI).
It does make sense to keep at least a weather eye on all of the
technologies. One thing that bugs me is that everyone I meet (even
developers) seems to equate ".NET" with "C#". The C++ group needs to do a
better job of selling C++ as a first class .NET language. However, it
sounds like they may be focusing on native again and I can't argue much with
that. Regardless of how good .NET gets, there will always be a need for
native (at least for the forseeable future). We want to use the right tool
for the job regardless.
> It's not just Microsoft that is leaving MFC but 3rd parties like component
> developers and sites like CodeProject. There are far more UI controls for
> .NET than for MFC now.
Yeah, there hasn't been much "new" coming out for MFC for free, but some of
the guys who make money at it (like Ultimate Toolbox, and Xtreme Toolkit,
etc.) are getting really good and, for the price, you get a ton of
functionality. Of course, there are also some dynamite .NET libraries. I
would imagine they are easier to write and, of course, work as assemblies
for any of the .NET syntaxes.
> Like them, I certainly am not emboldened to stay in native if the main
> focus of C++ is to have more tools to grok millions lines of code (useless
> to me), increase standard conformance (useless to me), or to perpetuate
> hopelessly complex libraries like STL (useless to me). MFC is no longer
> meant to be the best way to develop Windows apps that are not huge (and
> pre-existing). I see no reason to stay in C++ except if you have
> entrenched legacy code, and lots of it.
Agreed. Or, when I really need to focus on performance on a user's desktop
that may not be a multi-processor super computer. I'm guessing a good part
of Office 2007 and Vista are still native (although I don't know any
particulars) so I'd guess Microsoft is still in that boat as well.
> OTOH, native code continues to enjoy performance and predictability, a
> mature framework that is a real framework (i.e. has things like
> document/view and not just a RAD canvas), a much better redist story, and
> better resource localization. The question is, what will it be like in 5
> years? Will C# and .NET get these features, or will C++ get the features
> of .NET (like properties, delegates, clean syntax, etc.) It's clear the
> managed camp are getting the lion's share of resources at Microsoft and
> are making the most gains. I'm betting C# and .NET will pick up its
> missing pieces faster than native will.
Perhaps.
> I still plan to write lots of native code involving things like hooks.
> But I can't see where MFC offers any advantage for UI's.
There are a lot of people who know MFC so it does still have some momentum,
but it really needs a lot of spiffing up to stay in the running. I'm not
sure what Microsoft intends to do with it, but I don't get the impression
that much of the "spiffing" has to do with UI.
> There is a version of WPF called WPF/E (the /E is "everywhere) which I
> believe is callable from native. Not sure about this.
That would be interesting...
Daniel James
wrote:
> http://msdn2.microsoft.com/en-us/vstudio/aa948851.aspx has a nice feature
> set of Orcas. But due to the fact all the links are in .XPS format I did
> not read them.
Nor did I (what is .xps anyway, and why can't these links be to normal HTML
pages?).
Still, TR1 does not seem to be mentioned on that page and it would be a real
pity if it were NOT included it in TR1. Is there anything one can do to
register a specific request that TR1 libraries be included with the Orcas
release?
Cheers,
Daniel.
David Ching
news:OJitt23a...@TK2MSFTNGP06.phx.gbl...
> So it improves the programmer's productivity, perhaps, but not necessarily
> the programmer's program.
>
Yes, I think with a RAD based solution that uses components, it is
inevitable you give up ultimate flexibility and do it the component's way
because it's so easy, and since source code is not provided as much as it is
with MFC controls, it's harder to modify. Also, the .NET programmer works
with much higher level things like component properties and never dives into
Windows messages. There is no such thing as PreTranslateMessage() as far as
I know. ;)
> It does make sense to keep at least a weather eye on all of the
> technologies. One thing that bugs me is that everyone I meet (even
> developers) seems to equate ".NET" with "C#". The C++ group needs to do a
> better job of selling C++ as a first class .NET language. However, it
> sounds like they may be focusing on native again and I can't argue much
> with that. Regardless of how good .NET gets, there will always be a need
> for native (at least for the forseeable future). We want to use the right
> tool for the job regardless.
>
Besides being the right time to get into .NET now due to Vista essentially
replacing Win2K and what was left of Win9x/ME, it is a once in a lifetime
chance for us crufty C++ programmers to dive into .NET with the language we
love. WinForms is still a great UI platform, and C++/CLI is a first class
way to program WinForms. This won't last when Orcas comes out later this
year and causes XAML and WPF to be the focus. C++/CLI won't interop with
XAML. So start diddling with WinForms now in C++/CLI, before even this
becomes obsolete.
C++/CLI will still be a way of harnassing .NET subsystems in MFC programs,
but you wouldn't want to start a new .NET program using C++/CLI when WPF
takes hold.
> Yeah, there hasn't been much "new" coming out for MFC for free, but some
> of the guys who make money at it (like Ultimate Toolbox, and Xtreme
> Toolkit, etc.) are getting really good and, for the price, you get a ton
> of functionality.
Ultimate Toolbox is essentially dead. The last update just compiled with
VC2005. Not sure about XTreme, but basically MFC controls has become a
niche market.
> Of course, there are also some dynamite .NET libraries. I would imagine
> they are easier to write and, of course, work as assemblies for any of the
> .NET syntaxes.
>
Yes, the thing that bugs me is it is standard not to ship source code. But
the catalog of .NET components is so large, the choice is clear.
> Agreed. Or, when I really need to focus on performance on a user's desktop
> that may not be a multi-processor super computer. I'm guessing a good
> part of Office 2007 and Vista are still native (although I don't know any
> particulars) so I'd guess Microsoft is still in that boat as well.
>
I would guess the reason they are still native is not for performance
reasons. It is because they have millions of lines of source code they
aren't willing to toss.
> There are a lot of people who know MFC so it does still have some
> momentum, but it really needs a lot of spiffing up to stay in the running.
> I'm not sure what Microsoft intends to do with it, but I don't get the
> impression that much of the "spiffing" has to do with UI.
>
I don't either.
>> There is a version of WPF called WPF/E (the /E is "everywhere) which I
>> believe is callable from native. Not sure about this.
>
> That would be interesting...
This is discussed in those forums.microsoft.com/msdn thing.
-- David
David Ching
> HTML
> pages?).
>
> Still, TR1 does not seem to be mentioned on that page and it would be a
> real
> pity if it were NOT included it in TR1. Is there anything one can do to
> register a specific request that TR1 libraries be included with the Orcas
> release?
>
.xps is Microsoft's equivilent of .pdf. Apparently you need some sort of
plug-in to view these files, although Vista has it built-in. I've asked in
the MVP newsgroup about TR1 and will let you know what they say.
Thanks,
David
David Ching
> register a specific request that TR1 libraries be included with the Orcas
> release?
>
I'm not sure how definitive it is, but Orcas is pretty far along, and what's
in the CTP currently is a good indication of what will be in the final
release.
https://connect.microsoft.com/VisualStudio is where you can register
requests.
Sorry that's all I can say.
-- David
Ajay Kalra
> I know.
Nothing like that is available but you get access to the wdnproc and
do all sorts of magic there.
---
Ajay