> D'un cote t'as une bibliotheque de softs plutot petite et principalement serveurs
Mais oui. Sous Fedora (ça doit être la même chose ailleurs mais je les connais moins) c'est plus de 6 Go de source et 8 Go de binaire (Fedora Core + Extras). Tous les logiciels desktop sont aussi en 64 bits (sauf flash, désolé).
Franchement, soit un peu sérieux.
> de l'autre une bibliotheque de softs principalement desktop et enorme
Oui windows à plus de soft. C'est indiscutable. Mais sous Linux c'est 99,9 % qui est dispo en 64 bits et sous Windows c'est ... 50 % (?) voire moins.
> Des softs non-64bits sous Linux il y en a plein d'autres, RealPlayer, ColdFusion, etc...
Tu cites encore du logiciel proprio.
> > 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
Ben autant pour moins, je ne croyait qu'XP était sortit en 2001 (je n'utilisais pas Windows depuis 97/98). Il me reste à me bruler une main...
> C'est jamais inconnu, suffit de faire sizeof(wchar_t) pour le savoir.
Comme sizeof(int) n'est pas inconnu. Mais tu es en train de noyer le poisson. Quand on code, on ne doit pas suposer quelle est la taille d'un int ou alors on est un mauvais codeur qui ne fait que des choses non portable. On ne sait que ça : short >= int >= long && short >= 2 && long >=4 .
Comme la norme C ne dit pas la taille d'un int, la libc ne dit pas la taille d'un wchar_t. Par contre Windows dit qu'elle est la taille d'un wchar_t. Le faisant Windows s'imposer de conserver cette taille.
Pour mon info, comment tu fais pour iswalpha() alors qu'il attend un wchar_t et que celui-ci est de 2 octets sous Windows (selon la définition de Windows) ? Comment tu fais pour passer du 32 bits ?
Sous Linux, c'est n'est pas un problème. Même si Linux stockait wchar_t sur 16 bits, passer iswalpha() en 32 bits (supporter usc-4) n'est pas un problème car la taille de wchar_t n'est pas dans la difinition de wchar_t (comme la taille d'un int n'est pas dans la diffinition d'un int) et donc l'API ne change pas. Pour Windows c'est une autre histoire.
> Oui mais la tu compares l'incomparable.
Ben quand on peut comparer Linux à Windows ? Jamais ?
> Alors qu'on ait 100x plus de developpeurs de cette maniere peut-etre, mais on a aussi bcp plus de softs
+ de softs, donc plus d'expert Windows, plus d'expert qui peuvent contribuer à Windows.
Je parle à un puit sans fond qui fait dans le simplisme quand ça l'arrange.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal [TROP LONG] Réflexions sur le libre. Évalué à 2.
Mais oui. Sous Fedora (ça doit être la même chose ailleurs mais je les connais moins) c'est plus de 6 Go de source et 8 Go de binaire (Fedora Core + Extras). Tous les logiciels desktop sont aussi en 64 bits (sauf flash, désolé).
Franchement, soit un peu sérieux.
> de l'autre une bibliotheque de softs principalement desktop et enorme
Oui windows à plus de soft. C'est indiscutable. Mais sous Linux c'est 99,9 % qui est dispo en 64 bits et sous Windows c'est ... 50 % (?) voire moins.
> Des softs non-64bits sous Linux il y en a plein d'autres, RealPlayer, ColdFusion, etc...
Tu cites encore du logiciel proprio.
> > 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
Ben autant pour moins, je ne croyait qu'XP était sortit en 2001 (je n'utilisais pas Windows depuis 97/98). Il me reste à me bruler une main...
> Je parlais du PID, pas du pthread_t
Finalement, je comprend ton problème.
> Ok, va lire ca alors http://www.microsoft.com/globaldev/handson/dev/winxpintl.msp(...)
Cette doc n'est pas dans le SDK.
> C'est jamais inconnu, suffit de faire sizeof(wchar_t) pour le savoir.
Comme sizeof(int) n'est pas inconnu. Mais tu es en train de noyer le poisson. Quand on code, on ne doit pas suposer quelle est la taille d'un int ou alors on est un mauvais codeur qui ne fait que des choses non portable. On ne sait que ça : short >= int >= long && short >= 2 && long >=4 .
Comme la norme C ne dit pas la taille d'un int, la libc ne dit pas la taille d'un wchar_t. Par contre Windows dit qu'elle est la taille d'un wchar_t. Le faisant Windows s'imposer de conserver cette taille.
Pour mon info, comment tu fais pour iswalpha() alors qu'il attend un wchar_t et que celui-ci est de 2 octets sous Windows (selon la définition de Windows) ? Comment tu fais pour passer du 32 bits ?
Sous Linux, c'est n'est pas un problème. Même si Linux stockait wchar_t sur 16 bits, passer iswalpha() en 32 bits (supporter usc-4) n'est pas un problème car la taille de wchar_t n'est pas dans la difinition de wchar_t (comme la taille d'un int n'est pas dans la diffinition d'un int) et donc l'API ne change pas. Pour Windows c'est une autre histoire.
> Oui mais la tu compares l'incomparable.
Ben quand on peut comparer Linux à Windows ? Jamais ?
> Alors qu'on ait 100x plus de developpeurs de cette maniere peut-etre, mais on a aussi bcp plus de softs
+ de softs, donc plus d'expert Windows, plus d'expert qui peuvent contribuer à Windows.
Je parle à un puit sans fond qui fait dans le simplisme quand ça l'arrange.