DOS-Befehl so korrekt?

Dietmar W. schrieb:
> Habe ich so noch nie gesehen.

Diese Schreibweise wird auch nur bei 2stelligen COM-Port-Nummern (die 
man insbesondere bei USB-Seriell-Adaptern gerne hat) zwingend benötigt.

Dietmar W. schrieb:
> so stehen bleiben?

Glaube nich, norm. sehe ich da nur \\.\xyz123
Hier kannst ja mal nachlesen, was es damit auf sich hat:
https://docs.microsoft.com/de-de/dotnet/standard/io/file-path-formats

Ein gutes altes DOS kann mit \\.\\ ueberhaupt nichts anfangen.
Selbst bei einem W98-DOS haette ich da Zweifel.

Da du aber nur eine Environmentvariable setzt, entscheidet
letztendlich die Applikation, ob sie damit etwas anfangen kann.

Fuer USB-Seriell-Adapter aendere ich eher die Einstellung
der Portnummber im Treiber als das ich mit so etwas anfangen
wuerde.

oerks schrieb:
> Ein gutes altes DOS kann mit \\.\\ ueberhaupt nichts anfangen.

\\ ist nichts anderes als eine Escape Sequenz für \, wie man sie auch in 
C Code nutzen kann und ich denke, das wird es sein.
Ein String geeignet für ein Programm das in C geschrieben wurde.

\\.\\ macht also \.\

Dein Befehl ist nicht richtig.

DA siehst du wie das richtig geht ->>> 
https://www.computerhope.com/modehlp.htm

Da siehst du wie das richtig geht. Einfach gesagt der COM-Port muss 
IMMER Initialisiert werden, mit den richtigen Parametern. Ansonsten 
läuft da gar nix.

Nano schrieb:
> \\ ist nichts anderes als eine Escape Sequenz für \, wie man sie auch in
> C Code nutzen kann und ich denke, das wird es sein.

Nein, die "escapelose" Schreibweise ist tatsächlich \\.\COMxx - der 
zusätzliche Backslash hinten ist entweder ein Tippfehler, oder Windows 
toleriert das.

https://support.microsoft.com/en-us/topic/howto-specify-serial-ports-larger-than-com9-db9078a5-b7b6-bf00-240f-f749ebfd913e

Schlaumaier schrieb:
> Da siehst du wie das richtig geht. Einfach gesagt der COM-Port muss
> IMMER Initialisiert werden, mit den richtigen Parametern. Ansonsten
> läuft da gar nix.

Typischer Schlaumaier/Alexander/Pucki-Blödsinn.

Mit SET setzt er eine Environment-Variable für die danach gestartete 
Anwendung. Die wird sich dann schon selbst um die Initialisierung 
kümmern.

> Ein String geeignet für ein Programm das in C geschrieben wurde.

C ist das '\' voellig egal. Es gibt da an der Stelle kein Escape.
Genau wie Java, das den selben Mechanismus nutzt.

1

/* programm.c */

2

#include <stdio.h>

3

4

int main(int argc, char **argv, char **envp){

5

  int c;

6

  while (envp[c] != NULL){

7

    printf("%d\t%s\n",c,envp[c]);

8

    c++;

9

  }

10

}

1

>set PORT=\\.\\

2

3

>programm | find "PORT"

4

33      PORT=\\.\\

Interpretiert wird das erst vom Betriebssystem.

Hmmm schrieb:

> Nein, die "escapelose" Schreibweise ist tatsächlich \\.\COMxx - der
> zusätzliche Backslash hinten ist entweder ein Tippfehler, oder Windows
> toleriert das.

Würde ich auch so sehen.

> Mit SET setzt er eine Environment-Variable für die danach gestartete
> Anwendung. Die wird sich dann schon selbst um die Initialisierung
> kümmern.

So sieht's aus und so sah es praktisch schon immer aus, selbst unter 
DOS. Eigentlich hat nur die Shell selber die "default"-Einstellung 
benutzt, nahezu alle Anwendungen haben immer ihr eigenes Ding gemacht. 
Bei DOS lag das vor allem daran, das es eigentlich wiederum nur auf die 
vom BIOS gelieferten Routinen aufgesetzt hat, die schlicht unglaublich 
grottig waren und die Fähigkeiten selbst des ursprünglich verwendeten 
8250 nicht wirklich ausgenutzt haben, geschweige denn die seiner 
Nachfolger...

Hmmm schrieb:
> Mit SET setzt er eine Environment-Variable für die danach gestartete
> Anwendung. Die wird sich dann schon selbst um die Initialisierung
> kümmern.

Wenn das Programm so schlau ist, wieso macht es dann nicht alles selbst.

Dos-Commands macht man nur wenn es nicht anders geht.

c-hater schrieb:
> Eigentlich hat nur die Shell selber die "default"-Einstellung
> benutzt, nahezu alle Anwendungen haben immer ihr eigenes Ding gemacht.

Völlig richtig.

Und wenn die schon ihr eigenes Ding machen, dann brauchen die auch keine 
Shell-Befehle.

Schlaumaier schrieb:
> Wenn das Programm so schlau ist, wieso macht es dann nicht alles selbst.

Tut es doch. Es bekommt lediglich - in diesem Fall per Environment - 
mitgeteilt, welchen COM-Port es verwenden soll.

Schlaumaier schrieb:
> Dos-Commands macht man nur wenn es nicht anders geht.

Environment-Variablen sind ausserhalb Deiner beschränkten Welt nichts 
Ungewöhnliches.

Schlaumaier schrieb:
> Und wenn die schon ihr eigenes Ding machen, dann brauchen die auch keine
> Shell-Befehle.

Aber eine Konfiguration. Ob man die in der Registry, einer 
Konfigurationsdatei oder auch im Environment ablegt, ist ziemlich egal.

Hmmm schrieb:
> Aber eine Konfiguration. Ob man die in der Registry, einer
> Konfigurationsdatei oder auch im Environment ablegt, ist ziemlich egal.

Jepp. Aber genau DIE Konfiguration macht man im Programm.

Da kann ich mich noch an meine GW-Basic + Powerbasic Zeit erinnern. Da 
habe ich öfters mit den Serial-Port gearbeitet. Und die GANZEN 
Einstellungen wurden im Programm gemacht.  Wieso zu Hölle soll das in 
der modernen Zeit anders sein.  Aktuell meine COM-Port-Einstellungen für 
die Arduino-Ansteuerung speichere + Steuere ich doch auch in meine 
Programm. tz tz tz

Das einzige wozu ich mal den das Dos-Zeug für Serial gebraucht habe war 
als ich lpt1: auf com1: umgelegt habe. Was dazu führe das die 
Druckerausgabe meine DOS-Programm auf den Terminal-Programm meines Amiga 
erfolgte. Papier war teuer und Nadeldrucker laut (besonders nachts).
Noch schön brav mich ESC-Code als Steuerbefehle. ;) Das waren noch 
Zeiten.

In modernen Umgebungen habe ich das nur einmal benutzt. Um LPT1: auf USB 
um zu lenken. Das doofe Prg. kannte nur LPT1: als Druckerport.

Schlaumaier schrieb:
> Aber genau DIE Konfiguration macht man im Programm.

Du als Profi weisst natürlich, wie "man" es richtig macht.

Und woher weisst Du, ob dieses Programm überhaupt eine 
Benutzeroberfläche hat und nicht bloss ein Tool für die Commandline ist?

Genau, Du weisst es nicht und lieferst deshalb nur nutzlose 
"Informationen" wie den obigen Unsinn bzgl. MODE.

Hmmm schrieb:
> Und woher weisst Du, ob dieses Programm überhaupt eine
> Benutzeroberfläche hat und nicht bloss ein Tool für die Commandline ist?

bei einen  Tool für die Commandline übergebe ich diese Infos als 
Parameter. ;)