PInvoke and constants

[vertigo]

Hello
I use some win 32 API function for example:
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);

my code:
[DllImport("kernel32.dll")]
static extern IntPtr CreateFile(string name, int DesiredAccess, int
ShareMode, IntPtr securityAttributes, int CreationDisposition,
int FlagsAndAttributes, IntPtr TemplateFile);
later:
Handle = CreateFile( Name, GENERIC_WRITE, FILE_SHARE_READ, IntPtr.Zero,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, IntPtr.Zero );

But i compiler does not know these constants: GENERIC_WRITE,
FILE_SHARE_READ, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL.
How can i access them ?

Thanx
Michal

[Willy Denoyette [MVP]]

You have to "handcode" them yourself with the values from the SDK header
files (winnt.h), something like this will do:

const uint GENERIC_READ = 0x80000000;
.....

Willy.

"vertigo" <ax***@wp.pl> wrote in message
news:cn**********@nemesis.news.tpi.pl...

Hello
I use some win 32 API function for example:
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);

my code:
[DllImport("kernel32.dll")]
static extern IntPtr CreateFile(string name, int DesiredAccess, int
ShareMode, IntPtr securityAttributes, int CreationDisposition,
int FlagsAndAttributes, IntPtr TemplateFile);
later:
Handle = CreateFile( Name, GENERIC_WRITE, FILE_SHARE_READ, IntPtr.Zero,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, IntPtr.Zero );

But i compiler does not know these constants: GENERIC_WRITE,
FILE_SHARE_READ, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL.
How can i access them ?

Thanx
Michal

[ShaneB]

This may help you:

http://www.pinvoke.net/

ShaneB

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:ed**************@TK2MSFTNGP14.phx.gbl...

You have to "handcode" them yourself with the values from the SDK header
files (winnt.h), something like this will do:

const uint GENERIC_READ = 0x80000000;
....

Willy.

"vertigo" <ax***@wp.pl> wrote in message
news:cn**********@nemesis.news.tpi.pl...

Hello
I use some win 32 API function for example:
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile
);

my code:
[DllImport("kernel32.dll")]
static extern IntPtr CreateFile(string name, int DesiredAccess, int
ShareMode, IntPtr securityAttributes, int CreationDisposition,
int FlagsAndAttributes, IntPtr TemplateFile);
later:
Handle = CreateFile( Name, GENERIC_WRITE, FILE_SHARE_READ, IntPtr.Zero,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, IntPtr.Zero );

But i compiler does not know these constants: GENERIC_WRITE,
FILE_SHARE_READ, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL.
How can i access them ?

Thanx
Michal

[Willy Denoyette [MVP]]

"ShaneB" <st********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

This may help you:

http://www.pinvoke.net/

Me? I don't think so, but thanks anyway :-).
I prefer to stay away for this PInvoke stuff as much as possible. Most of
what's included in http://www.pinvoke.net/ is covered by managed
alternatives, it's just a matter of searching/learning what's included in
the FCL.

Willy.

[ShaneB]

No, not you :) That was for the original poster.

Anyhoo, I too avoid PInvoke as much as I can...but there are still many
things missing from the framework. Hopefully 2.0 will address many of them.

ShaneB

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

"ShaneB" <st********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

This may help you:

http://www.pinvoke.net/

Me? I don't think so, but thanks anyway :-).
I prefer to stay away for this PInvoke stuff as much as possible. Most of
what's included in http://www.pinvoke.net/ is covered by managed
alternatives, it's just a matter of searching/learning what's included in
the FCL.

Willy.

[Willy Denoyette [MVP]]

Sure, there are things missing, but as far as I can see, a lot of what's
fount at http://www.pinvoke.net/ is covered by the FCL.
The problem is that people used to VB's 'declare ...' stuff and C/C++ /Win32
programming, are simply looking for direct replacements of Win32 API's when
porting applications to .NET, this without taking some time to learn/see
what's covered by the FCL.
Don't get me wrong, there's nothing basically wrong with PInvoke:
- as long as you know there are no managed alternatives and,
- you know perfectly well what the API is doing, just go for it.
But, a lot of "developers" are blindly using the PInvoke signatures and data
definitions without looking at the API requirements, platform dependencies,
security implications and maintenance issues related to OS versions updates
after deployment, sooner or later they will be faced with a lot of (hard to
trace) issues.
There's a group of PInvoke API's I would call "dangerous" when used in a
managed application because they can disturb the correct functioning of the
CLR.

Willy.
"ShaneB" <st********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

No, not you :) That was for the original poster.

Anyhoo, I too avoid PInvoke as much as I can...but there are still many
things missing from the framework. Hopefully 2.0 will address many of
them.

ShaneB

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

"ShaneB" <st********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

This may help you:

http://www.pinvoke.net/

Me? I don't think so, but thanks anyway :-).
I prefer to stay away for this PInvoke stuff as much as possible. Most of
what's included in http://www.pinvoke.net/ is covered by managed
alternatives, it's just a matter of searching/learning what's included in
the FCL.

Willy.