.NET und PDF Software

Beim Ausführen einer Powershell-Datei erhielt ich im Protokoll neulich folgende bekannte Fehlermeldung, obwohl Set-ExecutionPolicy auf RemoteSigned gesetzt war:

Die Datei "...test.ps1" kann nicht geladen werden, da die Ausführung
 von Skripts auf diesem System deaktiviert ist. Weitere
 Informationen erhalten Sie mit "get-help about_signing".
Bei Zeile:1 Zeichen:2
+ . <<<<  '...test.ps1'
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

Die Lösung lag letztendlich darin, dass das entsprechende Skript auf einem 64Bit-System als 32Bit-Task aufgerufen wurde. Es war ausreichend, Set-ExecutionPolicy unter Powershell (x86) ebenfalls aufzurufen und entsprechend zu setzen.

Bezüglich der Verarbeitung von Komma-Werten habe ich heute wieder einge Erkenntnisse gewonnen, die teilweise auch aus der verbesserten Dokumentation vom Microsoft.NET Framework 4 her rührten. Dort ist unter anderem zum Typ Double folgendes zu lesen:

Bei Verwendung einer Gleitkommazahl könnte ein Wert möglicherweise nicht wiederhergestellt werden.

Das Problem verdeutlicht folgendes gekürztes Beispiel aus der MSDN:

double fromLiteral = -4.42330604244772E-305;
double fromParse = Double.Parse("-4.42330604244772E-305");
 
Console.WriteLine("Double value from literal: {0,29:R}", fromLiteral);
Console.WriteLine("Double value from Parse method: {0,24:R}", fromParse);
 
// On 32-bit versions of the .NET Framework, the output is:
//    Double value from literal:        -4.42330604244772E-305
//    Double value from Parse method:   -4.42330604244772E-305
//
// On other versions of the .NET Framework, the output is:
//    Double value from literal:      -4.4233060424477198E-305
//    Double value from Parse method:   -4.42330604244772E-305

Das die hinteren Stellen einer Double-Zahl Ungenauigkeiten unterliegen, war mir schon länger klar. Das der selbe Code auf verschiedenen Systemen aber andere Genauigkeiten erzielen kann, war eine neue Erkenntnis, die bis dato nur als ungeäußerte und nicht beweisbare Vermutung im Raum stand.

Um das Problem zu umgehen, habe ich zwei Extensions für mich geschrieben:

public static bool NearZero(this double value)
{
    return Math.Abs(value) < 1e-12;
}
public static bool NearValue(this double value, double compareValue)
{
    if (value.NearZero() && compareValue.NearZero()) return true;
 
    return Math.Abs(value - compareValue) < 
        Math.Min(Math.Abs(value), Math.Abs(compareValue)) * 1e-12;
}

Mit der ersten prüfe ich auf 12 Stellen hinter dem Komma, ob die Zahl fast Null ist. Mit der zweiten Methode kann ich simple 2 Werte auf annähernde Gleichheit überprüfen.

Windows 64 Bit setzt sich in Zeiten fallender RAM-Preise immer mehr durch, als Vista64. Bei dem Zugriff auf die Registry stolpert man dabei aber über ungeahnte Probleme.

32Bit Programme legen Ihre Einträge nämlich nicht in der normalen Registry ab, sondern im Unterschlüssel Wow6432Node (wird von Windows umgeleitet):

Was bedeutet das für eigene Programme:
Möchte man von einem 64-Bit Programm aus auf Einstellungen eines 32-Bit Programms zugreifen, ist der Unterschlüssel Wow6432Node zu öffnen. Will man von einem 32-Bit Programm Einstellungen eines 64-Bit Programms auslesen, so steht man vor einem Problem. Will man auf die 64-Bit Schlüssel zugreifen, so muss man die Registry mit speziellen Parametern öffnen. Für Delphi findet man eine Lösung in Delphi-PRAXIS. Für .NET ist die Sache erstaunlicherweise komplizierter.