This works for WinMain()...
int __stdcall WinMain(HINSTANCE hIns, HINSTANCE hPrevIns, LPSTR lpszArgument, int iShow)
and this for the Window Procedure...
long __stdcall fnWndProc(HWND hwnd, unsigned int msg, WPARAM wParam,LPARAM lParam)
An LRESULT is just a long. However, the above will only work for 32 bit OS. The calling conventions are different for 64 bit Win. So your best bet by far if you are contemplating Win SDK development (or anything else, for that matter), is to stick to the defines and typedefs in the Windows headers. You really don't have much choice in this.
The thing I find bizarre is that just about all these typedefs used in windows (at least for 32 bit) are just ints of one kind or another, e.g., int, unsigned int. However, we have to deal with HFONT, HBRUSH, LRESULT HINSTANCE, HDC, HNENU, etc, ad infinitum. In all my years of coding I can't remember one time where this sort of thing has saved me from inadvertantly passing the wrong kind of object to a function.
For this reason I find coding in PowerBASIC to be rewarding and more hassle free. Take for example a WM_PAINT handler involving a 'HDC', which is just really an opaque pointer 32 bits in size (for 32 bit OS). In C or C++ you have this...
typedef struct WindowsEventArguments
long fnWndProc_OnPaint(lpWndEventArgs Wea)
char szBuffer="Hello, World!";
And in PowerBASIC one just uses the primitive data type ( long - 32 bits signed) for everything, here HDC...
wParam As Long
lParam As Long
hWnd As Dword
hInst As Dword
Function fnWndProc_OnPaint(wea As WndEventArgs) As Long
Local szBuffer As Asciiz*16
Local ps As PAINTSTRUCT
Local hDC As Long