Category Archives: Operating System

Verzögerter Start eines Dienstes dank MsiServiceConfig Tabelle

June 25, 2009 14:04 ⋅ Leave a Comment ⋅

Ab Microsoft Windows Installer 5.0 kann die MsiServiceConfig Tabelle verwendet werden, um einen Dienst verzögert zu starten.
Der Service Control Manager (SCM) wurde mit dieser Option in Windows Vista erweitert.
Mit der MsiServiceConfig Tabelle können diese neuen Funktionalitäten des SCM für einen Dienst konfiguriert werden.

Einen Dienst verzögert zu starten soll helfen die Zeitspanne eines Systemstartes zu optimieren. Wenn ein Dienst nicht unmittelbar zum Zeitpunkt des System Start benötigt wird, so kann dieser zu einem späteren Zeitpunkt  gestartet werden. Ein Dienst der verzögert gestartet wird, wird innerhalb von 2 Minuten nach dem System Start gestartet. Ein Setup Autor kann nun bei einem Dienst entscheiden, ob dieser sofort zur Verfügung stehen muss, oder ob es sich um einen Dienst einer Anwendung handelt, welcher auch zu einem späteren Zeitpunkt gestartet werden kann.

Der Dienst selber wird wie gewohnt über die ServiceInstall Tabelle installiert und über die ServiceControl Tabelle gestartet, ggf. gestoppt oder gelöscht.

Sollte die MsiServiceConfig Tabelle nicht im Schema der Installation sein, so kann die Tabelle mit Orca 5.0 oder einem Setup Authoring Tool (welches die Windows Installer 5.0 Technologie unterstützt) erstellt werden.

MsiServiceConfig

Die Felder sind für einen verzögerten Start wie folgt auszufüllen:

ServiceConfigure: ist ein Identifier
Name: Name des Dienstes der in der ServiceInstall Tabelle steht, oder der Name eines bereits installierten Dienstes.
Event: 1
ConfigType: 3
Argument: 1
Component_: Name einer Komponente aus der Installation

Der nächste und auch der letzte Punkt ist dem Windows Installer mit der MsiConfigureServices Aktion mitzuteilen, dass ein Service mit den neuen Optionen zu konfigurieren ist.

MsiConfigureServices

Die MsiConfigureServices Aktion wird zwischen der InstallServices und der StartServices gestellt.

Weitere Informationen zu den neuen SCM Funktionen:
http://msdn.microsoft.com/en-us/library/bb203962(VS.85).aspx

Stefan Hotan
Member of the Ontrex SPA Team

Posted in: Operating System, Services

Einfacher Weg zum LocalLow Verzeichnis

May 7, 2009 10:08 ⋅ Leave a Comment ⋅

Mit der Einführung der Integrity Access Level (IL) Funktionalität unter Windows Vista und Windows 7, wurde ein neues Verzeichnis, das LocalLow Verzeichnis eingeführt.

Das LocalLow Verzeichnis wir für Prozesse verwendet, die als Low-Level Prozess ausgeübt werden. In der Regel betrifft dies Prozesse, welche unter dem Internet Explorer Prozess gestartet werden, wie das Apple Quicktime Plugin oder Sun Java Runtime Environment. Diese Prozesse können nur noch Dateien in diesem Ordner schreiben oder modifzieren.

Wird eine Applikation repaketiert, welche in diesem Ordner eine Datei erstellt, dann wird schnell klar, dass der Windows Installer Dienst dieses neue Verzeichnis nicht auflöst. Eigentlich gehört das LocalLow Verzeichnis wie die restlichen ‘Special-Folders’ aufgelöst. Das neue Verzeichnis jedoch ist weder in MSI 4.0, 4.5 noch 5.0 Bestandteil der Directory Tabelle.

Es gibt hierzu eine einfache Lösung, wenn Wise Package Studio 7 SP3 oder höher eingesetzt wird. Ab dieser Version von Wise Package Studio wird mit der CustiomAction WiseSetProfilesFolder das Root-Verzeichnis des aktuellen Benutzers aufgelöst (ebenfalls eine Schwachstelle des Windows Installer Dienstes). Aufbauend auf diesem Verzeichnis (ProfileFolder) kann nun mit zwei Einträgen in die Directory Tabelle das LocalLow Verzeichnis dynamisch aufgelöst werden.

 Das LocalLow Verzeichnis

Stefan Hotan
Member of the Ontrex SPA Team

Posted in: Best Practices, File System

Type 1 Fonts Registration mit Windows Installer

February 27, 2009 16:41 ⋅ Leave a Comment ⋅

Die Windows Installer (MSI) Datei hält eine Font Tabelle für die Installation von Schriften bereit. Diese ermöglicht den manuellen Registrationsprozess für eine Schrift zu automatisieren. Der manuelle Weg ist bestens bekannt, einfach mit drag-and-drop die Schriften-Dateien ins Fonts Verzeichnis verschieben und gut ist.

Wenn man das gleiche mit einer Postscript Schrift (PFM und PFB Datei) durchführt,  so ist dies bei einer manuellen Registration kein Problem. Will man diesen Vorgang jedoch repaketieren, also über das Snap-Shot Verfahren aufzeichnen, so wird die Schriftart erst nach einem Neustart des Rechners ansprechbar.

Der Grund für dieses Verhalten liegt in der Tatsache, dass die Font Tabelle nur für TrueType Schriften (.TTF Dateien) gedacht ist. Diese Tabelle ist nicht mit Postscript Schriften kompatibel.

Der Snap-Shot der Registration wird pro Schriftart einen Registry-Key erstellen:
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionType 1 InstallerType 1 Fonts
Name der Schrift, T[~]<Datei>.PFM[~]<Datei>.PFB
Dieser Eintrag in der Registry ist soweit in Ordnung, nach der Installation ist die Schrift registriert, jedoch nicht aktiviert. Ein Reboot wäre in diesem Fall nötig.

Was aber, wenn man nach der Installation direkt auf die neue Schriftart ohne Reboot zugreiffen will?
Dies ist technisch möglich, benötigt jedoch einen API-Call auf die Datei atmlib.dll, sprich eine Custom Action muss her.

Eine Möglichkeit diesen API-Call durchzuführen ist die verwendung des Wise Script Editors.
Folgender Print-Screen zeigt die benötigte ‘Call DLL function’:

 

wisescript3

Das erste Argument übergibt den Schriften-Namen, der zweite definiert den Schrift-Typ, der dritte und vierter die Schrift. Die benötigten Informationen kann man beim Snap-Shot aus der Registry entnehmen.
Die kompilierte .EXE Datei ist danach im Deferred Context der Installation durchzuführen. Nach der Installation steht die Postscript Schriftart sofort dem Endanwender zur Verfügung.

Die Dateierweiterung PFM steht für Postscript Font Metrich und die PFB Datei steht für Postscript Font Binary. Beide Dateien müssen ins Fonts Verzeichnis kopiert werden, bevor der API-Call durchgeführt wird. Bei Postscript Schriften können auch noch AFM (Adobe Font Metric) und INF (Type I LaserJet font information) beiliegen, welche nicht benötigt, oder einfach mit ins Fonts Verzeichnis kopiert werden können.

Stefan Hotan
Member of the Ontrex SPA Team

Posted in: Fonts, Wise Package Studio

Applikation startet nicht nach .NET Installation

February 17, 2009 18:03 ⋅ Leave a Comment ⋅

Seit im Jahr 2006 das Microsoft .NET Framework 2.0 installierbar ist, können ältere Programme, die mit dem .NET Framework 1.0 oder 1.1 entwickelt wurden, nach der .NET Framework 2.0 installation, auf einmal nicht mehr starten.

Der Grund liegt in der Programmierung selber. Da das .NET Framwork die Side-by-Side Technologie unterstütz, werden Programme in der .NET Version ausgeführt, worin diese entwickelt worden sind. Nach Microsoft Richtlinien, ist der Applikation anzugeben, mit welchem .NET Framework diese ausgeführt werden kann. Leider gibt es fehlbare Applikationen, die diese Information nicht beinhalten (sogenannte Unmanaged Applications) und diese Applikationen bekommen Probleme, sobald eine neuere Version von einem .NET Framework auf den PC installiert wird.

Um dieses Problem zu lösen, empfiehlt es sich, eine aktuelle Version der Applikation zu verwenden. Dieses Problem tritt vorallem bei Applikationen die vor der Veröffentlichung des .NET Framework 2.0 herausgegeben wurden.

Ist keine neuere Version erhältlich, so kann eine .Config Datei erstellt werden, welche dem Betriebsystem angibt, mit welchen .NET Framework die Applikation zu laufen hat.

Beispiel LiveLink 9.5:

Dateiname: alviewer.exe.config
Inhalt der Textdatei:

<configuration>
<startup>
   <supportedRuntime version=”v1.1.4322″ />
   <supportedRuntime version=”v1.0.3705″ />
</startup>
</configuration>

Mit diesem einfachen Trick, lassen sich ältere Unmanaged .NET Applikationen in einer Multi .NET Framework Umgebung betreiben.

Posted in: .NET Framework