Dieser Beitrag ist schon älter. Bitte vergewissern Sie sich, dass die Rahmenbedingungen oder der enthaltene Lösungsvorschlag noch dem aktuellen Stand der Technik entspricht.

Batch - Betriebssysteminformationen abfragen (auch ohne WSH) - NT, 200x, XP, Vista, ... - Name ink. Typ (Server, Home, etc.), Version, Product Suite (Terminal Server, etc.), Sprache und Windows Service Pack, 32 oder 64 Bit

Mitglied: NeonZero

Der Beitrag, inkl. Quelltext, ist Gemeinfrei (er darf ohne jegliche Einschränkung genutzt werden).


In dieser Anleitung soll eine Batch-Funktion gebaut werden, die gebräuchliche Betriebssysteminformationen ermittelt kann und dabei auch in der Lage ist zu prüfen, ob bestimmte Eigenschaften für das aktuelle System zutreffen (also ob es sich z. B. um einen Terminal Server handelt, ob Service Pack 2 [oder womöglich höher] installiert wurde, ob die deutsche Sprachversion von Windows verwendet wird, etc.).

Die Batch soll ohne .vbs und anderen optionalen Skriptsprachen auskommen. Ziel ist es also, eine Batch-Funktion zu schreiben, die möglichst auf allen Computern ablauffähig ist, auf denen ein Windows-Betriebssysem läuft; also auch auf Computern, auf denen kein Windows Scripting Host (WSH) läuft.

Einschränkung: Da Batch-Funktionen erst seit NT3.51 unterstützt werden, ist der Ablauf unter älteren Betriebssystemen (Win3.x bis Win9x) nicht möglich.

Es wird zunächst gezeigt, wie man mit der Funktion umgeht. Dabei soll ein Überblick geschaffen werden, was sich mit der Funktion machen lässt. Der eigentliche Funktionscode ist recht lang, da er die Besonderheiten zahlreicher Betriebssystemversionen berücksichtigen muss. Der Code befindet sich am Ende des Beitrages.


back-to-topAufruf der Funktion

Die Funktion wird im Folgenden „FncWinVer“ genannt und per
    call :FncWinVer [Parameter]
aufgerufen.

back-to-topBetriebssysteminformationen ermitteln
Sobald die Funktion ohne Parameter aufgerufen wird, werden die Betriebssysteminformationen ein einem Format ausgegeben, das sich gut für die Verarbeitung in einer for-Schleife eignet:
Unter Windows XP könnte das die folgende Ausgabe bewirken:
    Windows XP Professional:5.1 Build 2600:NonSuite:German:SP2:32 bit

Zudem ist es möglich, die Ausgabezeile wie folgt einer Variablen (hier _x) zuzuweisen:
    call :FncWinVer -s _x
Eine Aufschlüsselung der Werte ist dann in folgender Weise denkbar:

back-to-topBetriebssysteminformationen abfragen
Für eine Abfrage, ob etwas zutrifft, oder nicht, bieten Batch-Funktionen ganz allgemein einen Rückgabewert an, der sich mit
    <call :Batch-Funktion> && echo Die Bedingung ist erfüllt
oder
    <call :Batch-Funktion> || echo Die Bedingung ist nicht erfüllt
direkt auswerten lässt. Denn die Bedingung ist für && erfüllt, wenn der Rückgabewert der Funktion 0 ist; die hinter dem || stehende Anweisung wird hingegen ausgeführt, wenn der Rückgabewert ungleich 0 ist.

Das lässt sich auch auf die hier gezeigte Batch-Funktion anwenden. Die denkbar einfachste Abfrage ist die nach dem verwendeten Betriebssystem-Namen. Sie kann wie folgt erfolgen:
    call :FncWinVer -e "NT4" "XP" && echo Das Betriebssystem ist entweder NT4 oder XP
bzw.
    call :FncWinVer -e "NT4" "XP" || echo Das Betriebssystem ist weder NT4 noch XP

Es ist auch möglich, mehrere Anweisungen an die Funktion zu binden
    call :FncWinVer -e "2000" "2008" "XP" && (
        echo Das Betriebssystem ist entweder Windows 2000, 2008 oder XP
        echo ... hier eine zweite echo-Anweisung
    )

Mögliche Betriebssystem-Namen, die sich hier abfragen lassen, sind z.B.
    "NT3", "NT4", "2000", "2003", "2008", "XP", "Vista", ...
Grundsätzlich sollte die Funktion auf allen Windows-Versionen laufen, die auf NT basieren, von NT3 bis Vista und Nachfolgende, wobei die Namen nur bis zur maximal gewünschten Übereinstimmung angegeben werden müssen. Also wird hier z. B. „NT“ angegeben, so ist die Bedingung unter NT3 und NT4 erfüllt. Wird stattdessen „3“ angegeben, so passt 2003 und NT3 in das Suchmuster der Funktion.

Auf gleicher Weise lassen sich nicht nur die Betriebssystem-Namen abfragen, sondern auch sämtliche andere Felder, die die Funktion ohne Parameter ausgegeben hat.
Bei einer "Windows XP Home"-Version würde nur die erste Zeile ausgegeben werden. Eine englische Variante von "Windows XP Professional" würden die beiden ersten Ausgaben hervorbringen. Bei einer deutschen Variante von "Windows XP Professional" würden alle vier Ausgabezeilen zu sehen sein. Die Anfrage wurde so formuliert, dass als weitere Bedingung genau das "Service Pack 2" (nicht höher oder niedriger) installiert sein muss, um eine Ausgabe zu erzeugen.

Hinweis: Seit Windows Vista wurde die Länderkennung von German in de geändert. Eine entsprechende Abfrage nach einer deutschen 32-Bit Variante von Windows Vista mit beispielsweise Service Pack 1 muss also wie folgt erfolgen:
    call :FncWinVer -e "Vista:::de:SP1:32" && echo Das ist ein deutsches Windows Vista, 32-Bit, mit Service Pack 1

Auch Abfragen ohne Angabe des Betriebssystem-Namens sind möglich:

Die folgende Abfrage zeigt, wie man ermitteln kann, ob es sich um Windows 2000 mit Service Pack 2 oder höher handelt. Das schließt Service Pack 3 genauso mit ein, wie neuere Versionen von Windows (2003, 2008, etc.). Das wird erreicht, indem die anderen bekannten Systeme ausgeschlossen werden (hier beispielhaft auch XP und Vista):
Künftige Betriebssystem-Versionen führen in diesem Beispiel ebenfalls zur Abarbeitung des ()-Blocks, da sie ja nicht explizit ausgeschlossen wurden.

back-to-topDer Funktionscode

Um den Funktionscode zu kopieren, klicke auf "in den Speicher kopieren". Wenn nur ein Teil des Codes kopiert werden soll, klicke auf "Quelltext" und maximiere das sich dann öffnende Fenster, um den unerwünschten Zeilenumbruch zu unterbinden. Dort lassen sich die Zeilen wie gewohnt markieren und kopieren.

Bedeutung der Versionsfelder:
    x.x.x
    |   |   '-->Änderungen in diesem Bereich zeigen an, dass ein Fehler beseitigt
    |   |         oder eine Optimierung vorgenommen wurde
    |   '---->Der Parameteraufbau zu einer Option oder der Funktionsumfang hat
    |             sich verändert (neue Optionen, etc.)
    '------->Es wurde eine grundlegende Änderung vorgenommen (allgemeiner
                   Parameteraufbau, Rückgabewert oder ähnliches)

Version 2.0.1: In der vorherigen Version schlug die Anweisung
    call :FncWinVer -e "NT" && echo Es wurde Windows NT gefunden.
leider auch bei z.B. "Windows 2003 Enterprise Edition" an. Der Fehler wurde behoben. Hintergrund: Die verwendete Suchmethode arbeitete nicht case-sensitive. -- NeonZero 22.07.2009

Version 2.0.0: Der Rückgabewert enthält nun ein zusätzliches Feld, welches angibt, ob es sich um eine 32-Bit- oder eine 64-Bit-Variante von Windows handelt. Die Abfrage kann wie folgt erfolgen:
    call :FncWinVer -e ":::::32" && echo Es handelt sich um eine 32 Bit Variante von Windows
    call :FncWinVer -e ":::::64" && echo Es handelt sich um eine 64 Bit Variante von Windows

Version 1.0.3: Windows Vista kennt keine prodspec.ini mehr. Die Länderkennung befindet sich jetzt in der Variablen %LC_LANG%, allerdings als en oder de und nicht als German. Damit muss man wohl leben. Die allgemeine Produktinformation findet sich jetzt in der Registry wieder. Der Code und die Anleitung wurden entsprechend angepaßt. -- NeonZero 29.01.2009

Version 1.0.2: Anders als unter Windows 2000 (und neuer) wird unter NT4 die Information über die Verfügbarkeit eines Terminal Servers nicht unter ProductSuite abgelegt. Vielmehr ist sie Bestandteil der allgemeinen Produktinformation ("Windows NT Server 4.0 Terminal Server Edition"). Zur Vereinheitlichung wurde der Eintrag "Terminal Server Edition" aus diesem (ersten) Feld entfernt und in das (dritte) Feld ProductSuite verschoben. Damit sollte nun auch unter NT4 der Terminal Server wie in der Anleitung beschrieben im dritten Feld abfragbar sein (call :FncWinVer -e "NT4::Terminal Server::" && echo Das Betriebssystem arbeitet als Terminal Server). Zusätzlich wurde die NT-Produktinformation (Feld1) für eine bessere Abfragemöglichkeit vereinheitlicht (eine Suche nach "NT3", "NT4" oder auch "NT4 Server", etc. ist nun möglich). -- NeonZero 13.01.2009

Version 1.0.1: Das Auslesen der Registry-Einträge wurde derart angepaßt, dass nun auch NT3, NT4 und Windows 2000 unterstützt werden. Einzige Einschränkung: Eine Auflistung der "ProductSuite" (unter "HKLM\System\CurrentControlSet\Control\ProductOptions") ist mir unter diesen alten Betriebssystemen noch nicht gelungen, da dies ein MULTI_SZ-Eintrag ist. Das bedeutet, dass die Funktion so tut, als ob auf dem System keine ProductSuite installiert wurde. Alle anderen Informationen sind ohne Einschränkung abfragbar. XP, Windows 2003 und neuer sind von dieser EInschränkung nicht betroffen. Wenn jemand eine Idee hat, wie sich unter Windows 2000 mit Standardmethoden (ohne WSH und ohne ein zusätzliches Tool installieren zu müssen) ein MULTI_SZ-Eintrag auswerten läßt, dann wäre ich für einen Hinweis dankbar. -- NeonZero 13.01.2009

Version 1.0.0: Erste Version, die lediglich unter XP, Windows 2003 und neueren Versionen von Windows funktioniert; sie nutzt reg.exe, die von NT3 bis w2k auf einer Standardinstallation noch nicht vorhanden ist (das wird erst ab Version 1.0.1 berücksichtigt - danke an @paulepank für den Hinweis). -- NeonZero 11.01.2009

Content-Key: 105641

Url: https://administrator.de/contentid/105641

Ausgedruckt am: 28.11.2021 um 06:11 Uhr

Mitglied: TuXHunt3R
TuXHunt3R 11.01.2009 um 00:16:54 Uhr
Goto Top
Grundsätzlich mal nicht schlecht, allerdings benutze ich inzwischen bei solchen Scripts inzwischen immer die PowerShell in Kombination mit WMI (oder VBS, wenns denn vom Chef so bestimmt wurde). Batchcode ist meiner Meinung nach zu unleserlich und zu kryptisch für solch komplexe Scripts.
Mitglied: NeonZero
NeonZero 11.01.2009 um 02:30:31 Uhr
Goto Top
Hallo TuXHunt3R. Ich kann Deine Argumente gut nachvollziehen. Allerdings würde man bei der Verwendung der PowerShell oder einer alternativen Skriptsprache das maßgebliche Ziel aus den Augen verlieren. Die spezielle Anforderung war es, die Lauffähigkeit zu gewährleisten, ohne ein Zusatzprodukt installieren zu müssen und auch ohne auf einen aktivierten WSH angewiesen zu sein. Der Vorteil von Batch ist ja gerade der, dass der Code ohne weiteres Zutun auf jedem der genannten Systeme ausgeführt werden kann.

Bye, nz
Mitglied: Biber
Biber 11.01.2009 um 12:22:10 Uhr
Goto Top
Moin TuXHunt3R,
Batchcode ist meiner Meinung nach zu unleserlich und zu kryptisch für solch komplexe Scripts.
Genau diese Ansicht ist ja die große Herausforderung beim Erstellen von Batchscripts und erst recht von Tutorials zum Thema "Batchlösungen für komplexere Probleme".

Batchdateien sind wirklich nicht selbstdokumentierend und erzwingen syntaktisch nicht unbedingt eine strukturierte Herangehensweise.

Gerade deshalb finde ich NeonZeros Tutorial - mit sauberer Herleitung, Struktur und Dokumentation - im Bereich "Batch & Shell" sehr gelungen.

Und die von NeonZero formulierte Ausgangssituation "Wie kann ich verlässliche Ergebnisse erzielen, wenn ich als Werkzeuge nur ein Stück Bindfaden und zwei Streichhölzer zur Verfügung habe?" finde ich bezogen auf Windows-Standard-Client-Installationen durchaus begründet.

Natürlich geht es mit einem prall gefüllten Powershell-Werkzeugkasten eventuell "besser". aber ...
... ein C#-oder .NET-Coder würde auch sagen:
"Hey, da brat ich Dir in 10 Minuten was Besseres zusammen."

Von mir jedenfalls großes Lob für das mit Bindfaden und Streichhölzern erstellte Ergebnis.

Grüße
Biber
Mitglied: paulepank
paulepank 11.01.2009 um 20:01:58 Uhr
Goto Top
Hallo hier,

@Biber
...für das mit Bindfaden und Streichhölzern erstellte Ergebnis
naja, etwas Zauberpulver war auch dabei, weil ...

@NeonZero
...dass der Code ohne weiteres Zutun auf jedem...
Das stimmt so nicht.
Am Beispiel vom Windows 2000 - hier gibt es keine reg.exe.
Diese muß per Hand aus dem Supporttool entweder in den System32-Ordner kopiert werden.
Dann wäre der Aufruf %SYSTEMROOT%\system32\reg.exe doppelt gemoppelt.
oder die Supporttools werden installiert. Dann liegt reg.exe im Ordner %ProgramFiles%\Supporttools.
Dann ist der Aufruf %SYSTEMROOT%\system32\reg.exe sogar falsch.
Fazit:
Da %ProgramFiles%\Supporttools zur PATH-Variablen hinzugefügt wird genügt auf jeden Fall als Aufruf reg.exe query ....

Der Anspruch "ohne weiteres Zutun" kann durch Verwenden von reg.exe nicht erfüllt werden.

cu paulepank
Mitglied: NeonZero
NeonZero 11.01.2009 um 22:47:25 Uhr
Goto Top
Zitat von @paulepank:
... Windows 2000 - hier gibt es keine reg.exe.

Das ist ein guter Hinweis. Danke. Mann könnte das über die Export-Funktion von regedit.exe lösen, die auch unter Windows 2000 läuft. Allerdings wird diese Anpassung die Batch-Funktion um einiges aufblähen.

Bis dahin ist die Batch-Funktion, wie Du richtig festgestellt hast, nur für XP, Windows 2003 und Nachfolgende geeignet.

Nachtrag: Mit der aktuellen Anpassung sollte die Batch-Funktion (Verison 1.0.1) nun auch unter NT3, NT4 und w2k laufen. Allerdings mit einer Einschränkung: Der Eintrag "ProductSuite" unter "HKLM\System\CurrentControlSet\Control\ProductOptions" lässt sich nicht über den Weg der Export-Funktion von regedit.exe aufschlüsseln, da dies ein MULTI_SZ-Eintrag ist. Wenn jemand eine Idee hat, wie sich unter Windows 2000 mit Standardmethoden (ohne WSH und ohne ein zusätzliches Tool installieren zu müssen) ein MULTI_SZ-Eintrag auswerten läßt, dann wäre ich für einen Hinweis dankbar.

Bye, nz
Mitglied: TuXHunt3R
TuXHunt3R 14.01.2009 um 00:21:01 Uhr
Goto Top
@ Biber:
Und die von NeonZero formulierte Ausgangssituation "Wie kann ich verlässliche Ergebnisse erzielen, wenn ich als Werkzeuge nur ein Stück Bindfaden und zwei Streichhölzer zur Verfügung habe?" finde ich bezogen auf Windows-Standard-Client-Installationen durchaus begründet.

Bei Servern gehört die PowerShell ab 2008 standardmässig dazu, bei den Clientsystemen ab Windows 7. Das .NET Framework 2.0 ist seit Vista auch überall standardmässig drauf (ausser der Core-Installation von 2008 Server) und den WSH gibt es seit Windows 2000 auch überall standardmässig dazu. Aber ich verstehe deine Argumentation...


Am Beispiel vom Windows 2000 - hier gibt es keine reg.exe.
Richtig. Es gibt auch noch andere Dinge, die bei Windows 2000 anders sind, z.B. die Abfrage des Errorlevels (%errorlevel%).
Mitglied: NeonZero
NeonZero 14.01.2009 um 12:39:09 Uhr
Goto Top
TuXHunt3R, Du möchtest auf einem Windows 2008 lieber per PowerShell-Skript nach dem verwendeten Betriebssystem fragen. Unter Windows 2000 nutzt Du dafür lieber den WSH und unter NT4 vermutlich lieber eine Batch-Lösung. Um das zu tun, musst Du vorher schon wissen, um welches System es sich handelt. Dann ist die Abfrage nach dem verwendeten Betriebssystem allerdings überflüssig. Andernfalls brauchst Du etwas, das auf all diesen Systemen läuft. Die Batch-Funktion erfüllt diese Voraussetzung.

Zudem: Selbst wenn Du ein System hast, auf dem per Standardinstallation eine PowerShell installiert wurde, wird Dein PowerShell-Skript nicht laufen, da die Skript-Ausführung standardmäßig deaktiviert ist. Das ist Teil des Sicherheitskonzepts. Der Administrator muss die PowerShell erst entsprechend konfigurieren und dabei bewusst festlegen, welche Art von .ps1-Skripten zugelassen sind (z.B. nur Skripte von lokalen Laufwerken starten, ggf. nur signierte Skripte starten, etc.). Eine verlässliche einheitliche Einstellung, die Du z.B. außerhalb Deines Unternehmens vorfinden kannst, gibt es nicht.

Ähnlich sieht es mit dem WSH aus. Aus Sicherheitsgründen wird er gerne deaktiviert. Deshalb existiert ja die Aufgabenstellung aus der Einleitung, die explizit darauf hinweist, dass bei dieser Lösung nicht auf den WSH zugegriffen werden soll. Was Du mit dem .NET-Framework machen möchtest, ohne den WSH zu verwenden, ist mir unklar.

Zitat von @TuXHunt3R:
Es gibt auch noch andere Dinge, die bei Windows 2000 anders sind, z.B. die Abfrage des Errorlevels (%errorlevel%).

Könntest Du das bitte konkretisieren?

Bye, nz
Mitglied: TuXHunt3R
TuXHunt3R 15.01.2009 um 21:43:36 Uhr
Goto Top
Windows 2000:

Windows Vista:
(Aus dem Kopf, nicht getestet)

Des weiteren ändert bei den verschiedenen zusätzlichen Commandline-Tools (z.B. Resource Kit) manchmal die Syntax. Ich glaube, RMTSHARE ist so ein Beispiel. Bin mir allerdings nicht sicher.
Mitglied: NeonZero
NeonZero 16.01.2009 um 09:50:18 Uhr
Goto Top
Zitat von @TuXHunt3R:
Aus dem Kopf, nicht getestet

Es wäre nett, wenn Du den Test bitte nachholen könntest. Beide Abfragen sollten unter beiden Systemen funktionieren (wobei Du bitte zwischen dem Vergleichsoperator und den beiden Argumenten ein Leerzeichen setzen solltest).

Bye, nz
Mitglied: onegasee59
onegasee59 02.02.2009 um 22:37:07 Uhr
Goto Top
Hallo NeonZero,

Erstmal Respekt. Wirklich Klasse gemacht.

Dazu noch eine Frage:

Kann man hier auch die Abfrage ob 32- oder 64-bit-System ebenfalls mit einbauen?

gruß
onegasee59
Mitglied: NeonZero
NeonZero 03.02.2009 um 17:21:37 Uhr
Goto Top
Ich habe die Funktion entsprechend angepasst. Sie hat jetzt die Version 2.0.0, da sich der Rückgabewert geändert hat (ein zusätzliches letztes Feld enthält die gefragte Information). Die Abfrage kann nun wie folgt erfolgen:
    call :FncWinVer -e ":::::32" && echo Es handelt sich um eine 32-Bit-Version von Windows

Es ist jedoch ein quick-and-dirty hack, da ich auf die Schnelle keine offizielle Aussage von MS finden konnte, die besagt, wie man aus einer Batch heraus diese Information ermitteln soll. Was soll’s. Sobald sich mir ein besserer Weg offenbart, um an diese Information zu gelangen, werde ich die Funktion entsprechend anpassen.

Allgemeine Abfragemöglichkeiten in einer DOS-Konsole wären:
  1. dxdiag /t benutzt APIs, um solche Informationen zu sammeln und in eine Textdatei abzuspeichern. Die Textdatei ließe sich in einer for-Schleife auswerten. Allerdings dauert es extrem lange, bis die Protokolldatei angelegt wird. Für die Batch-Funktion scheint mir dieser Weg ungeeignet zu sein.
  2. Alternativ dazu könnte man auch eine WMI-Anfrage starten (z.B. wmic path win32_operatingsystem get caption). Das funktioniert aber nur auf Windows 2003, XP Professional (nicht XP Home) und Vista. Auch muss der WMIC (Windows Management Instrumentation Commandline) auf dem PC installiert sein; dieser benötigt zudem den WSH. Für die Funktion ist diese Lösung deshalb nicht geeignet.
  3. Auf 64-Bit Windows-Systemen gibt es einen Registry-Schlüssel namens HKEY_LOCAL_MACHINE\Software\WOW6432. Das scheint ein virtueller Key zu sein, der die 32-Bit-Schlüssel zusammenfasst.
  4. Zudem gibt es auf 64-Bit-Systemen exklusiv das Verzeichnis %windir%\SysWOW64.

Daher benutze ich in der Funktion nun einfach die Abfrage, ob das Verzeichnis %windir%\SysWOW64 auf dem System vorhanden ist, in der Hoffnung, dass auch künftige 64-Bit-Systeme ein solches Verzeichnis anlegen.

Bye, nz
Mitglied: onegasee59
onegasee59 03.02.2009 um 18:01:24 Uhr
Goto Top
Hallo NeonZero,

erstmal Danke für Deinen Antwort.

Ich habe inzwischen auch mal recherchiert.

Zu Punkt 4.
Ich frage das gleiche Verzeichnis "%windir%\SysWOW64" in meinem Tool XPandWMP-PermReset-Fix , damit es nicht auf 64bit-Systemen angewendet werden kann. Vor einigen Tagen erhielt ich Rückmeldung das bei einem User mein Tool das weiterarbeiten verweigert und ihm 64bit meldet, er aber angeblich nur ein 32bit-System hat.

Habe dann mal weiter recherchiert und jetzt die Abfrage über Systemvariable eingebaut:

if %PROCESSOR_ARCHITECTURE%==x86 (set osbit=32bit) else (set osbit=64bit)

Vielleicht ist das auch für Dich gegeignet.

Gruß
onegasee59
Mitglied: NeonZero
NeonZero 03.02.2009 um 19:02:51 Uhr
Goto Top
Hallo Matthias. Danke für Deinen Tipp. In einer .exe sollte die Abfrage kein Problem sein. Du kannst leicht auf eine entsprechende API zugreifen, die Dir u.a. die 32 oder 64-Bit-Variante zurückgibt (siehe msdn-Suche).

<ot>Sympathisch finde ich, dass Du Deine Tools als Freeware zur Verfügung stellst. Perfekt wäre es, wenn auch die Sourcen enthalten wären. Gibt es einen speziellen Grund dafür, sie nicht in die .zip zu packen?</ot>

Ich würde mich gerne selbst davon überzeugen, ob auf der fraglichen 32-Bit-Version tatsächlich dieses Verzeichnis existiert. Dabei ist es wichtig zu wissen, was genau unter „Systemsteuerung / System / Allgemein“ des betroffenen PCs ausgegeben wird. Kannst Du die Angaben des Anwenders bitte hier posten?

Bye, nz
Mitglied: onegasee59
onegasee59 03.02.2009 um 22:46:16 Uhr
Goto Top
Hallo NeonZero,

Hallo Matthias. Danke für Deinen Tipp. In einer .exe sollte die Abfrage kein Problem sein. Du kannst leicht auf eine entsprechende API
zugreifen, die Dir u.a. die 32 oder 64-Bit-Variante zurückgibt (siehe msdn-Suche).

Ist Batch-to-EXE, d.h. nur als *.exe verpackt. ;-) face-wink

<ot>Sympathisch finde ich, dass Du Deine Tools als Freeware zur Verfügung stellst. Perfekt wäre es, wenn auch die
Sourcen enthalten wären. Gibt es einen speziellen Grund dafür, sie nicht in die .zip zu packen?</ot>


Klar könnte ich machen, aber dann müsste sich jeder Interressent den ganzen Kram runterladen.
Wollte ich vermeiden, weil wenn man die *.zip entpackt und die *.exe startet, findet man den gesamten Inhalt der *.exe im Ordner Temp.
"C:\Dokumente und Einstellungen\..username..\Lokale Einstellungen\Temp"

Ich würde mich gerne selbst davon überzeugen, ob auf der fraglichen 32-Bit-Version tatsächlich dieses Verzeichnis
existiert. Dabei ist es wichtig zu wissen, was genau unter „Systemsteuerung / System / Allgemein“ des betroffenen PCs
ausgegeben wird. Kannst Du die Angaben des Anwenders bitte hier posten?

Gerne, muss ich aber hoffen das von Ihm noch eine Reaktion auf mein Antwort an Ihn kommt.
Er hatte in der Newsgroup geantwortet und ist dabei über das Webinterface von MS gegangen, also keinen replayfähigen Emailaccount benutzt.
Thread "Installation fehlgeschlagen" in NG microsoft.public.de.inetexplorer.ie7

Gruß
onegasee59
Mitglied: Batchler
Batchler 28.01.2011 um 21:58:27 Uhr
Goto Top
Hallo Leute,

bin neu hier und bin schon durch einige Threads hier im Unterforum "Batch & Shell" inspiriert worden, komme aber momentan nicht weiter.

Habe mal vor längerer Zeit angefangen, das Betriebssystem bei Win2000 zu ermitteln, dann ist WinXP dazugekommen und mittlerweile bin ich bei Win7 / 64bit angekommen. Auf der Suche nach einer allgemeingültigen Abfrage bin ich auf diesen Thread gestoßen.

Super Sache, allerdings sind mir 2 Sachen aufgefallen.

Bei Windows 7 wird folgendes Ergebnis ausgespuckt:


Ergebnisse von "ServicePack" und "Architecture" rutschen ein Feld nach oben. Nach dem ich unter die Zeile 42

set _#Lang=%LC_LANG%
noch folgende Zeile eingefügt habe
IF "%_#Lang%" == "" SET _#Lang=No Localization
klappt es mit der Abfrage. Ich denke, da Win7 mehrsprachig ist, wird auch keine direkte Sprache hinterlegt sein. Ist aber nur eine Vermutung von mir und es funktioniert.

Da, wo ich nicht weiterkomme, ist bei Windows 2000:

Wie man sieht, wird bei "Architecture" noch ein Rest vom nachfolgenden Befehl mit angehängt. Ich habe schon ein bisschen probiert, da ich aber, sagen wir mal, fortgeschrittener Anfänger bin, komme ich mit meinem Latein nicht weiter.

Hat jemand von Euch eine Idee, wo der Fehler in diesem Skript liegt ?

Ach ja, noch eine kleiner Schönheitsfehler meinerseits: Wollte bei "Architecture" folgende Ausgabe: "64bit (x64)" bzw. "32bit (x86)"
Bei den Klammern innerhalb des "SET"-Befehls für die Variablen-Deklaration "_#Bit" kommt das Skript ins Straucheln. Habe es mit dem Maskierungszeichen ^ versucht, klappt aber auch nicht. Wie gesagt nur ein kleiner Schönheitsfehler, sollte aber jemand eine Lösung dafür haben, immer her damit.

So das war es fürs erste Mal.
Gruß

Batchler

Nachtrag:

Habe es gerade nochmals probiert mit der "Architecture"-Ausgabe: "64bit (x64)" bzw. "32bit (x86)" und dem Maskieren von der Klammer.

wenn ich mir per ECHO die Variable direkt anzeigen lasse
echo Architecture....... %%f
habe ich folgende Ausgabe
Architecture....... 32bit ^(x86^)

wenn ich aber die Ausgabe wieder in einer Variable hinterlege
SET Architecture=%%f
und danach per ECHO aufrufe
ECHO Architecture....... %Architecture%
habe ich folgende Ausgabe
Architecture....... 32bit (x86)

also alles wieder im Lot.
Mitglied: 99045
99045 06.09.2011 um 12:13:53 Uhr
Goto Top
Ich hätte da einen 5-Zeiler im Angebot, bei dem die wesentlichen Informationen das Systemprogramm systeminfo.exe, dabei ab Windows XP ermittelt und eine Batchzeile für die Ausgabe sorgt:


Funktioniert ab XP bis Win7 32/64 auf Workstations, Server habe ich nicht, kann es also nicht testen, sollte aber eigentlich ebenfalls funktionieren. Evtl. muss der Zähler von 15 auf einen etwas höheren Wert gesetzt werden.
Heiß diskutierte Beiträge
question
Windows Server 2019 AD MigrationjamesbrownVor 1 TagFrageWindows Server9 Kommentare

Hallo zusammen Langsam habe ich Panik, die komplette Domäne zerschossen zu haben. Bevor ich weiter vergehe, wollte ich darum hier um Rat bitten. Was ist ...

question
Mobilfunk-Internet ins Heimnetzwerk integrieren? gelöst AvarianVor 1 TagFrageNetzwerkmanagement8 Kommentare

Hallo, Ich bin neu hier. Wir sind vorletztes Jahr umgezogen. Die Gelegenheit habe ich damals direkt genutzt, um künftig auf wackelige WLAN-Lösungen (Repeater, Mesh-Repeater, Powerlines ...

general
Sicherheit beim Online-BankingWeyershausenVor 13 StundenAllgemeinSicherheitsgrundlagen18 Kommentare

Hallo, in unserer Firma verwenden wir SFirm als Online-Banking-Software. In dieser Woche hatten wir einen IT-Berater bei uns, der uns dringend folgendes Vorgehen empfahl: Wir ...

question
Maximale Empfänger bei Office365 gelöst mmpmmpVor 1 TagFrageMicrosoft Office11 Kommentare

Hallo, ich verwende nun Office365 (Exchange Online) für Emails und würde gerne die Weihnachtsgrüße per Mail versenden. Wo liegen die Beschränkungen der maximalen Empfänger? ...

report
Mailversand durch Sophos XG gestört (25.11.2021)kgbornVor 1 TagErfahrungsberichtFirewall2 Kommentare

Kurze Information - vielleicht hat jemand eine ähnliche Beobachtung gemacht. Ein IT-Admin hat mich darauf hingewiesen, dass es wohl gestern (25.11.2021) ein Update des Antivirus-Pattern ...

question
Treuhand für ebay-Verkäufer, die nicht direkt nach D. liefernDerWoWussteVor 1 TagFrageHardware4 Kommentare

Moin Kollegen, es gibt ja Fälle, wo man alte Hardware benötigt, aber nur noch über ebay bekommt. Wenn der Verkäufer dann aber nicht nach Deutschland ...

question
Reinigung der Apple Watch gelöst honeybeeVor 1 TagFrageApple6 Kommentare

Hallo, mit welchem Reinigungsmittel kann ich das Armband meiner Apple Watch schonend reinigen? Auf dem Bild seht ihr, dass es in einem guten Zustand ist. ...

question
Über das Notebook per Simkarte von unterwegs aus ins Internet?isarc01Vor 1 TagFrage5G, 4G, LTE, UMTS, EDGE & GPRS8 Kommentare

Hallo, folgende Frage: Wenn ich über mein Notebook über eine angemeldete SIM Karte mit einer Datenflatrate ins Internet gehen möchte, benötige ich hier einen bestimmten ...