Der Quellcode des Windows-Rechners, ein Alptraum

Der Windows-Rechner Calc befindet sich auf Milliarden Rechnern, da er mit Windows ausgeliefert wird. Kürzlich wurde der Quellcode des Programms als Open Source auf GitHub freigegeben. Ein paar Leute haben sich den Programmcode angesehen, das Teil ist ein Alptraum. Memory Leaks, Inhalt der Zwischenablage geht an Microsoft-Server, Berechnungsfehler und mehr.

Aktuell geht ja eher die Geschichte, dass Microsoft eine Grafikfunktionen-Anzeige im Windows 10-Rechner integrieren will, durch die Blogs und Internetmedien. Dabei wäre es eher wichtig, den Quellcode des Rechners mal zu entrümpeln und zu bereinigen.

(Quelle: Microsoft)

Blog-Leser Adrian hat mich auf diese Fundstelle von PVS-Studio im Web aufmerksam gemacht – danke da für. Es geht um den Windows-Rechner Calc, der auf allen Windows-Systemen mit an Bord ist. Vor einigen Tagen wurde der Quellcode dieses Programms ja als OpenSource auf Github freigegeben (siehe Windows Rechner als Open Source auf GitHub freigegeben). Die Community von PVS-Studio hat sich den Code mal angesehen und erstaunliches gefunden.

Zwischenablage geht an Microsoft

Das folgende Code-Fragment im GitHub-Quellcode des Rechners hat sofort die Aufmerksamkeit der Community auf sich gezogen.

void TraceLogger::LogInvalidInputPasted(....)
{
  if (!GetTraceLoggingProviderEnabled()) return;

  LoggingFields fields{};
  fields.AddString(L"Mode", NavCategory::GetFriendlyName(mode)->Data());
  fields.AddString(L"Reason", reason);
  fields.AddString(L"PastedExpression", pastedExpression);
  fields.AddString(L"ProgrammerNumberBase", GetProgrammerType(...).c_str());
  fields.AddString(L"BitLengthType", GetProgrammerType(bitLengthType).c_str());
  LogTelemetryEvent(EVENT_NAME_INVALID_INPUT_PASTED, fields);
}

Diese Funktion protokolliert Text aus der Zwischenablage und sendet ihn anscheinend an Microsoft-Server. Dem PVS-Studio-Beitrag entnehme ich, dass der Code weitere 'verdächtige' Stellen enthält. Macht schon Laune.

Weitere Unfälle

Die Leute von PVS-Studio haben den statischen Analysator des Tools PVS-Studio verwendet, um den Quellcode des Rechners zu überprüfen. Da der Windows-Rechner nicht in Standard-C++ geschrieben ist, gab es Zweifel, ob eine statische Code-Analyse möglich sei. Aber die Analyse hat wohl (trotz einiger Fehlalarme) funktioniert. Hier eine kurze Übersicht zu gefundenen Problemen.

• Falscher Zeichenkettenvergleich (V547, Calculator LocalizationSettings.h Zeile 180): Ein Ausdruck 'm_resolvedName == L«en-US»' innerhalb einer if-Abfrage liefert immer den Wert false.
• Memory leak im Programmcode (V773, CalcViewModel StandardCalculatorViewModel.cpp Zeile 529): Im Modul existiert ein potentielles Speicherleck, denn eine Funktion wird beendet, ohne den Zeiger "temp" freizugeben.
• Schwere Ausnahme (V702, CalcManager CalcException.h Zeile 4): Klassen sollten immer von std::exception (und ähnlichem) als 'public' abgeleitet werden (es wurde kein Schlüsselwort angegeben, so dass der Compiler es standardmäßig auf 'private' setzt).
• Fehlender Tag in Datumsmodul (V719, CalcViewModel DateCalculator.cpp Zeile 279):
• Die Switch-Anweisung deckt nicht alle Werte der Enum (Auflistung) 'DateUnit' ab.
• Verdächtiger Vergleich von realen Zahlen (V550, Calculator AspectRatioTrigger.cpp Zeile 80): Der Code enthält einen merkwürdigen Vergleich zweier realer Zahlen (Fließkommawerte) der Art ratio == threshold. Es ist wahrscheinlich besser, einen Vergleich mit definierter Genauigkeit zu verwenden: fabs(A — B) < Epsilon.

An dieser Stelle breche ich die Auflistung mal ab. Der Beitrag auf habr.com enthält eine ganze Latte weiterer solcher Stilblüten im Programmcode. Gut, Fehler können immer passieren – das weiß ich auch – obwohl meine Zeiten als Entwickler ein Viertel-Jahrhundert vorbei sind. Aber es stellt sich schon die Frage, wie es mit der Code-Qualität aus Redmond bestellt ist.

Ein paar Gedanken

Denn der jetzt freigegebene Code ist ja quasi so etwas wie eine Arbeitsprobe, die Redmond vorgelegt hat. Wieso nutzt das Unternehmen nicht selbst solche Tools zur Code-Analyse? Meine Einschätzung: Der Windows-Rechner ist nicht wichtig, da hat niemand Erfahrenes hingesehen. Der Windows-Rechner wurde imho wohl nach dem Erstellen von Generationen von 'Freshmen' bei Microsoft weiter entwickelt, die dann für solche Kalauer im Code sorgten.

Es stellt sich natürlich die Frage, wie es mit dem Code und dessen Qualität in anderen Modulen ausschaut. Ich bin ja nun schon länger im Geschäft und erinnere mich an eine Episode mit einem Script-Debugger, der von Microsoft zur Jahrtausendwende für das Debuggen von WSH-Scripten benutzt werden konnte. Das Teil hatte unendlich viele Macken und ein deutscher Entwickler, der seinerzeit in den USA lebte, wollte den Debugger überarbeiten. Ich stand mit ihm per Mail in losem Kontakt, weil ich damals Bücher zu Windows Script Host (auch bei Microsoft Press) veröffentlicht hatte. Der gute Mann hatte Zugriff auf den Quellcode des Microsoft Debuggers – schrieb aber am Ende des Tages seinen eigenen Debugger von Grund auf neu. Das Ergebnis war der PrimalScript-Debugger von SAPIEN.