PureBoard

Verfasst: **13.01.2009 14:47**

Kaeru Gaman hat geschrieben:ähm...

bekomm ich jetzt von Microsoft nen Gehaltsscheck, oder warum bekomme ich hier Bugmeldungen der Windows7-Beta gepostet?

oppala??

Willkommen im Entwicklerteam!

Verfasst: **13.01.2009 16:23**

Ihr habt beide recht! Aber..

Code: Alles auswählen

Text1 = @"HaHa"

..das heißt noch lange nicht das Text1 ein String ist, für mich ist es eine Variable (Long) mit einem Pointer zu X (unbekannt).
PureBasic sieht das auch so und behandelt es dem entsprechend.

Wird nun die String Funktion CompareMemoryString darauf angewendet sichert sich PB mit einem MaxCount ab.
Der Punkt zu dem maximal gesucht wird um eine Null Terminierung zu finden.

Und nun kommen wir zum Bug.
PB nutzt die MSVCRT.DLL, diese unterscheidet sich aber von XP zu VISTA und WIN7.
(Ich habe den Fehler unter VISTA und WIN7)

Und hier liegt der Hund begraben, ein Versionskonflikt.

Code: Alles auswählen

mov     eax, offset Str ; "HaHa"
mov     Str1, eax
mov     edx, offset Str ; "HaHa"
lea     ecx, Str2       ; int
call    sub_402008
push    0FFFF0001h      ; MaxCount
push    1               ; int
mov     eax, Str2
push    eax             ; Str2
push    Str1            ; Str1
call    sub_402390

PB gibt einen MaxCount von 4294901761 byte an (ffff0001h, ca 4GB),
die MSVCRT.DLL:strnicmp unter VISTA/WIN7 steigt aber bei 2147483647 byte (7fffffffh, 2GiB) aus.
Der Return entspricht also keinem Ergebnis sondern einer Fehlermeldung.

Bei 2GB ist bei der MSVCRT.dll (unter Vista/Win7) also Schluss,
evlt. ist diese Limitierung auch nur in der x64 Version zu finden?!
Sollte in der nächste PB Version unbedingt verbessert werden.

Und nun gib mal jemand Fred bescheid. ^^

Verfasst: **13.01.2009 17:05**

Ich würde auch darum bitten den Thread wieder in die Bug - Section zu verschieben, da es nun anscheinend sehr sicher ein PB Bug ist.

Verfasst: **13.01.2009 17:42**

Nachtrag:

Hab mir das jetzt noch mit PBx64 unter VISTAx64 angesehen.
Das Limit von 2GiB ist hier ebenfalls vorhanden und macht keinen unterschied zwischen x86 und x64 Mode.
In dem Fall sollte man auch unabhängig ob PB x86 oder x64 dieses bei beiden von 0FFFF0001h auf 07FFFFFFh korrigieren,
bzw. von 0FFFFFFFFFFFF0001h auf 0000000007FFFFFFFh. (x64)

Verfasst: **13.01.2009 17:45**

K, sieht echt nach nem PB Bug aus, hab jetzt auch mit Win 7 64 getestet, selber Fehler. Könnte das bitte jemand im Englischen Forum melden der msschlt's Erklärung in verständliches Englisch übersetzen kann?

Verfasst: **13.01.2009 19:06**

Mein English ist eher schlecht, dennoch hab ich den Bug mal grob im englischen Forum beschrieben.

Verfasst: **13.01.2009 19:14**

msschlt hat geschrieben:Mein English ist eher schlecht, dennoch hab ich den Bug mal grob im englischen Forum beschrieben.

Wenn Ihr schon undokumentierte Features als Bug meldet, dann bitte mit
korrektem Beispielsource. Schon wieder ein #PB_Ignore

Mach da mal ein -1 oder meinetwegen #PB_Default, #PB_Any draus, ansonsten wirds wohl keiner beachten.

Verfasst: **13.01.2009 19:17**

@ts-soft
Ja ist mir auch gerade aufgefallen und habe es korrigiert. xD

Verfasst: **14.01.2009 00:40**

@ts-soft:

Wobei, naja was heißt undokumentierte Features?

Code: Alles auswählen

Text1.s = "BUG"
Text2.s = "BUG"

Debug CompareMemoryString(@Text1, @Text2, #PB_String_NoCase, -1, #PB_Ascii)

Das ist doch ganz nach Handbuch oder seh ich das falsch?
Ich weiß die Länge nicht, setze das ASCII Flag und -1.
Würde auch funktionieren wenn PB intern ein max. Count von 2GiB setzen würde.

Verfasst: **14.01.2009 00:47**

Wenns mit korrekter (dokumentierter) Syntax passiert, dann ist es wohl ein
Bild

Hier im Thread wurde ja erst der Fehler falsch beschrieben, dann falsch Syntax angewendet usw.

Das sich zum Schluß doch noch ein Fehler herauskristallisiert ist ja mehr
Zufall

Passiert nur im ASCII-Modus.

PureBoard

Windows 7 x86 - CompareMemoryString Bug