Wtl

[nuzzle]

After a year and a half, WTL has now come up with a new version. The major changes being some adjustment so it works with MVS 2008.

Is WTL something to go for really?

[JVene]

I give it a big "eh".....

But then, I don't enjoy creating applications tied directly to Windows operating systems - I want portability.

However, many thought WTL was much nicer, more modern, cleaner and easier than MFC.

[nuzzle]

I give it a big "eh".....


I cannot. I need to decide. I've almost decided to go for WTL.

Please tell me I'm wrong.

[JVene]

There are many who do give it high marks. It's documentation is limited (perhaps not as much today as it was a couple of years ago the last I looked seriously into it) - and it is NOT formally supported by Microsoft (unless news to the contrary escaped me, which is certainly possible).

Seriously, though - is there a strong reason to choose a non-portable framework for an application?

You mentioned they updated WTL to run in 2008 (I would be surprised if it took much effort), but does it offer anything to support Vista or Windows 7? WTL was designed, if memory serves, at a time when Windows 2000 was modern (or perhaps it was XP). Win32 applications should run in Vista and Windows 7 - so my point isn't about whether it will run, but would you have interest in services exclusive to Vista/W7 which might be better supported by MFC? (I doubt this, but it's possible).

To that point, do you need more than basic coverage of Win32 for your application? Most applications really don't, and can be made portable. Would your purpose be suited if you could provide a Linux or Mac build. Would you have interest in a handheld version?

As a framework, WTL is fine for most general Windows GUI application work. Without knowing the slightest thing about what you're about to build, that statement could be meaningless.

[nuzzle]

As a framework, WTL is fine for most general Windows GUI application work. Without knowing the slightest thing about what you're about to build, that statement could be meaningless.

I was considering WTL as an alternative to using Win32 directly (if I wanted portability I would probably go for Java).

My main concern is that WTL doesn't seem that active. The updates are infrequent and there's little activity at the forum. I may be wrong though. I know WTL was once supported by Microsoft and developers still are Microsoft employees. So WTL may very well be actively developed and maintained, but it has to keep a low profile in order not to be considered a threat to other Microsoft technologies.

Could it be that WTLs special relation with Microsoft imposes restrictions on how visible the project can afford to be? I think it might.

[JVene]

As I understand it, WTL was never an official MS product, just an "open source" kind of contribution. There was never official support, only community support. Those that like it say it's much better, but it does not enjoy consistent active development, there is limited documentation and I don't know of many products built using it.


As a C++ developer, my first reaction to an C API is to consider encapsulation; win32 qualifies. Of course there are other frameworks that are worth considering other than WTL and MFC. I suppose you have reasons to reject MFC or you wouldn't favor win32 as an alternative to WTL.

Unless you're quite familiar with win32 development, choosing it may be a regrettable decision in the long run, though plenty of software was created using it.

Why not consider wxWidgets? It has a long history, is somewhat familiar to MFC developers (and is sometimes easier that MFC), it's free and portable.

There are some downsides. While it may have more documentation that WTL, it's not as widely known as MFC, and it's not as "visual" a development environment as MFC, but then if you had any inkling of using win32, that doesn't matter to you anyway.

On the subject of portability, your point about Java skips some crucial facts. Java isn't as portable as advertised. Performance and compatibility among the platforms is more suspect that promised, but that's an aside from the central message I have to convey here.

Portability is an issue for C and C++ developers. The entire reason C was created in the 70's was portability - between hardware. All platforms that advance over time, be they hardware or OS, even languages, require developers to think in terms of portability. My aged colleagues and I remember quite well the nightmare of "portability" from Windows 3.0 to Windows 3.1 (and to Windows win32 in '95 vs NT 3.1, then to NT 2k, XP....). Portability is an issue that isn't solved simply by choosing Java either.

There can be conflicts between versions of the Java installation such that older applications are broken when an upgrade of the runtime is performed, and, of course, the newer applications that require the updated runtime can't perform without the upgrade. Sun servers had this problem is several generations. Plus, the wide disparity of performance on the different platforms can create such a performance level mismatch that an application is unusable without specific runtime engines, or tweaks to them. When Java was "new" this wasn't a problem, but the assumption that it would always stay "clean" was in error.

C# has had similar problems in the various progressions of .NET versions, which is a minor portability problem even within .NET.

wxWidgets is a portable framework. It is literally possible to develop one body of C++ application code that runs on Linux, Unix, Windows and Apple (though on Apple QT has better portability, it's just pricey).

I realize portability isn't part of your goal now. Your reply states that.

My reply is that, from the viewpoint of an experienced developer, portability is an issue in the practice, and I've come across it in surprising situations when I swore it would never be a problem. If it ever was a problem, it's not the choice of C++ that made it so, it was my choice in development direction (like choosing WTL).

I can't say I'm happy with wxWidgets as if it were the best choice; I might be happier with QT if it weren't so expensive. Then, too, I was never entirely happy with MFC either. MS once stated, before the beta's of VC 9, that support for MFC was now at it's end and wouldn't be moved forward. That hasn't happened, an update was issued with VC 9, but it makes you think, doesn't it - if one developed an application based on a framework like MFC, and MS insists on moving into .NET and leaving MFC behind, where does that leave the developers who based large bodies of work on MFC? They'd be marginally better than those under wxWidgets if that platform's development suddenly died off, and at least wxWidgets supports other platforms (even handhelds).

I run through this tributary because you came back on this thread after some time, and it appears you are thinking carefully about a direction. I empathize, there are no perfect directions and haven't been for years. OWL, a framework from Borland that was really preferred by Borland fans because it was portable between OS/2 and Windows 16 and 32 bit builds (something even MFC didn't quite manage within Windows) - it has been lost to history. It wasn't exemplary, and certainly not modern C++ (it was developed with Borland's first C++ compilers), but there were a number of applications built using it that had to figure something out. OWL wouldn't even compile in the MS compilers (though with effort it could be done).

I would be more helpful than generalities if you had some way of communicating what you're making.

Some applications are business designs - what I call "bag of fields" - the GUI is essentially dialogs, usually interfaced to SQL.

Some are all custom work - like Adobe Illustrator/Photoshop. That is, there's hardly any common control in most frameworks that's going to provide much leverage - the application is going to be started with a basic window object and all or mostly custom code from there.

Some are not GUI minded at all - they may present a GUI interface, but the guts of the application aren't even GUI - they could be implemented in a text UI if required. Applications like FTP clients (or especially FTP servers), other communications or technical utilities are like this.


What kind of support from a framework does your application require? That might help me suggest which of the several frameworks I've used might be of more help than win32 or WTL.

(or that WTL would do fine).

[Arjay]

WTL is a good alternative over MFC for creating non-Document/View Windows applications.

[nuzzle]

I would be more helpful than generalities if you had some way of communicating what you're making.


Thanks for your extensive reply.

I'm going to write a Molecular Dynamics application (a mix of molecules obeying physical laws interacting in 3D). For this I need a GUI, a 3D subsystem and a number crunching unit.

After having considered various portable alternatives I've come to the conclussion that C++ source level portability is sufficient and it's better that my program runs very well on one platform than so-so on many. So Windows it is. I'm planning to use Direct3D, CUDA, Intel TBB and Win32. I'm looking for higher level support software for all of these (suggestions are wellcome).

When it comes to Win32 I've identified WTL and Win32++ as GUI options. Win32++ is very nice,

http://users.bigpond.net.au/programming/

but before I go for it I would also wan't to check out WTL. The reason I asked at this forum is I want to avoid stepping on a mine. I takes some serious effort to try out a new package and if it's doomed anyway I rather not waste my time.

[nuzzle]

WTL is a good alternative over MFC for creating non-Document/View Windows applications.

I have no reason not to believe you when you say that but I would appreciate if you would expand a little on your reply.

[Arjay]

MFC has a richer feature set (like classes for databases, file I/O, the aforementioned doc/view architecture, etc), but WTL definitely has a smaller footprint. In a way, because WTL is template based, it's a bit more 'modern' than MFC (as MFC was designed before templates were in C++).

I would prefer to suggest the following in a private mail, but since you don't have it enabled... That being said, you may want to investigate WPF in .Net. You can get some very decent 3D performance with WPF. If interested, check out Maximizing WPF 3D Performance on Tier-2 Hardware (http://blogs.msdn.com/wpfsdk/archive/2007/01/15/maximizing-wpf-3d-performance-on-tier-2-hardware.aspx) and be sure to try the 3D samples in the WPF SDK.

[nuzzle]

You can get some very decent 3D performance with WPF. If interested, check out Maximizing WPF 3D Performance on Tier-2 Hardware (http://blogs.msdn.com/wpfsdk/archive/2007/01/15/maximizing-wpf-3d-performance-on-tier-2-hardware.aspx) and be sure to try the 3D samples in the WPF SDK.

Thank you. I've already investigated the option you suggest. Some time ago I wrote a C++/CLI test program using WPF both for the GUI and the 3D subsystem.

I must say C++/CLI really is an amazing language and the compiler a great technical achievement. But I felt C++/CLI lacks a good infrastructure. It's very hard to find example programs and documentation (for example on how to use WPF). I could use C# instead of course but then my whole program would be hopelessly tied down to Windows. If I used C++/CLI I could still write the major portion in classic C++.

The main problem though is that I want to be able to show an enormous, like millions, number of atoms (spheres). Even if WPF is good it's not designed to handle that kind of extreme. Another drawback is that it wasn't clear whether .NET would work well with Intel TBB (Threading Building Blocks). I need fine-grained threading to utilize multiple processor cores in algorithms. It's also not clear whether CUDA works well with .NET and that's key to my application.

And finally, another aspect is that the C++/CLI - WPF combination in principle is equivalent to the Java - Swing - Java3D combination. The main advantage of the Java route is portability. The drawback is the same though. The scenegraph based handling of 3D (in both WPF and Java3D) doesn't quite cut it performancewise. For that I need to use either Direct3D or OpenGL more directly.

So an option would be to use WPF as GUI but to use Direct3D for the 3D subsystem. I'm still considering that option but then there's always the Java - JOGL (OpenGL) alternative. The latter being technically equivalent roughly but much more portable.

But basically I'm drawn towards using plain old C++ with a set of quite low-level APIs. I feel I'm avoiding lots of trouble and setbacks in that way and I'm prepared to accept the additional effort I probably will have to put in. Managed code is the answer in many situations but mine is a scientific application with very demanding performance requirements.

[JVene]

Either there's another thread, maybe even in another forum, on this topic, or a reply I made recently was never posted.

Now that I know more about what you're doing I can respond more directly.

I can tell you without reservation, you need to consider 64 bit targets. Your memory management issues associated with large data sets are going to be much more manageable. At the very least, you need to write with 64 bit portability in mind, which isn't difficult (less so than Unicode, for example).

I can also declare with certainty that your 3D framework support is more important than your GUI selection. wxWidgets has, for example, an OpenGL 'widget' that can place a 3D control into a dialog. The performance difference between DirectX and OpenGL will be minimal, more directly associated with the OpenGL implementation vs DirectX implementation for a particular card, and it's obvious that your demands will require a careful graphics system selection anyway. To that end, you'll seriously need an abstraction of the 3D access.

From experience I can tell you you do not want to place any DirectX or OpenGL API calls within your application code. It simply does not pay dividends, even though early research may indicate to you that you might.

Consider picking up one of David Eberly's recent texts on 3D "game" engine design (trust me, it's not strictly a game engine book - that's a marketing choice). Eberly's recent books cover the design of his WildMagic 3D engine, freely downloadable and GNU open source. What's important here is not the engine itself, but the book/engine combination. WildMagic has been used in research work such as yours; several commercial products are based on it, sometimes loosely. Eberly is a PhD in mathematics, has worked in 3D for many years, and both the book and his engine describe in excellent detail exactly what you're going to require for 3D visualization of complex, large scientific datasets. The book presents good reasoning behind all of his design choices, and serves as a detailed documentation of the WildMagic engine.

One point Eberly makes that is focused on game developers is the rejection of the STL. This is not essential to your work. In real time game environments his reasoning is more applicable, but in your work the choice is probably to favor the reliability of STL containers. His framework and book suggestion on that point may be set aside, yet his point does play out - performance of certain STL containers has undesirable performance implications which he describes. This includes smart pointers, though I've found shared_ptr quite good.


WildMagic will work with DirectX or OpenGL on systems as diverse as Windows or Mac. Performance is realtime even though you can choose the backend engine at compile time. Everything is built from a performance critical standpoint, even though the backend is abstracted (this is the key point).

The GUI framework you choose should be portable. You might not realize it fully just now, but for this kind of target you may find application usage requests in Linux or Unix high end systems, if not now, in a future generation of your work. As such, you should seriously consider either QT or wxWidgets, and avoid any frameworks that completely tie you to Windows, while still providing full performance and coverage of the GUI resources of each target system - QT and wxWidgets can do that.

I suppose you have either what is essentially a dialog based application, or a tabbed document design, quite likely with some multiple monitor support. That is, your application will present, in it's primary mode of use, a window with a set of controls and a prominent window showing the 3D visualization, possibly with a means of selecting from multiple views/datasets. Most GUI frameworks will do fine for this and more, and QT and wxWidgets will suffice without trouble.

QT is pricey but better documented, while wxWidgets is free, but stable and active. Professional applications have been based on both. QT is more modern, but some report it's performance is marginally slower. It does have better MAC support, but both have equivalent support of Windows/Linux/Unix targets. I wouldn't hesitate to choose either (and I've used both).

I would hesitate to accept WTL, MFC, anything .NET, or any win32 specific approach for your target - and you've already mentioned the primary reasons. Mixed language approaches tend to split the programming team and complicate staffing on a project like this. Your sense to stay entirely in C++ - and I would stress portable C++ - is essential.

I'd recommend you keep a Linux VM handy with current development tools installed, and toss the code over from Windows for compile/lint checks against GCC in that environment, while relying on Visual Studio for development. I use this approach myself. Visual Studio's debugger is quite good and responsive. Checking with GCC under Linux occasionally ensures your code is portable from the start, not just between platforms but among compilers (and thus the C++ language compliance).

That technique even helped my work simply moving from Visual Studio 2003 to 2005 to 2008.


Also, before you commit to CUDA, double check on OpenCL. Abstract the physics/math as much as possible; this area of the industry is changing rapidly, and we may well see mixed CPU/GPU devices based on OpenCL before your project is in full use. I don't expect CUDA will be favored there. Abstracting the interface will help keep you flexible with respect to GPU usage, and Eberly's design for graphics abstraction will be instructive on this point.

[nuzzle]

- and I would stress portable C++ - is essential.


Thanks for your valuable input.

Well, you're promoting a portable approach. I've considered that too but I keep coming back to a native Windows approach.

I know about the WildMagic engine and I even own the Eberly book you mention.

http://www.geometrictools.com/index.html

I always considered WildMagic a kind of "proof of concept" for the techniques discussed in the book but I can see now that the engine has developed over the years. I'm sure it's a good engine but there are these drawbacks in my view:

1. It's one-man operation (or rather two because the wife seems to be involved).
2. A commersial version is planned and this usually puts an end to active developments of the open source version.
3. The engine supports both OpenGL and Direct3D and this usually means the engine is CPU heavy while the trend today is to let the GPU do most of the work.
4. The engine is scenegraph based which has lower performance compared with direct control of the low-level rendering API.

If I were to adopt the portable approach these are the alternatives I would prefer. For scenegraph based rendering: OpenSceneGraph,

http://www.openscenegraph.org/projects/osg

And for direct OpenGL control: G3D,

http://g3d-cpp.sourceforge.net/

Both are well integrated in wxWidgets, my preferred choise of portable GUIs. The runners up are QT and FLTK. Unfortunately QT is too expensive because of the hefty yearly upgrade fees. I don't know much about FLTK but it was recommended by Stroustrup in his new book so I'd definately consider it if I were to go the portable route.

You may be right that portability is the right choise and I'll reconsider it carefully. An important factor to throw in the mix is that the portable approach effectively means settling for OpenGL. OpenGL seems a little old and tired and the action seems to be with Direct3D. At least I get that impression after reading articles like this,

http://www.tomshardware.com/reviews/opengl-directx,2019.html

Once again thanks for your input. I think I check out WTL before I make up my mind. It can't hurt to know what it's like.

[wigga]

i think OpenGL+wxWidgets is a very nice solution.

its portable and wxWidgets is an activly developed solution. i think they even have a window editor but im not sure.

also opengl is very fast and easy to use.

[nuzzle]

i think OpenGL+wxWidgets is a very nice solution.

its portable and wxWidgets is an activly developed solution. i think they even have a window editor but im not sure.

also opengl is very fast and easy to use.

I agree. If I were to go for a portable solution I would use wxWidgets and the G3D package I mentioned in my previous post.

But portability is not my main concern for this project. It's much more important to come up with an excellent solution on one platform. I feel that working with fairly low-level APIs on one OS gives me the best control.

I could have picked Linux or Mac, but because Windows is dominant on the desktops of my envisioned costumers, I go for Windows. And that's why I'm asking about WTL. I was wondering if anyone has experience with this package and would recommend it?

[Arjay]

I could have picked Linux or Mac, but because Windows is dominant on the desktops of my envisioned costumers, I go for Windows. And that's why I'm asking about WTL. I was wondering if anyone has experience with this package and would recommend it?Here's a couple of good links on WTL. The first one compares WTL to MFC and contains a couple of interesting links (which is how I found the second link).

http://www.endurasoft.com/vcd/mfcwtl.htm
http://www.sellsbrothers.com/tools

I'd recommend doing a few of the samples listed and try out if WTL will work for you.

[nuzzle]

Here's a couple of good links on WTL. The first one compares WTL to MFC and contains a couple of interesting links (which is how I found the second link).

http://www.endurasoft.com/vcd/mfcwtl.htm
http://www.sellsbrothers.com/tools

I'd recommend doing a few of the samples listed and try out if WTL will work for you.

Sure there are links (and I'll check yours out).

But what I'm looking for here is personal experience. Preferably I'd like to hear from someone who's actually used WTL and not just heard about it (like myself and everybody else it seems).

[Arjay]

But what I'm looking for here is personal experience. ??? See the Windows Template Library links about 2/3 of the way down the page of the sellbrother links. Read the 2 part article about "WTL Makes UI Programming a Joy". That might give you enough to decide whether to spend more time investigating it.

[nuzzle]

??? See the Windows Template Library links about 2/3 of the way down the page of the sellbrother links. Read the 2 part article about "WTL Makes UI Programming a Joy". That might give you enough to decide whether to spend more time investigating it.

That's fine, but to be very direct, I don't need directions. What I need is someone speaking their mind.

So, as a direct question to you Arjay, do you or don't you think I should use WTL?

[Arjay]

That's fine, but to be very direct, I don't need directions. What I need is someone speaking their mind.

So, as a direct question to you Arjay, do you or don't you think I should use WTL?See the comment in my replies #7 and #10. Beyond that, you'll need to decide for yourself as I don't know the particulars of your environment or requirements. Good luck in your search.

[nuzzle]

See the comment in my replies #7 and #10. Beyond that, you'll need to decide for yourself as I don't know the particulars of your environment or requirements. Good luck in your search.

Sorry Arjay. I appreciate your effort, but I've made it clear by now that I don't want more links.

Sayonara everbody.

[nuzzle]

I'd like to make a correction to one of my previous posts where I wrote that Qt is expensive. This is no longer true. Qt is now owned by Nokia, the mobile phone maker, and they've released Qt under the LGPL 2.1 license. See here for the implications,

http://www.ics.com/files/docs/Qt_LGPL.pdf

This definately changes things. I've decided to go the portable road using Qt as GUI, so it seems WTL will stay unchartered territory for me. :)

I appologize for the slightly irritated tone I adopted at the end. And thank you all for your help.

[JVene]

That is great news, thanks for putting that link up.

[nuzzle]

That is great news

Yes, I've always felt C++ lacked a sophisticated, affordable and portable GUI.

In my view the open sourcing of Qt puts C++ back to where it belongs, namely ahead of both C# and Java. :)

[wigga]

C++ has always been ahead of C# and Java in my book. but yes it is such a great language but lacks up to date libraries.

[nuzzle]

but lacks up to date libraries.

What up-to-date libraries do you feel C++ is lacking?

[nuzzle]

I've located a very good WTL introduction. The best I've seen by far. It looks and feels like a manuscript for a book almost ready to get published. It's somewhat dated (from around 2000) but it should still cover the basics very well.

It's easiest to find if you use the AltaVista search engine (www.altavista.com). Search for "WTL Developer’s Guide By Eamon O’Tuathail" and click on the first hit. It's a pdf file.

Although in hindsight the author was far too optimistic about the future impact of WTL, this "book" has actually made me more inclined to use WTL today even though it must be considered a rather obscure technology.

[nuzzle]

I've continued along the WTL route actually. I'm keeping Qt as a backup for the time being.

I've already noticed that WTL is much more solid than the Win32++ library I've been using so far. Win32++ imposes restrictions you don't want really and is generally shaky. So if I've recommended Win32++ in the past it's in the past.

[Arjay]

Glad to hear the WTL route is working out for you.

[nuzzle]

Glad to hear the WTL route is working out for you.

Since I've actually used WTL I'm beginning to understand its virtues better. I've even become interested in ATL and COM. It maybe isn't cutting edge but it's what you got if you want to use static C++ isn't it. :)

Anyway I've managed to create a Direct3D window and it works very well in a pane in a splitter window just the way I wanted it to.

Not knowing too much yet, WTL is like the slim verion of MFC . It's like what you want if you want a basic Windows GUI.

And it seems WTL is actively developed and you can get help if you ask for it. I can only recommend it. It's even fun to use. I'm very positive.

[Arjay]

Cool. I don't know if you are doing anything with databases, but if you are, check out the ATL OLEDB consumer database classes. If you like WTL over MFC, then you'll like these classes over the MFC database classes.