Auswirkungen von 32-Bit Programmen unter 64-Bit Betriebssystemen


Ein Kunde hat einen Brother PTouch Labeldrucker. Nach dem Umzug auf Windows 8.1 lief die zugehörige Software nicht mehr. Um dem Problem auf die Spur zu kommen war prinzipiell eine Aktualisierung der Client PTouch Software notwendig. Beim Testen zeigten sich aber die typischen Probleme bei Verwendung von 32-Bit Programmen unter 64-Bit Windows-Betriebssystemen. Deshalb hier mal exemplarisch was man machen kann und vor allem, wie sich die Probleme äußern.

Generell bietet es sich an, wenn man Problemen auf den Grund gehen möchte, eine Eingabeaufforderung zu öffnen. Jetzt muss man aber wissen, dass man unter einem 64-Bit Betriebssystem unter Windows normalerweise auch die 64-Bit CMD.EXE erhält. In der Regel klappt damit alles problemlos aber bei bestimmten Dingen provoziert man dadurch auf einmal ein anderes Verhalten.

So hatten wir ein Testskript in VBScript geschrieben, welches einfach nachvollziehbar ein Objekt erzeugen sollte. Der betreffende Eintrag lautete:

Set objDoc=CreateObject("bpac.Document")

als Fehlermeldung gab es aber immer

C:\Temp\TestDruckDirekt.VBS(10, 1) Laufzeitfehler in Microsoft VBScript:
ActiveX-Komponenten kann kein Objekt erstellen: ‚bpac.Document‘

Blöd sowas, aber wer verwendet noch VBScript? Also Powershell aufgerufen und da gibt es was ähnliches:

$c=new-object -ComObject "bpac.Document"
new-object : Die COM-Klassenfactory für die Komponente mit CLSID
{B940C105-7F01-46FE-BF41-E040B9BDA83D} konnte aufgrund des folgenden Fehlers
nicht abgerufen werden: 80040154 Klasse nicht registriert (Ausnahme von
HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
In Zeile:1 Zeichen:4
+ $c=new-object -ComObject "bpac.Document"
+    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [New-Object], COMExcept
   ion
    + FullyQualifiedErrorId : NoCOMClassIdentified,Microsoft.PowerShell.Comman
   ds.NewObjectCommand

Zwar ausführlicher aber im Prinzip die gleiche Meldung wie bei VBScript. Solche Geschichten sind immer irgendwie doof.

Da man aber in Powershell mehr Möglichkeiten hat, bietet sich z. B. dieses an: https://newyear2006.wordpress.com/2012/06/20/prfen-ob-eine-powershell-sitzung-in-einer-32bit-oder-64bit-prozess-umgebung-luft/. Damit kann man ganz einfach sehen, ob man unter einem 32-Bit oder 64-Bit Prozess läuft.

[System.IntPtr]::Size
8

Aha, also 8, d.h. die aktuelle Eingabeaufforderung ist unter 64-Bit unterwegs. Also nochmal denselben Test gemacht, nachdem mit

START C:\Windows\SysWOW64\CMD.EXE

eine neue Eingabeaufforderung explizit als 32-Bit Prozess gestartet wurde. Dort brachte dann die Überprüfung mittels Powershell die 4 für einen 32-Bit Prozess als Ergebnis.

Wenn man nun unter dieser Shell das Testscript.VBS aufruft, läuft alles.

Hat man Batchdateien in diesem Zusammenhang laufen, dann kann man die Umgebungsvariablen PROCESSOR_ARCHITECTURE und PROCESSOR_ARCHITEW6432 abfragen. Speziell wenn die Umgebungsvariable PROCESSOR_ARCHITEW6432 vorhanden ist, weiß man, dass man unter einem 64-Bit-System unter einem 32-Bit Prozess unterwegs ist. Hier ist die Sache mit PROCESSOR_ARCHITEW6432 näher beschrieben: http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s


%d Bloggern gefällt das: