Hello Everybody

This is the normal way of writing this line....
invoke CreateFileA, ADDR File01, GENERIC_READ, 0, 0, OPEN_EXISTING, 0, 0

My question is since NULL = 0 is there any real particular reason why it's better to use NULL instead of just plain 0.

Could those 0's get overwritten in ANY kind of way by something.
or is it OK to use them with no problem at all...

Thanks
Posted on 2002-01-26 15:51:43 by cmax
NULL signifies that this part of the parameter is NULL or Nothing, Nada. It's Ok to use 0(Zero), it's the same thing, it's just for formality sakes and readability. You can also use 1 for TRUE...
Posted on 2002-01-26 15:56:43 by stryker
I sure did not want to use it because i guest it would have to make those 4 additional jumps to check in with Windows.inc equ NULL = 0

It seems such a waste....
Posted on 2002-01-26 16:04:37 by cmax
Ahh, I remember in the TASM days...I never used windows.inc, I use to make windows.inc as a reference and hard coded the equivalent hexadecimal values into the parameters of a function...Its sucks by the way. :grin:
Posted on 2002-01-26 16:09:17 by stryker
0 for null has been 100% ok for me so far, but True can equal 1 or -1.
Posted on 2002-01-26 17:07:32 by eet_1024

I sure did not want to use it because i guest it would have to make those 4 additional jumps to check in with Windows.inc equ NULL = 0

It seems such a waste....


Well, if your application is small enough and doesn't use too many items from "windows.inc" then just define them within your own code...

Simple enough I would assume (but only if you really care)

Sliver
Posted on 2002-01-26 17:23:16 by Sliver
cmax,

A couple of things, when you use an equate like NULL in your code, the assembler substitutes the value into the code at assemble time and there is no additional runtime code at all from using the equates.

Unless you have some other reason with your API usage, the include files in MASM32 use the standard names for these functions so you do not have to specify the "A" ending with them. This is to retain the naming conventions used in the documentation for windows API calls.

The guys who used to code in TASM will tell you the joys of endlessly having to chase the info that is already contained in WINDOWS.INC.

It was designed to take the hassle out of coding in win32 assembler so that you could just work with the standard documentation to call a function.

Regards,

hutch@movsd.com
Posted on 2002-01-26 20:11:20 by hutch--
Sliver could you post a basic line up of how i would go about doing this...It don't have to be perfect just something to give me an idea of how to do it...Just a line or two....Thanks

Hutch, i am working on the same thing that i started two years ago, the only difference now is that i'm just getting very tectnical about it...I have rebuilded well over 500 times. This is my last time.... By me reduing everything the hard way it is letting me see every single thing that is going on and why....An you know i am bent on the idea of packing everything under one file. Right or wrong i'm in it for the long haul...I read about this and that, masm jump tables and stuff.... Maybe there won't be an jump table when i'm finish...I stuck on one project so this way may be better for me... not for someone who need rapid devlopment and decent turn-overs time...You said in spook post something about getting into your code and see what's going on....Here i will be....

Thanks Hutch

You should be very proud of where you have sent me...and others
I'm not super good yet but I never thought i could do it...ALL of thoses details
Posted on 2002-01-27 00:34:57 by cmax
cmax, the idea is that NULL is for pointer values, 0 for integer values.
Whether you want to use NULL is up to you... I like it. Can make
it a bit easier to pick out what parameter you're looking at in a long
API call, without having to count...
Posted on 2002-01-28 10:00:09 by f0dder