To whom it may concern,
I read the documentation that came with my version of masm. It shows some examples for using TYPEDEF. After looking at the BNF Grammer that shows how masm sees the different instructions. I
created the following 2 instructions that assembled with no errors but I have found no examples on how to use them. Here are the 2 different examples that I am talking about:
label1 typedef ptr proc
label2 typedef proc
Does anybody have any examples on how to use them?
Thank you for your help.
Welcome to the Forum :icon14:
I have no example ready, but you may find some stuff using the search function (http://masm32.com/board/index.php?action=search;advanced;search=). Use e.g. "typedef ptr proc" to find quite a number of threads. If that's not enough, try to search the old forum. (http://www.masmforum.com/board/index.php?action=search;advanced)
deleted
Thank you for your example jj2007 but the example I am looking for are using these instructions:
label1 typedef ptr proc
label2 typedef proc
I am looking for examples of using user defined proc. I have not found any.
Do these statements create the same user defined type:
Label1 typedef
Label1 typedef ptr
I did not find and examples of using the first statement. Masm gave me no error for either one of the statements. I did find a example of using the second statement. Should the first statement be a error?
No idea. It is difficult to understand out of context what you mean, and we rarely use these constructs, probably because there are better alternatives. Can you post a complete example showing where it chokes, and explaining what you really want to achieve?
All 6 variations are the same.
(Do you mean ?
label1 typedef PROTO
label2 typedef ptr label1)
.486
.model flat, stdcall
printf proto C :ptr, :vararg
ExitProcess proto :dword
label1 typedef ptr proc
label2 typedef proc
.data
msg db "Hello from called function",10,0
.code
myFunc proc
invoke printf, addr msg
ret
myFunc endp
main proc
mov esi, myFunc
call esi
call label1 ptr esi
call label2 ptr esi
lea esi, myFunc
call esi
call label1 ptr esi
call label2 ptr esi
push 0
call ExitProcess
main endp
end
Output:
Hello from called function
Hello from called function
Hello from called function
Hello from called function
Hello from called function
Hello from called function
:biggrin:
Be careful of what you wish for, you can provide sheer confusion and get nothing out of it.
TYPEDEF MADNESS
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
include \masm32\include64\masm64rt.inc
WOTTA_LOTTA_ROT typedef PTR
INT_UNKNOWN_SIZE_AND_NAME_BOVINE_EXCREMENT typedef PTR WOTTA_LOTTA_ROT
YETTA_NUTHA_MINDLESS_TYPEDEF_NAME typedef PTR INT_UNKNOWN_SIZE_AND_NAME_BOVINE_EXCREMENT
WTF_IS_THIS_PILE_OF_CRAP typedef YETTA_NUTHA_MINDLESS_TYPEDEF_NAME
UNKNOWABLE_TYPE typedef PTR WTF_IS_THIS_PILE_OF_CRAP
.code
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
entry_point proc
; bsvar# = bullsh*t variable
LOCAL bsvar1 :UNKNOWABLE_TYPE
% echo +++++++++++++++++++++++++++++++++
% echo UNKNOWABLE_TYPE = varsize(UNKNOWABLE_TYPE) bytes
% echo +++++++++++++++++++++++++++++++++
mov rax, 12345678
mov bsvar1, rax
conout str$(rax),lf
waitkey
invoke ExitProcess,0
ret
entry_point endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
end
:badgrin: :t
Thank you AW. That was exactly what I was looking for.
Do these instruction create the same code?
Label1 typedef
Label1 typedef ptr
According to the listing file if I create code and name them as this:
Label1 typedef
Label2 typedef ptr
Then the listing file shows the attr for Label2 as ptr but shows blank for Label1.
Are they two different types? Is Label2 a pointer type? I think it is.
But I have no idea what type is Label1.
Still trying to understand TYPEDEF.
I love the example from hutch--. :lol:
Have a look at a couple of basic things, there is no difference in 32 bit between a normal DWORD variable and a pointer. In 32 bit ALL pointers are the native data size, 4 bytes in length. The only factor that a processor understands is the data SIZE, not its name. While TYPEDEF statements are usable for renaming data sizes and their use, it comes at the price that you no longer know how BIG the data is and this is an endless source of data size errors.
If you start off the bottom, size based data you are free of the confusion and with practice you will get to remember things like BYTE PTR which is the ADDRESS of a BYTE in memory. A BYTE PTR is standard Intel notation in x86 and while you can TYPEDEF it to things like PCHAR and the like, you gain nothing from doing it and you lose the reference to how BIG the data is.
Thank you for the explanation Hutch--.
So for the examples I was originally talking about:
Label1 typedef
Label2 typedef ptr
Label1 is not a pointer and has no defined size. Shouldn't this be an error when creating it? Masm gives no error unless I attempt to make it local in a proc:
local pmystr1:Label1
c:\masm32\bin\assembly2.asm(152) : error A2195: parameter or local cannot have void type.
Label2 is a pointer it does not need a defined size.
Am I understanding this correctly?
Pretty close to it.
error A2195: parameter or local cannot have void type.
This is the same as in a high level language,
variable =
Its an error if you don't have something to assign to the variable.
You have data types and depending on the OS version, in 32 bit, a PTR is 32 bit, in Win64 a pointer = QWORD (8bytes).
Know the OS version and you know the native data size for a pointer. You have the rest of the integer data sizes,
BYTE
WORD
DWORD
QWORD
There are larger 128 and 256 data types but you won't need them yet.
Destroying Masm small brain, aka Buffer Overflow :bgrin:
.486
.model flat, stdcall
ExitProcess proto :dword
label1 typedef ptr CRAP
.data
msg db 'Blowing MASM',10,0
crap label1 1000000
.code
main proc
invoke Exitprocess, 0
main endp
end
Microsoft (R) Macro Assembler Version 14.20.27508.1
Copyright (C) Microsoft Corporation. All rights reserved.
Assembling: testB.asm
MASM : fatal error A1016: Internal error
Version 14.20.27508.1
ExceptionCode = C0000005
ExceptionFlags = 00000000
ExceptionAddress = 0089F3E7 (00870000) "H:\masm32\bin\ml.exe"
NumberParameters = 00000002
ExceptionInformation[ 0] = 00000000
ExceptionInformation[ 1] = 00008408
CONTEXT:
Eax = 00000000 Esp = 010FF340
Ebx = 00000001 Ebp = 010FF344
Ecx = 00008400 Esi = 00000000
Edx = 00000000 Edi = 00008400
Eip = 0089F3E7 EFlags = 00010202
SegCs = 00000023 SegDs = 0000002B
SegSs = 0000002B SegEs = 0000002B
SegFs = 00000053 SegGs = 0000002B
Dr0 = 00000000 Dr3 = 00000000
Dr1 = 00000000 Dr6 = 00000000
Dr2 = 00000000 Dr7 = 00000000
Quote from: AW on April 17, 2019, 02:00:36 AM
Destroying Masm small brain, aka Buffer Overflow :bgrin:
Just a bug in ML14
X:\masm32\test>ml crap.asm
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: crap.asm
crap.asm(11) : error A2004: symbol type conflict : CRAP
crap.asm(11) : fatal error A1016: Internal Assembler Error
Quote from: HSE on April 17, 2019, 02:20:24 AM
Just a bug in ML14
X:\masm32\test>ml crap.asm
Microsoft (R) Macro Assembler Version 6.14.8444
Copyright (C) Microsoft Corp 1981-1997. All rights reserved.
Assembling: crap.asm
crap.asm(11) : error A2004: symbol type conflict : CRAP
crap.asm(11) : fatal error A1016: Internal Assembler Error
Not really: crap.asm(11) : fatal error A1016: Internal Assembler Error
At least now you receive a report. :badgrin:
Quote from: AW on April 17, 2019, 02:29:09 AM
At least now you receive a report. :badgrin:
Clearlly the error is "CRAP". Why you want a report?
Quote from: HSE on April 17, 2019, 02:58:44 AM
Quote from: AW on April 17, 2019, 02:29:09 AM
At least now you receive a report. :badgrin:
Clearlly the error is "CRAP". Why you want a report?
CRAP is perfectly valid, a pointer to CRAP is 4! :t The value of pointing to it varies though. :dazzled:
See:
.486
.model flat, stdcall
printf proto C :ptr, :vararg
ExitProcess proto :dword
label0 typedef ptr CRAP
.data
msg db "Value of a pointer to CRAP is %d, value of pointing to CRAP is %d",10,0
valueofpointingtocrap label0 0
.code
main proc
mov eax, label0
invoke printf, offset msg, eax, valueofpointingtocrap
push 0
call ExitProcess
main endp
end
Output:
Value of a pointer to CRAP is 4, value of pointing to CRAP is 0
:biggrin:
Now come on guys, MASM does not have bugs, it just has many specialised features that you need to understand, get 'em right and it pops object modules, otherwise it pops garbage at you, especially with the later versions. :P
Quote from: AW on April 17, 2019, 03:05:50 AM
The value of pointing to it varies though. :dazzled:
Of course, is a pointer! :biggrin:
.486
.model flat, stdcall
includelib \masm32\lib\kernel32.lib
includelib \masm32\lib\msvcrt.lib
printf proto C :ptr, :vararg
ExitProcess proto :dword
label0 typedef ptr CRAP
CRAP struct
Emptyness db 0,0,0,0
CRAP ends
.data
msg db "Value of a pointer to CRAP is %d, value of pointing to CRAP is %d",10,0
valueofpointingtocrap label0 offset Atelier
Atelier CRAP <'idea'>
.code
main proc
mov eax, label0
invoke printf, offset msg, eax, valueofpointingtocrap
push 0
call ExitProcess
main endp
end main
Output:
Value of a pointer to CRAP is 4, value of pointing to CRAP is 4206663 :t
Quote from: hutch-- on April 17, 2019, 08:40:15 AMNow come on guys, MASM does not have bugs, it just has many specialised features that you need to understand, get 'em right and it pops object modules, otherwise it pops garbage at you, especially with the later versions. :P
The list of known "features" (http://www.masmforum.com/board/index.php?topic=10435.0) and their workarounds is long - see also the Discovering the mysteries of MASM features (http://masm32.com/board/index.php?topic=7491.0) thread. The problem with some of the later versions is that you can
never get it right, see e.g. the garbled error message problem (http://masm32.com/board/index.php?topic=7325.msg79884#msg79884).
Then there is a really nasty "feature" of recent ML versions: it produces
wrong code, "forgetting" one byte. See the Guaranteed to crash in MASM (http://masm32.com/board/index.php?topic=6732.0) and MASM 14.0 .if signed comparison bug (http://masm32.com/board/index.php?topic=6447.0) threads.
Finally, there are UAsm (http://masm32.com/board/index.php?board=51.0) and AsmC (http://masm32.com/board/index.php?board=55.0), 100% compatible except that they don't have the "features", but attention, they are 5 times as fast as Micros**t MASM, you might get confused and sick by so much speed 8)
:biggrin:
> the garbled error message problem.
Real Programmers[tm] don't make errors. :P
> Finally, there are .... ....
But MASM is there as long as Microsoft are there and you get it out of them for free. MASM has seen them come and go like JWASM and other pretenders and like it or lump it, MASM is the most directly used assembler in the world. GAS may come close as a compiler back end.
For MASM syntax, I'd agree that MASM is indeed the most popular assembler (mostly because it's the one that comes with the MASM32 SDK), but for coding in assembly in general ? I'd say NASM is at least as popular if not more (on Linux I only ever see people using NASM). And as a compiler back-end, I'd argue GCC/Clang/Icc combined are used more (they all use GAS as their assembler) than MSVC. Moreover, there are plenty of tools that emit output for GAS (or that uses GAS) while I know of almost none that generate output for MASM (not counting MSVC).
but with latest VC++,you can output your 4 differerent cpu architecture=4 different assemblers for x86,x64,ARM,ARM64?
is ARM,ARM64 also a MASM version?
windows phone development among things its for
The target OS is the factor here, MASM will not run in Unix versions unless you use a Windows emulator and while there are versions of NASM and GAS that will run in Windows, they have nothing like the support that Windows dedicated assemblers have. NASM is a specialised tool for different platforms while GAS is mainly a compiler back end, I have seen very few write apps in GAS although it can be done in Windows if you set up a linker that will handle resource files.
I have always like GAS, its a no bullsh*t low level assembler and while the Unix guys tend to write AT&T notation in the few places where its used with manual code, it does have the option of Intel notation which then makes it a lot cleaner to use.
Quote from: hutch-- on April 18, 2019, 02:12:40 AM
while there are versions of NASM and GAS that will run in Windows, they have nothing like the support that Windows dedicated assemblers have.
I mean, Mingw and Cygwin (and thus the GAS in their toolchains) are both very well supported afaik, and NASM is packaged in a frequently updated package in MSYS2 and Cygwin, so I don't exactly see what you mean here.
I think I now understand TYPEDEF. Thanks to everyone.
One question.
If TYPEDEF has PROTO in it . Is PROTO used to define multiple variables where instead it would have to use multiple TYPEDEF without PROTO?
> I don't exactly see what you mean here.
Its simple, MASM has been around since 1982 and it has a massive user base. Microsoft have supplied it for that long and they have updated it for each OS version. They also supply it with their VC\VS applications since 1999 so it has a massive current distribution. NASM uses its own notation as it is a multi-port tool and GAS originally used AT&T notation as you see in some very low level Unix based code. As a compiler back end, GAS has a high rate of use but only in Unix based systems, in Windows the GCC tool chain is only a small player along side Microsoft's own VC based tools.
Only over recent times was GAS starting to support Intel notation as well as AT&T and that made it far more usable for the massive number of people who understand Intel notation.
The Chinese team (I am suspecting that only Chineses do MASM at Microsoft) is working on it:
https://developercommunity.visualstudio.com/content/problem/537068/masm-buffer-overflow-with-variable-named-as-fake-t.html
Quote
We've got a fix for this and I expect it to ship in the 16.2 release.
:t
Quote from: AW on May 07, 2019, 02:37:16 PM
Quote
We've got a fix for this and I expect it to ship in the 16.2 release.
:t
Thank you! Is this https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html (https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html) the last bug that remains to be fixed? Nidud also follows the news :P
Quote from: LiaoMi on May 07, 2019, 05:42:53 PM
Thank you! Is this https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html (https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html) the last bug that remains to be fixed? Nidud also follows the news :P
Yes, Mark Gardner (https://developercommunity.visualstudio.com/users/106472/6e98da84-2b71-6d6f-9d1b-443d9a9b8e19.html?itemsifollow) is also with that one. After that, MASM will be 100% bug free. :badgrin:
AW,
I thought I had a understanding of the TYPEDEF instruction when I examined you sample code. I attempted to change your sample code to the enclosed listing.
However I am getting the following errors from the assembler:
Lines 26,27,30 and 31 Invalid use of register
.486
.model medium,stdcall
printf proto near C :ptr, :vararg
ExitProcess proto near :dword
label1 typedef ptr proc
label2 typedef proc
.data
msg db "Hello from called function",10,0
.code
myFunc proc near
invoke printf, addr msg
ret
myFunc endp
main proc near
mov esi, myFunc
call esi
call label1 ptr esi
call label2 ptr esi
lea esi, myFunc
call esi
call label1 ptr esi
call label2 ptr esi
push 0
call ExitProcess
main endp
End
Output:
end
I noticed that Label1 is always a far ptr even though I never defined it that way. I also did not find any way to make it a near ptr.
As you can see I am trying to make it a near subroutine not a far subroutine. What am I doing wrong? Is PROC a distance or a size for the pointer?
Thank you for your help.
Quote from: StillLearningMasm on May 09, 2019, 06:32:18 AM
AW,
I thought I had a understanding of the TYPEDEF instruction when I examined you sample code. I attempted to change your sample code to the enclosed listing.
However I am getting the following errors from the assembler:
Lines 26,27,30 and 31 Invalid use of register
.486
.model medium,stdcall
printf proto near C :ptr, :vararg
ExitProcess proto near :dword
label1 typedef ptr proc
label2 typedef proc
.data
msg db "Hello from called function",10,0
.code
myFunc proc near
invoke printf, addr msg
ret
myFunc endp
main proc near
mov esi, myFunc
call esi
call label1 ptr esi
call label2 ptr esi
lea esi, myFunc
call esi
call label1 ptr esi
call label2 ptr esi
push 0
call ExitProcess
main endp
End
Output:
end
I noticed that Label1 is always a far ptr even though I never defined it that way. I also did not find any way to make it a near ptr.
As you can see I am trying to make it a near subroutine not a far subroutine. What am I doing wrong? Is PROC a distance or a size for the pointer?
Thank you for your help.
Have a look at the previous thread, http://masm32.com/board/index.php?topic=7837.msg85924#msg85924
And in the 32-bit flat model there is no difference between near and far procedure calls. They are all the same, you don't it to qualify calls with near or far.
AW,
Thank you for the reply. I looked at that link but I still do not understand why I am getting those error messages. What do I need to do to fix them?
Thank you for your help.
AW,
You have in your code the instruction:
call label1 ptr esi
I have not seen a ptr register combination after a call instruction (I did not even know that it was possible). Where do I find information on this?
Thank you
Quote from: StillLearningMasm on May 09, 2019, 08:14:44 AM
AW,
Thank you for the reply. I looked at that link but I still do not understand why I am getting those error messages. What do I need to do to fix them?
Thank you for your help.
Model is FLAT not Medium. In 32-bit and 64 bit Windows the only model is FLAT.
Quote from: LiaoMi on May 07, 2019, 05:42:53 PM
Quote from: AW on May 07, 2019, 02:37:16 PM
Quote
We've got a fix for this and I expect it to ship in the 16.2 release.
:t
Thank you! Is this https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html (https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html) the last bug that remains to be fixed? Nidud also follows the news :P
The 3 BYTE STRUCT bug will be fixed in VS 2019 release 16.3. Now we are at 16.1
StillLearningMasm,
There is an inherent problem in the questions you ask in that have not explained what OS you are targeting and what version of MASM reference material you are using. You have kept using MS-DOS notation while trying to use 32 bit registers and combinations of this type simply do not work. If you want to write 16 bit DOS code, we have a sub forum for that but if you want to write 32 or 64 bit code you need to change the reference material you are using to properly address the OS version that support 32 and 64 bit code.
This is the bare minimum to write 32 bit MASM code.
.486 ; create 32 bit code
.model flat, stdcall ; 32 bit memory model
option casemap :none ; case sensitive
If you are trying to write modern 32 bit code you would use,
.686p ; create 32 bit code
.MMX
.XMM
.model flat, stdcall ; 32 bit memory model
option casemap :none ; case sensitive
Quote from: AW on June 03, 2019, 03:46:14 AM
Quote from: LiaoMi on May 07, 2019, 05:42:53 PM
Quote from: AW on May 07, 2019, 02:37:16 PM
Quote
We've got a fix for this and I expect it to ship in the 16.2 release.
:t
Thank you! Is this https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html (https://developercommunity.visualstudio.com/content/problem/508122/masm-invoke-with-a-3-byte-struct.html) the last bug that remains to be fixed? Nidud also follows the news :P
The 3 BYTE STRUCT bug will be fixed in VS 2019 release 16.3. Now we are at 16.1
Hi AW,
good news :thup:, I hope they will not postpone the release for half a year, as they like to do, because most recently versions have already been updated to the new number 14.21.27702 ..
Hi LiaoMi,
Since they had nothing new to show for a long time, I am expecting these bug fixes will change significantly the release numbers. :badgrin:
VS 2019 16.2 is out, apparently the bug is fixed.
This one: https://developercommunity.visualstudio.com/content/problem/537068/masm-buffer-overflow-with-variable-named-as-fake-t.html