help request - sizeof and api

[abuckau907]

Kind of embarrassed to ask, but I've been trying to make my code 64 bit compatible and have been struggling with incorrect api declaration.
(coding in C#.net , framework 4.0)
edit* technically my code works(for my pc at least). I just think* I have a some errors in my api declarations and I'm wondering if those declarations will cause issues when run on other versions of windows.

Here is an example..
OpenProcess --> I google it.
pInvoke.com says

IntPtr OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId)

while microsoft says

HANDLE WINAPI OpenProcess(
  _In_  DWORD dwDesiredAccess,
  _In_  BOOL bInheritHandle,
  _In_  DWORD dwProcessId
);

I know it seems like basic 32vs64etc type thing, but it's still giving me grief
Anyway, m$ says dwDesiredAccess is DWORD --> DWORD is unsigned 32 bit

(so really the API declaration should use uint ??)
edit*( ive seen both - hence my confusion)

( I've had "C# 3.0 in a nutshell" for months now..finally starting at page one and reading. )

Anyway, here is the question:
Which one is correct?
(as a matter of practicality, will a process.id ever be over int32.maxvalue ?? so api declaration doesn't matter can be either?)

        [DllImport("kernel32.dll")]
        private static extern IntPtr OpenProcess(uint dwDesiredAccess,[MarshalAs(UnmanagedType.Bool)] bool bInheritHandle,uint dwProcessId );

or

        [DllImport("kernel32.dll")]
        private static extern IntPtr OpenProcess(int dwDesiredAccess,[MarshalAs(UnmanagedType.Bool)] bool bInheritHandle,int dwProcessId );

edit: title misleading. I'm not trying to use sizeof (or marshal.sizeof) at all. Just not sure if declaring the parameters unsigned vs signed matters.

-Thanks.

[Cromon]

You may safely assume that DWORD is a 32 bit unsigned integer. The MSDN says:

A DWORD is a 32-bit unsigned integer (range: 0 through 4294967295 decimal).

DWORD is actually pretty misleading. You should also worry under a 32 Bit environment. The size of a word on a 32 bit system is 32 Bit, therefore a double word should be 64 bit. But that type is a leftover from old 16 bit when it was introduced. There a DWORD is 32 bit and stayed 32 bit over the time.

Anyway, for the processid parameter: Even on x64 you most likely wouldnt wanna run more than 2^32-1 processes id say . Thus the need for 64 bit process identifiers is obsolete.

And to fully convince you - from x64 kernel32.dll:

.text:6B825286 ; HANDLE __stdcall OpenProcessStub(DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwProcessId)
.text:6B825286                 public _OpenProcessStub@12
.text:6B825286 _OpenProcessStub@12 proc near           ; DATA XREF: .rdata:off_6B8E1C08o
.text:6B825286
.text:6B825286 dwDesiredAccess = dword ptr  8
.text:6B825286 bInheritHandle  = dword ptr  0Ch
.text:6B825286 dwProcessId     = dword ptr  10h

/Edit:
And after all your question lacks a vital point. You are asking:

(as a matter of practicality, will a process.id ever be over int32.maxvalue ?? so api declaration doesn't matter?)

Its completely unimportant if there are id's larger than int32.maxvalue. Its not like a p-invoke signature would only cause problems if there is actually a value larger than int32.maxvalue it already causes problems if its called.

Imagine the following native function:

void __stdcall someFunction(unsigned __int64 value) {
    // whatever
}

If you create a signature like

[DllImport(...)]
private static extern void someFunction(uint value);

youll get a problem as soon as you are calling it. The reason is pretty simple. Calling the imported function will push 4 bytes to the stack but someFunction removes 8 bytes from it. Therefore esp wouldnt be properly restored, the stack is out of sync even if you call someFunction with 0.

[abuckau907]

You may safely assume that DWORD is a 32 bit unsigned integer. ...

^^i said this in first post.?

I know about data types, but don't know why they are 2 different (albeit very close) types for the same thing.
Q)My question was, unsigned int32, or, signed int32 for pid. Apparently it doesn't matter, since Windows always tries to use low pid's, so it should always fit in Int32.

Q2) Is it the same (uint,bool,uint) for windows vista,7, 8 (32 and 64bit) ??

-Thnx.

So if both work, is the uint version 'more correct', or are pid officially Int32? Any special circumstance?

[Cromon]

Why would use a signed integer if it uses unsigned ones? Whats the benefit except having unsafe code?

I know about data types, but don't know why they are 2 different (albeit very close) types for the same thing.

What are you talking about?

[abuckau907]

System.Diagnostics.Process.Id -- signed int32
kernel32::OpenProcess(**,*****, procId) -- unsigned int32

I don't care which type I use, as long as it's consistent (like you say!)

It doesn't matter (for now, because my code works), but I always thought I had a mistake w/ my api declarations. Thought I'd ask here since most ppl have probably used openprocess before.

--is this .net trickery, (ie. windows stores it as uint and .net tracks it as int?!?) or for backwards compatibility, or ?



(and Q. 2) Is it the same for all windows os (xp, vista,7,8, x86 and x64) ?

--I'll try to get book on windows internals soon. I'm on xp32, so compatibility testing is hard/nonexistent.
http://msdn.microsoft.com/en-us/libr...ss.handle.aspx - currently reading here and random posts from '08 lol, will maybe post an update later.

--also
Even on x64 you most likely wouldnt wanna run more than 2^32-1 processes id say . Thus the need for 64 bit process identifiers is obsolete.
Even on x64 you most likely wouldnt wanna run more than 2^24-1 processes id say
Even on x64 you most likely wouldnt wanna run more than 2^16-1 processes id say //35k is a lot. even for a server.
I wasn't saying make make pid int64, i was saying the opposite, that .net treats it as signed int (1/2 the range) instead of unsigned int. :/

[Cromon]

Thats a common "problem" with .NET. Signed integers are used for everything even if doesnt make any sense at all. I guess that comes from the veeeery bad habit of java where you dont have unsigned datatypes. /* Edit: Its not derived from java but the fact that unsigned integers are not CLS-compilant. */ There are even worse properties, for example HandleCount is also a signed integer like there is a possibility that a variable that represents a number of things could ever be < 0...

Usually its best limit interactions between .NET and unmanaged code as much as possible. OpenProcess is not needed, use the System.Diagnostics.Process API.