WTL - What's All The Fuss About?
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Code Bloat - That is a valid reason. Just because you don't think so doesn't mean it isn't. Faster - Yes. Not as much UI crap in there. WTL tends to be more lightweight. Reliable - No, I can't really say this. Alongside MFC - Yes More Versitle - I am able to do more with WTL than MFC. The more you vary from MFC's design the harder it is to get it to do what you need. The DOC/VIEW stuff isn't in WTL. Updated UI - Well, not that important now since MFC7. But WTL had the new UI before MFC. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
Code Bloat - That is a valid reason. Just because you don't think so doesn't mean it isn't. Faster - Yes. Not as much UI crap in there. WTL tends to be more lightweight. Reliable - No, I can't really say this. Alongside MFC - Yes More Versitle - I am able to do more with WTL than MFC. The more you vary from MFC's design the harder it is to get it to do what you need. The DOC/VIEW stuff isn't in WTL. Updated UI - Well, not that important now since MFC7. But WTL had the new UI before MFC. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
I'll agree code bloat is a valid factor. There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped.
-
I'll agree code bloat is a valid factor. There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped.
Mark Nischalke wrote: There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped. Actually, if you link to MFC statically, you don't have to ship the DLL's either. Static linking is the way to go, man - I like a neat, self-contained app that doesn't have to pollute the system with mfc42.dll, msvcrt.dll, etc. No generalization is 100% true. Not even this one.
-
Mark Nischalke wrote: There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped. Actually, if you link to MFC statically, you don't have to ship the DLL's either. Static linking is the way to go, man - I like a neat, self-contained app that doesn't have to pollute the system with mfc42.dll, msvcrt.dll, etc. No generalization is 100% true. Not even this one.
But it drastically increases the size. Would you rather download 3MB or 300k?
-
But it drastically increases the size. Would you rather download 3MB or 300k?
If you're distributing on CD, not having to worry about version incompatiblity is worth the extra size. A problem arises however when you need to use multiple MFC DLLs along with your program... --------_**
I don't think that I'm a sell-out but I do "Enjoy Coke!"...
**_
-- Bloodhound Gang, The Inevitable Return Of The Great White Dope
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
What is the big deal about WTL? It' could have been a next-generation desktop framework for Windows, were Microsoft interested in such a thing. What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) Nothing, really; it is better from an architectural standpoint, in that makes use of more modern programming paradigms, in particular, templates. This makes multiple inheritance simpler. What doesn't it do that MFC does? A lot. There is no doc/view architecture, or in fact any soft of high-level app framework. Are the various app/class wizards still available? Heh. Nothing of much use. No class wizard at all, not even the pathetic thing foind in VC7. You're totally on you won for adding new members. And since there is no documentation, this usuall means going back to the WTL source and unraveling the message macros for every member function you want to add. Does it make development faster? Not at all; it's about 3 timne slower. See above. Are your apps faster? They should be, but i don't know; I only built a smallish test app before giving up. Are your apps more reliable? No reason they should be. What's the point of the library? It seems to be a pet project of someone at MS who did not like MFC. Can it be used *with/alongside* MFC? Nope. Why should I consider using it? Got me.
-
I'll agree code bloat is a valid factor. There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped.
Mark Nischalke wrote: There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped. Umm.. MFC doesn't require that MFC DLL's be shipped, either. That's an urban legend promoted by the early MFC team. Link statically.
-
Code Bloat - That is a valid reason. Just because you don't think so doesn't mean it isn't. Faster - Yes. Not as much UI crap in there. WTL tends to be more lightweight. Reliable - No, I can't really say this. Alongside MFC - Yes More Versitle - I am able to do more with WTL than MFC. The more you vary from MFC's design the harder it is to get it to do what you need. The DOC/VIEW stuff isn't in WTL. Updated UI - Well, not that important now since MFC7. But WTL had the new UI before MFC. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Honestly, code bloat? Gimme a break here. Do two apps in class wizard using MFC statically linked of each type described below, and then do the same two apps just using WTL with all the required code compiled into the executable (no DLL's). 1) A simple dialog-based app. 2) A simple MDI application that doc/view, a toolbar, and statusbar. The app doesn't have to do anything other than what the MFC app wizard gives you. How much difference in executable size do you really expect (or realize)? In my experience, the code starts to grow when you start adding things like MFC's collection classes and such. More often than not, code grows primarily due to non-MFC UI related (core) app-specific code. What "new UI" are you talking about, the XP bubble interface? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
I'll agree code bloat is a valid factor. There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped.
-
Mark Nischalke wrote: There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped. Umm.. MFC doesn't require that MFC DLL's be shipped, either. That's an urban legend promoted by the early MFC team. Link statically.
But the dll's must be present (and the correct version). If they are not the app won't work so you must distribute them or statically link. Again increasing the size of the app or the distribution or both.
-
But it drastically increases the size. Would you rather download 3MB or 300k?
I statically link MFC and I use the MFC collection classes, and I ship three separate executables that are each about 250k in release mode. It zips down quite nicely, too (a little less than 400k). "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
John Simmons / outlaw programmer wrote: What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) I like it because it is a small a light weight frame-work that is very close to the SDK. I especially like the use of template. One of the things that templates gives is something called simulated-dynamic binding, or virtual binding, I am able to change the root class implementation of a fundemental part of the framwwork by just changing a template arguement. This task is not so simple in MFC or C++ with out templates for that matter. Especially if you want to change something at the root of the MFC framework, you will need to build a completely new MFC dll and distribute that. In WTL, all of the code is built into your EXE. There is a lot less code to wade through if you want to figure out how something is done. There are only about 25 header files if you include the code from ATL. There is a default template for the multi-threaded SDI program that models the new document-centric model that microsoft has taken with their office products. Where each new document in a single word program gets its own top level window. I am not sure if MFC has this yet. John Simmons / outlaw programmer wrote: What doesn't it do that MFC does? It creates a framework for message handling including pretranslate message. It does dialog data transfer, ui update. It wraps all of the standard and common controls in a very shallow manner. It provides the ability for an MRU list. Basically every thing that you need in order to do basic windows programming with all of the window objects. John Simmons / outlaw programmer wrote: Are the various app/class wizards still available? I believe that you can still use the class wizard to create classes and things like that, but you do not have a wizard to insert new message handlers and things like that, you still have to do that manually. John Simmons / outlaw programmer wrote: Does it make development faster? I think that depends on how well you know either tool. I also think that it depends on what you are trying to do. If you are doing basic windows development I think that it is teh same. If you are doing something that MFC has already written a class for that you don't have it may be slower. There are somethings that WTL will make faster. Like I mentioned earlier
-
But the dll's must be present (and the correct version). If they are not the app won't work so you must distribute them or statically link. Again increasing the size of the app or the distribution or both.
You really should do a little research. If you statically link with MFC, you DO NOT need the DLL's AT ALL, and the application will IGNORE the DLL's that exist on your system. Even better, your app will function fine even if an older or newer version of the DLL's exist on your system. "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
What is the big deal about WTL? It' could have been a next-generation desktop framework for Windows, were Microsoft interested in such a thing. What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) Nothing, really; it is better from an architectural standpoint, in that makes use of more modern programming paradigms, in particular, templates. This makes multiple inheritance simpler. What doesn't it do that MFC does? A lot. There is no doc/view architecture, or in fact any soft of high-level app framework. Are the various app/class wizards still available? Heh. Nothing of much use. No class wizard at all, not even the pathetic thing foind in VC7. You're totally on you won for adding new members. And since there is no documentation, this usuall means going back to the WTL source and unraveling the message macros for every member function you want to add. Does it make development faster? Not at all; it's about 3 timne slower. See above. Are your apps faster? They should be, but i don't know; I only built a smallish test app before giving up. Are your apps more reliable? No reason they should be. What's the point of the library? It seems to be a pet project of someone at MS who did not like MFC. Can it be used *with/alongside* MFC? Nope. Why should I consider using it? Got me.
It doesn't take 3 times the amount of time to create a WTL application. The only time that really comes into play is when you have to re-invent a feature in MFC that isn't in WTL. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Er, "code bloat" is just about the most important reason. I have re-written one of my MFC apps (a GUI form designer) in WTL and it is has shrunk from 1.5MB to less than 500KB. My users are VERY happy and the application is just as functional. Why is "code bloat" not considered a valid response? In order to ensure our MFC apps run on any Windows platform correctly, we have to statically link with MFC - this creates HUGE EXEs - this is a bad thing IMHO. What does it do that MFC doesn't? Not much, apart from being simpler hence much easier to understand. This may not be an issue for many people, but personally, I like to know how the framework I am using fits together, and MFC is getting complicated under the hood. WTL apps actually have a WinMain! The message maps are easier to follow, etc. I think that over the years, MFC has gotten too big and too complicated. Keeping It Simple has got to be a good thing surely? I am using WTL7 with VS.NET - I don't have full ClassWizard support, but I can add message map handlers, etc. Yes, VS.NET could do with more WTL support, but it has basic enough support. Faster development? Well, there is a learning curve like any new framework. I have been using MFC since 1995 and I consider myself very productive using it - WTL has taken a little getting used to (mainly the C++ template side of things) but I now use it for all new projects. I have been using it now on and off for about 4 months and would say I am almost at the MFC productivity level. Faster apps? I cannot tell yet, but I will be re-writing a critical app using WTL this summer which will be the acid test for memory usage and speed... More reliable? Being a simpler framework, I am inclined to think so but that really depends on the programmer doesn't it? However, as WTL resides in a dozen or so header files (no LIBs!!) then any bugs that do exist (in the library) are easily fixed. In-house we keep a copy of WTL on CVS - this will allow us to apply fixes, etc. easily. This would be hard to do with MFC. I am going off at a tangent here, but perhaps in the future people will also be able to use WTL with non-MS compilers (there is a Watcom fan club here at my company - in fact, as an MS compiler user I am in a minority!!!) Can it be used with MFC? I can't see much point in doing this, but as WTL is really "ATL with a UI", then I guess it could be done. Many WTL classes use the same names as MFC, which may be problematic, though I guess namespaces could help here. Why should you consider
-
You really should do a little research. If you statically link with MFC, you DO NOT need the DLL's AT ALL, and the application will IGNORE the DLL's that exist on your system. Even better, your app will function fine even if an older or newer version of the DLL's exist on your system. "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
This is getting out of hand. Yes if you statically link you don't need them but if you dynamically link you do. I have distributed apps that were broken by incorrect versions of dll's as I'm sure you and most others have. 'nough said
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Test case was a do nothing dialog app (i.e. Just click through the wizard and compile in release) MFC Statically linked: 200kb ATL: 32kb
-
Honestly, code bloat? Gimme a break here. Do two apps in class wizard using MFC statically linked of each type described below, and then do the same two apps just using WTL with all the required code compiled into the executable (no DLL's). 1) A simple dialog-based app. 2) A simple MDI application that doc/view, a toolbar, and statusbar. The app doesn't have to do anything other than what the MFC app wizard gives you. How much difference in executable size do you really expect (or realize)? In my experience, the code starts to grow when you start adding things like MFC's collection classes and such. More often than not, code grows primarily due to non-MFC UI related (core) app-specific code. What "new UI" are you talking about, the XP bubble interface? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Shrug. Is this a good example John? None of the above apps really does anything, so I expect both to be small. From personal experience, WTL generates smaller apps. One big problem I have had with MFC in the past is getting a COM Automation interface working correctly with an SDI/MDI app - all sorts of gotchas when calling it from VB, etc. In the past I have gone to great lengths to get ATL support working with it (Nick Hodapp wrote a legendary article about this years ago) - with WTL however, it is a breeze. COM in general is much easier with ATL/WTL.
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
I have not yet used WTL in a real application because of the following reasons: Very little or no documentation, known bugs, no doc / view, limited classwizard support, most of the code available is MFC and will have to be rewritten for WTL, and MS does not officially support it and they may pull it at any time. After saying all this, I may still use WTL in my next project because I develop all my applications multithreaded and the design of MFC's doc/view forces you to create all views in the main thread otherwise you will get into a lot of trouble. John
