C-Commandline Programm für Windows entwickeln

Andi schrieb:

> Könnt ihr mir einen einfachen Weg für meine Zwecke weisen?
> Cross-Entwicklung (mingw, cygwin)?

Cygwin hat den Vorteil, daß es wesentlich ähnlicher zu Linux wäre, 
solange Dir das in 32 bit ausreicht (außer die haben inzwischen auch 64 
bit). Du brauchst dann aber die Cygwin-DLL dazu, was zum Hausgebrauch 
und auch für GPL-Programme kein Problem ist, sonst aber U.u. schon.

MingW hingegen erzeugt Dir Windows-Programme in "richtig nativ", aber um 
den Preis, daß Du dann auch Windows-spezifisch programmieren mußt. Das 
ist bei Dateien kein Problem, weil man das ja sowieso mit den 
Standardfunktionen von C macht, aber bei den Sockets wird es 
ungemütlicher.

Nop schrieb:
> Cygwin hat den Vorteil, daß es wesentlich ähnlicher zu Linux wäre,
> solange Dir das in 32 bit ausreicht (außer die haben inzwischen auch 64
> bit). Du brauchst dann aber die Cygwin-DLL dazu, was zum Hausgebrauch
> und auch für GPL-Programme kein Problem ist, sonst aber U.u. schon.

32bit reichen sicher aus.
DLL ist kein Problem und Lizenzprobleme sehe ich auch keine.


> MingW hingegen erzeugt Dir Windows-Programme in "richtig nativ", aber um
> den Preis, daß Du dann auch Windows-spezifisch programmieren mußt. Das
> ist bei Dateien kein Problem, weil man das ja sowieso mit den
> Standardfunktionen von C macht, aber bei den Sockets wird es
> ungemütlicher.

Riecht das etwa nach winsocket?
Das habe ich noch in schlechter Erinnerung ... und würde lieber einen 
grossen Bogen um das Thema machen ;)

Also werde ich mir mal cygwin anschauen...

Danke, andi

Ich verstehe nicht, warum immer wieder Cygwin empfohlen wird - das Teil 
ist nen einziger Hack. Mag ja ok sein, um irgendwelche Posix-Programme 
zu bootstrappen, aber nichts für den Normalgebrauch - darin geschriebene 
Programme sind wie ein Fremdkörper im System.

Mingw dagegen kann ich empfehlen. Erstellt kleine Programme, und im 
Gegensatz zu Microsofts Compilern, ohne zusätzliche 
Runtime-Abhängigkeiten. Für Konsolenanwendungen genau das richtige. Mit 
etwas Sorgfalt läuft ein und dasselbe Programm dann auf allen 
Windows-Versionen ab 2000.

Für aufwendigere GUI-Anwendungen dürfte allerdings Visual-C & Co am 
einfachsten sein.

> Riecht das etwa nach winsocket?
> Das habe ich noch in schlechter Erinnerung ... und würde lieber einen
> grossen Bogen um das Thema machen ;)

Ne einfache TCP-Verbindung aufmachen und Daten austauschen geht mit 
winsock doch genau so wie unter Linux - die Funktionen heißen nur etwas 
anders.

Wenn du dir aber mal anschaust, was Cygwin für Klimmzüge macht, um 
select(2) zu implementieren ...


PS: im vorigen Post muss es "ab Windows NT" heißen ;-)

Ich werfe mal C++ mi Qt ins Rennen...

Vorteil:
+ Sourcecode für Win, Linux "Mac" nutzbar (kompilierbar)
+ Bietet Netzwerkklassen (TCP/UDP Basis und auch einige Server-Klassen)
+ Wenn eine GUI benötigt wird, ist alles dabei...
+ Kompilieren unter Windows mit Visual Sudio (Community Studio reicht) 
oder auch mingw möglich
+ Qt-Creator als Entwicklungsumgebung für Linux, Windows (nutzt dann 
Debugger von VS) und Mac

Nachteil:
- Das Framework ist schon ziemlich "fett"
- Nicht wirklich "Keep it simple"

läuft der python code auch mit pypy zu langsam?

Naja, ähnlich ;-) Man muss schon einiges ändern: aus dem Kopf (ist schon 
ne Weile her): WSAStartup/WSACleanup am Anfang/Ende, nen Socket ist kein 
int, statt read/write/close recv/send/closesocket, anderes 
Errorhandling.

Andi schrieb:
> Leider ist es ein wenig (ok, viel) zu langsam, ich werde es also in C
> neu schreiben.


Bist du dir sicher, dass du das nicht einfach nur falsch machst?

Gerade bei Python kann man als alter C Programmierer viel in der 
Performance versauen. Viele Dinge werden in Python anders gelöst und 
sind im C-Style deutlich langsamer.

Felix U. schrieb:
> Bei read/write stimmt es schlicht nicht, die sind POSIX und gibt es
> dementsprechend auch.

Die funktionieren allerdings unter Windows nicht auf Sockets.

> recv/send sind auch Teil der Berkeley API und sollten auch unter Unix
> verwendet werden, dafür sind sie ja da.

Sowohl read()/write() als auch recv()/send() sind erlaubt, denn auch 
Sockets sind FDs.

Es kann sogar passieren, dass stdin und stdout Sockets sind, z.B. beim 
Start durch inetd.

Andi schrieb:
> Könnt ihr mir einen einfachen Weg für meine Zwecke weisen?

Bin jetzt so eher der embedded C Gelegenheitsprogger aber vielleicht 
hilft es:

Für Windows nutze ich Pelles C Compiler. Ist so schön simpel und für 
Commandline gibt es eine Vorlage.

Erstmal danke für die vielen Varianten ... viele Wege führen nach Rom ;)

Habe jetzt viel Lesestoff für die nächsten Tage.

cython und pypy werde ich auf jeden Fall mal ausprobieren.

nicht"Gast" schrieb:
> Bist du dir sicher, dass du das nicht einfach nur falsch machst?

Ha! Nein natürlich nicht.
Andersrum: Ich bin mir sicher, dass ich in python vieles falsch mache ;)

> Gerade bei Python kann man als alter C Programmierer viel in der
> Performance versauen. Viele Dinge werden in Python anders gelöst und
> sind im C-Style deutlich langsamer.

Da gebe ich dir 100%ig recht.
Mein ständiger Kampf wenn ich mit python arbeite ;)
Trotzdem mag ich die Sprache recht gerne...

Allerdings ist gerade der kritische Teil sehr einfach gestrickt.

Zur Erklärung: Es ist eine relativ einfache Server-Client Applikation.
Der Server läuft auf einer Arm mit FreeRTOS und lwip im Raw-Modus.
Der Client auf einem PC und eben momentan in Python.

Client:
- Daten aus Datei auslesen
- Daten senden.
- Empfangene Daten einlesen.
- Und in eine andere Datei schreiben.

Zur Simulation habe ich einen einfachen Server auch in Python am Laufen:
- Daten empfangen und gleich wieder senden (quasi Echomodus)

Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.
Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.

Momentan ausreichend, da die Zielhardware aktuell nicht mehr als 
50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren 
500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern 
;)

Windows 10 enthält ein komplettes Linux Subsystem, man muss es nur 
aktivieren.  Ich arbeite aber trotzdem immer noch mit Cygwin weil 
Openssh in diesem neuen Subsystem nur eingeschränkt funktioniert.

asdfasd schrieb:
> Ich verstehe nicht, warum immer wieder Cygwin empfohlen wird - das
> Teil ist nen einziger Hack.

Zum Entwickeln mag ich das ganz gerne, insbesondere weil ich nicht 
dauernd Linux hochfahren muß, nur um zu checken, ob es auch mit Linux 
durchcompiliert. Und ich habe keine Lust, dafür jetzt mit VMs 
herumzufummeln.

Außerdem bietet Cygwin auch GDB im Terminal, den ich hin und wieder mal 
nutze. Meistens bei vertrackten Segfaults, deren Ursache nicht auf 
Anhieb ersichtlich ist.

Eine Einschränkung bei Cygwin ist allerdings, daß die sanitizer-Optionen 
von GCC nicht funktionieren. Das geht nur mit nativem Linux. Schade 
eigentlich, denn die sind für Test/Debug-Runs sehr nützlich.

Oder auch, um mal eben schnell kleinere Linuxprogramme ans Laufen zu 
bringen.

Andi schrieb:
> Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec.
> Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec.
>
> Momentan ausreichend, da die Zielhardware aktuell nicht mehr als
> 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren
> 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern

Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um 
mich Nichtigkeiten widmen zu können :)

War kein Witz. ich bin wirklich neidisch.

> Widerspruch! C++, na klar -- aber ein GUI-Framework wie
> Qt für eine reine Konsolenanwendung?

Und schon wieder jemand, der Qt nur als GUI Framework kennt.

Tatsächlich ist die Qt GUI Komponente ein optinaler Teil von Qt. Die 
anderen Komponenten kann man sehr gut auf der Kommandozeile nutzen. 
Gerade für Netzwerk Anwendungen stellt Qt viele hilfreiche Sachen 
bereit.

Das Tutorial von meinem Webserver zeigt, wie man Qt in Konsole 
Anwendungen nutzt: http://stefanfrings.de/qtwebapp/index.html

Das Framework ist übrigen nicht "ziemlich fett". Die Java Runtime und 
.NET sind wesentlich umfangreicher. Abgesehen davon insteressiert das 
heutzutage niemanden mehr, der Geld für Softwareentwicklung ausgibt.

In den 90er Jahren gab es mal eine Firma, die haben es geschafft, ein 
Unix ähnliches Betriebssystem mit grafischem Desktop, Dateimanager, 
Email Client und Web Browser auf nur 2 Disketten zu packen. Das war 
damals noch cool, heute interessiert es niemanden mehr.

Wir leben in einer Zeit, wo handelsübliche Mikrocontroller (keine 
Exoten) schon mit 1MB internem Flash Speicher zu haben sind und bei PC's 
zig MB für UEFI verballert werden. Fotos werden standarmäßig mit 
12Megapixel und geringer Kompression gespeichert und bei Webseiten 
scheint es keine Sau mehr zu interessieren, ob der Download einer 
einzelnen Seite ein paar zig kB oder 2MB umfasst.

Die Maßeinheit "kiloByte" verliert an Bedeutung. Viele Laien wissen 
nichtmal, was das bedeutet. Sie kennen nur Megabytes und Gigabytes.

> Client:
> - Daten aus Datei auslesen
> - Daten senden.
> - Empfangene Daten einlesen.
> - Und in eine andere Datei schreiben.
>
> Zur Simulation habe ich einen einfachen Server auch in Python am Laufen:
> - Daten empfangen und gleich wieder senden (quasi Echomodus)

dieser Beschreibung nach also nichts was NetCat (nc.exe?) nicht schon 
kann.
Warum also doch eigene Quellcode (Erstellungs- & Wartungsaufwand) und 
Binary (Testaufwand)?
Und: wie schlägt sich nc durchsatzmässig denn so im Vergleich?

nicht"Gast" schrieb:
> Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um
> mich Nichtigkeiten widmen zu können :)
> War kein Witz. ich bin wirklich neidisch.

Wenn du das Erreichen der Projekt-Zielvorgaben als Nichtigkeit 
bezeichnen kannst, bin ich neidisch auf Deinen Job ;)


Kaj G. schrieb:
> Arbeitest du mit dem threading-Modul?
>...
> Mit dem multiprocessing-Modul geht das.

Nein, ich habe bisher nur ein paar Versuche mit coroutinen und asyncio 
gemacht.
Dabei hatte ich allerdings das Problem dass ich das Senden und Empfangen 
nicht auf 2 Routinen aufsplitten konnte.

Ja, da waren sie wieder meine Python-Schwächen ;)

Aber eigentlich brauche ich das nicht, da die Datenmenge in beide 
Richtungen identisch ist. Ich muss also nur dafür sorgen dass die 
Zielhardware ein wenig mehr Daten kriegt um die Latenzzeiten 
auszugleichen.

Sheeva P. schrieb:
> Wenn Du eher kleine Frames versendest, ist das vollkommen normal, denn
> dann steigt der Overhead des Protokolls.

Das ist klar.
Aber auch wenn ich grössere Frames nehme steigt der Durchsatz nicht 
wirklich großartig an.

> Naja, wenn Du entsprechend viele Sensoren hast, und je nachdem, was Du
> auf diesem PC machst... Wie gesagt: vielleicht sagst Du mal ein bisschen
> mehr über Anwendungsfall, Applikation, und Protokoll. ;-)

Am PC passiert sonst nicht wirklich wesentliches mit den Daten.
Die eigentlich Arbeit macht die Zielhardware.

Kommandozeile vor dem Frühstück für Alle! schrieb:
> dieser Beschreibung nach also nichts was NetCat (nc.exe?) nicht schon
> kann.

Für diesen Test hätte nc wahrscheinlich gereicht (wenn ich daran gedacht 
hätte) ;)

> Warum also doch eigene Quellcode (Erstellungs- & Wartungsaufwand) und
> Binary (Testaufwand)?

Soo aufwändig war das Erstellen der Testprogramme unter Linux nicht 
wirklich.

Die Entscheidung ist doch: Kann ich mit Python weiterarbeiten oder muss 
ich auf C umsteigen. Beides parallel zu machen habe ich nicht vor ;)

> Und: wie schlägt sich nc durchsatzmässig denn so im Vergleich?

Meine kleinen C-Programme unter Linux in einer VBOX zeigen dass ich 
schnell genug werde.
Tests auf einer echten Linuxmaschine stehen allerdings noch aus.
Aber wenns in der VBOX schon reicht, sollte es mit nativen 
Windowsprogrammen erst recht klappen.

Ich mag Python aber trotzdem noch nicht aufgeben und werde meine 
Programme aufräumen, aufs wesentlich reduzieren und hier reinstellen.
Vielleicht mag ja einer der Pythonspezialisten mal drüberschauen und 
meine Lücken aufdecken;)

Wird aber ein paar Tage dauern...

Danke einstweilen noch einmal für die vielen Anregungen!

Ich habe vor >10 Jahren mal Code geschrieben, der TCP Zeug macht und 
sich im Visual Studio und mit dem gcc kompilieren lässt. Als Anhang ein 
Tool, das Daten aus einer TCP Verbindung liest und in eine Datei 
schreibt. Das ganze mit select() und so. Ist von 2014, der olle Code 
funktionierte immer noch :)

in scanner.c wird die Winsock initialisiert/runtergefahren, ansonsten in 
s400w ein bissel was mit #ifdef (oopensocket) umgebogen. select() selber 
ist für Windows und Unix identisch.

Andi schrieb:
> nicht"Gast" schrieb:
>> Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um
>> mich Nichtigkeiten widmen zu können :)
>> War kein Witz. ich bin wirklich neidisch.
>
> Wenn du das Erreichen der Projekt-Zielvorgaben als Nichtigkeit
> bezeichnen kannst, bin ich neidisch auf Deinen Job ;)

Das deine Vorgaben strenger sind konnte ja keiner Ahnen. Du hattest was 
von 50 MBit geschrieben, die der Controller kann.

Welche Geschwindigkeiten sollst du denn erreichen?

Gibt es für Python eigentlich einen Profiler, dass man schauen kann, wo 
die Zeit verloren geht?

nicht"Gast" schrieb:
> Das deine Vorgaben strenger sind konnte ja keiner Ahnen. Du hattest was
> von 50 MBit geschrieben, die der Controller kann.
>
> Welche Geschwindigkeiten sollst du denn erreichen?

Ich habe geschrieben 'aktuell':

Andi schrieb:
> Momentan ausreichend, da die Zielhardware aktuell nicht mehr als
> 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren
> 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern ;)

Das heißt dass die Jungs in der Hardwareabteilung auch noch Gas geben 
müssen (und das auch tun)

;)

Wenn's spartanisch sein darf und 32-bit reichen:
http://www.delorie.com/djgpp/

(größere Projekte würde ich damit nicht aufsetzen wollen, aber für 
quick&dirty ausreichend)

Kaj G. schrieb:
> Sheeva P. schrieb:
>> Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine
>> reine Konsolenanwendung?
> Ich haette gedacht, dass gerade Du es besser weisst :(

Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist 
und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor 
allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres 
Handling im Zusammenspiel mit den GUI-Teilen zu haben. Die andere 
Alternative wäre wohl gewesen, die damals bereits vorhandenen Teile von 
Qt an die STL anzupassen.

Andi schrieb:
> Die Entscheidung ist doch: Kann ich mit Python weiterarbeiten oder muss
> ich auf C umsteigen. Beides parallel zu machen habe ich nicht vor ;)

Dabei ist das gar nicht so schwierig. Du könntest

 - die lahmen Teile Deines Python-Programms durch eine Extension 
ersetzen,
   die wahlweise in C (siehe Python-Dokumentation oder Cython) oder in 
C++
   (siehe dazu die C++-Bibliothek boost::python) geschrieben sein kann

 - Dein Python-Programm mit nuitka in C++ und darüber in nativen Code
   übersetzen

 - einen anderen Python-Interpreter wie Jython oder Pypy benutzen

> Ich mag Python aber trotzdem noch nicht aufgeben und werde meine
> Programme aufräumen, aufs wesentlich reduzieren und hier reinstellen.
> Vielleicht mag ja einer der Pythonspezialisten mal drüberschauen und
> meine Lücken aufdecken;)

Wahrscheinlich wäre es nicht die schlechteste Idee, zunächst einmal die 
Performanceengpässe in Deinem Code zu identifizieren, sprich: einen der 
vorhandenen Python-Profiler oder ggf. gprof zu benutzen.

Für mich als hauptsächlicher Java Programmierer fühlt sicht Qt viel 
gewohnter an, als stl. Das ist bei mir der Hauptgrund, warum ich es 
gerne nutze.

> vor allem deswegen hineingebaut wurden, um ein konsistenteres,
> einfacheres Handling im Zusammenspiel mit den GUI-Teilen zu haben.

Ja das sehe ich auch so. Ich kenne Qt seit Version 1.irgendwas. 
Allerdings ist das kein nachteil (mehr). Da sind viele nützliche Sachen 
drin, die abseits der GUI prima funktionieren. Der Verzicht auf die GUI 
macht hier nichts komplizierter, als nötig.

Ich denke, er wollte nur den historischen Grund nennen, warum Qt häufig 
noch als GUI Framework bezeichnet wird.