MFC under VS2010
in [MFC]
|
Prev: MDI App: start 2 DocTemplates in CMyApp::InitInstance
Next: How To: CStatubar panel Right-align text
From: Hector Santos on 29 Mar 2010 17:24 David Ching wrote: >> One of the reasons I didn't want to commit to VS20xx compile based >> product packaging and distribution was based of new OS and different flavors >> of OS> SxS and manifest stuff. >> > > They took out the manifest stuff (at least relating to CRT redists) so > it is > now like VS6 in that regard. The CRT/MFC/ATL redists aren't manifested > anymore, there is no SxS installation of these anymore. So it is back to > DLL hell, for these. But just sticking them into your .exe folder works > without any additional work now. Great! >> The beauty of having a product under VC6 was that it was design purely >> for WIN32 and never had to worry about the version of windows users had. >> That seem to change now. > What do you mean? Even VS 6 you still had to set _WIN32_IE, _WINVER, etc. > correctly. This is still the case. Yes, I always keep that to a minimum to maximize WIN32 across all Windows OS from 95-based OSEs to NT based OSes. Only in rare exceptions, like IPHLPAPI.DLL for our SMTP Server for the changss made to DNS server discovery lookup starting with 2000, do we have a specific dependency. Maybe a few others, but overall pure WIN32 and no advanced IE controls, etc. > In addition, WPF is a superset of Silverlight.... That is all I needed to know about WPF for now. I get the picture now. :) Thank you! -- HLS
From: Hector Santos on 29 Mar 2010 17:36 Ajay Kalra wrote: > On Mar 29, 4:45 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: >> OK, so the bottom line, VS2010 does not add .NET dependency to "pure" >> MFC applications. > > That has been the case since day one. Regardless of what VS you use, > MFC app by default will not have any .Net dependency. Right, but as I had eluded, as a business strategy that will change, IMO. MS has been slowing changing the WIN32 compatibility long term process, understandably so. As we move along, the required components for centralization will be common once again, hence, these sub-systems dependencies can be leverage, even possible for MFC. WPF amd WP7 is the first time where a new platform of development will be totally managed under a specific set of GUI development tools and sub-system. .NET will be the next "long term promise" as more and more devices include the newer OSes with .NET as natural part of it. I didn't knew exactly what WPF was. David telling me its based on SilverLight totally gives me the picture. What I was asking was whether VS2010 at some level has finally reached that point where developing for MFC or recompiling an existing MFC under VS2010 begins to introduced some of these dependencies. I think we need to see what happens in July when XP and 2000 is no longer supported and all the remaining OSes has the new sub-systems. -- HLS
From: Ajay Kalra on 29 Mar 2010 18:37 On Mar 29, 5:36 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > > That has been the case since day one. Regardless of what VS you use, > > MFC app by default will not have any .Net dependency. > > Right, but as I had eluded, as a business strategy that will change, > IMO. That will be foolhardy. MFC is what it is. Thats what differentiates it from .Net: no dependency on .Net. If MFC starts to depend upon .Net, it will be the end of MFC. There will be absolutely no reason to use MFC. > WPF amd WP7 is the first time where a new platform of development will > be totally managed under a specific set of GUI development tools and > sub-system. .NET will be the next "long term promise" as more and > more devices include the newer OSes with .NET as natural part of it. > I didn't knew exactly what WPF was. David telling me its based on > SilverLight totally gives me the picture. ..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). -- Ajay
From: David Ching on 29 Mar 2010 19:24 "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
From: Hector Santos on 29 Mar 2010 20:09
Thanks David. :) David Ching 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 > > -- HLS |