MFC under VS2010
in [MFC]
|
Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: Ajay Kalra on 29 Mar 2010 20:24 On Mar 29, 7:24 pm, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: > "Ajay Kalra" <ajayka...(a)yahoo.com> wrote in message > > The point is, if native development is the only trick in your bag, you are > not going to be well positioned to develop Windows in the future. MS is > slowly making essential capabilities managed-only. I have forgotten what native development is. It seems odd but I hope I dont ever have to do that for GUI development. For server side work, unmanaged is OK. -- Ajay > > -- David
From: Joseph M. Newcomer on 29 Mar 2010 22:59 One of the things Microsoft discovered is that native code is NOT going to go away. That's why we are getting enhanced support in new versions of MFC, constantly improved native mode compiler, etc. So they have realized that the managed world is NOT going to supplant native code for a lot of applications. And nobody has mentioned "managed C++". joe On Mon, 29 Mar 2010 16:24:48 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Ajay Kalra" <ajaykalra(a)yahoo.com> wrote in message >news:ea82573e-1729-4c91-86f6-0ac1260ecdd8(a)g17g2000vba.googlegroups.com... >> .Net has been in this position for a long time. WinForms was pure .Net >> as well. Nothing new has happened here. Most of the resources from >> MSFT will naturally go into the newer technologies. MFC is dated(and >> there is nothing wrong in it). >> > >The point I believe Hector is making is that Windows desktop has always >allowed both native and .NET apps to co-exist, but the newer Windows >platforms such as cross-platform browser and Windows Phone, which both use >Silverlight, only allow managed development. And it's not inconceivable >that future Windows desktop will allow only managed apps as well, with >native apps being run in a VM or other legacy hosting container. > >The point is, if native development is the only trick in your bag, you are >not going to be well positioned to develop Windows in the future. MS is >slowly making essential capabilities managed-only. > >-- David > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Giovanni Dicanio on 30 Mar 2010 05:45 "Joseph M. Newcomer" <newcomer(a)flounder.com> ha scritto nel messaggio news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd(a)4ax.com... > One of the things Microsoft discovered is that native code is NOT going to > go away. That's true. When you have a big code base of native C++ code, it makes more sense to maintain and evolve it, than migrating to .NET. Moreover, C++ has a big advantage of being multiplatform and there is a rich ecosystem of open-source C++ libraries available. And there are things that are better done in C++ than in C#. For example: shell extensions (which are COM based). And even if last version of .NET (.NET 4) seems to allow side-by-side loading of different CLRs in the same process, it seems to me inefficient to inject the .NET runtime in a process (probably adding +20MB per process) to write a shell extension in managed code. >That's > why we are getting enhanced support in new versions of MFC, As already written, if you have an existing C++/MFC app working, it can be wiser to maintain it and evolve it, than rewriting from scratch in WPF. But, if you want to start a new app project today, what would you use? MFC or WPF? (Or probably just HTML/CSS/JavaScript...? Or maybe Adobe AIR?) Hard question! Microsoft kind of gave an answer: in 1998 VS6 (great) IDE was built using MFC. I recall a tip-of-the-day that read something like this: "We used it before you: VC6 is written in MFC". In 2010, VS2010 IDE is written in WPF. And, as David pointed out, new mobile devices (which should represent a growing market) use managed GUI technologies like Silverlight. > constantly improved native > mode compiler, etc. Yes, both the C++ compiler and the libraries have been being improved since VC6. > And nobody has mentioned "managed C++". I think "Managed C++" is deprecated (it was since VS2005, IIRC). With VS2005 they introduced C++/CLI. However, I think that it is good only to build bridges between native code and managed code, e.g. to wrap some native code libraries and expose them to C#. Giovanni
From: David Ching on 30 Mar 2010 07:37 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:f5q2r5hrd0sj3sv0j59lla2lf4jkpg0qmd(a)4ax.com... > One of the things Microsoft discovered is that native code is NOT going to > go away. That's > why we are getting enhanced support in new versions of MFC, constantly > improved native > mode compiler, etc. So they have realized that the managed world is NOT > going to supplant > native code for a lot of applications. > > And nobody has mentioned "managed C++". > joe > Did I say native code was going away? Clearly, it's not. What I said is: "if native development is the only trick in your bag, you are not going to be well positioned to develop Windows in the future." Clearly, that is true as well. For the past three years, it's been very difficult for me to find Win32/MFC jobs here in the Bay Area. Mostly all the job ads for Windows client want at least some .NET experience, and most of them are interested ONLY in .NET. C++ is still used for cross platform or embedded, but then we are not talking about Windows. And it's not just me. I have former colleagues who have been programming MFC (and MFC only) for the last decade who are now having difficulty being attractive in the job market. Conversely, from the hiring side, one of my current gigs is at an extremely large and well known global nework company. They hired me as a C# engineer and even though I suggested writing their app in C++, they expressly did not want that for fear they would not be able to hire capable people to maintain it, as "MFC programmers are dying out." So it's a cycle that spells the doom of MFC. It's funny that the lip service MS pays to MFC with "enhanced support in new versions of MFC" is not improving the job market at all. Well, duh. I look back at our debates on what is the proper prefix of user defined windows messages - UWM_, WM_, or whatever. Then I think, how quaint it is to be using Windows messages as a communication mechanism in the first place! Qt's signals and slots, and .NET delegates are so simple and powerful in comparison. -- David
From: Ajay Kalra on 30 Mar 2010 09:13
On Mar 30, 7:37 am, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: > For the past three years, it's been very difficult for me to find Win32/MFC > jobs here in the Bay Area. Mostly all the job ads for Windows client want > at least some .NET experience, and most of them are interested ONLY in .NET. > C++ is still used for cross platform or embedded, but then we are not > talking about Windows. And it's not just me. I have former colleagues who > have been programming MFC (and MFC only) for the last decade who are now > having difficulty being attractive in the job market. This has been my experience as well. When we hire for GUI, we only look for .Net. (C++ isnt even looked at). I havent seen a MFC job opening in years.It has been nothing but .Net for a long while. -- Ajay |