MFC's future
-
I think without MS behind it, a slight breeze could kill MFC. :rolleyes: If I were just learning to program now, would I try to learn MFC? No sooner than I'd try to learn COBOL. MFC-only coders will live on for years in maintenance roles and in their own projects, but unless MS puts some serious muscle into updating it, it'll soon lose all appeal for new projects.
Shog9
Let your mercy spill / On all these burning hearts in hell If it be your will / To make us well...
Shog9 wrote: MFC-only coders will live on for years in maintenance roles and in their own projects, *looks at resume, notices no .NET-related technologies listed* Aww CRAP! ;P I prefer to wear gloves when using it, but that's merely a matter of personal hygiene [Roger Wright on VB] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. [Rich Cook]
-
MFC will become the equivalent of those old classes we used to use for "windowing" in dos programs within the next 7-10 years. There's too much legacy code to see it die rapidly, but I suspect that it's going to fade away. I'm fully into .net now and couldn't see any reason to MFC for business application development. Maybe little utilities, etc, but then again those are usually ideal console apps so who can say. The real kicker is when .net is standard on every PC. At that point who wouldn't use it for little utilities etc when it compiles to a tiny 5k program. I'm amazed when a fairly sophisticated business app compiles to only 100kb in total for .net. It's great that way. Either way, I don't think .net can be put in the "fad" category at this point, I had my doubts a year ago, but it's very slick, works well, makes sense from every aspect for working class programming of business apps. MFC is just loaded with too much crap that it has accumulated over the years from win 3 days to now and it's become so byzantine and archaic by modern standards that it just has to collapse eventually under it's own weight. ------------
And the funy thing that the highly paid and the most valuable people working in my organization are the ones who back 15-20 years ago wrote some proprietary server stuff on very popular and cutting edge back then VAX/VMS... using Pascal!!! Gues what -- they are still in charge... The real kicker is when .net is standard on every PC. At that point who wouldn't use it for little utilities etc when it compiles to a tiny 5k program. I'm amazed when a fairly sophisticated business app compiles to only 100kb in total for .net. It's great that way. Sure, however I was waiting for MFC4 to appear on every PC for 6 years now. Looks like it happened!... That's why alot of MFC guys are not in a hurry to move to VC7 -- wait another 6 years for MFC7 to be deployed?! 100KB business applcation? How much resources are in it? Or maybe resources under .NET became smaller? "Hello world" -- 12 bytes --> that's how large your ideal EXE should be, assuming Notepad is installed? How large is CLR man?... Check this out if haven't done yet... Also, check your IE size that suppose to deploy your 100k EXE... MFC is just loaded with too much crap that it has accumulated over the years from win 3 days to now and it's become so byzantine and archaic by modern standards that it just has to collapse eventually under it's own weight. So, 12MB CLR is not crap and is absolutely used by your 100kb business application? Mine MFC app with a crap could sit amazingly on 1.2mb diskette (including MFC BTW)... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
Nishant S wrote: Uhm, I take it that you have never taken a proper look at the .NET BCL. If you had then you probably wouldn't be saying this Jim. Remember, there is nothing stopping you from continuing to use MFC while also taking advantage of the BCL. Well, no, I haven't. Interesting; I've heard of CLR, but not BCL. But, see, here's why desktop developers aren't interested in .NET: 1) It's geared primarily towards Web development. 2) It requires a 10 meg+ DLL. 3) It's not geared towards performance: it's geared towards Jave-like performance, via C#. No, I can't work on .NET while working on MFC apps. Why? No time to learn! Writing good code takes time. Even after 20 years in this biz, the last 12 doing C++ exclusively, I still have tons to learn about C++. Why waste time learning yet here another today, gone tomorrow Microsoft technology?
Jim A. Johnson wrote: 2) It requires a 10 meg+ DLL. This is what stops me from using .Net presently. According to my site stats, close to 50% of the people are still using Windows 98. (I get more hits from Mac and Linux users than WinME users! hehe) I don't think it would go over too well with alot of users if my setup package jumped from 4MB to 15ishMB. (As more people start using highspeed, it should also become more feasible to use .Net.) At any rate, I plan on learning .Net in the background on small projects, (so far I find it excellent) but I think it's going to take some time before it becomes the "mainstream thing". XP was released in 2001, and still only 30-35% of windows users are actually using it. How long is it going to take before a majority are using a version of Windows that comes with .Net pre-installed?
My 20 favorite films:
http://www.ymdb.com/user_top20_view.asp?usersid=8912 -
The whole point is that, if .NET actually does kill MFC, then it probably just establishes the fact that .NET must have actually got to a stage where programmers find it much more powerful and easy to use than MFC ever was. The old must make way for the young. It's been like that since Adam first saw Eve without the leaves... Nish
"I'm a bit bored at the moment so I'm thinking about writing a new programming language" - Colin Davies My book :- Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
Nishant S wrote: The old must make way for the young. It's been like that since Adam first saw Eve without the leaves... I love the bible. It is R-rated all over the place, especially the Old Testament, but it's written in subtle way so that kids and naive adults will complete miss it the sexual aspect and can pass for PG. Wes
-
John Cardinal wrote: desparado author fleeing the country :-D Nish
"I'm a bit bored at the moment so I'm thinking about writing a new programming language" - Colin Davies My book :- Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
sorry for asking: but what does the 'S' stand for.. you call yourself nishant s. never figured out what the s means.
"I'm from the South Bronx, and I don't care what you say: those cows look dangerous."
U.S. Secretary of State Colin Powell at George Bush's ranch in Texas -
sorry for asking: but what does the 'S' stand for.. you call yourself nishant s. never figured out what the s means.
"I'm from the South Bronx, and I don't care what you say: those cows look dangerous."
U.S. Secretary of State Colin Powell at George Bush's ranch in TexasBernhard wrote: but what does the 'S' stand for.. Nishant Sivakumar Nish :-)
"I'm a bit bored at the moment so I'm thinking about writing a new programming language" - Colin Davies My book :- Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
-
I think without MS behind it, a slight breeze could kill MFC. :rolleyes: If I were just learning to program now, would I try to learn MFC? No sooner than I'd try to learn COBOL. MFC-only coders will live on for years in maintenance roles and in their own projects, but unless MS puts some serious muscle into updating it, it'll soon lose all appeal for new projects.
Shog9
Let your mercy spill / On all these burning hearts in hell If it be your will / To make us well...
-
Microsoft .NET is a very perspective technology, but I think it could kill MFC. Not in near future, but some time later. I didn't read anything about this, I'm just want to hear your opinion about MFC's future.
Well, where I work we create machine prototypes and the performance is very very important, nowadays we are programming in VC++6 and MFC, and due to the great amount of job I have not been able to study the .NET... When I can I will study it because as is a new technology I need to know it, I don't want to wake up one morning and see that I'm totally "out of scope"... I've seen the IDE that comes with the VC++ .NET and it has been a big pain... it is very different that the one that exists now... and this makes even more difficult to change from the MFC environment to the NET one... But as each new technology, it will have it's use and some people will embrace it and some others will discard it... MFC will change not disappear... there must be always a way to program only for your desktop computer in a fast way... avoiding the classes that are used to interconnect PC's via iNet and so on... ... I leave it here, talking about this is talking about the future and I cant predict it... :-O
-
Nishant S wrote: Uhm, I take it that you have never taken a proper look at the .NET BCL. If you had then you probably wouldn't be saying this Jim. Remember, there is nothing stopping you from continuing to use MFC while also taking advantage of the BCL. Well, no, I haven't. Interesting; I've heard of CLR, but not BCL. But, see, here's why desktop developers aren't interested in .NET: 1) It's geared primarily towards Web development. 2) It requires a 10 meg+ DLL. 3) It's not geared towards performance: it's geared towards Jave-like performance, via C#. No, I can't work on .NET while working on MFC apps. Why? No time to learn! Writing good code takes time. Even after 20 years in this biz, the last 12 doing C++ exclusively, I still have tons to learn about C++. Why waste time learning yet here another today, gone tomorrow Microsoft technology?
Jim A. Johnson wrote: It's geared primarily towards Web development. Amazing, this is a postulate that I often hear related to Java. It's a bit confusing, because I rarely use Java for the Web. I have done ISAPI and CGI in C a lot though, but I would hesitate to declare that C is designed for web applications... "After all it's just text at the end of the day. - Colin Davies "For example, when a VB programmer comes to my house, they may say 'does your pool need cleaning, sir ?' " - Christian Graus
-
peterchen wrote: MFC RIP I hope not :( I hear the opposite alot tha MFC is growing and will continue to grow. I am just to ground in to my current programming habits. Code4Food ---- "There is no try; only do or do not" -Yoda
Code4Food wrote: I hear the opposite alot tha MFC is growing and will continue to grow. MFC can't die, there is far too much legacy code out there that use it. MFC is not growing. There is no further place for MFC to grow. It is a ten year old framework that has served us well. Whilst we are still writing Win32 desktop apps then MFC will always be with us but for the new future that MS are creating, there is no room for MFC. Michael 'War is at best barbarism...Its glory is all moonshine. It is only those who have neither fired a shot nor heard the shrieks and groans of the wounded who cry aloud for blood, more vengeance, more desolation. War is hell.' - General William Sherman, 1879
-
How would you right a product such as dreamweaver: a. Straight C b. Straight C++ c. WTL d. MFC e. .net
Normski wrote: How would you right a product such as dreamweaver VB or Java ;P
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Sure, why not? If you are not concerned with memory footprint as well as .NET deployment is not an issue -- sure it can and probably should be used... I'm just against that crowd that already rendered MFC/ATL/COM as dead. Yes, sure CLR and only CLR is the bright future! LOL... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
Actually Nish and I are the most ardent MFC devs you'll ever find. That's exactly why we're writing a book showing not how to replace MFC but how to augment MFC with the various BCL classes. Sure I can download Boost. I can download Expat. I can download a bunch of stuff because everybody's got their own API for everything. However, with the BCL I can simply flip a switch and get both class libraries - MFC and BCL. This gives me the best of both worlds. I continue being productive in an environment that I've used since version 1 and yet I get access to a class library that provides many features I don't have with MFC by doing nothing more than changing a project setting. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
Nishant S wrote: Uhm, I take it that you have never taken a proper look at the .NET BCL. If you had then you probably wouldn't be saying this Jim. Remember, there is nothing stopping you from continuing to use MFC while also taking advantage of the BCL. Well, no, I haven't. Interesting; I've heard of CLR, but not BCL. But, see, here's why desktop developers aren't interested in .NET: 1) It's geared primarily towards Web development. 2) It requires a 10 meg+ DLL. 3) It's not geared towards performance: it's geared towards Jave-like performance, via C#. No, I can't work on .NET while working on MFC apps. Why? No time to learn! Writing good code takes time. Even after 20 years in this biz, the last 12 doing C++ exclusively, I still have tons to learn about C++. Why waste time learning yet here another today, gone tomorrow Microsoft technology?
Jim A. Johnson wrote: No, I can't work on .NET while working on MFC apps. Why? No time to learn! Writing good code takes time. That's precisely the point. I could care less about .NET in my normal day-to-day Windows programming life. However, the BCL simply gives me access to another class library. You have to learn very little about the CLR in order to take advantage of the BCL. Jim A. Johnson wrote: Why waste time learning yet here another today, gone tomorrow Microsoft technology? Because programming is a an evolutionary job where you continually learn to master the best way to remain as productive as you can. Like any other new technology I simply isolate my BCL code so that if it's gone a few years down the road, I plug something else in. I woudl do that with any library or set of APIs that I'm working with. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
I have heard from people that Visual Studio 8 (whatever they name it) will have many enhancements. The only thing is that these people are sworn to non-disclosure agreements. So, it would appear that it is not entirely dead... if what they say is true. Also, my copy of Programming with Visual C++.NET, which is an MSPRESS core reference, is full of MFC code. This is promising for MFC, but not particularly meaningful, since this is a Sixth Edition book which was based of the Fifth Edition which was written at the height of MFC. Here are a few quotes: "MFC is a mature and well-understood technology that's accompanied by a host of third-party extensions. For at least a little while longer, MFC represents the most effective way to write full-featured stand-alone applications" - Programming with Microsoft Visual C++.NET, page xxx. "Is COM dead? Is MFC dead? Is ATL dead? These are questions many developers are asking. The simple answer is no, these older technologies are not dead. Yes, old skills still have value. A few years ago, people used to ask whether Java was going to kill C++. I always answered, 'Did C++ kill COBOL?' Of course not. In the same way, .NET isn't going to kill traditional Windows-only programming." - Using Visual C++.NET, page 15. "One of the design goals for Visual C++.NET was that it should be, to quote a member of the Microsoft development team, 'a great upgrade' for those doing non-.NET Windows programming. This, by the way, was not a design goal for other parts of Visual Studio.NET, including Visual Basic.NET." - Using Visual C++.NET, page 15. "ATL & MFC remain viable options for developers who want to write unmanaged code, and we’re still actively enhancing the libraries. Two big things we’re doing for the next version are making ATL interoperate with MFC better and also creating a new technology, ATL Server, which gets developers to the .NET platform while being able to leverage their existing ATL/MFC code. We will not update MFC/ATL to become managed (the .NET Framework already does a great job in that space). " - Lon Fisher on .NET @ CodeProject[^] These quotes are helpful, but not inspiring. I keep asking, "What is a little while?" and "Isn't COBOL really as good as dead?" I guess we will see. I am encouraged that C++ got consideration as heav
Tom Welch wrote: I have heard from people that Visual Studio 8 (whatever they name it) will have many enhancements. The only thing is that these people are sworn to non-disclosure agreements. So, it would appear that it is not entirely dead... if what they say is true. I would be one of those people. As someone that is on the various betas, I can't be specific. However, I can tell you that I wouldn't have spent the past number of months writing a book on extending MFC if I thought MFC were going away. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
Me think MFC will stay with us much longer then you guys here are expecting. Not to say, that there is no real conflict in using MFC and .NET: it's just not mutualy excluding technologies as you present it here. You can still use full power of MFC in your MC++ compiler. Yes, you will lose security permision features -- so what? Unless you are deploying not to fully trusted sites -- that's fine. Yes, no question .NET and CLR is nice for distributed and server site developments. On the client however: one could complain about alot of things not implemented there to consider it comparable to MFC and OLE/COM currently fully available from unmanaged soultions: Where are Windowless Controls? Where is aggregation? Where is Compound Document support? Where is standard Plugin Architecture comaparable to ActiveX, where OLE Container at least knows where to find available controls and what interfaces they should support? P/Invoke is everywhere! COM Assembly wrappers HUGE! (Check mshtml). You move HTML into managed -> CCW will be HUGE! (and you have to support it cause COM inside HTML will be used for very long time)... I also, see alot of possible problems realated to uncontrolable way GC and "Lazy COM" works in .NET. What I mean here: my company spend alot of efforts developing Client Solutions in Java, and what happened is: it's very difficult in QA to test and predict possible client configurations. So, what happens is: QA tests your "managed"(or java) program under some stressed conditions, but in reality client conditions are "slightly" different, therefore client circumstances may not be tested well enough... Time of course will tell...:);P "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
MFC will be with us for a very long time. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
Joe Woodbury wrote: An experienced developer can still put an GUI application together faster with MFC than with .NET Hmm..I'd have to disagree with you 100% there, but then again I guess it depends on the application. I've no need for MDI or SDI and pretty much never have so maybe that's what your referring to? ------------
I agree that the winforms controls are nice, but I can also code a ui much quicker in MFC - due to these main reasons: 1) document templates 2) commandui 3) command routing 4) shell integration 5) document/view support ... This is not to mention the fact that anything I can't do in MFC has been done by somebody, some place and surely posted on some Web site. WinForms is just too new to have that kind of support. Can I hack any of these features with WinForms? Sure. But why should I move to something until it proves to be better than what I currently have? I guess it comes down to user base issues. My clients are accustomed to what we as MFC devs can produce and the timeline it takes us. I can't justify taking longer in order to use a new tool when I can't quantify why the new tool will help them as end-users. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson -
Tom Welch wrote: I have heard from people that Visual Studio 8 (whatever they name it) will have many enhancements. The only thing is that these people are sworn to non-disclosure agreements. So, it would appear that it is not entirely dead... if what they say is true. I would be one of those people. As someone that is on the various betas, I can't be specific. However, I can tell you that I wouldn't have spent the past number of months writing a book on extending MFC if I thought MFC were going away. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen SigvardssonTom Archer wrote: I would be one of those people. As someone that is on the various betas, I can't be specific. However, I can tell you that I wouldn't have spent the past number of months writing a book on extending MFC if I thought MFC were going away. You are so close to becoming my hero. :)
-
And the funy thing that the highly paid and the most valuable people working in my organization are the ones who back 15-20 years ago wrote some proprietary server stuff on very popular and cutting edge back then VAX/VMS... using Pascal!!! Gues what -- they are still in charge... The real kicker is when .net is standard on every PC. At that point who wouldn't use it for little utilities etc when it compiles to a tiny 5k program. I'm amazed when a fairly sophisticated business app compiles to only 100kb in total for .net. It's great that way. Sure, however I was waiting for MFC4 to appear on every PC for 6 years now. Looks like it happened!... That's why alot of MFC guys are not in a hurry to move to VC7 -- wait another 6 years for MFC7 to be deployed?! 100KB business applcation? How much resources are in it? Or maybe resources under .NET became smaller? "Hello world" -- 12 bytes --> that's how large your ideal EXE should be, assuming Notepad is installed? How large is CLR man?... Check this out if haven't done yet... Also, check your IE size that suppose to deploy your 100k EXE... MFC is just loaded with too much crap that it has accumulated over the years from win 3 days to now and it's become so byzantine and archaic by modern standards that it just has to collapse eventually under it's own weight. So, 12MB CLR is not crap and is absolutely used by your 100kb business application? Mine MFC app with a crap could sit amazingly on 1.2mb diskette (including MFC BTW)... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: So, 12MB CLR is not crap and is absolutely used by your 100kb business application? Mine MFC app with a crap could sit amazingly on 1.2mb diskette (including MFC BTW)... That's not the point and you know it. I don't have a single diskette in this office, I *do* however download software from the internet. That's the whole point. If you forsee a rewarding career as a maintenance programmer, I'm not going to tell you that's wrong, to each his own. I just prefer to be working on new things, learning new things etc. ------------
-
I agree that the winforms controls are nice, but I can also code a ui much quicker in MFC - due to these main reasons: 1) document templates 2) commandui 3) command routing 4) shell integration 5) document/view support ... This is not to mention the fact that anything I can't do in MFC has been done by somebody, some place and surely posted on some Web site. WinForms is just too new to have that kind of support. Can I hack any of these features with WinForms? Sure. But why should I move to something until it proves to be better than what I currently have? I guess it comes down to user base issues. My clients are accustomed to what we as MFC devs can produce and the timeline it takes us. I can't justify taking longer in order to use a new tool when I can't quantify why the new tool will help them as end-users. Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen SigvardssonI really don't understand this, perhaps it's because we develop client server database apps primarily, but there is undoubtedly no question that winforms or several orders of magnitude faster than mfc. I don't know about dancing paper clips etc but for a meat and potatoes client side application I just can't agree. ------------
-
Tom Archer wrote: I would be one of those people. As someone that is on the various betas, I can't be specific. However, I can tell you that I wouldn't have spent the past number of months writing a book on extending MFC if I thought MFC were going away. You are so close to becoming my hero. :)
Tom Welch wrote: You are so close to becoming my hero. :) I should come up with my own theme song... Coder-man, coder-man Does whatever a guru can. Spins an app, any size Right before your very eyes. Look out! Here's comes the coder-man.... Cheers, Tom Archer Inside C#,
Extending MFC Applications with the .NET Framework It's better to listen to others than to speak, because I already know what I'm going to say anyway. - friend of Jörgen Sigvardsson