MASM Bugs & how to overcome them... ----------------------------------- MASM V6.11 was created mainly for 16bit appz like DOS and Windows 3.1 They never tested 32bit compiling enough. I've talk to Microsoft about it a lot and it seems they never knew but assured me all 32bit bugs would soon be eliminated due to Windows 95 usage. Anyways here's what you have to avoid and how to get around it. All the bugs are around the INVOKE command which calls proc in a C style. Here is an example of the problems demo proc,a:dword mov eax,a ret demo endp invoke demo,bx When the above is completed MASM will expand bx to a 32bit register by pushing a 16bit 0 and then BX. But they forget to put a db66h somewhere so they push a 32bit 0 instead and this messes everything up causing great headaches with a lot of fustrating debugging and start to really piss you off BIG TIME!!!!! It also assumes that segment registers when pushed are 16bit and they are not in PMODE. When pushing seg regs in PMODE the CPU pushes a dword not a word. Just for alignment purposes. Note that invoke dword aligns all parameters regardless whether the wanted variable is a byte or word. It just does not do it properly in some cases. case 1-if a dword is expected but a word is given then it messes up NOTE: varargs are all considered dwords case 2-segment registers are assumed 16bit when pushed What I have done is made a macro called 'callp' which does exactly what invoke does but it works. So use callp instead of invoke!!!! Probs with callp: it does not check for parameter matching, it simple just pushes everything as a dword. It may be a little slower but not by much and it is worth it...(it uses movzx eax,var a lot so you can't pass eax to proc unless it's the first one to be pushed, the one on the right) It will let you know when you used EAX when you were not allowed. As long as a movzx was not needed you can use it. eg: callp printf,eax,ebx,ecx,edx ;that's OK callp printf,eax,bx,cl ;ERROR!!