Tweet
Hallo,<br><br>unter Windows 98 (erste Ausgabe) habe ich das Problem, dass ich keine COM-Objekte (DLL's) registrieren kann,<br>wenn die Daten auf einem Netzlaufwerk liegen. Die DLL's wurden mit Delphi 7 Prof. compiliert.<br>Diese Dateien wurden früher mit Delphi 5 Ent. compiliert und da gab es noch keine Probleme.<br><br>Hat jemand eine Idee, wie man die Dateien unter Win98 registriert bekommt?<br><br>Vielen Dank bereits im vorhinein<br>Stephan H.
-
-
Das Problem tritt unter Win98/ME auf, wenn die Dateien auf einem Netzlaufwerk (gemappt oder UNC) liegen. Der InstallShield kann aber noch nicht mal diese Dateien registrieren, wenn ein lokales Verzeichnis über SUBST als Laufwerk verfügbar gemacht wurde.<br><br>Das Problem tritt bereits bei <b>LoadLibrary</b> auf, hier passiert einfach nichts mehr. Es macht keinen Unterschied, ob die COM-Objekte Runtime-Packages verwenden oder nicht. Eine DLL, die kein COM-Objekt ist, kann ganz normal in den Speicher geladen werden.<br><br>Hat jemand bereits eine ähnliche Erfahrung gemacht oder kennt vielleicht eine Lösung für mein Problem?<br><br>Grüße Stephan H -
Ja.
Das registrieren von COM-ActiveX-Objecten von einem Netzwerklaufwerk ist immer problematisch bezüglich der durch Windows vorgegebenen Sicherheitsrichtlinien. (Kein Remote-Aufruf möglich, aufruf under nicht Admin-Konto nicht möglich, ...)<br>
Und diese sind über die Zeit aufgrund diverser ausnützbarer Sicherheitslücken immer strenger gewordenComment
-
Bisher gab es mit dieser vorgehensweise keine Probleme, hierbei handelt es sich ja eigentlich nicht um einen Remote-Aufruf, da die COM-Objekte auf dem lokalen Rechner ausgeführt werden/werden sollen, mit anderen Worten handelt es sich bei diesen COM-Objekten <u>nicht um DCOM- oder COM+- Objekte</u>, die auf einem entfernten Rechner ausgeführt werden sollen.<br>Es sollte aber dennoch eigentlich nichts im Wege stehen, dass die DLL zumindest über LoadLibrary geladen werden kann, dass das Registrieren Admin-Rechte benötigt ist schon klar, LoadLibrary funktioniert schon nicht und daher kommt es gar nicht soweit, dass die Adresse zum Registrieren aufgerufen wird.<br><br>Heute morgen habe ich ein kleines COM-Object (auch eine DLL) a) unter Delphi 7 Prof. und b) unter Delphi 5 Ent. kompiliert. Die D5-Datei kann registriert werden und die D7-Datei nicht. Was ist an den Dateien unterschiedlichComment
-
Hallo,
>Was ist an den Dateien unterschiedlich?
für das Verhalten beim Registrieren ist die jeweils zuständige <b>Class Factory</b> verantwortlich. Im Fall eines Automation-Objekts ist das <b>TAutoObjectFactory</b> (siehe <b>Initialization</b>-Abschnitt der Objekt-Unit). Man könnte nun im Source-Verzeichnis von Delphi 5 und 7 nachsehen, ob sich die eingebundene Class Factory in der Implementierung unterscheidet. Weiterhin könnte man beide Typbibliotheken in der IDL-Syntax miteinander vergleichen, ob dort andere Attribute gesetzt werden.
>..LoadLibrary funktioniert schon nicht..
Was liefert ein nachfolgender Aufruf von <b>GetLastError</b> zurück?

Comment
-
Die COM-Objekte werden auf dem lokalen Rechnern ausgeführt und <u>nicht als DCOM- oder COM+-Objekte</u>. Diese Dateien befinden sich doch nur auf einem Fileserver, welcher sonst nicht verwendet wird. Mit einem Domänen-Admin funktioniert es ebenfalls nicht, unter NT4/W2K funktioniert es mit lokalen Admin-RechtenComment
-
Hallo Herr Kosch,<br><br>leider wird LoadLibrary nicht abgearbeitet, die Anwendung bleibt einfach nur stehen (wie bei einer Endlosschleife).<br><br>Die IDL's unterscheiden sich an 2 Stellen:<br>- Bei der D7-IDL fehlt: importlib("STDVCL40.DLL");<br>- An einer Stelle eine andere Schreibweise, bei D5 auf 3 Zeilen verteilt und bei D7 in 1.<br><br>Ich werde mal die TAutoObjectFactory-Classen vergleichenComment
-
Hallo,
>..leider wird LoadLibrary nicht abgearbeitet..
passiert dies auch, wenn eine Minimal-Anwendung nur LoadLibrary aufruft? Wenn ja, tritt der Effekt auch auf, wenn <b>LoadLibraryEx</b> mit dem Flag <b>LOAD_IGNORE_CODE_AUTHZ_LEVEL</b> oder <b>LOAD_LIBRARY_AS_DATAFILE</b> (siehe Hilfeseite LoadLibraryEx in der MS Platform SDK-Hilfe) aufgerufen wird?
Es gibt da einen RTL-Bug (wenn ich mich richtig erinnere), der u.U. dafür sorgt, dass der DLLHandler in der DLL nicht korrekt auf DLL_Thread_Attach, DLL_Thread_Detach und DLL_Process_Detach reagiert. Beim Laden als Ressource sollte dies aber keine Rolle spielen.

Comment
-
Hallo,<br><br>LoadLibraryEx gibt mit dem Parameter LOAD_LIBRARY_AS_DATAFILE gibt 0 zurück und GetLastError liefert leider ebenfalls 0.<br>Bei den anderen Parametermöglichkeiten bleibt die Anwendung auch stehenComment
-
Vielen Dank für Ihre Antworten,<br><br>da ich hierfür keine Lösung sehe, werden die COM-Objekte unter Win98/ME lokal installiert und registriert.<br><br>Stephan HComment
-
Info Laut Borland wurde dieser Fehler mit dem Update Pack 1 für Delphi7 behoben. (Keine Gewährleistung, da ich es selber nicht getestet habeComment
Comment