user32.dll im speicher verschoben-HHCTRL.OCX belegt speicher

[Olli]

010Editor ebenso. Wurde schon bei MVI gepostet. MS ist also schon seit letzter Woche darueber informiert

Uebrigens scheinen viele der Programme mit einem Borlandlinker gelinkt zu sein. Ein (Foren)Schelm wer dabei Boeses denkt.

[MagicAndre1981]

Zitat von Olli:

Uebrigens scheinen viele der Programme mit einem Borlandlinker gelinkt zu sein. Ein (Foren)Schelm wer dabei Boeses denkt.

[OldGrumpy]

Naja, ob das so Absicht war weiss ich nicht... Die Systemlibs von Windows liegen alle so im Adressraum verteilt, dass keine Relocations notwendig werden, und trotz Pufferbereichen ist der Platz halt nicht grenzenlos gross - und wenn jetzt durch endlose Updates eines der Files zu gross wird, klemmt es dann halt mit dem verfügbaren Platz und Windows verschiebt automatisch die DLL die zu spät kommt an einen freien Platz. Dumm nur dass das bei System-DLLs nicht erlaubt ist (user32.dll nimmt ja eine Sonderrolle ein) - und diese Programme alle ihre DLLs nicht in der gleichen Reihenfolge laden wie Microsoft das erwartet (zuerst die Kernbibliotheken wie z.B. user32.dll)

[Olli]

Zitat von OldGrumpy:

und diese Programme alle ihre DLLs nicht in der gleichen Reihenfolge laden wie Microsoft das erwartet (zuerst die Kernbibliotheken wie z.B. user32.dll)

... sondern in der Reihenfolge in welcher der Linker sie in der Importtabelle auflistet

Kernel32 ist immer direkt nach NTDLL da, weil es ansonsten kein Win32-Prozess ist (NT-Plattform-spezifisch), der Rest ist leider frei. Eine Korrektur im Loader wuerde das ja auch beheben

[OldGrumpy]

Zitat von Olli:

Zitat von OldGrumpy:

und diese Programme alle ihre DLLs nicht in der gleichen Reihenfolge laden wie Microsoft das erwartet (zuerst die Kernbibliotheken wie z.B. user32.dll)

... sondern in der Reihenfolge in welcher der Linker sie in der Importtabelle auflistet

Kernel32 ist immer direkt nach NTDLL da, weil es ansonsten kein Win32-Prozess ist (NT-Plattform-spezifisch), der Rest ist leider frei. Eine Korrektur im Loader wuerde das ja auch beheben

*seufz* Drück ich mich so missverständlich aus? Natuerlich werden die Module in der Reihenfolge geladen wie sie in der IT stehen. Das stell ich ja auch gar nicht in Abrede. Nur hat MS sich wohl dran gewöhnt dass die Kern-DLLs (NTDLL, Kernel32, User32, et.al.) immer zuerst kommen und alle Welt das gefälligst auch so zu machen habe. Dann bekommt man beim Testen ja auch keine Fehler zu sehen Ich halte das nur nicht für eine Attacke auf Borland sondern eher für einen Fall von "dumm gelaufen". Am Loader schrauben wird MS vermutlich nicht, weil damit wieder jede Menge andere CoWs(*) aufgemacht werden, ich denke da vor allem mal in Richtung Kopierschutz und so - da gabs schon wegen wesentlich kleinerer Änderungen durchaus dicke Probleme

Nachtrag:
(*)CoW -> Can of Worms

[Olli]

Nein, hast dich nicht missverstaendlich ausgedrueckt - aber ich. Ich meinte meine Aussage eher scherzhaft, nicht dass MS gezielt Borland attackiert oder so.

Zitat von OldGrumpy:

ich denke da vor allem mal in Richtung Kopierschutz und so - da gabs schon wegen wesentlich kleinerer Änderungen durchaus dicke Probleme

Tja, wer foult muss halt mit sowas rechnen

[kleiner Unwissender]

Ich hab das gleiche Problem (mit der Shell32.dll)
Und zwar immer wenn ich einen Spielepatch installieren möchte!

[Hobby-Programmierer]

Moin ...,
und hier das ofizielle MS Statement

LG Mario

[kleiner Unwissender]

Den Patch hab ich ja schon lange installiert. Wenn ihr aber mal hier her geht seht ihr das es 2 Fehlermeldungen sind, und nur die eine von dem Patch gelöst wird. Die andere hab ich auch erst seid dem ich den Patch hab. (Ja ich hab das BriscoPack instaliert, aber bis dato keine Probleme gehabt und kann jetzt auch Patches nicht mehr installieren, die vorher noch keine Probleme gemacht haben. Deinstallation von BriscoPack hat nix gebracht)