Total Process Control <---- Programmer gesucht!

[Tylerandy]

Hallo an alle, hier im Forum,

Ich möchte gern ein paar Programmer anwerben, ein kleines Utilitie zu programmieren, dass sich durchaus als sehr sinnvoll erweisen kann.

Es handelt sich um ein Programm, das den Namen "Total Process Control" erhalten soll. Dabei handelt es sich um ein kleines Utilitie, das wie folgt arbeiten sollte:

Das Programm soll folgende Aufgabe erfüllen: Es soll Windows durch Optimierung der Prozesse stabieler machen. Das höhrt sich jetzt zunächst mal so an, als müsste man jetzt via API in jeden Prozess eingreifen, aber so kompliziert muss es nicht sein.
Was das Programm machen soll, wird unten gleich mit einem Beispiel erklährt.

Das Programm hat keine GUI, ihr müsst also nur den Algorithmus, den das Programm ausführen soll, programmieren.
Wenn das Programm gestartet wird, wird in der Task-Leiste ein Tray-Icon abgelegt, mit dem man das Programm wieder beenden kann (via Rechtsklick - Beenden).
Um das Programm trotzt fehlenden GUI trotzdem zu steuern, wird die einfache Methode verwendet, dass sämtliche Einstellungen einfach in eine INI-Datei geschrieben werden, die dann vom Programm ausgelesen wird.

Dabei sollte die INI wie folgt aufgebaut sein:

--------------------------------------------Muster-INI----------------------------------------------

[GeneralOptions] <--- Abschnitt für die allgemeinen Programm Optionen.
AtWindowsStartUp = 1 <--- Legt fest, ob das Programm beim Start von Windows mitstartet.
ChangePrioAtDefUsage = 1 <--- Damit ist "ChangePrioAtUsageOf" aktiviert.
ChangePrioAtUsageOf = 85 <--- Dies ist in meinen Augen eine geniale Funktion, die hilft, das System stabiler zu halten. Wird unten erklährt.
ChangePrioAtUsageTo = 0 <--- Definiert die zuzuweisende Priorität durch "ChangePrioAtUsageOf". Näheres zu diesen drei Optionen unten.

[AutoExecDefinition] <--- Hängt mit der weiter unten zu findenden Option "AutoExec = [Zahl]" zusammen. Näheres unten in der Dokumentation.
Batchdatei1.BAT = 1 <--- Definiert die Datei "Batchdatei1.BAT" als Nr.1.
VBSskript2.VBS = 2 <--- Definiert die Datei "VBSskript.VBS" als Nr.2.
Exe-Datei3.EXE = 3 <--- Definiert die Datei "Exe-Datei3.EXE" als Nr.3.

[ProcessDefinition] <--- Hier werden die Prozesse eingetragen, für die später dann Parameter definiert werden können.
cmd.exe = 1 <--- cmd.exe ist also hier Nr.1
notepad.exe = 2 <--- notepad.exe wird als Nr.2 definiert.
.
.
.

[ProcessParameters] <--- Abschnitt für die Parameter, die für die definierten Prozesse übernommen werden.
ApplyFor = 1 <--- Die folgenden Parameter werden auf den Prozess angewendet, der als Nr. 1 definiert wurde (hier: cmd.exe).

AssignToCore = 02 <--- Bei Dual-Core Prozessoren, wird der Prozess in diesem Fall auf dem 2.ten Core ausgeführt.
Priority = 3 <--- Setzt die Prozess Priorität von "cmd.exe" auf 3, also auf "Höher als Normal".
Minimize = 0 <--- Hält den Prozess minimiert, wenn er ein oder mehrere Fenster hat.
Maximize = 1 <--- Hält den Prozess maximiert, wenn er ein Fenster hat.
Hide = 0 <--- Hält die Fenster versteckt.
ExcludeFromLowSet = 1 <--- Schließt diesen Prozess von der Anwendung der Option "ChangePrioAtDefUsage" Befehls aus.
AutoExec = 2 <--- Führt die als Nr.2 definierte AutoExec Datei aus (hier: VBSskript.VBS). Näheres dazu unten in der Dokumentation.
ExecutionInterval = 60 <--- Gehöhrt zu der Option "AutoExec". Wird ebenfalls unten erklährt.


ApplyFor = 2

Minimize = 0
Maximize = 1
Hide = 0
.
.
.
--------------------------------------------Muster-INI Ende----------------------------------------------

So, das war meine Muster-INI.
Ich habe versucht, den Aufbau INI-gerecht zu gestalten, so dass das Auslesen und verarbeiten der Optionen halbwegs leicht von der Hand gehen sollte.
Sieht auf den ersten Blick sehr kompliziert aus, aber das is es gar nich.
Ihr werdet sehen, dass das gar nicht so komplex ist, wie es aussieht.

Noch was zu den Einzelnen Funktionen (Dokumentation):
Die Option "ChangePrioAtDefUsage" ist eine, in meinen Augen, geniale Option, die maßgeblich zur Stabilität des Systems betragen kann.
Undzwar handelt es sich bei dieser Option um eine Funktion, die allen Prozessen, die in diesem Fall 85% (ChangePrioAtUsageOf = 85) oder Mehr an CPU Leistung benötigen automatisch die Prozess Priorität Low (ChangePrioAtUsageTo = 0) zuweist.

0 = Low/Niedrig
1 = BelowNormal/Niedriger als Normal
2 = Normal/Normal
3 = AboveNormal/Höher als Normal
4 = High/Hoch
5 = Realtime/Echtzeit

Dazu kann man mit der Option "ExcludeFromLowSet = 1" auch Prozesse definieren, die von dieser Funktion ausgeschlossen werden, was besonders z.B. bei Spielen und wichtigen Windows-Prozessen logisch sein dürfte.

"Priority = [Zahl]" setzt die Priorität des Prozesses auf die definierte Priorität.

Was noch zu erwähnen wäre, wäre, dass die Option "SetLowAtUsageOf" natürlich höhere Priorität als die Option "Priority" hat. Damit will ich sagen, dass wenn jetzt z.B. cmd.exe über 85% braucht und damit auf "Niedrig" gestellt wird, dass dann die Option "Priority = [Zahl]" die Priorität wieder, in diesem Fall, auf 3, also auf "Höher als Normal" hebt.

Noch zu erläutern wäre der Abschnitt und die damit verbundene Option "AutoExec".
Im Abschnitt "[AutoExec]" wird den auszuführenden Skripten/EXE-Dateien, wie
bei den Prozessen, eine Nummer zugewiesen.
Diese Zahlen werden dann mit der Option "AutoExec" verwendet (AutoExec = 2).
Die dazugehöhrende Option "ExecutionInterval" legt fest, in welchen
Zeitabständen diese Datei/Skript ausgeführt wird. In diesem Fall ist es 1 Min. (ExecutionInterval = 60 <--- 60 sec.), wobei auch eingestellt werden kann, dass die Datei/Skript nur einmal ausgeführt wird, undzwar z.B. mit "ExecutionInterval = -15". Durch das negativieren der Zahl wird festgelegt, dass die Datei/Skript nur EINMAL, undzwar 15 sec. nach dem Starten des Prozesses ausgeführt wird.

"AssignToCore = [Zahl]" ist auch in meinen Augen eine tolle Option, die besonders die zunehmende Zahl von Dual-Core Prozessor Besitzern erfreuen wird. Dadurch kann man individuell für jeden Prozess festlegen, auf welchem Kern er ausgeführt wird. Dann kann man z.B. einen Kern für wichtige Aufgaben frei haben, während der andere alle wichtigen Hintergrund Operationen verarbeitet.
-----------------------------------------------------------------------------------------------------

So, jetzt werdet ihr sicher denken, "OMG, was will der bloß von mir! Wie soll ich das hinkriegen!?". Besonders, da ich die AssignToCore-Option da reingeschrieben habe, wird da jetzt ne Menge aufstöhnen, aber ich sag's vorweg: Dafür gibt's ne schöne Hilfe, die euch noch nen schönen Teil Arbeit abnehmen kann: Sie heißt "Process.exe" und ist ein kleines Commandline-Utilitie, das mit Parametern bedient wird. Das kleine Prog kann Programme beenden, terminieren, anhalten und wieder fortsetzen, ihre Priorität ändern und, ganz wichtig, DIE AFFINITY MASKE DER PROZESSE ÄNDERN, sprich Sie kann die Prozesse Kernen in einem Multi-Kern Prozessor zuweisen, die Sie dann verarbeiten, womit das Problem geklährt wäre.
Interessierte Programmer schicken mir einfach eine PN, dann schicke ich ihnen die Datei.

Wenn Ihr das Command-Tool mit TotalProcessControl benutzt, sorgt bitte dafür, dass keinerlei Kommando-Fenster angezeigt werden und dadurch aktive Fenster inaktiviert werden. Es wäre nervig, wenn man z.B. gerade einen Text schreiben würde, aber dann keine Buchstaben mehr auf dem Bildschirm erscheinen, weil das Fenster inaktiviert wurde.

Wenn's geht sollte das Programm möglichst in Echtzeit laufen. Besonders rasch sollten die Prioritäten den Prozessen zugewiesen werden, wenn diese gestartet werden. Dennoch wäre es höchst wünschenswert, wenn das Programm selbst den Prozessor wenig belasten würde. Der Arbeitsspeicher, denn das Programm braucht sollte wenn möglich 32MB nicht überschreiten, wobei ich das aber sowieso bezweifle.

---------------------------------------------------------------------------------------------------------------------

So, das war's von meiner Seite. Ich hoffe ihr hab alles verstanden. Wenn nicht, einfach PN an mich und fragen.
Ich hoffe, es werden sich hier die ein oder anderen melden...






MfG Tylerandy

[Lukas]

Sprich, du willst, dass dir jemand was programmiert, mit dem du ein command line-Programm als Daemon laufen lassen und via Config-File konfigurieren kannst?

[Tylerandy]

Ähm neee,

es sollte schon ne normale WIN32-Anwendung sein mit allem drum und dran (nur halt ohne GUI). Die Process.exe sollte nur eine Hilfe sein, falls jemand beim programmieren dieser Optionen Probleme hat. Besser wär's natürlich, wenn man ohne Process.exe auskommt, aber ich weiss ja nicht, wie aufwändig so eine Option zu programmieren ist, besonders mit der Änderung der Affinity Mask und so.

Wie gesagt es soll bloß eine Hilfe sein. Ich kenn mich in Programmiersprachen nur
begrenzt aus, aber ich dachte, dass man die Process.exe dann so z.B. shellexecute('Process.exe -a 02 firefox.exe')
winhide('Process.exe';Windows..) benutzt oder wie auch immer man sowas programmiert. Ich spreche nicht von einer Emulation. Das ist keine EXE-Datei à la
Quick-Basic oder Command.com, sonder eher so, wie die CMD.exe

[dead_orc]

Ich hoffe, ich liege nicht falsch, wenn ich dir sage: Das wird hier niemand machen.

Aber lass mich etwas weiter ausholen: Wenn jemand ankommt "programmiert mal für mich $xy" macht das nen seeeehr schlechten Eindruck. Nicht nur auf mich, da bin ich mir sicher. Das wird auch nicht dadurch besser, dass du ständig schreibst "das ist gar nicht so schwer, glaubt mir!". Woher willst du das wissen, wenn du, wie du selber sagst, kaum Ahnung von Programmiersprachen hast? Alleine ein Fenster zu verstecken das nicht der Anwendung selber gehört ist nicht das Simpelste. Außerdem weiß ich nicht, wo du eine Process.exe hast, mein Windows zumindest hat die nicht.

Ich mach dir nen Vorschlag: Du lernst ne Programmiersprache (und weil du ja Windows benutzt und wahrscheinlich nichtmal weißt, was Python ist, wird diese vermutlich C[++] sein) und wir helfen dir dann bei der Realisierung dieses Programms. Denn so konkrete Vorstellungen wie du hast wäre das wirklich das Einfachste.

[Tylerandy]

Aaaaalso,

erstmal komm ich nicht einfach hier an und sag "programmiert mal Prog XY"!
Ich mag ja nicht so wirklich Ahnung hab, wie man jetzt Syntaxgenau ein Programm schreibt und Fenster mit Check- Radio- oder anderen Boxen macht, aber ich kenn mich grob aus und hab halbwegs ne Ahnung, wie sowas ungefähr funktioniert. Teilweise kann ich das durch meine kleinen BASIC Kenntnisse auch nachvollziehen, aber nur teilweise...

Die Process.exe, oder wie es sich offiziell nennt "Command Line Process Utilitie", ist ein Tool von BeyondLogic (http://www.beyondlogic.org). Copyright(C) 2002-2003 Craig.Peacock@beyondlogic.org.
Gehört nicht zur Standartausstattung von Windows, da muss man eine Weile suchen und das Tool ist wirklich eine große Hilfe finde ich zumindest, wenn ich mal das ein odere andere batche.

Im übrigen weiss ich, was Python, C++, Java und die anderen Programmiersprachen sind!

Außerdem: Eine Vorversion des Programms habe ich schon. Sie heißt ProcessControl, wurde in Java geschrieben und weisst den Prozessen fast in Realtime ihre Priorität zu.
Es gibt durchaus Leute, die sowas gerne freiwillig machen, weil sie Spaß daran haben!

[Ineluki]

Irgendwie bezweifle ich, dass die ganze Strategie fruchten wird.
Normalerweise sollte man nicht in der Priority-Strukturierung rumpfuschen, schon gar nicht unter Windows. Des weiteren bringt es doch gar nichts, generell jedem Programm, das viel Rechenzeit benoetigt, selbige zu verweigern, und Programmen, die keine Rechenzeit benoetigen selbige Zuzuschanzen. Das ist so, wie wenn bei einer Hungersnot das Essen nur an diejenigen ausgeteilt wird, die schon satt sind.

Die Loesung mit der INI Datei ist auch nicht gerade optimal. Und eine GUI zum Konfigurieren zu erstellen ist (zumindest in einigen Sprachen/IDEs) nicht aufwaendiger, als das lesen aus der Ini-Datei, da man sich die GUIs per Drag&Drop zusammenstellen kann. Gerade fuer solche Programme ist Delphi oder Lazarus geradezu predestiniert (solltest du dir mal ansehen).

Anstatt das mit der Process.Exe zu machen sollte man wohl lieber auf die gute alte Windows-API zurueck greifen. Wenn die Process.Exe es kann, kann es auch die API (gerade bei so kernnahen Aufgaben) und man hat mehr Kontrolle anstatt einem anderen Programm zu vertrauen.

Allerdings stimme ich Dead_Orc zu, dass Auftraege "Ich will A, also kuemmert euch" hier nicht gern gesehen sind. Die meisten hier sind mit ihren eigenen Projekten bereits ausgelastet. Es ist ja nicht so, dass wir die ganze Zeit vor dem Rechner sitzen, Daeumchen drehen und gruebeln "Was koennte ich heute programmieren, mir ist so langweilig." Wenn du so etwas selbst versuchen willst, und da viel Zeit und Energie hineinstecken willst, geben wir gerne Hilfestellungen, und helfen auch mal mit, etwas aus der API rauszusuchen. Allerdings sind wir keine kostenlosen Arbeitssklaven.

Da das Programm nur auf Windows zu laufen braucht, empfehle ich wirklich hierfuer Delphi zu verwenden. So ein Programm braucht keine Extremoptimierungen und sonstwelche Lowlevel Tricks wie in C, eine GUI ist schnell erstellt, man hat vollen Zugriff auf die WindowsAPI auch ohne die DLLs direkt anzusprechen und es gibt fertige OpenSource Zusatzkomponenten, die einem ein Programm in den Tray verstecken, etc.

[Tylerandy]

Normalerweise sollte man nicht in der Priority-Strukturierung rumpfuschen, schon gar nicht unter Windows.

...

Nun ja, ich hab da so das ein oder andere Prog im Hintergrund, die nicht unbedingt die wichtigsten sind und deshalb die Performance nicht beeinträchtigen sollten.

Des weiteren bringt es doch gar nichts, generell jedem Programm, das viel Rechenzeit benoetigt, selbige zu verweigern, und Programmen, die keine Rechenzeit benoetigen selbige Zuzuschanzen.

...

Dafür gibt es die Ausnahmen Definition, bzw. könnte man es auch anders rum machen, also die Option nur für Prozesse aktivieren, die viel Rechenpower brauchen.
Ich hab mir die Option nicht ausgedacht, um jetzt z.B. Rendering oder andere Programme in der Art auszubremsen, aber es gibt manchmal die ein oder anderen Programme, die ziemlich viel Rechenpower brauchen, obwohl sie weniger taugen.
Oder wer hat nicht mal was von einem Prozess gelesen, der aufgrund eines Fehlers zu viel Rechenpower braucht und Windows deshalb einfriert?

Die Loesung mit der INI Datei ist auch nicht gerade optimal. Und eine GUI zum Konfigurieren zu erstellen ist (zumindest in einigen Sprachen/IDEs) nicht aufwaendiger, als das lesen aus der Ini-Datei, da man sich die GUIs per Drag&Drop zusammenstellen kann.

...

Wenn das so einfach ist, kann man das ja machen. Hätt ich auch nix dagegen...

Anstatt das mit der Process.Exe zu machen sollte man wohl lieber auf die gute alte Windows-API zurueck greifen. Wenn die Process.Exe es kann, kann es auch die API (gerade bei so kernnahen Aufgaben) und man hat mehr Kontrolle anstatt einem anderen Programm zu vertrauen.

...

Wie gesagt: Das sollte nur eine Hilfe sein...

[Lukas]

Dafür gibt es die Ausnahmen Definition, bzw. könnte man es auch anders rum machen, also die Option nur für Prozesse aktivieren, die viel Rechenpower brauchen.
Ich hab mir die Option nicht ausgedacht, um jetzt z.B. Rendering oder andere Programme in der Art auszubremsen, aber es gibt manchmal die ein oder anderen Programme, die ziemlich viel Rechenpower brauchen, obwohl sie weniger taugen.
Oder wer hat nicht mal was von einem Prozess gelesen, der aufgrund eines Fehlers zu viel Rechenpower braucht und Windows deshalb einfriert?

...

Wenn Windows einfriert, ist eh alles zu spaet. Wenn ein Prozess einfach "nur" extrem viel Rechenpower frisst, kann man ihn auch gleich abschiessen - wenn er die Rechenpower dann nicht kriegt, wird er naemlich eh nie fertig mit dem, was er tut.

[Tylerandy]

Ja, schon war. Man könnte ja so eine Option a la "NotifyAtHighUsage" einbauen. Erst wird der Prozess in seiner "Fresssucht" mal gedrosselt und dann wird der Benutzer in Kenntnis gesetzt, was man denn nun damit machen soll (beenden, ignrorieren, anhalten etc.) oder so...