goodbye MFC, goodbye windows
-
Beer26 wrote: ready to try to port WinAPI for GDI on xlib. Even if I'm not able to do that completely, I'm going to keep going in this direction with existing libs like gtkmm for building apps now. So you're not really leaving the world of Microsoft if you're still using WinAPI? Beer26 wrote: Too much for me. I'm outta here. Well, say hello to a lot of development tools that are poorly documented, don't work as advertised (oh wait, Linux people don't NEED to advertise!!!) and take days and days to install, often involving custom tweaks of your device drivers just to get things running. And you think I exaggerate. Mwahahaha! Beer26 wrote: I'm outta here. Does that mean you won't be posting on CP anymore? ;P Marc MyXaml Advanced Unit Testing
marc i know ur a very experienced developer and all but really ... keep it real please ... im by no means a linux guru but i can set up a dual-boot machine with dev environments for both windows and debian/linux in maybe 5hrs (with a decent internet connection) sure developing for linux isnt as easy as windows with its single api (well it DID have a single api hmmmmmmmm) but it is here to stay and its future development isnt driven by the need to make ever more profits (like ms is) linux is becoming a very serious threat to ms and they know it so i would suggest that all smart developers with more than a few years of working life ahead of them get at least familiar with linux as well as windows
-
marc i know ur a very experienced developer and all but really ... keep it real please ... im by no means a linux guru but i can set up a dual-boot machine with dev environments for both windows and debian/linux in maybe 5hrs (with a decent internet connection) sure developing for linux isnt as easy as windows with its single api (well it DID have a single api hmmmmmmmm) but it is here to stay and its future development isnt driven by the need to make ever more profits (like ms is) linux is becoming a very serious threat to ms and they know it so i would suggest that all smart developers with more than a few years of working life ahead of them get at least familiar with linux as well as windows
l a u r e n wrote: marc i know ur a very experienced developer and all but really ... keep it real please ... Good heavens. I was being sarcastic (well, mostly)! I guess I forgot the smileys. Here. I'll make up for it: :-D :-D :-D Marc MyXaml Advanced Unit Testing
-
yes, it does, unless you open a linux section. I am currently using the intel C/C++ compiler for linux along with the eclipse cdt IDE for development http://www.intel.com/software/products/compilers/linux/ http://www.eclipse.org/cdt/ Eclipse IDE actually comes with the intel linux compiler, I use the GTK UI with that. They actually do work as they are supposed to. I think you are refering to IDE's like KDevelop and other such IDE's that aren't as good or use proprietary libraries by default such as QT instead of the free GTK ones. I've been developing with linux for about a year now in testing, and it's been going pretty well. You are right that the stuff isn't as polished as on windows for development and requires more reading and time, but I think it's worth it for what I want to do with the future of my application development. I want code that will last past the latest trend. I tried alot of stuff from MS including WFC with J++, MFC, COM, C++, ASM with MASM over the years and it was all pretty steady until technologies started dropping off, esp after the lawsuit with sun. I think it would be AWESOME X 10 of you guys here at CP to open a C++ section for linux, and I would be more than willing to submit some of the class libraries I have made this past year for sockets, and other utilities. I don't have that many,but I'm building it up every day. Linux already has alot of great free dev-libraries to link to, but I am trying to make a repository of free reusable classes for myself like you all have here. Any chance of that as a new section? I know you have alot of MS adverts on here, so I'm not sure if you guys are allowed to do it or not.
I too think it would be awesome to have a linux (or rather a unix) section here. A couple of years ago several of us thought the same way, and there was even some active talk about it, but it never panned out. Before you go too hog wild on linux, some thoughts from someone who has done a fair bit of *attempted* advanced GUI dev on linux, as well as successful advanced GUI dev on Win32 and OS X. I have written (or attempted - you can see where this is going) code using both raw XLib and GTK. Both suck the toenails off a rhino. gtkmm is slightly less sucky, but only slightly. Marc is dead on when it comes to tools. Yes KDevelop *looks* pretty. And in fact it even does some damn nice stuff as long as you buy into certain preconditions, such as build management using automake and autoconf. Automake and autoconf are programming abortions which should be wiped from the face of the earth. Written to make writing make files easier, they simply extend the problem by introducing yet *another* unreadable, useless, gibbering set of text files that no one really understands how they work! (But look! It's text! Shiny things!) Sadly KDevelop uses them extensively. The problem? Try using KDevelop when you have somehow gotten the *wrong* version of either automake or autoconf, and you'll soon discover how truly fucked you are. And good luck trying to upgrade them (I tried. Repeatedly. And gave up). And good luck with docs. Ouch. Can you say ouch again? I knew you could. Get used to using a LOT of Google and walking through the GTK code. The mailing list is so so, IMHO the signal-to-noise ratio was not very good. You get a lot of mindless jibber-jabber on it. So you want to use STL? Oooh, can we all say overnight compiles! GCC blows the spew of hobgoblins, and that's putting it nicely. It's horribly slow-and the resulting code tends to be 3-4 times the size of what the MSVC compiler produces - and that's with optimizing for size and running strip on binaries. Ahh, but now you want to debug right? Well make sure to become thoroughly aquainted with printf, because if you think GCC blows chunks, the GNU debugger, GDB, positively sprays heaping chunks of elephant fecal matter. You'll be introduced to such fun things as: - dropped breakpoints - GDB has the annoying habit of simply "forgetting" where you set the breakpoint, and then blowing right past it. Fun. - it has a weird concept of what stepping through a line of code means. Perhaps this is only on OS X, but if you try and step through code, you frequently end
-
I too think it would be awesome to have a linux (or rather a unix) section here. A couple of years ago several of us thought the same way, and there was even some active talk about it, but it never panned out. Before you go too hog wild on linux, some thoughts from someone who has done a fair bit of *attempted* advanced GUI dev on linux, as well as successful advanced GUI dev on Win32 and OS X. I have written (or attempted - you can see where this is going) code using both raw XLib and GTK. Both suck the toenails off a rhino. gtkmm is slightly less sucky, but only slightly. Marc is dead on when it comes to tools. Yes KDevelop *looks* pretty. And in fact it even does some damn nice stuff as long as you buy into certain preconditions, such as build management using automake and autoconf. Automake and autoconf are programming abortions which should be wiped from the face of the earth. Written to make writing make files easier, they simply extend the problem by introducing yet *another* unreadable, useless, gibbering set of text files that no one really understands how they work! (But look! It's text! Shiny things!) Sadly KDevelop uses them extensively. The problem? Try using KDevelop when you have somehow gotten the *wrong* version of either automake or autoconf, and you'll soon discover how truly fucked you are. And good luck trying to upgrade them (I tried. Repeatedly. And gave up). And good luck with docs. Ouch. Can you say ouch again? I knew you could. Get used to using a LOT of Google and walking through the GTK code. The mailing list is so so, IMHO the signal-to-noise ratio was not very good. You get a lot of mindless jibber-jabber on it. So you want to use STL? Oooh, can we all say overnight compiles! GCC blows the spew of hobgoblins, and that's putting it nicely. It's horribly slow-and the resulting code tends to be 3-4 times the size of what the MSVC compiler produces - and that's with optimizing for size and running strip on binaries. Ahh, but now you want to debug right? Well make sure to become thoroughly aquainted with printf, because if you think GCC blows chunks, the GNU debugger, GDB, positively sprays heaping chunks of elephant fecal matter. You'll be introduced to such fun things as: - dropped breakpoints - GDB has the annoying habit of simply "forgetting" where you set the breakpoint, and then blowing right past it. Fun. - it has a weird concept of what stepping through a line of code means. Perhaps this is only on OS X, but if you try and step through code, you frequently end
I'm actually working on doing the Win GDI on top of Xlib right now so us former windows MFC developers can easily develop on linux in the future. I used KDevelop for a couple years, and I didn't like the QT integration aspect, because it's heavy and QT costs alot of money for a non GPL license. The intel compiler I use is much better than GCC and it costs nothing for a GPL license or $399 for a commerical license, cheaper than visual studio, and it comes with Eclipse IDE for GTK+ or motif. GTKmm is far superior to GTK because you can use it with C++. The framework is similar to MFC and it's pretty easy to build an app with Glade or Glade2 for UI RAD building then just do your event code in the precoded functions. Glade and GTKmm is very similar to MFC as far as the app wizard. OK, I first started coding on linux with C++ in late 99 early 2000, so I'm not totally new to it, though I only used to use the shell with gcc and gdb. The thing is, it was just an extra until recently. Now I've decided i don't want to eat MS's soup de jour anymore when ever they clean house and change platforms on a whim, and I want something a little more stable as my development platform. If you haven't tried intel's compiler for linux there is a demo and a GPL version you can try, it's rather good. It makes shared so libs .a libs(with ar of course) and normal binaries and link pretty much just like GCC and it's compatible with existing libraries. I think if you used KDevelop with GCC, you really should try Eclipse with intel cc because it's much nicer. Eclipse's "IDE managed" make files aren't super great because they don't let you do the `pkg-config something` for extra libs. They actually make you enter each and every include dir and lib dir individually. Though I don't have to worry about it because I code my own make files, I learned how a while ago, and it's alot easier than using automake. Cheers PS- though I personally prefer RPM because it's now standard with the linux standard base linuxbase.org , People that are hardcore into windows installers can use installsheild for linux also, which is nice though I'd never use it over rpmbuild
-
Beer26 wrote: If i continue to develop windows software just because my customers use it... I don't understand where you are coming from here - do you mean you won't be developing Windows software for your clients anymore, or something else? :~ I was saying that, in the former case, few of us get to control what our clients run and that is why we will continue to write Windows software. If everybody in the industry stopped developing Windows software overnight, it wouldnt be Microsoft that would suffer and be forced to limit us to a single framework to win back developers, it would be the hundreds of thousands of development companies filing for bankruptcy the following morning.
David Wulff The Royal Woofle Museum
Everybody is entitled to my opinion
would IBM and sun be among them? just kidding. I get your point, it's costly, but I'd rather go this route and have lasting extensible code for my own development needs. I know this may not work for everybody and I'm not saying it should. The dropping of MFC was the final straw for me though.
-
would IBM and sun be among them? just kidding. I get your point, it's costly, but I'd rather go this route and have lasting extensible code for my own development needs. I know this may not work for everybody and I'm not saying it should. The dropping of MFC was the final straw for me though.
You will NEVER have "lasting" code! It is a fact of like for a developer. Technologies will come that clients demand and you will always move on to something else. You only have to find what is new, jump into it and it should last you far longer than any legacy technologies. Yes, C++ or Java will be around, but the API's keep changing and demands on the software keep changing. This is not just a MS thing, it is all platforms. Shoot, even Apple through out their OS for a Unix form. About the only way you can write code that will last for a LONG time is to make it not access storage, never have a UI, do not access networks. Yep, it can just about only do a loop :) Look how far Java has changed with their new version? Linux now has two GUI's, what is going to happen when they want to compete with Longhorn and its advanced graphics? More changes... On a little side note, you can dig into things such as .NET or Java and work both sides of the fense, since they are now mostly cross platform. Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
-
I have been hearing pretty much this exact message for 7 years. I believe MFC is a 5 headed monster that will probably never die so while you should definitely be learning the newer technologies I'd take the "death is imminent" message with a grain of salt. I think Microsoft would probably like MFC to die, but that by no means it actually will. David
Agreed. For every person at MS that says that it's dead, I can give you one that says that not only is it alive, but that it will have another reason. For example, Walter Sullivan is a manager on the VC++ team (also one of the main people who put the WTL on the MSDN CDs some time ago) and he's stated on several occassions that MFC isn't going anyplace. Cheers, Tom Archer "Use what talents you possess. The woods would be very silent if no birds sang there except those that sang best." - William Blake * Inside C# -Second Edition * Visual C++.NET Bible * Extending MFC Applications with the .NET Framework
-
Windows Forms will be in the place of MFC come 2006 -- supported, but not the primary (or at least, "newest") GUI framework, thanks to Avalon.
Any remotely useful information on my blog will be removed immediately.
There are 10 kinds of people in the world. Those who have heard of the ubiquitous, overused, worn-out-like-an-old-shoe binary "joke" and those who haven't. Judah Himango
Yeah, but in 2006 most development is going to go through a major change. I kind of dread it as I have too much work to do now ;) Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
-
my updated books for sale list, and here is my slightly tarnished copy of VS2005 that just got tossed out. I know alot of you guys can't do this, but this was really the last straw for me. I was one of those saps that took the time to learn WFC java extensions only to have all my apps become obsolete over night. And now this. I took the past couple years to learn C/C++ linux programming because in the back of my mind, I just knew this was going to happen, that once again, all of my user applications would become unextensible and worthless. I knew it. I just did. So I took my free time and learned C/C++ on lin and now I'm ready to move forward with standard code and libraries STL, ect... that I know are here to stay. I know alot of you think this is dumb, but this is the path I'm going on. I have one pretty big last direct show application I made with MFC to finish, then I'm going to kiss it goodbye. I have built myself a mega lin development tower, and I'm getting ready to try to port WinAPI for GDI on xlib. Even if I'm not able to do that completely, I'm going to keep going in this direction with existing libs like gtkmm for building apps now. Alot of you can't because win now dominates the desktop, but I can't stand these types of changes anymore. They don't just extend on a technology anymore, they wipe it out and start all over again and it's too much for me. I thought MFC was here to stay from earlier posts a couple years ago by the same guy from MS, but now they've changed their minds. Too much for me. I'm outta here.
Steve is just giving his opinion. Like when Jeffrey Richter states that all .NET dev is going to be C# because that's *the* .NET language. Read my response to David C where I basically refer to Walter Sullivan's remarks (Walter is a PM on the VC++ team) about the fact that MFC is not going away any time soon. Cheers, Tom Archer "Use what talents you possess. The woods would be very silent if no birds sang there except those that sang best." - William Blake * Inside C# -Second Edition * Visual C++.NET Bible * Extending MFC Applications with the .NET Framework
-
You will NEVER have "lasting" code! It is a fact of like for a developer. Technologies will come that clients demand and you will always move on to something else. You only have to find what is new, jump into it and it should last you far longer than any legacy technologies. Yes, C++ or Java will be around, but the API's keep changing and demands on the software keep changing. This is not just a MS thing, it is all platforms. Shoot, even Apple through out their OS for a Unix form. About the only way you can write code that will last for a LONG time is to make it not access storage, never have a UI, do not access networks. Yep, it can just about only do a loop :) Look how far Java has changed with their new version? Linux now has two GUI's, what is going to happen when they want to compete with Longhorn and its advanced graphics? More changes... On a little side note, you can dig into things such as .NET or Java and work both sides of the fense, since they are now mostly cross platform. Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
Rocky Moore wrote: You will NEVER have "lasting" code There *IS* long lasting code. I work with a machine translation library that was initially developed in early 90's. Works like a charm. Do you know how much Fortran 77 code is around and still working? Rewriting perfectly functional software just to be "hip" makes no business sense.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Rocky Moore wrote: You will NEVER have "lasting" code There *IS* long lasting code. I work with a machine translation library that was initially developed in early 90's. Works like a charm. Do you know how much Fortran 77 code is around and still working? Rewriting perfectly functional software just to be "hip" makes no business sense.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
It's not being HIP.. It is not rewriting the software, it is NEW development. It is maintaining old code that take more work to keep up than to rewrite. If you continue to write in old legacy technologies, you will be in a box and your market will shrink. It depends on what you are doing and what you expect. There are a lot of DOS applications around, but I know of no one that writes them today! Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
-
It's not being HIP.. It is not rewriting the software, it is NEW development. It is maintaining old code that take more work to keep up than to rewrite. If you continue to write in old legacy technologies, you will be in a box and your market will shrink. It depends on what you are doing and what you expect. There are a lot of DOS applications around, but I know of no one that writes them today! Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
can you explain this to me? What the heck does it matter if your code library is in a .NET PE or in a dll or in a .so or in COM or corba? I think the person who's post you answered is right. I've had to recompile C code for unix on linux that was written in the 80's on GCC, and all I had to change were the old style C declarations. I can still and do compile java code from JDK 1.1.8 on 1.5 with netbeans. All this stuff is bologna, it's another way to sell more books, and more IDE's and more stuff you don't really need. I'm through chasing the doggy's tail. Tell me one thing you can write a library for in .NET with IL wrapped metadata COM that you can't with regular WinAPI or MFC or Linux? Just one thing please? You can package any code as any type of reusable library, period. Sure .NET makes the code available to be linked by many languages, but that doesn't change the fact that you could do that with COM or Corba. These are the same old libraries we saw on Java and MFC repackaged as .NET IL code and labeled as "brand new" No thanks. I'm changing to linux, plus I can extend my java code into looking glass, which is actually something different on the Desktop for a change. Yes I run looking glass from the cvs on sun.com and yes I like it. I learned java before C++ many moons ago, and I never gave it up for MS's managed code, because I knew better. I was hoping they would extend the pillars of longhorn into normal C++ and MFC but they didn't and now they're cancelling the library all together. I think it's time for me to move on to something that doesn't change faster than I change my socks. I got burned on WFC a few years ago too, the msdn docs disappeared overnight on that one, it was like a great magician's disappearing act.
-
It's not being HIP.. It is not rewriting the software, it is NEW development. It is maintaining old code that take more work to keep up than to rewrite. If you continue to write in old legacy technologies, you will be in a box and your market will shrink. It depends on what you are doing and what you expect. There are a lot of DOS applications around, but I know of no one that writes them today! Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
You are focused on technologies too much, IMHO. The library I mentioned was not designed for Win 3.1 - it was designed to be portable. It was used in 16-bit Windows (some parts even on DOS, I suspect), then ported to Win32, OS/2, Mac, Linux, and currently it works on Windows 2000/XP machines and is mostly being used from a .NET WinForms application. And in couple of years WinForms will be a "legacy technology", but the old C++ mt library will still work with whatever is the technology of the day - unless discontinued for some non-technical reason, of course. I focus on the basics: data structures, algorithms, programming languages, development methodologies, project management. Technologies come and go, but the core knowledge remains. All this .NET vs MFC grunting makes no sense to me. I learn whatever technology I need for a particular task, and then forget it and learn a new one for the next task. Big deal.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
You are focused on technologies too much, IMHO. The library I mentioned was not designed for Win 3.1 - it was designed to be portable. It was used in 16-bit Windows (some parts even on DOS, I suspect), then ported to Win32, OS/2, Mac, Linux, and currently it works on Windows 2000/XP machines and is mostly being used from a .NET WinForms application. And in couple of years WinForms will be a "legacy technology", but the old C++ mt library will still work with whatever is the technology of the day - unless discontinued for some non-technical reason, of course. I focus on the basics: data structures, algorithms, programming languages, development methodologies, project management. Technologies come and go, but the core knowledge remains. All this .NET vs MFC grunting makes no sense to me. I learn whatever technology I need for a particular task, and then forget it and learn a new one for the next task. Big deal.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
I think we are still talking on the same plane, just different words. The program had to be "changed" ("Ported") to new technologies as it always will. You cannot use your old legacy system for ever nor do you build new development on it, the OS's change, IO changes and there will always be change. Code does not tie to one technology and go on living forever. Even in Fortran, there are new compilers and changes come and go and there will be a need to learn these new technologies. Even if you have application code generators that translate your code to new technologies, that generator has to change. There is no good forever code when technologies keep changing. From what I could read, the point of the thread was that the person did not like all the change. That they wanted to have a technology that would live forever. That will not happen no matter which platform is used. Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
-
can you explain this to me? What the heck does it matter if your code library is in a .NET PE or in a dll or in a .so or in COM or corba? I think the person who's post you answered is right. I've had to recompile C code for unix on linux that was written in the 80's on GCC, and all I had to change were the old style C declarations. I can still and do compile java code from JDK 1.1.8 on 1.5 with netbeans. All this stuff is bologna, it's another way to sell more books, and more IDE's and more stuff you don't really need. I'm through chasing the doggy's tail. Tell me one thing you can write a library for in .NET with IL wrapped metadata COM that you can't with regular WinAPI or MFC or Linux? Just one thing please? You can package any code as any type of reusable library, period. Sure .NET makes the code available to be linked by many languages, but that doesn't change the fact that you could do that with COM or Corba. These are the same old libraries we saw on Java and MFC repackaged as .NET IL code and labeled as "brand new" No thanks. I'm changing to linux, plus I can extend my java code into looking glass, which is actually something different on the Desktop for a change. Yes I run looking glass from the cvs on sun.com and yes I like it. I learned java before C++ many moons ago, and I never gave it up for MS's managed code, because I knew better. I was hoping they would extend the pillars of longhorn into normal C++ and MFC but they didn't and now they're cancelling the library all together. I think it's time for me to move on to something that doesn't change faster than I change my socks. I got burned on WFC a few years ago too, the msdn docs disappeared overnight on that one, it was like a great magician's disappearing act.
I can run programs and compile C++ code written in the 80's for DOS but that does not mean it has any value in today's world. You want to go to Linux, that is fine, I will be there writing .NET code in the near future myself, but that does not mean technology will stand still. Java is taken a lot of the development on Linux from the C++ roots. In the future there will probably be a battle of .NET and Java. Does not matter though as long as both remain a viable platform. C++ is on the fading end of things as companies care less about squeezing out the last cycle of performance for the sake of rapid development and maintenance. Things like OS's will probably remain in the C++ world but many of the applications are moving. Platform is not important. Technology that is currently available is not important. They will always change and developers will always have to change to stay viable. If all you know about .NET is that it was created to push books and make money, you did not learn much about .NET! Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
-
I think we are still talking on the same plane, just different words. The program had to be "changed" ("Ported") to new technologies as it always will. You cannot use your old legacy system for ever nor do you build new development on it, the OS's change, IO changes and there will always be change. Code does not tie to one technology and go on living forever. Even in Fortran, there are new compilers and changes come and go and there will be a need to learn these new technologies. Even if you have application code generators that translate your code to new technologies, that generator has to change. There is no good forever code when technologies keep changing. From what I could read, the point of the thread was that the person did not like all the change. That they wanted to have a technology that would live forever. That will not happen no matter which platform is used. Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
I think that Beer26 really hates the way technologies get "discontinued" rather than enabled to cooperate with the new ones, and if this is the case I agree with him. Many people have invested their time into learning and working with technologies like Visual J++ or VB6, or (like me) Managed Extensions for C++, and the way Microsoft just throws these technologies to trash instead of providing an upgrade path is irritating. However, Linux is even worse in this regard, and I hope he does not find it out the hard way :)
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-
Hear hear! I comletely second what you just said. I wouldn't go back to c++ / mfc from c# / winforms unless tortured very professionally.
John Cardinal wrote: I wouldn't go back to c++ / mfc from c# / winforms I used C++/MFC for several years, and since I wrote my first line of C#, I haven't gone back. Development in C#/.NET is really so much faster, that really now using MFC has no advantage (maybe performance? it's argueable but still, who cares if a bubble sort takes 0.1 or 0.5 seconds?) MFC is definitely not dead, there are many apps still using it and it will be around for *at least* 5 to 7 years more (adding that to the 12 years old it is already since it came out with MS C++ 7.0 in 1992). But for new projects, why start with old technollogies? use the new ones, learn them, you may actually like them! :) -- LuisR
Luis Alonso Ramos Intelectix - Chihuahua, Mexico Not much here: My CP Blog!
-
I think that Beer26 really hates the way technologies get "discontinued" rather than enabled to cooperate with the new ones, and if this is the case I agree with him. Many people have invested their time into learning and working with technologies like Visual J++ or VB6, or (like me) Managed Extensions for C++, and the way Microsoft just throws these technologies to trash instead of providing an upgrade path is irritating. However, Linux is even worse in this regard, and I hope he does not find it out the hard way :)
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
Yeah, been there.. Over the last 20 years I have been a programmer, there have been a lot of technologies and platforms. Many seem to "try" new technologies hoping to make them float ("OLE anyone") but at the end of the day it is all a turkey shoot as to which will survive. I remember when Borland dumped it's C++ development (practically, their compilers become garbage) and decided Delphi was everything a person needed, pushing it down the throats of all us developers. So much for all the learning of OWL. Microsoft was busy pushing VB on everyone but at least had enough sense to keep the C++ development tools. Now .NET is making waves for many reasons, but on is that you are not language dependant, you can use multple programming languages to build a single app, in the same assembly. At least that is one road block out of the way. You can still use C++, C#, VB.NET, Fortan.NET, and a host of other languages to build a single application. Rocky <>< www.HintsAndTips.com - RSS Enabled www.JokesTricksAndStuff.com www.MyQuickPoll.com Me Blogs: wdevs - MSN Spaces (new)
-
marc i know ur a very experienced developer and all but really ... keep it real please ... im by no means a linux guru but i can set up a dual-boot machine with dev environments for both windows and debian/linux in maybe 5hrs (with a decent internet connection) sure developing for linux isnt as easy as windows with its single api (well it DID have a single api hmmmmmmmm) but it is here to stay and its future development isnt driven by the need to make ever more profits (like ms is) linux is becoming a very serious threat to ms and they know it so i would suggest that all smart developers with more than a few years of working life ahead of them get at least familiar with linux as well as windows
Well said. But at the same time, if you are writing with MFC, it suggests you are going GUI apps, and guess where the majority of GUI apps run. Where I work, the servers run on Linux & Solaris, and the GUI's run on Windows 2000. And its going to stay that way. The only deviation may be in a switch from some of Stingrays libs to someone elses, though we'll stick with the grid, which is the best out there. We have too much code in C++, and so will not be bothering to switch to managed with the hassle of having mixed managed and unmanged. Why make life difficult. And managed GUI's are slooooooow. They are fine for some VB style flat client/db interface, but when you have a large number of clients listening to distributed real time data coming in, you need something quicker.
-
would IBM and sun be among them? just kidding. I get your point, it's costly, but I'd rather go this route and have lasting extensible code for my own development needs. I know this may not work for everybody and I'm not saying it should. The dropping of MFC was the final straw for me though.
How the hell do you think you will ever have lasting code? Come on. Get realistic. You think the STL C++ stuff you develop for Linux an the GUI's you will develop too will still work on the latest greatest SuSE, Debian, Mandrake, RedHat etc etc etc in 5 or 6 years.... :laugh::laugh::laugh::laugh::laugh: Regards, Brian Dela :-) Now Bloging![^]
