News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

ml64 vs uasm64 syntax for proto

Started by jimg, July 26, 2018, 06:36:24 AM

Previous topic - Next topic

aw27

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.


jimg

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?"

HSE

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.
Equations in Assembly: SmplMath

jj2007

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, 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 menTM don't need such tools 8)

aw27

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




hutch--

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.


aw27

It's not called a hangover. It's called wine flu.