Es ist nich Emba, es ist nicht MS schuld und dies schieben sich nicht gegenseitig den schwarzen Peter zu.
Wenn eine
DLL im Adressraum deiner Anwendung geladen wird und eine Absturz vollführt, dann ist diese
DLL schuld bzw. dann hat der Hersteller der
DLL hier nacharbeit zu leisten.
Falls es dem Hersteller egal ist, so wäre eine Idee das Laden der
DLL zu verhindern (z.B. durch einen Hook auf die LoadLibrary-
WinAPI-Funktion).
Genau das wollte ich eigentlich damit ausdrücken, dass es nicht sein kann dass sich diese zwei den schwarzen Peter zuschieben. Allerdings so ganz aus der Verantwortung will ich Emba auch nicht entlassen. Denn TOpenDialog bildet einen Systemdialog ab, der auch in anderen (Non-Delphi-) Programmen zum Einsatz kommt und dort nicht zu Abstürzen führt.
Genau dann hat man nämlich die Situation, dass die Anwender nur die Wirkung und nicht die Ursache sehen.
Mein Programm stürzt ab, während Programm xyz problemlos mit der selben Shellextension läuft. Also muss der (Anwender-) Logik zufolge
mein Programm Schuld sein und nicht die Shellextension.