Question for Habran.

[hutch--]

Something that was easy to do with ML64 was to create a set of include file for the entire API libraries as the list of names were easily resolved from the import libraries but they only occur in 2 simple forms, the "externdef SendMessageA:PROC" form and the expanded form,

externdef __imp_ActivateActCtx:PANYARGS
ActivateActCtx equ <__imp_ActivateActCtx>

externdef __imp_AddAtomA:PANYARGS
AddAtomA equ <__imp_AddAtomA>
  IFNDEF __UNICODE__
    AddAtom equ <__imp_AddAtomA>
  ENDIF

externdef __imp_AddAtomW:PANYARGS
AddAtomW equ <__imp_AddAtomW>
  IFDEF __UNICODE__
    AddAtom equ <__imp_AddAtomW>
  ENDIF

externdef __imp_AddConsoleAliasA:PANYARGS
AddConsoleAliasA equ <__imp_AddConsoleAliasA>
  IFNDEF __UNICODE__
    AddConsoleAlias equ <__imp_AddConsoleAliasA>
  ENDIF

Now I wonder and the reason why I ask the question, is it possible to use include files of either of these types while using the native "invoke" notation so that a complete set of includes can be done quickly ? It means that more people can get to use either your assembler or Nidud's without having to wait until someone else can provide enough support for them to be able to understand and write code with it.

[johnsa]

I've had a few goes trying to reference these types of declarations via invoke without any luck.
First off we have to have a PROTO and thus the parameters need to be defined and typed.
Even if invoke could work without the proto and use this type of inclusion, you wouldn't have any type-checking/arg-count validation against the calls?

[hutch--]

John,

That is correct but what I had in mind was getting enough stuff up and going so more folks could use it. I have a working "invoke" in ML64 so it can be done, the main idea is its easy to bash out a set of non type checking prototypes so more people can use HJWASM.

[johnsa]

What's wrong with using WinInc ? (if we're talking about the standard WIN32 libs)

[hutch--]

I confess John that I have never liked Japheth's includes as they try and follow the Microsoft headers with only varying degrees of success. I learnt long ago that multiply equated high level data types are a source of endless confusion to people learning assembler and I say this with over 20 years of experience in this area. Where you need prototypes, assembler SIZE based prototypes solved the problem, look up the data SIZE and they know what to do with it.

I asked Habran the question in the first place as it seems he gets very little support from his user base, you need libraries, includes, macros and documentation so that ordinary programmers can use the assembler. I have done the libraries recently using one of Pelle's tools but you need a reliable set of include files and matching dicumentation to make the assembler usable.

[jj2007]

assembler SIZE based prototypes solved the problem, look up the data SIZE and they know what to do with it.

I agree. Install the latest MasmBasic version, select Init in the second, 64-bit, Hello World example, and hit F6. Afterwards, have a look at \Masm32\MasmBasic\Res\DualWin.inc (2 MB, can't post it here). Hint: SIZE_P stands for "size of pointer".

[johnsa]

I tend to agree that all the needless highly typed references from direct header conversion can be a pain (especially when almost all of them result in being a dword or qword after you've followed the chain of definitions).
It might be easier to run a process through wininc and convert all the types back to their primitive counter-parts, a customised version of the assembler could even do that.. as each item would be in the symbol table we'd know it's size and could equate that back, then just write out the include files from the tokenizer.

Then you could have both options, typed and un-typed.