Problems in porting Win32 API in PowerShell
Hi,
I encounter the problem of adapting such a port on Win32 API in PowerShell (type. NET + P / Invoke).
Default PowerShell a number is considered a signed integer (System.Int32).
I just installed the SDK 6.1 for access to statements in the file WinUser.h, but I do not know how to interpret the different types of declared values.
Finally, the more precisely:
-what is the default on the directive define next?
Code:
ICON_SMALL = 0 # define ICON_SMALL 0
The following statement specifies a long, does this mean> 32 bit? In this case type in use. NET?
Code:
0x00000400L # define MF_BYPOSITION
Another question, the values of groups such as GWL_xxx or WS_xxx can be used, and coupled indifferently according to API or are they specific API and at the type of the parameter referencing?
Namely, if such a constant is declared as a signed integer, will always regarded as such even if several APIs use this constant?
Re: Problems in porting Win32 API in PowerShell
Hello,
- To my knowledge, the default type is int, which also gives System.Int32. On the other hand, the type is not specifically stated, it must be possible without a cast in a short ...
- Same. But in passing GWL_WNDPROC is obsolete, use GWLP_WNDPROC now.
- The only difference here is readability. It shows that these flags.
- It specifies a long time, but it is always 32 bits, System.Int32. Even under Windows 64 bit, long stay on 32 bit (LLP64 model). Note that this is not the case in C #, or designate long System.Int64.
- The functions that use a set of constants always say the same type, or equivalent types (int vs long, for example). Except in the case of some handles: loadImage () for example returns both handles USER (hIcon, hCursor) that GDI handles (HBITMAP).
Re: Problems in porting Win32 API in PowerShell
This is what I understood, for some constant I do not know if I have to use IntPtr or System.int32/64
For example 2 for these constants:
Code:
ICON_SMALL = [UInt32] 0 # API SendMessage:
# Typedef UINT wParam; from?
# Or UINT_PTR typedef wParam;? from WTypes.h sdk 6.21
BS_PUSHBUTTON = 0 # # API?:
# Typedef LONG LPARAM; = [IntPtr]? Int64 (signed)?
While knowing that initially, for simplicity, I am not concerned that in 32-bit PowerShell.
Re: Problems in porting Win32 API in PowerShell
For all handles and pointers, in the corresponding type. Net and Powershell is System.IntPtr, and nothing else.
The good wParam typedef C UINT_PTR is therefore in System.IntPtr. Net and Powershell (or UIntPtr, but use of unsigned types is not recommended as non-CLS-compliant).
The proper C typedef LPARAM and lResult LONG_PTR is therefore also System.IntPtr.
SetWindowLongPtr () is for the 64bit compatibility, but can and should be used in 32 bits. Unfortunately, C and C + +, how it is when you set compiles 32 (a simple macro) poses some problems to be solved fairly easily.
BS_PUSHBUTTON is a style, a DWORD (System.UInt32 or System.Int32)