Discussion :

[moknassim]

salut,
je programme actuellement en C , et je voudrais utiliser l'api windows , alors quelle librairie complete me conseillez-vous utiliser ?
et sil vous plait des liens pour cette libraire (librairie,installation,tutoriaux)

[LordBob]

regarde par la, ca pourrait te plaire:
http://bob.developpez.com/tutapiwin

[moknassim]

non c pas ça que je veu (c++ builder) mais une libraire sous c

[LordBob]

je ne comprend pas ce que tu veux ! le tutorial est valable pour Builder et VC, ou n'importe qu'elle autre compilo !
on parle d'API d'un systeme d'exploitation et non pas de librairie !
sinon tu as des librairies multiplateforme, mais je presume que ca ne n'est pas ce que tu veux non plus !

[Emmanuel Delahaye]

je programme actuellement en C , et je voudrais utiliser l'api windows , alors quelle librairie complete me conseillez-vous utiliser ?

Avec Dev-C++, tu as accès à l'ensemble des fonctions de l'API Windows. Tu peux même télécharger le manuel...

Je rappelle que le système Windows est livré avec des dizaines de DLL qui offrent au programmeur l'ensemble des fonctions systèmes de Windows quelque soit son langage de programmation.

Pour les utiliser en C, il faut un compilateur/IDE qui fourni les petites bibliothèques (.lib) qui fournissent une interface 'C' aux DLL.

Pour la programmation GUI sous Windows (qui n'a rien à voir avec ce que tu connais), le bon forum est "Développement Windows".

[Mac LAK]

Pour les utiliser en C, il faut un compilateur/IDE qui fourni les petites bibliothèques (.lib) qui fournissent une interface 'C' aux DLL.

L'API Win32 est en C à 99.99%... En général, un "#include <windows.h>" avec un compilateur digne de ce nom (ou le PSDK) suffit à permettre l'utilisation des fonctions usuelles, telles que GetTickCount(), Sleep(), CreateThread(), etc...

Pour les autres, LoadLibrary() et GetProcAddress() sont là pour cette raison : pourquoi donc pleurer pour un .LIB ???

Référence : http://msdn.microsoft.com/library/
Plusieurs milliers de pages à lire, pas plus... ;-)

[Emmanuel Delahaye]

L'API Win32 est en C à 99.99%...

Non, pas du tout (VB ne pourrait pas fonctionner si c'était le cas). L'interface d'une DLL est plutôt de type Pascal (ordre des paramètres inverse du C nombre de paramètre fixe, correction de pile par l'appelé, ce qui interdit les appels avec nombre variable de paramètres)

D'ailleurs lorsqu'on fabrique une DLL, on doit utiliser un tas de mots clés pour les fonctions exportées (PASCAL, WINAPI) qui informent le compilateur qu'il ne doit pas générer une interface C standard mais autre chose. C'est pour cela que n'importe quel compilateur ne peut pas générer de DLL. Il faut un compilateur 'Windows' (VC++6, BCCBuilder, Dev-C++) pour gérer ces particularités...

[Mac LAK]

C'est un peu off-topic, mais bon...

Non, pas du tout (VB ne pourrait pas fonctionner si c'était le cas). L'interface d'une DLL est plutôt de type Pascal (ordre des paramètres inverse du C nombre de paramètre fixe, correction de pile par l'appelé, ce qui interdit les appels avec nombre variable de paramètres)

Je parles de l'API (code en C), pas de l'interface... La convention d'appel (je préfères ce terme à "interface", si ça ne te gêne pas) est en général "stdcall", différente du passage "pascal".

Code :

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

1
2
3
4
5
6
7
Calling conventions 
Directive  Parameter order  Clean-up  Passes parameters in registers?
register   Left-to-right    Routine   Yes
pascal     Left-to-right    Routine   No
cdecl      Right-to-left    Caller    No
stdcall    Right-to-left    Routine   No
safecall   Right-to-left    Routine   No

La convention "cdecl", par exemple, laisse le travail de nettoyage à l'appelant... Et elle est utilisable dans une DLL, comme toutes les autres. Tu peux même mixer plusieurs conventions au sein d'une même DLL, si tu as une violente compulsion masochiste... ;-)

D'ailleurs lorsqu'on fabrique une DLL, on doit utiliser un tas de mots clés pour les fonctions exportées (PASCAL, WINAPI) qui informent le compilateur qu'il ne doit pas générer une interface C standard mais autre chose.

Faux, on peut créer une DLL avec presque n'importe quelle convention d'appel. Bien sûr, dans ce cas, il y a de très fortes chances que la DLL ne soit utilisable qu'avec le compilateur utilisé pour la générer (ou un compilateur sachant utiliser cette convention), je te l'accorde bien volontiers...

En C, l'usage recommande de n'utiliser que WINAPI (défini en général dans "windef.h") pour les DLL, car habituellement, la convention est reconnue par tous les compilateurs sous Windows, y compris (et surtout !) les compilateurs non-C (C++, Delphi, VB, WinDev, etc...).
Cette déclaration peut être propre à chaque compilateur, bien sûr. L'API Win32, elle, n'utilise qu'une seule convention, toujours la même (stdcall) : l'interface Windows (les .H) du compilateur s'y plie pour définir la macro WINAPI.

BC++, MinGW et VC++ la définissent tous trois comme "__stdcall", mais c'est "_far _pascal" pour BC++ en mode 16 bits, par exemple.

C'est pour cela que n'importe quel compilateur ne peut pas générer de DLL. Il faut un compilateur 'Windows' (VC++6, BCCBuilder, Dev-C++) pour gérer ces particularités...

Cf. ci-dessus. Ce n'est vrai que lorsque tu veux t'assurer de la réutilisabilité de la DLL avec d'autres compilateurs/langages.
N'oublie pas que générer une DLL est beaucoup plus l'affaire du linker que du compilateur...


Pour le problème initial du posteur, la "librairie complète" se résume à faire "#include <windows.h>" : un compilateur Win32 digne de ce nom ne viendra même pas te réclamer un seul .LIB (ni quoi que ce soit d'autre, d'ailleurs)... L'importation "manuelle" des DLL (via LoadLibrary) n'est en général nécessaire que pour des fonctions plutôt spécifiques, et souvent de très haut niveau.