The MASM Forum

Concerning 64-bit programming with HJWASM, is to possible to consider that everything can be QWORDs in include files? ( like DWORDs in masm32 include files ) :  My intention is to convert all the DWORDs to QWORDs for 64-bit compatibility.

A quick example, kernel32.inc :

ActivateActCtx PROTO :QWORD,:QWORD
AddAtomA PROTO :QWORD
AddAtom equ <AddAtomA>

AddAtomW PROTO :QWORD
AddConsoleAliasA PROTO :QWORD,:QWORD,:QWORD
AddConsoleAlias equ <AddConsoleAliasA>

AddConsoleAliasW PROTO :QWORD,:QWORD,:QWORD
AddLocalAlternateComputerNameA PROTO :QWORD,:QWORD
AddLocalAlternateComputerName equ <AddLocalAlternateComputerNameA>
.
.
.


That would probably work, in that case it would be better to use INT_PTR and than it would be valid for both 32 and 64 bit, however, that would be the same as ToutEnMasm's SDK with XMASM.
WinInc can be used in both 32 and 64 bit and it shows what kind of data is used:

Quote
Add typedef proto stdcall :HBITMAP,:HBITMAP,:ptr DWORD
ReplaceIcon typedef proto stdcall :DWORD,:HICON,:ptr DWORD
SetOverlayImage typedef proto stdcall :DWORD,:DWORD
Replace typedef proto stdcall :DWORD,:HBITMAP,:HBITMAP
AddMasked typedef proto stdcall :HBITMAP,:COLORREF,:ptr DWORD
Draw typedef proto stdcall :ptr IMAGELISTDRAWPARAMS
Remove typedef proto stdcall :DWORD
GetIcon typedef proto stdcall :DWORD,:DWORD,:ptr HICON

IMHO it would be better idea to concentrate on going through WinInc and recheck everything to work properly,
It could be a collective task, we could share headers to be tested. 

Hi habran,

Thanks for the information. I will try WinInc, it's a nice and sophisticated work. I will try the all everything is QWORD method.

On x86-64, when you move a value using 32 bits register it "zero' upperside of 64 bits register.
eg:
mov rax,-1
mov eax,12345678h

now rax is not 0ffffffff12345678h, instead it is 0000000012345678h.

You need change structure alignment to 8 by command line, handles (all structure members that start with 'h' on masm32 include will be qwords), all members that start with 'lp' and 'p' (pointers) are now 64 bits too. Equates remains the same, don't need touch. Functions prototipe only the ones that need handles,pointers and long pointers are 64 bits.
So, wParam, lParam and uMsg are 32 bits, hWnd is 64 bits, but you can consider use 64 bits because that fact above.

Quote from: mineiro on July 12, 2016, 09:32:16 AMSo, wParam, lParam and uMsg are 32 bits, hWnd is 64 bits, but you can consider use 64 bits because that fact above.

Does that mean DefWindowProc works with mixed size arguments?

JJ,

If you save the 4 registers that are passed to the WndProc into locals, you use them with DefWindowProc() as the 4 arguments required and you have no reason to change from 4 QWORD variables from the original 64 bit registers.

I do not have tested ok, I do not have winx86-64, but, if you have function below:

WndProc   proc hWnd:Qword,uMsg:dword,wParam:dword,lParam:dword
        ret
WndProc   endp

But parameters are passed by registers rcx,rdx,r8,r9
so, dwords turns into qwords.

WndProc   proc hWnd:qword,uMsg:qword,wParam:qword,lParam:qword
mov hWnd,rcx
mov uMsg,rdx
mov wParam,r8
mov lParam,r9
        ret
WndProc   endp

And above code is supposed the same as below

WndProc   proc hWnd:qword,uMsg:qword,wParam:qword,lParam:qword
mov hWnd,rcx        ;<-qword
mov uMsg,edx
mov wParam,r8d     ;<-dword
mov lParam,r9d
;----above is prologue of this code
;here goes your code
;---below is epilogue of this code, supose you don't remember if registers rcx and rdx is trashed
;so you move from function parameter to register back again
mov rcx,hWnd
mov rdx,uMsg
mov r8,wParam
mov r9,lParam
call DefWindowProc
;...
        ret
WndProc   endp

---edited---
inserted defwindowproc.

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
WndProc proc hWnd:QWORD, uMsg:DWORD, wParam:QWORD, lParam:QWORD

If you can find a reliable way to get the argument count in API functions then you can automate an entire set of Win 64 prototypes that match the libraries. Getting the names out of Microsoft format libraries is a reasonably simple operation, just scan the library for the starting "imp" notation then copy it up to the following zero terminator. Its the argument count that cannot be obtained from the libraries. Perhaps a full scan of the Microsoft header files could produce the argument count.

Quote from: habran on July 12, 2016, 07:18:11 PM
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM
WndProc proc hWnd:QWORD, uMsg:DWORD, wParam:QWORD, lParam:QWORD

Yes, wParam and lParam are qwords, thanks for correct.
uMsg being dword is pseudo promoted to qword, as Chen say, upperside is ignored.
And this point can create confusion, because if somebody is coding thinking with qwords but the real meaning is dword so weird things can happen.
So, I think it's better define types exactly
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx

QuoteSo, I think it's better define types exactly

Yes, that is why WinInc is the best solution.

It just happens to be a matter of fact that the 4 arguments passed to a WndProc are 64 bit registers and even if only the bottom 4 bytes are used, they are still QWORD 64 bit registers. Be careful what you wish for using WinInc as it locks you into the Microsoft "mystery bag" style of header files. You cannot enforce strong typing in assembler as the data always collapses to assembler data sizes. If you want strongly typed data, use a C compiler.

Microsoft "mystery bag" style of header files:
WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

opposite to perfectly clear what we are doing:
WndProc proc hWnd:QWORD, uMsg:QWORD, wParam:QWORD, lParam:QWORD

Aussie way of thinking ::)

How many more years I have to spend in OZ to start thinking upside down, or it is a gift only to people born here :icon_confused:

Quote from: habran on July 13, 2016, 08:19:49 AMHow many more years I have to spend in OZ to start thinking upside down

Just to help get in the mood you ought to turn your Godfather avatar upside down :)

Thanks for the advice rrr314159, I'll think about it :bgrin:

I think you should use that avatar instead of me because you are the one who first renamed JWasm to HJWasm ;)

Quote from: habran on July 13, 2016, 08:19:49 AM
Microsoft "mystery bag" style of header files:

Code Select Expand

WndProc proc hWnd:HWND, uMsg:UINT, wParam:WPARAM, lParam:LPARAM

opposite to perfectly clear what we are doing:

Code Select Expand

WndProc proc hWnd:QWORD, uMsg:QWORD, wParam:QWORD, lParam:QWORD

I am with Hutch on this one, for the simple reason that an assembly programmer spends a lot of time debugging. And in the debugger you see a QWORD 8)

To the extent I understand the issue I also agree with hutch. When I had any trouble with WinInc files (may have been my fault) I often fixed it simply by changing everything to QWORD. The attempt to force strong-typing onto assembler is misguided.

But a note of caution, that obviously doesn't work with structure definitions, of which there are a lot. They often must use specifically bytes or dwords.

When I meet first time masm32 project I think this way too, all prototypes are dword, it's easy to understand. I like this minimalistic way, we as being programmers only need two types, signed and unsigned. So I spend a lot of time on structures, trying to understand that jargon used, what are handles? what are these things? I learned so much about masm directives, like equates, typedefs, macros, ..., and not only this, I have started recognize not onlyC and C++ sources because that typedefs, but others languages too .
Now I changed my point of view.
Imagine that all prototypes have been done using typedefs, so to update masm32 includes, structures, ..., to win64 is just few steps, you only need change 20 lines more or less, and all prototypes, structures can be mutually used on masm32 or masm64.

That is what WinInc aready is, it can be used for both 32 and 64
However, as I said before, people like to choose the worst option if you give them a chance to choose

I's very useful to learn about types, handles, and "all that jargon" because we have to deal with C++ people and resources a lot. But that doesn't mean our include files have to be written that way.

As for using 32 and 64 - I always used separate includes and libraries, and thought that was necessary. Are you (habran and mineiro) saying WinInc is set up to use one set of includes for both? So, at the beginning it has equates to set "HANDLE" (and so forth) to either QWORD or DWORD as appropriate, then all the rest is written with "HANDLE" and it works for both 32 or 64. I didn't know that. If that approach works, fine. But even in that case I think I'd prefer to put "QDWORD" everywhere then set it to either 4 or 8 bits once at the top. In WinInc 64-bit includes, how many different names are there that all mean, simply, QWORD? I guess it's at least 100. For assembler none of them are necessary.

Having said that, whoever does the job of producing working include files is welcome to do it his way. I appreciate their efforts, and unless I want to do the work myself have no grounds for complaint.

The solution for what habran is after is in fact to use only the Microsoft C/C++ header files and make a front end for the assembler that can read them. That would solve all of the problems in creating include files.

I like to have readability of code.
When using WinInc it is easy to convert some good C snippet to asm and optimize it.
With all of HLL built in HJWasm there will be no big visual difference, however a great improvement in quality and speed.
WinInc can be used for both 32 and 64 bite without any change except which version you want to build

Here is what I use in most of my x64 assembly programing:

Quote
option casemap : none
option win64 : 11
option frame : auto
option stackbase : rsp
.nolist
.nocref
WINVER EQU 600h
WIN32_LEAN_AND_MEAN equ 1
_WIN64    EQU 1
include windows.inc
include string.inc
include guiddef.inc
include regexpfunc.inc
include CommCtrl.inc
include winbase.inc
include shellapi.inc
include winuser.inc
include commdlg.inc
include Richedit.inc
include OLE2.inc
include windef.inc
include AkelBuild.inc
include AkelEdit.inc
.list
.cref
includelib advapi32.lib
includelib user32.lib
includelib kernel32.lib
includelib gdi32.lib
includelib comctl32.lib
includelib Shell32.lib
includelib comdlg32.lib
includelib Ole32.lib
includelib uuid.lib

It does look like a tidy layout but it still has the problem that the user must know which Microsoft named include file must be used as they don't match the import libraries.

This point I agree with sir Hutch, on both scenarios.
An assembler that can understand C header will be an addendum. And about include files that holds specific function names of libraries. Solasm assembler know few C header names, this is a good point.

I have learned that .h files holds equates that they call "#define". Other way they do that is doing an enumeration, that are equates again but on growing order. Have macros that I cut all and don't ue and have too data types definitions.

I have started translating gtk header files and by using data definitions make better reading while coding.
If you see the code line below on source code:
local somestrangename:GtkWidget
You know 2 things from GtkWidget, first is that is a dword on 32 bits or qword on 64 bits O.S. (being windows or linux), and second thing is about hierarchy as gtk is Oriented Object, so have heritage on names too. This is valid on windows side too, we can code using paradigms, procedural way that we know (many if's and compares) and like a black box. I'm learning this new concept, it allows a lot modular code, so, write only one time and use forever.
Have another point that native english speakers don't care about, it's language. Generally official manual language is english language. But on open source way you are able to translate manual into your own language. This makes learning curve quickly to foreginers. So, if somebody will translate that manual, it will preserve that type names.
My opinion is that sir Hutch dominates the jargon and fully control vernacular way. I'm like this on my own language. And was hard to me learning programming because language obstacles.

I can assure you that your English is better than my Russian and I have had to translate a reasonable amount of it recently. At least I can read the code.

Quote from: rrr314159 on July 14, 2016, 09:30:47 AMIn WinInc 64-bit includes, how many different names are there that all mean, simply, QWORD? I guess it's at least 100. For assembler none of them are necessary.

They might not be necessary, but it makes it so... aristocratic. Imagine they would have called Edward Albert Christian George Andrew Patrick David simply "Edward" ::)

You can write in your code:

db C7,84,24,E4,00,00,00,03,00,00,00

or:
mov       dword ptr [rsp+0E4h],3   

but I prefer:
mov       wc.style, CS_HREDRAW or CS_VREDRAW

Quote from: habran on July 15, 2016, 05:50:58 AMbut I prefer:
mov       wc.style, CS_HREDRAW or CS_VREDRAW

I prefer m2m :icon_mrgreen:

.data
  wcx WNDCLASSEX <WNDCLASSEX, MyWinStyle, WndProc, 0, 0, 1, 2, 3, COLOR_BTNFACE+1, 0, txClass, 4>
  wc equ [ebx.WNDCLASSEX] ; we use an equate for better readability
.code
  mov ebx, offset wcx
  int 3
  m2m wc.style, CS_HREDRAW or CS_VREDRAW  ; 5 bytes short
  mov wc.style, CS_HREDRAW or CS_VREDRAW  ; 7 bytes long
  mov wc.hInstance, rv(GetModuleHandle, 0)

0040107D         ³?  6A 03              push 3                                        ; ³
0040107F         ³?  8F43 04            pop dword ptr [ebx+4]
00401082         ³?  C743 04 03000000   mov dword ptr [ebx+4], 3
00401089         ³?  6A 00              push 0                                        ; ³
0040108B         ³.  E8 AA050000        call <jmp.&kernel32.GetModuleHandleA>         ; ³hInst = 0040163A ('MiniWin')
00401090         ³?  8943 14            mov [ebx+14], eax

Actually,  add wc.style, CS_HREDRAW or CS_VREDRAW

is even shorter :biggrin:

 m2m is not good for x64 with option STACKBASE : RSP
PUSH and POP are verboten in that case as Japheth used to say, except if you know exactly what you are doing
but  add wc.style, CS_HREDRAW or CS_VREDRAW is  8)

mov wc.hInstance, rv(GetModuleHandle, 0) is good 8)
I use two kind of these macros: dwinvoke and qwinvoke, so if that was x64 I woul use:
mov wc.hInstance, qwinvoke(GetModuleHandle, 0)

 :biggrin:


    mrm MACRO target,source
      mov rax, reparg(source)
      mov target, rax
    ENDM



    LOCAL var :QWORD
    mrm var, "This is plain text"

Yeah babe :eusa_clap: