This line-
QueryInterfaceProto TYPEDEF PROTO lpThis:LPTHIS,iid:REFIID,ppvObject:PPVOID
gives this error-
Error A2091: Language type must be specified
I don't have a masm 64 reference manual, but the 32 bit manual says language is optional.
Jim,
ML64 does not use prototypes.
This line came from \masm32\include64\win64.inc, so I'm not understanding something here. What is the purpose of the line if it's not a proto?
It probably has to do with it being a TYPEDEF. Vasily wrote some of this stuff so I can really help you there. If you are writing 64 bit MASM, you don't use prototypes.
Okay, I can believe that the error is because it's a typedef, not a proto.
I think it's still a problem that it's accepted in ml64 but not uasm64.
And still, if ml64 doesn't use protos, shouldn't win64.inc be fixed up?
Jim,
I don't have time for a wild goose chase, take my word for it that ML64 does not use prototypes, if you have the time to waste, write a prototype for a test procedure then enter the wrong data to call the procedure and the prototype will do nothing. ML64 does not use them.
Quote from: hutch-- on July 27, 2018, 03:54:08 AMwrite a prototype for a test procedure then enter the wrong data to call the procedure and the prototype will do nothing. ML64 does not use them.
ML64 is really an ill-mannered pig, but it can be taught to behave better:
include \Masm32\MasmBasic\Res\JBasic.inc
Init ; OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
jinvoke MessageBox, 0, Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format"), Chr$("This will build fine"), MB_OK
; jinvoke MessageBox, Chr$("This will not build"), MB_OK ; error: ## not enough arguments for MessageBox ##
EndOfCodeCan be built with UAsm, too 8)
Hi, not big deal but ML64 automatic do cdecl calling for all types protos and proc, but uasm its off for user selection of preferred calling convention for WIN64.
its possible to pass the .inc with an UASM option to add the calling, langtype for protos and procs.
Example
file.asm
.x64
;option casemap:none ; small case option for typed know types PROTO|proto, PROC|proc etc
option frame:auto
option stackbase:rbp ; RSP or RBP are supported options for the stackbase.
option win64:7 ; 11-15 for RSP and 1-7 for RBP.
option language:C ; Available languages, WIN32 = CDECL = C, FASTCALL, STDCALL. WIN64 = CDECL, FASTCALL(ignored but compiles), STDCALL, VECTORCALL.
win64.inc
yourcode......
:biggrin:
jinvoke MessageBox, 0, Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format"), Chr$("This will build fine"), MB_OK
MASM
invoke MessageBox,hWnd,"This was built in Microsoft Assembler","About MASM",MB_OK
I rest my case. :P
In this specific case, both versions will produce a similar MessageBox. The difference is that you can forget the hwnd, and your code will still build. And crash. My jinvoke will just refuse to build, and tell you what your problem is: error: ## not enough arguments for MessageBox ##
What was the purpose of the real invoke macro introduced twenty years ago?
Quote
Error A2091: Language type must be specified
What ML64 version are you using? The latest and greatest or the oldest you could find? :badgrin:
hello sir jimg;
As you perceived ml64 don't do parameters check from function prototypes. Depending how you code you have an option that is switch to masm32 only to do that, just to see if you receive an error message. I was doing this way when I was starting, switching between both.
:biggrin:
> The difference is that you can forget the hwnd, and your code will still build.
The difference is assembler programmers know the argument count of an external procedure, ML64 is not a consumer product, it is an industrial product that does not hold your hot little hand. The only assembler in 64 bit that is MASM compatible is MASM. :P
> What was the purpose of the real invoke macro introduced twenty years ago?
The obvious, to hold your hot little hand. In 64 bit, who cares. :eusa_boohoo:
Would have been a lot easier if the original design for MASM(32 bit or even 16 :P ) in general, were to pass args to the called procedure in registers.
A lot of people are so used to using
push x
push x
push x
push x
call procedure
or
invoke procedure, x, x, x, x.
Makes my brain hurt, trying to do it any other way. I guess I don't have the 'right stuff' for 64 bit coding in MASM.
Z,
In the days of YAW (16 bit MS-DOS) arguments were passed in registers to system functions when interrupts did not mean an unreliable means of contraception. PUSH / CALL syntax worked OK but it made for slower code and increased complexity. With the advent of 64 bit x86-64 processors with twice as many registers, its a no brainer to use them to pass arguments as a vast number of API calls and procedures have 4 or less arguments., now its reg, reg, reg, reg, write to stack, write to stack etc .... :P
My take on this is that using PROTOTYPES in 64-bit MASM is the last opportunity you have to become aware that functions do have parameters and sneak a peek at what they are.
It is completely different to write:
ExitProcess PROTO :dword
than to write:
PPROC TYPEDEF PTR PROC
extern __imp_ExitProcess:PPROC
ExitProcess equ <__imp_ExitProcess>
The second option takes unfair advantage of ML64 being a dumb beast that swallows everything we throw at it. :lol:
It serves also as an excuse for INVOKE macros being unable to validate prototype parameters as real INVOKE internals features use to do.
My original post was to point out either one of two things should be fixed-
1. Hutch's Win64.inc has four proto lines without language. Either the lines should be fixed by adding the language (this works, I tried it), or if as Hutch says, ml64 ignores protos, remove them. Since ml64 is not giving an error, I suspect the author did not know to fix them. I'm not a proponent of ignoring incorrect code just because it does not cause an error.
2. Because Hutch has in the past been reluctant to fix things like this if they are working for him, I suspect Uasm will have to be updated to use a default language. This is also something unlikely to happen since it is not Uasm's problem.
"Can we just all get along?"
I think it's posible to make a macro system to count arguments, test size of each argument, etc. But you have to make the definitions ( or PROTO) compatible with that system. A lot of work.
Quote from: HSE on July 27, 2018, 11:13:48 PMI think it's posible to make a macro system to count arguments, test size of each argument, etc.
Yes, that's possible (http://masm32.com/board/index.php?topic=5314.msg59884#msg59884), since August 2016. The
jinvoke macro has well over 300 lines, but it works fine with ML64, UAsm and AsmC, and it doesn't need any extra includes, just a MasmBasic installation. It can "hold your hot little hand", but remember, real men
TM don't need such tools 8)
@jimg,
I don't think there is any error or need for a language specifier in Win64.inc when it declares QueryInterfaceProto. This is the reason I asked what version of ML64 are you using.
On the other hand the Jwasm & UASM WinInc is extremely buggy when it comes to 64-bit. Fixing and updating it is a boring work that nobody will ever dare to do.
Jim,
Quote
1. Hutch's Win64.inc has four proto lines without language. Either the lines should be fixed by adding the language (this works, I tried it), or if as Hutch says, ml64 ignores protos, remove them. Since ml64 is not giving an error, I suspect the author did not know to fix them. I'm not a proponent of ignoring incorrect code just because it does not cause an error.
2. Because Hutch has in the past been reluctant to fix things like this if they are working for him, I suspect Uasm will have to be updated to use a default language. This is also something unlikely to happen since it is not Uasm's problem.
What you are doing here is saying that if you don't understand it, delete it. Now if you cannot comprehend the massive hours to fix this file in the first place so that it build most thing correctly, feel free to get off your arse and write your own. You are hardly in a position to dictate what stays and what is deleted in files that have taken some massive amount of work to fix and any changes or additions are very carefully done because if you had ever edited a major include file for ML64 you would find that it is extremely intolerant of include file errors and will dump multiple screens of garbage at you for getting it wrong.
I gave you the right advice the first time, ML64 does not use prototypes, it is a mistake to try and inflict your understanding of the 32 bit ML on what ML64 should be, its an entirely different tool that just does not work the same way. Vasily wrote the original include file in a very different way to how I write them and I had to untangle a massive number of TYPEDEF statements to get the file reliable. The file will not be modified at your request as you don't know what the effect will be from doing it.
As before, feel free to write your own.
Uncle.
It's not called a hangover. It's called wine flu.