Batch-Programme "übertragen"

[HuBaer]

Hallo allerseits,

ich habe bisher alle "Programme" in Batch geschrieben. Leider musste ich feststellen, dass Batch ziemlich verschwenderisch mit Rechnerressourcen ist und sobald viele Batches gleichzeitig laufen, einen 900 MHz-Rechner auch scheinbar ganz schön in die Knie zwingen können (Zwischenfrage: Stimmt das?).
Nun kam mir die Idee, die Batch-Programme einfach auf eine richtige Programmiersprache zu übertragen. Eigentlich dürfte dies kein großes Problem darstellen, es werden in erster Linie nur so Sachen wie

- If-Abfragen
- Dateien erstellen/kopieren/löschen...
- Programme aufrufen (auch mit Parametern)
- Springstellen (goto...)
- For-Schleifen
- usw.

verwendet. Leider bin ich in Sachen Programmieren eher Anfänger und wollte darum euch mal fragen, ob bzw. welche Programmiersprache am besten geeignet ist, um mein Vorhaben schnell und möglichst unkompliziert zu realisieren?!

Vielen Dank!

Gruß

EDIT: Noch eine Frage: Wenn ich die Bat-Dateien mittels gebräuclicher Konerter in eine exe-Datei umwandle, sind die Programme in Sachen Ressourcenverbauch noch genauso ineffizient wie davor?

 

[AndrewPoison]

Also für Anfänger eignet sich Pascal wohl nachwievor am besten. Es wurde geradezu dafür entwickelt.

Wenns ne Spur "härter" sein soll gäbe es natürlich noch C in allen seien Formen zur wahl

Aber wie gesagt... auf ner alten PC-Welt war mal Delphi 6 PE drauf, das würde sich für deine Zwecke schon bestens eigenen.

EXE-Dateien sind nicht so "verschwenderisch" bei vielen Befehlen im Allgemeinen, da ihre Aufrufe nicht so eine CPU-Last erbringen wie es in einem Batchfile üblich ist. Dazu laufen diese Programme nicht nur schonender für den Betrieb sondern dazu noch schneller. [um deine letzte frage damit zu beantworten: ja, auch konvertierte Programme sind dann besser - solange sie vollwertige Windows-Anwendungen sind]

In dieser Ausgabe war auch ein leichtverständliches Tutorial untergebracht wie man einen Taschenrechner baut. Brauchst du zwar nicht, aber um das Handling zu verstehn würd ichs trotzdem mal nachprogrammieren. Da du allerdings schon grundlegende "Programmierkenntnisse" bzgl der Batches hast, wäre ein Einstieg sicher nicht sonderlich schwer, wenngleich die Syntax eine völlig andere ist, aber es geht ja nur ums Prinzip

Leider kann ich dir nicht genau sagen welche Ausgabe das war, nur das es schon einige Jahre her ist (ich würde sagen min. 3).

 

[HuBaer]

Das Kompilieren der Batch wird wohl die schnellste und effektivste Lösung sein?
Ich hab mir sagen lassen, dass der Intepreter die Batch jedesmal aufs neue übersetzt und dadurch die Ressourcen so verschwendet werden? Und dass ein einmaliges Compilieren schon einen Geschwindigkeitsvorteil bringt?

Der Batch-Compiler unter http://www.antonis.de/dos/index.htm#download erstellt mir aus der Batch eine Com-Datei. Wenn ich diese ausführen will, dann erhalte ich aber nur lauter Fehlermeldungen wie z.B. "Pfad nicht gefunden" usw.! An was kann das liegen?

Dann bin ich auf diesen http://www.bionic-software.de Compiler gestoßen. Dort erhalte ich aber eine Trojanerwarnmeldung, was wahrscheinlich ein Fehlalarm ist. Lasse ich die Batch nun konvertieren, habe ich wie gewünscht eine exe-Datei vorliegen. Das komsiche ist nun, wenn ich diese ausführe, dann scheint es immer noch eine Batch zu sein, auch auf der Titelleiste steht das Übliche "C:\WINNT\System32\cmd.exe". Was ist da los?

Gruß

 

[Siberian..Husky]

also eine "richtige" programmiersprache wie c(++), pascal, java oder c#, ist nun beim besten willen nicht als batch alternative zu gebrauchen.

für sowas nimmt man eine ordentliche scriptsprache. da gibts verschiedene möglichkeiten:

entweder du nimmst den windows scripting host. damit lassen sich batch scripte am einfachen portieren. zur verfügung stehen einige sprache, z.b. j-script(ecmascript/javascript) oder vbs.

oder du entscheidest dich für eine wirklich ordentliche scriptsprache, nimmst also python oder ruby. das ist ein stück komplizierter, vorallem weil die installation der sprachen unter windows für viele anfänger etwas verwirrend sein kann. ausserdem wird das portieren der batch scripte etwas komplizierter, da die mitgelieferten bibliotheken deutlich komplexer sind. daür bieten die sprachen aber auch deutlich mehr.

 

[muesler]

Wenn Deine Batch Datei das macht was Du willst, dann lass sie doch einfach wie sie ist. In der heutigen Zeit mit aktuellen CPUs wirst Du keinen Rechner mit so einer Batch Datei in die Knie zwingen...

Aber warum einfach halten, wenn's auch kompliziert geht

 

[Arnd]

Wenn Du Deinen rechner mit der Anzahl der Batches in die Knie zwingst. Wird sich das durch ein umstellen auf kompilierte Programme nicht wesentlich ändern.

Wenn Dein Rechner 900MHz hat, wieviel Hauptspeicher hast Du denn und welches OS?

Wenn Du den Hauptspeicher erweiterst, dürften deutlich mehr Batches gleichzeitig laufen können ohne den Rechner zu stark zu belasten.

MfG

Arnd

 

[AndrewPoison]

Es besteht schon ein enormer Performance-Unterschied zwischen Skripten und "echten" Programmen. Allein das ständige Interpretieren des Skripts kostet Zeit und natürlich prinzipiell erstmal die Resourcen des Interpreters, welcher noch weitere Resourcen anfordern kann und recht hohe CPU-Lasten bei geringem Tempo verursacht. Ein kompiliertes Programm hats da wesentlich einfacher

 

[Caleb]

Wenn ich Dein erstes Posting lese '- Dateien erstellen/kopieren/löschen...', '- Programme aufrufen (auch mit Parametern)
' denke ich dass das der Grund für Die langsahmer werdenden Vorgänge ist.

Festplattenzugriffe und Dateioperationen sind langsahm, und wenn Du das 2 oder 3 mal auf X Dateien anwendest ist es kein Wunder dass Dein Rechner in die Knie geht, eine schnellere Programmiersprache wird hieran nicht das geringste ändern.

 

[Arnd]

Und auch ein kompiliertes Programm wird auf einem 900 MHz Rechner mit z.B. 256MB RAM unter Windows XP seine Probleme mit der Performance haben. Vor allem wenn mehrere Anwendungen gleichzeitig laufen.
Deswegen die Frage nach der Rechnerausstattung.

Aber es ist schon richtig das eine Commandshell in der viel passiert eine hohe CPU Last erzeugt. Allerdings wird ein kompiliertes Programm das nicht mehr als eine 1:1 Portierung ist, das selbe Problem haben. Um das zu umgehen muss auch entsprechend programmiert werden.

MfG

Arnd

 

[HuBaer]

Na gut, ich versuche mal ein Problem näher zu erläutern, vielleicht kann mir ja wer weiterhelfen:

Es werden bis zu zehn Batches im Abstand von ein paar Sekunden geöffnet. Alle Batches sollen 120 Sekunden nach dem Öffnen der ersten Batch wieder schließen. Das heißt, wenn die 10. Batch erst nach 100 Sekunden geöffnet wird, soll diese schon in 20 Sekunden schließen.
Bisher hatte ich das so gelöst:

Auszug aus Inhalt der Batch:

....
....
if not exist D:\Alarmierung\Reloadsperren\Reloadsperre.tmp start D:\Alarmierung\Tools\Count120.bat & echo temp > "D:\Alarmierung\Reloadsperren\Reloadsperre.tmp"
...
...
:wait
if exist D:\Alarmierung\Reloadsperren\Count120.tmp exit
D:\Alarmierung\Tools\wait.exe 0.5
goto wait


Die Batch Count120.bat lautet so:

D:\Alarmierung\Tools\wait.exe 120
echo temp > D:\Alarmierung\Reloadsperren\Count120.tmp
del D:\Alarmierung\Reloadsperren\Reloadsperre.tmp
exit


Funktion des Ganzen: Die erste Batch startet das Programm Count120.bat. Danach erstellt sie eine temporäre Datei, damit die Count120.bat von nachfolgenden Batches nicht nochmal gestartet wird. Die Count120.bat wartet 120 Sekunden und erstellt dann die Datei Count120.tmp.
Die Batches überprüfen zweimal in der Sekunde, ob die Datei vorhanden ist. Sind die einheitlichen 120 Sekunden abgelaufen, ist die Datei da und die Batches beenden sich.

Nun ist so eine Befehlsabfolge meiner Meinung nach ziemlich "ineffektiv". Sind z.B. 10 Batches offen, wird das Wait-Programm 20 Mal in der Sekunde gestartet und 20 Mal die Existenz der Datei überprüft. Das nimmt doch ganz schön Rechenleistung?

Gruß

 

[Caleb]

Mit 'Rechenleistung' hat das nichts zu tun, sondern mit den Zugriffszeiten der Festplatte, der um den Faktor von c.a. eine Millon mal langsahmer ist als die Zugriffszeiten auf den Hauptspeicher.

Warum fragst Du aber 2 mal in der Sekunde ab ob die Datei noch existiert ? Ist in der tat ineffektiv und bedeutet ständig langsahme Dateizugriffe.
Wie wäre es wenn Du einfach die Zeit der Erstellung in der Datei Speicherst und diese nur einmal mit dem Starten der anderen Batches ausliest und dann einfach nach 120 Sek. nach Referenzzeit beendest ?

 

[Arnd]

Der Vorschlag ist zwar gut, damit stösst man aber vermutlich gleich an die Grenzen der DOS Batch Programmierung :-). Mit einem DOS Batch File aber ein File öffnen und die Zeit auslesen?

Mit z.B. Perl wäre das sicher einfach zu lösen

MfG

Arnd

 

[HuBaer]

Mit 'Rechenleistung' hat das nichts zu tun, sondern mit den Zugriffszeiten der Festplatte, der um den Faktor von c.a. eine Millon mal langsahmer ist als die Zugriffszeiten auf den Hauptspeicher.

Warum fragst Du aber 2 mal in der Sekunde ab ob die Datei noch existiert ? Ist in der tat ineffektiv und bedeutet ständig langsahme Dateizugriffe.
Wie wäre es wenn Du einfach die Zeit der Erstellung in der Datei Speicherst und diese nur einmal mit dem Starten der anderen Batches ausliest und dann einfach nach 120 Sek. nach Referenzzeit beendest ?

Meinst du, wenn ich die betroffenen Programme/Batches auf eine Ramlaufwerk schiebe, dass ich mir eine gewisse Besserung erhoffen kann?

Gruß

 

[Siberian..Husky]

eigentlich solltest du sowas so garnicht machen. dafür sind bats nicht gedacht. du solltest dir dringend eine ordentliche scriptsprache ansehen, ein paar interessante kannst du ja aus meinem ersten posting hier entnehmen .