About type indicators and linking

[BlackVortex]

1) Do I really need to specify the data type when filling a structure member ? I see in the structure definition that the types are declared already.

Example :
mov D[nid.uVersion], NOTIFYICON_VERSION   ; it needs the D

2) Do I really need to specify dlls while linking ? Isn't there some way around that ?

Plz don't tell me to rtfm, my brain is fried today   :toothy

3) What can I use to search for a define/structure inside a folder full of headers/includes etc ? There was some utility for that but I can't find it.

[ecube]

you can use the #DEFINE LINKFILES switch in your source to avoiding having to specify dlls(assuming your using the latest verison of donkeys headers) i'm releasing a nice GoASM sdk tommorow that shows a lot of examples of different things. Hopefully you check it out, GoASM rocks!!

[ecube]

also not sure what you meant by the struct stuff but you can do something like

#ifdef structname
invoke MessageBox,0,'defined',NULL,MB_ICONINFORMATION
#endif

to see if its defined

[BlackVortex]

Aha, I used
#dynamiclinkfile kernel32.dll user32.dll shell32.dll
and it's fine now, cool. I don't need to keep editing my build batch file.

About the define I mean, how can I find in which file is (as an example) NOTIFYICONDATA struct defined ? Searching the file contents with windows doesn't give any results.

My first question is also pending   :green

[donkey]

1. GoAsm does not do any type checking at all so if you are moving an ambiguous amount of data you must always specify the size. Since GoAsm does not use the types of structure members except to calculate the size and offsets of members it does not know the number of bytes to move, the constant NOTIFYICON_VERSION has no inherent size either so it must be specified. If you use a register, the size of data is determined by the register size and no indicator is necessary. The PUSH opcode will always assume a DWORD in WIN32 and a QWORD in WIN64, (SIZE_T). The D[ is equivalent to DWORD PTR in MASM, however since MASM stores and remembers the size of the memory operand it is not necessary for most mov's except where casting a type to a different size, GoAsm requires it for all ambiguous mov's.

[ecube]

you can use a fantastic tool named FindALL from http://www.winasm.net/forum/index.php?showtopic=1838, open source, it searches through files for words you specify and writes to a output

example I searched C drive for *.asm files and the word "invoke"

Code Select Expand


"C:\alldll\dll\gui_dll\loaders\asm\asm_loader.asm"
22:     invoke LoadLibrary,offset VBDLL       ;load dll
25:     invoke GetProcAddress,eax,offset FCE  ;get pointer to exported function
29:   ;  invoke FreeLibrary, eax               ;unload dll
31:     invoke ExitProcess, NULL

"C:\alldll\dll\simple\bin\asm_loader.asm"
25:     invoke LoadLibrary,offset VBDLL          ;load dll
etc...


[BogdanOntanu]

1. GoAsm does not do any type checking at all so if you are moving an ambiguous amount of data you must always specify the size. Since GoAsm does not use the types of structure members except to calculate the size and offsets of members it does not know the number of bytes to move, the constant NOTIFYICON_VERSION has no inherent size either so it must be specified.

With all due respect I find this completly unacceptable for a modern assembler.

I can understand that it does help to speed up the assembler BUT it also means that at each move I would have to manually check for the size of the structure member or variable OR else I could have a very bad kind of error that will not be signaled by the assembler.

However with a little extra work the assembler can remember and check the "types" (or at least the sizes) of structure members and variables and IMHO this is a task for the assembler and not for the human.

If you use a register, the size of data is determined by the register size and no indicator is necessary.

This is logical but still an error should be generated if I try to move EAX into a byte or word structure member or variable.

Take my opinion with a grain of salt since I am not involved with GoASM. However I am involved with writing assemblers and the way they do (or should do) things under the hood ...

What somebody will "see" and claim as an advantage for an assembler can and will be seen as an disadvantage by other people.

[BlackVortex]

I read the goasm manual with the explanation for not using type indicators and parameter checking, seems to be mainly to reduce red tape,reduce source script size and readability and allow the programmer freedom to write anything anywhere, not bound by types.

But when using a nice big header/inc library the plan backfires. Having to check each member's size is the true red tape and adds to the source. And sooner or later I will make a mistake and write a dword into a word structure member, overflowing into the next member. Good luck finding this bug    :'(

It would be nice if there was some limited struct member size check and the usage of indicators for overriding it.

[donkey]

Well, for myself I can see Bogdan's point but since I use an IDE (RadASM) the structure definition is never more than an F1 key away. In reality for structures I am less than familiar with I have to check the docs anyway, for structures I am familiar with or my own it is not an issue. It is really something that I no longer miss about MASM and rarely give more than a passing thought to, I guess it all depends on what you're used to, the few times I find myself using MASM I am much more frustrated by having to use macros for simple things like inline strings or unicode (which I am using more and more) or it's inept invoke. There are trade-offs in everything, the main advantage to no type checking is speed of assembly, it takes time to check every instance of mov etc for proper types where in reality you pretty much already know the type. I find the ability to use a label in memory without square braces unacceptable in an assembler for many reasons (it is ambiguous) however there are a majority of assembly programmers who would disagree with me (and do), as Bogdan says what they "claim as an advantage for an assembler can and will be seen as an disadvantage by other people". Type checking is one thing that I neither need nor have ever really longed for, though to be honest when I first broke from MASM it was a bit disconcerting.

Edgar

[BlackVortex]

I just think it's better for the programmer to not have to do anything and just be safe, trusting the holiness of the defines.   :green

(Of course this is just a minor gripe compared to the lack of runtime conditionals)

[donkey]

The defines can be wrong, there is a lot of finger crossing involved in translating structures if you are looking to complete them within a lifetime. For example enumerated types can be of any size, when one is declared in a C++ structure it has no usable size indicator. You can work under the assumption that it is a DWORD and be right 99% of the time and leave the last 1% for bug corrections or you can search through 60MB of include files to see if you can't find a sensible unchained typedef for it knowing all along that Microsoft is notorious for omitting data (especially typedefs) in its headers so not finding it doesn't necessarily mean it defaults to DWORD. In the case of the header project I opted to define them all as DWORDs except a few that were easy to locate so I am sure to get error reports eventually, but from the posts at the MSDN forum Microsoft is still getting bug reports in headers that are more than 10 years old so I am not alone in this.