Fichtre, gros problème. Il manque un jeu et deux trucs proprio dont un existe en version libre et marche en 64 bits (xpdf ou evince et probablement d'autres).
NB : je n'ai jamais installé Quake ou Acrobat Reader. Il m'arrive d'avoir Flash (et je ne le garde pas de façon permanente).
Bref, 99,9 % tourne en 64 bits sous Linux.
Tu peux me faire la liste de ce qui ne marche pas sous Windows en 64 bits ?
Ça doit être long...
> La plupart des softs "grand public" ne sont pas dispo en 64bit sur Linux
Et c'est quoi les softs "grand public" qui n'existe pas ?
Il y a Flash et Acrobat Reader. C'est tout. Deux trucs proprio.
> Parce qu'OpenOffice 64bit sur Linux n'est pas encore utilisable
Il est utilisable et utilisé. D'ailleurs RHEL 5 aura openoffice en 64 bits. Red Hat est devenu suicidaire selon toi ?
> bref, ils en sont au meme point.
Non. Un est dispo (pardon pour début mars avec support et tout) et l'autre non. Et n'oublies pas de prendre en compte les moyens de MS ainsi que son volume de vente qui sont sans commune mesure avec Red Hat...
> > > ca fait 6 ans...
> > 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.
> Moi je te proposes d'aller lire
Ben "ça fait 6 ans..." c'est du pipo. Et ça j'en étais sûr au point d'en mettre ma main au feu.
> Ca ne date en fait que depuis 2002-2003
???
Alors ça m'étonnerai dans les grandes largeurs. Si tous les thread d'un même processus avait le même pthread_t, ça ne marcherait tout simplement pas. Comment tu fais marcher par exemple pthread_join(pthread_t, ...) si tu ne peux pas lui dire quel est le thread que tu attends ?
Ou alors tu parles d'un autre problème. Mais de tout temps chaque thread à son identifiant. C'est obligatoire.
Le plus gros problème de LinuxThread était les signaux. Mais ça avait aussi des avantages. Avec NPTL tu ne peux pas envoyer un signal à un thread spécifiquement (sauf débug et peut-être SIGUSR1 et SIGUSR2). Pour NPTL, la norme Posix a été suivie (ce qui n'a pas été du gout de tout le monde).
> tu utilises LPWSTR quand tu veux une chaine de caracteres, et tu utilises WCHAR* quand tu veux un pointeur sur un caractere.
Je dois reconnaitre que cette subtilité m'a échappé. Quand j'ai commencé à lire du code windows, j'ai pesté contre ces trucs...
> Ben moi je te propose de relire la doc
OK, j'ai lu. Windows XP support UTF-16. Linux c'est généralement UTF-8 pour le stockage dans les fichiers et ucs-4. UTF-8 et UTF-16 n'étant qu'une façon de coder Unicode. Notons qu'à une époque on disant Unicode même pour "seulement" usc-2. Et notes bien que le pointeur sur msdn que tu as donné dit : "Pointer to a null-terminated string of 16-bit Unicode characters".
Ça ne parle pas de UTF-16. UTF-16 n'est pas un "16-bit Unicode characters" (pour info, UTF-8 n'est pas un "8-bit Unicode characters"). UTF-16 peut-être codé de 2 à 6 octets. UTF-8 c'est de 1 à 6.
> Ben moi je te propose de relire la doc
Tu m'as donné un pointeur sur un blog...
Désolé mais je ne considère pas les blogs comme de la doc.
> et te rendre compte que le fait que WCHAR est 16bit n'y change rien
Car c'est du UTF-16 pour XP. Comme on peut utiliser un "char *" pour du UTF-8.
Mais la définition de wchar_t de Windows ne permet pas de passer à usc-4. Windows 2000 étant usc-2, j'ai pensé au vu son API qu'il aurait des problèmes pour passer à usc-4. Ce qui n'est pas faux, mais ce n'est pas un problème puisqu'il y a UTF-16. Désolé, je n'avais pas pensé à UTF-16.
> De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine.
Non. Sous Linux le développeur n'est pas sensé connaitre la taille d'un wchar_t. En interne, c'est effectivement codé sur 32 bits (usc-4) sur mon système. Mais ça serait du utf-8, du utf-16, du usc-2, du char, que ça ne changerait rien. La doc de la libc dit que wchar_t est un "wide character" sans préciser si c'est du 8, 16, 32 ou du 48 bits.
La doc de Windows dit qu'un wchar_t est un wide character codé sur 16 bits. Si c'est du UTF-16 alors c'est faux.
La définition de wchar_t dans Linux n'est pas dans /usr/include, mais au niveau du compilateur (par exemple : /usr/lib/gcc/i386-redhat-linux/4.1.1/include/ ).
Avec les définitions de la libc, on peut avoir un système embarqué qui utilise du ansi ou du usc-2 pour économiser de la mémoire sans changer les programmes ni la définition de wchar_t (celle que doit connaitre le développeur et non la définition au niveau du compilateur). Par contre, il faut recompiler.
Pour info, la définition de wchar_t de libc est celle de la ISO C90.
> De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine. Raison pour laquelle il est des APIs specifiques pour ca sur les 2 plateformes.
Pas vraiment. Ce n'est pas que la taille soit variable ou différente le problème. Le problème est que par définition sizeof(char) = 1. Alors que par définition sizeof(wchar_t) = inconnu (du moins avec ISO C90 c'est plateforme dépendant comme int par exemple).
De plus tu devrais savoir que Windows offre (ou offrait) des macros pour avoir le même source que l'application soit en ansi ou Unicode :-) (type TCHAR et TEXT et passe de ansi à ucs-2).
> On a 100x plus de developpeurs que Linux+KDE+... reunis ? Permets moi d'en douter.
Microsoft seul, ça prête effectivement à discution. Mais Windows et notamment son noyau n'est pas développé uniquement par MS. Les constructeurs de hardware y participe activement (ce n'est en rien un reproche). Par exemple on sent très bien l'influence des fabriquants de carte graphique dans Direct3D (et ce n'est en rien un reproche).
De plus, il faut s'entendre sur le terme développeur. Pour Linux, les derniers chiffres était de 100 développeurs à plein temps qui font 99 % du code et 1000 contributeurs (proposition, rapport de bug, bench, etc) qui ne sont pas à plein temps. Et c'est 100 développeurs à plein temps qui font aussi les drivers. Je ne pense pas que MS à 1000 développeurs sur le noyau de Windows. Par contre Windows a infiniment plus de développeur des constructeurs de hardware (qui font notamment les drivers) sur le noyau de Windows que sur le noyau Linux. C'est indiscutable. Notons aussi que le noyau Linux est le projet où il y a le plus de développeur à plein temps, et de loins. Linux (le noyau) est le projet le mieux loti.
> l'OS lui-meme ?
OS = noyau (bas niveau)
Ben si tu intégres des drivers, probablement que Windows a 100 fois plus de développeurs que Linux.
Mais compares avec Gnome ou KDE.
Quand je disais qu'il y avait 100 fois plus de développeurs sur Windows que sur Linux, j'entendais tous les développeurs (adobe, etc). Pas seulement ceux de MS.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
Ça ne marche pas terrible en vente JBoss, de l'aveu même de Red Hat. M'enfin, je pense que ça va décoller.
> De ce que j'en ai lu, c'est pas tres utilisable, notamment vis a vis de problemes avec Java sur plateforme 64bit.
Ben sous Fedora, le java utilisé en gcj. Donc pas de problème.
> Ah oui ? T'as Quake 64bits ? Flash 64bits ? Acrobat Reader 64bits ? ...
Fichtre, gros problème. Il manque un jeu et deux trucs proprio dont un existe en version libre et marche en 64 bits (xpdf ou evince et probablement d'autres).
NB : je n'ai jamais installé Quake ou Acrobat Reader. Il m'arrive d'avoir Flash (et je ne le garde pas de façon permanente).
Bref, 99,9 % tourne en 64 bits sous Linux.
Tu peux me faire la liste de ce qui ne marche pas sous Windows en 64 bits ?
Ça doit être long...
> La plupart des softs "grand public" ne sont pas dispo en 64bit sur Linux
Et c'est quoi les softs "grand public" qui n'existe pas ?
Il y a Flash et Acrobat Reader. C'est tout. Deux trucs proprio.
> Parce qu'OpenOffice 64bit sur Linux n'est pas encore utilisable
Il est utilisable et utilisé. D'ailleurs RHEL 5 aura openoffice en 64 bits. Red Hat est devenu suicidaire selon toi ?
> bref, ils en sont au meme point.
Non. Un est dispo (pardon pour début mars avec support et tout) et l'autre non. Et n'oublies pas de prendre en compte les moyens de MS ainsi que son volume de vente qui sont sans commune mesure avec Red Hat...
> > > ca fait 6 ans...
> > 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.
> Moi je te proposes d'aller lire
Ben "ça fait 6 ans..." c'est du pipo. Et ça j'en étais sûr au point d'en mettre ma main au feu.
> Ca ne date en fait que depuis 2002-2003
???
Alors ça m'étonnerai dans les grandes largeurs. Si tous les thread d'un même processus avait le même pthread_t, ça ne marcherait tout simplement pas. Comment tu fais marcher par exemple pthread_join(pthread_t, ...) si tu ne peux pas lui dire quel est le thread que tu attends ?
Ou alors tu parles d'un autre problème. Mais de tout temps chaque thread à son identifiant. C'est obligatoire.
Le plus gros problème de LinuxThread était les signaux. Mais ça avait aussi des avantages. Avec NPTL tu ne peux pas envoyer un signal à un thread spécifiquement (sauf débug et peut-être SIGUSR1 et SIGUSR2). Pour NPTL, la norme Posix a été suivie (ce qui n'a pas été du gout de tout le monde).
> tu utilises LPWSTR quand tu veux une chaine de caracteres, et tu utilises WCHAR* quand tu veux un pointeur sur un caractere.
Je dois reconnaitre que cette subtilité m'a échappé. Quand j'ai commencé à lire du code windows, j'ai pesté contre ces trucs...
> Ben moi je te propose de relire la doc
OK, j'ai lu. Windows XP support UTF-16. Linux c'est généralement UTF-8 pour le stockage dans les fichiers et ucs-4. UTF-8 et UTF-16 n'étant qu'une façon de coder Unicode. Notons qu'à une époque on disant Unicode même pour "seulement" usc-2. Et notes bien que le pointeur sur msdn que tu as donné dit : "Pointer to a null-terminated string of 16-bit Unicode characters".
Ça ne parle pas de UTF-16. UTF-16 n'est pas un "16-bit Unicode characters" (pour info, UTF-8 n'est pas un "8-bit Unicode characters"). UTF-16 peut-être codé de 2 à 6 octets. UTF-8 c'est de 1 à 6.
> Ben moi je te propose de relire la doc
Tu m'as donné un pointeur sur un blog...
Désolé mais je ne considère pas les blogs comme de la doc.
> et te rendre compte que le fait que WCHAR est 16bit n'y change rien
Car c'est du UTF-16 pour XP. Comme on peut utiliser un "char *" pour du UTF-8.
Mais la définition de wchar_t de Windows ne permet pas de passer à usc-4. Windows 2000 étant usc-2, j'ai pensé au vu son API qu'il aurait des problèmes pour passer à usc-4. Ce qui n'est pas faux, mais ce n'est pas un problème puisqu'il y a UTF-16. Désolé, je n'avais pas pensé à UTF-16.
> De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine.
Non. Sous Linux le développeur n'est pas sensé connaitre la taille d'un wchar_t. En interne, c'est effectivement codé sur 32 bits (usc-4) sur mon système. Mais ça serait du utf-8, du utf-16, du usc-2, du char, que ça ne changerait rien. La doc de la libc dit que wchar_t est un "wide character" sans préciser si c'est du 8, 16, 32 ou du 48 bits.
La doc de Windows dit qu'un wchar_t est un wide character codé sur 16 bits. Si c'est du UTF-16 alors c'est faux.
La définition de wchar_t dans Linux n'est pas dans /usr/include, mais au niveau du compilateur (par exemple : /usr/lib/gcc/i386-redhat-linux/4.1.1/include/ ).
Avec les définitions de la libc, on peut avoir un système embarqué qui utilise du ansi ou du usc-2 pour économiser de la mémoire sans changer les programmes ni la définition de wchar_t (celle que doit connaitre le développeur et non la définition au niveau du compilateur). Par contre, il faut recompiler.
Pour info, la définition de wchar_t de libc est celle de la ISO C90.
> De meme que sous Linux que wchar_t soit 16,32 ou autre, si plusieurs caracteres peuvent avoir des tailles differentes, t'es dans la mouise quand tu parses la chaine. Raison pour laquelle il est des APIs specifiques pour ca sur les 2 plateformes.
Pas vraiment. Ce n'est pas que la taille soit variable ou différente le problème. Le problème est que par définition sizeof(char) = 1. Alors que par définition sizeof(wchar_t) = inconnu (du moins avec ISO C90 c'est plateforme dépendant comme int par exemple).
De plus tu devrais savoir que Windows offre (ou offrait) des macros pour avoir le même source que l'application soit en ansi ou Unicode :-) (type TCHAR et TEXT et passe de ansi à ucs-2).
> On a 100x plus de developpeurs que Linux+KDE+... reunis ? Permets moi d'en douter.
Microsoft seul, ça prête effectivement à discution. Mais Windows et notamment son noyau n'est pas développé uniquement par MS. Les constructeurs de hardware y participe activement (ce n'est en rien un reproche). Par exemple on sent très bien l'influence des fabriquants de carte graphique dans Direct3D (et ce n'est en rien un reproche).
De plus, il faut s'entendre sur le terme développeur. Pour Linux, les derniers chiffres était de 100 développeurs à plein temps qui font 99 % du code et 1000 contributeurs (proposition, rapport de bug, bench, etc) qui ne sont pas à plein temps. Et c'est 100 développeurs à plein temps qui font aussi les drivers. Je ne pense pas que MS à 1000 développeurs sur le noyau de Windows. Par contre Windows a infiniment plus de développeur des constructeurs de hardware (qui font notamment les drivers) sur le noyau de Windows que sur le noyau Linux. C'est indiscutable. Notons aussi que le noyau Linux est le projet où il y a le plus de développeur à plein temps, et de loins. Linux (le noyau) est le projet le mieux loti.
> l'OS lui-meme ?
OS = noyau (bas niveau)
Ben si tu intégres des drivers, probablement que Windows a 100 fois plus de développeurs que Linux.
Mais compares avec Gnome ou KDE.
Quand je disais qu'il y avait 100 fois plus de développeurs sur Windows que sur Linux, j'entendais tous les développeurs (adobe, etc). Pas seulement ceux de MS.