Problèmes suite au portage d'API Win32 sous PowerShell

Salut,
je rencontre un problème d'adaptation de type sur un portage d'API Win32 sous PowerShell (type .NET+ P/Invoke).
Par défaut sous PowerShell un nombre est considéré comme un entier signé (System.Int32).

Je viens d'installer le SDK 6.1 pour accéder aux déclarations présentes dans le fichier WinUser.h, mais je ne sais pas comment interpréter les différents types des valeurs déclarées.
Enfin plus précisement :
-quel est le type par défaut sur la directive define suivante ?

Code:

---

ICON_SMALL = 0 #define ICON_SMALL 0

---

-quel est le type par défaut sur celle-ci ?

Code:

---

GWL_WNDPROC = -4 #define GWL_WNDPROC (-4)

---

-quelle différence pourrait-il y avoir entre

Code:

---

1 2	#define SWP_NOSIZE 0x0001

---

et

Code:

---

1 2	#define SWP_NOSIZE 1

---

- la déclaration suivante précise un long, est-ce à dire >32 bit ? Dans ce cas quel type utiliser sous .NET ?

Code:

---

#define MF_BYPOSITION 0x00000400L

---

Autre question, les valeurs de groupes tels que GWL_xxx ou WS_xxx peuvent-elles être utilisés, et couplés, indifférement selon les API ou sont-elles spécifiques à certaines API et donc aux types du paramètre les référençant ?
A savoir, si telle constante est déclarée comme un type entier signé, sera-t-elle toujours considérée comme tel même si plusieurs API utilisent cette constante ?

Merci

Bonjour,

1. À ma connaissance, le type par défaut est int, ce qui donne System.Int32 également. D'un autre côté, le type n'étant pas spécifiquement précisé, on doit pouvoir le mettre sans cast dans un short...
2. Pareil. Mais au passage, GWL_WNDPROC est obsolète, il faut utiliser GWLP_WNDPROC maintenant.
3. La seule différence ici, c'est la lisibilité. Ça montre bien qu'il s'agit de flags.
4. Ça précise un long, mais c'est toujours 32 bits, System.Int32. Même sous Windows 64 bits, les long restent sur 32 bits (modèle LLP64). Note que ce n'est pas le cas en C#, ou les long désignent System.Int64.
5. Les fonctions qui utilisent un ensemble de constantes les déclarent toujours du même type, ou de types équivalents (int vs long, par exemple). Sauf dans le cas de certains handles: LoadImage() par exemple retourne aussi bien des handles USER (HICON, HCURSOR) que des handles GDI (HBITMAP).

Bonjour,

Citation:

---

Envoyé par Médinoc

À ma connaissance, le type par défaut est int, ce qui donne System.Int32 également.

---

Après qq recherches j'en étais arrivé à cette conclusion mais ta confirmation n'est pas de trop.

Citation:

---

Envoyé par Médinoc

Pareil. Mais au passage, GWL_WNDPROC est obsolète, il faut utiliser GWLP_WNDPROC maintenant.

---

Me basant principalement sur la doc de MSDN, je n'y trouve pas cette constante.
N'est-elle pas dédiée au 64 bits ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

//SDK 6.1 Winuser.h ... /* * Window field offsets for GetWindowLong() */ #define GWL_WNDPROC (-4) #define GWL_HINSTANCE (-6) #define GWL_HWNDPARENT (-8) #define GWL_STYLE (-16) #define GWL_EXSTYLE (-20) #define GWL_USERDATA (-21) #define GWL_ID (-12) #ifdef _WIN64 #undef GWL_WNDPROC #undef GWL_HINSTANCE #undef GWL_HWNDPARENT #undef GWL_USERDATA #endif /* _WIN64 */ #define GWLP_WNDPROC (-4) #define GWLP_HINSTANCE (-6) #define GWLP_HWNDPARENT (-8) #define GWLP_USERDATA (-21) #define GWLP_ID (-12) ...

---

LP pour long pointer ?

Citation:

---

Envoyé par Médinoc

La seule différence ici, c'est la lisibilité. Ça montre bien qu'il s'agit de flags.

---

Je prend conscience que le C sait être très subtile et une fois sut ça coule de source ;-)

Citation:

---

Envoyé par Médinoc

Note que ce n'est pas le cas en C#, ou les long désignent System.Int64.
...
Sauf dans le cas de certains handles: LoadImage() par exemple retourne aussi bien des handles USER (HICON, HCURSOR) que des handles GDI (HBITMAP).

---

C'est ce que j'avais cru comprendre, pour certaines constantes je ne sais pas trop si je dois utiliser IntPtr ou System.int32/64
Par exemple pour ces 2 constantes :

Code:

---

1 2 3 4 5 6

ICON_SMALL =[UInt32]0 #API Sendmessage: # typedef UINT WPARAM; from ??? # ou typedef UINT_PTR WPARAM; ? from WTypes.h sdk 6.21 #BS_PUSHBUTTON=0 #API ?: # typedef LONG LPARAM; = [IntPtr] ? Int64 (signé) ?

---

Tout en sachant que dans un premier temps, pour simplifier, je ne me préoccupe que de PowerShell sous 32 bits.

Pour tous les handles et pointeurs, le type correspondant sous .Net et Powershell est System.IntPtr, et rien d'autre.

Le bon typedef C pour WPARAM est UINT_PTR, donc System.IntPtr en .Net et Powershell (ou UIntPtr, mais l'usage de types non-signés n'est pas recommandé, car non-CLS-compliant).
Le bon typedef C pour LPARAM et LRESULT est LONG_PTR, donc System.IntPtr aussi.

SetWindowLongPtr() est pour la compatibilité 64bits, mais peut et doit être aussi utilisée en 32 bits. Malheureusement en C et C++, la façon dont elle est définie quand tu compiles en 32 (une simple macro) pose quelques problèmes assez faciles à résoudre.

BS_PUSHBUTTON est un style, donc un DWORD (System.UInt32 ou System.Int32)

Citation:

---

Envoyé par Médinoc

Pour tous les handles et pointeurs, le type correspondant sous .Net et Powershell est System.IntPtr, et rien d'autre.

---

"Pour tous les handles et pointeurs" ça j'avais compris, mais je ne sais pas si passer un Int32 ou un UInt32 via P/Invoke à une API attendant un pointeur ou un handle est transparent :?

Citation:

---

Envoyé par Médinoc

ou UIntPtr, mais l'usage de types non-signés n'est pas recommandé, car non-CLS-compliant

---

Bah de ce coté j'ai eu provisoirement le soucis :

Citation:

---

Version 1 of PowerShell doen't natively support unsigned types.

---

Bruce payette

Code:

---

1 2 3 4 5

#impossible # WS_POPUPWINDOW = [UInt32]("0x80000000" -bor 0x00800000 -bor 0x00080000) #Utiliser des long castés en entier signé... WS_POPUPWINDOW =[uint32](0x80000000L + 0x00800000L + 0x00080000L)

---

Citation:

---

Envoyé par Médinoc

quand tu compiles en 32

---

Si j'avais une phase de compilation je pense que j'aurais eu moins de pb, en tout cas en Delphi je n'ai jamais eu à "descendre si bas".
Il me semble que pour ce portage sous PowerShell j'ai à me préoccuper de lever des ambiguïtés (enfin surtout préciser mes intentions). De plus, pour différentes raisons, je dois mémoriser ces constantes de manière particuliéres en définissant leur type (sauf erreur de ma part):

Code:

---

1 2 3 4 5 6 7 8

$Const=@{ NomConstante=[Intptr] 567 } Set-Constant "cConst" $Const "Constantes test" #Pour chaque entrée de la hashtable $Const on construit dynamiquement un membre de type ScriptProperty en lecture seule : # cConst.NomConstante {get=[System.IntPtr] 567;set=Throw "La propriété NomConstante est en lecture seule.";}

---

Citation:

---

Envoyé par Médinoc

BS_PUSHBUTTON est un style, donc un DWORD (System.UInt32 ou System.Int32)

---

Ok
Je te remercie pour ton aide :P