GetCurrentProcess.Id vs GetCurrentProcessId API

[jbpez]

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.

 

[chiph]

Which one matches the value you see in the Windows Task Manager?

If you're running Windows XP, open a command window and run the tasklist command. Does that match what you're seeing?

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[jbpez]

System.Diagnostics.Process.GetCurrentProcess.Id matches the value in Windows Task Manager.

I figured it out.

In VB6 I declared as a long:
Private Declare Function GetCurrentProcessId Lib "Kernel32" () As Long

But in VB.NET I need to change it to integer:
Private Declare Function GetCurrentProcessId Lib "kernel32" () As Integer

This also applied to other functions that I was having problems with.

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 an "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?

 

[chiph]

Because a long in .net is 8 bytes, while in vb6 it's 4 bytes.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[ThatRickGuy]

Isn't integer defined by the Processor in .Net? I was thinking it was still 4 bytes on 16b procs and was 8 bytes on 32b procs (and presumably larger on 64b procs).

I could be completely off on that one, but I thought I remembered reading that someplace years ago.

If in doubt though, there are also the types Int16, Int32, and Int64 if you want to control the memory size.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[chiph]

The VB.NET language reference says:

Long variables are stored as signed 64-bit (8-byte) integers ranging in value from -9,223,372,036,854,775,808 through 9,223,372,036,854,775,807.

and

Caution If you are interfacing with components written in Visual Basic version 6.0, for example Automation or COM objects, keep in mind that Long has a different data width (32 bits) in Visual Basic 6.0. If you are passing a 32-bit argument to such a component, declare it as Integer instead of Long in Visual Basic .NET.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first

 

[chiph]

Isn't integer defined by the Processor in .Net? I was thinking it was still 4 bytes on 16b procs and was 8 bytes on 32b procs (and presumably larger on 64b procs).

One of the design goals of .NET was to provide some degree of processor-architecture neutrality. Microsoft knows all too well the pain of writing portable C code, and didn't want to suffer through that again (I don't blame them!).

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first