30

vince (./29) :
Et sincèrement, je ne suis pas de ton avis, je pense que c'est extrêmement débile de coder en utilisant des apis spécifiques 16, 32 ou 64

Ah mais rendre une appli compatible 64 bits ne signifie pas écrire du code spécifique, mais comme tu dis du code identique, compilable pour chaque archi et isofonctionnel.
Et c'est ça le boulot que beaucoup de devs ont du faire pour rendre leurs apps compatible 64 bits : adapter leur programme à une taille 16/32/64 inconnue à l'avance, mais pas écriture du code spécial pour une archi ou une autre.

31

ouais et c'est là où c'est mieux quand l'os propose des apis portables et pas spécifiques...
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

32

Folco (./26) :
ecoute, j'ai jamais dit qu'il n'y avait aucun souci depuis 7 ans. sick
Non mais tu sous entend que tout fonctionne très bien depuis longtemps. C'est ça mon seul problème… Donc pour la peine continuons:
Simplement qu'aujourd'hui, tu peux avoir l'intégralité de ton install en 64 bits, sous Windows c'est pas possible. Point barre. Vient pas inventer autre chose.
Bien sur que si. Comme j'ai déjà du le dire (mais c'est pas grave, au pire Godzil l'a fait), tout Windows 7 est 64 bits (y compris internet explorer)… ça s'arrête là. Si tu veux trier les logiciels par leur support 64 bits tu peux le faire, et tu auras certains choix à faire (débiles) mais je ne pense pas que ça soit vraiment pénalisant si tu cherchais vraiment à avoir du 64 bits à tout prix. -_-
Après tout, de nos jour, il n'y a plus besoin de grand chose en dehors d'un navigateur Web (fourni par Windows).
(D'ailleurs, de plus en plus d'applications Windows son codées en .NET, et le runtime .NET est 100% compatible 64 bits wink)
En plus, "ajouter des fonctionnalités en sachant que ton apps ne sera plus compatible un de ces 4 (drop du 32 bits par Win64), ou modifier ton code pour ne plus jamais avoir de souci 32/64 bits, c'est un choix technique, qui se discute
Je suis entièrement d'accord, mais c'est un choix que tu n'as pas sous Linux. Evidemment, si tu démarres un nouveau projet et que tu choisis une architecture obsolète c'est complètement con. Mais si tu en es à la version 2.3 de ton application et que tu as une liste de fonctionnalités conséquente à implémenter tu vas faire quoi ? Rallonger la liste un peu plus avec le 64 bits au risque de délayer ton appli d'un ou plusieurs mois ? Passer au 64 bits d'abord et laisser toute les fonctionnalités manquantes pour la version suivante ? Dans tous les cas tu vas perdre énormément de temps. Et dans le cas où ton application compile directement sans aucun problème, ce qui *devrait* normalement toujours être le cas, tu peux juste proposer une version test 64 bits en parallèle en espérant qu'elle ne souffre d'aucun bug grave, mais tes clients sérieux ne voudront jamais utiliser une application beta si il y a possibilité d'avoir une version stable (32 bits) équivalente.
il n'y en a pas un bien (ben oué, c'est Windows donc forcément génial) et un à chier (ben oué, Linux quoi).
Tu confonds tout:
Avec Windows, tu as le choix de migrer ou non ton application en 64 bits, car tu distribues des binaires, et les DLL sont rigoureusement compatible entre 32 et 64 bits, il n'y aura pas de problème de version débile. Ton application 32 bits sortie il y a 3 ans et codée parfaitement (j'idéalise clairement mais bon…) va marcher au poil sans avoir besoin de la recompiler, ce qui tombe bien car tu as abandonné le projet depuis. (Ou perdu le code source, c'est au choix)
Avec Linux tu n'as pas ce choix, car tu ne peux pas distribuer de binaires. (Oui, tu *peux* sur le principe, mais la version des librairies doit être rigoureusement la même, en 32 bits et en 64 bits, ce qui est impossible dans un monde ou une centaine de distributions Linux se battaillent) Résultat tu balances des sources, et dès que la possibilité se présentera, ben on remplacera ton boulot par celui d'un autre.
Donc oui, dans ce cas précis, la solution Microsoft est universellement meilleure, car préserve une rétro-compatibilité. (Ça peut être utile de casser la compatibilité entre la version n et n+1 (ce qui se produit souvent) mais entre la version n 32 bits et n 64 bits c'est franchement moyen…)
Je suis en plus partisan de la seconde solution, question de propreté.
Je n'aime pas non plus les applications 32 bits, « question de propreté ». Malgré cela, tu devrais essayer de comprendre les motivations d'une personne qui pourrait ne pas vouloir migrer en 64 bits, et comprendre en quoi cela peut poser un réel problème dans le monde réel. (Dans le monde réel on va installer un Linux 32 bits au lieu d'un 64 bits afin de bien garder la compatibilité avec les applications 32 bits…)
Comme certaine personne, tu devrais te dire que parfois, tes choix et idées ne sont pas les meilleures et les seules, et que si certains font d'autres choix, ils ont peut-être des bonnes raisons auxquelles même toi n'a pas pensé. Si si.
C'est qui qui est venu troller sur Linux qui est tout en 64 bits sauf Wine (ce qui n'est normalement plus le cas) dans un sujet qui parle à la base de Windows ?
(Et si tu es si malin, donne les donc ces raisons auxquelles je n'ai pas pensé. Je n'ai jamais été contre apprendre de nouveaux truc…)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

33

GoldenCrystal (./32) :
Non mais tu sous entend que

Donc en clair, je l'ai pas dit.

Et même plus, je ne le pensais pas (ben oué, j'ai même expérimenté le contraire (== les difficultés du 64 bits qq années sous nux), je suis au courant vois-tu tongue)
GoldenCrystal (./32) :
C'est ça mon seul problème

Et donc tu me tombes dessus pour un truc qui sort tout droit de ton immagination. smile
GoldenCrystal (./32) :
Rallonger la liste un peu plus avec le 64 bits au risque de délayer ton appli d'un ou plusieurs mois ? Passer au 64 bits d'abord et laisser toute les fonctionnalités manquantes pour la version suivante ? Dans tous les cas tu vas perdre énormément de temps.

"Passer" au 64b, c'est dur uniquement pour les porcs, pas pour un programme codé correctement. Et encore, ça ne jouera a priori que là où l'arithmétique des pointeurs a été utilisée avec les pieds.
Un (petit) programme comme A68k n'a nécessité qu'un cast pour devenir multi-archi, j'appelle pas ça "énormément de temps". smile

34

Ben ouais, mais affronte la réalité, et accepte le fait que les 3/4 des programmes que tu utilises (même parmi les « excellents ») ont été codés par des porcs (pas nécessairement intégralement, hein). C'est pas glorieux (et j'ai certainement exagéré les proportions, oui) mais c'est comme ça.

Et:
Folco (./33) :
Et donc tu me tombes dessus pour un truc qui sort tout droit de ton immagination. smile
Ça ne ressemble pas à mon imagination:
Folco (./24) :
sous Linux, ça fait longtemps que c'est mature et bien au point
(Tiens c'est marrant, 23 et 32 cheeky)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

35

Folco (./33) :
GoldenCrystal (./32) :
Non mais tu sous entend que

Donc en clair, je l'ai pas dit.

Et même plus, je ne le pensais pas (ben oué, j'ai même expérimenté le contraire (== les difficultés du 64 bits qq années sous nux), je suis au courant vois-tu tongue)
GoldenCrystal (./32) :
C'est ça mon seul problème

Et donc tu me tombes dessus pour un truc qui sort tout droit de ton immagination. smile
GoldenCrystal (./32) :
Rallonger la liste un peu plus avec le 64 bits au risque de délayer ton appli d'un ou plusieurs mois ? Passer au 64 bits d'abord et laisser toute les fonctionnalités manquantes pour la version suivante ? Dans tous les cas tu vas perdre énormément de temps.

"Passer" au 64b, c'est dur uniquement pour les porcs, pas pour un programme codé correctement. Et encore, ça ne jouera a priori que là où l'arithmétique des pointeurs a été utilisée avec les pieds.
Un (petit) programme comme A68k n'a nécessité qu'un cast pour devenir multi-archi, j'appelle pas ça "énormément de temps". smile

Pas besoin de coder comme un "porcs" pour avoir du code non compatible...

hq2x par exemple n'est PAS compatible 64bit telque, et pourtant il n'es pas si mal codé, mais des que tu tape sur des structures stoqué sur le disque '(par exemple) tu as vite des soucis.
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

36

Godzil (./35) :
des que tu tape sur des structures stoqué sur le disque '(par exemple) tu as vite des soucis.
Ben justement, c'est un signe que c'est pas codé proprement, ça cheeky
(mais c'est vrai que le C est un langage pourri pour faire du code portable, ça fait longtemps que je le pense)
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

37

GoldenCrystal (./34) :
sous Linux, ça fait longtemps que c'est mature et bien au point

Oué, "longtemps" est exagéré en effet, quelques petites années quand même, mais pas depuis 7 ans c'est certains.
Enfin, aujourd'hui, ça me semble l'être, en tout cas pour les softs que j'utilise.
GoldenCrystal (./34) :
(Tiens c'est marrant, 23 et 32 mod.gif )

Oué, je pousse la contradiction à fond, même dans les numéros de posts trioui