Message argument data types

I wonder if anyone can point me to a definitive list of the correct data types for the arguments of windows messages? I would also quite like to know the 'correct' formal name of these parameters, if only to keep my code readable. I seem to recall the old documentation that accompanied 'Visual C++ v4.0' did so, but the modern help files that come with 'VisualStudio 2017 Community' have changed format entirely and seem to have lost most of this vital information along the way.

For instance, assuming the place holders wParam and lParam respectively I believe the parameters which accompany WM_CHAR map to:

static_cast<TCHAR>(wParam) = ChCharCode

while

lParam = lKeyData directly.

My own research has shown the 'winapi.freetechsecrets.com' web page does seem to provide some of these data. That is where I learned the WM_CHAR parameters mentioned above. However is is not an exhaustive list nor entirely authoritative. For instance they say WM_GETDLGCODE has no arguments while it very definitely does--wParam contains the nVirtKey parameter and lParam casts into a pointer to an MSG structure. Also I find it quite hard to navigate!

Is there perhaps an official book or *.PDF that lists them all?
Last edited on
Many thanks JayhawkZombie!!! That does look to be a comprehensive list and a good part of what I am after.

I have myself continued to look for something similar to the old-style VC4.0 documentation and eventually turned up this website:

http://laurencejackson.com/win32/

The forum it is connected to seems to be for a completely third-party version of BASIC that I have never heard of before called 'PowerBASIC'. Apparently it does not use the '.NET' CLR nor a proprietary pseudo-code and interpreter of its own. In this it sounds rather like 'VisualBasic v6.0' as it will compile and link all the way down to native binary code, just like C/C++ and Delphi. I shall have to check it out in the future as a lifetime license apparently only costs about £70! Excellent value.

Anyway, the *.CHM help file that page offers is apparently a re-mounting of all the reference material from the Win32 SDK circa 1998, which in style if not content is exactly what I am looking for! Obviously it does not document the newer material that came after, but for now it seems to cover most of the basic (no pun intended!) windows programming details that I am after--messages and their parameters along with the types and formal names of these parameters.

I will leave this question open for a little longer in case anyone can add further suggestions, but I think between JayhawkZombie's excellent find and the 'PowerBASIC' Win32 SDK *.CHM file I may just have what I need for now.

Update:
I have done a bit more searching, but can find nothing better than the combination of JayhawkZombie's excellent find and the 'PowerBASIC' Win32 Reference *.CHM. Accordingly I am going to mark this question as answered.
Last edited on
PowerBASIC has been my main compiler for most of the last 20 years. Its nothing like VB6. If I had to describe it to a C++ coder in terms of actually what it is, I say a high level version of MASM. With it you can create a stand alone GUI executable with no runtime dependencies of only 6 or 7 k. Most of what C++ coders get out of external libraries is built into the language. While I still use it, I've gravitated most of my coding to C++ because PowerBASIC does not produce 64 bit code. Its a 32 bit compiler which generates 32 bit code. The creator of the language passed away in the process of creating a 64 bit compiler, and I doubt anyone will be able to port the compiler code written in MASM to 64 bit. Many PowerBASIC users gravitated to Freebasic. I simply moved to C++. In saying that I have to say trying to do with C++ what I was able to accomplish with PowerBASIC was extraordinarily difficult. I had to create my own version of the C Runtime, and create my own String Class just to give you some idea. Took me a number of years but finally accomplished it. If 32 bit code suits you I'd give PowerBASIC a close look.
That does sound fascinating! Even to an observer it feels like a colossal loss, both for the gentleman's family of course but also the wider programming public that the person behind this has died. Simply for one man to produce what sounds like such a massively professional product is an accomplishment all its own. I hope someone or a volunteer group are able to step in and finish the 64Bit work.

I myself came to C--and then C++--directly from Atari BASIC in the early eighties. The lack of a native string variable type was a huge hurdle to overcome, so I totally understand what you mean about having to write your own class. Admittedly in Atari BASIC you still had to define the length of your strings in advance. However even then DIM $STRING(100) is a lot easier to use than the jury-rigged C approach of manhandling an array of char variables so they represent a string via dynamically-allocated memory and a manually assigned null-terminator... At least it seemed pretty botched back then! Oddly enough though I quite enjoyed the weird near/far pointer DOS memory model.
Last edited on
Yes, it was a staggering loss for Bob Zale to pass away when he did. He devoted his life to writing compilers. It was his passion of passions. What happened is his wife tried to keep the company going for a number of years, but she eventually had to sell the company to a fairly large software firm that specializes in tax software. I'm hoping they will be able to produce a 64 bit compiler, and I'm certain they are quite competant, but I'm not sure very many folks are up to the level of genius that Bob Zale was.

I'm busy right this moment, but since you are interested, later I'll post some C++ verses PowerBASIC versions of the same code, and I'll explain the variable types involved, which are interesting.
I look forward to seeing that freddie1! Many thanks!.

Here is what I consider to be the simplest possible Windows GUI program written against the Windows Api, i.e., no class frameworks, that nonetheless uses RegisterClassEx() to register a Window Class, and CreateWindowEx() to create a window...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// cl Main.cpp /O1 /Os /MT user32.lib
#include <windows.h>

LRESULT CALLBACK fnWndProc(HWND hwnd, unsigned int msg, WPARAM wParam, LPARAM lParam)
{
 if(msg==WM_DESTROY)
 {
    PostQuitMessage(0);
    return(0);
 }

 return (DefWindowProc(hwnd, msg, wParam, lParam));
}


int WINAPI WinMain(HINSTANCE hIns, HINSTANCE hPrevIns, LPSTR lpszArgument, int iShow)
{
 char szClassName[]="Form1";
 WNDCLASSEX wc;
 MSG messages;
 HWND hWnd;

 memset(&wc,0,sizeof(wc));
 wc.lpszClassName=szClassName;                wc.lpfnWndProc=fnWndProc;
 wc.cbSize=sizeof (WNDCLASSEX);               wc.hInstance=hIns;
 wc.hbrBackground=(HBRUSH)COLOR_BTNSHADOW;
 RegisterClassEx(&wc);
 hWnd=CreateWindowEx(0,szClassName,szClassName,WS_OVERLAPPEDWINDOW,75,75,320,305,HWND_DESKTOP,0,hIns,0);
 ShowWindow(hWnd,iShow);
 while(GetMessage(&messages,NULL,0,0))
 {
    TranslateMessage(&messages);
    DispatchMessage(&messages);
 }

 return messages.wParam;
}


I used command line compilation with Visual Studio 2008 (that's an old version) and built as 32 bit. My command line compilation string is at top. I'm seeing 37,376 bytes for the stand alone executable built /MT linkage, i.e., no dependencies except a valid Windows installation. Now, that same program built with the newer Visual Studio build chains is 80 to 100k.

Now, here is what that exact program looks like in PowerBASIC...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#Compile Exe        "Form1.exe"
#Dim                All
#Include Once       "Windows.inc"

Function fnWndProc(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
  If wMsg=%WM_DESTROY Then
     PostQuitMessage(0)
     Exit Function
  End If

  fnWndProc=DefWindowProc(hWnd, wMsg, wParam, lParam)
End Function


Function WinMain(ByVal hInstance As Long, ByVal hPrevIns As Long, ByVal lpCmdLn As Asciiz Ptr, ByVal iShowWnd As Long) As Long
  Local szAppName As Asciiz*16
  Local wc As WNDCLASSEX
  Local hWnd As Dword
  Local Msg As tagMsg

  szAppName="Form1"
  wc.lpszClassName=VarPtr(szAppName)   : wc.lpfnWndProc=CodePtr(fnWndProc)
  wc.hInstance=hInstance               : wc.hbrBackground=%COLOR_BTNFACE+1
  wc.cbSize=SizeOf(wc)
  RegisterClassEx(wc)
  hWnd=CreateWindowEx(0,szAppName,"Form1",%WS_OVERLAPPEDWINDOW,200,100,325,300,0,0,hInstance,ByVal 0)
  Call ShowWindow(hWnd,iShowWnd)
  While GetMessage(Msg,%NULL,0,0)
    TranslateMessage Msg
    DispatchMessage Msg
  Wend

  Function=msg.wParam
End Function


Here is the compiler output for the above...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
PowerBASIC 10 for Windows

Copyright (c) 1996-2011 PowerBasic Inc.

Englewood, Florida USA

All Rights Reserved



Primary source:  C:\Code\PwrBasic\PBWin10\Forms\Form1\Form1A.bas   {191328 total lines}

Target compilation:  Form1.exe

Compile time:  0.9 seconds, at 12755200 lines/minute



960 bytes compiled code, 3276 bytes RTLibrary,

12 bytes string literals, and 2692 bytes dgroup.

Executable stack size:  1048576 bytes.

Disk image: 7680 bytes   Memory image: 5980 bytes.


So PowerBASIC's code generation is so tight that its creating the exact same program in 5980 bytes, which is a very, very small fraction of what Microsoft's compilers can do, seemingly.

Also, note the compilation speed. Much, much faster than any C++ compiler out there. PowerBASIC is written in pure handcrafted assembler.

There's a whole lot can be said about the above, but unfortunately, my time is limited right now. I'll have more time in 10 days or so.

But I'll say this. The above C++ code can be built by the older Mingw build chain to 7168 bytes, which is close to the PowerBASIC build size. Whole lot going on there too. Mingw uses msvcrt.dll for its C Runtime which Microsoft is furious about. But its a key to what's going on.

On the variable types. PowerBASIC variable types are exactly like MASM. A 32 bit unsigned variable is a Dword. This simplifies all the ridiculous Windows C/C++ data types which are HANDLEs - which are all 32 bit unsigned numbers in x86 builds, and 64 bit unsigned integers in 64 bit builds. In C parlance you have a ridiculous assembladge of things like...

HWND - Handle to Window
HDC - Handle to Device Context
HBRUSH - Handle to Brush

...etc, ad infinitum. In PowerBASIC, they are all Dwords. You'll see in my PowerBASIC WinMain....

1
2
3
4
5
6
7
Local hWnd As Dword
[//CODE]

If I needed an HDC for a Handle to a Device Context, it would be not this (in C parlance...

[CODE]
HDC hDC


but this...

 
Local hDC As Dword


They are all 32 bit unsigned integers. So PowerBASIC is a 'weakly typed' programming language. That's actually my personal preference. I'm 64 years old, and have been writting code since Fortran days on main frames in the 1970, and in my entire programming career I have never encountered a bug in my code that could have been prevented by a strongly typed programming language like C++. All this nonsense in C++ about type safty and all these bizarre syntactically ugly casts is in my opinion nothing but vanity and vexation of the spirit.

To facilitate interaction with the Windows Api and C/C++ code, PowerBASIC includes a full set of fixed length string variable types that somewhat mimic...

 
char szBuffer[128];


or...

 
wchar_t szBuffer[128];


In PowerBASIC that would be...

 
Local szBuffer As Asciiz*128


or...

 
Local szBuffer As WStringZ*128


The later would be 'Wide Character Z String or zero terminated string. The PowerBASIC language automatically null terminates Z Strings. In my PowerBASIC code above I used a szClassName Asciiz*16 to contain the name of the class. Note it can be assigned through direct assignment with the '=' sign as opposed to in C/C++ one would need strcpy/wcscpy to copy characters to it.

The WPARAM and LPARAM parameters to a Window Procedure are just Longs or Dwords in PowerBASIC. They are not typed as anything special like in C/C++. Basically, in 32 bit builds integers are either signed or unsigned. There aren't any other alternatives. C makes a mess out of it with all these platform specific data types, i.e., LPARAM, WPARAM, HINSTANCE, HWND, HBRUSH, HDC, HANDLE, etc., ad infinitum. Can't continue any more now.

That makes absolutely fascinating reading!!! Many thanks for going in to so much detail.

I especially like the simplicity of the data-types. That really strikes a chord with me. The windows 'hEverything' approach becomes very tiring very quickly and if you are programming for the API then you end up using 'reinterpret_cast<>()' or worse still c-style casts almost all the time. This becomes literally all the time inside message-handler functions. Therefore for all the vaunted type-safety you end up immediately undermining it all just to get things done. If you really can do most things as a DWORD then... Wow, just the weight taken off the programmer there is very compelling indeed. I have honestly never really 'got' the C/C++ fetish for so called type-safety.

In regards alternatives to PowerBASIC, I have come across something called 'PureBASIC' which seems to have quite a high reputation and on the surface sounds very similar. Is this anything you have come across Freddie1?
Yes, I've personally given some thought to purchasing PureBasic. It is available in 64 bit which PowerBASIC isn't. Far as I know it is still being actively developed by a French programmer of good reputation. Here is a board you might be interested in...

http://www.jose.it-berater.org/smfforum/index.php

The man who runs that board is a genius, plain and simple. His name is Jose Roca from Spain. Many years ago he honored me by giving me a sub-board on his forum. But I digress. Theo Gottwald from Germany has a sub-board there about PureBasic. You'll find it under my board.

The way I see it is that PowerBASIC was always the best of the best. There simply was never anything to match it. I came close to buying PureBasic though. But when Bob Zale passed away I decided to just use C++. I've put years of work developing my various libraries to get them to the point where I have a close PowerBASIC substitute, involving, like I said, my development of my own C Runtime as opposed to using Microsoft's, which is simply too bloated, and my own classes for Strings, database connections, etc. Far as I'm concerned the C++ Standard Library is unusable for me, as it simply bloats code too much. So I've had to develop substitutes for anything I need from it.

I'd like to give you more detail, but am on the road right now clearing land in Colorado USA to build a log cabin. I'm in a motel now but leaving in a few hours and won't get back on the internet for 10 days or so. Perhaps we can correspond further at that time. I've a lot of tutorial material about PowerBASIC and C/C++ on my board at Jose's site.
No worries!!! Its been a fascinating conversation and we've certainly covered a lot of ground. I'll also check out that forum you mention.

Hope all goes well out in the woods!
Last edited on
Topic archived. No new replies allowed.