Question about creating include files for HJWASM64

[jj2007]

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)

[rrr314159]

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.

[mineiro]

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.

[habran]

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

[rrr314159]

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.

[hutch--]

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.

[habran]

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:

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

[hutch--]

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.

[mineiro]

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.

[hutch--]

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.

[jj2007]

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.

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" ::)

[habran]

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

[jj2007]

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

I prefer m2m :icon_mrgreen:

Code Select Expand

.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,

Code Select Expand

  add wc.style, CS_HREDRAW or CS_VREDRAW

is even shorter

[habran]

 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)

[habran]

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)