Pour utiliser les fonctions systeme windows comme les sockets, les
timers, les threads, enfin ce genre de chose en utilisant C++, existe t
il d autres bibliotheques que la win32, la MFC et l OWL ?
"Arnaud Debaene" wrote in message news:41a886c9$0$13773$
Loïc Joly wrote:
L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table placée à l'offset 0 de l'objet, avec des entrées de 4 octets....
Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé n'importe où... ce qui permet d'en rajouter d'ailleurs sans remettre en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit respecter l'ordre donnée par de la définition de la liste des méthode de l'interface...
Vincent Burrel ferait mieux de revoir ses bouquins d'histoire de l'informatique ;-)
Cerainement car je ne faisais pas référence à l'histoire écrite, mais celle que j'ai vécu. 1990, les langage ++ étaient très peu usité par les professionnels du développement. Et le ++ est arrivé finalement que tardivement dans le monde professionnel, n'a fait que formaliser des concepts utilisés et modélisés depuis des lustres, avant même l'avènement d'UNIX.
VB (VB c'est moi, si vous parlez de Visual Basic, dites MSVB ou Visual basic :-)
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:41a886c9$0$13773$636a15ce@news.free.fr...
Loïc Joly wrote:
L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table placée à
l'offset 0 de l'objet, avec des entrées de 4 octets....
Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé
n'importe où... ce qui permet d'en rajouter d'ailleurs sans remettre en
cause l'objet. Par contre l'ordre des méthodes dans la v-table doit
respecter l'ordre donnée par de la définition de la liste des méthode de
l'interface...
Vincent Burrel ferait mieux de revoir ses bouquins d'histoire de
l'informatique ;-)
Cerainement car je ne faisais pas référence à l'histoire écrite, mais celle
que j'ai vécu. 1990, les langage ++ étaient très peu usité par les
professionnels du développement. Et le ++ est arrivé finalement que
tardivement dans le monde professionnel, n'a fait que formaliser des
concepts utilisés et modélisés depuis des lustres, avant même l'avènement
d'UNIX.
VB
(VB c'est moi, si vous parlez de Visual Basic, dites MSVB ou Visual basic
:-)
"Arnaud Debaene" wrote in message news:41a886c9$0$13773$
Loïc Joly wrote:
L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table placée à l'offset 0 de l'objet, avec des entrées de 4 octets....
Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé n'importe où... ce qui permet d'en rajouter d'ailleurs sans remettre en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit respecter l'ordre donnée par de la définition de la liste des méthode de l'interface...
Vincent Burrel ferait mieux de revoir ses bouquins d'histoire de l'informatique ;-)
Cerainement car je ne faisais pas référence à l'histoire écrite, mais celle que j'ai vécu. 1990, les langage ++ étaient très peu usité par les professionnels du développement. Et le ++ est arrivé finalement que tardivement dans le monde professionnel, n'a fait que formaliser des concepts utilisés et modélisés depuis des lustres, avant même l'avènement d'UNIX.
VB (VB c'est moi, si vous parlez de Visual Basic, dites MSVB ou Visual basic :-)
Arnaud Debaene
Vincent Burel wrote:
"Arnaud Debaene" wrote in message news:41a886c9$0$13773$
Loïc Joly wrote:
L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table placée à l'offset 0 de l'objet, avec des entrées de 4 octets....
Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé n'importe où... ce qui permet d'en rajouter d'ailleurs sans remettre en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit respecter l'ordre donnée par de la définition de la liste des méthode de l'interface...
Mea culpa, je me suis mal exprimé : je ne parlais pas de la v-table mais ben entendu du v-ptr qui pointe dessus.
Arnaud
Vincent Burel wrote:
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:41a886c9$0$13773$636a15ce@news.free.fr...
Loïc Joly wrote:
L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table
placée à l'offset 0 de l'objet, avec des entrées de 4 octets....
Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé
n'importe où...
ce qui permet d'en rajouter d'ailleurs sans remettre
en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit
respecter l'ordre donnée par de la définition de la liste des méthode
de l'interface...
Mea culpa, je me suis mal exprimé : je ne parlais pas de la v-table mais ben
entendu du v-ptr qui pointe dessus.
"Arnaud Debaene" wrote in message news:41a886c9$0$13773$
Loïc Joly wrote:
L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table placée à l'offset 0 de l'objet, avec des entrées de 4 octets....
Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé n'importe où... ce qui permet d'en rajouter d'ailleurs sans remettre en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit respecter l'ordre donnée par de la définition de la liste des méthode de l'interface...
Mea culpa, je me suis mal exprimé : je ne parlais pas de la v-table mais ben entendu du v-ptr qui pointe dessus.
Arnaud
Vincent Burel
"Arnaud Debaene" wrote in message news:41a8acc6$0$23385$
Vincent Burel wrote: > "Arnaud Debaene" wrote in message > news:41a886c9$0$13773$ >> Loïc Joly wrote: >> >> L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table >> placée à l'offset 0 de l'objet, avec des entrées de 4 octets.... > > Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé > n'importe où... >ce qui permet d'en rajouter d'ailleurs sans remettre > en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit > respecter l'ordre donnée par de la définition de la liste des méthode > de l'interface... Mea culpa, je me suis mal exprimé : je ne parlais pas de la v-table mais
ben
entendu du v-ptr qui pointe dessus.
oui oui, c'est ca ! avec COM, ce pointeur n'est pas obligé d'être en début de structure...
VB
"Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
news:41a8acc6$0$23385$626a14ce@news.free.fr...
Vincent Burel wrote:
> "Arnaud Debaene" <adebaene@club-internet.fr> wrote in message
> news:41a886c9$0$13773$636a15ce@news.free.fr...
>> Loïc Joly wrote:
>>
>> L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table
>> placée à l'offset 0 de l'objet, avec des entrées de 4 octets....
>
> Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé
> n'importe où...
>ce qui permet d'en rajouter d'ailleurs sans remettre
> en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit
> respecter l'ordre donnée par de la définition de la liste des méthode
> de l'interface...
Mea culpa, je me suis mal exprimé : je ne parlais pas de la v-table mais
ben
entendu du v-ptr qui pointe dessus.
oui oui, c'est ca ! avec COM, ce pointeur n'est pas obligé d'être en début
de structure...
"Arnaud Debaene" wrote in message news:41a8acc6$0$23385$
Vincent Burel wrote: > "Arnaud Debaene" wrote in message > news:41a886c9$0$13773$ >> Loïc Joly wrote: >> >> L'ABI de COM est celle de VC++ sauf erreur de ma part : v-table >> placée à l'offset 0 de l'objet, avec des entrées de 4 octets.... > > Mauvaise connaissance du sujet, la (les) v-table(s) peut être placé > n'importe où... >ce qui permet d'en rajouter d'ailleurs sans remettre > en cause l'objet. Par contre l'ordre des méthodes dans la v-table doit > respecter l'ordre donnée par de la définition de la liste des méthode > de l'interface... Mea culpa, je me suis mal exprimé : je ne parlais pas de la v-table mais
ben
entendu du v-ptr qui pointe dessus.
oui oui, c'est ca ! avec COM, ce pointeur n'est pas obligé d'être en début de structure...
VB
Emmanuel Delahaye
Aurélien REGAT-BARREL wrote on 25/11/04 :
J'ai quand même envie de pinailler, surtout que je rédige un petit article là dessus, ça va me permettre d'avoir votre avis. Win32 est en C, certes,
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en n'importe quoi. Seul compte l'interface, et le fait qu'elles soient implémentée dans une DLL.
Elle sont appelables par n'importe quel langage qui respecte l'ABI des l'API Win32. (Ordre, format, type, nombre de paramètres).
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Aurélien REGAT-BARREL wrote on 25/11/04 :
J'ai quand même envie de pinailler, surtout que je rédige un petit article
là dessus, ça va me permettre d'avoir votre avis. Win32 est en C, certes,
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait
plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en
n'importe quoi. Seul compte l'interface, et le fait qu'elles soient
implémentée dans une DLL.
Elle sont appelables par n'importe quel langage qui respecte l'ABI des
l'API Win32. (Ordre, format, type, nombre de paramètres).
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
J'ai quand même envie de pinailler, surtout que je rédige un petit article là dessus, ça va me permettre d'avoir votre avis. Win32 est en C, certes,
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en n'importe quoi. Seul compte l'interface, et le fait qu'elles soient implémentée dans une DLL.
Elle sont appelables par n'importe quel langage qui respecte l'ABI des l'API Win32. (Ordre, format, type, nombre de paramètres).
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Christian ASTOR
Emmanuel Delahaye wrote:
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en n'importe quoi.
La quasi-totalité des APIs exportées est en C. Dans le Shell, il y a pas mal de C++. Dans le Kernel, pas mal d'ASM.
Emmanuel Delahaye wrote:
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait
plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en
n'importe quoi.
La quasi-totalité des APIs exportées est en C.
Dans le Shell, il y a pas mal de C++.
Dans le Kernel, pas mal d'ASM.
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en n'importe quoi.
La quasi-totalité des APIs exportées est en C. Dans le Shell, il y a pas mal de C++. Dans le Kernel, pas mal d'ASM.
Aurelien REGAT-BARREL
>> J'ai quand même envie de pinailler, surtout que je rédige un petit article là dessus, ça va me permettre d'avoir votre avis. Win32 est en C, certes,
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en n'importe quoi. Seul compte l'interface, et le fait qu'elles soient implémentée dans une DLL.
On aime chercher des poils aux oeufs je vois... :-) J'ai parlé de Win32, pas de l'API Win32. Or ton discours porte sur la notion d'API, d'interface. Ok, mais j'avais plus en tête le sous système Win32 => l'implémentation de l'API au moyen d'un langage non objet. Et quoique tu en dises, avec quelque chose d'aussi bas niveau il est difficile de dissocier l'API Win32 du langage C. C'est pas comme si elle était refilée sous forme de fichiers idl. Là, la documentation des fonctions est en C, le PSDK n'existe que pour le langage C, la dualité ANSI/UNICODE de l'API repose essentiellement sur les possibilités du préprocesseur C, etc... Par exemple tu dis que l'interface est implémentée dans une dll. Mais on peut pinailler, avec les macros d'une part, et surtout avec le fait qu'un sacré nombre de fonctions documentées dans la MSDN n'existe dans aucune dll. Je parle des fonctions en version ANSI/UNICODE biensûr, telle que GetWindowText, qui au passage utilise des chaînes de caractères C et non PASCAL...
Elle sont appelables par n'importe quel langage qui respecte l'ABI des l'API Win32. (Ordre, format, type, nombre de paramètres).
Et il se trouve que cette ABI est celle du langage C. CQFD :-P
-- Aurélien REGAT-BARREL
>> J'ai quand même envie de pinailler, surtout que je rédige un petit
article
là dessus, ça va me permettre d'avoir votre avis. Win32 est en C, certes,
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait
plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en
n'importe quoi. Seul compte l'interface, et le fait qu'elles soient
implémentée dans une DLL.
On aime chercher des poils aux oeufs je vois... :-)
J'ai parlé de Win32, pas de l'API Win32. Or ton discours porte sur la notion
d'API, d'interface. Ok, mais j'avais plus en tête le sous système Win32 =>
l'implémentation de l'API au moyen d'un langage non objet.
Et quoique tu en dises, avec quelque chose d'aussi bas niveau il est
difficile de dissocier l'API Win32 du langage C. C'est pas comme si elle
était refilée sous forme de fichiers idl. Là, la documentation des fonctions
est en C, le PSDK n'existe que pour le langage C, la dualité ANSI/UNICODE de
l'API repose essentiellement sur les possibilités du préprocesseur C, etc...
Par exemple tu dis que l'interface est implémentée dans une dll. Mais on
peut pinailler, avec les macros d'une part, et surtout avec le fait qu'un
sacré nombre de fonctions documentées dans la MSDN n'existe dans aucune dll.
Je parle des fonctions en version ANSI/UNICODE biensûr, telle que
GetWindowText, qui au passage utilise des chaînes de caractères C et non
PASCAL...
Elle sont appelables par n'importe quel langage qui respecte l'ABI des
l'API Win32. (Ordre, format, type, nombre de paramètres).
Et il se trouve que cette ABI est celle du langage C. CQFD :-P
>> J'ai quand même envie de pinailler, surtout que je rédige un petit article là dessus, ça va me permettre d'avoir votre avis. Win32 est en C, certes,
Personne n'a dit ça. Win32, ce sont des fonctions systèmes. Elle serait plutôt 'en Pascal' vu l'ABI utilisée... En fait elles sont écrites en n'importe quoi. Seul compte l'interface, et le fait qu'elles soient implémentée dans une DLL.
On aime chercher des poils aux oeufs je vois... :-) J'ai parlé de Win32, pas de l'API Win32. Or ton discours porte sur la notion d'API, d'interface. Ok, mais j'avais plus en tête le sous système Win32 => l'implémentation de l'API au moyen d'un langage non objet. Et quoique tu en dises, avec quelque chose d'aussi bas niveau il est difficile de dissocier l'API Win32 du langage C. C'est pas comme si elle était refilée sous forme de fichiers idl. Là, la documentation des fonctions est en C, le PSDK n'existe que pour le langage C, la dualité ANSI/UNICODE de l'API repose essentiellement sur les possibilités du préprocesseur C, etc... Par exemple tu dis que l'interface est implémentée dans une dll. Mais on peut pinailler, avec les macros d'une part, et surtout avec le fait qu'un sacré nombre de fonctions documentées dans la MSDN n'existe dans aucune dll. Je parle des fonctions en version ANSI/UNICODE biensûr, telle que GetWindowText, qui au passage utilise des chaînes de caractères C et non PASCAL...
Elle sont appelables par n'importe quel langage qui respecte l'ABI des l'API Win32. (Ordre, format, type, nombre de paramètres).
Et il se trouve que cette ABI est celle du langage C. CQFD :-P
-- Aurélien REGAT-BARREL
Emmanuel Delahaye
Aurelien REGAT-BARREL wrote on 29/11/04 :
Elle sont appelables par n'importe quel langage qui respecte l'ABI des l'API Win32. (Ordre, format, type, nombre de paramètres).
Et il se trouve que cette ABI est celle du langage C. CQFD :-P
Elle est inversée, non ? Avec correction de pile dans la fonction et nombre fixe de paramètres ? C'était comme ça en Win 16, ça a peut être changé en Win 32...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Clearly your code does not meet the original spec." "You are sentenced to 30 lashes with a wet noodle." -- Jerry Coffin in a.l.c.c++
Aurelien REGAT-BARREL wrote on 29/11/04 :
Elle sont appelables par n'importe quel langage qui respecte l'ABI des
l'API Win32. (Ordre, format, type, nombre de paramètres).
Et il se trouve que cette ABI est celle du langage C. CQFD :-P
Elle est inversée, non ? Avec correction de pile dans la fonction et
nombre fixe de paramètres ? C'était comme ça en Win 16, ça a peut être
changé en Win 32...
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++
Elle sont appelables par n'importe quel langage qui respecte l'ABI des l'API Win32. (Ordre, format, type, nombre de paramètres).
Et il se trouve que cette ABI est celle du langage C. CQFD :-P
Elle est inversée, non ? Avec correction de pile dans la fonction et nombre fixe de paramètres ? C'était comme ça en Win 16, ça a peut être changé en Win 32...
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Clearly your code does not meet the original spec." "You are sentenced to 30 lashes with a wet noodle." -- Jerry Coffin in a.l.c.c++
Aurelien REGAT-BARREL
>> Et il se trouve que cette ABI est celle du langage C. CQFD :-P
Elle est inversée, non ? Avec correction de pile dans la fonction et nombre fixe de paramètres ? C'était comme ça en Win 16, ça a peut être changé en Win 32...
PASCAL est devenu obsolète, c'est WINAPI e.g. __stdcall now. D'après ce que je sais c'est un mix C/PASCAL (entre ordre de passage qui est C je crois, gestion de la pile PASCAL, name mangling heu je sais plus, faudrait voir la doc). Y'a une histoire de vararg aussi, qui est permis avec __stdcall. Mais c'est surtout pour les types utilisés et les pointeurs à gogo que je dis CQFD. Dans ABI j'inclus les types utilisés (en particulier les chaînes).
-- Aurélien REGAT-BARREL
>> Et il se trouve que cette ABI est celle du langage C. CQFD :-P
Elle est inversée, non ? Avec correction de pile dans la fonction et
nombre fixe de paramètres ? C'était comme ça en Win 16, ça a peut être
changé en Win 32...
PASCAL est devenu obsolète, c'est WINAPI e.g. __stdcall now. D'après ce que
je sais c'est un mix C/PASCAL (entre ordre de passage qui est C je crois,
gestion de la pile PASCAL, name mangling heu je sais plus, faudrait voir la
doc). Y'a une histoire de vararg aussi, qui est permis avec __stdcall. Mais
c'est surtout pour les types utilisés et les pointeurs à gogo que je dis
CQFD. Dans ABI j'inclus les types utilisés (en particulier les chaînes).
>> Et il se trouve que cette ABI est celle du langage C. CQFD :-P
Elle est inversée, non ? Avec correction de pile dans la fonction et nombre fixe de paramètres ? C'était comme ça en Win 16, ça a peut être changé en Win 32...
PASCAL est devenu obsolète, c'est WINAPI e.g. __stdcall now. D'après ce que je sais c'est un mix C/PASCAL (entre ordre de passage qui est C je crois, gestion de la pile PASCAL, name mangling heu je sais plus, faudrait voir la doc). Y'a une histoire de vararg aussi, qui est permis avec __stdcall. Mais c'est surtout pour les types utilisés et les pointeurs à gogo que je dis CQFD. Dans ABI j'inclus les types utilisés (en particulier les chaînes).
