c et api windows

Version imprimable

10/05/2005, 19h30
moknassim

c et api windows

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)
10/05/2005, 19h42
LordBob

regarde par la, ca pourrait te plaire:
http://bob.developpez.com/tutapiwin
10/05/2005, 19h45
moknassim

non c pas ça que je veu (c++ builder) mais une libraire sous c
10/05/2005, 19h49
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 !
10/05/2005, 20h37
Emmanuel Delahaye

Re: c et api windows

Citation:

Envoyé par moknassim

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".
10/05/2005, 21h27
Mac LAK

Re: c et api windows

Citation:

Envoyé par Emmanuel Delahaye

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

http://yelims3.free.fr/Hein/Hein03.gif
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... ;-)
10/05/2005, 21h58
Emmanuel Delahaye

Re: c et api windows

Citation:

Envoyé par Mac LAK

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...

Re: c et api windows

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

Citation:

Envoyé par Emmanuel Delahaye

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".
Citation:
Envoyé par Aide Delphi
Code:

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... ;-)

Citation:

Envoyé par Emmanuel Delahaye

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.

Citation:

Envoyé par Emmanuel Delahaye

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.