WTL vs System.WinForms?
Jefferson Liu
Walter Sullivan [MSFT]
enhancements fixed here and there but no integration with tools and Wizards
in VC. Its one of many possible directions we could go in future releases of
VC for unmanaged C++ libraries, but with the very large number of MFC users
and codebases out there, it probably wouldn't ship in VC in its current
form.
After we decided to release it as-is in the Platform SDK, there have never
been any plans to support it in VC7 (or VC.NET if you prefer that naming
convention...;^) ).
Thanks,
Walter Sullivan
Lead Program Manager, ATL/MFC
"Jefferson Liu" <jeffer...@hotmail.com> wrote in message
news:OrNOhIGoAHA.1092@tkmsftngp03...
User
Windows libraries.
No good developers like MFC. Even Microsoft does not use it for its
own applications. (And no, just because someone is using CString does
not mean they are using MFC for building applications.) It's brain dead
for anything other than very simple projects.
Why wouldn't you want to support WTL? If I don't want to switch to
buggy C# right now what choices do I have now other than MFC.
BTW, to design a really good OO Windows library there has to be
support for OO languages in Win32. You can't even have a normal
C++ class that implements a windows without doing some stupid hack
on class pointers. Can you imagine a Win32 that you could easily tie to
a C++ class - that would be too much for MS to do :-). I mean they
only had years and years to come up with a feature like that.
"Walter Sullivan [MSFT]" <wal...@microsoft.com> wrote in message
news:uGzZkb4oAHA.1752@tkmsftngp03...
Walter Sullivan (MSFT)
There are several major Microsoft applications built using MFC (more than
just CString). FrontPage, Visio, Money, Publisher, Works, Encarta, VC1.0-6.0
IDE's, are just a few that spring to mind. Eudora Pro, Netscape Navigator
(through version 4 at least), WordPerfect, IBM ViaVoice, Act!, PeachTree are
just a few major external apps built using MFC that spring to mind. I could
enumerate dozens of others both inside and outside of Microsoft if I had the
time.
I don't disagree with your observations necessarily, but there is a
misconception which just isn't true. There are some very significant and
complex applications built with MFC and the fact that people can still be
productive with it 10 years after it was designed is quite remarkable in
Computer Science terms. You do raise some valid concerns, all of which we've
discussed at length for a long time.
MFC is not, and wasn't meant to be, a demostration of good object oriented
library design. It was specifically designed to make the Windows API more
natural to a C++ programmer. The goals of WTL and ATL for that matter
weren't to demonstrate good object oriented library design, they both are
intended to be useful and productive tools for the C++ developer. Intended
not to abstract away so much of the underlying technology that when you had
to drop down to the OS, you didn't feel lost. And for those programmer's
used to programming primarily at the Win32 API level, the class libraries
would be approachable without having to learn a completely new programming
model.
The Windows API has to be accessible to many more languages than just C++,
or other object oriented laguages, so this is likely the main reason we
haven't been more aggressive in pursuing a completely new API. However,
since there are probably 150 different teams, and 2000 individual developers
producing the collection of API that Microsoft exposes, I'm really
speculating. There isn't a corporate mandate on how to expose your
technology. Every group is trusted to do it in the most reasonable and
efficient way for their target customers.
WTL, which was created by the same team producing MFC and ATL, is a very
interesting technology and we'll be evaluating what to do with it in future
VC++ releases as I've mentioned before. I'm really happy you're finding it a
good alternative for your C++ development, that's helpful for us to think
about when we are looking at product plans for future versions.
Walter Sullivan
Program Manager, ATL/MFC
"User" <zura...@syrres.com> wrote in message
news:uixBF88sAHA.1284@tkmsftngp05...
Jim Wasson
C/C++ developer and have used MFC extensively along with ATL and WTL. (Only
a little WTL because its official status is "unsupported"). I think that
WTL was a very interesting release and I liked where it was going a lot. It
was a potentially real alternative to MFC. Granted MFC is good for building
GUI-based apps, but its architecture doesn't work well for apps that aren't
document-centric. WTL and ATL-based apps were just beginning to open the
"application framework" up for "other" types of applications such as near
real-time and control type applications. For many developers, MFC is "the"
application framework so it often gets used where it's not appropriate
leading to frustration, bloated apps and unnecessary development problems
That's because you have to tweak it so much to do what you need to do, and
messing with something as large as MFC can get problematic very fast.. I
have seen serial port drivers (not the low-level DDK stuff) that were
implemented as MFC apps, and to me, that isn't appropriate at all. I don't
mean to complain, I have gotten a lot of mileage out of MFC. But I know
that Microsoft can do better -- and by better, I mean can provide many good
alternatives. I saw ATL as one and WTL was (and still is) very promising,
too.
"Walter Sullivan (MSFT)" <wal...@microsoft.com> wrote in message
news:emFQMf$sAHA.1456@tkmsftngp04...
> ...snip for brevity...
Eamonn Wallace
news:emFQMf$sAHA.1456@tkmsftngp04...
> WTL, which was created by the same team producing MFC and ATL, is a very
> interesting technology and we'll be evaluating what to do with it in
future
> VC++ releases as I've mentioned before. I'm really happy you're finding it
a
> good alternative for your C++ development, that's helpful for us to think
> about when we are looking at product plans for future versions.
Personally everybody I have introduced to WTL loves it...
I use it for most of my dev work...
I only recently switched to VC from BCB and I hated MFC with
a vengeance<g>
WTL is excellent for the things I want to do, long may it continue...
--
ewallace@europe.<thisbitgoes>com
Eamonn Wallace
Steve Maillet
days... I just don't have the time to dig into it like I did back then...
--
Steve Maillet
Entelechy Software Consulting
smaillet 'AT' EntelechyConsulting 'DOT' com
http://www.EntelechyConsulting.com
"Eamonn Wallace" <eamonnwa@indigo.[thisbitgoes].ie> wrote in message
news:em5oelTtAHA.1736@tkmsftngp04...
Ryan Park
So do you think WTL is good enough to be used in real product
which released to customers?
Recently I'm looking for a good substitution for MFC.
And found WTL. Now I'm planning to port my project to WTL.
Of cause I also prefer WTL cause its source code is much
more readable than MFC's. (I'm rather familiar to ATL.)
But I'm hesitating cause it's not supported by MS.
And there are little document on it.
Do you really recommend me to port to WTL?
Regards,
Ryan
Walter Sullivan (MSFT)
application in Windows ME is written with WTL. There are other pieces of
Windows XP that use WTL and probably stuff I'm not familiar with.
It depends on the amount of maintenance you (or your company) want to take
on yourself. If you want SP's, support from PSS, compatibility in future
versions of VC, that kind of thing, then WTL probably isn't a good choice.
There are plenty of people to help answer questions on codeproject.com, WTL
mailing list on yahoogroups.com and other places. So if you're willing to
consider WTL just part of your own codebase then the likelihood that you'll
get completely stuck on a problem you can't solve seems reasonably low.
Walter Sullivan
Lead Program Manager, ATL/MFC
"Ryan Park" <ba...@intizen.com> wrote in message
news:OyLeU1xtAHA.504@tkmsftngp05...
Ryan Park
Thanks for the info.
I personally decided to try after reading your post.
As I've been heard that one of team in MS uses WTL,
I think there is no reason to avoid it.
Soon I would say "We decided to use WTL", now I'm collecting
information on WTL to persuade my colleagues.
Can you or anybody recommend some good resources for WTL?
TIA.
Regards,
Ryan
Eamonn Wallace
We have used WTL in commercial apps and it works fine.
We did side by side dev on an app in the early stages of the design
and the MFC version clocked in about 1.5MBs, the WTL version clocks in at
200k.
While in these days of massive hard disks program sizes may not be a problem
as such. It is however nice when a full app weighs in at 200k though:-)
--
ewallace@europe.<thisbitgoes>com
Eamonn Wallace
"Ryan Park" <ba...@intizen.com> wrote in message
news:OwvPxB3tAHA.2332@tkmsftngp05...
Neil Hodgson
> We have used WTL in commercial apps and it works fine.
> We did side by side dev on an app in the early stages of the design
> and the MFC version clocked in about 1.5MBs, the WTL version clocks in at
> 200k.
I recently (because the client required it) ported an application from
being based directly on the Win32 API to using WTL. My biggest problem with
WTL is that BoundsChecker does not follow all of the paths WTL uses for
storing pointers and handles so reports a large number of leaks and invalid
uses. I like to use BoundsChecker to ensure code quality but if there are
too many false positives, it becomes difficult to see the real problems.
With .NET, many of the problems C++ is prone too are eliminated so the
need for BoundsChecker is less. However, there will still be a need for
tools to check for long lived garbage kept alive by inadvertant references
just as there is for Java.
Another problem is that WTL, like ATL is written with 'too clever' code.
When you are assured of support and maintenance, as Microsoft and the user
community provided for ATL, then this is not a problem. But for WTL there is
a much larger chance that you will be left on your own, with programmers
maintaining a complex library that they do not fully understand.
Neil
Ryan Park
Regards,
Ryan
Eamonn Wallace
news:OeVZPo9tAHA.2248@tkmsftngp05...
I'd have to disagree almost totally with your analysis:-)
> I recently (because the client required it) ported an application from
> being based directly on the Win32 API to using WTL. My biggest problem
with
> WTL is that BoundsChecker does not follow all of the paths WTL uses for
> storing pointers and handles so reports a large number of leaks and
invalid
> uses. I like to use BoundsChecker to ensure code quality but if there are
> too many false positives, it becomes difficult to see the real problems.
Just because Boundchecker (which I've never used) can't handle
some code does not imho mean the code is inherently worse.
> With .NET, many of the problems C++ is prone too are eliminated so the
> need for BoundsChecker is less. However, there will still be a need for
> tools to check for long lived garbage kept alive by inadvertant references
> just as there is for Java.
Too much handholding with Java for my liking...gimme da power:-)
> Another problem is that WTL, like ATL is written with 'too clever'
code.
> When you are assured of support and maintenance, as Microsoft and the user
> community provided for ATL, then this is not a problem. But for WTL there
is
> a much larger chance that you will be left on your own, with programmers
> maintaining a complex library that they do not fully understand.
Clever code...well its (sort of) the way C++ code will be written in the
future,
templates and so on
I find the code reasonably clear, concise and relatively simple to
understand.
Its merely a very thin wrapper over the APIs involved.
I suppose its a style I am comfortable with others peoples mileage may vary.
I find some of the more arcane depths of MFC to be too clever by far and
almost
totally unreadable. Some like that style...
With ATL7/VC7 promising more adherence to the ISO standard I feel any
programmer should be able to read the code for WTL at a glance,
not necessarily understand every nuance in the code but have a reasonable
shot at making any required changes.
Anyway the basic point I am making is I like WTL it suits my mindset.
I am not saying that WTL is perfect, far from it, however the developers
of WTL are responsive to most suggestions and bug reports..
BTW thanks for the input and sorry I don't agree with your analysis.