ObjAsm64

[habran]

If you look in Winbase.h in WinInc you will see how it suppose to be to work in both 32 and 64 bit:

Code: [Select]

@DefProto WINBASEAPI, HeapCreate, stdcall, ,     <:DWORD, :SIZE_T, :SIZE_T>, 12
@DefProto WINBASEAPI, HeapDestroy, stdcall, ,    <:HANDLE>, 4
@DefProto WINBASEAPI, HeapAlloc, stdcall, ,      <:HANDLE, :DWORD, :SIZE_T>, 12
@DefProto WINBASEAPI, HeapReAlloc, stdcall, ,    <:HANDLE, :DWORD, :LPVOID, :SIZE_T>, 16
@DefProto WINBASEAPI, HeapFree, stdcall, ,       <:HANDLE, :DWORD, :LPVOID>, 12
@DefProto WINBASEAPI, HeapSize, stdcall, ,       <:HANDLE, :DWORD, :LPCVOID>, 12
@DefProto WINBASEAPI, HeapValidate, stdcall, ,   <:HANDLE, :DWORD, :LPCVOID>, 12
@DefProto WINBASEAPI, HeapCompact, stdcall, ,    <:HANDLE, :DWORD>, 8
@DefProto WINBASEAPI, GetProcessHeap, stdcall, , <>, 0
@DefProto WINBASEAPI, GetProcessHeaps, stdcall, , <:DWORD, :PHANDLE>, 8


[habran]

This is defined in WINASM.INC:

Code: [Select]

;--- macro to define a prototype, either directly or by using
;--- an IAT entry

ifdef _WIN64
WINSTDCALLCONV equ <fastcall>
@DefProto macro apiqual:REQ, name_:REQ, type_, namesuffix, parms, suffix
;;echo defproto: apiqual
%ifidn <apiqual>,<__declspec ( dllimport )>
  proto_&name_ typedef proto parms
  externdef __imp_&name_: ptr proto_&name_
  name_&namesuffix equ <__imp_&name_>
else
  name_&namesuffix proto parms
endif
endm
else
WINSTDCALLCONV equ <stdcall>
@DefProto macro apiqual:REQ, name_:REQ, type_, namesuffix, parms, suffix
;;echo defproto: apiqual
%ifidn <apiqual>,<__declspec ( dllimport )>
  proto_&name_ typedef proto type_  parms
  ifnb <suffix>
    externdef stdcall _imp__&name_&@&suffix: ptr proto_&name_
    name_&namesuffix equ <_imp__&name_&@&suffix>
  else
    externdef c _imp__&name_: ptr proto_&name_
    name_&namesuffix equ <_imp__&name_>
  endif
else
  name_&namesuffix proto type_ parms
endif
endm
endif

;ifdef COBJMACROS


[habran]

As you can see WINSTDCALLCONV  is used to create stdcall or fastcall

WinMain proto WINSTDCALLCONV :HINSTANCE, :HINSTANCE, :LPSTR, :DWORD

[Biterider]

Hi habran
I see the convinience of using a macro for this task. I'll go this way!
What about the return value? As far as I know, UASM is/will be able to evaluate it.
Shouldn't we pass it as an additional parameter?

Biterider

[habran]

Don't bother ;)
That is up to programmer to decide.
The return value is usually in RAX register and we can chose AL, AX, EAX or RAX, depending on our need.
I am glad you liked the macro :t
I like typed parameters as it is now in WinInc, it is more readable
I am happy that You have undertaken that hard task, because I lake your approach to that task and I
trust in your programming skills 8)

[Biterider]

Hi
Good news! 
I have been able to build the first set of include files with the new h2incX (version 0.10).
I've been working on this project for the last few weeks to better support MASM, UASM and ObjAsm with the latest header files for Win10.
The next step is to set up the right switches in a Windows.inc prepended file, named WinAsm.inc, as it was in the original project.
In the analysis of the converted code, I came to the conclusion that creating a tool that works completely without human interaction will be very difficult, at least using this approach. The most important reason is that C works differently than MASM. In C you can create definitions based on things that come later. To understand this, I've expanded the functionality of h2incX to visualize the "Include Tree". There are many cases of symbols that are used before they are defined. It is easy to understand this using this pseudo graphical tree.

After setting the main switches, I have to work a bit more on the COM interfaces and the matching macros.

Biterider