NASM HelloWorld - DOS
in [ASM]
|
Prev: Linux X demo
Next: where [BITS 32] directive?
From: Jim Carlock on 6 Aug 2007 01:32 "Jim Carlock" wrote: : And one other question... there's alot of function names prefixed : with __stdcall_defined_. : : %define __stdcall_defined_WSAStartup _WSAStartup@8 Found something in the nasm32.inc file. %ifdef __stdcall_defined_%1 %define %1 __stdcall_defined_%1 extern __stdcall_defined_%1 %endif I don't understand what's going on there. It looks unstraight or backwards or upside down. Something just doesn't read right. -- Jim Carlock
From: SpooK on 6 Aug 2007 02:11 On Aug 5, 8:57 pm, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > Compiling the demo1.asm... > > 08/04/2007 11:28 PM 868 demo1.asm > 08/05/2007 09:25 PM 1,536 demo1.exe > 08/05/2007 01:50 PM 146,083 demo1.obj > > NASM builds a huge object files, I'm guessing that it's throwing all > the structures from the include files into the object file. There any > way to get NASM to not create such a huge object file when the > WINDOWS.INC is included? As far as I have experienced, only the linker takes care of that :P But seriously, I've noticed that too... and it annoys me a bit. I am trying to alleviate some of that with better macros but the executable is the important end result. > And one other question... there's alot of function names prefixed > with __stdcall_defined_. > > %define __stdcall_defined_WSAStartup _WSAStartup@8 > > Pardon me for not looking at the source. Google found nothing > and found nothing in the help documents. Searched Google for > __stdcall_defined. Google didn't even turn the underscores into > spaces (so that's a good thing, I think). Is there something going > on somewhere that I'm not seeing? > That is specific to NASM32 and is merely a unique way to keep track of the different call types, specifically STDCALL in this case, via the macro system. > : And one other question... there's alot of function names prefixed > : with __stdcall_defined_. > : > : %define __stdcall_defined_WSAStartup _WSAStartup@8 > > Found something in the nasm32.inc file. > > %ifdef __stdcall_defined_%1 > %define %1 __stdcall_defined_%1 > extern __stdcall_defined_%1 > %endif > > I don't understand what's going on there. It looks unstraight or > backwards or upside down. Something just doesn't read right. > > -- > Jim Carlock That macro is to assure that externs for any "invoked" functions are only applied once. After studying NASM's macro facilities a bit, you will see your way through such obscure macros ;) PS: You may wish to make the distinction between "DOS" and a Win32 console... they may look the same on the outside... but they are two entirely separate beasts on the inside... and it helps me when looking at these threads :P
From: Evenbit on 6 Aug 2007 03:32 On Aug 6, 1:32 am, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > > Found something in the nasm32.inc file. Let us pretend that "Assemble" is being substituted: > > %ifdef __stdcall_defined_%1 So, if "__stdcall_defined_Assemble" has been previously defined, then the next two lines will be processed. > %define %1 __stdcall_defined_%1 This becomes "%define Assemble __stdcall_defined_Assemble" which allows you to invoke the functions simply by stating "Assemble" instead of being required to prepend the "__stdcall..." stuff. > extern __stdcall_defined_%1 But we *want* the prepended stuff when we use the "extern" keyword. > %endif > > I don't understand what's going on there. It looks unstraight or > backwards or upside down. Something just doesn't read right. > I am Half-expecting Are. to drop-in and suggest that parenthises would improve the understanding. PA-NASM?? Nathan.
From: Frank Kotler on 6 Aug 2007 11:38 Evenbit wrote: > On Aug 6, 1:32 am, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > >>Found something in the nasm32.inc file. > > > Let us pretend that "Assemble" is being substituted: > > >>%ifdef __stdcall_defined_%1 > > > So, if "__stdcall_defined_Assemble" has been previously defined, then > the next two lines will be processed. Correct. But Jim's right that this seems backwards. I would have expected "%ifndef ...". The point being to not declare it "extern" if we've already got it declared "extern". Some assemblers (Masm?) "merge" multiple externs, Nasm does not, and it bloats the executable slightly. Best, Frank
From: SpooK on 6 Aug 2007 12:15
On Aug 6, 10:38 am, Frank Kotler <fbkot...(a)verizon.net> wrote: > Evenbit wrote: > > On Aug 6, 1:32 am, "Jim Carlock" <anonym...(a)127.0.0.1> wrote: > > >>Found something in the nasm32.inc file. > > > Let us pretend that "Assemble" is being substituted: > > >>%ifdef __stdcall_defined_%1 > > > So, if "__stdcall_defined_Assemble" has been previously defined, then > > the next two lines will be processed. > > Correct. But Jim's right that this seems backwards. I would have > expected "%ifndef ...". The point being to not declare it "extern" if > we've already got it declared "extern". I can see from that perspective, but here is a further breakdown. Let's take a common example, the ExitProcess function from kernel32. [code] .... processing include files... .... processing kernel32.inc... %define __stdcall_defined_ExitProcess _ExitProcess@4 .... processing the source file... invoke ExitProcess, DWORD 0 ;How the call looks in the source code .... going through the INVOKE macro... %ifdef __stdcall_defined_%1 ;If "__stdcall_defined_ExitProcess" is defined... %define %1 __stdcall_defined_%1 ;Setup a define that turns "ExitProcess" into "_ExitProcess@4" extern __stdcall_defined_%1 ;EXTERN _ExitProcess@4 %endif invoke _ExitProcess@4, DWORD 0 ;How the above call would look at this point Every instance of the term "ExitProcess" while the define is in effect is now replaced with "_ExitProcess@4" and all is gravy. So as you can see, EXTERN for each defined function in the include files is never processed more than once. > Some assemblers (Masm?) "merge" > multiple externs, Nasm does not, and it bloats the executable slightly. I just tested that theory about NASM, with "EXTERN _ExitProcess@4" twice, and it *did* merge the externs (I looked at the hex dump) and *did not* bloat the executable one bit. Win32 DEMO1 remained 1536 bytes both when assembling/linking the original content and with an extra "EXTERN". As for the object file, that may be another matter... although seemingly insignificant :) |