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...
D'un cote t'as une bibliotheque de softs plutot petite et principalement serveurs, de l'autre une bibliotheque de softs principalement desktop et enorme, pas tres normal comme comparaison hein.
Des softs non-64bits sous Linux il y en a plein d'autres, RealPlayer, ColdFusion, etc...
Tu remarqueras qu'une app qui existe a la fois sous Linux et Windows et existe en 64bit pour Linux d'habitude existe aussi en 64bit pour Windows
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.
Ben 2007-2001(XP)=6 hein
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 ?
Je parlais du PID, pas du pthread_t
Tu m'as donné un pointeur sur un blog...
Désolé mais je ne considère pas les blogs comme de la doc.
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.
Eh si c'est vrai, tout comme pour la libc c'est 32bit. Comme je te le dis, que wchar_t soit 16bit n'y change rien, une chaine de caracteres "internationale" sur les 2 plateformes, elle aura des caracteres qui n'entrent pas dans un wchar_t , resultat, peu importe qu'il soit trop petit de 2,3 ou 4 bytes.
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).
C'est jamais inconnu, suffit de faire sizeof(wchar_t) pour le savoir.
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).
Oui, mais ca ne resoud pas le probleme, si tu veux acceder a un caractere dans une chaine Unicode, tu peux pas simplement faire bob[3], ni sur Linux ni sur Windows. Parce que ta chaine, c'est un array de wchar_t(qu'il soit 16 ou 32bit n'y change rien), et que les caracteres de la chaines n'ont peut-etre pas tous la meme taille.
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.
Oui mais la tu compares l'incomparable. Linux n'a rien d'equivalent a Photoshop et Illustrator par exemple. Alors qu'on ait 100x plus de developpeurs de cette maniere peut-etre, mais on a aussi bcp plus de softs
[^] # Re: Re:
Posté par pasBill pasGates . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 0.
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...
D'un cote t'as une bibliotheque de softs plutot petite et principalement serveurs, de l'autre une bibliotheque de softs principalement desktop et enorme, pas tres normal comme comparaison hein.
Des softs non-64bits sous Linux il y en a plein d'autres, RealPlayer, ColdFusion, etc...
Tu remarqueras qu'une app qui existe a la fois sous Linux et Windows et existe en 64bit pour Linux d'habitude existe aussi en 64bit pour Windows
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.
Ben 2007-2001(XP)=6 hein
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 ?
Je parlais du PID, pas du pthread_t
Tu m'as donné un pointeur sur un blog...
Désolé mais je ne considère pas les blogs comme de la doc.
Ok, va lire ca alors http://www.microsoft.com/globaldev/handson/dev/winxpintl.msp(...)
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.
Eh si c'est vrai, tout comme pour la libc c'est 32bit. Comme je te le dis, que wchar_t soit 16bit n'y change rien, une chaine de caracteres "internationale" sur les 2 plateformes, elle aura des caracteres qui n'entrent pas dans un wchar_t , resultat, peu importe qu'il soit trop petit de 2,3 ou 4 bytes.
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).
C'est jamais inconnu, suffit de faire sizeof(wchar_t) pour le savoir.
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).
Oui, mais ca ne resoud pas le probleme, si tu veux acceder a un caractere dans une chaine Unicode, tu peux pas simplement faire bob[3], ni sur Linux ni sur Windows. Parce que ta chaine, c'est un array de wchar_t(qu'il soit 16 ou 32bit n'y change rien), et que les caracteres de la chaines n'ont peut-etre pas tous la meme taille.
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.
Oui mais la tu compares l'incomparable. Linux n'a rien d'equivalent a Photoshop et Illustrator par exemple. Alors qu'on ait 100x plus de developpeurs de cette maniere peut-etre, mais on a aussi bcp plus de softs