Discussion :

[jdsetls]

Bonjour,

Qui utilise les API Windows et de quelle façon ?
J'ai l'impression qu'on peut absolument tout faire avec, sauf qu'elles sont un peu décourageantes en terme de convivialité.

Qu'en pensez-vous ?

Merci
Cordialement

[Patrice Terrier]

Principalement les programmeurs système, les programmeurs de jeux, et les fournisseurs de composants qui proposent des "addons" sous forme de DLL Win32, seul format compatible avec tous les langage de programmation Windows, à condition d'utiliser la convention d'appel _stdcall au lieu de _cdecl.

Bien entendu pas question de MFC ni d'ATL et encore moins de DotNET

Quelques avantage qui résultent de l'utilisation directe de l'API Windows bas niveau :
- Il n'y a aucune encapsulation, donc pas de Framework supplémentaire à télécharger.
- Le code est très rapide et très compacte car tout est déjà dans la Flat API de Windows.
- On peut contourner les bugs des langages "évolués".
- On peut créer ses propres composants.
etc.

Pour ceux qui parlent anglais, voir ma profession de foi ici :
http://www.jose.it-berater.org/smffo...p?topic=1129.0

et pour ceux qui veulent en apprendre plus sur la programmation bas niveau (en anglais), voir là :
http://www.jose.it-berater.org/smffo...hp?board=151.0

...

[jurassic pork]

hello Patrice,

Bien entendu pas question de MFC ni d'ATL et encore moins de DotNET

Qu'entends-tu par là ?

[jdsetls]

Bonjour,
Si j'ai bien compris, la cinquième édition du livre de Charles Petzold SDK est 'culte'.
Je me souviens avoir acheté un des tout premiers bouquin en américain sur les API.
Un pavé dans les 1300 pages.
Cordialement

[Patrice Terrier]

Qu'entends-tu par là ?

Depuis de nombreuses années, toute la politique de Microsoft a été de détourner les "programmeurs" de la programmation bas niveau.
Sous prétexte que le code "managé" est plus sûr que le code bas niveau qui lui est "unsafe", résultat les jeunes informaticiens ne savent plus programmer en utilisant directement le SDK, et il sont incapable d'écrire le moindre bout de code avec un simple éditeur ASCII et un compilateur en ligne de commande, et je ne parle même pas de la taille du code généré.

Je programme de temps en temps en C#, mais ne l'utilise jamais en production, uniquement pour des démos. Car je ne supporte pas d'attendre 45 secondes avant de pouvoir afficher "Hello world" la première fois qu'il doit charger le Framework DotNET.
En outre comme le code IL n'est pas du véritable code compilé, il est impossible de l'exécuter sans "run-time", dans ces conditions je préfère utiliser WinDev.

Concernant MFC et ATL, ils ne fonctionnent pas sans le CRT Microsoft, alors bonjour la galère quand la bonne version n'est pas installée sur la machine des clients, ou alors il faut utiliser à chaque fois un installateur, donc pas question d'envoyer simplement un ZIP avec juste l'EXE. Et comme je n'utilise pas la POO je n'ai rien à faire de MFC (Microsoft Foundation Class).

...

[DelphiManiac]

...
En outre comme le code IL n'est pas du véritable code compilé, il est impossible de l'exécuter sans "run-time", dans ces conditions je préfère utiliser WinDev....

Le code Winev n'est pas plus compilé que l'IL et Windev à tout autant besoin d'un runtime.

L'avantage de l'IL par rapport à Windev, c'est que le framework (au moins en version 2) est déployé nativement sur la plupart des versions de Windows.


Concernant les API, pourquoi pas quand on a besoin de performances maximales, sinon le reste du temps, c'est une "bétise" de se passer des framework, ceux ci apportent des fonctionnalités testées et validées. Pourquoi réinventer la roue à chaque fois ?

En allant à l’extrême, tu devrais te mettre à l'assembleur, cela semble bien correspondre à ta forme de pensée, mais ce n'est pas parce que tu penses d'une certaine manière que celle ci est la meilleure :/ La réciproque es tout autant valide.


Juste pour mon information, quand tu codes et que tu as besoin d'afficher une fenêtre, tu codes toi même, à chaque fois, la boucle de gestion des messages ?

[Patrice Terrier]

Le code Winev n'est pas plus compilé que l'IL et Windev à tout autant besoin d'un runtime.

Oui, vous avez tout à fait raison, WinDev est du p-code, mais je préfère utiliser WinDev que DotNET, car je n'ai pas à me prendre la tête pour m'interfacer avec les DLLs bas niveau.

Concernant les API, pourquoi pas quand on a besoin de performances maximales, sinon le reste du temps, c'est une "bétise" de se passer des framework, ceux ci apportent des fonctionnalités testées et validées. Pourquoi réinventer la roue à chaque fois ?

Je ne cherche pas à polémiquer, j'essaie de répondre aux questions qui me sont posées.
Je ne cherche pas non plus à réinventer la roue, puisque déjà tout existe dans l'API bas niveau

En allant à l’extrême, tu devrais te mettre à l'assembleur, cela semble bien correspondre à ta forme de pensée, mais ce n'est pas parce que tu penses d'une certaine manière que celle ci est la meilleure.

Pour ce qui est le cœur de mon métier, à savoir la programmation de composants, je n'ai pas le choix.
Par contre quand je dois écrire des applications complètes, je fais appel à WinDev, c'est pour cela qu'il fait partie de ma boîte à outils.

Concernant l'assembleur, pourquoi pas, lorsque c'est nécessaire...
Voici un exemple de calcul matriciel utilisé dans la version 32-bit de GDImage.dll (écrit en PowerBASIC)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
SUB MatrixMul5x5FPU(BYREF mr() AS SINGLE, BYREF m1() AS SINGLE, BYREF m2() AS SINGLE )
DIM p AS SINGLE PTR
 
p = VARPTR(m1(0))
! mov ecx,eax
p = VARPTR(m2(0))
! mov edx,eax
p = VARPTR(mr(0))
 
block:
! call column
! call column
! call column
! call column
! call column
EXIT SUB
 
column:
! call cell
! call cell
! call cell
! call cell
! call cell
! add edx,20
! sub ecx,20
! ret
 
cell: ' row A * column B
! fld   dword ptr [ecx   ]
! fmul  dword ptr [edx   ]
! fld   dword ptr [ecx+20]
! fmul  dword ptr [edx+04]
! fld   dword ptr [ecx+40]
! fmul  dword ptr [edx+08]
! fld   dword ptr [ecx+60]
! fmul  dword ptr [edx+12]
! fld   dword ptr [ecx+80]
! fmul  dword ptr [edx+16]
! faddp st(1),st(0)
! faddp st(1),st(0)
! faddp st(1),st(0)
! faddp st(1),st(0)
! fstp  dword ptr [eax]
! add   eax,4
! add   ecx,4
! ret
END SUB

Juste pour mon information, quand tu codes et que tu as besoin d'afficher une fenêtre, tu codes toi même, à chaque fois, la boucle de gestion des messages ?

Tout dépend du langage que j'utilise, mais les exemples que j'ai posté ici, sont issus du C++, alors j'utilise la seule syntaxe qui me permet de faire du copier coller de l'un à l'autre. Au passage çà permet de voir ce qu'il y a sous le capot, car n'oubliez pas que WinDev lui-même est programmé principalement en C++.

...

[jurassic pork]

hello,
je suis tout à fait d'accord avec DephiManiac concernant dotnet. Il est vrai que depuis windows 7 le framework dotnet est intégré à toutes les versions de windows. Sachant que c'est microsoft qui le produit autant dire que son intégration à windows est optimale. Patrice tu dis que tu attends 45 secondes pour que dotnet se lance la première fois, cela m'étonne fortement tu dois avoir un processeur un peu lent . L'avantage a l'utiliser dans windev par rapport aux api c'est que les objets dotnets sont vus comme des classes avec leurs methodes et leurs propriétés. Beaucoup plus facile à interfacer qu'avec les apis. Bien sur tout n'est pas parfait et il y a des assemblages dotnet que l'on arrive pas à utiliser dans windev mais la plupart du temps cela fonctionne.

Ami calmant, J.P

[Patrice Terrier]

Monsieur JP

L'avantage a l'utiliser dans windev par rapport aux api c'est que les objets dotnets sont vus comme des classes avec leurs methodes et leurs propriétés. Beaucoup plus facile à interfacer qu'avec les apis.

Je comprends votre point de vu, mais en raison des contraintes de programmation qui sont les miennes, je préfère l'utilisation de l'API bas niveau qui me permet de passer d'un langage à l'autre... facilement (oui, oui).

...

[Hibernatus34]

Même chez Microsoft, il est arrivé qu'on utilise le SDK pour contourner la lenteur de .Net.
Il y avait un article de blog de l'équipe Visual Studio qui expliquait comment ils faisaient apparaître le splash screen de VS2010 et pourquoi (lenteur de chargement avec .Net).

Microsoft se ré-intéresse au C++ depuis quelques temps, et au lieu de faire une API "tout .Net" comme certains le prédisaient, il ont fait WinRT...


Personnellement, je pense que vous avez tous raison, seulement vous ne développez pas les mêmes choses. WinDev n'est pas dépendant de .Net, donc une "extension" à WinDev ne doit pas l'être non plus.

Comprendre le fonctionnement interne d'une appli Windows me paraît utile, car WinDev se calque pas mal dessus.
Un exemple simple : TimerSys() ne fait qu'un SetTimer(), qui génère un message WM_TIMER, donc un événement de l'IHM, et non un traitement parallèle comme peuvent le penser des débutants.

J'ai moi aussi développé des extensions à mes applis WinDev sous forme de DLL natives et elles n'utilisent évidemment aucun framework à la noix (genre MFC), il faut que ça soit léger, rapide, fiable et sans dépendances. De toute façon, ce que je fais avec est plus facilement écrit en C++ qu'en un quelconque langage .Net.

[Patrice Terrier]

Monsieur Hibernatus34

Vous avez tout à fait raison.
Microsoft est entrain (une nouvelle fois) de faire machine arrière, pour générer à nouveau du code qui ne nécessite pas un Framework monstrueux (DotNET) et qui soit capable de tourner sur des tablettes... ANDROID (sic), la concurrence a du bon, merci Google !

Retour à la case départ.

PS : GDIPLUS et même DWM sont écrits en mode procédural et en code dit "unsafe" !!!

Note : code "unsafe" = code qui manipule des pointeurs pour adresser directement les registres du CPU.
C'est la seule chose que comprenne le code machine (assembleur), avec entre autre l'instruction JUMP qui n'est rien d'autre qu'un GOTO

...

[Lana.Bauer]

Un sondage a été ajouté. Merci pour cette discussion intéressante.

[jdsetls]

Bonjour,
Autant je suis persuadé de l'utilité et de la puissance des API, fonctions Windows de base permettant de gérer le système, autant je suis perplexe.
Leur syntaxe, comme disent les américains, est 'arcane', c'est à dire réservée aux initiés.
Et tchernobylesque en ce sens qu'elles utilisent des codes issus du C ou C++ qui déconcertent l'innocent utilisateur de Windev.
Si le C et ses avatars sont des Dieux majeurs, je dois être un Dieu mineur qui se cache sous les pierres.
Pourtant je me souviens que, lors des cours PCSoft Windev expert 1 et expert 2, on nous a appris à utiliser les API.

Ce que je voudrais ici, et par exemple je crois l'excellent Hibernatus en être capable, c'est de savoir comment passer les paramètres de façon simple, presque en aveugle et sans comprendre le code.
Prenons un exemple. La liste exhaustive des API Windows se trouve dans leur index à :
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

On peut y lire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
BOOL WINAPI SystemParametersInfo(
  _In_     UINT uiAction,
  _In_     UINT uiParam,
  _Inout_  PVOID pvParam,
  _In_     UINT fWinIni
);
 
Parameters
 
uiAction [in]
 
    Type: UINT

Cette API est courte. Je l'ai choisie pour cela.
Pour autant, en l'absence d'exemples je ne comprends pas ce qu'elle fait :

Retrieves or sets the value of one of the system-wide parameters. This function can also update the user profile while setting a parameter.

C'est beau !!!
Je me souviens que le péché mortel en pédagogie est le présupposé. On suppose que le lecteur connait déjà.

Donc merci de lister ici des exemples clairs d'API, afin de stimuler les rares neurones qui me restent.
Cordialement

[Hibernatus34]

Pour répondre au sondage :
- Beaucoup de GDI+ (version native C++)
- DirectSound
- Manipulation de fenêtres, champs (notamment layered windows pour des effets sympas)

Et hors SDK Windows, on a des projets utilisant des SDK de matériel (e.g. ED-SDK Canon), libs de traitement d'image (e.g. ArcSoft), nos propres DLL C++ (soit du traitement, soit un pont vers d'autres API, car c'est plus pratique en C++ qu'en WD), libs comme libvlc, LAME...

[Ry_Yo]

...

Pour autant, en l'absence d'exemples je ne comprends pas ce qu'elle fait :
Retrieves or sets the value of one of the system-wide parameters. This function can also update the user profile while setting a parameter.

C'est beau !!!
Je me souviens que le péché mortel en pédagogie est le présupposé. On suppose que le lecteur connait déjà.

Donc merci de lister ici des exemples clairs d'API, afin de stimuler les rares neurones qui me restent.
Cordialement

Bonjour, vous parlez de stimuler les neurones, c'est que vous avez une envie d'apprendre. Donc si vous prenez le temps calmement de lire l'aide, vous auriez les réponses à vos interrogations.

Vous sortez une phrase du contexte, il est donc normal que personne ne comprenne rien. Il est clair que n'importe qui se poserait des questions à la lecture de la phrase que vous avez sorti comme ça sans le reste de l'aide.
Si je m'amuse à faire la même analogie avec l'aide de windev :

HLitRecherche (Fonction)
Positionne sur le premier enregistrement du fichier de données dont la valeur d'une rubrique spécifique est supérieure ou égale à une valeur recherchée (recherche générique). L'enregistrement est lu et les variables HFSQL correspondantes sont mises à jour.

Hein, quoi ? c'est quoi un fichier de données, une rubrique ? c'est quoi les variables HFSQL ? Ca veut dire que HLitRecherche attend une fonction en paramètre ?
Pour vous citez :

...
Je me souviens que le péché mortel en pédagogie est le présupposé. On suppose que le lecteur connait déjà.

Bref, donc si vous prenez le temps de lire et comprendre l'aide de la msdn : Cette fonction permet de récupérer ou modifier un paramètre système (windows)

Je vois déjà la question suivante : oui, mais je ne sais pas c'est quoi un paramètre système ? et qu'est-ce que je dois écrire.

Toujours un peu plus bas dans l'aide de la msdn :
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

The system-wide parameter to be retrieved or set. The possible values are organized in the following tables of related parameters:

Accessibility parameters
Desktop parameters
Icon parameters
Input parameters
Menu parameters
Power parameters
Screen saver parameters
Time-out parameters
UI effect parameters
Window parameters
....

S'en suit l'énumération de tous les paramètres modifiable pour chaque famille de paramètres.

Puis comme pour l'aide windev, un détail de la valeur attendu pour chaque paramètre.

[Patrice Terrier]

Un sondage a été ajouté. Merci pour cette discussion intéressante.

A mon avis il manque une option :
- Oui, toujours

Utilisation systématique des API = réduction drastique de la taille du code et augmentation des performances, tout en économisant la mémoire.

On gagne sur tous les tableaux !

[WDKyle]

Il faudrait écrire un "Les API pour les nuls"

[jdsetls]

Bonjour, vous parlez de stimuler les neurones, c'est que vous avez une envie d'apprendre. Donc si vous prenez le temps calmement de lire l'aide, vous auriez les réponses à vos interrogations.

Vous sortez une phrase du contexte, il est donc normal que personne ne comprenne rien. Il est clair que n'importe qui se poserait des questions à la lecture de la phrase que vous avez sorti comme ça sans le reste de l'aide.
Si je m'amuse à faire la même analogie avec l'aide de windev :


Hein, quoi ? c'est quoi un fichier de données, une rubrique ? c'est quoi les variables HFSQL ? Ca veut dire que HLitRecherche attend une fonction en paramètre ?
Pour vous citez :


Bref, donc si vous prenez le temps de lire et comprendre l'aide de la msdn : Cette fonction permet de récupérer ou modifier un paramètre système (windows)

Je vois déjà la question suivante : oui, mais je ne sais pas c'est quoi un paramètre système ? et qu'est-ce que je dois écrire.

Toujours un peu plus bas dans l'aide de la msdn :
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx



S'en suit l'énumération de tous les paramètres modifiable pour chaque famille de paramètres.

Puis comme pour l'aide windev, un détail de la valeur attendu pour chaque paramètre.

..................
Merci pour tout cela,
Il vous sera par conséquent facile de nous donner un exemple Windev d'utilisation de cette API ?
D'autant que chacun est demandeur.
Il me semble avoir lu exhaustivement tout cela. Si vous n'arrivez pas à illustrer l'exemple, alors c'est que vous avez lu autant que moi.
Merci d'avance si vous réussissez,
Cordialement

[Hibernatus34]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
bAnim est booléen
 
API("User32", "SystemParametersInfoA", 0x1042, 0, &bAnim, 0)
Trace("SPI_GETCLIENTAREAANIMATION -> " + bAnim)

Effectivement, c'est facile.
Mais vous avez choisi une page d'aide énorme, à cause d'une énumération, alors qu'il y en a des bien plus courtes qui permettent de prendre ses marques facilement.
Notamment pour repérer le petit pavé qui donne le nom de la DLL (User32) et le nom de la fonction (SystemParametersInfoA/SystemParametersInfoW)...

C'est comme vouloir rentrer par une fenêtre du 2ème étage alors qu'il y en a une ouverte au rez-de-chaussée...

[Ry_Yo]

..................
...
Il me semble avoir lu exhaustivement tout cela. Si vous n'arrivez pas à illustrer l'exemple, alors c'est que vous avez lu autant que moi.
...
Cordialement

Je ne suis pas là pour écrire à votre place, "je ne comprends pas" n'est pas assez précis pour moi. Qu'est-ce que vous ne comprenez pas ? l'aide de la msdn, l'aide de windev pour la fonction API() ?

Mais vu que vous doutez de la pertinence de mes posts.... J'ai bien compris que vous n'avez jamais manipulé les API avec Windev. Donc dans un autre de vos post, je vous ai dis de vous penchez sur WDAPI.EXE afin d'avoir déjà une structure à peu près correcte :
http://www.developpez.net/forums/d14...v/#post7822002

Donc après avoir lancé WDAPI vous auriez écrit quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
RetourFonction est un booléen // Type C :BOOL
uiAction est un entier sans signe // Type C :UINT
uiParam est un entier sans signe // Type C :UINT
pvParam est un entier système // Type C :PVOID
fWinIni est un entier sans signe // Type C :UINT
 
RetourFonction=API("USER32","SystemParametersInfoA",uiAction,uiParam,pvParam,fWinIni)

Ensuite vous dites que l'aide de la msdn est incompréhensible, à cela je vous ai répondu oui et non. tout comme l'aide de PCSOFT ou le manuel d'utilisation d'un boeing 747... il faut un minimum de connaissance pour la comprendre.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
BOOL WINAPI SystemParametersInfo(  <--Cela signifie que SystemParametersInfo() est une fonction qui retournera un booléen
  _In_     UINT uiAction,              <-- _In_ signifie paramètre d'entrée
  _In_     UINT uiParam,               <-- _In_ signifie paramètre d'entrée
  _Inout_  PVOID pvParam,           <-- _InOut_ signifie pointeur paramètre d'entrée/sortie
  _In_     UINT fWinIni                  <-- _In_ signifie paramètre d'entrée
);

Voilà....

Maintenant imaginons que je veuille récupérer la vitesse de la souris. Je continu de lire l'aide de la MSDN et je tombe sur ça :

SPI_GETMOUSESPEED
0x0070

Retrieves the current mouse speed. The mouse speed determines how far the pointer will move based on the distance the mouse moves. The pvParam parameter must point to an integer that receives a value which ranges between 1 (slowest) and 20 (fastest). A value of 10 is the default. The value can be set by an end-user using the mouse control panel application or by an application using SPI_SETMOUSESPEED.

Donc super je sais que le paramètre "uiParam" doit être égale à SPI_GETMOUSESPEED qui est égale à la valeur 0x0070

Donc si je veux pas m'embêter à convertir de l'hexa en décimal j'écris ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
RetourFonction est un booléen // Type C :BOOL
uiAction est un entier sans signe // Type C :UINT
uiParam est un entier sans signe // Type C :UINT
pvParam est un entier système // Type C :PVOID
fWinIni est un entier sans signe // Type C :UINT
nVitesse est un entier
 
uiParam = 0
uiAction = 0x0070 //récup les infos
pvParam = &nVitesse 
fWinIni = 0
 
RetourFonction=API("USER32","SystemParametersInfoA",uiAction,uiParam,pvParam,fWinIni)
info(nVitesse)

à la question pourquoi uiParam = 0, toujours en lisant l'aide :

uiParam [in]

Type: UINT

A parameter whose usage and format depends on the system parameter being queried or set. For more information about system-wide parameters, see the uiAction parameter. If not otherwise indicated, you must specify zero for this parameter.

En gros cela dit que ce paramètre est optionnel, il dépend du type de paramètre système que l'on manipule. En l'occurrence ici récupérer la vitesse de la souris ne soit pas obligatoire. Par défaut j'ai mis zéro...

Et même réponse pour le paramètre fWinIni

En conclusion vous devriez avec un code qui vous renvoi la vitesse de la souris qui est compris entre 1 et 20. amusez-vous dans le panneau de configuration à modifier cette valeur et lancer le morceau de code, miracle, on récupère bien la vitesse de la souris.

Une fois de plus, je n'ai rien inventé, mais je prends le temps nécessaire à comprendre "l'aide en ligne" soit directement, soit grâce à google....

EDIT : Pour ma défense, sachez que je suis un développeur 100% WLangage, je n'ai jamais travaillé sur d'autres langage (à peine étudier).