Dienst lässt sich nicht unter anderem Namen registrieren

[hurzli]

Hallo zusammen !

Ich brauche dringend einen Rat warum das was ich mir ausgedacht habe nicht funktioniert.
Ich habe mich zwar schon ziemlich weit durchgebissen, die letzte Erkenntnis ist aber leider (noch) ausgeblieben.

Kurze Beschreibung meines Vorhabens :
1) Ein Dienst, der ein bestimmtes "Gerät" (genauer wäre zu langwierig) bedient.
Es kann an einem Computer mehrere angeschlossene Geräte geben.
Für jedes Gerät soll der Dienst mit unterschiedlichen Übergabeparametern erneut gestartet werden können. Der Dienst ist fertig, startet, stoppt binnen Sekunden und tut genau das, was ich erwarte.

2) Ein Konfigurationsprogramm, mit dem für jedes Gerät dynamisch eine Konfiguration erzeugt wird und ein neuer Dienstname dafür vergeben wird. Dieser Name wird verwendet um über CreateService() einen neuen Eintrag für den Dienst in der Registry mit unterschiedlichen Parametern anzugelegen.

Jetzt kommt das Problem :
Wenn ich aus dem Konfigurationsprogramm heraus der CreateService()-Funktion als lpServiceName den Namen übergebe, der im Dienst unter TService.Name steht, funktioniert alles bestens. Um den Dienst mehrfach mit unterschiedlichen Parametern starten zu können, braucht jede Instanz einen eigenen "Block" in der Registry unter einem neuen Namen.
Und daran scheitert es !!!!
Der gesamte Registryblock wird mit allen Schlüsseln und Werten unter diesem Namen zwar angelegt, der Dienst lässt sich aber nicht starten. In der Dienste-Verwaltung steht als Status "wird gestartet", aber es passiert nichts weiter.

Ich habe auch schon versucht den Dienst unter dem neuen Namen über die Kommandozeilentools instserv.exe, scmgr.exe und sc.exe zu registrieren, aber das Verhalten ist das selbe! Der Dienst startet unter dem neuen Namen einfach nicht richtig ! Es liegt also nicht am Aufruf aus meinem Konfigurationsprogramm. Keine Fehlermeldung, kein Eintrag im Ereignisprotokoll ! Echt frustrierend !


Was passt hier nicht ?? Es kann nur eine Kleinigkeit sein und ich komme einfach nicht drauf !

Ein hilfesuchender Gruß
Stefan

[Assarbad]

Hoppala. Das ist wieder eine Frage die man nur beantworten kann mit: "was willst du denn eigentlich machen?"

1. Für Geräte gibt es Treiber. Wieso also ein Dienst?
2. Wenn du einen Dienst benutzt, dann doch sicher nur weil er SYSTEM-Rechte hat, oder? Wieso kann dieser Dienst also nicht für jedes "Client-Gerät" einen neuen "Server-Thread" starten. Wäre weit sinnvoller, ressourcenschonender, eleganter, fehlerunanfälliger.

[hurzli]

Hi !
Ich hatte garnicht erwartet, dass sich nochmal jemand rührt !
Die anzusteuernden "Geräte" sind keine normale Computerperipherie sondern komplette automatische Lagersysteme, Paternosterlager, Rotomaten etc. Diese Geräte werden mit Aufträgen versorgt und melden ihre Aktionen zurück (So im Groben). Jeder Lagertyp auf seine eigene Art. Die dabei anfallenden Daten und die benötigte Rechenleistung um diese Daten zu verarbeiten sind eher gering.

In der Threadtechnologie bin ich ein gebranntes Kind, denn die verschiedenen Threads kommen manchmal auf Ideen bzw. in Zustände, auf die ich im Traum nie gekommen wäre. Alles in Allem strotzen die meisten Multithreadanwendungen die ich so gesehen habe von CriticalSections. Alle Threads warten meistens darauf, dass einer mit irgendwas fertig wird. Eigenlich hätte man's dann auch gleich sequentiell lösen können.

Weil hinter so einem wie auch immer gelösten Programmteil eine reelle Fertigung steht und es bei
deren Ausfall gleich so richtig ums Geld geht, geht mir die Sicherheit der laufenden Programmteile vor. Ressourchen und Eleganz sind in diesem Fall nur "Grauwerte".

Eigentlich ist das Problem bereits gelöst.
Versucht hatte ich die TService-Komponente von Delphi 5.
Die hat meiner subjektiven Meinung nach einen Fehler. Als Dienstname wird der TService.Componentname in die Registry eingetragen und der ist nicht der Name, den ich dem Dienst über mein Konfigurationsprogramm eingetragen hatte. DESHALB lief der Dienst einfach nicht los. Falscher Name, das ist alles.

Die Lösung : ein in Delphi 3 geschriebenen Dienst, der sich noch so richtig zu Fuß um alle Einträge/Aktionen selbst kümmert, auf meine Anforderungen angepasst, bringt's. Also eine Delphi 3 Dienst-Hülle mit meiner Funktionalität, wenn man das ganze so nennen will.

Gruß
Stefan

[Assarbad]

Zitat von hurzli:

Ich hatte garnicht erwartet, dass sich nochmal jemand rührt !

Ich gehe unregelmäßig alle Postings durch und schaue in die die mich interessieren und unbeantwortet sind oder wenige (0-2) Antworten haben.

Zitat von hurzli:

Die anzusteuernden "Geräte" sind keine normale Computerperipherie sondern komplette automatische Lagersysteme, Paternosterlager, Rotomaten etc. Diese Geräte werden mit Aufträgen versorgt und melden ihre Aktionen zurück (So im Groben). Jeder Lagertyp auf seine eigene Art. Die dabei anfallenden Daten und die benötigte Rechenleistung um diese Daten zu verarbeiten sind eher gering.

Okay. Theoretisch geht ein Gerätetreiber auch für einen Toaster (das DDK kommt mit einem solchen Bsp) aber vielleicht wäre das mit der Einarbeitungszeit tatsächlich Overkill.

Zitat von hurzli:

In der Threadtechnologie bin ich ein gebranntes Kind, denn die verschiedenen Threads kommen manchmal auf Ideen bzw. in Zustände, auf die ich im Traum nie gekommen wäre. Alles in Allem strotzen die meisten Multithreadanwendungen die ich so gesehen habe von CriticalSections. Alle Threads warten meistens darauf, dass einer mit irgendwas fertig wird. Eigenlich hätte man's dann auch gleich sequentiell lösen können.

Dann hast du nur die schlechten Bsp. für Synchronisation erlebt. Schau dir den Apache-Server an, der ist ein gutes Beispiel
Jeder Thread kann ja einen eigenen Puffer haben, der erst dann geschrieben wird "wenn was frei ist". Es geht also auch ohne daß die sich gegenseitig blocken. Allerdings muß man sich gut überlegen was in einen Thread soll. Außerdem ist die Delphi-TThread-Klasse auch nicht dazu angetan solche Dinge zu machen. Entweder was eigenes schreiben oder direkt mit Threads und deren APIs arbeiten.

Zitat von hurzli:

Weil hinter so einem wie auch immer gelösten Programmteil eine reelle Fertigung steht und es bei
deren Ausfall gleich so richtig ums Geld geht, geht mir die Sicherheit der laufenden Programmteile vor. Ressourchen und Eleganz sind in diesem Fall nur "Grauwerte".

Was war jetzt eigentlich das Problem. Vielleicht habe ich es ja komplett falsch verstanden. Also ich hatte es so aufgefaßt, daß du pro Gerät dynamisch einen neuen Dienst erzeugst und dies Namenskonflikte bringt. Wenn dem nicht so ist, verstehe ich wohl das Problem noch nicht ganz.

Alternativ zu Threads kannst du unter NT (und 2000, XP ...) auch Fiber verwenden. Grob gesagt sind dies Usermode-Threads und du kannst sie selbst schedulen. Im Falle von Threads macht dies der Scheduler im KM für dich.

Zitat von hurzli:

Eigentlich ist das Problem bereits gelöst.

Gut

Zitat von hurzli:

Versucht hatte ich die TService-Komponente von Delphi 5.
Die hat meiner subjektiven Meinung nach einen Fehler. Als Dienstname wird der TService.Componentname in die Registry eingetragen und der ist nicht der Name, den ich dem Dienst über mein Konfigurationsprogramm eingetragen hatte. DESHALB lief der Dienst einfach nicht los. Falscher Name, das ist alles.

Ist das in D5 Pro bereits drin? Dann würde ich es mal bei uns im PC-Pool testen. Privat hab ich nur D4 Pro.

Zitat von hurzli:

Die Lösung : ein in Delphi 3 geschriebenen Dienst, der sich noch so richtig zu Fuß um alle Einträge/Aktionen selbst kümmert, auf meine Anforderungen angepasst, bringt's. Also eine Delphi 3 Dienst-Hülle mit meiner Funktionalität, wenn man das ganze so nennen will.

Und die Hülle startet "Prozesse" oder "Dienste" (ich weiß, daß Dienste auch Prozesse sind!)?

Gruß,

[sakura]

Zitat von hurzli:

Ich hatte garnicht erwartet, dass sich nochmal jemand rührt !

Ich hatte den Thread damals (vor Jahren ) gar nicht gesehen. Wir sind zwar gegen sofortiges Pushen von Fragen, aber es ist durchaus okay am Tag darauf nochmal selbst einen Beitrag anzuhängen und nachzuhaken. Bei bis zu 80 neuen Themen am Tag geht schnell mal eines unter

Also, versuche uns noch einmal wenn Du ein Problem hast

......