Don't kill MFC
-
Hi.. Sure there is many isues about MFC that don't make it perfect. But MFC is nice and easy to work with, and most important its what we have used for may years. So if I was to use some new kind of classes it had to support the old MFC. I can't just start to rewrite 10 years of prjects or stop to maintain them, becaurse something new and probably better comes along. Just my thought ;) John Achfeld
-
Hi.. Sure there is many isues about MFC that don't make it perfect. But MFC is nice and easy to work with, and most important its what we have used for may years. So if I was to use some new kind of classes it had to support the old MFC. I can't just start to rewrite 10 years of prjects or stop to maintain them, becaurse something new and probably better comes along. Just my thought ;) John Achfeld
Hi John, The VS.Net guys have gone to great lengths to allow you to intermix .Net functionality into your existing code. I'm not here to make a Microsoft advertisement, but I can assure you that this issue is top-of-mind with them. The intermixing works both ways too, you can write a C# app that allows you to call into your existing code, and your existing code can call new .Net code seamlessly. Without question there will be some issues involved with this, but from what I've seen and used so far, it seems to work very well. Listen, I don't think anyone on CodeProject has more of a vested interest in keeping MFC alive and well than I do, but as we've discussed in the lounge a few times taking MFC to the next level is way more difficult than it should be (COM, binary reuse, etc). Microsoft for all intents and purposes has developed an OO operating system in .Net, as they've been planning to for years. The OO-OS (if you will) greatly simplifies the implementation of an OO language to sit on top of it.
-
Hi.. Sure there is many isues about MFC that don't make it perfect. But MFC is nice and easy to work with, and most important its what we have used for may years. So if I was to use some new kind of classes it had to support the old MFC. I can't just start to rewrite 10 years of prjects or stop to maintain them, becaurse something new and probably better comes along. Just my thought ;) John Achfeld
-
I certainly don't think MFC will be killed overnight. Depending on how well VS .Net performs and meets developers requirements and I really think MFC will be around for a long time yet (finger X'ed). Norm
The .NET Platform and Frameworks take the API to another level. It is what the majority of Windows developer should and will use. There will be new tools, languages, libraries, books, magazines, and all the other supporting activities necessary to make it a very productive and exciting environment to program in. Must more than we've disclosed so far. I'm here to tell you that alongside the .NET Platform, Microsoft will be actively and aggressively developing an unmanaged operating system API and platform including C++ class libraries exposing the underlying operating system to you for a long time to come. This includes MFC, ATL, ATL Server, DirectX, Kernel, User, GDI, Comctl, and all the other API you've come to know and love. We have a lot of new tools, API, etc, in store for the unmanaged developer as well. You should learn about and try out the .NET stuff, you'll find that it can do much of what you want very easily. The existing stuff only gets better from here as well. Walter Sullivan Lead Program Manager, ATL/MFC
-
The .NET Platform and Frameworks take the API to another level. It is what the majority of Windows developer should and will use. There will be new tools, languages, libraries, books, magazines, and all the other supporting activities necessary to make it a very productive and exciting environment to program in. Must more than we've disclosed so far. I'm here to tell you that alongside the .NET Platform, Microsoft will be actively and aggressively developing an unmanaged operating system API and platform including C++ class libraries exposing the underlying operating system to you for a long time to come. This includes MFC, ATL, ATL Server, DirectX, Kernel, User, GDI, Comctl, and all the other API you've come to know and love. We have a lot of new tools, API, etc, in store for the unmanaged developer as well. You should learn about and try out the .NET stuff, you'll find that it can do much of what you want very easily. The existing stuff only gets better from here as well. Walter Sullivan Lead Program Manager, ATL/MFC
Hey Walter, I have a question. Is WTL doing to become officially supported ? Is it going to continue growing ? Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
-
Hey Walter, I have a question. Is WTL doing to become officially supported ? Is it going to continue growing ? Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
I'm not Walter, but I did read this quote in an interview with some MS managers: "WTL is code that was released unsupported and we have no intention of updating it. We have no intention of continuing its availability. Frankly, it should never have been released and it will be removed from the platform SDK at the time of the next SDK revision" -- Tony Goodhew http://windows.oreilly.com/news/visualc\_0500.html
-
Hey Walter, I have a question. Is WTL doing to become officially supported ? Is it going to continue growing ? Christian The content of this post is not necessarily the opinion of my yadda yadda yadda. To understand recursion, we must first understand recursion.
Right now the plan for WTL is to leave it in the Platform SDK. Bugs, features and other maintenance on WTL is officially not supported. However, in reality, it will be enhanced a bit and serious bugs will be fixed. It will not be part of Visual Studio.NET. However, for releases beyond Visual Studio.NET we will be listening to the feedback of our users and could incorporate it into a future release. Thanks for your question, Walter Sullivan Lead Program Manager, ATL/MFC
-
I'm not Walter, but I did read this quote in an interview with some MS managers: "WTL is code that was released unsupported and we have no intention of updating it. We have no intention of continuing its availability. Frankly, it should never have been released and it will be removed from the platform SDK at the time of the next SDK revision" -- Tony Goodhew http://windows.oreilly.com/news/visualc\_0500.html
See my other post in this thread. Tony's quote was a little aggresive. It won't be removed from the SDK and may in fact be incorporated into future VC releases. When had WTL as a working concept of things we could do to ATL. It turned out rather well but unfortunately we couldn't properly incorporate it into VC. We had commited to ATL Server, the C++ Attributes stuff, updates to MFC and frankly we just didn't have enough people on my team to "productize" WTL as well. Its the kind of decision we, and many of you, have to make every day about your product. It was good enough that I felt releasing it in the SDK "as-is" would provide a lot of value to Windows C++ Developers. I knew there was going to be a lot of flack about lack of documentation, Wizards, and other "official" support but decided that even lacking that many would find it very useful. It was an experiment, releasing unsupported code. So I have to say that for those folks who think MS shouldn't have released it if we weren't going to "support" it, don't use it. For those who find it useful and are getting work done with WTL, I hope you are glad we put it in the SDK. And for those who wish MS would fully incorporate it into Visual C++, thanks! We appreciate the feedback, we'll strongly consider that in our future product plans, and I apologize that I couldn't deliver it in VS.NET. Later, Walter Sullivan Lead Program Manager, ATL/MFC
-
See my other post in this thread. Tony's quote was a little aggresive. It won't be removed from the SDK and may in fact be incorporated into future VC releases. When had WTL as a working concept of things we could do to ATL. It turned out rather well but unfortunately we couldn't properly incorporate it into VC. We had commited to ATL Server, the C++ Attributes stuff, updates to MFC and frankly we just didn't have enough people on my team to "productize" WTL as well. Its the kind of decision we, and many of you, have to make every day about your product. It was good enough that I felt releasing it in the SDK "as-is" would provide a lot of value to Windows C++ Developers. I knew there was going to be a lot of flack about lack of documentation, Wizards, and other "official" support but decided that even lacking that many would find it very useful. It was an experiment, releasing unsupported code. So I have to say that for those folks who think MS shouldn't have released it if we weren't going to "support" it, don't use it. For those who find it useful and are getting work done with WTL, I hope you are glad we put it in the SDK. And for those who wish MS would fully incorporate it into Visual C++, thanks! We appreciate the feedback, we'll strongly consider that in our future product plans, and I apologize that I couldn't deliver it in VS.NET. Later, Walter Sullivan Lead Program Manager, ATL/MFC
I for one is happy you put it in the SDK. WTL greatly helped me learn how to write leaner client code, and provided a set of classes that greatly simplifies the serverside coding as well. The insight in what templates can do for code reuse that I've learned from ATL/WTL has been invaluable to me. Opinions expressed do not neccecarily reflect those of my employer; I do think for myself. Resisting temptation is easier when you think you'll maybe get another chance later on.
-
I for one is happy you put it in the SDK. WTL greatly helped me learn how to write leaner client code, and provided a set of classes that greatly simplifies the serverside coding as well. The insight in what templates can do for code reuse that I've learned from ATL/WTL has been invaluable to me. Opinions expressed do not neccecarily reflect those of my employer; I do think for myself. Resisting temptation is easier when you think you'll maybe get another chance later on.
My experience with templates has been "The less the better"! Not only are they complex and obscure the solution in many cases, but they are difficult to develop, and unless you are a library provider, they rarely solve enough problems to warrent their usage. That said....I'm a bit worried about C# not having template support. Using templates for container classes as one does in STL is very nifty. I'm frequenctly using std::vector and std::map. I know that arrays are supported in C#, but haven't discovered if maps are....and since I use maps about as often as vectors, that has me a bit worried.
-
My experience with templates has been "The less the better"! Not only are they complex and obscure the solution in many cases, but they are difficult to develop, and unless you are a library provider, they rarely solve enough problems to warrent their usage. That said....I'm a bit worried about C# not having template support. Using templates for container classes as one does in STL is very nifty. I'm frequenctly using std::vector and std::map. I know that arrays are supported in C#, but haven't discovered if maps are....and since I use maps about as often as vectors, that has me a bit worried.
I'd say templates is a design and compiletime feature, and as such it is of most use to me when developing class libraries - which is what I do. Complexity and obscurity are two different things, the former can be handled by providing well-written documentation and tutorials, the latter by simply knowing what you are doing, and keeping in mind that others probably will want to look at the code when using it. Using templates in C# may or may not be a non-issue, depending on who you are listening to. Regarding the .NET runtime capabilities however, template support is irrelevant (to .NET), if we are talking about C++ templates (which really do not change any runtime behaviour). There is of course some thought to be made about the concepts of runtime templates, but if that's a relevant discussion or not is way above my line of skills to make an opinion about. To reconnect the subject; WTL is complex, but not obscure. It helps me solve the problems I need solved in a way that fits my goals (smallest code possible, while still being maintainable to a sufficent degree). Opinions expressed do not neccecarily reflect those of my employer; I do think for myself. Resisting temptation is easier when you think you'll maybe get another chance later on.
-
The .NET Platform and Frameworks take the API to another level. It is what the majority of Windows developer should and will use. There will be new tools, languages, libraries, books, magazines, and all the other supporting activities necessary to make it a very productive and exciting environment to program in. Must more than we've disclosed so far. I'm here to tell you that alongside the .NET Platform, Microsoft will be actively and aggressively developing an unmanaged operating system API and platform including C++ class libraries exposing the underlying operating system to you for a long time to come. This includes MFC, ATL, ATL Server, DirectX, Kernel, User, GDI, Comctl, and all the other API you've come to know and love. We have a lot of new tools, API, etc, in store for the unmanaged developer as well. You should learn about and try out the .NET stuff, you'll find that it can do much of what you want very easily. The existing stuff only gets better from here as well. Walter Sullivan Lead Program Manager, ATL/MFC
All this is real nice and all, but those of us who've been involved with development in Visual C++ and MFC from the beginning been bitten by forced obsolesence imposed by Microsoft in the past, and we're not a very trusting bunch. No amount of corporate rhetoric is going to asuade our trepidation - we'll have to see it to believe it. I've got ten years invested in VC/MFC and while I'm honestly eager to see what .NET and VS7 are all about, I'd hate to think I'm about to lose that time investment and be reduced to the status of a rank beginner once again. I'm too old to have to start over.
-
I'd say templates is a design and compiletime feature, and as such it is of most use to me when developing class libraries - which is what I do. Complexity and obscurity are two different things, the former can be handled by providing well-written documentation and tutorials, the latter by simply knowing what you are doing, and keeping in mind that others probably will want to look at the code when using it. Using templates in C# may or may not be a non-issue, depending on who you are listening to. Regarding the .NET runtime capabilities however, template support is irrelevant (to .NET), if we are talking about C++ templates (which really do not change any runtime behaviour). There is of course some thought to be made about the concepts of runtime templates, but if that's a relevant discussion or not is way above my line of skills to make an opinion about. To reconnect the subject; WTL is complex, but not obscure. It helps me solve the problems I need solved in a way that fits my goals (smallest code possible, while still being maintainable to a sufficent degree). Opinions expressed do not neccecarily reflect those of my employer; I do think for myself. Resisting temptation is easier when you think you'll maybe get another chance later on.
Well.....WTL (like ATL) lacks good documenation. Sure....since its open source, if you're willing to dig around you'll be able to uncover the feature or functionality you need. As for complexity being "handled" with documentation....well there isn't enough written about MFC to make it "simple"....I prefer something that is simple to begin with, and which can be enhanced to make something more complex so that the learning curve is something that can be managed while I develop a product -- hey new stuff is great, but I've got new stuff pouring out of my ears!
-
Well.....WTL (like ATL) lacks good documenation. Sure....since its open source, if you're willing to dig around you'll be able to uncover the feature or functionality you need. As for complexity being "handled" with documentation....well there isn't enough written about MFC to make it "simple"....I prefer something that is simple to begin with, and which can be enhanced to make something more complex so that the learning curve is something that can be managed while I develop a product -- hey new stuff is great, but I've got new stuff pouring out of my ears!
I strongly disagree on WTL being poorly documented. Sure, there are no documentation of the specific classes included in WTL, but most classes expose the same interface as its corresponding MFC class. What really differs between MFC and ATL is the way classes can interact with each other, like the way CWindow, CContainedWindow and CAxWindow is actually implemented. Using the CListBox is really not that different in WTL from MFC, but making it custom drawn is another whole story. Reusing the code that makes it customdrawn is easier by leaps and bounds in WTL compared to MFC. But then again, that is true only for a specific set of problems; there are a lot of problems that is best solved with MFC (although I'm not working with that kind). WTL specifics may be poorly documented, but ATL is not. If one learns ATL, one will surely understand WTL also, provided that he/she also understands the Win32 API (which, I've noticed, is usually not the case with the in-/mid- experienced MFC programmer). To me, simple is not in contradiction to complex. A lot of complex code is simple to reuse, or to modify, or replace entirely. It may still be complex in the way it is constructed, but that does not put implications on the code that depends on it - the interface is of course defined before the logic problem is actually solved and implemented; thus, any dependant code really is bound to the interface, leaving the implementation to be either complex or straightforward. Opinions expressed do not neccecarily reflect those of my employer; I do think for myself.
-
All this is real nice and all, but those of us who've been involved with development in Visual C++ and MFC from the beginning been bitten by forced obsolesence imposed by Microsoft in the past, and we're not a very trusting bunch. No amount of corporate rhetoric is going to asuade our trepidation - we'll have to see it to believe it. I've got ten years invested in VC/MFC and while I'm honestly eager to see what .NET and VS7 are all about, I'd hate to think I'm about to lose that time investment and be reduced to the status of a rank beginner once again. I'm too old to have to start over.
I can't quite figure out what you are saying here. On the one hand you say "but those of us who've been involved with development in Visual C++ and MFC from the beginning been bitten by forced obsolesence imposed by Microsoft in the past", and then you go on to say how you've been using MFC for 10 years and don't want to lose your investement in it. Which is it? Has MS made MFC incompatible and "bitten" you, or hasn't it?
-
I can't quite figure out what you are saying here. On the one hand you say "but those of us who've been involved with development in Visual C++ and MFC from the beginning been bitten by forced obsolesence imposed by Microsoft in the past", and then you go on to say how you've been using MFC for 10 years and don't want to lose your investement in it. Which is it? Has MS made MFC incompatible and "bitten" you, or hasn't it?
I wasn't referring to the language/framework, I was referring to Microsoft's propensity for just abandoning developers with no real notice - case in point - Win32s. They just stopped supporting it with no prior notice to MSDN subscribers, and we had users we had to support. I understand the need to eventually drop support for Win32s (and other antique or work-around technologies), but they pretty much left everyone else high and dry. Further, we were stuck using VC++ 4.1 whgen the rest of the world was free to proceed merily along using newer/better versions of the compiler/framework because MS didn't include support for Win32s in later versions (again understandable, but a pain in the ass, nonetheless). Programmers that have been in the entrenched in the biz for a while have watched MS's development support erode to a mere glimmer of what it was in the not-too-distant past, so I'm probably just a bit jaded. "That was then and this is now" doesn't pass muster with me because it has never worked out in the past. Why should I assume everything is gonna be peachy-f*ckin-keen just because Microsoft says it's gonna be? I certainly don't see a reason to slurp on MS's sphincter simnply because they claim it smells all rosey down there, and I want proof that things have improved. Will I learn C# and .NET? Sure, if I wanna be able to find work. Is C# and .NET everything MS says it's gonna be? Who can tell for sure at this point? Do I have to like and welcome nebulous changes like this? No. I don't mean to sound so bitter/angry/upset or any of that, but i'm not gonna sit back and bite my tongue simply because someone else might not agree with me. :-)
-
I strongly disagree on WTL being poorly documented. Sure, there are no documentation of the specific classes included in WTL, but most classes expose the same interface as its corresponding MFC class. What really differs between MFC and ATL is the way classes can interact with each other, like the way CWindow, CContainedWindow and CAxWindow is actually implemented. Using the CListBox is really not that different in WTL from MFC, but making it custom drawn is another whole story. Reusing the code that makes it customdrawn is easier by leaps and bounds in WTL compared to MFC. But then again, that is true only for a specific set of problems; there are a lot of problems that is best solved with MFC (although I'm not working with that kind). WTL specifics may be poorly documented, but ATL is not. If one learns ATL, one will surely understand WTL also, provided that he/she also understands the Win32 API (which, I've noticed, is usually not the case with the in-/mid- experienced MFC programmer). To me, simple is not in contradiction to complex. A lot of complex code is simple to reuse, or to modify, or replace entirely. It may still be complex in the way it is constructed, but that does not put implications on the code that depends on it - the interface is of course defined before the logic problem is actually solved and implemented; thus, any dependant code really is bound to the interface, leaving the implementation to be either complex or straightforward. Opinions expressed do not neccecarily reflect those of my employer; I do think for myself.
If ATL is not poorly documented, do you mean to say it is well documented????? I sure don't think so, and I've been using it for over three years! Its not awful, and it can be decoded, but it is not well documented. As for being ATL complex but simple, I think you're forgetting that there is a lot to manage WHENEVER you use MI and whenever you use templates....let alone use the two together!! Sometimes a typo in an ATL class header can cause the most confounding error messages!! Don't get me wrong....I love ATL -- I use it a lot when I want to write a COM object that doesn't have any UI support....but for UI I find there is a lot more MFC code out there to work with, and that it is easier to work with. That doesn't mean its "better", but at the same time, MFC more than does the job for my apps.
-
I wasn't referring to the language/framework, I was referring to Microsoft's propensity for just abandoning developers with no real notice - case in point - Win32s. They just stopped supporting it with no prior notice to MSDN subscribers, and we had users we had to support. I understand the need to eventually drop support for Win32s (and other antique or work-around technologies), but they pretty much left everyone else high and dry. Further, we were stuck using VC++ 4.1 whgen the rest of the world was free to proceed merily along using newer/better versions of the compiler/framework because MS didn't include support for Win32s in later versions (again understandable, but a pain in the ass, nonetheless). Programmers that have been in the entrenched in the biz for a while have watched MS's development support erode to a mere glimmer of what it was in the not-too-distant past, so I'm probably just a bit jaded. "That was then and this is now" doesn't pass muster with me because it has never worked out in the past. Why should I assume everything is gonna be peachy-f*ckin-keen just because Microsoft says it's gonna be? I certainly don't see a reason to slurp on MS's sphincter simnply because they claim it smells all rosey down there, and I want proof that things have improved. Will I learn C# and .NET? Sure, if I wanna be able to find work. Is C# and .NET everything MS says it's gonna be? Who can tell for sure at this point? Do I have to like and welcome nebulous changes like this? No. I don't mean to sound so bitter/angry/upset or any of that, but i'm not gonna sit back and bite my tongue simply because someone else might not agree with me. :-)
If anything, MS maintains backwards compatibility *TOO* long. Take the for scope of VC6 for instance, or the crappy CObject type identification. Win32s was an abomination. It needed to die, as it was holding back the framework from progressing. If you want to talk abandonment, look at Borland. They simply abandoned OWL completely. They broke all their old users code in the name of chasing after a moving draft standard. BTW, while you were limited to using MFC 4.1, you weren't limited to using VC4.1. You could use MFC 4.1 up to most recent VC6 if you wanted to.
