GetCurrentProcess.Id vs GetCurrentProcessId API

[johnboy]

How is the "System.Diagnostics.Process.GetCurrentProcess.Id" different
from the GetCurrentProcessId API (Kernel32.dll)?

I'm trying to convert code from VB6 to VB.NET and supposedly
GetCurrentProcess.Id (.NET) is the equivalent of GetCurrentProcessId
API, but it doesn't work. I placed both in my .NET app to read the
results and I get different numbers. I tried just using the API in .NET
but the function (WD_ConnectPS from ehlapi32.dll) that needs the
process id won't accept it.

How can I get the process id that works in VB6 in VB.NET?

Please help, thank you.

 

[Guest]

How is the "System.Diagnostics.Process.GetCurrentProcess.Id" different

from the GetCurrentProcessId API (Kernel32.dll)?

I'm trying to convert code from VB6 to VB.NET and supposedly
GetCurrentProcess.Id (.NET) is the equivalent of GetCurrentProcessId
API, but it doesn't work. I placed both in my .NET app to read the
results and I get different numbers. I tried just using the API in .NET
but the function (WD_ConnectPS from ehlapi32.dll) that needs the
process id won't accept it.

Getting the process id works fine for me - x and y are the same below:

Declare Function GetCurrentProcessId Lib "kernel32" () As Integer
Dim x As Integer = System.Diagnostics.Process.GetCurrentProcess.Id
Dim y As Integer = GetCurrentProcessId()

So, the problem is not with the process id, it is with how you call
WD_ConnectPS in ehlapi32.dll. I guess the declare statement is not right.
You may need to talk to the dll authors for some .net advice - is it NetSoft?

Good luck on what sounds like a challenging conversion.

 

[johnboy]

I thought the following was the way to declare APIs in VB.NET:

<DllImport("Kernel32.dll")> Private Shared Function
GetCurrentProcessId() As Long
End Function

I noticed that you declared GetCurrentProcessId as integer and not as
long.
Once I changed every declared function and arguments that were type
"long" in VB6 to "integer" in VB.NET everything worked.

It seems like the difference between VB6 and VB.NET when it comes with
declaring API functions is that when type "long" is used in VB6 and
"integer" is used in VB.NET.

Now, why would GetCurrentProcessId declared as long return a completely
different number than when declared as integer in VB.NET?

 

[Guest]

I thought the following was the way to declare APIs in VB.NET:

<DllImport("Kernel32.dll")> Private Shared Function
GetCurrentProcessId() As Long
End Function

I noticed that you declared GetCurrentProcessId as integer and not as
long.
Once I changed every declared function and arguments that were type
"long" in VB6 to "integer" in VB.NET everything worked.

It seems like the difference between VB6 and VB.NET when it comes with
declaring API functions is that when type "long" is used in VB6 and
"integer" is used in VB.NET.

Now, why would GetCurrentProcessId declared as long return a completely
different number than when declared as integer in VB.NET?

Actually, my typical api declaration looks like this:

Friend Declare Function GetDesktopWindow Lib "user32" () As IntPtr

IntPtr (a horrible name for a .net integeral value type) is supposed to cope
with 32-bit and 64 bit issues. The .net doc says this:

"The IntPtr type is designed to be an integer whose size is
platform-specific. That is, an instance of this type is expected to be
32-bits on 32-bit hardware and operating system, and 64-bits on 64-bit
hardware and operating systems."

and this:

"A platform-specific type that is used to represent a pointer or a handle."

I use IntPtr in this context because fxcop suggested it. I suggest you use
fxcop also. It will take a while to get used to it, and some of its
complaints are silly IMO, particularly re naming conventions. But on balance
it points out areas for improvement. I like having no fxcop complaints about
my declare statements.

 

[Claes Bergefall]

I thought the following was the way to declare APIs in VB.NET:

<DllImport("Kernel32.dll")> Private Shared Function
GetCurrentProcessId() As Long
End Function

I noticed that you declared GetCurrentProcessId as integer and not as
long.
Once I changed every declared function and arguments that were type
"long" in VB6 to "integer" in VB.NET everything worked.

It seems like the difference between VB6 and VB.NET when it comes with
declaring API functions is that when type "long" is used in VB6 and
"integer" is used in VB.NET.

Long in VB6 is 32-bit
Long in VB.NET is 64-bit

Integer in VB6 is 16-bit (IIRC)
Integer in VB.NET is 32-bit

So the correct datatype to use is Integer

Now, why would GetCurrentProcessId declared as long return a completely
different number than when declared as integer in VB.NET?

Why wouldn't it? The return type is part of the declaration to. Using the
wrong one leads to unpredictable results

/claes