• # C'est normal

    Posté par  (site web personnel) . Évalué à 6.

    Pour paraphraser quelqu'un:
    32 MB ought to be enough for anybody.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: C'est normal

      Posté par  . Évalué à 4.

      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

      • [^] # Re: C'est normal

        Posté par  . Évalué à 2.

        pour firefox, non, ils utilisent le compilateur de MS.
  • # Oh ...

    Posté par  . Évalué à 2.

    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...

    Nimporte quoi
    • [^] # Re: Oh ...

      Posté par  (site web personnel) . Évalué à 10.

      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)
      • [^] # Re: Oh ...

        Posté par  . Évalué à 1.

        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
        • [^] # Re: Oh ...

          Posté par  . Évalué à 10.

          (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)

          Quoi donc ?
          • [^] # Re: Oh ...

            Posté par  . Évalué à 4.

            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)
            • [^] # Re: Oh ...

              Posté par  . Évalué à 4.

              (nom di diou quel bordel ce site MSDN, comment qu'il est mal foutu, tout ça tout ça)

              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  . Évalué à 4.

                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.
                • [^] # Re: Oh ...

                  Posté par  . Évalué à 1.

                  "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.
                  • [^] # Re: Oh ...

                    Posté par  . Évalué à 1.

                    tu crois qu'il n'y a aucune contradiction ?

                    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  (site web personnel) . Évalué à 8.

        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...)
  • # Chouette

    Posté par  (site web personnel) . Évalué à 6.

    > "comment freiner le dev LL sous Vista"

    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  . Évalué à 8.

      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.
      • [^] # Re: Chouette

        Posté par  . Évalué à 10.

        A mon avis, il y a trois explications possibles:
        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...
      • [^] # Re: Chouette

        Posté par  . É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  . Évalué à 7.

          hum, cela n'exclue pas les 2 première possibilités ...

          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  . Évalué à 5.

    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...
    • [^] # Re: ...

      Posté par  . Évalué à 5.

      C'est vrai que malloc c'est une API viellotte et mal conçue, alors changer son comportement ne peut pas faire de tort.
      • [^] # Re: ...

        Posté par  . Évalué à 3.

        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.
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: ...

        Posté par  . Évalué à 3.

        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 ?
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: ...

            Posté par  . Évalué à 2.

            « 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" ...

            me semble être amusante.
      • [^] # Re: ...

        Posté par  . Évalué à 3.

        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.
      • [^] # Re: ...

        Posté par  . Évalué à 2.

        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 ! »...
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 1.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: ...

            Posté par  . Évalué à 4.

            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.
  • # GCC n'est pas bride sous vista

    Posté par  . Évalué à 5.

    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.
    • [^] # Re: GCC n'est pas bride sous vista

      Posté par  . Évalué à 6.

      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.

      Donc bon FUD des familles.
    • [^] # Re: GCC n'est pas bride sous vista

      Posté par  (site web personnel) . Évalué à 3.

      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.
      • [^] # Re: GCC n'est pas bride sous vista

        Posté par  (site web personnel) . Évalué à 8.

        C'est la fête:

        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.
        • [^] # Re: GCC n'est pas bride sous vista

          Posté par  . Évalué à 3.

          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.

          ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

          • [^] # Re: GCC n'est pas bride sous vista

            Posté par  . Évalué à 4.

            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)
  • # Pentium

    Posté par  (site web personnel) . Évalué à 10.

    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...

    http://fr.wikipedia.org/wiki/Bogue_de_la_division_du_Pentium
  • # Personnellement...

    Posté par  . Évalué à 4.

    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.

    Mes 2 centimes suisses.
    • [^] # Re: Personnellement...

      Posté par  . Évalué à 0.

      Ah oui c'est vrai excusez-moi, l'explication du soi-disant probleme n'est absolument pas pertinente et merite d'etre cachee.

      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  (site web personnel) . Évalué à 2.

      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.
      • [^] # Re: Personnellement...

        Posté par  . Évalué à 1.

        ça tombe mal, le monsieur parle de Vista ici (sans préciser l'édition mais je crois qu'on s'en fout)
      • [^] # Re: Personnellement...

        Posté par  . Évalué à 4.

        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).
  • # Date de publication

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Tiens, c'est amusant, la page a été mise à jour le premier avril...

    M'enfin, moi, je dis ça, je dis rien...
    • [^] # Re: Date de publication

      Posté par  (site web personnel) . Évalué à 1.

      ... mais publiée pour la première fois en mars.

      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.