Unicode, seit jahrzehnten. (2009)
Ein Char ist nun 2 Byte groß.
Man könnte jetzt einfach und billig alle Char/String gegen AnsiChar/AnsiString erstzen
oder muß überall mal prüfen, dass die Größen passen.
z.B.
Zitat:
Delphi-Quellcode:
function MD5String(M: string): MD5Digest;
var
Context: MD5Context;
begin
MD5Init(Context);
MD5Update(Context, pChar(M), length(M));
MD5Final(Context, Result);
end;
A) Hier wird jetzt ein anderer Hash berechnet, denn der UnicodeString hat andere Bytes, als wie früher der gleiche AnsiString
B) Und hier wird der Hash falsch berechnet, da nur die erste Hälfte der Bytes des String verrechnet werden -> Lösung:
Length(M) * SizeOf(Char)
C) Wenigstens "knallt" es hier nicht, da nur gelesen wird, und zwar weniger als Vorhanden ist. Würde dagen nun z.B. ein UnicodeString komplett in einen nun halb so großen
ANSI-Speicherplatz geschrieben, dann hast hinten einen wunderschönen
Buffer-Overflow.
D) InlineAssembler funktioniert auch nur in
Win32. Für Win64 oder gar andere Platformen ist diese
Unit somit auch nichts. (Assembler geht, aber nur als komplette Funktion)
E) Abgesehn davon, dass es MD5 auch schon ferig überall im Delphi versteckt gibt und man es nicht mehr selbst machen muß.
Das Beispiel beim MD5 war nur als Erstes aufgefallen ... davon gibt es bestimmt überall noch viel mehr, überall in dieser
Unit.
Weiteres Beispiel: CHAR im TIdSector ist definitiv falsch, denn nur weil Delphi jetzt anders arbeitet, hat sich der Record im Windows nicht geändert, also der ist und bleibt immernoch
ANSI.
Ach ja, hier wird auch das "gemessene" CPU-Tempo eingerechnet.
* erstmal sind CPUs/Kerne schon seit ewig dynamisch getaktet, also verändern ständig den Takt, je nach Auslastung
* dann ist die Messung mit Sleep nicht sehr genau
* 500ms ist schon recht lang und es könnte glatt sein, dass auf einem Kern die Messung begonnen wird und auf einem Anderen beendet.
* * zum Glück arbeitet der TimeStampCounter (RdTSC) nicht mehr mit dem echten Takt der Kerne, sondern bei den meisten CPUs nur noch virtell mit dem selben Zähler (eigenem Takt) neben allen Kernen, so dass es nicht auffällt, dass hier die Messung nicht auf einen Kern begrenzt wurde
Dieses GetHardwareID würde schon alleine deswegen bei jedem Aufruf ein anderes Ergebnis liefern und würde somit doch eh nichts Brauchbares liefern?
[EDIT]
Warum wird überhaupt der CPUSpeed gemessen, wenn er nirgendwo verwendet wird?
Da wird massenhaft sinnlos Zeugs bestimmt/ausgelesen/gemessen,
dann sind diese Variablen nichtmal öffentlich (nur im Implementation)
und sie werden auch nicht in
result:=MD5Print(MD5String(CPUID+HDDManufactur+HDDSerialno+Winproductid));
verwendet.
Und HDDManufactur/GetIdeSerialNumber wird auch nur etwas "vernünftiges" liefern, wenn das Programm als Admin läuft, da sonst der direkte Zugriff auf die Festplatte zurecht verboten ist. (aber egal, weil wenn nicht als Admin ausgeführt, arbeitet das eh nicht)
Tipp: Via
WMI kommst auch an all diese Infos.
Such dir dort ein paar passende Werte raus. Darüber dann ein Hash gebildet (mit einer der Hashfunktionen im Delphi), damit wirst bestimmt mehr/länger Freude haben.