pasBill pasGates a écrit 16349 commentaires

Eh j'ai une excuse hein, c'est 3h du matin ici :+)

Ah oui c'est vrai j'oubliais Windows mobile 7 c'est la version pour telephone de windows 7... Au passage je voudrais vous feliciter pour cette magnifique reussite technologique!

a) Tu m'expliqueras le rapport
b) C'est une reussite technologique, le fait que tu ne saches pas evaluer un OS (ou que tu sois de mauvaise foi, a mon avis c'est les 2) ne prejuge pas de la qualite de l'OS

Si bien sûr, ça a à voir avec ça. Si c'était facile, ça serait fait, même pour trois gus. Ce n'est certes pas impossible, mais ce n'est pas trivial.

C'est facile au niveau du code, simplement ca coute au niveau du test, packaging et formation du support, tout en ne ramenant rien a l'echelle de MS.

Avec du logiciel libre, on a un portage pour les 3 gus de MIPS, un pour les 3 gus avec de l'Alpha, un pour les 3 gus en ARM, etc.

Absolument, pour un systeme utilise par 3 gus, il est clair et net que Linux est plus approprie.

Le truc est pas que ces gus sont pas serieux, mais faut revenir un peu sur terre, MS est une societe commerciale, une marche ou ils ne peuvent pas vendre au moins un million de licences, ca ne vaut rien pour eux.
C'est une question de choix c'est tout, il y a des marches que MS choisit de ne pas poursuivre pour raisons commerciales, ca veut pas dire que les gens de ce marche sont inutiles, simplement qu'il n'y en a pas beaucoup.

Ah ben merde alors, je me suis fait eu comme on dit :+) A force de baigner dans l'anglais je le vois meme quand c'est du francais...

Je monitores
Tu monitores
Il monitore
Nous monitorons
Vous monitorez
Ils monitorent

Ah oui, ca a l'air d'etre un verbe francais

OUHAOU vous avez reussi a faire plus que 2 archis (qui sont tres similaire x86 et xx64) c'est impressionnant dis donc. Vous etes vraiment tres tres fort. Bon Ok lorsque l'on voir le nombre d'architecture supporte par Linux/xBSD vous etes des nains...

Juste pour rire:

http://en.wikipedia.org/wiki/List_of_Linux_supported_archite(...)

Une vingtaine de famille (tu me permet d'omettre les sous categories je ne veux pas trop vous enfoncer)

Oh mais ca qu'est ce que je m'en fous tu sais...

Windows a ete prouve portable, c'est un fait etabli (MIPS, i860, PPC, x86, amd64, IA64, Alpha)

Ensuite qu'on evite de sortir l'OS sur une archi donnee pour 3 gugus sur leur PPC ou autre, tout le monde sauf toi sait que cela n'a rien a voir avec la difficulte technique de le faire et tout a voir avec le fait que cela ne rapporterait quasiment rien.

Ton deuxieme point je ne vais pas me fatiguer a y repondre car tu n'as soit pas compris le sujet de la nouvelle soit tu ne sais pas lire et vu le nombre de hors sujet que tu fais l'une ou l'autre des possibilite sont valables.

Hors sujet ? Ben soit c'est hors-sujet et ton post l'etait aussi, soit il ne l'est pas, vu qu'il est directement lie a ton post...

Windows suporte a peine 2 architecture et uniquement pour les pc.

x86, amd64, ia64

1+1+1 = 3 mon cher Albert_

Naturellement le materiel present dans un telephone ou dans un super ordi est "tres legerement" different de ce que l'on peut trouver dans un pc, dernier point essaye donc d'utiliser un matos un peu ancien avec windows cela peut etre assez amusant (je connais des boites qui ont encore des pc sous windows 98 a cause de cela...), je sens venir le "ah mais linux avec le nouveau matos..." tout d'abord cela n'est presque plus vrai et de plus la proportion de nouveau matos par rapport a l'ancien fait que cet argument n'est plus du tout valable dans l'optique du nombre de matos utilisable a l'installation (c'est a dire sans rajout de drivers fait par une boite externe au projet).

Hahaha sans rajout de drivers fait par une boite externe au projet , elle est marrante celle-la, elle sort d'ou cette regle ?

On regarde la realite, dans le monde reel, 90% des gens recoivent l'OS avec le PC, partant de la, que les drivers viennent avec le projet ou pas on s'en fout un peu hein.
Faut pas demander a MS de suivre un mode absolument inutile au vu du marche, ca n'a aucun sens.

Tu mélanges deux situations différentes. Ton soft gère 32768 éléments ou MAX_INT éléments ? Ce n’est pas la même chose.
Cas où ton soft gère 32768 éléments : ben tu fais pas MAX_INT, mais #define MAXELEMS
Cas où ton soft gère MAX_INT : tu aimerais bien que ton algo scale avec les capacités de ta machine, donc il me semble normal que MAX_INT change selon l’architecture, et tant pis si ça plante pour une machine pas assez puissante.

Sans blague ? Merci je connais, mais moi je regardes pas la theorie de ce que t'es sense faire et que 1% des gens font, mais ce que l'enorme majorite des gens font, parce qu'au final si le langage est tellement alambique que personne ne sait, c'est comme si le langage ne le faisait pas.

La realite est que l'enorme majorite des developpeurs ne sait meme pas qu'un int peut avoir une taille differente d'un systeme a l'autre. Cette realite fait que tous ces softs qu'ils ont ecrits ne sont probablement pas multiplateforme.

La realite est qu'un soft ecrit par un neuneu en Java/Python/autre lui par contre il a toutes les chances de tourner sur plein de plateformes differentes.

Mais il est incapable de profiter de la puissance de ce nouvel OS flambant neuf, et au final, si tu veux en profiter, tu es obligé de recoder ton programme en changeant des int par des long.

Tout a fait, maintenant ce que Java fera c'est d'ajouter a sa spec de nouvelles methodes supportant une taille d'entier superieure pour les tableaux et autres, et ca resoudra le probleme, sans rien remettre en cause.

Ton soft gere des elements(peu importe quoi), et tu utilises un ID pour les differencier, qui est un int.

Combien d'elements maximum peut-il gerer ? MAX_INT ...

Quel est le moyen le plus rapide d'acceder a ces elements ? Une table contenant ces elements, une table de taille ... MAX_INT

--> malloc(MAX_INT) ou MAX_INT*(ce que tu veux)

C'est peut-etre pas optimal, mais c'est pas stupide non plus hein quand la taille au final est bien plus petite que la RAM dispo sur les machines standards.

Ca a tout son sens quand ton soft gere 32768 (ou 65536 avec MAX_UINT) elements, le probleme etant quand tu 4 ans plus tard un nouveau systeme sort, et il a des int sur 32bits, et boum, tu te retrouves avec ta table qui fait 2 milliards d'entrees.

Et devines quoi, aujourd'hui tout le monde a un systeme avec CPU 64bits, et des int 32bits, d'ici quelque annees tout le monde aura 128Go de RAM en standard sur son iPad/desktop/frigo et on verra regulierement des tables de 2^32 elements, tu sais, MAX_UINT, ou si ce n'est l'allocation elle-meme, une reservation d'espace d'addressage continu de cette taille a remplir au fur et a mesure des besoins(ca se fait probablement deja aujourd'hui dans des bases de donnees).

Et dans quelque annees, un nouvel OS(ou ancien et modernise) bien joli va sortir tout 64bit et tout, avec des int de 64bit vu que tout le monde a 128Go de RAM et qu'un int 32bit c'est devenu ringard, et boum, la meme merde.

Quand t'as des types de taille statique, ce genre de merde n'arrive pas, si tu passes ton soft sur le nouvel OS, ton code il marche, point.

C'est bien, tu viens de nous dire nois sur blanc que tu avais du code specifique a la machine en C, qui donc n'etait pas portable.

Merci de confirmer ce que je dis depuis le debut.

La prochaine fois, reflechis avant d'ecrire.

Ce que pBpG dit, c’est que sur une machine où l’entier est à 16 bits mais où l’adressage est sur 20 bits — à l’aide de mécanismes comme la segmentation —, malloc(INT_MAX), c’est 16 fois moins (en fait 32, il a oublié que INT_MAX était signé) que l’espace adressable, donc que ça plantera pas — au contraire de nos machines où taille de l’entier = capacités d’adressage.
C’est tout.
Le seul exemple qu’il a donné, c’est « sur 16 bits on peut utiliser malloc(INT_MAX) pour allouer 64ko, et ça plante sur 32 bits », ce que j’appelle difficilement un exemple probant.

Vraiment ? Pourtant c'est un exemple reel, qui demontre que non, C n'est pas un langage multi-plateforme du fait de la non definition de ses types de base parmis d'autres faiblesses au niveau support multiplateformes.

Tu iras des lors expliquer a ce code qu'il n'a jamais existe, et qu'il n'avait pas non plus lieu d'exister.

J'ai du bol, je serais plus la en 2015

Vu ta reponse, je suis pas tres chaud pour recommencer

...pour faire profiter la population de votre travail sans contre-partie.

Je savais bien que tu n'etais pas serieux !

s/windows 7/Vista

Fait leur manger un poisson avarie, ils comprendront (si ils survivent).

Ben non, le sterilisateur est optionel et est la uniquement pour ceux qui oublient tout le temps de fermer la porte du frigo. Pour le bac a legumes, on sait tous que les legumes c'est bon pour la sante et tres peu de gens veulent une clayette !

Et apres on s'etonne que Linux donne froid dans le dos a Ballmer...

Si tu commandes un yaourt, il te dira qu'il doit d'abord commander 3 litres de lait, 300g de sucre et une barquette de fraise.

Et si tu essaies ensuite de commander un yaourt a la peche, il te dira qu'il y a un conflit entre la barquette de peche et la barquette de fraise

Marrant, parce que de tous les commentaires de cette depeche, il n'y a qu'un commentaire qui contient le mot idiot, et c'est le tien.

Et ca en dit long sur toi et ton apport a ce fil de discussion et ce site en general.

Merci de confirmer que tu n'as rien d'intelligent a dire

Tu vois pas l'utilite de creer un tableau de 64Ko en C sur un systeme qui a 1Mo de RAM et qui peut en addresser 1Mo voire 16 ? Moi oui

Le probleme est quand ce meme code se met a allouer 2Go sur un systeme qui ne peut en allouer que 4 au grand maximum et qui en realite n'en a que 3 ou 2 de disponible en allocation pour un processus, sans compter ce que le systeme utilise et qui reduit et fragmente la quantite disponible.

--> Tu passes d'une allocation qui est 16 ou 256x plus petite que l'espace d'addressage, a une qui est 2x plus petite que l'espace d'addressage, et tu passes d'une tres tres grande chance d'avoir une allocation reussie, a quasiment aucune.

Tu le vois toujours pas le probleme ?

La difference avec les autres langages, c'est qu'avec eux, ta taille d'allocation ne change pas, elle est constante quel que soit le systeme, des surprises du genre tu n'en as pas, si ton code tourne sur un 80x286 avec 16Mo de RAM, tu sais qu'il tournera sur un P4 avec 2Go de RAM, avec le C ce n'est pas le cas.

T'as un truc intelligent a dire au passage ?

Parce qu'un malloc(INT_MAX) sur certains systemes a tout son sens, et sur d'autres absolument aucun, alors qu'un byte[] gros = new byte[java.Integer.MAX_INT] lui a _toujours le meme sens_ ou que ce soit. Et c'est bien ca qui fout la merde avec le C, le meme code se comporte differement d'un systeme a l'autre.

Mais bon, c'est tellement plus simple de sortir des inepties plutot que regarder la verite en face ...

Je te l'ai donnee plus haut la reponse, c'est cette meme reponse qui t'explique pourquoi un malloc(INT_MAX) est tout a fait acceptable sur un CPU tel que le 80286 et que le _meme_ code explose sur un x86 32bit

Tout a fait, le probleme etant de trouver une librairie qui
a) est disponible sur toutes les plateformes que tu veux
b) est utilisable du point de vue de la licence

Avec le framework du langage, c'est simple la question ne se pose pas.

Avec C, vu qu'il n'y a justement pas de framework, ben faut bien chercher et esperer avoir de la chance.