Click here to Skip to main content
13,354,733 members (60,572 online)
Click here to Skip to main content
Add your own
alternative version


46 bookmarked
Posted 23 Apr 2006

DWinLib: An Overview

, 8 May 2010
Rate this:
Please Sign up or sign in to vote.
An overview to DWinLib - a minimal Windows wrapper
This is an old version of the currently published article.

Last Update

  • 5/8/2010 - Updated core code to properly handle MDI applications, use Thread Local Storage, and several other things I'm probably forgetting. Started the process of consolidating all old articles onto 'David O'Neil' account.

Note 1: I intend to remove the articles from the other account in the next month or so, in order to have only one set of documents to keep up. I will probably even remove the original DWinLib writeup, as DWinLib has chaged a lot since then. I apologize for the bookmarks this will break.

Note 2: I am going to post the linked articles when they become available, and update the link on this page at those times. As this is written, the links point to old articles that haven't been updated. An easy way to tell whether a link is updated is to look at the author. 'RandomMonkey' articles are old. 'David O'Neil' articles are new (except for the article in note 1).

Note 3: As the linked articles haven't yet been updated, they will not work with the DWinLib_3.00 sources, and require the older framework.


In about 2000 I decided to make a computer program to give precise control to all of the events in a MIDI composition. The first edition was created in Borland Builder, and, since I hadn't known much about programming beyond my college Fortran class (and a little dabbling in C) before taking on the project, it involved a massive amount of learning. But I succeeded—to a point. During the last iteration a bug appeared where Windows was trying to send a message to a window that had been destroyed. Of course, that's a big problem, and should never happen in a well-written application.

I triple and quadruple-checked my code (and then triple and quadruple-checked it again), and could not find anything wrong, and did not know what to do. It appeared that the problem was deep in the guts of Borland's VCL, although looking back on it now, it may have simply been that I did not set 'Msg.Result=0" (or something like that) for some messages I handled. Not knowing that, though, I decided, rightly or wrongly, to take the plunge and master Windows API programming, in order to gain the knowledge to fix the bug permenantly.

And so DWinLib was born. It was another massive learning experience, and it was a success. I managed to get my program running with it, and the bug was put to rest. In addition, MEdit (my program) worked more smoothly, because I learned how to reduce WM_PAINT and WM_ERASEBKGND messages, and only refresh the screens once when I wanted them to. (There were items in Borland's VCL that made it difficult to achieve that task, although I'm certain it was possible with a little more learning.) There was one other huge benefit to using DWinLib: my program had grown so big that it had bumped into the limitations of Borland Builder's flakey IDE, and it kept getting built incorrectly when using the VCL. The DWinLib version did not have this problem.

In about 2006 I shared DWinLib on CodeProject, and David Nash took it upon himself to make it compile in other environments. That was a big evolution in DWinLib's history, and after his initial success I changed the signatures of many routines, to make them conform to Windows' signatures, rather than what I thought they should conform to. (Prior to that, I was trying to be a purist, and make everything return built-in types, such as 'int,' rather than 'LRESULT.' The things you learn as you progress...)

I shared more of my lessons at that time, but, due to a bug with the way CodeProject then handled apostrophes, I wasn't able to reply on the bulletin boards, so I created another account without an apostrophe, and because of that my articles became scattered in two places. It was my intention to organize them correctly, but another project reared its head, and I became too busy documenting the forgotten astronomical foundation that Western religion is founded upon, and I couldn't get back to this until now. (That project is finished!, and if you are curious about the celestial events that the biblical story of Samson was created from, visit my website.)

DWinLib has slowly evolved over the intervening years, as I have continued to play with it in my spare time. I look forward to discussing some of those changes throughout these new articles, as well as consolidating the information from my other account. Let's begin by discussing a little about DWinLib's advantages, and some of the other frameworks that now exist.

What's In It For Me, You Ask

There are many interesting items in DWinLib. Depending upon your programming experience, some of them will be more interesting than others.

To me, there are two main reasons for sharing these articles, and the code behind DWinLib. First, I believe that frameworks of this nature are intrinsically interesting. After all, it fascinated me so much that I continued programming, even when I got sick of the many changes that occurred, and the drastic rewrites that were required. To those of you who share this fascination, I hope I have done some justice in presenting a more complete overview of everything that goes into one of these works. The other reason for sharing is that none of the other Windows wrapper presentations I've seen explain how to wrap child controls easily, nor explained what it takes to incorporate callbacks for event handlers. Perhaps you will find that knowledge useful someday.

Moving on to more concrete items, one of the things I really like in DWinLib is that a resource editor isn't needed. Every control derived from WinControl automatically gets a control ID, and DWinLib takes care of processing those IDs. All that you have to do is to write event handlers. You do have to programatically lay out how you want things to appear, but if you don't have access to a resource editor, eliminating ID processing can be a great boon. (There is a free resource editor available (created by Julien Audo?), so if you want to do it that way, you can create programs that don't take advantage of WinControl processing. Maybe someday for fun I'll put together an example, but that is way down on my list of to do items!)

Another benefit of DWinLib is that it is not tied to one compiler. It can be built with Visual Studio, DevC, Borland, or another standard C++ compiler.

If you are familiar with C++ programming, one of the neat things about DWinLib is that it is fairly easy to see what is needed to wrap the Windows API. If you are not yet familiar with C++ programming, you will get a better feel for C++ and the Windows API while working your way through the code.

Another advantage to DWinLib is that DWinLib is the only framework available (that I know of) that allows you to use true multiple inheritance with DWinLib objects. I was told that should be bolded, so DWinLib allows the programmer to use multiple inheritance with DWinLib objects. Of course, you could not inherit from two objects with independent window procedures and have the program work correctly, as the basic premise you are trying to accomplish is unsound.

In a semi-related topic, it is sometimes possible to create windows on the stack, rather than on the heap, but you have to know what you are doing when you try that. I will add more specifics on the requirements later (i.e., I haven't looked at that ability in years, and I don't have time to document it properly right now, but I remember that it can be done).

I was once able to state that DWinLib allowed you to make flicker-free applications more easily than other frameworks. This is still true if you have an XP machine, and have it set up to use the Windows classic style. Ever since XP's theming occurred, it is almost impossible to get rid of a lot of window flicker when resizing, because Microsoft has never updated some of the common controls to eliminate double painting occurring on WM_PAINT and WM_ERASEBKGND messages, and their theming mechanism precludes overriding this correctly, as far as I can tell. An example of the flicker I'm discussing can be seen if your web browser has a scroll bar visible on the right of this window, and you resize the window from the left edge. The scroll bar appears to jump erratically. In windows with dockers on the right edge, this jumping can be really annoying. I haven't been able to figure out how to overcome this behavior in Windows 7.

There are other benefits of DWinLib, and we will look at many of them in these writings, but the most important benefit from my perspective is that it makes Windows programming fun.

Comparatively Framed

In the first version of this article, I listed many of the other frameworks and API wrapper examples that I am aware of. I will probably move this section into the article where I discuss the internals of DWinLib's operations, so that I can add some information about how a few of these accomplish their OOPification of the Window WinProc procedure, versus how DWinLib does it. But until that is rewritten, here is a summary of the alternatives to DWinLib that I'm aware of.

Windows Specific Products:

  • .Net - Still relatively proprietary, as you really need VS (or Borland's newer products) in order to use it effectively. It also requires big redistributions for computers that don't already have the .Net runtime installed. Using the Mono project will still potentially require a large redistribution of the .Net framework, and, as far as I know, really requires VS or another costly alternative, such as one of the newer Borland products to use effectively.

  • MFC - The grandmother of all frameworks (almost). To use MFC on a real-world app requires the (discontinued?) $300 version of VS, in order to get the resource editor. If you want to statically link MFC, you will need the $800 version of VS. (I'm uncertain about these prices, because Visual Studio's price structure changed with the 2010 edition, and the standard edition no longer seems to be offered.)

  • Visual Class Library (VCL): CBuilderX, Personal Edition - (This product may not be available any more?) Borland left a bad taste in my mouth once. I won't let it happen again. But for $50, it is usable, although as far as I know, it has some limitations. For instance, you need to redistribute the VCL's dll's, and it doesn't have any source code available.

Windows Specific Frameworks:

  • Visual Component Framework (VCF) - It appears that Jim Crafton and his crew have put a phenomenal amount of work into this. It contains threading libraries, graphics libraries, and a whole slew of other stuff. I seem to recall that he was attempting to make this into a Rapid Application Development solution at one time, but that topic doesn't appear on a quick perusal of the current site. I also couldn't find any overview on its inner workings. I found statements that it is being made cross-platform, but it doesn't appear to be yet.

  • Relisoft's Generic Windows Wrapper - One of the first places I learned about creating Windows API wrappers.

  • Oluseyi Sonaiya's Window Wrapper - Another resource.

  • David Nash's SDI Framework - Very impressive, since the SDI framework now handles MDI! Also, David is a great guy, and I'm not saying that just because of my familiarity with the name! (And I feel compelled to express my thanks to him once again for his help so long ago.)

  • Win32 Generics wrapper - but that site does not appear to try to show you how it is accomplished. In addition, it requires high-level template magic to accomplish the vast majority of its tricks.

  • WTL - For those that can't get enough of templates. I have heard high praises sung by its supporters.

(I believe that in all of the Windows specific frameworks listed, you have to resort to the ground-level API and assign control IDs yourself if you want to handle child controls. Or you will have to develop your own solution if you want to do this in an easier manner. DWinLib dows not have that requirement. I may be wrong regarding WTL.)


  • GTK - It seems to have evolved from the from the first time I looked at it, because I once said that their example is not really 'objectified' in the OOP meaning of the word, but rather more of a 'C' / procedural programming paradigm. It now appears to be objectified, or I didn't look at it very closely four years ago.

  • wxWidgets - I like this better than most, as it appears to be a fairly clean design. Unfortunately, I have ran some programs based upon this, and some of the 'controls' did not work as I expected them to. When I contacted the author, I was told that it was a problem with wxWidgets that they could not figure out how to overcome. I do not know if those quirks have been fixed. (That was a long time ago, so I suspect they have been fixed.)

  • QT - From what I have read, it is one of the cleanest alternatives, but it is even worse than MFC in that it is $1,500 $3,695 - OUCH - for a license, unless you make your application OpenSource.

Link Heaven

I once tried to fit all of the information in the following articles into one document. There was too much stuff, so I chose to make this article an overview, and link to more in-depth writings at the appropriate places. I hope that this approach helps make the information easier to digest. With that, the first subtopic to link into is setting up Visual Studio for creating Win32 API programs. Some people have found that page to be useful for making VCE usable, even for non-DWinLib purposes. The article was written for Visual Studio 2005 Express Edition, but I am adding some stuff for VS 2008 Express Edition. (VS 2008 EE is much easier to set up a Windows program in than VS 2005 was.) I don't have plans to upgrade to VS 2010 Express, as what I have works for me.

The Absolute Minimum Windows Wrapper

The second topic to delve into is what I consider to be the absolute minimum windows wrapper. That example shows how some common controls can be integrated. Reading that writing, you will see how DWinLib originated, but DWinLib has progressed far from those humble beginnings. If you have an extremely simple program, that wrapper may do the job for you, but if your program is that simple, a pure API program will almost be just as easy.

The Guts of DWinLib

Right now, the only explanation of DWinLib's internals that exists is available in the original DWinLib page. I will create a new one within the next month or so, which documents the changes that have occurred since then, and flows with this article.

DWinLib and Modal/Modeless Dialogs

It took a great amount of thought and learning in order to be able to program all windows using the same techniques in DWinLib, but I believe I was successful. This means that you can create modal/modeless windows using the same techniques as you use to create your regular windows. The great benefit to this is that this approach makes it much easier to program without having a resource editor available. There are some tricks involved, but I believe I have presented them clearly in my Modal/Modeless Windows in DWinLib presentation. Also note that DWinLib's equivalent to the standard 'Hello World' program is presented in the beginning part of that presentation.


The last thing to add is that DWinLib can be used to build Unicode applications. To do so, open the 'ProgramHeaders.h' file in the application's subdirectory. Uncomment the '#define UNICODE' and '#define _UNICODE' lines. In addition, use the 'wString' type where you would use std::strings or std::wstrings. This typedef is in 'ProgramHeaders.h', and looks like the following:

#include <string>
typedef std::basic_string<TCHAR, std::char_traits<TCHAR>, std::allocator<TCHAR> > wString;

This expands to the same thing as std::string or std::wstring in VCE, depending upon what TCHAR becomes due to the definition or non-definition of UNICODE.

It is also worth noting that the 'ProgramHeaders.h' file is designed to be the first file processed by the preprocessor. It takes care of the Windows includes for the project, as well as any other items that you may desire. Once a unit of your project is stable, #include it in the 'ProgramHeaders.h' file, and if you have kept the precompiled headers working as in the sample programs, your build times will be considerably reduced.

In addition to that, it appears that you cannot build a true Unicode application with Dev-C++, as there is not an equivalent to the Windows 'c0w32w.lib' file. All of the strings can be Unicode in a program compiled with Dev-C++, but you will not be able to link to wWinMain, which a true Unicode application calls as its entry point. (Even though VCE doesn't seem to have a 'c0w32w.lib' file, it somehow appears to tie into the correct Unicode entry point.)

And with that, we have reached the end of this overview of DWinLib. I hope these writings will be of use to you in your future, and wish you the best with your endeavors, no matter what framework you choose. 

The End


  • 1/27/2006 - No wars have yet erupted over the use of DWinLib. It is hopeful that this trend will continue.
  • 2/19/2006 - Updated DWinLib for 64-bit compatibility. I have not tested a 64 bit build, therefore please give your feedback on any missed items if you create a 64 bit application with DWinLib.
  • 2/20/2006 - Added link to a minimal window wrapper example.
  • 2/24/2006 - Removed dead link and added link to modal dialog creation instructions. Also updated the zip file to reflect small changes in WinButton unit.
  • 4/11/2006 - Completely restructured presentation. Simplified accelerator table inclusion - it's now always included in a project.
  • 5/8/2010 - Updated core code to properly handle MDI applications, use Thread Local Storage, and several other things I'm probably forgetting. Started the process of consolidating all old articles onto 'David O'Neil' account.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

David O'Neil
Software Developer
United States United States
I am the author of Laughing at the Devil: One Man’s Religious Discoveries. For those who are “ready to look at the world - religion, science, spirituality - differently,” LATD is the book to turn to.

In about 1994 I began studying and documenting the astronomy of our ancestors. A hint lead to many years of partial understanding, before a profound breakthrough occurred and some old myths finally made sense.

The greatest of my discoveries is the celestial observations behind the biblical tale of Samson, which was created 3,000 years ago. That find casts a profound new light on the roots of Western religion, as well as the foundation of modern science. To learn more, visit my website.

Trained as a mechanical engineer, I learned C++ programming on my own in order to create a MIDI program. I am delighted to say I also succeeded in that goal. Happy coding, everybody!

You may also be interested in...

Comments and Discussions

Discussions on this specific version of this article. Add your comments on how to improve this article here. These comments will not be visible on the final published version of this article.
QuestionQt licensing Pin
Vladimir Svrkota16-Feb-13 6:15
memberVladimir Svrkota16-Feb-13 6:15 
AnswerRe: Qt licensing Pin
David O'Neil16-Feb-13 15:55
memberDavid O'Neil16-Feb-13 15:55 
GeneralFile Not Found Pin
Frigyes Nagy24-Apr-06 9:56
memberFrigyes Nagy24-Apr-06 9:56 
GeneralRe: File Not Found Pin
David O'Neil24-Apr-06 13:09
memberDavid O'Neil24-Apr-06 13:09 
GeneralBeside those that you have mentioned Pin
Anthony_Yio23-Apr-06 22:00
memberAnthony_Yio23-Apr-06 22:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.180111.1 | Last Updated 8 May 2010
Article Copyright 2006 by David O'Neil
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid