Office-PlugIn mit Libre- bzw. Openoffice nutzen?

[milo1012]

Was die Runtimes angeht wird definitiv eine Installation benötigt wenn noch nicht vorhanden.
Seit mindestens Windows 2000 gibt es die Side-by-side-Assemblys (deswegen auch "winsxs"), welche die Runtimes an einem zentralen Ort verwalten und den DLL-Konflikten vorbeugen sollen.
Ich habe noch eine Menge alte Programme die MFC-DLLs benötigen, dort hat ein einfaches kopieren meist gereicht, aber bei den VC-Runtimes scheint das nicht mehr so einfach zu sein.
Auf einem "nackten" Win XP ging es jedenfalls nachweislich nicht ohne Installation.
Bei deinem Win7 hat es nur funktioniert weil die Zertifikate und Registry-Einträge schon vorhanden waren.

Was die Doku angeht habe ich es jetzt auch gefunden...ich hatte die wichtigsten PDFs nur kurz überflogen.
Für mein Verständnis sollte so etwas schon auf der Download-Seite ersichtlich sein, weil es wie gesagt keine Standard-Windows-Komponente ist und zusätzlich geladen werden muss.

Gut, jedenfalls funktioniert es, haken wir das Thema ab

[milo1012]

Da es mich geärgert hat dass das Plugin auf die VC-Runtimes angewiesen ist
habe ich etwas recherchiert und eine Lösung gefunden.
Damit lässt sich das Plugin auch auf "nackten" Systemen und somit auch portabel starten.
Wem die Lösung schon bekannt ist der möge es ignorieren:
Die Idee dazu gibt es z.B. hier und hier.

Auch die VC-Runtimes der Versionen 2005, 2008 und 2010 lassen sich lokal benutzen wenn die
eingebetteten Manifests entsprechend angepasst werden.
Die Lösung:
Für jede benötigte DLL (und jede .flt-Datei!) des Oracle-Pakets entweder mit einem Resource Editor, z.B. XN Resource Editor
(was eine ziemliche Klickerei ist), oder schneller mit binärem Suchen und Ersetzen,
z.B. mit Search and Replace (dann müssen aber die Offsets erhalten bleiben, also ggf. je nach Länge mit Leerzeichen auffüllen)
das eingebettete Manifest ändern in:

Code: Select all

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
	<dependency>
		<dependentAssembly>
		<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42" processorArchitecture="x86">
		</assemblyIdentity>
	</dependentAssembly>
	</dependency>
</assembly>

(Das Entscheidende ist dass der publicKeyToken gelöscht wird und für 64bit muss processorArchitecture in amd64 geändert werden)

Dann erstelle man im DLL-Verzeichnis eine Datei Microsoft.VC80.CRT.manifest
mit Inhalt:

Code: Select all

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
	<noInheritable></noInheritable>
	<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42" processorArchitecture="x86"></assemblyIdentity>
	<file name="msvcr80.dll"></file>
	<file name="msvcp80.dll"></file>
</assembly>

(für 64bit muss processorArchitecture in amd64 geändert werden)
Jetzt braucht man noch die msvcp80.dll und msvcr80.dll in der im Manifest hinterlegten Version.
(die msvcm80.dll wird nicht benötigt)
z.B. hier offz. bei MS:
64bit und 32bit

Man entpacke besagte beide Dateien ins gleiche Verzeichnis und siehe da, es funktioniert ohne installierte System-Runtimes !

Theoretisch liese sich der uLister so sogar auf Windows 2000 starten, nur dummerweise ist
die ulister.wlx mit Visual Studio 2010 kompiliert und benötigt mindestens XP.
Ich habe die Plugin-DLL neu kompiliert und tatsächlich, uLister funktioniert problemlos auch auf Win2000.
Wer Interesse an meiner DLL hat möge sich melden, dann werde ich sie hochladen.

[Native2904]

Vielen Dank- dieser Thread hat mir sehr weitergeholfen.