Discussion :

[Hibou57]

Remarque préalable à ce post. Je pensais initialement poster ce sujet dans le forum système/windows, mais comme il est organisé par version de windows, et ne comporte pas d'entrées pour le système windows en général, je post ce sujet, à défaut, dans developpement/windows.

Je cite un extrait d'un long article, que vous pouvez lire en intégralité ici : http://www.joelonsoftware.com/articles/APIWar.html

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

(c'est moi qui souligne).

Je résume, en français, pour ceux/celles qui ne lisent pas l'anglais. Un jeux, SimCity, qui fonctionnait bien sous DOS, s'avérait ne plus fonctionner sous Windows, dut-à un bug qui le faisait utiliser des zones des mémoires aprés les avoir libéré (sous DOS, mono-tâche, ça ne posait pas de problème.. mais sous Windows, le bug s'exprimait pleinement en faisant cracher l'application). Plutôt de corriger le bug (SimCity était une application phare, et windows ne pouvait pas s'en passer, car un OS se vend surtout pour les applications qu'il execute), plutôt que de corriger le bug de SimCity, une fonction spécial à été ajouté à Windows, pour que windows detecte l'execution de SimCity, et pour que dans cette circonstance, Windows passe dans un mode de gestion spéciale de la mémoire, autorisant l'utilisation de zones de mémoires pourtant libérées!

Je suppose qu'il y en a d'autres... mais j'avais envie de vous en faire part.

N.B. Je ne jête pour autant pas la pierre à Windows, parce qu'au moins, Windows, il marche lui ... concrêtement .... hummm...

[Médinoc]

Ils ont fait ça dans quel Windows?
Déjà, vu que ça s'applique sur un programme DOS, cela ne peut avoir été gardé dans WinNT...
Donc, ils ont sans doute fait ça dans Win16, reste à savoir si c'était toujours actif dans Win32...

Sinon, ton article me fait penser à ceci (Framework .Net)
http://msdn.microsoft.com/msdnmag/is...aspx?side=true

All the changes involved with renaming the section would have taken so long that we would have had to significantly slip the release date of Visual Studio 2005 and SQL Server 2005. Then one of our team members proposed an alternate solution that, if implemented, may have gone down in history as one of the ugliest hacks ever: rather than rename the section so that the validation code no longer failed on it, hack the String.StartsWith method so that it in this specific situation it lied and returned false rather than true. We would detect that the application had just called "configProtectedData".StartsWith("config") and return false. We even designed a series of optimization to make this check impact other applications as little as possible:

Code C# ? :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if (result == true && input.Length == 6 && this.Length == 19 &&
    this.Equals("configProtectedData") &&
    MethodInfo.GetCurrentMethod().Name.Equals("VerifySectionName"))
{
    return false;
}

Là aussi, c'est moi qui souligne.

[Hibou57]

J'en avais une bien croustillante aussi, mais je l'ai perdu.... c'était un bout de code de l'API, qui tentait d'appeler plusieurs fois une fonction dans une boucle, pour voir si ça marche (l'appel direct fonctionnait une fois sur 10, pour raisons inconnues)... au petit bonheur de la chance.

Une chose à savoir quand même : c'est toujours une erreur de se reposer sur de telles informations pour la conception d'une application, parce que la compatibilité ascendante (d'ailleurs récement abandonné avec windows longhorm), ne s'applique pas à ces aspects non documentés de windows.