Welches Tool um einfaches Programm zu erstellen?

[_Gast (Gast)]

Vorwort: Ich bräuchte ein Programm auf Windows, um bei der Änderung 
einer Datei, diese über UART zu senden.

Design (siehe Anhang):

- Auswahl COM Port und Baudrate
- "..." Auswahl der zu überwachenden Datei
- Darstellung des Nachrichtenverlaufes (< vor ausgehenden und > vor 
eingehenden Nachrichten), halbduplex ist ausreichend
- Fenster mit letzter eingehenden Nachricht welche einen bestimmten Code 
davor hatte.


Funktion:

Auswahl COM Port und Baudrate: Es soll möglich sein, den gewünschten COM 
Port und die für die Übermittlung verwendete Baudrate aus zu wählen. 
Sobald ein COM Port und die Baudrate ausgewählt worden ist, soll eine 
entsprechende Nachricht per UART gesendet werden.

Auswahl Datei: Über den Button [...] soll eine Datei ausgewählt werden 
unabhängig ihrer Endung (theoretisch nicht größer 1MB). Sonald diese 
Datei ausgewählt worden ist, soll diese per UART gesendet werden. 
Anschließend soll diese Datei überwacht werden und immer wenn sich der 
Inhalt ändert soll diese neu gesendet werden. Es sollen sowohl Druckbare 
wie auch nicht Druckbare Zeichen gesendet werden, sodass die Datei beim 
Empfänger wieder zusammen gesetzt werden kann.

COM Kommunikation: In diesem Feld sollen die gesendeten und empfangen 
Daten ohne Filter dargestellt werden. Gesendete Daten sollen ein "<" und 
empfangene Daten ein ">" davorgestellt bekommen.

Letzte Nachricht mit bestimmter Syntax: Wenn eine Nachricht mit einer 
bestimmten Zeichenfolge davor empfangen wird, soll diese bis zur 
nächsten Nachricht mit entsprechender Zeichenfolge hier angezeigt 
werden.


Bonus:

Fehlersicherheit: Die Daten werden in Blöcken von z.B. 128Byte versendet 
wonach beispielsweise ein Paritätsbyte kommt.

Bei Antwort vom Empfänger "Richtig" werden die nächsten 128Byte 
gesendet.
Bei Antwort vom Empfänger "Falsch" werden die letzten 128Byte erneut 
gesendet.
Bei mehrfacher Antwort vom Empfännger "Falsch" wird die übertragung nach 
dem 3. Versuch abgebrochen und eine Zeichenfolge für den Abbruch 
gesendet.
Bei keinie Antwort vom Empfänger wird die Übertragung nach 3. Sekunden 
abgebrochen und eine Zeichenfolge für den Abbruch gesendet.

Unterstützung von Commandos ähnlich Putty für Textfarbe durch empfangene 
Daten.




Frage:

Welches Programm würdet ihr mir empfelen für dieses Ziel, könnt ihr mich 
dabei unterstützen, hat jemand sowas schon mal gemacht, möchte das vllt 
sogar jemand für mich machen?

Sollten weitere Fragen sein, oder etwas von mir nicht richtig durchdacht 
bin ich natürlich daran interessiert.

[Rufus Τ. F. (rufus)]

_Gast schrieb:
> Welches Programm würdet ihr mir empfelen für dieses Ziel,

Das, das Du schon hast (oder kennst) und mit dem Du bereits umgehen 
kannst.

Wenn Du so eines nicht hast, dann eines, wo ein persönlicher Bekannter 
von Dir mit umgehen kann, damit er Dir bei Deinen möglichen Problemen 
damit helfen kann.

Wenn Du keinen Bekannten hast, dann eines, das mit einer 
Programmiersprache arbeitet, mit der Du schon selbst zu tun hattest.

Oder mit einer, bei der abzusehen ist, daß Du der in Deiner Schule bzw. 
sonstwie in der nächsten Zeit begegnen wirst.

[Hmm (Gast)]

Hui, vor einem ganz ähnlichen Problem stehe ich auch gerade - serielle 
Kommunikation mit µC und GUI in Windows.

Ich habe meine derartigen Programme bisher als C-Programm mit 
Kommandozeile geschrieben (in Code::Blocks). Das geht ganz passabel, 
aber naja, Kommandozeile...

So, wie ich das sehe, gibt es folgendes:
QT (in C++), aber da muss man sich offensichtlich registieren.

Mit wxWidgets und C++ in Code::Blocks: Dazu bin ich zu blöd. Bei mir 
kompiliert nicht einmal die Lib durch, was man ja erst einmal tun muss. 
Die Precompiled Packages funktionieren auch nicht.

Python : Da ist für mich völlig undurchsichtig, welche IDE/Editor und 
welches Framework da Sinn macht.

Java : Keinen Plan.

Visual Studio:  Fällt bei mir weg, weil 1. Microsoft, 2. Linux soll auch 
gehen

Nach 4 Stunden herumprobieren, ist mir heute die Lust dazu erst einmal 
gründlich vergangen.
Erkenntnisse bis jetzt: Ohne eine neue Programmiersprache (ich kann nur 
C halbwegs ordentlich) wird das nichts.

So einfach scheint das nicht zu sein :-(

[Kaj G. (Firma: RUB) (bloody)]

Hmm schrieb:
> QT (in C++), aber da muss man sich offensichtlich registieren.
https://www.qt.io/download-qt-for-application-development
Einfach die Open Source Variante waehlen. Das sollte ohne Registrierung 
laufen. Ich weiss aber nicht, wie das unter Windows aussieht, bin nur 
auf Linux unterwegs.

Hmm schrieb:
> Python : Da ist für mich völlig undurchsichtig, welche IDE/Editor und
> welches Framework da Sinn macht.
Qt fuer Python: PyQt. Um die Gui zumachen kann man den QtDesigner oder 
den QtCreator verwenden. Als Editor kann ein einfacher Texteditor 
reichen. Wenn es eine komplette IDE sein soll, dann ist vielleicht eric 
etwas. Damit sollte man auch die Guis designen koennen.
https://eric-ide.python-projects.org/

[Roland P. (pram)]

Ich würde es vielleicht mit Autoit versuchen:

File system watcher:
https://www.autoitscript.com/autoit3/docs/libfunctions/_WinAPI_FindFirstChangeNotification.htm


Com Port
https://www.autoitscript.com/wiki/CommAPI_Examples

Zuerst mal als Konsolenanwendung, später dann eine GUI rum bauen.

Allerdings bist du dann auch auf Windows fixiert. Da bleibt dir dann 
wohl nur Java, Python oder Perl

/edit zum Zugriff auf die Com Schnittstelle brachst du meist auch eine 
weitere Library

VG Roland

[Joachim B. (jar)]

Hmm schrieb:
> Erkenntnisse bis jetzt: Ohne eine neue Programmiersprache (ich kann nur
> C halbwegs ordentlich)

machs doch mit lcc32 ist C und kann überall genutzt werden, jedenfalls 
der Quellcode

[Eierfreak (Gast)]

Hmm schrieb:
> So einfach scheint das nicht zu sein :-(

Unser Lehrer (für Techniker) steigt mit absoluten Anfängern (da weiß 
keiner was ein Array ist, ohne Witz!) mit GUI-Programmierung in Java 
ein! Das ist so simpel, einfacher und schneller geht's (für Anfänger) 
nun wirklich nicht mehr.

Aber mit deiner Einstellung kannst du das gleich knicken...

Aber falls doch: Java mit Eclipse und Windowbuilder/JFrame? (verdammt, 
wie heißt das Plugin? )

[A.. P. (arnonym)]

_Gast schrieb:
> Welches Programm würdet ihr mir empfelen für dieses Ziel

Delphi/Lazarus:

* Super GUI-Builder und reichlich Komponenten für dein Vorhaben
* Delphi ist eine recht einfache Sprache (der Vorgänger Pascal wurde ja 
auch als Lernsprache entworfen)

_Gast schrieb:
> könnt ihr mich dabei unterstützen

Dafür sind wir in diesem Forum und wir versuchen es :)

_Gast schrieb:
> hat jemand sowas schon mal gemacht

Grundsätzlich ein serielles Terminal entwickelt? Gibts dutzendfach im 
Netz (für allgemeine Anwendungsfälle). Für Spezialfälle hat sicher der 
ein oder andere auch schon seinen seriellen Monitor o.ä. mit eigenem 
Protokoll gebastelt. Ich hab's noch nicht gebraucht.

_Gast schrieb:
> möchte das vllt sogar jemand für mich machen?

Du wirst hier niemanden finden, der dir deine Arbeit vorkaut. 
scherz_on Ich könnte dir das aber freilich machen - 75€/h. 
Aufwandsschätzung würde auf dem von dir zu liefernden Pflichtenheft samt 
exakter Anforderungen deines speziellen Protokolls basieren. Ich könnte 
dich auch bei der Erstellung dessen unterstützen - 75€/h. Zzgl. evtl. 
Reisekosten & Spesen. scherz_off

Gruß

[_Gast (Gast)]

Roland P. schrieb:
> Allerdings bist du dann auch auf Windows fixiert. Da bleibt dir dann
> wohl nur Java, Python oder Perl

Nur Windows reicht mir persönlich.
Habe mir gedacht das mit C++ zu machen ... habe ein wenig C bisher 
gemacht, schaut aber irgendwie total anders aus :)



Joachim B. schrieb:
> machs doch mit lcc32 ist C und kann überall genutzt werden, jedenfalls
> der Quellcode

Für C habe ich keinen Beispielcode gefunden für die Serielle 
Schnittstelle :(



Kurze Info:

Ich habe heute bereits den großteil des Tages da rein gesteckt und dies 
sind meine bisherigen Ergebnisse:

VisualStudio: 6GB ... ist das dein Ernst - nicht genug 
Festplattenspeicher
Netbeans: Hmmm schaut erst mal nicht schlecht aus, aber "noch" recht 
früh im Tutorial bereits überfordert
Dev-C++: Kompiliert nicht, alle Foreneinträge sagen "Nicht nutzen, 
veraltet"
CodeBlocks: Installiert ... muss los, keine Zeit mehr.

Aalso: Morgen Code::Blocks anschauen und QT habe ich auch mal herunter 
geladen.
Von mir aus kann es auch erst mal nur eine Konsolenanwendung sein, das 
Bunti kann später hinzu.

[Paul W. (solarturtle)]

Mit Visual Studio in VB.net

Habe schon serielle Kommunikation mit einem Mikrocontroller gemacht, 
habe daher einiges was ich übernehmen könnte.

_Gast schrieb:
> möchte das vllt sogar jemand für mich machen?

Bis Dienstag Abend könnte ich dir eine Version programmieren, was schon 
die meisten deiner Funktionen beinhaltet. Wenn alles geht, kommen die 
letzten Feinheiten rein. 100€ sollten es aber schon sein, weil 10-15h 
Arbeit werden es insgesamt schon werden.

Schreib mir einfach bei Interesse.
Vg Paul

[Manfred (Gast)]

Roland P. schrieb:
> Ich würde es vielleicht mit Autoit versuchen:

AutoIT kenne ich ziemlich gut und verfluche inzwischen, mich nicht 
gleich mit einer richtigen Programmierumgebung befasst zu haben. Jede, 
noch so kleine, Anwendung erzeugt über 800kB Code.

> Com Port
> https://www.autoitscript.com/wiki/CommAPI_Examples

Ich habe es noch nicht geschafft, einen COM-Port unter AutoIT wirklich 
anständig zu behandeln.

Rufus hat es sehr salomonisch formuliert:
Rufus Τ. F. schrieb:
> Das, das Du schon hast (oder kennst) und mit dem Du bereits umgehen
> kannst.
>
> Wenn Du so eines nicht hast, dann eines, wo ein persönlicher Bekannter
> von Dir mit umgehen kann,

Die Anforderungen sind weit über Kindergartenniveau, er muß sich in eine 
erwachsene Umgebung einarbeiten. Wegen der Nähe zu Mikrocontrollern 
würde ich aktuell zu QT tendieren wollen.

Eierfreak schrieb:
> Unser Lehrer (für Techniker) steigt mit absoluten Anfängern (da weiß
> keiner was ein Array ist, ohne Witz!) mit GUI-Programmierung in Java
> ein! Das ist so simpel, einfacher und schneller geht's (für Anfänger)
> nun wirklich nicht mehr.

Schreibe lieber "unser Leerer" - die Java-Fritzen klicken haufenweise 
Zeugs zusammen, schwingen große Sprüche und sind anschließend nicht 
schuld an Fehlfunktionen, weil sie ja vorhandene Klassen verwendet 
haben. Ich sehe die Javas in der Nähe der Arduinos, nur ein paar wenige 
verstehen, was sie tun.

Zumindest sind bei Java-Programmen die Install-CDs nicht unnötig leer 
und der Anwender freut sich, dass er sein RAM im PC nicht unnötig 
gekauft hat.

[Joachim B. (jar)]

_Gast schrieb:
> Für C habe ich keinen Beispielcode gefunden für die Serielle
> Schnittstelle :(

echt jetzt?

ist doch Standard

handle holen open read write close

Anleitungen gibts reichlich imNetz
https://www.codeproject.com/Articles/8860/Non-Overlapped-Serial-Port-Communication-using-Win

HANDLE hCom;
        if(!WriteFile(hCom, &rs232_send, strlen(rs232_send), &iBytesWritten, NULL))
            {  LPVOID lpMsgBuf;
            FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM |
                             FORMAT_MESSAGE_IGNORE_INSERTS, NULL, GetLastError(),
                             MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (LPTSTR) &lpMsgBuf, 0, NULL);
            MessageBox(NULL, (LPCTSTR)lpMsgBuf, "Error: WriteFile", MB_OK | MB_ICONINFORMATION);
               LocalFree(lpMsgBuf);
          } // if(!WriteFile(hCom.......
          else
          {
/*
            printf(  "\n\n--------------------------------------------------------------------------\n"
                    "Wait for inputs from the serial port\n"
                    "Gets maximal 70 characters until a EndOfLine character (RETURN) is detected\n\n");
*/
//            if(*strrchr(rs232_out, ','))
//              *strrchr(rs232_out, ',')=0;
//            else
//              strcpy(rs232_out, "\"leer\"");
            strcpy(rs232_in, "");
            i = 0;
              do
            {  // look for a character in the input buffer
              ReadFile ( hCom, &rs232_in[i], 1, &BytesRead, NULL);
                if (BytesRead > 0)

[W.S. (Gast)]

A.. P. schrieb:
> * Delphi ist eine recht einfache Sprache (der Vorgänger Pascal wurde ja
> auch als Lernsprache entworfen)

Da knurrt aber der Blindenhund!

Also:
- Delphi ist die Entwicklungsumgebung.
- VCL ist die benutzte Klassenbibliothek, bei Lazarus LCL oder so 
ähnlich
- und PASCAL ist die benutzte Programmiersprache.

Halte das doch bitte mal auseinander.



_Gast schrieb:
> Frage:
>
> Welches Programm würdet ihr mir empfelen für dieses Ziel, könnt ihr mich
> dabei unterstützen, hat jemand sowas schon mal gemacht, möchte das vllt
> sogar jemand für mich machen?

1. Empfehlung: Duden.
2. Für genau dein Ziel: selber nachdenken und selber schreiben. Gründe 
dazu weiter unten.
3. Mit gutgemeinten Ratschlägen unterstützt dich hier wohl jeder gern.
4. Ja, ich habe sowas schon gemacht. Für die PC Seite mittels Delphi, 
für die WinCE-Seite mittels EVC.
5. Nein, sowas würde ganz gewiß hier niemand für dich machen. Da ist 
(s.o.) selbermachen angesagt.

Im Grunde ist das Ganze ja keine Frage nach irgend einer 
Programmiersprache, sondern nach einem sinnvollen Procedere.

Also muß man sich zuerst Gedanken darüber machen, wie sich zwei 
unterschiedliche Geräte, die an jeweils einem Ende irgend einer 
Übertragungskette hängen, miteinander verständigen.

Als Erstes steht ein Synchronisieren an, also daß der eine dem anderen 
sagt, daß er ne Datei senden will. Sowas muß er vermutlich dezent 
wiederholen, weil er ja nicht weiß, ob de andere grad drangestöpselt ist 
und auch Zeit zum Zuhören hat. Der andere muß sich dann überlegen, ob er 
das Ansinnen annimmt und es dem einen auch mitteilen.

Als nächstes sollte man sich ein Blockformat aussuchen oder ausdenken. 
Bloß eine simple Prüfsumme reicht manchmal vielleicht aus, aber es 
müssen ja noch viele andere Dinge kommuniziert werden: Gesamtlänge, 
Dateiname, Blocknummer, usw... und zum Schluß sowas wie Adler32 o.ä.

Tja, und dann kommt die Frage nach einem ausreichenden Userinterface.

Also etwa so herum.

W.S.

[Possetitjel (Gast)]

Hmm schrieb:

> So, wie ich das sehe, gibt es folgendes:
> QT (in C++), [...]
>
> Mit wxWidgets und C++ in Code::Blocks: [...]
>
> Python : [...]
>
> Java : Keinen Plan.
>
> Visual Studio:  [...]


Wie üblich fehlt Tcl/Tk.

[900ss (900ss)]

Ich hab hiermit schon schöne kleine Tools geschrieben.
Für viele Dinge gibt er fertige APIs.

http://www.purebasic.com/index.php

Es erzeugt kleine EXE-Dateien, man braucht keine zusätzlichen Runtimes.

PS. Ja, ist Basic und nicht C/C++.... Na und?

[pegel (Gast)]

Ich hatte so etwas mit fluid/fltk (Linux) bzw. Quincy2005 (Win) gemacht.
Dazu eine Plattform unabhängige portableserial. Die finde ich z.Z. 
nicht,
diese scheint aber etwa das Gleiche zu sein:

https://www.teuniz.net/RS-232/

Ergibt auch kleine exe für Win und Linux.

[A.. P. (arnonym)]

W.S. schrieb:
> Da knurrt aber der Blindenhund!

Meinst du dich damit?

W.S. schrieb:
> Also: - Delphi ist die Entwicklungsumgebung.
> - VCL ist die benutzte Klassenbibliothek, bei Lazarus LCL oder so
> ähnlich
> - und PASCAL ist die benutzte Programmiersprache.
>
> Halte das doch bitte mal auseinander.

Vielen Dank, dass du das an dieser Stelle getan hast. Was täten wir alle 
nur ohne deine umgehende Erhellung?

Im Übrigen habe ich nichts von der VCL/LCL oder etwaigen weiteren 
Komponenten, wie z.B. den Jedi-Komponenten, erzählt. Das hast du jetzt 
noch mit ins Spiel gebracht. Aber natürlich hast du Recht, dass den 
Entwicklungsumgebungen Delphi/Lazarus (Handels-/Projektnamen) die 
Sprache Object Pascal zugrunde liegt. Ich denke aber, dass der 
interessierte Leser das auch von selbst auseinandergedröselt hätte, 
sofern ihn diese kleine Ungenauigkeit denn überhaupt gestört hätte.

Und außerdem: Hätte sich der TO tatsächlich für Delphi - pardon, Pascal 
- entschieden, so täte er gut daran, trotzdem mit dem Suchwort "Delphi", 
statt "Pascal", nach Hilfe zu suchen. Damit fände er nämlich 
einschlägigere Ergebnisse zu seiner Entwicklungsumgebung bzw. seinen 
Problemen, wenn er nicht gerade Hilfe für Turbo Pascal 5.0 sucht.

Gruß

[Programmiersprachentheaterintendant (Gast)]

Uiii, was da wiedermal für ein Bohei abgeht!

Serielle Schnittstellen werden unter allen Programmiersprachen gleich 
verwendet: ist schliesslich dieselbe HW für Alle, respektive derselbe 
Treiber + dieselbe Lib welche das kapselt und das ganze wird für alle 
Programme auf gleiche Weise vom Betriebssystem gestellt.

Die geschilderten Anforderungen sind definitiv standard & alltags 
Hausmannskost, ausser das Protokoll. Unter jedem gescheiten BS geht 
Dateiüberwachung, Fallentscheidung, serieller Transfer, etwas Warten, 
wiederholen in Schlaufe definitiv mit Bordmittel also ein wenig *shell 
scripting* .

(wenn ich richtig gelesen habe: das Protokoll ist NOCH NICHT vorgegeben)

Muss denn das Protokoll unbedingt ein Eigenbrau sein, der die ganzen 
Fehler der EDV-Geschichte abermals wiederholt? (diesmal ggfs. mit 
neuen Bugs...)
Dateitransfer über serielle Schnittstellen gibt es seit der 
Windelpupszeit der el. Telekommunikation und die bewärtesten davon sind 
sowieso als Libs vorhanden (und als Quellcode für den Fall dass die 
Gegenstelle ein uC ist).
Also nur anzapfen und nutzen. Warum nochmals neu erfinden UND neu 
implementieren?

[Frank E. (Firma: Q3) (qualidat)]

https://processing.org/

für alle Plattformen (win / mac /linux).

Beruht intern auf Java, Programmierung in C++ ...

[Eierfreak (Gast)]

Manfred schrieb:
> Ich sehe die Javas in der Nähe der Arduinos, nur ein paar wenige
> verstehen, was sie tun.

Hehe, er macht auch "C" parallel auf einem Arduino ;D

OK, unser "Leerer" macht das zwar trotzdem gut, aber direkt in Java GUI 
ohne Vorkenntnisse einzusteigen, finde ich schon etwas arg.

Ich bin zwar auch kein Freund von Java, aber um schnell Ergebnisse zu 
erhalten die auch funktionieren, geht das echt gut. Und für's Hobby 
reicht das allemal aus. Vor allem, wenn das Programm nur ein paar mal 
verwendet werden soll und nicht 24/7 in der Industrie läuft...

[X4U (Gast)]

_Gast schrieb:
> Welches Programm würdet ihr mir empfelen für dieses Ziel, könnt ihr mich
> dabei unterstützen, hat jemand sowas schon mal gemacht, möchte das vllt
> sogar jemand für mich machen?

Wäre eine Freelancer Seite etwas für dich?

> Bonus:
>
> Fehlersicherheit: Die Daten werden in Blöcken von z.B. 128Byte versendet
> wonach beispielsweise ein Paritätsbyte kommt.

Nimm ein Protokoll das es gibt und open source ist.

[Rufus Τ. F. (rufus)]

X4U schrieb:
> Nimm ein Protokoll das es gibt und open source ist.

Uralter etablierter Standard: XMODEM.

https://en.wikipedia.org/wiki/XMODEM

Oder Y- bzw. ZMODEM, oder kermit. Eines davon beherrscht jedes 
ernstgemeinte Terminalprogramm.

[Hmm (Gast)]

Kaj G. schrieb:
> Hmm schrieb:
>> QT (in C++), aber da muss man sich offensichtlich registieren.
> https://www.qt.io/download-qt-for-application-development
> Einfach die Open Source Variante waehlen. Das sollte ohne Registrierung
> laufen. Ich weiss aber nicht, wie das unter Windows aussieht, bin nur
> auf Linux unterwegs.

Danke für den Tipp! Das klappt, und sieht erst mal vernünftig aus.

Nach 3 Stunden probiererei läuft das (Siehe Bild). Von wegen 
Installieren und loslegen. Mit der Standardinstallation ist es nicht 
getan.

Ich habe folgendes Tutorial verwendet:
https://wiki.qt.io/Qt_for_Beginners

Und jetzt heißt es erst mal C++ Büffeln. Naja, jammern hilft nicht.

[Heinz B. (Firma: Privat) (hbrill)]

Das Schreiben einer kleinen GUI und das
Senden und Empfangen über die ser. Schnittstelle
stellt wohl kaum eine Hürde dar. Je nachdem, welche
Programmiersprache man nimmt, ist es etwas mehr
oder weniger Aufwand.

Was etwas trivial sein wird :

_Gast schrieb:
> Anschließend soll diese Datei überwacht werden und immer wenn sich der
> Inhalt ändert soll diese neu gesendet werden. Es sollen sowohl Druckbare
> wie auch nicht Druckbare Zeichen gesendet werden, sodass die Datei beim
> Empfänger wieder zusammen gesetzt werden kann.

Wenn nun jemand die Datei mit z.B. dem Windows-Editor
ändert, wie soll das Programm denn das erkennen ?
Eine Windowsbotschaft gibt es wahrscheinlich nicht
und der Editor wird eine solche auch nicht an das
Hauptprogramm verschicken. Eine Änderung anhand der
Dateigröße abzufragen, ist auch nicht optimal. Was ist,
wenn nur ein paar Bytes abgeändert werden, die Dateigröße
aber bestehen bleibt ?

Sowas ginge, wenn man noch einen Editor (MultiEdit) ins
Hauptprogramm integriert, mit dem die Datei geändert werden muß.
Oder einen Editor als selbstgeschriebenes Programm, der beim
Speichern eine selbstdefinierte Windowsbotschaft an das Fenster
des Hauptprogramms schickt und dieses dann diese Botschaft
auswertet.

[Sheeva P. (sheevaplug)]

Hmm schrieb:
> Python : Da ist für mich völlig undurchsichtig, welche IDE/Editor und
> welches Framework da Sinn macht.

Für so einfaches Zeug reichen Tkinter bzw. Tix (letzteres ist eine etwas 
hübschere Erweiterung zu Tkinter). Was der TO gezeichnet hat, würde dann 
ohne große Funktionalität und Politur etwa so aussehen:

#!/usr/bin/python
# *-* coding: utf-8 *-*
import Tix as T
import tkFileDialog as tFD
import os

class MyLabel(T.Label):
    def __init__(self, *args, **kwargs):
        kwargs['padx'] = 5
        kwargs['pady'] = 5
        kwargs['borderwidth'] = 2
        kwargs['background'] = 'white'
        kwargs['relief'] = T.SUNKEN
        T.Label.__init__(self, *args, **kwargs)
        

class MainWin(T.Tk):
    def __init__(self, *args, **kwargs):
        T.Tk.__init__(self, *args, **kwargs)
        self.title('Kopfzeile von Windows mit Programmnamen')

        self.topFrame = T.Frame(self, padx=5, pady=5, bd=2,
                                relief=T.SUNKEN)
        self.lblCom = MyLabel(self.topFrame,
                              text='COM #')
        self.lblCom.pack(side=T.LEFT)
        self.lblBaud = MyLabel(self.topFrame,
                               text='Baudrate')
        self.lblBaud.pack(side=T.LEFT)
        self.lblFile = MyLabel(self.topFrame,
                               text='Ausgewählte Datei')
        self.lblFile.pack(side=T.LEFT)
        self.btnFile = T.Button(self.topFrame,
                                text='...',
                                command=self.askFile)
        self.btnFile.pack(side=T.LEFT)
        self.topFrame.pack(side=T.TOP)

        self.txtCom = T.Text(self, width=48, height=12)
        self.txtCom.pack(side=T.TOP)

        self.txtCom.insert(T.END, "COM Kommunikation\n\n" +
                           "< vom Rechner gesendete Nachricht\n" +
                           "> Empfangene Nachricht")

        self.lblBottom = MyLabel(self,
                                 text='Letzte Nachricht ' +
                                 'mit bestimmter Syntax ' +
                                 '(Last Status)')
        self.lblBottom.pack(side=T.TOP)

        
    def askFile(self):
        filename = tFD.askopenfilename(title='Open File')
        self.lblFile.config(text=os.path.basename(filename))
        

if __name__ == '__main__':
    MainWin().mainloop()

[W.S. (Gast)]

A.. P. schrieb:
> Vielen Dank, dass du das an dieser Stelle getan hast. Was täten wir alle
> nur ohne deine umgehende Erhellung?

Oh bittesehr.

Und was "wir alle" (womit du dich selber gemeint hast) tätest, ist ganz 
klar: Du würdest ohne diese Erhellung immer noch ohne Orientierung im 
Dunkeln herumtappen.

Genau dieses Phänomen sehe ich bei sehr vielen Anfragen im Stile 
dieses Threads: Der TO hat zwar ein Vorhaben, schafft es jedoch nicht, 
selbiges wirklich mit der nötigen Gründlichkeit zu formulieren. Siehe: 
"Vorwort: Ich bräuchte ein Programm auf Windows, um bei der Änderung 
einer Datei, diese über UART zu senden."

Wer ändert da welche Datei? Wer überprüft da, ob diese Datei geändert 
wurde und wer sendet diese dann an wen und wer ist der Empfänger (bare 
metal oder App in anderem OS?). Je schwammiger die Fragen sind, desto 
heftiger ist die Notwendigkeit der Präzisierung.

Kurzum, Fragen über Fragen. Eine davon hab ich ja nun final geklärt. 
Gelle?

W.S.

[Programmiersprachentheaterintendant (Gast)]

> Wenn nun jemand die Datei mit z.B. dem Windows-Editor
> ändert, wie soll das Programm denn das erkennen ?

Durch regelmässiges abfragen der Dateimetadaten wie "letzter 
Zugriffszeitpunkt" und " letzter Schreibzeitpunkt"?
Jedes Dateisystem dass diesen Namen verdient hält solche Metadaten pro 
Datei vor...

> Eine Windowsbotschaft gibt es wahrscheinlich nicht
Schau an: ein Nicht-Betriebssystem...

[Heinz B. (Firma: Privat) (hbrill)]

Programmiersprachentheaterintendant schrieb:
> Durch regelmässiges abfragen der Dateimetadaten wie "letzter
> Zugriffszeitpunkt" und " letzter Schreibzeitpunkt"?
> Jedes Dateisystem dass diesen Namen verdient hält solche Metadaten pro
> Datei vor...

Klärt aber immer noch nicht, ob was beim letzten Schreibzeitpunkt
geändert wurde oder ob nur einfach neu gespeichert wurde.

Von daher auch nur sub-optimal !!!!

[Manfred (Gast)]

900ss D. schrieb:
> http://www.purebasic.com/index.php
> Es erzeugt kleine EXE-Dateien, man braucht keine zusätzlichen Runtimes.

Damit hat ein Kollege früher PC-basierte Prüfsysteme geschrieben, lief 
gut. Scheint aus der Mode zu sein. Ich selbst hatte MS-PDS-Basic im 
Einsatz, aber nie probiert, ob das auf aktuellen Umgebungen noch zur 
Funktion zu bewegen ist.

Eierfreak schrieb:
> Ich bin zwar auch kein Freund von Java, aber um schnell Ergebnisse zu
> erhalten die auch funktionieren, geht das echt gut. Und für's Hobby
> reicht das allemal aus. Vor allem, wenn das Programm nur ein paar mal
> verwendet werden soll und nicht 24/7 in der Industrie läuft...

Java bedeutet in meinen Augen immer "Groß und langsam", ich benutze 
gerne mal einen meiner kleinen PCs. Und ja, ich kenne Java-Software, die 
24/7 laufen muß, meine Begeisterung ist sehr begrenzt.

Hmm schrieb:
> Nach 3 Stunden probiererei läuft das (Siehe Bild).

Du hast schon einmal Ausdauer für den Einstieg bewiesen, fühle Dich 
gelobt :-)

> Von wegen Installieren und loslegen. Mit der Standardinstallation ist es nicht
> getan.

tja ...

> Und jetzt heißt es erst mal C++ Büffeln. Naja, jammern hilft nicht.

Wenn Du das wirklich durchziehst, wird es sich langfristig sicherlich 
auszahlen, mach' weiter!

[Rolf M. (rmagnus)]

Heinz B. schrieb:
> Wenn nun jemand die Datei mit z.B. dem Windows-Editor
> ändert, wie soll das Programm denn das erkennen ?

Indem es sich vom System benachrichtigen lässt:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365261(v=vs.85).aspx

Bzw, da Qt erwähnt wurde - da gibt's schon fertige Klassen für sowas:
http://doc.qt.io/qt-5/qfilesystemwatcher.html

Oder in Python:
https://pypi.python.org/pypi/watchdog

[Sheeva P. (sheevaplug)]

Programmiersprachentheaterintendant schrieb:
>> Wenn nun jemand die Datei mit z.B. dem Windows-Editor
>> ändert, wie soll das Programm denn das erkennen ?
>
> Durch regelmässiges abfragen der Dateimetadaten wie "letzter
> Zugriffszeitpunkt" und " letzter Schreibzeitpunkt"?
> Jedes Dateisystem dass diesen Namen verdient hält solche Metadaten pro
> Datei vor...

Sorry, aber Polling ist irgendwie ziemlich Siebziger... Und ich weiß 
zwar nicht, wie das unter Windows ist, aber unter Linux (und IIRC auch 
unter Solaris) kannst Du Änderungen an diesen Metadaten über die 
Mountoptionen abschalten.

>> Eine Windowsbotschaft gibt es wahrscheinlich nicht
> Schau an: ein Nicht-Betriebssystem...

Diese hier haben gewisse Ähnlichkeiten mit Linux' inotify:

https://msdn.microsoft.com/en-us/library/aa364417(VS.85).aspx

https://docs.microsoft.com/de-de/dotnet/api/system.io.filesystemwatcher?view=netframework-4.7.1

[Programmiersprachentheaterintendant (Gast)]

Sheeva P. schrieb:
> Programmiersprachentheaterintendant schrieb:
:
> Sorry, aber Polling ist irgendwie ziemlich Siebziger...
:
> Diese hier haben gewisse Ähnlichkeiten mit Linux' inotify:
>
> https://msdn.microsoft.com/en-us/library/aa364417(VS.85).aspx
>
> https://docs.microsoft.com/de-de/dotnet/api/system.io

Natürlich FULL ACK, bereits im voraus!
Jetzt kommen auch die Fleischstücke auf den Diskussionstisch  :-) und 
der TO bekommt guten Mehrwert zu den sonst bloss... naiven Antworten.

[Zeno (Gast)]

Heinz B. schrieb:
> Klärt aber immer noch nicht, ob was beim letzten Schreibzeitpunkt
> geändert wurde oder ob nur einfach neu gespeichert wurde.
>
> Von daher auch nur sub-optimal !!!!

Indem man bei jeder Prüfung der Datei eine Prüfsumme ablegt. Wenn die 
Prüfsumme bei der nächsten Prüfung eine andere ist, wurde vermutlich was 
geändert ansonsten nicht.

[Heinz B. (Firma: Privat) (hbrill)]

Weil es mich auch interessiert, werde ich mich mal
durch die API wursteln.

PS:

Sheeva P. schrieb:
> Sorry, aber Polling ist irgendwie ziemlich Siebziger... Und ich weiß
> zwar nicht, wie das unter Windows ist, aber unter Linux (und IIRC auch
> unter Solaris) kannst Du Änderungen an diesen Metadaten über die
> Mountoptionen abschalten.

Polling braucht man dazu gar nicht. Das Abfragen von
Windowsnachrichten erledigt man üblicherweise in der
Warteschleife, in der auch die anderen GUI-Elemente
(wie Buttons etc.) abgefragt werden.

Bei Purebasic, XProfan usw. werden nur die wichtigen
Nachrichten vom Eventsystem behandelt, um den Programmierer
nicht schon gleich mit massenweisen Nachrichten zu erschlagen.

Das hält aber nicht davon ab, andere Windowsnachrichten
oder gar selbstdefinierte Botschaften selber zu behandeln.
Die braucht man nur zu definieren und z.B. über den Notifycode
abfragen.

[Zeno (Gast)]

Heinz B. schrieb:
> Polling braucht man dazu gar nicht. Das Abfragen von
> Windowsnachrichten erledigt man üblicherweise in der
> Warteschleife, in der auch die anderen GUI-Elemente
> (wie Buttons etc.) abgefragt werden.

Welche konkrete Windowsnachricht willst Du da abfangen? Ich wüßte keine 
die sagt das die Datei XY verändert wurde. Ich laß mich da aber gern 
eines besseren belehren.

Am Polling wird da wohl nichts vorbei gehen. Ich würde bei der Sache gar 
nicht auf die Dateiattribute setzen, obwohl das auch mein erster Ansatz 
war. Ich würde in geeigneten Abständen eine Prüfsumme bilden. Sobald 
sich diese verändert, wurde auch die Datei verändert. Das wäre dann der 
Trigger.

[Rolf M. (rmagnus)]

Zeno schrieb:
> Am Polling wird da wohl nichts vorbei gehen.

Alle Postings, die beweisen, dass das Blödsinn ist, überlesen?

[Heinz B. (Firma: Privat) (hbrill)]

z.B. diese da :

FILE_NOTIFY_CHANGE_LAST_WRITE (0x00000010)
in Verbindung mit der API-Funktion FindFirstChangeNotification

Mal sehen, da gibt es auch Möglichkeiten mit .Net usw.
Und da gibt es was, mit Übergabe eines Fensterhandle,
wo das entsprechende Fenster informiert wird.

[Sheeva P. (sheevaplug)]

Heinz B. schrieb:
> Sheeva P. schrieb:
>> Sorry, aber Polling ist irgendwie ziemlich Siebziger... Und ich weiß
>> zwar nicht, wie das unter Windows ist, aber unter Linux (und IIRC auch
>> unter Solaris) kannst Du Änderungen an diesen Metadaten über die
>> Mountoptionen abschalten.
>
> Polling braucht man dazu gar nicht. Das Abfragen von
> Windowsnachrichten erledigt man üblicherweise in der
> Warteschleife, in der auch die anderen GUI-Elemente
> (wie Buttons etc.) abgefragt werden.

Auch das ist am Ende nichts anderes als Polling, egal wo genau Du es 
jetzt konkret abfackelst. Der Trick von zum Beispiel Linux' inotify-Api 
ist aber, daß der Kernel entsprechende Hooks zur Überwachung anbietet 
und seinerseits quasi selbständig die zuvor registrierte Aktion auslöst, 
sobald dann das zu überwachende Event eintritt.

[A.. P. (arnonym)]

W.S. schrieb:
> Du würdest ohne diese Erhellung immer noch ohne Orientierung im Dunkeln
> herumtappen.

Sicherlich nicht. Ich habe schon vor Jahren professionell mit Delphi 
Anwendungen entwickelt und war tief in der Materie drin. Und wo man in 
diesem Feld auch unterwegs war, sprachen auch alle von "Delphi", statt 
von "Pascal", und jeder wusste, was gemeint ist. Und wenn 
"Delphi"-Entwickler gesucht werden, sind damit ganz gewiss nicht 
Personen gemeint, die nur unter Borland/Embarcadero/CodeGear Delphi 
entwickeln, sondern die Delphi als Sprache beherrschen.

Also spiel dich jetzt mal hier nicht auf, nur weil du mal einen Begriff 
gelesen hast, mit dem auch du was anfangen konntest. Ich wollte den TO 
lediglich mit der Nase auf die Entwicklungsumgebung stupsen.

W.S. schrieb:
> Kurzum, Fragen über Fragen. Eine davon hab ich ja nun final geklärt. Gelle?

Nein, hast du nicht. Deinen ganzen Aussagen lag nicht eine Frage 
zugrunde, du hast nur wieder mal ein bisschen rumgeklugscheißert.

[Bernd K. (prof7bit)]

Sheeva P. schrieb:
> Der Trick von zum Beispiel Linux' inotify-Api
> ist aber, daß der Kernel entsprechende Hooks zur Überwachung anbietet

Geht inotify nicht auch nur ganz normal mit Read-Events für Handles auf 
die man blockierend mit select() oder poll() oder read() warten muss? 
IMHO scheint mir das der exakt selbe Mechanismus in grün zu sein. Ich 
hab da nix von irgendwelchen Callbacks oder Hooks gelesen die der Kernel 
höchstpersönlich aufrufen soll.

Ich hab auch sonst noch in keinem Userland code irgendwelche 
Hook-Funktionen gesehen die der Kernel höchstpersönlich ausführen soll, 
da wären ja Tür und Tor geöffnet.

[Sheeva P. (sheevaplug)]

Bernd K. schrieb:
> Geht inotify nicht auch nur ganz normal mit Read-Events für Handles auf
> die man blockierend mit select() oder poll() oder read() warten muss?
> [...]
> IMHO scheint mir das der exakt selbe Mechanismus in grün zu sein.

Ein klassisches Polling würde immer wieder die Metadaten des 
Dateisystems auslesen, bis es eine Änderung daran feststellt. Durch das 
ständige Lesen werden Ressourcen zum Lesen und Vergleichen der Metadaten 
verbraucht.

Inotify(7) setzt auf Events auf, die durch Aufruf der 
Dateisystemfunktionen ausgelöst werden und die blockierenden Calls 
freigeben. Die Freigabe dieser blockierenden Calls ist dann die 
Nachricht für das aufrufende Programm, daß eins der überwachten Events 
aufgetreten ist.

Bei inotify(7) passiert also nur dann was, wenn tatsächlich ein Event 
zur Verarbeitung ansteht. Ansonsten blockiert der Syscall kommod vor 
sich hin, und verbraucht dabei keine Ressourcen.

[Rolf M. (rmagnus)]

Sheeva P. schrieb:
> Bei inotify(7) passiert also nur dann was, wenn tatsächlich ein Event
> zur Verarbeitung ansteht. Ansonsten blockiert der Syscall kommod vor
> sich hin, und verbraucht dabei keine Ressourcen.

Das scheint mir aber bei der Windows-Variante auch nicht anders. Auch da 
nutzt man einen blockierenden Aufruf, um auf Events zu warten. Oder 
gehst du davon aus, dass diese Windows-Umsetzung dann intern pollt?

[Heinz B. (Firma: Privat) (hbrill)]

Wenn man in etwa weiß, wie Windows tickt (arbeitet),
ist es doch ganz einfach. Ohne Polling des Eventsystems,
sei es nun intern durch die Programmiersprache oder
durch eine selber gemachte Eventschleife, funktioniert
kein Windowsprogramm mit GUI-Elementen so richtig.

Wie sollte man auch sonst abfrgaen, ob z.B. ein
Button gedrückt wurde ? Wenn das nicht in einer
Schleife geschieht, könnte man einen Button auch
nur einmal drücken und das Programm wäre zu Ende.

Also ist das Polling sowieso schon da. Ob man da
noch weitere Events bzw. Botschaften registriert
und abfrägt, ist nur Beiwerk.

Die Abfrage in solchen Systemen wird halt auf das
Nötigste reduziert, damit das Programm später
keinen Performanceverlust erleidet.

Man stelle sich vor, man würde alle möglichen
Nachrichten bzw. Events kontinuierlich in einer
Schleife abfragen. Das Programm würde arschlangsam
werden oder würde sich sogar nur schwer bedienen
lassen.

Dafür ist man dazu übergegangen, die für das Programm
zusätzlichen interessanten Nachrichten selber abfangen
zu können. Da dies i.d.R. sehr wenige sind, wird das
gesamte System nicht sonderlich damit belastet.

[Sheeva P. (sheevaplug)]

Rolf M. schrieb:
> Das scheint mir aber bei der Windows-Variante auch nicht anders. Auch da
> nutzt man einen blockierenden Aufruf, um auf Events zu warten. Oder
> gehst du davon aus, dass diese Windows-Umsetzung dann intern pollt?

Ich habe keine Ahnung von Windows und weiß deswegen nicht, wie Windows 
das macht. Tatsächlich würde ich vermuten, daß Windows das ähnlich 
handhabt wie Linux, aber, wie gesagt: ich weiß es nicht.

[Sheeva P. (sheevaplug)]

Heinz B. schrieb:
> Wenn man in etwa weiß, wie Windows tickt (arbeitet),
> ist es doch ganz einfach. Ohne Polling des Eventsystems,
> sei es nun intern durch die Programmiersprache oder
> durch eine selber gemachte Eventschleife, funktioniert
> kein Windowsprogramm mit GUI-Elementen so richtig.

Die von Dir angesprochene Eventloop läuft aber im Userspace und leidet 
für den Fall, daß ständig Dateiattribute abgerufen werden müssen, 
darunter, daß dabei jedes Mal ein teurer Kontextwechsel zwischen 
Usermode (Eventloop) und Kernelmode (Dateisystemtreiber) stattfinden und 
eben immer wieder dieselben Dateisystemattribute gelesen und verglichen 
werden müssen. Das wäre leider hochgradig ineffizient und eben: Polling. 
Probier's halt aus: wenn Du kein Delay in Deine Poll-Schleife einbaust, 
belegt das 100% eines CPU-Kerns.

Tatsächlich würde ich nach der von mir oben verlinkten Dokumentation von 
FindFirstChangeNotification und FileSystemWatcher erwarten, daß Windows 
intern ebenfalls mit Dateisystemevents auf Kernelebene arbeitet. Im 
ersten Fall kann das von FindFirstChangeNotification zurückgegebene 
Handle mit blockierenden Wait-Operationen verwendet werden (die 
blockieren und erst zurückkehren, wenn eins der gesuchten 
Dateisystemevents ausgelöst wird, ähnlich wie unter Linux' inotify). Im 
zweiten Fall werden dem erzeugten FileSystemWatcher eine oder mehrere 
Callback-Funktionen mitgegeben, die aufgerufen werden, wenn das 
entsprechende Event ausgelöst wird.

All dies ist -- wenn ein Windows-Spezialist das besser weiß, möge er 
mich bitte korrigieren -- völlig unabhängig von den Eventloops einer 
GUI.

[Heinz B. (Firma: Privat) (hbrill)]

Ich denke mal, daß die Systemevents auch immer ausgelöst werden.
Die sind aber Fenster-unabhängig. Es gibt ja auch eine API, der
man ein Fensterhandle mitgibt, an das dann der Systemevent
geschickt wird.

Wenn man anders herum mal den Eventloop betrachtet :
Einen Button-Click gibt es ja in dem Sinne eigentlich
nicht. Der setzt sich aus den Mausklicks Button_down,
Button_up zusammen. Und wenn diese auch noch in der
Clientarea des Fensters (ja - auch ein Button ist für
Windows nur ein Fenster) stattfinden, ist es ein
Klick auf einen Button. Und wie man sieht, sind das
ja System bzw. Hardware - Events (Kernelfunktionen),
die erst mal nichts mit Fenstern zu tun haben.

Ich wußte das vorher auch nicht, erst als ich mich mal
vor Jahren mit SubClassing von Fenstern beschäftigte,
fand ich das heraus.

Und gerade das SubClassing ermöglicht es ja, daß sich
die originale Windowprozedur nicht um jeden Furz kümmern
muß. Es gibt Programmiersprachen, bei denen man sich
beim Subclassen dann auch noch selber um den Klick
kümmern muß, was sonst das Programmiersystem macht.
Bei anderen Sprachen wiederum, muß man sich nur um den
extra zu bearbeitenden Event kümmern. Den Rest erledigt
das Programmiersystem.

Also, soweit auseinander liegen diese Sachen gar nicht.

[Carl D. (jcw2)]

Sheeva P. schrieb:
> Tatsächlich würde ich nach der von mir oben verlinkten Dokumentation von
> FindFirstChangeNotification und FileSystemWatcher erwarten, daß Windows
> intern ebenfalls mit Dateisystemevents auf Kernelebene arbeitet. Im
> ersten Fall kann das von FindFirstChangeNotification zurückgegebene
> Handle mit blockierenden Wait-Operationen verwendet werden (die
> blockieren und erst zurückkehren, wenn eins der gesuchten
> Dateisystemevents ausgelöst wird, ähnlich wie unter Linux' inotify). Im
> zweiten Fall werden dem erzeugten FileSystemWatcher eine oder mehrere
> Callback-Funktionen mitgegeben, die aufgerufen werden, wenn das
> entsprechende Event ausgelöst wird.
>
> All dies ist -- wenn ein Windows-Spezialist das besser weiß, möge er
> mich bitte korrigieren -- völlig unabhängig von den Eventloops einer
> GUI.

FileChangeNotifications sind Kernel-Objekte, auf die man blockierend 
warten kann. Da aber Windows-GUI-Threads von einer MessageLoop abhängig 
sind, kann man auch warten auf Kernel-Objekte und eintreffende 
Messages, die dann gleich dispatched werden. Und worauf man wartet, kann 
sehr fein eingestellt werden, z.B. "Schreiben auf Datei in Ordner xyz". 
Nur diese lösen einen Contextswitch aus. Messages natürlich auch, denn 
die Message-Queue ist nur ein weiteres Objekt auf das gewartet wird. Ich 
meine mich erinnern zu können (hab das letztesmal zu Win2000-Zeiten 
gemacht), daß mit MessageLoop ein Kernel-Objwerkt weniger in die 
WarteListe paßt, eben wegen der Message-Queue. Die CSe durch Messages 
stören aber nicht, denn man möchte diese ja gerade parallel zum Warten 
verarbeiten. Ohne GUI geht's natürlich auch ohne MessageLoop.

[Sheeva P. (sheevaplug)]

Carl D. schrieb:
> FileChangeNotifications sind Kernel-Objekte, auf die man blockierend
> warten kann. Da aber Windows-GUI-Threads von einer MessageLoop abhängig
> sind, kann man auch warten auf Kernel-Objekte und eintreffende
> Messages, die dann gleich dispatched werden.

Wenn Du in einer GUI-MessageLoop blockierend auf etwas wartest, 
blockiert sie. Das heißt, die Eingabeevents können für die Dauer der 
Blockade nicht mehr verarbeitet und die GUI also nicht mehr bedient 
werden.

> Und worauf man wartet, kann sehr fein eingestellt werden, z.B.
> "Schreiben auf Datei in Ordner xyz".

Man kann einstellen, für welche Ereignisse der Betriebssystemkernel ein 
Event auslöst.

> Nur diese lösen einen Contextswitch aus.

Unter Linux und Solaris ist es jedenfalls so, daß beim klassischen 
Polling jeder *stat(2)-Call einen Kontextwechsel auslöst. Es würde mich 
wundern, wenn der Windows-Kernel das anders handhaben würde (oder 
könnte). Immerhin reden wir hier von Events, die von 
Dateisystemfunktionen ausgelöst werden, und das Dateisystem gehört IMHO 
auch unter Windows zum Kernel.

> Messages natürlich auch, denn die Message-Queue ist nur ein weiteres
> Objekt auf das gewartet wird.

Ja, aber da der Userspace-Syscall unterdessen blockiert und der 
aufrufende Thread in der Zeit zwischen Aufruf und Event einfach nur gar 
nichts tut und untätig vor sich hin wartet, findet in diesem Falle nur 
genau ein einziger Kontextwechsel statt: nämlich dann, wenn das Event 
eintritt und der Kernel den Userspace-Code darüber benachrichtigt, indem 
er den blockierenden Syscall zurückkehren läßt und also dessen Blockade 
beendet.

Polling bedeutet, etwas viele Male zu lesen, nur um eine einzige 
Änderung mitzubekommen. Effizienter ist, vom Kernel Nachrichten für die 
gewünschten Events anzufordern und sich dann schlafen zu legen, bis er 
eine ebensolche Nachricht schickt. Genau deswegen gibt es solche 
Benachrichtigungssysteme im Kernel wie inotify und die genannten 
Windows-Äquivalente doch. Wenn man das auch nur annäherungsweise ähnlich 
effizient mit einer GUI-Messageloop oder sogar mittels Polling 
hinbekommen könnte, wären diese Subsysteme und Funktionen komplett 
nutzlos und überflüssig. :-)

[Rolf M. (rmagnus)]

Sheeva P. schrieb:
> Immerhin reden wir hier von Events, die von
> Dateisystemfunktionen ausgelöst werden, und das Dateisystem gehört IMHO
> auch unter Windows zum Kernel.

Ob nun Kernel oder nicht, ist egal. Das Dateisystem wird definitiv in 
einem anderen Kontext ausgeführt. Es kann ja nicht jeder Prozess seine 
eigene Instanz des Dateisystems laufen lassen.

[Carl D. (jcw2)]

Sheeva P. schrieb:
> Carl D. schrieb:
>> FileChangeNotifications sind Kernel-Objekte, auf die man blockierend
>> warten kann. Da aber Windows-GUI-Threads von einer MessageLoop abhängig
>> sind, kann man auch warten auf Kernel-Objekte und eintreffende
>> Messages, die dann gleich dispatched werden.
.
> Wenn Du in einer GUI-MessageLoop blockierend auf etwas wartest,
> blockiert sie. Das heißt, die Eingabeevents können für die Dauer der
> Blockade nicht mehr verarbeitet und die GUI also nicht mehr bedient
> werden.
.
>> Und worauf man wartet, kann sehr fein eingestellt werden, z.B.
>> "Schreiben auf Datei in Ordner xyz".
>
> Man kann einstellen, für welche Ereignisse der Betriebssystemkernel ein
> Event auslöst.
.
>> Nur diese lösen einen Contextswitch aus.
>
> Unter Linux und Solaris ist es jedenfalls so, daß beim klassischen
> Polling jeder *stat(2)-Call einen Kontextwechsel auslöst. Es würde mich
> wundern, wenn der Windows-Kernel das anders handhaben würde (oder
> könnte). Immerhin reden wir hier von Events, die von
> Dateisystemfunktionen ausgelöst werden, und das Dateisystem gehört IMHO
> auch unter Windows zum Kernel.
>
>> Messages natürlich auch, denn die Message-Queue ist nur ein weiteres
>> Objekt auf das gewartet wird.
>
> Ja, aber da der Userspace-Syscall unterdessen blockiert und der
> aufrufende Thread in der Zeit zwischen Aufruf und Event einfach nur gar
> nichts tut und untätig vor sich hin wartet, findet in diesem Falle nur
> genau ein einziger Kontextwechsel statt: nämlich dann, wenn das Event
> eintritt und der Kernel den Userspace-Code darüber benachrichtigt, indem
> er den blockierenden Syscall zurückkehren läßt und also dessen Blockade
> beendet.
>
> Polling bedeutet, etwas viele Male zu lesen, nur um eine einzige
> Änderung mitzubekommen. Effizienter ist, vom Kernel Nachrichten für die
> gewünschten Events anzufordern und sich dann schlafen zu legen, bis er
> eine ebensolche Nachricht schickt. Genau deswegen gibt es solche
> Benachrichtigungssysteme im Kernel wie inotify und die genannten
> Windows-Äquivalente doch. Wenn man das auch nur annäherungsweise ähnlich
> effizient mit einer GUI-Messageloop oder sogar mittels Polling
> hinbekommen könnte, wären diese Subsysteme und Funktionen komplett
> nutzlos und überflüssig. :-)

Einfach mal die Doku zu MsgWaitForMultipleObjects durchlesen
https://msdn.microsoft.com/de-de/library/windows/desktop/ms684242(v=vs.85).aspx
dann fällt das ein oder andere Raten wie es sein müßte weg.

Sorry, normalerweise kenne ich von dir eigentlich fundierte Kommentare, 
aber beim aktuellen Thema fehlt es anscheinend an Grundlagen.

Windows ist eigentlich für mich was nervtötendes, ich benutze das nur 
unter Zwang. Aber unter dem maroden Krempel werkelt aber ein Kernel, der 
früher mal VMS hieß und der, schon bevor B.Gates den Hern Cutler 
eingekauft hat, Dinge konnte, die sich manche offensicht auch heute noch 
nicht vorstellen können. Nicht ohne Grund wurde VMS auf Proczessrechnern 
eingesetzt, da ist Pollen verpönt. Leider scheint man irgendwann 
aufgehört zu haben, VMS bzw. seine Konzepte in der Lehre zu behandeln.

[Sheeva P. (sheevaplug)]

Rolf M. schrieb:
> Sheeva P. schrieb:
>> Immerhin reden wir hier von Events, die von
>> Dateisystemfunktionen ausgelöst werden, und das Dateisystem gehört IMHO
>> auch unter Windows zum Kernel.
>
> Ob nun Kernel oder nicht, ist egal. Das Dateisystem wird definitiv in
> einem anderen Kontext ausgeführt. Es kann ja nicht jeder Prozess seine
> eigene Instanz des Dateisystems laufen lassen.

Richtig, deswegen macht das der Kernel, und genau deswegen sind Abfragen 
von Metadaten des Dateisystems auch immer mit einem teuren 
Kontextwechsel zwischen User- und Kernelspace verbunden. Und das ist nur 
einer der vielen Gründe, die klassisches Polling so teuer machen im 
Vergleich zu modernen Event Notification APIs -- und aus denen man kein 
Polling, sondern diese modernen APIs benutzen will.

Schau, es ist ganz einfach: ich kann täglich zehnmal zum Briefkasten 
gehen und schauen, ob Post da ist. Oder ich kann mich darauf verlassen, 
daß mein Briefträger beim Einlegen der Post das kleine Fähnchen 
hochgeklappt hat um mir dadurch mitzuteilen, daß ich nach der Post 
schauen soll. Welche dieser beiden Vorgehensweisen ist wohl effizienter? 
Jawoll Scheff, janz jenau.

Und so ist das auch mit Event Notifications bei Dateisystemevents: die 
Dateisystemfunktionen, die die Dateien und ihre Metadaten ändern, sind 
schließlich immer die Ersten und wissen am Besten, wenn sie Dateien oder 
deren Metadaten ändern. Was liegt dabei näher, als diese Funktionen mit 
entsprechenden Fähigkeiten auszustatten, um interessierte Programme im 
Userspace über diese Änderungen zu benachrichtigen?

Egal, ob das inotify unter Linux oder OpenBSD, 
FindFirstChangeNotification unter Windows, FileSystemWatcher unter .NET, 
kqueue/kevent unter *BSD oder die Event Notifications unter AIX sind: 
jedes dieser Systeme hat eigens für diesen Zweck jeweils eigene 
Mechanismen. Weil jeder Systemhersteller weiß, wie extrem ineffizient 
und teuer so ein klassisches Polling ist.

Deswegen ist es mir ehrlich völlig schleierhaft, warum wir hier eine 
rückwärtsgerichtete Diskussion darüber führen müssen, daß man ja doch 
irgendwie ein klassisches Polling machen könne. Natürlich kann man das 
machen. Aber dann ist es halt Scheiße. Das ist und bleibt es auch dann, 
wenn man irgendwelchen esoterischen Hokuspokus betreibt wie eine 
GUI-Eventloop dafür zu vergewaltigen -- wobei heutige Eventloops ja 
schon längst kein Polling mehr machen, sondern auch nur auf Events 
warten.

[Sheeva P. (sheevaplug)]

Carl D. schrieb:
> Einfach mal die Doku zu MsgWaitForMultipleObjects durchlesen
> https://msdn.microsoft.com/de-de/library/windows/desktop/ms684242(v=vs.85).aspx
> dann fällt das ein oder andere Raten wie es sein müßte weg.

Wenn ich das richtig sehe, macht das etwas Ähnliches wie select(2): 
wartet darauf, daß eines der angegebenen Event-Subsysteme eines der 
konfigurierten Events meldet.

> Sorry, normalerweise kenne ich von dir eigentlich fundierte Kommentare,
> aber beim aktuellen Thema fehlt es anscheinend an Grundlagen.

Anscheinend nicht, denn...

> Windows ist eigentlich für mich was nervtötendes, ich benutze das nur
> unter Zwang. Aber unter dem maroden Krempel werkelt aber ein Kernel, der
> früher mal VMS hieß und der, schon bevor B.Gates den Hern Cutler
> eingekauft hat, Dinge konnte, die sich manche offensicht auch heute noch
> nicht vorstellen können. Nicht ohne Grund wurde VMS auf Proczessrechnern
> eingesetzt, da ist Pollen verpönt.

...das ist doch genau mein Reden: benutzt Events statt Polling. ;-)

(Kurz vergewissert -- ja, ich bin hier richtig, der Ausgangspunkt der 
Polling-Diskussion war dieser:

  Beitrag "Re: Welches Tool um einfaches Programm zu erstellen?"

Seit diesem Beitrag versuchen mir einige Menschen zu erklären, daß 
Polling in Wirklichkeit doch irgendwie knorke sei.)

[Heinz (Gast) (Gast)]

Das, was hier alles geschrieben wurde, ist ja alles
gut und schön. Aber bleiben wir doch mal auf dem
Boden der Tatsachen.

Was macht denn ein laufendes Windowsprogramm ?
Es wartet die meiste Zeit auf Ereignisse. Sei
es, daß ein Button gedrückt wird, eine Liste
gescrollt, Dateiauswahl usw. Die Infos bezieht
es aus der Message-Queue, die zyklisch abgefragt
wird. Und auf die für das Programm interessanten
Ereignisse wird dann reagiert. Ob da nun auch
noch systemrelevante Dinge, wie etwa Dateiänderung
u.ä. zusätzlich abgefragt werden, merken wir zeitmäßig
i.d.R. gar nicht.

Ob das Abfragen betriebssystemintern über Polling
oder Zeitscheiben geschieht, kann man sowieso nicht
beeinflussen. Es ist ja so ausgelegt, daß normalerweise
keine Ereignisse verloren gehen.

Man kann sowas ganz gut verfolgen, wenn man einen
Timer ins Programm einbaut. Wählt man das Timerereignis
unter 300 MS, merkt man, daß sich das Programm immer
schwerer bedienen läßt. Da werden dann tatsächlich
Klick-Ereignisse verschluckt. Bei solchen Fällen
ist es immer ratsam, einen Thread statt Timer zu verwenden.

[Bernd K. (prof7bit)]

Heinz (Gast) schrieb:
> Man kann sowas ganz gut verfolgen, wenn man einen
> Timer ins Programm einbaut. Wählt man das Timerereignis
> unter 300 MS, merkt man, daß sich das Programm immer
> schwerer bedienen läßt. Da werden dann tatsächlich
> Klick-Ereignisse verschluckt.

Was für ein kaputtes GUI-Toolkit benutzt Du denn?

[U.G. L. (dlchnr)]

Ich habe mehrere solche Applikationen (PC mit serieller Schnittstelle 
kommuniziert mit Embedded System, http://ultronics.de/all/wxW1.jpg , 
http://ultronics.de/all/sw/EprRd1702A_2.png) mit wxWidgets und 
VisualStudio bzw. Codelite/TDM-GCC (würde also auch mit GCC unter Linux 
funktionieren) gelöst - da ich den ROM/EPROM-Reader eh veröffentlichen 
wollte (bislang fehlt mir dafür die detailierte Dokumentation :-) kann 
ich Dir gegebenenfalls den Sourcecode dafür überlassen. Für die 
Kommunikation verwende ich immer Boost.Asio, so dass also Boost 
vorhanden sein muss.

Selber würde ich allerdings mein nächstes derartiges Projekt mit 
Qt/TDM-GCC lösen.

[Retro N. (retronerd)]

Ein einfaches Tool, das Dir die meiste Arbeit für GUI und Serial-Port 
uvm. schon abnimmt, ist z.B. Purebasic.

Durch Verwendung umfangreicher Libraries kann man sich auf die 
eigentliche Aufgabe konzentrieren, und das ganze Programm wird nur 
wenige Zeilen gross. Code Beispiele sind in PB inbegriffen. PB erzeugt 
kleine .exe Files, die in der Performance mit C/C++ Programmen 
vergleichbar sind. Läuft unter Windows, Linux und MacOS.

Ein komplett konfigurierbares Demo-Terminalprogramm im Source findest Du 
z.B. hier http://www.purebasic.fr/english/viewtopic.php?t=30372

Wenn Du aber Windows von Grund auf verstehen und in C/C++ programmieren 
möchtest, solltest Du Dir entweder Visual Studio 
https://www.visualstudio.com/de/vs/community/ und die MFC anschauen,
oder etwas kompakter mit reinem C z.B. PellesC (Instant IDE auf Basis 
lcc32) http://www.christian-heffner.de/ und Win-API. C/C++ dürfte vom 
Ergebnis deutlich sinnvoller sein, wenn Du langfristig ernsthaft 
programmieren willst, erfordert aber auch erheblich mehr Einarbeitung.

Wenn Du was fertiges suchst, lohnt vielleicht auch ein Blick auf
https://sourceforge.net/projects/scriptcommunicator/files/
https://www.hw-group.com/products/hercules/index_de.html
https://sites.google.com/site/terminalbpp/