32bit Service auf 64bit Platform

[Klaus01]

Hallo,

ist das prinzipiel möglich?
Sind Probleme zu erwarten - auf was muss ich besonders achten?
Würde den Service mit TService aufbauen wollen.

Ich frage weil das Zielsystem Windows2008 64bit ist,
ich aber kein 64bit System zum Testen habe.

Grüße
Klaus

[Bummi]

Ich hatte mit meinen Diensten bisher weder unter Vista, Windows7 oder Server 2008 (R2) Probleme.
Unter XP 64 habe ich keine Erfahrungen.

[Dezipaitor]

Dienste sind normale Programme und 32bit Dienste werden daher auch mit WOW64 ausgeführt, wie jedes normale 32bit Programm.

[Bernhard Geyer]

Wenn du nichts falsch machst (Hard Codierte Verzeichnisangaben, ...) dann läuft dein Code problemlos

[Klaus01]

Hallo,

danke für die Antworten, dann kann ich es ja angehen.

Grüße
Klaus

[Assarbad]

Zitat:

Zitat von Bummi (Beitrag 1057335)

Unter XP 64 habe ich keine Erfahrungen.

XP x64 basiert auf Windows 2003 und hat damit auch keine Probleme.

[Delphi-Laie]

Ich bestreite die Ausführungen der Vorredner nicht, habe allerdings bei etwas solch simplem wie dem Modulschnappschuß bereits negative Erfahrungen gesammelt: Bei dem nützten auch Administratorrechte eines 32-Bit-Programmes unter Windows (7) 64 Bit (vermutlich auch bei anderen 64-Bit-Windows) nicht, um vollständige Informationen (d.h., über jeden Prozeß, auch die Systemprozesse) einlesen zu können. Mithin griff ich zu Lazarus, dessen 64-Bit-Compilat die gewünschten Funktionen bot.

Zitat:

Zitat von Klaus01 (Beitrag 1057334)

Ich frage weil das Zielsystem Windows2008 64bit ist,
ich aber kein 64bit System zum Testen habe.

Alternativ könnte man das Programm zunächst unter 32-Bit-Lazarus entwickeln und dann - für denjenigen, dem die 64 Bit zur Verfügung stehen - auf 64 Bit portieren. Mit ein wenig Glück klappt das sogar ohne jede Änderung (so war es bei mir bereits bei 2 Projekten). Zugegeben: Lazarus ist aus der Delphi-Perspektive (noch?) kein Hochgenuß, aber was nicht ist, kann (und wird?) ja noch werden, und letztlich ist das Ergebnis das Wichtigste, dem sich der Weg dorthin unterordnen sollte.

[Assarbad]

Zitat:

Zitat von Delphi-Laie (Beitrag 1057458)

Ich bestreite die Ausführungen der Vorredner nicht, habe allerdings bei etwas solch simplem wie dem Modulschnappschuß bereits negative Erfahrungen gesammelt: Bei dem nützten auch Administratorrechte eines 32-Bit-Programmes unter Windows (7) 64 Bit (vermutlich auch bei anderen 64-Bit-Windows) nicht, um vollständige Informationen (d.h., über jeden Prozeß, auch die Systemprozesse) einlesen zu können.

Und was meinst du mit "Systemprozessen"?

[Delphi-Laie]

Zitat:

Zitat von Assarbad (Beitrag 1057468)

Zitat:

Zitat von Delphi-Laie (Beitrag 1057458)

Ich bestreite die Ausführungen der Vorredner nicht, habe allerdings bei etwas solch simplem wie dem Modulschnappschuß bereits negative Erfahrungen gesammelt: Bei dem nützten auch Administratorrechte eines 32-Bit-Programmes unter Windows (7) 64 Bit (vermutlich auch bei anderen 64-Bit-Windows) nicht, um vollständige Informationen (d.h., über jeden Prozeß, auch die Systemprozesse) einlesen zu können.

Und was meinst du mit "Systemprozessen"?

Die, die z.B. beim Modulschnappschuß nur dann ein konsistentes (= anzahlig größer als Null) Ergebnis zurückliefern, wenn das Programm zuvor erfolgreich Exklusivrechte ("Privilegien") anforderte. Es sind dies von der Prozeß-ID her die niedrigen Prozesse, sie reichen bei mir namentlich von "System" bis "svchost", während die anderen Prozesse ab "explorer.exe" (in Richtung steigender Prozeß-IDs) auch ohne solche Privileganforderung solche Informationen preisgeben. Desweiteren benötigt man auch diese maximalen bzw. exklusiven Privilegien, um solche Prozesse mit niedrigen IDs "abzuschießen".

Irgendetwas muß an diesen Prozessen anders sein (Ring 0?); ich nenne sie, wohl nicht ganz korrekt, Systemprozesse.

[Assarbad]

Alles klar ;)

Zitat:

Zitat von Delphi-Laie (Beitrag 1057544)

Die, die z.B. beim Modulschnappschuß nur dann ein konsistentes (= anzahlig größer als Null) Ergebnis zurückliefern, wenn das Programm zuvor erfolgreich Exklusivrechte ("Privilegien") anforderte. Es sind dies von der Prozeß-ID her die niedrigen Prozesse, sie reichen bei mir namentlich von "System" bis "svchost", während die anderen Prozesse ab "explorer.exe" (in Richtung steigender Prozeß-IDs) auch ohne solche Privileganforderung solche Informationen preisgibt. Desweiteren benötigt man auch diese maximalen bzw. exklusiven Privilegien, um solche Prozesse mit niedrigen IDs "abzuschießen".

Dienste abzuschießen ist ohnehin eine schlechte Idee, es sei denn alles andere schlägt fehl. Zuerst sollte man "net stop" (API-Funktion ControlService) benutzen. Früher konnte man bspw. auch winlogon.exe abschießen, da aber der Session-Manager (smss.exe) ein Handle auf diesen Prozeß hielt, kassierte man dafür innerhalb von Sekunden einen BSOD.

"System" ist kein Prozeß und kann auch nicht abgeschossen werden. Genau wie der "Leerlaufprozeß" (aka "Idle process"), der ebenfalls nur ein Pseudo-Prozeß ist. "System" repäsentiert in gewisser Weise den NT-Kernel und die darin geladenen Treiber. Hat einfach was mit dem Scheduling zu tun.

Zitat:

Zitat von Delphi-Laie (Beitrag 1057544)

Irgendetwas muß an diesen Prozessen anders sein (Ring 0?); ich nenne sie, wohl nicht ganz korrekt, Systemprozesse.

Sie laufen in der Service-Session (üblicherweise 0), welche ab Windows Vista strenger vom Rest des Systems abgetrennt ist. Außerdem laufen sie oft unter anderen Benutzerkonten.

Nachtrag: mit Ring 0, aka Kernelmodus, hat das nicht viel zu tun. Üblicherweise hat fast jeder Thread (außer reine Kernelthreads) etwas sowohl in Ring 0 als auch in Ring 3 zu erledigen. Und da Prozesse im Grunde nur Threads "gruppieren", ist die Aussage auf Prozesse insoweit anwendbar. Es gibt aber auch gewisse Ausnahmen wo die Grenze (insbesondere beim Start) verschwimmt, bspw. smss.exe