The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

WNDPROC - how you handle it today?

Secretly, I have always had issues with the Win32 API.  It is well documented and pretty pervasive.  But,everytime I write a Win32 GUI application, I think to myself, "What in the world?"

This system was created a long time ago; it is 2005, if Microsoft asked you to write the Win32 API, what are some things you would change.  Me, I would drop the approach towards WNDPROC.  Now, I am trying to port some Win32 code to a new language and can't figure out the best approach.

if you don't know what I am talking about, here is a some C code:

LRESULT CALLBACK SomeWndProcFunction(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam)
      case WM_CREATE:

Here is our 'WNDCLASSEX WndClass' struct:        = 0;
// This is it here!!!!
SomeWndClass.lpfnWndProc  = SomeWndProcFunction;
SomeWndClass.cbClsExtra    = 0;

Then we register all that stuff above:


Outside of finding a way to get rid of WNDPROC, I would not have made such overruse of the preprocessor, or at least without some common-sense mapping back to the C-type.

A HWND would be 'void*' and that is it, I would use C types.
Berlin Brown Send private email
Thursday, August 04, 2005
The 'overuse' of the preprocessor macro's is unavoidable if you want to have any hope to be able to cleanly recompile your code when some future version of windows requires changes to the sizeof() of things like HANDLES, HWND's etc., e.g. as in the current transition of WIN32 to WIN64.
The Real API Send private email
Thursday, August 04, 2005
I assumed there are a billion reasons.  Maybe if they reduced the use of macros and typedefs.
Berlin Brown Send private email
Thursday, August 04, 2005
If you don't like Win32 API, you should start looking at WinFX for Windows Vista - WinFX is supposed to replace Win32 API just as Win32 API replaced DOS in the past.

Otherwise, i would suggest developing a model which encapsulates static Win32 API function calls into object-oriented classes, such that you can transform switch-case statements like "WM_CREATE", "WM_PAINT" into "onCreate()" or "onPaint()".
Aaron Send private email
Thursday, August 04, 2005
While I can live with the WndProc structure, programming in pure C, I find it much much more annoying that you need to (cast) all your way down your code. Not any now and then, like using

ucharval = (unsigned char)(uintval & 255);

to silence overparanoid compilers for the "possible loss of precision", BUT ALL THE #*$ TIME, assuming a given 32 bit oriented memory model. Giving anything through wParam and lParam, it is a pointer to a structure then, a 32 bit value then, combined x and y coordinates then, and so on and so on. Cast this there and that here, or the other way around.

Well, in fact it doesn't matter, since Windows is only compatible to itself, I have to carefully encapsulate the whole things anyway to reach a maximum of portability. Absolutely NO business logic in the UI, absolutely NO Windows typedefs and macros in the business logic, and anything is fine, so far.

Thursday, August 04, 2005
To avoid casting you can use "message crackers" that are in windowsx.h (well, actually they do the casting for you, so that you don't have to worry about it).
Parisian developer ISO cute geek girl
Friday, August 05, 2005
At the risk of a contentious suggestion, I'd say I'd probably use standardized api's, for instance be as POSIX-compliant as I could, and not introduce new api's and massively market it all the time. (The Unix API's have been fairly stable for a _long_ time, for instance, and all major OS's except MS use them).

Sure, there's alot of annoying incompatibilities from time to time, for instance Linux for the longest time hasn't had quite POSIX-threading (Much better now with NPTL), but at least it isn't a complete and fundamental shift with windows.

Having said that, by all means C# and .NET is cool, but to my mind, that's just one vender's wrapper for their own low-level api's, and we are dealing with the low-level api's.
Wednesday, August 31, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz