Thus far I have found no workaround for this problem.
et pour paraphraser Distrowatch : "Put the fun back into computing. Use Linux, BSD" ;)
plus il y aura de mécontents, et plus les gens passeront à autre chose...
Et comment cela se fait que l'on en ait pas parlé plus tôt ? Firefox, openoffice et co, ils n'utilisent pas gcc comme base pour compiler sous windows ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
Ca, je trouve que c'est le truc le plus mesquin que MS ait fait. Encore faire passer OpenGL par DirectX (et virer WGL) c'est déjà pas terrible, mais ca ...
Bon le workaround ca serait de faire du reverse engineering pour faire marcher le linker gcc sous windows pour avoir le même résultat que le linker m$.
Le pire c'est que c'est peut être que le début.
Imaginez que ca en arrive a un point ou la team gcc soit obligée d'analyser les binaires windows pour voir que l'octet d'offset 3F doit être a 4A pour que le programme puisse accéder au système de fichier...
Il ne faut pas non plus s'enflammer, le terme "gcc sous vista" est abusif puisque ça ne concerne que djgpp c'est à dire la version "dos" de gcc, et pas mingw. ça ne gêne quasiment personne cette limitation, il suffit d'utiliser mingw (ou gcc/cygwin)
farpaitement, le mec mélange tout, comme le montre la mention de HIMEM.SYS et de divers DOS Extender.
limite si il ne se plaint pas que les bons vieux virus sous DOS ne marchent plus :(
il y a beaucoup de choses à dire sur Windows (on peut comparer Visual C++ 2003 et 2005 par exemple, quelque chose de très très précis manque bizarrement dans ce dernier et ça c'est très très mal) mais tant qu'à faire, neuneu aurait dû faire sa très fine analyse avec Vista 64 bits, ça aurait été encore pire niveau incompatibilités
une histoire d'une des variétés proposées de C Run-Time Libraries qu'il n'est plus possible d'utiliser (sans autre raison que "ouhlala c'est mal s'il vous plait ne le faites plus"), je ne suis pas sûr de retrouver la bonne page.
(ah oui, merci Microsoft au passage de faire disparaitre de votre déjà bordélique site la partie concernant le produit n quand le produit n+1 sort. très, très pratique, vraiment)
la partie "The single-threaded CRT (C runtime)(libc.lib, libcd.lib) (formerly the /ML or /MLd options) is no longer available."
boom, voila, d'un coté ils te tartinent qu'il faut utiliser la version multithreaded et comment faire vroom vroom avec, et à coté ils te disent que certaines fonctions à la con (chiantes, connues comme telles depuis 20 ans et plus, comme strtok(), non réentrante) vont faire que des conneries avec le runtime multithread (divers programmes vont utiliser la même librairie et se marcher dessus via des variables statiques partagées d'un coup par tout le monde, une vraie tournante madame)
heureusement, tout n'est pas perdu, il faut juste employer la version secure desdites fonctions, fonctions de remplacement fournies par Microsoft, comme strtok_s() pour remplacer strtok(). ça veut juste dire passer en revue votre code et remplacer les méchantes fonctions qui marchent plus ou qui cassent tout par des toutes gentilles et super secure même si bien plus lentes ou limitées pour une raison ou une autre par rapport à avant. ou constipées : avec des vérifications non désirables et non désactivables. ou bien vous n'avez plus tout le code de tout votre bazar, mais aussi des .lib contenant des appels à ces vilaines fonctions...
ben nom di diou j'aurais préféré garder cette librairie sous le coude, vraiment, que devoir me palucher tous ces assauts de modernité. virer la libc classique monothread standard de base, boudiou, ca va bien dans leur tete ? ah, c'est fait exprès ? pas merci, vraiment, pas merci.
boom, voila, d'un coté ils te tartinent qu'il faut utiliser la version multithreaded et comment faire vroom vroom avec, et à coté ils te disent que certaines fonctions à la con (chiantes, connues comme telles depuis 20 ans et plus, comme strtok(), non réentrante) vont faire que des conneries avec le runtime multithread (divers programmes vont utiliser la même librairie et se marcher dessus via des variables statiques partagées d'un coup par tout le monde, une vraie tournante madame)
Il n'y a AUCUNE difference.
La lib monothread n'a strictement aucun avantage sur la lib multithread, c'etait une relique du passe.
Ton soft il est soit multithread soit non.
Si il l'est, tu utilises la CRT monothread, t'es dans la merde, tu utilises la CRTE multithread, tu l'es moins.
Si il ne l'est pas, quelque soit la lib utilisee, t'es tout bon.
Faut bien comprendre qu'une librairie elle a beau avoir des variables statiques, ces variables ne sont pas partagees par tous les processus, mais par tous les threads d'un meme processus. Il y a une copie differente par processus.
Si tu passes de monothread a multithread, _rien_ ne casse. La lib multithread fait des choses en plus et mieux, elle ne fait rien de moins ou moins bien.
"Il n'y a AUCUNE difference" puis "La lib multithread fait des choses en plus et mieux, elle ne fait rien de moins ou moins bien", tu crois qu'il n'y a aucune contradiction ?
"c'etait une relique du passe" - ah, l'argument historique, imparable. "bouh, z'êtes ringards !", aucune protestation possible. les gus qui en ont besoin, qui ont constaté des différences - ont dû être ravis d'être traités de dinosaures condammnés depuis longtemps. comme les gus qui ont acheté Visual Basic 6 la veille du lancement de VB.Net, je suppose.
bravo de deviner les besoins de vos clients de façon aussi omnisciente et merci de leur fournir le support qu'ils méritent pour avoir été assez naïfs pour vous suivre à l'époque.
Bon je rephrase: si tu passes de monothread a multithread, tu ne verras aucune difference, car la lib multithread ne fait rien de moins ou moins bien que la monothread.
ah, l'argument historique, imparable. "bouh, z'êtes ringards !", aucune protestation possible. les gus qui en ont besoin, qui ont constaté des différences - ont dû être ravis d'être traités de dinosaures condammnés depuis longtemps
Si tu me donnes une difference ou la multithread se comporte differement de la monothread dans un environnement monothread, je serai ravi de ravaler mes paroles.
Exactement, si je ne me trompe pas DJGPP est prévu pour DOS. GCC pour Windows, c'est MinGW.
Il utilise un logiciel qui n'est pas prévu pour le système qu'il utilise. Le gus devrait même être content que DJGPP ait fonctionné jusqu'à Win XP.
Si j'étais MS, ça fait longtemps que je ne supporterai plus rien ayant à voir avec DOS / Win 3.1 / Win 9x.
A des moments faut casser la compatibilité ascendante pour progresser. Windows est bourré de bidouilles pour faire marcher les vieux programmes (ex les short pathnames : c:\progra~1\ etc...)
En même temps, si les developpeurs passait moins de temps sous Windows, et maintenant Vista, ça ferais plus de logiciels de meilleurs qualité et exclusifs à Linux.
Donc moi je suis plutôt pour ce genre de bridage !
C'est clair!
C'est connu depuis longtemps maintenant que Microsoft traite ses clients comme des otages. J'attends avec impatience le moment où les gens vont enfin se rendre compte qu'effectivement ils sont vraiment otages....
Mais enfin, le type qui à cette mésaventure écrit ça:
I would appreciate being informed of a fix for this problem, if one exists. However, I am not interested in wild guesses, vague suggestions, or discussions of Microsoft. My definition of a "fix" does not include installing and booting to a different operating system
En gros, il s'est fait plumer pour un OS qu'il ne peux pas utiliser pour des raisons obscures, il ne peut pas non plus utiliser le Nero qu'il a acheté, il se plaint de défauts de Vista, mais il est hors de question qu'il change d'OS!
A mon avis, il y a trois explications possibles:
- il est masochiste
- il pense qu'en faisant du bruit, microsoft fera un geste pour lui
- il est vraiment bête.
J'hésite.
Tu as oublié la bonne réponse : son employeur veut que ça marche sous Windows (donc aussi sur la dernière nouvelle version).
Si Firefox et OpenOffice n'étaient pas disponibles sous Windows, IE serait toujours à plus de 80% et les formats OpenDocument ne seraient pas aussi en vogue. Vous ne réalisez pas que des logiciels libres sous Windows, c'est la première étape vers Linux ? Une fois que toutes les applications phares seront disponibles sous les deux systèmes d'exploitation, la migration sera presque transparante.
Et le plus important, ce sont des formats de données documentés et si possible libres. Après chacun est libre de choisir ses outils comme bon lui semble...
A mon avis, il y a trois explications possibles:
- il est masochiste
- il pense qu'en faisant du bruit, microsoft fera un geste pour lui
- il est vraiment bête.
J'hésite.
Sais-tu qui est vraiment ce monsieur ? C'est loin d'être le guignol dont tu tentes de nous dépeindre le portrait. Cours vite visiter sa page web pour te rendre compte qu'il est (très) loin (mais alors vraiment très loin) d'être un charlot dans ce domaine.
J'ai l'impression qu'il va falloir se rabattre sur le cas n°1 :)
Sinon, l'impression générale est que c'est kador en mathématiques, en numération plus exactement, et qu'il lui a fallut jouer serré avec les compilateurs et les implémentations des types natifs des processeurs pour son travail. Mais j'ai rien vu qui ne lui donne une once de crédit sur la partie système (liaison, API et bibliothèques, ce qui nous intéresse ici).
Par contre, j'ai maintenant la certitude qu'il s'est tellement pris la tête pour faire tourner ces algos de manière ultra optimum qu'il a une peur bleue d'y avoir a refaire face en changeant un seul octet dans environnement d'exécution habituel, comme quoi, tout masochiste a ses limites :)
Bah voilà, ça commence ou "comment freiner le dev LL sous Vista" ...
En meme temps ils ont le droits de changer de temps en temps leur API, on leur reproche souvent de trainé des boulets par soucis de compatibilité.
Et puis c'est bizare il a l'air de dire que les version de gcc de mingw et cygwin marche....
Enfin son truc est basé sur gcc 3.04, ca m'a pas l'air tout jeune...
rien dans l'API malloc ne stipule l'abscence ou l'existence d'un maximum de memoire allouable. Par contre l'API stipule bien l'erreur si la memoire ne peut etre allouee. Apparement, c'est ce qui se passe.
Ce qu'il dénonce, c'est un changement du comportement de la même API quand on passe sous Vista. S'il s'agissait effectivement d'un changement d'API, il y aurait une erreur à l'exécution lors de la liaison dynamique.
Ben c'est la meme chose : on peut dire que les fonctions utilisé ont été mise obsolètes depuis un certain temps et comme cette API possait des pb (de secu, était un effet de bord non documenté,...), ils ont décidé de la restreindre a certains cas (<32 Mb). [ce n'est que pure hypothese de ma part]
As explained above, the executables produced by these products do not exhibit the 32MB memory limitation when executed in XP or Win98SE, so the problem is due to Vista, not GCC 3.04 or DJGPP. If you disagree, I would be interested to hear of your own results after compiling, linking, and running (within Vista) my sample code, using any version of GCC which does not link to the Win32 API.
Et alors si sont truc utilise une API qui n'est plus valide sous vista, c'est son problème pas celui de vista.
Si je telecharge un programme prevu pour la libc5 et qu'il ne marche pas sur glibc6, j'ai aussi le droit de faire un scandale comme quoi Linux c'est de la merde ?
« tu as parfaitement le droit de passer pour un gars amusant en te plaignant d'un problème largement documenté publiquement et très connu. »
Donc si je comprend bien, il y a un gars sérieux qui à un problème technique inédit et non documenté, et qui s'interroge sur la manière de le résoudre. Très bien.
Par contre la manière de présenter l'information :
Bah voilà, ça commence ou "comment freiner le dev LL sous Vista" ...
Tu te trompes : il n'y a pas de changement d'API vu que les logiciels mis en oeuvre utilisent ... la même API !
Ben si l'API en question est DPMI http://gilisa.free.fr/outils/dpmi/ c'est un vieux machin prévu pour DOS, ça peut pas non plus être supporté indéfiniment.
Franchement si son problème est bien DPMI, "Windows Vista restricts GNU GCC apps to 32 MB" c'est n'importe quoi.
As explained above, the executables produced by these products do not exhibit the 32MB memory limitation when executed in XP or Win98SE, so the problem is due to Vista
Ce raisonnement est faux : Ce n'est pas parce que quelque chose fonctionne qu'il est correctement écrit [1]. Peut être par exemple que les API de XP étaient plus permissives que ne le sont celles de Vista.
Les gars de MS n'ont certainement pas ajouter cette limitation volontairement. De toute manière, ça aurai quand même été étonnant que djgcc marche sous vista du premier coup. Maintenant, c'est sûr que sans sources (et quasiment sans documentation), c'est moins facile à adapter...
[1]: ma vie, en TP de SQL.
- un étudiant écrit une requête fausse. Elle fonctionne quand même
- il la modifie (en rajoutant du code juste). Ça ne fonctionne plus.
- « M'sieux j'comprend pas ! »...
1) c'était en 1994, soit il y a plus de 12 ans. il a très bien pu disjoncter depuis. les frasques d'ESR qui fout en l'air son système en forçant des options de rpm puis vient râler après qu'il a tout cassé, par exemple, ça peut faire peur.
2) il n'est peut-être pas exactement dans son domaine de compétences. oui, j'ai lu sa page, mais disons en forçant le trait que je n'attends pas de Knuth ou de RMS une bonne connaissance de la base de registre de Windows ou de comment faire le ménage d'un PC vérolé, par exemple.
3) ca peut arriver à tout le monde de se mélanger les pinceaux. je crois que c'est le cas ici. ses "ADDITIONAL NOTES" indiquent qu'il constate que d'autres "vieux" outils, librairies, etc merdoient tout aussi gaiement sous Vista.
oui, Vista semble avoir du mal en l'état avec des programmes contenant des gestionnaires de mémoire tiers et autres "DOS Extender" et (tada!) non je ne pense pas que ça soit une attaque contre le Libre et gcc.
se baser uniquement sur le passé de ce gus et en profiter pour négliger, oublier tout esprit critique, cai po bien.
De ce que je comprends c'est juste qu'une API est a moitie "deprecated" (et il se trouve que c'est l'API de la libc), et qu'il faut utiliser les fonctions win32 proprio.
Qu'importe, il suffit d'utiliser une libraire qui wrappe les appels a malloc vers les fonctions win32 comme le font les compilos proprio.
GCC n'est pas bride sous vista, il n'est juste pas adapte aux nouvelles APIs. Un meilleur titre que "Windows Vista restricts GNU GCC apps to 32 MB" serait "GNU GCC is restricted to 32MB under Windows Vista".
PS: je ne suis pas un defenseur de MS mais un pourfendeur des alarmistes qui donnent des arguments sans credibilite.
N'en peche, ça a failly marché, j'ai failli comprendre qu'en gros les lociels compilés avec Gcc marchaient plus sous Windows.
Bah ouais, je lis trop vite.
Je ne comprends pas comment gcc peut faire pour allouer de la mémoire sans passer par l'API Win32. En plus, dire que c'est propriétaire, ce n'est pas nouveau, il faut bien à un moment faire des appels systèmes, et vous savez quoi? Ces appels systèmes sont propriétaires, vu qu'on est sur un système proprio.
DJGPP is a complete 32-bit C/C++ development system for Intel 80386 (and higher) PCs running DOS
Donc apparemment il compile un programme DOS (32 bits) et il est tombé sur un bug (problème de rétro-compatibilité avec un OS qui a commencé à disparaître il y a 12 ans). Génial.
En même temps, le DOS permet d'allouer plus de 32Mo de RAM, et les émulateurs DOS de NT4, 2000 et XP aussi. Donc introduire une telle limitation, ça a sa place dans une release note.
source ? parce que pour allouer plus de 64 ko de façon contigue avec TurboC (par exemple) à la belle époque, il fallait commencer à tirer la langue.
il fallait commencer à utiliser un driver de mémoire supérieure (d'où des noms comme himem.sys) et pour ne plus se pisser dans les poils à devoir gérer des tas de minuscules petits blocs de données de 64 ko, il fallait passer au 32 bits. on appellait ça des DOS Extender, beaucoup de jeux et applis DOS vers disons 1994 ou 1995 les utilisaient et affichaient souvent une petite chaine de caractères genre DOS4GWX au lancement
deux choses ici :
* il y en avait 36 sur le marché des développeurs et en fait plus si on commence à compter les différentes versions de chaque : ce n'était pas unifié du tout. pas trop besoin vu qu'on lancait une seule appli à la fois, à peine le PC allumé, et pas Doom depuis Autocad par exemple.
* pas possible en général de lancer de telles applis depuis Windows 3.1 ou 95, mais certaines marchaient, comme Doom : je suppose que Microsoft n'a pas essayé de supporter absolument tous ces DOS Extender, seulement les plus populaires (et encore, ceux définitivement pas incompatibles avec son propre merdier)
Donc introduire une telle limitation, ça a sa place dans une release note.
tout à fait d'accord, ou dans un des outils de compatibilités que Microsoft va peut-être sortir comme ils l'ont fait à l'époque de Windows 2000/XP pour des tas d'applis et jeux Windows 95/98/ME ("Microsoft Windows Application Compatibility Toolkit")
en même temps avec la version 64 bits de Vista ce genre de gags va être encore plus courant et euh "décisif", "sanglant", car là c'est clairement annoncé que la plupart des programmes 16 bits vont tout simplement pas marcher (et pas juste ceux utilisant directement des accès disques et autres comme maintenant)
Juste pour info : le type qui a découvert ce problème (Thomas Nicely), c'est le même qui avait mis au jour le bug de la division du Pentium en 1994, qui avait obligé Intel à remplacer tous les processeurs défectueux...
Je lui conseillerai d'ouvrir Explorer, d'aller dans \Windows\system32 , click droit sur command.com, aller dans la tab "memory" et changer les valeurs.
Tu as testé ce que tu proposes ? La valeur maximale que l'on peut saisir sous Windows XP, c'est 65535, soit 64 Mo. Ça ne résoud absolument pas le problème.
J'ai regarder sous vista (c'est assez incomprehensible comme reglage) et la valeur max semble 16 MB (peut etre * 2 en selectionnant les differents type de memoire).
Par ailleurs, la date de dernière mise à jour est maintenant le 2 avril.
[ce qui est bizarre c'est que tu ne l'aies pas remarqué : l'heure de la mise à jour est 3:30 EDT, ce qui correspond à 7:30 UTC (sauf erreur), soit 9h30 heure française, c'est-à-dire quelques minutes avant la publication de ton commentaire. La page a dû être mise à jour entre le moment où tu l'as lue et celui où tu as commenté ici.]
# C'est normal
Posté par lolop (site web personnel) . Évalué à 6.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: C'est normal
Posté par B16F4RV4RD1N . Évalué à 4.
et pour paraphraser Distrowatch : "Put the fun back into computing. Use Linux, BSD" ;)
plus il y aura de mécontents, et plus les gens passeront à autre chose...
Et comment cela se fait que l'on en ait pas parlé plus tôt ? Firefox, openoffice et co, ils n'utilisent pas gcc comme base pour compiler sous windows ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: C'est normal
Posté par Nap . Évalué à 2.
# Oh ...
Posté par Oscar Blumberg . Évalué à 2.
Bon le workaround ca serait de faire du reverse engineering pour faire marcher le linker gcc sous windows pour avoir le même résultat que le linker m$.
Le pire c'est que c'est peut être que le début.
Imaginez que ca en arrive a un point ou la team gcc soit obligée d'analyser les binaires windows pour voir que l'octet d'offset 3F doit être a 4A pour que le programme puisse accéder au système de fichier...
Nimporte quoi
[^] # Re: Oh ...
Posté par Troy McClure (site web personnel) . Évalué à 10.
[^] # Re: Oh ...
Posté par Gniarf . Évalué à 1.
limite si il ne se plaint pas que les bons vieux virus sous DOS ne marchent plus :(
il y a beaucoup de choses à dire sur Windows (on peut comparer Visual C++ 2003 et 2005 par exemple, quelque chose de très très précis manque bizarrement dans ce dernier et ça c'est très très mal) mais tant qu'à faire, neuneu aurait dû faire sa très fine analyse avec Vista 64 bits, ça aurait été encore pire niveau incompatibilités
[^] # Re: Oh ...
Posté par manuell . Évalué à 10.
Quoi donc ?
[^] # Re: Oh ...
Posté par Gniarf . Évalué à 4.
(ah oui, merci Microsoft au passage de faire disparaitre de votre déjà bordélique site la partie concernant le produit n quand le produit n+1 sort. très, très pratique, vraiment)
[^] # Re: Oh ...
Posté par Gniarf . Évalué à 4.
http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).asp(...)
la partie "The single-threaded CRT (C runtime)(libc.lib, libcd.lib) (formerly the /ML or /MLd options) is no longer available."
boom, voila, d'un coté ils te tartinent qu'il faut utiliser la version multithreaded et comment faire vroom vroom avec, et à coté ils te disent que certaines fonctions à la con (chiantes, connues comme telles depuis 20 ans et plus, comme strtok(), non réentrante) vont faire que des conneries avec le runtime multithread (divers programmes vont utiliser la même librairie et se marcher dessus via des variables statiques partagées d'un coup par tout le monde, une vraie tournante madame)
heureusement, tout n'est pas perdu, il faut juste employer la version secure desdites fonctions, fonctions de remplacement fournies par Microsoft, comme strtok_s() pour remplacer strtok(). ça veut juste dire passer en revue votre code et remplacer les méchantes fonctions qui marchent plus ou qui cassent tout par des toutes gentilles et super secure même si bien plus lentes ou limitées pour une raison ou une autre par rapport à avant. ou constipées : avec des vérifications non désirables et non désactivables. ou bien vous n'avez plus tout le code de tout votre bazar, mais aussi des .lib contenant des appels à ces vilaines fonctions...
ben nom di diou j'aurais préféré garder cette librairie sous le coude, vraiment, que devoir me palucher tous ces assauts de modernité. virer la libc classique monothread standard de base, boudiou, ca va bien dans leur tete ? ah, c'est fait exprès ? pas merci, vraiment, pas merci.
[^] # Re: Oh ...
Posté par pasBill pasGates . Évalué à 4.
Il n'y a AUCUNE difference.
La lib monothread n'a strictement aucun avantage sur la lib multithread, c'etait une relique du passe.
Ton soft il est soit multithread soit non.
Si il l'est, tu utilises la CRT monothread, t'es dans la merde, tu utilises la CRTE multithread, tu l'es moins.
Si il ne l'est pas, quelque soit la lib utilisee, t'es tout bon.
Faut bien comprendre qu'une librairie elle a beau avoir des variables statiques, ces variables ne sont pas partagees par tous les processus, mais par tous les threads d'un meme processus. Il y a une copie differente par processus.
Si tu passes de monothread a multithread, _rien_ ne casse. La lib multithread fait des choses en plus et mieux, elle ne fait rien de moins ou moins bien.
[^] # Re: Oh ...
Posté par Gniarf . Évalué à 1.
"c'etait une relique du passe" - ah, l'argument historique, imparable. "bouh, z'êtes ringards !", aucune protestation possible. les gus qui en ont besoin, qui ont constaté des différences - ont dû être ravis d'être traités de dinosaures condammnés depuis longtemps. comme les gus qui ont acheté Visual Basic 6 la veille du lancement de VB.Net, je suppose.
bravo de deviner les besoins de vos clients de façon aussi omnisciente et merci de leur fournir le support qu'ils méritent pour avoir été assez naïfs pour vous suivre à l'époque.
[^] # Re: Oh ...
Posté par pasBill pasGates . Évalué à 1.
Bon je rephrase: si tu passes de monothread a multithread, tu ne verras aucune difference, car la lib multithread ne fait rien de moins ou moins bien que la monothread.
ah, l'argument historique, imparable. "bouh, z'êtes ringards !", aucune protestation possible. les gus qui en ont besoin, qui ont constaté des différences - ont dû être ravis d'être traités de dinosaures condammnés depuis longtemps
Si tu me donnes une difference ou la multithread se comporte differement de la monothread dans un environnement monothread, je serai ravi de ravaler mes paroles.
[^] # Re: Oh ...
Posté par alberthier (site web personnel) . Évalué à 8.
Il utilise un logiciel qui n'est pas prévu pour le système qu'il utilise. Le gus devrait même être content que DJGPP ait fonctionné jusqu'à Win XP.
Si j'étais MS, ça fait longtemps que je ne supporterai plus rien ayant à voir avec DOS / Win 3.1 / Win 9x.
A des moments faut casser la compatibilité ascendante pour progresser. Windows est bourré de bidouilles pour faire marcher les vieux programmes (ex les short pathnames : c:\progra~1\ etc...)
# Chouette
Posté par Christophe Merlet (site web personnel) . Évalué à 6.
En même temps, si les developpeurs passait moins de temps sous Windows, et maintenant Vista, ça ferais plus de logiciels de meilleurs qualité et exclusifs à Linux.
Donc moi je suis plutôt pour ce genre de bridage !
[^] # Re: Chouette
Posté par Gilles G. . Évalué à 8.
C'est connu depuis longtemps maintenant que Microsoft traite ses clients comme des otages. J'attends avec impatience le moment où les gens vont enfin se rendre compte qu'effectivement ils sont vraiment otages....
Mais enfin, le type qui à cette mésaventure écrit ça:
En gros, il s'est fait plumer pour un OS qu'il ne peux pas utiliser pour des raisons obscures, il ne peut pas non plus utiliser le Nero qu'il a acheté, il se plaint de défauts de Vista, mais il est hors de question qu'il change d'OS!
A mon avis, il y a trois explications possibles:
- il est masochiste
- il pense qu'en faisant du bruit, microsoft fera un geste pour lui
- il est vraiment bête.
J'hésite.
[^] # Re: Chouette
Posté par Anonyme . Évalué à 10.
Si Firefox et OpenOffice n'étaient pas disponibles sous Windows, IE serait toujours à plus de 80% et les formats OpenDocument ne seraient pas aussi en vogue. Vous ne réalisez pas que des logiciels libres sous Windows, c'est la première étape vers Linux ? Une fois que toutes les applications phares seront disponibles sous les deux systèmes d'exploitation, la migration sera presque transparante.
Et le plus important, ce sont des formats de données documentés et si possible libres. Après chacun est libre de choisir ses outils comme bon lui semble...
[^] # Re: Chouette
Posté par Xavier Maillard . Évalué à 2.
A mon avis, il y a trois explications possibles:
- il est masochiste
- il pense qu'en faisant du bruit, microsoft fera un geste pour lui
- il est vraiment bête.
J'hésite.
Sais-tu qui est vraiment ce monsieur ? C'est loin d'être le guignol dont tu tentes de nous dépeindre le portrait. Cours vite visiter sa page web pour te rendre compte qu'il est (très) loin (mais alors vraiment très loin) d'être un charlot dans ce domaine.
[^] # Re: Chouette
Posté par Anonyme . Évalué à 7.
Et après avoir parcouru ca :
http://www.trnicely.net/pentbug/pentbug.html
J'ai l'impression qu'il va falloir se rabattre sur le cas n°1 :)
Sinon, l'impression générale est que c'est kador en mathématiques, en numération plus exactement, et qu'il lui a fallut jouer serré avec les compilateurs et les implémentations des types natifs des processeurs pour son travail. Mais j'ai rien vu qui ne lui donne une once de crédit sur la partie système (liaison, API et bibliothèques, ce qui nous intéresse ici).
Par contre, j'ai maintenant la certitude qu'il s'est tellement pris la tête pour faire tourner ces algos de manière ultra optimum qu'il a une peur bleue d'y avoir a refaire face en changeant un seul octet dans environnement d'exécution habituel, comme quoi, tout masochiste a ses limites :)
# ...
Posté par M . Évalué à 5.
En meme temps ils ont le droits de changer de temps en temps leur API, on leur reproche souvent de trainé des boulets par soucis de compatibilité.
Et puis c'est bizare il a l'air de dire que les version de gcc de mingw et cygwin marche....
Enfin son truc est basé sur gcc 3.04, ca m'a pas l'air tout jeune...
[^] # Re: ...
Posté par wismerhill . Évalué à 5.
[^] # Re: ...
Posté par mdlh . Évalué à 3.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par M . Évalué à 3.
Ben c'est la meme chose : on peut dire que les fonctions utilisé ont été mise obsolètes depuis un certain temps et comme cette API possait des pb (de secu, était un effet de bord non documenté,...), ils ont décidé de la restreindre a certains cas (<32 Mb). [ce n'est que pure hypothese de ma part]
As explained above, the executables produced by these products do not exhibit the 32MB memory limitation when executed in XP or Win98SE, so the problem is due to Vista, not GCC 3.04 or DJGPP. If you disagree, I would be interested to hear of your own results after compiling, linking, and running (within Vista) my sample code, using any version of GCC which does not link to the Win32 API.
Et alors si sont truc utilise une API qui n'est plus valide sous vista, c'est son problème pas celui de vista.
Si je telecharge un programme prevu pour la libc5 et qu'il ne marche pas sur glibc6, j'ai aussi le droit de faire un scandale comme quoi Linux c'est de la merde ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par Rémi Pannequin . Évalué à 2.
Donc si je comprend bien, il y a un gars sérieux qui à un problème technique inédit et non documenté, et qui s'interroge sur la manière de le résoudre. Très bien.
Par contre la manière de présenter l'information :
me semble être amusante.
[^] # Re: ...
Posté par manuell . Évalué à 3.
Ben si l'API en question est DPMI http://gilisa.free.fr/outils/dpmi/ c'est un vieux machin prévu pour DOS, ça peut pas non plus être supporté indéfiniment.
Franchement si son problème est bien DPMI, "Windows Vista restricts GNU GCC apps to 32 MB" c'est n'importe quoi.
[^] # Re: ...
Posté par Rémi Pannequin . Évalué à 2.
Ce raisonnement est faux : Ce n'est pas parce que quelque chose fonctionne qu'il est correctement écrit [1]. Peut être par exemple que les API de XP étaient plus permissives que ne le sont celles de Vista.
Les gars de MS n'ont certainement pas ajouter cette limitation volontairement. De toute manière, ça aurai quand même été étonnant que djgcc marche sous vista du premier coup. Maintenant, c'est sûr que sans sources (et quasiment sans documentation), c'est moins facile à adapter...
[1]: ma vie, en TP de SQL.
- un étudiant écrit une requête fausse. Elle fonctionne quand même
- il la modifie (en rajoutant du code juste). Ça ne fonctionne plus.
- « M'sieux j'comprend pas ! »...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: ...
Posté par Gniarf . Évalué à 4.
2) il n'est peut-être pas exactement dans son domaine de compétences. oui, j'ai lu sa page, mais disons en forçant le trait que je n'attends pas de Knuth ou de RMS une bonne connaissance de la base de registre de Windows ou de comment faire le ménage d'un PC vérolé, par exemple.
3) ca peut arriver à tout le monde de se mélanger les pinceaux. je crois que c'est le cas ici. ses "ADDITIONAL NOTES" indiquent qu'il constate que d'autres "vieux" outils, librairies, etc merdoient tout aussi gaiement sous Vista.
oui, Vista semble avoir du mal en l'état avec des programmes contenant des gestionnaires de mémoire tiers et autres "DOS Extender" et (tada!) non je ne pense pas que ça soit une attaque contre le Libre et gcc.
se baser uniquement sur le passé de ce gus et en profiter pour négliger, oublier tout esprit critique, cai po bien.
# GCC n'est pas bride sous vista
Posté par Matthieu Lemerre . Évalué à 5.
Qu'importe, il suffit d'utiliser une libraire qui wrappe les appels a malloc vers les fonctions win32 comme le font les compilos proprio.
GCC n'est pas bride sous vista, il n'est juste pas adapte aux nouvelles APIs. Un meilleur titre que "Windows Vista restricts GNU GCC apps to 32 MB" serait "GNU GCC is restricted to 32MB under Windows Vista".
PS: je ne suis pas un defenseur de MS mais un pourfendeur des alarmistes qui donnent des arguments sans credibilite.
[^] # Re: GCC n'est pas bride sous vista
Posté par farib . Évalué à 6.
Bah ouais, je lis trop vite.
Donc bon FUD des familles.
[^] # Re: GCC n'est pas bride sous vista
Posté par Fabimaru (site web personnel) . Évalué à 3.
[^] # Re: GCC n'est pas bride sous vista
Posté par Fabimaru (site web personnel) . Évalué à 8.
Donc apparemment il compile un programme DOS (32 bits) et il est tombé sur un bug (problème de rétro-compatibilité avec un OS qui a commencé à disparaître il y a 12 ans). Génial.
[^] # Re: GCC n'est pas bride sous vista
Posté par ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: GCC n'est pas bride sous vista
Posté par Gniarf . Évalué à 4.
il fallait commencer à utiliser un driver de mémoire supérieure (d'où des noms comme himem.sys) et pour ne plus se pisser dans les poils à devoir gérer des tas de minuscules petits blocs de données de 64 ko, il fallait passer au 32 bits. on appellait ça des DOS Extender, beaucoup de jeux et applis DOS vers disons 1994 ou 1995 les utilisaient et affichaient souvent une petite chaine de caractères genre DOS4GWX au lancement
deux choses ici :
* il y en avait 36 sur le marché des développeurs et en fait plus si on commence à compter les différentes versions de chaque : ce n'était pas unifié du tout. pas trop besoin vu qu'on lancait une seule appli à la fois, à peine le PC allumé, et pas Doom depuis Autocad par exemple.
* pas possible en général de lancer de telles applis depuis Windows 3.1 ou 95, mais certaines marchaient, comme Doom : je suppose que Microsoft n'a pas essayé de supporter absolument tous ces DOS Extender, seulement les plus populaires (et encore, ceux définitivement pas incompatibles avec son propre merdier)
Donc introduire une telle limitation, ça a sa place dans une release note.
tout à fait d'accord, ou dans un des outils de compatibilités que Microsoft va peut-être sortir comme ils l'ont fait à l'époque de Windows 2000/XP pour des tas d'applis et jeux Windows 95/98/ME ("Microsoft Windows Application Compatibility Toolkit")
en même temps avec la version 64 bits de Vista ce genre de gags va être encore plus courant et euh "décisif", "sanglant", car là c'est clairement annoncé que la plupart des programmes 16 bits vont tout simplement pas marcher (et pas juste ceux utilisant directement des accès disques et autres comme maintenant)
# Pentium
Posté par Archibald (site web personnel) . Évalué à 10.
http://fr.wikipedia.org/wiki/Bogue_de_la_division_du_Pentium
# Personnellement...
Posté par pasBill pasGates . Évalué à 4.
Mes 2 centimes suisses.
[^] # Re: Personnellement...
Posté par pasBill pasGates . Évalué à 0.
Par contre les aneries sur MS elles elles sont bien sur pertinentes.
Quel systeme de merde ces XP quand meme, ca permet a qqe attardes mentaux de jouer aux ayatollahs au detriment de tout le monde.
[^] # Re: Personnellement...
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Personnellement...
Posté par Gniarf . Évalué à 1.
[^] # Re: Personnellement...
Posté par M . Évalué à 4.
[^] # Re: Personnellement...
Posté par pasBill pasGates . Évalué à 0.
# Date de publication
Posté par nojhan (site web personnel, Mastodon) . Évalué à 3.
M'enfin, moi, je dis ça, je dis rien...
[^] # Re: Date de publication
Posté par davux (site web personnel) . Évalué à 1.
Par ailleurs, la date de dernière mise à jour est maintenant le 2 avril.
[ce qui est bizarre c'est que tu ne l'aies pas remarqué : l'heure de la mise à jour est 3:30 EDT, ce qui correspond à 7:30 UTC (sauf erreur), soit 9h30 heure française, c'est-à-dire quelques minutes avant la publication de ton commentaire. La page a dû être mise à jour entre le moment où tu l'as lue et celui où tu as commenté ici.]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.