Webkit.dll

[Hermie]

Sorry, eine Rückfrage:

Ich registriere die Webkit.dll.
Auf manchen Computer bekomme ich den Fehler, dass das Registrieren
fehlgeschlagen ist, auf manchen nicht.

Deshalb meine Frage: Muss man die überhaupt registrieren?

Viele Grüße,
Hermann

[Schmidt]

Am 23.05.2012 13:22, schrieb Hermie:
> Sorry, eine R�ckfrage:

>
> Ich registriere die Webkit.dll.
> Auf manchen Computer bekomme ich den Fehler, dass das Registrieren
> fehlgeschlagen ist, auf manchen nicht.
>

> Deshalb meine Frage: Muss man die �berhaupt registrieren?

Nein, muss man nicht.
Das einzige was beim RC4 zu registrieren w�re, ist die
vbRichClient4.dll (und falls eingesetzt, die vbWidgets.dll)
Und selbst das k�nnte man sich sparen, falls man regfree
(wie k�rzlich in der "dnp-Contest-Demo" gezeigt) per
DiretCOM.dll arbeitet.

Wer die WebKit-Browser-libs zusammen mit den RC4-
Basislibs einsetzt, muss eigentlich nur sicherstellen,
dass der optionale Ordner \WebKitCairo\ m�glichst an die
selbe Stelle platziert wird, an der sich auch vbRichClient4.dll
(und die anderen 2 Basis-Dlls) befinden.
Wird dieser WebKitCairo-Ordner nicht neben vbRichClient4.dll
platziert, laufen bestimmte Helfer-Automatismen beim Anwerfen
ins Leere, so dass man in diesem Falle in seiner App die von Ulrich
schon angesprochene cWebKit.InitWebKitDll Methode (einmalig beim
Aufstarten des Programms) mit der entspr. Pfadangabe aufrufen muss.
(in dieser Methode passiert u.a. das regfree Laden der eigentlichen
WebKit.dll).


Olaf

[Hermie]

Hallo Olaf,

danke.

Kannst Du bitte noch erklären, was Du meinst mit...

> Wer die WebKit-Browser-libs zusammen mit den RC4-
> Basislibs einsetzt, muss eigentlich nur sicherstellen,

> dass der optionale Ordner \WebKitCairo\ möglichst an die

> selbe Stelle platziert wird, an der sich auch vbRichClient4.dll
> (und die anderen 2 Basis-Dlls) befinden.

Ich habe die vbRichClient4.dll und vbWidgets.dll in den App.Path-Ordner
gemacht.
Im App.Path-Ordner befindet sich dann der Ordner WebKitCairo.
Die 2 dll's sind also eine Ebene "davor".

Es sieht also ungefähr so aus:

MeinProgramm\vbRichClient4.dll
MeinProgramm\vbWidgets.dll
MeinProgramm\WebKitCairo\

Bisher gab es damit keine Probleme. War das Zufall und soll ich die 2
dlls besser in den WebKitCairo-Ordner machen?

Viele Grüße,
Hermann

[Hermie]

Okay, jetzt bin ich doch grade mit meinem Latein am Ende.
Ich wollte es gerne erstmal ohne regfree machen.

Ich habe jetzt, weil ich kein Risiko eingehen wollte, alles, was mit
WebKit zu tun hat, in den Ordner

c:\Program Files(x86)\MeinProgramm\WebKitCairo gemacht.

Jetzt sagt er mir aber wieder
"WebKit.dll not loaded, please call InitWebkitDll beforehand (with the
correct path)."

ProcMon sagt mir, dass er WebKit.dll in
c:\Program Files(x86)\MeinProgramm\WebKitCairo\WebKitCairo\WebKit.dll"
sucht.

Gibt es eine exemplarische Vorgehensweise für die Verwendung ohne den
regfree-Ansatz, also eine Anleitung, was man wohin kopieren sollte?

Viele Grüße,
Hermann

[W. Wolf]

Am 24.05.2012 10:17, schrieb Hermie:

[...]

>
> ProcMon sagt mir, dass er WebKit.dll in
> c:\Program Files(x86)\MeinProgramm\WebKitCairo\WebKitCairo\WebKit.dll"
> sucht.
>

Ist das wirklich so: ..\WebKitCairo\WebKitCairo\.. ?

Welches BS verwendest Du? Welcher IE ist hier installiert? Gibt es auf
dem Rechner ein Office?

Der interne Aufruf vom WebKit ist immer regfree, egal ob Du nun die
vbRichClient4.dll registrierst oder nicht. Bei der WebKit-Instanzierung
hast du das schon versucht?

If WebKit Is Nothing Then
Set WebKit = New_c.WebKit(True, App.Path & "\WebKitCairo\")
end if

Schönen Gruß
W. Wolf

[Schmidt]

Am 24.05.2012 06:38, schrieb Hermie:

> Kannst Du bitte noch erklären, was Du meinst mit...
>
>> Wer die WebKit-Browser-libs zusammen mit den RC4-
>> Basislibs einsetzt, muss eigentlich nur sicherstellen,
>> dass der optionale Ordner \WebKitCairo\ möglichst an die
>> selbe Stelle platziert wird, an der sich auch vbRichClient4.dll
>> (und die anderen 2 Basis-Dlls) befinden.

Also für reinen RC4-Betrieb (ohne WebKit), gehören die
3 Basis-Dlls immer zusammen (in einen Ordner auf der Dev-
Maschine - bzw. später auch in einem "Destination-Ordner"
den das Setup-Programm vorgibt ... oder halt (wenn
regfree benutzt) auch gemeinsam in den App.Path.

Diese 3 Dlls sind:
vbRichClient4.dll <--- nur die ist zu registrieren
vb_cairo_sqlite.dll
DirectCOM.dll

> Ich habe die vbRichClient4.dll und vbWidgets.dll in den
> App.Path-Ordner gemacht.

Ok (bzgl. der vbWidgets.dll, die ebenfalls registriert sein will)...

> Im App.Path-Ordner befindet sich dann der Ordner WebKitCairo.
> Die 2 dll's sind also eine Ebene "davor".

Auch das ist korrekt - die Webkit-libraries sind
ja optional - und "der Ordnung halber" (und um's
simpel zu halten) sitzen diese Zusatz-Dlls in ihrem
eigenen Folder, den man dann entweder dazutun kann
(neben die Basis-Dlls), oder halt komplett weglässt.
Also dieser WebKitCairo-Folder ist mehr oder weniger als
"Blob" gedacht - nix zu registrieren *innerhalb* dieses
Folders (Webkit.dll offeriert zwar COM-Klassen, die werden
aber aus RC4-cWebKit regfree geladen).

Und wenn ich schreibe "optional den WebKitCairo-Folder
neben vbRichClient4.dll platzieren"... dann meine
ich das genau so - und nicht etwa "den *Inhalt* dieses
Folders neben vbRichClient4.dll platzieren".

> Es sieht also ungefähr so aus:
>
> MeinProgramm\vbRichClient4.dll
> MeinProgramm\vbWidgets.dll
> MeinProgramm\WebKitCairo\

So isses gedacht (hinsichtlich WebKitCairo-Folder)...
Was fehlt (neben vbRichClient4.dll) sind die 2 anderen
BaseDlls (vb_cairo_sqlite.dll, DirectCOM.dll).

> Bisher gab es damit keine Probleme. War das Zufall und soll
> ich die 2 dlls besser in den WebKitCairo-Ordner machen?

Nein, so wie das da oben steht, sieht es eigentlich
"so aus, wie es soll".

Was vor allem auf (potentiell "ungepflegten") XP-Installationen
noch sein könnte ist, dass die WebKit-libraries sämtlich
noch von der MS-VC2008 (C/C++)-Runtime (Version 9) abhängen:
>
http://www.microsoft.com/downloads/de-de/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF

Diese VC-Runtime "mittleren Alters" kommt auf Vista und
Win7 bereits vorinstalliert, ist aber (glaube ich)
bei XP erst ab XP/SP3 mit im Boot - oder kommt mit neueren
IE8-für-XP-Installationen - oder auch im Setup neuerer
MS-Office-Versionen (nach 2008).

Also falls Deine "Problem-Maschinen" relativ jungfräuliche
XP-Installationen sind (möglicherweise mit einem XP/SP < 3),
dann die VC-Runtime aus obigem Link nachinstallieren.

Ansonsten (falls vb_cairo_sqlite.dll und DirectCOM.dll
*nicht* neben vbRichClient4.dll sitzen), könnte auch dies
das Problem sein - die WebKit.dll hat eine Abhängigkeit
zu SQLite (für das lokale, über JS aufrufbare WebSQL-Feature),
normalerweise ist das "statisch eingelinkt"... in meinem WebKit.dll-
Kompilat habe ich das jedoch über eine externe Dll-Referenz
auf vb_cairo_sqlite.dll sichergestellt, um die WebKit.dll
"leichter" zu machen für's Deployment.

In einem Inno-Setup (mit gesetzter LZMA-Compression-Option)
tragen die 3 RC4-BaseDlls nur mit ca. 1.5MB auf - und der
optionale WebkitCairo-Folder mit seinen WebKit-libs dann mit
nochmals zusätzlichen ca. 3.5MB (was für eine moderne, mit
der Anwendung distributierbare Browser-Engine heutzutage
relativ klein ist).

Olaf

[Hermie]

Hi Olaf, hi Wolfgang,

ich denke mal, das Problem war, dass ich die DirectCOM.dll immer nur in
den System-Ordner mache und dass ich nur gesagt habe:
If NewWebKitInstance Is Nothing Then Set NewWebKitInstance = New_c.WebKit
(also ohne Pfad-Angaben)

Ich war davon ausgegangen, dass DirectCom schon gefunden wird, wenn es
im System-Ordner ist.
Ich musste DirectCom.dll aber noch in den WebKitCairo-Ordner machen.

Ich liste mal der Übersicht halber mein Setup:

C:\Program Files (x86)\MeinProgramm\vb_cairo_sqlite.dll
C:\Program Files (x86)\MeinProgramm\vbRichClient4.dll
C:\Program Files (x86)\MeinProgramm\webkitbrowser.ocx (Da habe ich den
Browser untergebracht, um ihn schön zu kapseln)
C:\Program Files (x86)\MeinProgramm\WebKitCairo
C:\Program Files (x86)\MeinProgramm\WebKitCairo\WebKit.dll

Das habe ich jetzt einfach mal in Panik ausprobiert, weil ich meine
Anwendung schnell updaten musste, damit sich keiner beschwert.
Ansonsten hätte ich es auch lieber ordentlich gemacht, mit RegFree und
mit Nachdenken darüber, warum was nicht geht.

Was mich aber echt verwirrt:
Warum klappt das Registrieren von WebKit.dll auf manchen Computern mit
erfolgreicher Rückmeldung überhaupt? Ich tue es jetzt nicht mehr, aber
hat mich doch gewundert.

Ich werde das am Wochenende nochmal in Ruhe alles prüfen.
Danke für die Erklärungen.

Liebe Grüße,
Hermann

[Schmidt]

Am 24.05.2012 14:43, schrieb Hermie:

> Ich war davon ausgegangen, dass DirectCom schon gefunden wird,
> wenn es im System-Ordner ist.
> Ich musste DirectCom.dll aber noch in den WebKitCairo-Ordner machen.

Das wundert mich etwas, da es dort eigentlich wenig Sinn macht.
Wenn, dann gehört es einen Ordner höher (neben vbRichClient4.dll).

> Ich liste mal der Übersicht halber mein Setup:
>
> C:\Program Files (x86)\MeinProgramm\vb_cairo_sqlite.dll
> C:\Program Files (x86)\MeinProgramm\vbRichClient4.dll
> C:\Program Files (x86)\MeinProgramm\webkitbrowser.ocx (Da habe ich den
> Browser untergebracht, um ihn schön zu kapseln)
> C:\Program Files (x86)\MeinProgramm\WebKitCairo
> C:\Program Files (x86)\MeinProgramm\WebKitCairo\WebKit.dll

Das sollte (jetzt nochmal komplett) eigentlich so aussehen:
\MeinProgramm\Meine.exe

\MeinProgramm\vbRichClient4.dll <-- zu registrieren
\MeinProgramm\vb_cairo_sqlite.dll
\MeinProgramm\DirectCOM.dll

\MeinProgramm\vbWidgets.dll <-- zu registrieren
\MeinProgramm\webkitbrowser.ocx <-- zu registrieren

\MeinProgramm\WebKitCairo\

Letzte Zeile oben (der WebKitCairo-Folder)
hoffentlich mit seinem kompletten Inhalt,
(nicht nur mit der Webkit.dll) - also insgesamt
genau 9 Dlls sollten dort enthalten sein, ebenso
wie der SubFolder \WebKit.resources\.

Das einzige was unterhalb des Ordners WebKitCairo
weggelassen werden darf, ist der \inspector\
Folder, welcher unterhalb \WebKit.resources\
sitzt. Das spart dann nochmal ca. ein halbes MB
(komprimiertes) Volumen - die LZMA-compression
des Ordners \WebKitCairo\ *ohne* den \inspector\
Folder beläuft sich dann auf nur noch rund 3MB.
Der Inspector ist das Dingen was aufpoppt, wenn
man auf einem bestimmten Element der WebSeite
"Inspect Element" aus dem Kontextmenü benutzt -
eigentlich nur für Entwickler interessant.

> Was mich aber echt verwirrt:
> Warum klappt das Registrieren von WebKit.dll auf manchen
> Computern mit erfolgreicher Rückmeldung überhaupt?

Weil Webkit.dll neben all den anderen "normalen Dll-Exports"
auch eine Function 'DllRegisterServer' offeriert (für
die Registrierung der COM-Interfaces welche die Webkit.dll
parallel zur normalen C++ Schnittstelle zusätzlich bereitstellt).

Also dass Regsvr32 Erfolg hat, ist eigentlich der Normalfall -
(wenn auch in diesem Falle unnötig). Dass es auf manchen
Maschinen nicht klappt, könnte an der schon beschriebenen
Dependency zu den MS-VC-2008 Runtime-Files liegen, die dann
ein erfolgreiches LoadLibrary verhindern (in dem Falle würde
LoadLibrary dann intern forciert von regsvr32.exe, um
letztlich den DllRegisterServer-call anspringen zu können).

Olaf

[Hermie]

Hi Olaf,

danke für die Erklärung (vor allem bezüglich der RegSvr32-Sache).
Danke auch, dass Du mich nicht zur Schnecke gemacht hast, weil ich da so
"rumwurschtele" ohne ein Konzept.

Liebe Grüße,
Hermann