New Windows and MFC
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
I'd have thought that Microsoft would be really shooting themselves in the foot if they didn't include some kind of backwards compatibility layer for Win32 based code. After all, Win2k (not sure about XP) can still run 16 bit win3.1 and OS/2 applications (thanks to it's NT heritage) -- Help me! I'm turning into a grapefruit! Buzzwords!
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Last time I looked at the Longhorn SDK - back in Alpha build 4074 - the Win32 API was still present. Indeed, it was being enhanced. I don't have any reason to believe that this will be different for Windows Vista Beta 1. I started writing a series[^] this time last year, but stopped - partly due to laziness but eventually because MS effectively restarted the Longhorn development. I might return to this now that Beta 1 is out. Stability. What an interesting concept. -- Chris Maunder
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Have a look at this. Clearest overview I’ve seen. The diagrams are especially good… http://www.windowsdevcenter.com/pub/a/windows/2004/07/13/winfx.html[^] Kevin
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
http://msdn.microsoft.com/visualc/whidbey/mfc2005/default.aspx[^] Pavel Sonork 100.15206
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Considering that MFC is based upon the Win32 API and the fact that Microsoft Office is still (and will be for the foreseeable future) a Win32 API based app, then I'm quiet sure that all our legacy C++/MFC code will run on Windows Vista. :-D Whether or not we get MFC wrappers to the new Avalon user interface components is debatable and probably doubtful. (Given that the VS 2005 MFC seems to be still using the standard Common Controls for toolbars yet the C#/.NET gets the new Toolstrip with the newer look) Backwards compatibility has always been Microsoft strength and one of the reasons why most developers haven't converted their apps to run on Linux or Apple platforms. Michael CP Blog [^] Development Blog [^]
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Avalon (the new gui) etc is built on top of win32, even though its .NET. For C++/MFC gyus, its business as usual. I do use .NET with C#, but as good as it is, I'm still going to be using C++ and MFC, and its seems MS have every intention of continuing with it as well.
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]
-
With all this talk about the new Windows I was wondering how this will affect old code and also new code going forward. Are the changes so significant that the apps we write now in MFC will not work on the new Windows? Will we have to learn all new libraries for windows programing?
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
I wouldn't worry. MFC is likely to be supported for a long time. In fact, I wouldn't be at all surprised if Visual Studio Orcas (the successor to Whidbey/VS2005) added XAML support to MFC. :cool: Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]
Thanks Nish that was very informative. Im glad to see that not everyone is just moving over to the .NET platform.
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
-
Avalon (the new gui) etc is built on top of win32, even though its .NET. For C++/MFC gyus, its business as usual. I do use .NET with C#, but as good as it is, I'm still going to be using C++ and MFC, and its seems MS have every intention of continuing with it as well.
Avalon (the new gui) etc is built on top of win32 Actually, it's built on top of DirectX more than anything. There are no Win32 common controls under the hood, as it is with Windows Forms. Avalon controls are managed code and do not have their own HWNDs (with the exception of context menus and drop down lists, which need their own HWND since they can be drawn outside the containing window).
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango
-
Thanks Nish that was very informative. Im glad to see that not everyone is just moving over to the .NET platform.
There are 10 kinds of people in this world. Those who understand binary and those who don't. We shouldn't assume something's debugged just because everyone in the whole world has access to the source code.
The 2 million plus lines of code in our product is not going to migrate all in one day ... :rolleyes:
-
I'd have thought that Microsoft would be really shooting themselves in the foot if they didn't include some kind of backwards compatibility layer for Win32 based code. After all, Win2k (not sure about XP) can still run 16 bit win3.1 and OS/2 applications (thanks to it's NT heritage) -- Help me! I'm turning into a grapefruit! Buzzwords!
I just ran a program last night on my XP machine that was coded for Windows v3.0. The date on the CD was 1992.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-
Funny! I just blogged on this today! Is MFC dead? Does MFC have a future?[^]
Will MFC *really* support Avalon? I can barely believe that! Joel Holdsworth
-
Avalon (the new gui) etc is built on top of win32 Actually, it's built on top of DirectX more than anything. There are no Win32 common controls under the hood, as it is with Windows Forms. Avalon controls are managed code and do not have their own HWNDs (with the exception of context menus and drop down lists, which need their own HWND since they can be drawn outside the containing window).
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango
But if DirectX is built on COM, then in a way, its still the Windows (win32) subsystem and everything that comes with that as COM is built on top of Win32. What I'm saying is its not built on a subsystem that directly interfaces with the NT subsystem, like the Win32 and Posix subsystems are.
-
Avalon (the new gui) etc is built on top of win32 Actually, it's built on top of DirectX more than anything. There are no Win32 common controls under the hood, as it is with Windows Forms. Avalon controls are managed code and do not have their own HWNDs (with the exception of context menus and drop down lists, which need their own HWND since they can be drawn outside the containing window).
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango
Win32 is not just the common controls, it's the entire 32 bit API. DirectX is a part of Win32, so yes, Avalon is built on top of Win32. Chris Richardson
-
But if DirectX is built on COM, then in a way, its still the Windows (win32) subsystem and everything that comes with that as COM is built on top of Win32. What I'm saying is its not built on a subsystem that directly interfaces with the NT subsystem, like the Win32 and Posix subsystems are.
You're right that WinFX is not a subsystem like Win32 or Posix. However, WinFX can make direct system calls, eliminating the middleman API (Win32). See this article[^] by Ian Griffiths for more information. Borrowing a snippet from that, Because WinFX will be a part of the OS, it will be able to have a much closer relationship with the low-level system services. In theory, WinFX could act as a peer of Win32 rather than having to be its client; it could effectively be a distinct subsystem. In practice, that's unlikely to happen any time soon for two reasons. First, where Win32 already provides the necessary services, there seems little point in WinFX reinventing the wheel. So expect those parts of the .NET Framework that are wrappers around Win32 (such as Windows Forms) to remain so for the foreseeable future. The second reason for not making WinFX an entirely independent subsystem is that P/Invoke would be tricky to implement if Win32 wasn't still there somewhere. Nevertheless, although we are likely to carry on seeing wrappers where Win32 already provides appropriate services, there's no reason for new services to be exposed at the Win32 level and then wrapped by WinFX. For platform services that are new to Longhorn, their only public API will be in WinFX. There may be corresponding undocumented system calls used by WinFX (just as there are today for many Win32 APIs) but there is no reason for there to be an equivalent new public Win32 API; Longhorn can cut out the middle man and have WinFX make system calls directly.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango
-
Win32 is not just the common controls, it's the entire 32 bit API. DirectX is a part of Win32, so yes, Avalon is built on top of Win32. Chris Richardson
Right, but the parent poster was talking about Avalon, in which he claimed was built on Win32, which isn't entirely correct. See my reply to Giles in this same thread for more info.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Homosexuality in Christianity Judah Himango
-
I'd have thought that Microsoft would be really shooting themselves in the foot if they didn't include some kind of backwards compatibility layer for Win32 based code. After all, Win2k (not sure about XP) can still run 16 bit win3.1 and OS/2 applications (thanks to it's NT heritage) -- Help me! I'm turning into a grapefruit! Buzzwords!
-
Carl Mercier wrote: OS/2 Bite your tongue. While you're at it, bite every part of your body within reach of your mouth. Chew hard. OS/2. Blleeecchhh. X| X| X| X|
Software Zen:
delete this;