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 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
-
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.
Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? The AppWizard-generated MFC code in that form would compile to about 200k using VC6. How big would it be using just WTL (and the Windows API of course)? As far as COM goes, I've never had a problem with using it in an MFC app. COM in and of itself is diffcult to work with and is WAY over-used, but that's a different topic. I will concede that there are times when an application has to be as thin as possible in both memory and disk footprint (especially embedded code), but for a normal desktop app with possibly hundreds or thousands of features, is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? "...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 can honestly say that I have NEVER had an app break because of errant MFC DLLs because I *always* statically link. The MFC42.DLL is 973k. Why in the world would I want to ship that with my app? I guess I'm just too unsophisticated to be drawn into all of Microsoft's newest whiz-bang technologies. "...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
John M. Drescher wrote: MS does not officially support it and they may pull it at any time. There have been very few changes to WTL since its initial version 3.0 release except a few bug fixes, a dynamic dialog resizing class and a few other features. So even if Microsoft pulls WTL the 16 header files that make it up still exist and provide an awesome framework for developing low overhead applications, you don't need much more than that to use WTL. I would like some documentation on it to make looking up function signatures a little easier but it is still a very viable solution for developing applications.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
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
One more thing that I forbot to mention that is an advantage for WTL, is that it is based on ATL which was designed from teh ground up to support COM. COM had to be Shoe-horned into MFC and is in many ways very clumsy to deal with, although it works. COM support in WTL is simply more natural.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? The AppWizard-generated MFC code in that form would compile to about 200k using VC6. How big would it be using just WTL (and the Windows API of course)? As far as COM goes, I've never had a problem with using it in an MFC app. COM in and of itself is diffcult to work with and is WAY over-used, but that's a different topic. I will concede that there are times when an application has to be as thin as possible in both memory and disk footprint (especially embedded code), but for a normal desktop app with possibly hundreds or thousands of features, is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? "...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: Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? WTL comes with an app wizard to create the generic MDI, SDI, multi-threaded SDI, or dialog based apps with a view, toolbar support with the possible use of command bars and rebars, status bars, contain activeX controls and what not. But in WTL's case I think that it would only take about 4 minutes to create both apps :)
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
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?
Tim Smith wrote: 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. I would like to comment on this. MFC has a generic way of doing things, that it assumes all developers want to develop their app the same way. WTL is straight application development. There is no assumption in the way that you are going to develop your app. So Tim is right in the fact that the more your app deviates from the generic windows app that MFC is designed for, the more difficult it will be for you to develop your app. This is not an issue with WTL.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? The AppWizard-generated MFC code in that form would compile to about 200k using VC6. How big would it be using just WTL (and the Windows API of course)? As far as COM goes, I've never had a problem with using it in an MFC app. COM in and of itself is diffcult to work with and is WAY over-used, but that's a different topic. I will concede that there are times when an application has to be as thin as possible in both memory and disk footprint (especially embedded code), but for a normal desktop app with possibly hundreds or thousands of features, is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? "...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.
It takes the same amount of time. I use the WTL AppWizard. The WTL versions of both examples are smaller. The WTL code, IMHO, is easier to follow. This is a no-brainer surely? If you haven't had problems with COM and MFC then you are a lucky man! It has caused me no-end of problems. I agree it is over-used and probably needs killing off, but some of our customers demand it for various reasons. is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? In my opinion - yes! The WTL AppWizard already exists, and I am getting along fine using VS.NET with WTL. Now I am familiar with the framework, I am writing smaller apps in much the same time as I can with MFC -this has got to be a good thing. I will concede that there is a LOT of good MFC code that I couldn't use without doing a WTL conversion - but, in reality, most MFC classes can be made to work with WTL very easily indeed. It isn't rocket science converting most classes - MFC is a pretty thin wrapper around Win32 in many places. I am building up a veritable library of WTL classes - perhaps I'll even post some soon ... :) Don't get me wrong - I love MFC, but I think it has reached the end of its life. Let's face it, there isn't going to me an MFC8 is there? Look how ATL came about - people wanted a framework to allow them to write small COM objects without the bulk of MFC. WTL is the same for UI apps. If anything, WTL is the future for C++ GUI development under Windows (I sure ain't in any hurry to learn C# and jump on that particular bandwagon!). I think MS are surprised at how popular WTL is getting, so I think its future is rosy (and being a light framework consisting of a bunch of header files, even if MS do drop it, someone else will pick it up and move it forward!).
-
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
John M. Drescher wrote: Very little or no documentation This situation is improving. There are many sample programs out there that demonstrate all of the available classes. Here are some handy links: http://www.viksoe.dk/wtl/ http://wtl.50megs.com/wtl.htm http://groups.yahoo.com/group/wtl/ Large chunks of WTL use the same class names and method names as MFC (the GDI classes, control classes, etc.). Picking it up is easy once you have a few samples, and the source is very easy to follow. I was cautious too at the beginning - but I played with WTL in my spare time, wrote a few small test apps, and now I am a total convert (as you have no doubt noticed!). John M. Drescher wrote: known bugs Hardly an issue, especially now WTL7 is out. Besides, to apply a bugfix you simply change the appropriate WTL header file - with MFC you need to wait for a service pack! John M. Drescher wrote: no doc / view I came across this "problem" - then I looked at the MFC source for CDocument/CView and realised there isn't much to it. In fact, I think there is a basic WTL doc/view framework available on CodeProject! I can see why this may be cause for concern, but depending on the application, this is not necessarily a big issue. John M. Drescher wrote: limited classwizard support True, though VS.NET goes further and improves this slightly. John M. Drescher wrote: most of the code available is MFC and will have to be rewritten for WTL Probably the main reason more people aren't flocking to use WTL. However, my experience has shown me that it isn't difficult to convert most MFC classes. There are also plenty of "MFC" classes that rely on little more MFC support than CString and/or CWnd - both of which can be duplicated with WTL code easily enough. Besides, as the library grows in popularity, so will the available codebase. John M. Drescher wrote: MS does not officially support it and they may pull it at any time And how exactly does MS "support" MFC? By posting the odd sample on MSDN? MFC is dying - and I believe that any future C++ GUI framework will be more like WTL than MFC. If there is an MFC8 then I will be very surprised (unless it is a bugfix service release ;)). The chances of MS pulling WTL are slim - there are many users now, and because the framework is lightweight, it would be picked up by an eager
-
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
John M. Drescher wrote: 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. MFC is indeed a bitch when you are doing multithreaded GUI development, but it is possible. ED for Windows (see sig) makes extensive use of multithreading, and operations like Find/Replace in Files use multiple threads and create doc/views from those threads. One day when I have some time I really need to write an article or two. Neville Franks, Author of ED for Windows. www.getsoft.com
-
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.
WTL's greatest strength, from an architectural standpoint, is that it mixes extremely well with the current C++ standard and with ATL. It is hard to compare it directly to MFC, because MFC is a kitchen-sink framework and tries to tackle areas as diverse as COM, HTTP, file handling and database support as well as UI support. WTL is almost completely focused on UI classes only. For someone who's been immersed in MFC for a while and used to it, it probably doesn't look that bad, but MFC has collections, RTTI and exception handling that have all been superseded by the '96 C++ standard. Also, MFC's most egregious flaw is the six- or seven-level-deep inheritance hierarchies that cause so much trouble for new (and old) developers. The C++ community has long since abandoned such thinking as bad practice (and for good reason). WTL makes a clean break from the MFC style by advocating the ATL mixin style of multiple inheritance. Consequently, if you're doing a standard dialog/view, you derive your classes from CDialogImpl. If you want to mixin scrolling support, then you also inherit from CScrollImpl. For dialog resizing support, mixin CDialogResize. The same goes for DDX/DDV support, splitters, printing and idle handling, to name a few. I find it much easier to guide my junior developers toward current C++ best practices under WTL than with MFC. I also find it much better to point developers toward a current C++ book to handle their questions on collections, file handling and exceptions than to explain the clunky MFC approaches. As was mentioned by someone else, WTL is built on top of ATL, so using ATL's COM support is natural. For those projects that require lightweight COM, integrating ATL and WTL is painless. MFC and WTL/ATL are much better integrated in VS.NET than in VS6. There were several posts on the WTL newsgroup about integrating MFC with the old WTL 3.1, but in most cases, the integration wasn't straightforward. When you understand what WTL does well (lightweight up-to-date UI's with a modern C++ approach) and that it's not trying to replace MFC, then it's easier to evaluate it on those merits. What WTL does tackle, it certainly does better. Brandon The WTL newsgroup: over 1400 members! Be a part of it. http://groups.yahoo.com/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.
What does it do that MFC doesn't do? Hmmmm Microsoft does not support using MFC in a printer driver. At my last job, we added WTL 3.1 to a printer driver without a problem. I believe that the driver has been released to customers now. At WinHEC2000, one of the big points the Paul Yao was trying to make was to not use MFC in a printer driver, even tho alot of people weer asking questions on how to do that. I talked to him and showed him WTL and he was very interested in WTL as a nice alternative. What doesn't it do that MFC does? Yes, there are a few things that MFC does and has that WTL doesn't. WTL is not a silver bullet for programming, just a nice tool that should be used to its maximum potential. Can it be used *with/alongside* MFC? Well I have written example programs that do use WTL adn MFC side-by-side, so yes it can be done. Why should I consider using it? Well its all up to you whether to use it or not. Even Microsoft has posted jobs with WTL as a skill they were looking for. If for no other reason its a new framework that makes you a better programmer. Kinda like learning Java when you already know VC++. I have been using WTL since it came out. It has grown since its start and has filled a nice gap that MFC leaves. What gap??? Well the shareware developer that has limited webspace and needs exes to be smaller. I think we can all agree that a WTL app is smaller compared to a MFC statically linked app. WTL COULD also be ported to other platforms since the source is all right there. Now, the legalities of that are a different story. I use WTL for my shareware, for commercial products, I used it in a small app that Kodak distributed for a problem with their cameras in WinME, and I use it in the games that I write. For games, you get the low overhead of the SDK instead of the slowdown of MFC. Most game makers will laugh at the use of MFC in their games for this reason. WTL is nice and fast for making games and I get MOST of the functionality of MFC with it. You ask why you should consider using it, and I ask why should you not look into it further. It has been a nice topic of discussion on interviews too. Most managers don't know what it is and you can then educate them. Steve Maier, MCSD
-
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'd be surprised at how little the size of the app increases without static linking; but frankly, who cares, once the app gets up beyond some minimum size? (My current app is running at about 5 meg, thanks to graphics.) The linker is good at throwing out unused code. And the distribution size actually will go down when you static link, rather than up; becasue you're usually only including a few hundred K of MFC code, rather than the 1 Meg+ required by the DLLs.
-
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.
(Note... Consider all of my responses to have IMHO, or IME in front of them!) -------- What does it do that MFC doesn't do? It does not require the MFC DLLs, but apps that use ATL may require more COM DLL dependencies than your average vanilla MFC app. It also stresses the compiler when it comes to templates. (Anyone been using ATL long enough to remember having to play around with
#includefile order to get around Internal Compiler Errors?) Another thing to consider is that ATL/WTL code is all template-based, and on non-trivial GUI projects (like writing an IDE), all that expanded code can bloat the app a bit. Also, when using MFC, classes likeCEditnormall sit in a MFC DLL. If you do not create unnecessaryCEdit-derived objects for every single edit control in your application, you can take advantage of that, and reduce your app's size. And lastly, be careful when others talk about "Code Bloat", and do not know if that really means the size of the app itself, and/or it's footprint, and/or the size of it's dependencies! What doesn't it do that MFC does? MFC-style Doc/View (it does have Views, however), and maybe a few minor things here and there (although there are many people out there that seem happy as hell to reinvent various parts of that wheel using ATL/WTL). It still does not really have official support (the WTL files and docs are still provided "as-is"). Are the various app/class wizards still available? An Appwizard is available, but there is no native ClassWizard-like support for things like associating a dialog resource with aCDialogResize-based class (at least, not that I am aware of). Does it make development faster? Depends on what you are more familiar with. For Example: can I create a CDialog-based class faster using ClassWizard (VC6.0) than using WTL? Yes. Are your apps faster? I have no real data either way. Are your apps more reliable? I have no reason to think yes or no, but bear in mind that ATL/WTL does not have as much testing or evolution behind it as MFC does. What's -
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's possibly the coolest, most flexible way to write a Windows app. What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) 1. Reduces Code Bloat. A WTL app will typically be 1/10th (or less) the size of an MFC app. For example, my fully fledged data plotting app that I wrote to analyze data from the Mass Spectrometer I'm writing control software for at work is 148kb in size. That's with the C runtime statically linked into it. It's not bad at all. 2. (My personal favorite reason), it uses assembly language thunks to map WNDPROCs to objects, unlike MFC which uses a Map to map pointers to classes. Not only does this make your code much more efficient if you're using a lot of windows in your app, but it makes the implementation of a window class MUCH more obvious. For example, you don't need to handle precreate messages in a special way; you just handle the WM_NCCREATE message. What doesn't it do that MFC does? 1. It doesn't lock you into a framework that you have to shoehorn your app design into. You can freely architect your application, with very few limitations. In the right hands, this is a good thing. In the wrong hands... well... go figure. Either way, it gives you the power to make that decision for yourself. 2. (Note: this applies to WTL/ATL3.1 only; I've not had chance to examine the 7.0 stuff) No file wrappers. No structured storage wrappers. This may or may not be a problem for you. Later versions have CString classes, etc. 3. No real classwizard / resource handler support in the system (although it does some things the same way as MFC). This is both a benefit and a curse; I hate the way MFC tramples all over resource files. 4. It doesn't get officially supported by Microsoft. I have the feeling that this may change eventually. 5. It doesn't put all those stupid AFX headers in every file you write. That's a big plus for me. Are the various app/class wizards still available? To an extent. You actually use those things? The mind boggles. Does it make development faster? Hell yes. I managed to put together an app in two weeks that would have taken several months previously. Oh, you meant vs. MFC, not vs. raw Win32? Oh, ok. It depends. If you're using MFC the way MFC was designed to be used, you'll Are your apps faster? It depends on the application domain. I'll say yes, with a caveat; namely, it depends on how you define "faster". Are your apps mor
-
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
Test case was a do nothing dialog app (i.e. Just click through the wizard and compile in release) MFC Statically linked: 200kb WTL: 32kb And if you don't mind your app only running on NT4.0, Win2K or XP and up... then you can set the /ALIGN parameter on the linker to 16 bytes (IIRC), and get that down to: MFC Statically Linked: ~200kb WTL: 15kb. :-) Of course... you probably don't want to do that in production code. But hey, I kind of like having my console apps ~2kb in size :) Si
