future of the windows platform
-
Hi, I'm a working and learning developer developing my applications in a wide variation of frameworks for the windows platform, i create my servers with native C++ and a little support of the win32 api. At the office i'm currently developing with the .NET framework and i must say its a wonderfull framework, however i dont have extreme knowledge of a specific framework, i know .net quite a bit however when talking about the .net framework 3.0 i'm still new to that. I also have some skills with ATL, developed a few activeX projects with it. Now i'm a bit blury about something, i just got myself a book on MFC but i'm thinking, whats worth it learning MFC, i mean with .NET rising on the windows platform, what will be the future of techniques like MFC and ATL in the next couple of years and more importantly after that. I could ofcourse learn MFC and i will because i just find it darn interresting and fun to do, however i'm not sure if it will be still suported and widely used in the future. Do you think that its better to completely focus on the .NET framework? What is going to happen to frameworks like MFC and ATL? is it going to be used alot or is nearly every windows developer slowly moving to the .net framework? I hope you guys can give me a clear vision because i just dont know. Thanks already! - Koen
-
Hi, I'm a working and learning developer developing my applications in a wide variation of frameworks for the windows platform, i create my servers with native C++ and a little support of the win32 api. At the office i'm currently developing with the .NET framework and i must say its a wonderfull framework, however i dont have extreme knowledge of a specific framework, i know .net quite a bit however when talking about the .net framework 3.0 i'm still new to that. I also have some skills with ATL, developed a few activeX projects with it. Now i'm a bit blury about something, i just got myself a book on MFC but i'm thinking, whats worth it learning MFC, i mean with .NET rising on the windows platform, what will be the future of techniques like MFC and ATL in the next couple of years and more importantly after that. I could ofcourse learn MFC and i will because i just find it darn interresting and fun to do, however i'm not sure if it will be still suported and widely used in the future. Do you think that its better to completely focus on the .NET framework? What is going to happen to frameworks like MFC and ATL? is it going to be used alot or is nearly every windows developer slowly moving to the .net framework? I hope you guys can give me a clear vision because i just dont know. Thanks already! - Koen
-
thats nice but i was asking for the future of the windows framework's on the windows platform.
Sorry I should have read your post rather than respond to the subject :-D I think Microsoft wants to migrate away from the Win32 API set that is why I brought up ReactOS. They obviously could not do that with the first round of Vista and had to decouple Framework 3.0 from the base OS. Eventually, I think, that Microsoft want the CLR to become the "kernel" and that application programmers code to the BCL. The problem is that Win32 has been around for over 20 years and that is a huge knowledge base that is being "threaten" by Microsoft's business model of upgrade cycles. Preserving Win32 is going to be highly desirable among system programmers who knows every trick in the Win32 book. This is going to be troublesome for Microsoft. Another thing is "bang for the buck". I saw a trend away from the constant upgrade cycle among many business during the dot-com bust of the early 2000's. They are not as willing to upgrade for the sake of Microsoft but must have business reasons. Microsoft may force the issue via lapsing support for XP and 2K. For example DirectX 10 does not run on XP. So it depend on they type of programmer that you are the type of apps you have to support, Going back to the previous example, if you are a gamer then you'll have to upgrade to Vista in order to get DirectX 10. If you are a system programmer then you'll have to go to Vista in order to stay ahead but you have to wonder how long will it be before Microsoft retire Win32. If you are an application programmer then you'll be better off learning the .NET Framework but as we are seeing if you are a Windows.Forms guru well that out the window and you should be learning the Windows Presentation Framework. Once again bringing up ReactOS. Unfortunately it is immature at this point but they are making great progress. Mono runs on ReactOS -- just to mention frameworks. Right now Win32 is save but as time goes on and as ReactOS moves toward beta (currently still in alpha) by early 2008, I think you'll see a great deal of interest in this platform by Win32 programmers who will want to preserve their knowledge base and have source that they can improve or wire in features as Microsoft alters the playing field. I hope this response better answers your question. Thanks
-
Sorry I should have read your post rather than respond to the subject :-D I think Microsoft wants to migrate away from the Win32 API set that is why I brought up ReactOS. They obviously could not do that with the first round of Vista and had to decouple Framework 3.0 from the base OS. Eventually, I think, that Microsoft want the CLR to become the "kernel" and that application programmers code to the BCL. The problem is that Win32 has been around for over 20 years and that is a huge knowledge base that is being "threaten" by Microsoft's business model of upgrade cycles. Preserving Win32 is going to be highly desirable among system programmers who knows every trick in the Win32 book. This is going to be troublesome for Microsoft. Another thing is "bang for the buck". I saw a trend away from the constant upgrade cycle among many business during the dot-com bust of the early 2000's. They are not as willing to upgrade for the sake of Microsoft but must have business reasons. Microsoft may force the issue via lapsing support for XP and 2K. For example DirectX 10 does not run on XP. So it depend on they type of programmer that you are the type of apps you have to support, Going back to the previous example, if you are a gamer then you'll have to upgrade to Vista in order to get DirectX 10. If you are a system programmer then you'll have to go to Vista in order to stay ahead but you have to wonder how long will it be before Microsoft retire Win32. If you are an application programmer then you'll be better off learning the .NET Framework but as we are seeing if you are a Windows.Forms guru well that out the window and you should be learning the Windows Presentation Framework. Once again bringing up ReactOS. Unfortunately it is immature at this point but they are making great progress. Mono runs on ReactOS -- just to mention frameworks. Right now Win32 is save but as time goes on and as ReactOS moves toward beta (currently still in alpha) by early 2008, I think you'll see a great deal of interest in this platform by Win32 programmers who will want to preserve their knowledge base and have source that they can improve or wire in features as Microsoft alters the playing field. I hope this response better answers your question. Thanks
-
I was a lead on the .NET Framework CLR Interoperability team and the intended migration path was to see COM retired. The purpose of Interoperability was to help COM developers to migrate to the .NET Framework. In fact Don Box referred to Adam Nathan's book on COM as the "last book on COM". So the intended direction of .NET is to see the retirement of COM as well as the retirement of Win32. However IMO I think the real problems attended to COM is really OLE Automation. OLE Automation really increased COM footprint making it really hard to learn as well as the process models (Apartment and Free threaded). However COM itself I think is easy so long as you write small and tight COM objects off of IUnknown and support IClassFactory. The registry however is a pain in the ass to work with. However you can instantiate COM objects without the registry. The point is that in .NET with reflection being first class a lot of the complexity of OLE Automation is simplified making it extremely easy to construct component. The .NET programming model is light years easier than COM programming and very much embraced by application developers. What really sold OLE Automation was VB and the tools that Microsoft supplied to hide all the COM complexity. .NET is just a much nicer and easier model. I am currently working for a firm that has a lot of COM object that I wrote a .NET interoperability layer for. Fortunately their COM objects was simple object written off of IUnknown. The layer is written using C++/CLI and object are instantiated without using the registry. IMO there will always be a need to write low level system code in C++ but the way I see the trend is that it may not make sense to write that as a COM component but as rather as DLL's and supply a PInvoke wrapper to make the DLL accessible in .NET. Again going back to the real heart of your question, if I am new programmer and had to choose where to spend my time reading I would spend it on .NET programming first and learn as much as I can about C#. It just so much easier to get up to speed. Next I would learn C++/CLI to migrate your C# knowledge to C++. Next I would spend time learning system programming and understanding Win32 system APIs. Next learn something about multiprocessing: threading, IO ports and devices. Finally then learn something about COM but not too deep. Learn the basics IUnknown, IDispatch, IClassFactory and some understanding of OLE Automation. Once again this is why I think Microsoft is opening an opportunity for React
-
I was a lead on the .NET Framework CLR Interoperability team and the intended migration path was to see COM retired. The purpose of Interoperability was to help COM developers to migrate to the .NET Framework. In fact Don Box referred to Adam Nathan's book on COM as the "last book on COM". So the intended direction of .NET is to see the retirement of COM as well as the retirement of Win32. However IMO I think the real problems attended to COM is really OLE Automation. OLE Automation really increased COM footprint making it really hard to learn as well as the process models (Apartment and Free threaded). However COM itself I think is easy so long as you write small and tight COM objects off of IUnknown and support IClassFactory. The registry however is a pain in the ass to work with. However you can instantiate COM objects without the registry. The point is that in .NET with reflection being first class a lot of the complexity of OLE Automation is simplified making it extremely easy to construct component. The .NET programming model is light years easier than COM programming and very much embraced by application developers. What really sold OLE Automation was VB and the tools that Microsoft supplied to hide all the COM complexity. .NET is just a much nicer and easier model. I am currently working for a firm that has a lot of COM object that I wrote a .NET interoperability layer for. Fortunately their COM objects was simple object written off of IUnknown. The layer is written using C++/CLI and object are instantiated without using the registry. IMO there will always be a need to write low level system code in C++ but the way I see the trend is that it may not make sense to write that as a COM component but as rather as DLL's and supply a PInvoke wrapper to make the DLL accessible in .NET. Again going back to the real heart of your question, if I am new programmer and had to choose where to spend my time reading I would spend it on .NET programming first and learn as much as I can about C#. It just so much easier to get up to speed. Next I would learn C++/CLI to migrate your C# knowledge to C++. Next I would spend time learning system programming and understanding Win32 system APIs. Next learn something about multiprocessing: threading, IO ports and devices. Finally then learn something about COM but not too deep. Learn the basics IUnknown, IDispatch, IClassFactory and some understanding of OLE Automation. Once again this is why I think Microsoft is opening an opportunity for React
Ah i see, nice answer. I started developing in Delphi however i didnt feel anything for the syntax so after i controlled delphi reasonable, i switched to C++. Spended 3 years learning C++ and after that C++/CLI. Made some applications with C++/CLI and i already saw myself continuously moving to the .NET framework. After that i got a job developing with C# and i was amazed over the language and its power and clean code. But i still couldn't say goodbye to C++ and i'm sure i wont. In my latest application which is a server application doing loads of processing continiously, i choose C++ as my library language, C++/CLI as the bridge between the unmanaged and managed code and C# for the interface. The reason for this question is that i also have to develop a client application which is going to be an activeX plugin. However, looking at the posibilities, i saw that there was no way developing an ActiveX plugin with C# without switching back to old Win32 and COM so i learned ATL, just for fun. Strangely i loved the complexity because ATL dives very deep in the power of C++. Then i came to a small decision problem. The interface for the client have to be very complex and both MFC and .NET have it in them. .NET is the logical chose because i already know alot of it and its easy to use and extend, however because the rest is using ATL i can use MFC to keep the dependencies as low as possible. I'm still not sure which one to take. The plugin needs to be small. .NET creates small executables however i cant make sure that the user have installed the .NET framework and that is a really huge disadvantage. ( I aim for gamers as users so expect some heavy machines with new software ) So i'd like to ask 2 more question First: What do you recommend from the story above: .NET or MFC? Second: What about DirectX? ;) just a small mind bothering Thanks in advance! -Koen
-
Ah i see, nice answer. I started developing in Delphi however i didnt feel anything for the syntax so after i controlled delphi reasonable, i switched to C++. Spended 3 years learning C++ and after that C++/CLI. Made some applications with C++/CLI and i already saw myself continuously moving to the .NET framework. After that i got a job developing with C# and i was amazed over the language and its power and clean code. But i still couldn't say goodbye to C++ and i'm sure i wont. In my latest application which is a server application doing loads of processing continiously, i choose C++ as my library language, C++/CLI as the bridge between the unmanaged and managed code and C# for the interface. The reason for this question is that i also have to develop a client application which is going to be an activeX plugin. However, looking at the posibilities, i saw that there was no way developing an ActiveX plugin with C# without switching back to old Win32 and COM so i learned ATL, just for fun. Strangely i loved the complexity because ATL dives very deep in the power of C++. Then i came to a small decision problem. The interface for the client have to be very complex and both MFC and .NET have it in them. .NET is the logical chose because i already know alot of it and its easy to use and extend, however because the rest is using ATL i can use MFC to keep the dependencies as low as possible. I'm still not sure which one to take. The plugin needs to be small. .NET creates small executables however i cant make sure that the user have installed the .NET framework and that is a really huge disadvantage. ( I aim for gamers as users so expect some heavy machines with new software ) So i'd like to ask 2 more question First: What do you recommend from the story above: .NET or MFC? Second: What about DirectX? ;) just a small mind bothering Thanks in advance! -Koen
Polity, Here's my recommendation based on your last message. I think you are doing the correct thing by writing low level libraries in C++ and then use C++/CLI as the bridge between managed and unmanaged code. That was exactly the approach I took with my project. However I would not worry about supporting MFC unless there is an absolute business reason. The reason I'm saying this is because if you are going to support .NET then I would use Windows.Forms to supply the user interface. If you are to going to be running mulit-platform then Windows.Forms is supported by Mono. If your application is going to run on Vista you can also write to Windows Presentation Layer. My general point here is that why support MFC and all of its overhead when you are willing to accept the overhead of .NET. In fact WTL is much lighter than MFC anyway. Just another case in point was that Mike Blazack (sp?) the lead developer of MFC was extremely skeptical of .NET Windows Forms initially. I was meetings where he voiced his skepticism. However after a while he began to embrace MFC. I was also a member of the original AFX team that wrote MFC. I liked MFC 1.0 but hated every incarnation of MFC after 1.0 when in 2.0 they added the OLE Doc/View support. The whole Doc/View stuff in MFC was poorly designed and intrusive. A former dev started his own open source initiative (now defunct) that I participated in of a window wrapper that was much light weight than MFC. I would mothball MFC. If you need to do UI in C++ I greatly suggest WTL. If you want a very good open source C++ UI then I'd suggest FoxToolkit, WXWidgets, and I think Qt even has one that is open source for Windows now. Another point if you go .NET. If you write an installer for your application you can include the .NET redistributable in your installer. Microsoft allow you to redistribute the .NET runtime library files so you can install the .NET runtime and write to .NET without having to worry whether or not the client has .NET. >>First: What do you recommend from the story above: .NET or MFC? I guess I already answered that question. >>Second: What about DirectX? just a small mind bothering There are .NET wrappers for DirectX. I haven't written a DirectX app in years however I did write a small DirectX application from C# PRIOR TO the release of the DirectX wrappers. You can do that because DirectX is supported by COM. There is a sample in Adam Nathan's .NET Interoperability book. I think there were some tweaks needed in the IL to m