> Je sais pas, tout comme toi, mais disons qu'une societe a des raisons d'augmenter ses chiffres, IDC un peu moins.
Les chiffres de Red Hat sont des chiffres comptables. De plus Red Hat étant en bourse ils sont vérifiables. Là tu dis que Red Hat magouille et tu pousses le bouchon un peu loin si tu n'as aucune preuve. Et si t'en as, lance des poursuites contre Red Hat. Tu es sûr de gagner et tu auras la bénédictions des actionnaires de Red Hat.
> IDC un peu moins.
Je n'ai pas remis en cause l'honnêteté d'IDC dans cette étude.
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
> a) Tout n'est pas dispo en 64bit sur Linux, loin de la
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
> b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Si Fedora/OOo (idem pour RHEL le produit commercial avec support et tout) le fait, j'ai énormément de difficulté à comprendre pourquoi Windows ne le fait pas si selon toi il n'y a aucune difficulté. Et notes bien que les moyens de Microsoft n'ont rien à voir avec les moyens ridicules de Red Hat à côté.
> Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent. Quand on connait les moyens de Windows, si tu affirmes qu'il n'y a pas de problème pour MS de fournir du 64 bits, on a un sérieux problème de logique dans ce que tu dis.
Pour info, AMD64 (en vrai 64 bits) est dispo depuis RHEL 3 (avec support et tout et plein de programme). Et pour une version de Linux en 64 bits (avec 99,9% des logiciels) il faut remonter à la nuit des temps.
M'enfin, continu d'affirmer que windows est aussi portable que Linux.
> Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Ben je n'ai vu que ucs-2.
> ca fait 6 ans...
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
> Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
+1 pour toi. Même si je trouve que c'est de la connerie à moyen/long terme.
> Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID
Oui. Désolé d'avoir dit PID.
> Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Linux a :
- Process ID pour les thread : c'est le même pour tous les thread d'un processus (normal, tous thread appartient à un processus). Le thread n'a pas cette information directement attaché à lui.
- Thread ID pour chaque thread : Le type n'est pas pid_t mais pthread_t
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Par contre au niveau noyau (chose dont n'a pas à se préoccuper le développeur), les numéros de processus (pid_t) et de thread (pthread_t) sont partagés. Le premier thread d'un processus a pthread_t = pid_t. Pour les autres pthread_t != pid_t (quelque soit le thread et le processus). Mais ça le développeur s'en fout. Si un jour Linux change ça, il n'y aura pas de problème de portabilité (sauf pour les applis codé avec les pieds).
> Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu serais gentil d'arrêter de me prendre pour un con.
> Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
+0,1 pour toi. Mais Windows a encore mieux et ça on ne le trouve pas sous Linux :-)
C'est WaitForMultiObject et notamment avec l'option "auto-reset". Avec les mutex c'est intéressant, d'autant plus que c'est atomic. On peut le simuler sous Linux mais ce n'est pas trivial.
> Sous Windows, personne n'utilises le modele "plusieurs processus"
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Alors que Windows fasse un gros processus. Les autres programmes (stockés dans des dll) seront dans des threads. C'est techniquement tout à fait réalisable. Mais dès qu'un truc plante, tout plante. Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Donc ne dit pas que "Sous Windows, personne n'utilises le modele "plusieurs processus"" car c'est absolument faux.
> sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux. Le seul problème de Linux est que durant assez longtemps il n'avait pas de thread au niveau noyau. C'est-à-dire que ça ne permettait pas de tirer profit des systèmes multi-cpu. Mais sur la bécane de messieur tout le monde on a rarement du multi-cpu (et même sur la majorité des serveurs).
Notons que les gains de performance du multi-thread sur le multi-processus n'est pas énorme (et souvent nul). D'autant plus que créer un processus sous Linux n'est pas cher (fork() ou clone()).
On a vu plusieurs projet forker un projet pour le passer en multi-thread sans qu'il y ait de gain.
> le support des threads etait a chier
C'est-à-dire ? Depuis Linux 2.0 le multi-thread est Posix. Il n'était pas parfaitement Posix mais à 98 % Posix. NTPL l'a rendu 100% Posix (ou 99,9 %). C'est ce qui a permis aux applications Linux de passer rapidement de LinuxThread à NPTL.
Exemple : Il y avait LinuxThead et NPTL dans RHEL 3. Il n'y a que NPTL dans RHEL 4. Pourtant fournir LinuxThread en parallèle n'est pas un problème. Mais porter les applications vers NPTL n'est pas un problème non plus.
Donc si tu dis que le multithread était à chier, il doit l'être encore aujourd'hui selon toi.
L'intérêt de NPTL n'était pas de passer d'un multi-thread à chié à un truc formidable. Mais d'avoir le multi-threading en mode noyau et être plus conforme Posix. C'est tout, bien que la tâche n'a pas été évidente.
NPTL a des avantages significatif dans le cas où on a plus de 50 ou 100 thread. Ça ne conserne pas la majorité des applications, c'est le moins qu'on puisse dire.
> resultat, tout le monde utilise les CRITICAL_SECTION
Je ne vois pas le rapport. Je n'ai pas dit que CRITICAL_SECTION était mauvais. Je parlais de l'API. Relis.
> Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
CreateFileMapping() par exemple.
Mais je suis mauvaise langue.
Je me suis trompé.
Il y a (si j'ai bonne mémoire) LocalAlloc qui retourne un HLOCAL et j'ai conclus rapidement qu'un GlobalAlloc retourne un HANDLE alors qu'il retourne un HGLOBAL (si j'ai bonne mémoire).
Retourner un (void *) comme tout le monde ça aurait été trop simple...
> tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
C'est une façon de voir la chose. Mais il n'y a aucun contrôle de type. Le seul intérêt des HANDLE est le WaitFor*Object(). C'est tout.
De plus WaitForSimgleObject ne marche pas pour tout. Il marche que pour attendre la fin d'un timer, la fin d'un thread, etc. Mais un WaitForSem() qui attend qu'un sémaphore passe à 10 ça n'existe pas.
Vu la contrepartie, je trouve ça sans intérêt. Par contre WaitForMultiObject (ou WaitForMultipleObject ?) c'est cool.
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions. Mais tant qu'elles sont rares, ça se gère. Sous Windows l'exception est la règle.
> mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
J'en ai lu beaucoup sur Windows ce dernier mois.
> Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
Le wchar_t je vois l'intérêt. Le WCHAR pourquoi pas. Mais les LPCWSTR, etc c'est stupide et ça n'améliore pas la lecture du code (il faut connaitre une tripoté de typedef).
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Tu me traites de con qui ne sait pas lire la doc. Je bosse sur Windows en tant que développeur depuis 1 mois seulement. Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
> Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Enfin, je tiens à te signalé que j'ai parlé de l'API de Windows après m'être informé. J'en parlais pour expliquer pourquoi "Linux tient tête à Windows" alors que Windows a facilement 100 fois plus de développeur que Linux.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
Il y a moins d'un mois, je n'aurai rien dit de l'API de Windows et j'en ai rien dit jusqu'à ce que je lise la doc.
Si j'étais un anti-Windows primaire, je n'aurais pas dit que l'API de Direct3D est bien foutue ni que le noyau de Windows offre toutes les fonctionnalités qu'on attend d'un OS moderne.
De plus, j'ai passé sous silence DirectShow alors que ça va devenir mon "coeur de métier". En un mot : lourdingue. Tellement lourdingue que MS fournit une tripoté de classe pour simplifier le développement. Mais comme ces classes ne répondent pas à mon besoin... ça va être lourdingue.
Mais DirectShow est bien moins pire que l'API de Windows. Son historique l'a rendu lourdingue. M'enfin, il n'y a pas vraiment d'équivalent dans le libre. Sauf gstreamer mais ce n'est pas encore ça ; espérons que ça ne tarde pas.
NB : gstreamer est beaucoup plus récent que DirectShow. Je dis ça avec que tu te foutes de gstreamer.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
Les chiffres de Red Hat sont des chiffres comptables. De plus Red Hat étant en bourse ils sont vérifiables. Là tu dis que Red Hat magouille et tu pousses le bouchon un peu loin si tu n'as aucune preuve. Et si t'en as, lance des poursuites contre Red Hat. Tu es sûr de gagner et tu auras la bénédictions des actionnaires de Red Hat.
> IDC un peu moins.
Je n'ai pas remis en cause l'honnêteté d'IDC dans cette étude.
> Quand a OpenOffice 64 bit, si je vais sur http://download.openoffice.org/680/index.html je ne le vois pas
http://fr2.rpmfind.net/linux/fedora/core/6/x86_64/os/Fedora/(...)
Cherches openoffice, tu le trouveras en 64 bits. Ce n'est qu'un exemple.
Ceci dit, c'est récent. Mais Openoffice est aussi dispo sur Sparc depuis longtemps.
> a) Tout n'est pas dispo en 64bit sur Linux, loin de la
Ouais, il manque flash.
Tout n'est pas dispo en 64 bit sur Linux. Seulement 99,9 %.
> b) Tu me montres la difference des APIs entre 32bit et 64bit sur Windows ? Je t'aides, t'auras du mal.
Ben si tout nickel (au moins autant que Linux), MS-Office en 64 bits ne coûte rien à faire et devrait déjà être là !
Alors pourquoi il n'y a pas de MS-Office en 64 bits alors que depuis Windows NT il y a une version de Windows en 64 bits ?
Si Fedora/OOo (idem pour RHEL le produit commercial avec support et tout) le fait, j'ai énormément de difficulté à comprendre pourquoi Windows ne le fait pas si selon toi il n'y a aucune difficulté. Et notes bien que les moyens de Microsoft n'ont rien à voir avec les moyens ridicules de Red Hat à côté.
> Quand a Office, ben pour la meme raison qu'OpenOffice faut croire...
T'es un peu girouette...
> Ben moi je vais voir http://www.redhat.com/about/presscenter/2005/press_rhel4.htm(...) et je vois qu'ils supportent x86, Itanium, AMD64 et Power.
> Voila, ca fait UN de plus que Windows, c'est a dire aucune difference a peu pres.
Sauf qu'il y a tout dedans. Et pour PowerPPC, c'est 64 bits.
De plus, je n'ai pas souvenir que Windows a une version AMD64 ! J'ai seulement entendu parlé de versions béta et qu'il y a une version AMD64 pour Vista. C'est donc très récent. Quand on connait les moyens de Windows, si tu affirmes qu'il n'y a pas de problème pour MS de fournir du 64 bits, on a un sérieux problème de logique dans ce que tu dis.
Pour info, AMD64 (en vrai 64 bits) est dispo depuis RHEL 3 (avec support et tout et plein de programme). Et pour une version de Linux en 64 bits (avec 99,9% des logiciels) il faut remonter à la nuit des temps.
M'enfin, continu d'affirmer que windows est aussi portable que Linux.
> Windows supporte UTF-16 depuis un moment deja(depuis XP en tout cas), ca fait 6 ans...
Ben je n'ai vu que ucs-2.
> ca fait 6 ans...
Ce qui est du pipo. Windows est passé à ucs-2 avec Windows NT (ou 2000?). Et je dis bien ucs-2 (2^16 caractères) et non utf-8 (2^32 caractères). Windows 2000 utilise ucs-2 (j'en mettrais ma main au feu) et XP n'est qu'une évolution de Windows 2000.
> Par contre plein de boites prennent leur ancien code 16bit et veulent le recompiler en 32bit, et la ca rend les choses bcp plus simples vu qu'ils n'auront quasiment pas a changer leur code.
+1 pour toi. Même si je trouve que c'est de la connerie à moyen/long terme.
> Il n'y a pas de PID pour les threads sous Windows, il y a un thread ID
Oui. Désolé d'avoir dit PID.
> Linux a un Process ID pour des threads, alors que ce sont des threads, pas des process, tu m'expliqueras la logique.
Linux a :
- Process ID pour les thread : c'est le même pour tous les thread d'un processus (normal, tous thread appartient à un processus). Le thread n'a pas cette information directement attaché à lui.
- Thread ID pour chaque thread : Le type n'est pas pid_t mais pthread_t
J'espère que tu vois maintenant la logique évidente.
C'est comme ça pour LinuxThread et NPTL.
Par contre au niveau noyau (chose dont n'a pas à se préoccuper le développeur), les numéros de processus (pid_t) et de thread (pthread_t) sont partagés. Le premier thread d'un processus a pthread_t = pid_t. Pour les autres pthread_t != pid_t (quelque soit le thread et le processus). Mais ça le développeur s'en fout. Si un jour Linux change ça, il n'y aura pas de problème de portabilité (sauf pour les applis codé avec les pieds).
> Pour les APIs multithread, de nouveau, c'est parece que tu ne comprends rien a l'architecture de Windows.
Tu serais gentil d'arrêter de me prendre pour un con.
> Tu fais comment pour attendre sur un event, un timer, la fin d'un thread, ... sous Linux ? Ah oui, des APIs differents, sous Windows, tous ces elements sont des objets, et tu utilises WaitForSingleObject.
+0,1 pour toi. Mais Windows a encore mieux et ça on ne le trouve pas sous Linux :-)
C'est WaitForMultiObject et notamment avec l'option "auto-reset". Avec les mutex c'est intéressant, d'autant plus que c'est atomic. On peut le simuler sous Linux mais ce n'est pas trivial.
> Sous Windows, personne n'utilises le modele "plusieurs processus"
Ce qui est de la connerie. Le modèle "plusieurs processus" a ses avantages et idem pour le multi-threading.
Le gros problème du multi-threading est que le plantage d'un thread fait planter pour le processus. Et c'est la même chose sous Windows.
Alors que Windows fasse un gros processus. Les autres programmes (stockés dans des dll) seront dans des threads. C'est techniquement tout à fait réalisable. Mais dès qu'un truc plante, tout plante. Et il me semble bien que Windows fournit un truc style "job control" pour "mimer" Unix. Les "jobs" sont des processus et non des thread.
Donc ne dit pas que "Sous Windows, personne n'utilises le modele "plusieurs processus"" car c'est absolument faux.
> sous Unix c'est frequent car jusqu'a recemment le support des threads etait a chier
Rires. Tous les Unix commerciaux ont du multi-thread depuis longtemps. Il n'y a que Linux qui a mis du temps car Linux a débuté en 91 (il était embryonnaire). La version 2.0 de Linux avait le multi-thread. Linux 2.0 est sorti quasiment en même temps que Windows 95/NT (en fait Linux l'avait pour la version 1.2.13 mais pas pour 1.2.0). Donc Windows n'a pas le multi-threading depuis plus longtemps que Linux et assurément pas avant les Unix commerciaux. Le seul problème de Linux est que durant assez longtemps il n'avait pas de thread au niveau noyau. C'est-à-dire que ça ne permettait pas de tirer profit des systèmes multi-cpu. Mais sur la bécane de messieur tout le monde on a rarement du multi-cpu (et même sur la majorité des serveurs).
Notons que les gains de performance du multi-thread sur le multi-processus n'est pas énorme (et souvent nul). D'autant plus que créer un processus sous Linux n'est pas cher (fork() ou clone()).
On a vu plusieurs projet forker un projet pour le passer en multi-thread sans qu'il y ait de gain.
> le support des threads etait a chier
C'est-à-dire ? Depuis Linux 2.0 le multi-thread est Posix. Il n'était pas parfaitement Posix mais à 98 % Posix. NTPL l'a rendu 100% Posix (ou 99,9 %). C'est ce qui a permis aux applications Linux de passer rapidement de LinuxThread à NPTL.
Exemple : Il y avait LinuxThead et NPTL dans RHEL 3. Il n'y a que NPTL dans RHEL 4. Pourtant fournir LinuxThread en parallèle n'est pas un problème. Mais porter les applications vers NPTL n'est pas un problème non plus.
Donc si tu dis que le multithread était à chier, il doit l'être encore aujourd'hui selon toi.
L'intérêt de NPTL n'était pas de passer d'un multi-thread à chié à un truc formidable. Mais d'avoir le multi-threading en mode noyau et être plus conforme Posix. C'est tout, bien que la tâche n'a pas été évidente.
NPTL a des avantages significatif dans le cas où on a plus de 50 ou 100 thread. Ça ne conserne pas la majorité des applications, c'est le moins qu'on puisse dire.
> resultat, tout le monde utilise les CRITICAL_SECTION
Je ne vois pas le rapport. Je n'ai pas dit que CRITICAL_SECTION était mauvais. Je parlais de l'API. Relis.
> Un block memoire ? Tu fais ca comment pour avoir un HANDLE sur un block memoire ?
CreateFileMapping() par exemple.
Mais je suis mauvaise langue.
Je me suis trompé.
Il y a (si j'ai bonne mémoire) LocalAlloc qui retourne un HLOCAL et j'ai conclus rapidement qu'un GlobalAlloc retourne un HANDLE alors qu'il retourne un HGLOBAL (si j'ai bonne mémoire).
Retourner un (void *) comme tout le monde ça aurait été trop simple...
> tu peux attendre sur tous ces objets avec le meme API. Bien plus simple que les 32 APIs differents pour faire la meme chose sous Linux.
C'est une façon de voir la chose. Mais il n'y a aucun contrôle de type. Le seul intérêt des HANDLE est le WaitFor*Object(). C'est tout.
De plus WaitForSimgleObject ne marche pas pour tout. Il marche que pour attendre la fin d'un timer, la fin d'un thread, etc. Mais un WaitForSem() qui attend qu'un sémaphore passe à 10 ça n'existe pas.
Vu la contrepartie, je trouve ça sans intérêt. Par contre WaitForMultiObject (ou WaitForMultipleObject ?) c'est cool.
Sous Linux pour attendre la fin d'un thread on fait pthread_join(pthread_t, void **). Ce n'est pas la mer à boire, c'est lisible.
> Oh si on le sait, c'est meme documente, comme tous les autres types : http://msdn2.microsoft.com/en-gb/library/aa383751.aspx
Donc on a des api qui exige spécifiquement du uint32...
Sous Linux on n'a pas ça. On a pid_t qui on une taille qui colle au hardware ou au besoin de la fonction. Mais on ne dit pas qu'un pid_t doit être un uint32. Un jour c'est un int16, un autre c'est un int32, on s'en fout. Il y a toujours des exceptions. Mais tant qu'elles sont rares, ça se gère. Sous Windows l'exception est la règle.
> mais visiblement tu ne lis pas la doc, dans ce cas pas etonnant que tu n'y comprennes rien.
J'en ai lu beaucoup sur Windows ce dernier mois.
> Plutot que dire que c'est pour des conneries, et si tu donnais des exemples ou c'est inutile ?
WTypes.h
Le wchar_t je vois l'intérêt. Le WCHAR pourquoi pas. Mais les LPCWSTR, etc c'est stupide et ça n'améliore pas la lecture du code (il faut connaitre une tripoté de typedef).
Puis selon http://msdn2.microsoft.com/en-gb/library/aa383751.aspx WCHAR c'est :
Donc Windows ne support que ucs-2. Merci d'en faire la démonstration.
Tu me traites de con qui ne sait pas lire la doc. Je bosse sur Windows en tant que développeur depuis 1 mois seulement. Toi ça fait depuis des années et tu ne sais toujours pas que Windows ne supporte que ucs-2 et pas UTF-8. UTF-8 est une façon de coder usc-4 (unicode) et a 2^32 valeurs. Ça ne rentre pas dans du 16 bits. wchar_t sous Linux est dans son implémentation actuelle du 32 bits. wchar_t n'est pas défini comme étant un int32, mais comme étant un wide caractère. Qu'il occupe 8, 16, 24 ou 32 bits, n'est pas une propriété que le développeur doit utiliser ni savoir (sauf pour débuggeur).
Avec la définition qu'a Windows de wchar_t, ça ne va pas être facile de passer à usc-4...
> Tout comme sous Windows, mais ton probleme c'est que tu n'y connais rien et en parles quand meme.
Très bien, fais ce que tu dis et arrêtes de parler du logiciel libre.
Enfin, je tiens à te signalé que j'ai parlé de l'API de Windows après m'être informé. J'en parlais pour expliquer pourquoi "Linux tient tête à Windows" alors que Windows a facilement 100 fois plus de développeur que Linux.
M'enfin, tu as peut-être une autre explication. Les développeurs Linux seraient 100 plus doués que les développeurs Windows ?
Il y a moins d'un mois, je n'aurai rien dit de l'API de Windows et j'en ai rien dit jusqu'à ce que je lise la doc.
Si j'étais un anti-Windows primaire, je n'aurais pas dit que l'API de Direct3D est bien foutue ni que le noyau de Windows offre toutes les fonctionnalités qu'on attend d'un OS moderne.
De plus, j'ai passé sous silence DirectShow alors que ça va devenir mon "coeur de métier". En un mot : lourdingue. Tellement lourdingue que MS fournit une tripoté de classe pour simplifier le développement. Mais comme ces classes ne répondent pas à mon besoin... ça va être lourdingue.
Mais DirectShow est bien moins pire que l'API de Windows. Son historique l'a rendu lourdingue. M'enfin, il n'y a pas vraiment d'équivalent dans le libre. Sauf gstreamer mais ce n'est pas encore ça ; espérons que ça ne tarde pas.
NB : gstreamer est beaucoup plus récent que DirectShow. Je dis ça avec que tu te foutes de gstreamer.