Zugriff auf Com-Schnittstelle

[Franklin Schiftan]

Hallo miteinander,

beim Versuch eines Umzuges verschiedener Programme von Win nach
Linux bin ich gerade an einem Punkt, wo ich nicht mehr weiterkomme
(zumal ich in Linux nur rudimentäre Kenntnisse habe). Da ich nicht
weiß, an welcher beteiligten Komponente ich am ehesten drehen muss,
mache ich mal ein Crosspost in den Gruppen Windows und Linux. Falls
jemand die Ursache klar erkennen sollte, möge er bitte beim
Antworten ein entsprechend passendes FollowUpTo setzen.

Gegeben ist

1. Ein Notbook mit Win7Ult64, welches keine körperlichen
Com-Anschlüsse mehr hat.
2. Daran angeschlossen ist daher ein USB2Serial-Adapter, der im Host
unter Com3 geführt wird und grundsätzlich auch funktioniert (siehe
Punkt 5)
3. Auf dem Host läuft unter anderem eine 32-bit-Manjaro-Linux-VM in
VirtualBox.
4. In dieser Linux-VM startet mein altes 16-bit-Windows-Programm zur
Telefonanlagen-Konfiguration unter Wine soweit einwandfrei.

ABER es kann den zur Kommunikation mit der Telefonanlage notwendigen
ComPort nicht öffnen (habe testhalber alle vier einstellbaren
ComPorts von 1 bis 4 durchprobiert).

Ein 'dmesg | grep tty' in der Manjaro-Linux-VM-Konsole ergibt u.a.

[ 0.000000] console [tty0] enabled
[ 6.771375] usb 1-2: pl2303 converter now attached to ttyUSB0

Dort scheint der Adapter also grundsätzlich erkannt zu werden, nur
eben nicht als Com-Schnittstelle.

Ist es nun ein Problem der zusätzlichen Wine-Schicht? Oder kann ich
dem 16-bit-Windows-Programm doch noch irgendwie durch Maßnahmen in
der Linux-VM direkt den Zugriff auf die Com-Schnittstelle des
USB2Serial-Adapters ermöglichen?

5. Hinweis: Unter einer alten WinXP-VirtualBox-VM funktioniert das
16-bit-Telefonanlagen-Programm *mit Zugriff* auf die am Host per
USB2Serial-Adapter bereitgestellte Com-Schnittstelle problemlos und
kann Daten mit der Telefonanlage austauschen.

--
..... und tschüss

Franklin

[Michael Baeuerle]

Franklin Schiftan wrote:
>
> [...] Falls

> jemand die Ursache klar erkennen sollte, möge er bitte beim
> Antworten ein entsprechend passendes FollowUpTo setzen.

Fup2 nach de.comp.os.unix.linux.misc gesetzt.

> [...]

> 4. In dieser Linux-VM startet mein altes 16-bit-Windows-Programm zur
> Telefonanlagen-Konfiguration unter Wine soweit einwandfrei.
>
> ABER es kann den zur Kommunikation mit der Telefonanlage notwendigen
> ComPort nicht öffnen (habe testhalber alle vier einstellbaren
> ComPorts von 1 bis 4 durchprobiert).
>
> Ein 'dmesg | grep tty' in der Manjaro-Linux-VM-Konsole ergibt u.a.
>
> [ 0.000000] console [tty0] enabled
> [ 6.771375] usb 1-2: pl2303 converter now attached to ttyUSB0
>
> Dort scheint der Adapter also grundsätzlich erkannt zu werden, nur
> eben nicht als Com-Schnittstelle.

ttySx bzw. ttyUSBx ist bei Linux ziemlich äquivalent zu COMx bei
Windows. Für mich sieht es so aus, als würde nur die Zuordnung nicht
passen.

> Ist es nun ein Problem der zusätzlichen Wine-Schicht? Oder kann ich
> dem 16-bit-Windows-Programm doch noch irgendwie durch Maßnahmen in
> der Linux-VM direkt den Zugriff auf die Com-Schnittstelle des
> USB2Serial-Adapters ermöglichen?

Hast du den COM-Port für Wine passend konfiguriert?

Hier steht was dazu in der Doku:
<https://www.winehq.org/docs/wineusr-guide/misc-things-to-configure>

[Franklin Schiftan]

Nein, noch nicht ... danke für den Link ...

> Hier steht was dazu in der Doku:
> <https://www.winehq.org/docs/wineusr-guide/misc-things-to-configure>

Ich habe - wenn ich die Seite richtig verstanden habe - jetzt also
in /.wine/dosdevices das Kommando 'sudo ln -s /dev/ttyUSB0 COM1'
abgesetzt und finde anschließend in diesem Verzeichnis den
symbolischen Link 'COM1'.

Dennoch kann das Telefonanlagen-Programm die Schnittstelle COM1
immer noch nicht öffnen.

Weitere Hinweise?

[Olaf Kaluza]

Franklin Schiftan <fraschi...@arcor.de> wrote:


>Weitere Hinweise?

Keine Details weil das je nach Linux etwas anderes geloest sein kann.

1. Dein Kernel hat den USB-port erkannt und stellt ihn bereit damit er
genutzt werden koennte.

2. Du musst/kannst irgendwo eintragen welche User ueberhaubt eine
serielle Schnittstelle nutzen duerfen. Es ist ja nicht so das Hinz und
Kunz einfach so die Berechtigung haben das zu tun. Dort musst du den
User eintragen unter dem deine Virtualisierung laeuft.

3. Danach musst du deiner Virtualisierung klar machen das die genau
diese serielle Schnittstelle als Comport durchreichen soll.

4. Und dann stellt sich die Frage ob dein olles Programm ueber Treiber
vom Windows auf den Comport zugreift oder direkt den Portbaustein
programmieren will und ob deine Visualisierung mit letzterem klar
kommt.


Es koennte auch noch eine andere Vorgehensweise funktionieren. Es
muesste eigentlich auch moeglich sein den USB-Port direkt
durchzureichen. Dann sollte unter Linux der Comport nicht auftauschen
und die Virtualisierung benoetigt den Prolific-Treiber.


Ich denke nichts davon ist fuer einen Anfaenger einfach. Viel
Glueck. :)

Olaf

[Franklin Schiftan]

Olaf Kaluza schrieb am 15.01.2016 um 17:00 Uhr:

> Franklin Schiftan <fraschi...@arcor.de> wrote:
>
>> Weitere Hinweise?
>
> Keine Details weil das je nach Linux etwas anderes geloest sein
> kann.

Es handelt sich hier bei dem Manjaro-Linux um ein Arch-Linux-Derivat.

> 1. Dein Kernel hat den USB-port erkannt und stellt ihn bereit
> damit er genutzt werden koennte.
>
> 2. Du musst/kannst irgendwo eintragen welche User ueberhaubt eine
> serielle Schnittstelle nutzen duerfen. Es ist ja nicht so das
> Hinz und Kunz einfach so die Berechtigung haben das zu tun. Dort
> musst du den User eintragen unter dem deine Virtualisierung
> laeuft.

Ich habe jetzt den User der Gruppe 'tty' hinzugefügt. (Eine in
anderen Linuxen wohl vorhandene Gruppe 'dialout' habe ich hier in
meinem Arch-Linux nämlich nicht gefunden.)

Am Misserfolg, die Com-Schnittstelle zu öffnen, hat sich allerdings
dadurch (natürlich nach Ab- und Anmelden) auch nichts geändert.

> 3. Danach musst du deiner Virtualisierung klar machen das die
> genau diese serielle Schnittstelle als Comport durchreichen
> soll.

Hmm, dem virtuellen Gerät sind keine direkten Com-Schnittstellen
zugeordnet, lediglich unter USB-Geräten ist dieser
USB2Serial-Adapter verbunden.
Ich hatte gedacht, dass ich diesen über den wie von Michael
erwähnten symbolischen Link in Linux als 'Com1' zur Verfügung
gestellt habe.

> 4. Und dann stellt sich die Frage ob dein olles Programm ueber
> Treiber vom Windows auf den Comport zugreift

Dazu kann ich jetzt so adhoc natürlich nicht wirklich was sagen.

> oder direkt den Portbaustein programmieren will und ob deine
> Visualisierung mit letzterem klar kommt.
>
>
> Es koennte auch noch eine andere Vorgehensweise funktionieren. Es
> muesste eigentlich auch moeglich sein den USB-Port direkt
> durchzureichen. Dann sollte unter Linux der Comport nicht
> auftauschen

So ist es momentan.

> und die Virtualisierung benoetigt den Prolific-Treiber.

Du meinst einen Prolific-Treiber für Linux? Wobei auf der
Hersteller-Seite steht "NOTE: Linux Kernel 2.4.31 and above already
includes built-in drivers for PL-2303 (VID_067B&PID_2303)." Danach
sollte das ja wohl eigentlich notwendig sein.

> Ich denke nichts davon ist fuer einen Anfaenger einfach.

Das ist zweifelsohne richtig ... ;-) ... ich bemühe mich redlich,
die notwendigen Infos aufzutreiben ... auch wenn's dann mit der
Umsetzung leider doch nicht immer gleich klappt ...

> Viel Glueck. :)

Danke ... mal sehen, ob ich diesen COMport-Zugriff noch irgendwann
unter Linux hinkriege ...

> Olaf

[Marcel Mueller]

On 15.01.16 11.31, Franklin Schiftan wrote:
> 1. Ein Notbook mit Win7Ult64, welches keine körperlichen
> Com-Anschlüsse mehr hat.
> 2. Daran angeschlossen ist daher ein USB2Serial-Adapter, der im Host
> unter Com3 geführt wird und grundsätzlich auch funktioniert (siehe
> Punkt 5)
> 3. Auf dem Host läuft unter anderem eine 32-bit-Manjaro-Linux-VM in
> VirtualBox.
> 4. In dieser Linux-VM startet mein altes 16-bit-Windows-Programm zur
> Telefonanlagen-Konfiguration unter Wine soweit einwandfrei.

Sicher, dass es 16 Bit, also Windows 3.1(1) ist?

> ABER es kann den zur Kommunikation mit der Telefonanlage notwendigen
> ComPort nicht öffnen (habe testhalber alle vier einstellbaren
> ComPorts von 1 bis 4 durchprobiert).

Das wird nichts. Unter 16 Bit Windows gab es noch kein USB und auch
keine (brauchbare) Serial-Port API. Deshalb haben die meisten Programme
direkt auf die UART Controllerchips zugegriffen. Aber Wine kann AFAIK
keine UART-Chips emulieren.

Du braucht eine VM die den 16550 Controller emulieren kann. VirtualBox
kann das.
Dazu müsstest Du aber Win 3.11 (16 Bit) direkt in VBox installieren,
ohne ein Linux dazwischen. Nun ist eine Win 3.1 Installation selbst in
einer VM wahrlich kein Vergnügen. Alternativ ginge auch OS/2 oder
eComStation. Das kann 16 Bit Windows Programme nativ ausführen und
erlaubt diesen direkten Hardwarezugriff auf die nunmehr virtuellen UART
Chips.

> Ist es nun ein Problem der zusätzlichen Wine-Schicht?

Ich würde sagen ja.

> Oder kann ich
> dem 16-bit-Windows-Programm doch noch irgendwie durch Maßnahmen in
> der Linux-VM direkt den Zugriff auf die Com-Schnittstelle des
> USB2Serial-Adapters ermöglichen?

Nein Direkt geht nicht. Die Dinger sind technisch komplett inkompatibel.
Die alten Programme wollen üblicherweise direkt auf die 16550 Controller
Chips zugreifen. Dieser Chip muss erst mal emuliert werden.

Aber vielleicht hast Du ja Glück, und es ist gar kein 16 Bit Programm,
sondern Win32. (Oft waren nur die Installer 16 Bit.)
Oder aber, Du hast eines der wenigen 16 Bit Programme erwischt, die
tatsächlich die damaligen APIs für den COM-Port Zugriff nutzen.
In diesen Fällen sollten tatsächlich korrekte Konfigurationsmaßnahmen
reichen.

> 5. Hinweis: Unter einer alten WinXP-VirtualBox-VM funktioniert das
> 16-bit-Telefonanlagen-Programm *mit Zugriff* auf die am Host per
> USB2Serial-Adapter bereitgestellte Com-Schnittstelle problemlos und
> kann Daten mit der Telefonanlage austauschen.

Das spricht eigentlich dafür, dass es sich in Wirklichkeit um ein Win32
Programm handelt, denn der direkte COM-Port Zugriff ging auch unter
WinXP schon nicht mehr. Da war bei WinME Schluss.


Marcel

[Franklin Schiftan]

Marcel Mueller schrieb am 15.01.2016 um 18:21 Uhr:

> On 15.01.16 11.31, Franklin Schiftan wrote:
>> 1. Ein Notbook mit Win7Ult64, welches keine körperlichen
>> Com-Anschlüsse mehr hat.
>> 2. Daran angeschlossen ist daher ein USB2Serial-Adapter, der im Host
>> unter Com3 geführt wird und grundsätzlich auch funktioniert (siehe
>> Punkt 5)
>> 3. Auf dem Host läuft unter anderem eine 32-bit-Manjaro-Linux-VM in
>> VirtualBox.
>> 4. In dieser Linux-VM startet mein altes 16-bit-Windows-Programm zur
>> Telefonanlagen-Konfiguration unter Wine soweit einwandfrei.
>
> Sicher, dass es 16 Bit, also Windows 3.1(1) ist?

Ja ... es ist von 2001 und in den File-Headern steht unter anderem

Description : ETS4016
Signature : 454Eh ( 16bit for Windows 3.x )
Target Operating system : Microsoft Windows
Expected Windows Version : 3.10
Linker Version : 6.01

>> ABER es kann den zur Kommunikation mit der Telefonanlage notwendigen
>> ComPort nicht öffnen (habe testhalber alle vier einstellbaren
>> ComPorts von 1 bis 4 durchprobiert).
>
> Das wird nichts. Unter 16 Bit Windows gab es noch kein USB und auch
> keine (brauchbare) Serial-Port API. Deshalb haben die meisten Programme
> direkt auf die UART Controllerchips zugegriffen. Aber Wine kann AFAIK
> keine UART-Chips emulieren.
>
> Du braucht eine VM die den 16550 Controller emulieren kann. VirtualBox
> kann das.
> Dazu müsstest Du aber Win 3.11 (16 Bit) direkt in VBox installieren,
> ohne ein Linux dazwischen.

Wie gesagt, mit WinXP in einer VM ist es kein Problem.

>> Ist es nun ein Problem der zusätzlichen Wine-Schicht?
>
> Ich würde sagen ja.
>
>> Oder kann ich
>> dem 16-bit-Windows-Programm doch noch irgendwie durch Maßnahmen in
>> der Linux-VM direkt den Zugriff auf die Com-Schnittstelle des
>> USB2Serial-Adapters ermöglichen?
>
> Nein Direkt geht nicht. Die Dinger sind technisch komplett inkompatibel.
> Die alten Programme wollen üblicherweise direkt auf die 16550 Controller
> Chips zugreifen. Dieser Chip muss erst mal emuliert werden.
>
> Aber vielleicht hast Du ja Glück, und es ist gar kein 16 Bit Programm,
> sondern Win32.

Dann würde es ja auch ohne eine entsprechende Fehlermeldung direkt
auf meinem Win7Ult64-Host-BS laufen können.

> Oder aber, Du hast eines der wenigen 16 Bit Programme erwischt, die
> tatsächlich die damaligen APIs für den COM-Port Zugriff nutzen.
> In diesen Fällen sollten tatsächlich korrekte Konfigurationsmaßnahmen
> reichen.
>
>> 5. Hinweis: Unter einer alten WinXP-VirtualBox-VM funktioniert das
>> 16-bit-Telefonanlagen-Programm *mit Zugriff* auf die am Host per
>> USB2Serial-Adapter bereitgestellte Com-Schnittstelle problemlos und
>> kann Daten mit der Telefonanlage austauschen.
>
> Das spricht eigentlich dafür, dass es sich in Wirklichkeit um ein Win32
> Programm handelt, denn der direkte COM-Port Zugriff ging auch unter
> WinXP schon nicht mehr. Da war bei WinME Schluss.

Wie gesagt über diesen USB2Serial-Adapter kann es (unter der
WinXP-VM) auf die Telefonanlage zugreifen.

> Marcel

Danke für Deine Gedanken dazu ...

[Olaf Kaluza]

Franklin Schiftan <fraschi...@arcor.de> wrote:


>> und die Virtualisierung benoetigt den Prolific-Treiber.

>Du meinst einen Prolific-Treiber für Linux? Wobei auf der

Nein, das meinte ich eben nicht! Du musst dann sogar Linux klar machen
das es selber die Finger von Prolific USB/RS232 Wandlern laesst. Ich
nutze aehnliches fuer einen Debugger. Auch da habe ich Linux gesagt
das diese GeraeteID nicht begrabbelt werden soll, und das eben der
Zugriff komplett durchgereicht wird. Dadurch musste ich dann unter dem
virtualisierten Windows den Originalwindowstreiber vom Hersteller
nutzen.

Das koennte aber bei einem USB/RS232 Geraet kritischer sein weil du
vielleicht andere Geraete dieses Typs unter Linux nutzen moechtest.
Es ist daher schwer zu sagen was in deinem Fall die bessere Loesung
ist.

>Hersteller-Seite steht "NOTE: Linux Kernel 2.4.31 and above already
>includes built-in drivers for PL-2303 (VID_067B&PID_2303)." Danach
>sollte das ja wohl eigentlich notwendig sein.

Das bezieht sie auf die Verwendung eines Geraetes unter Linux. Genau
das willst du aber nicht.


Olaf

[Franklin Schiftan]

Olaf Kaluza schrieb am 15.01.2016 um 20:05 Uhr:

> Franklin Schiftan <fraschi...@arcor.de> wrote:
>
>>> und die Virtualisierung benoetigt den Prolific-Treiber.
>
>> Du meinst einen Prolific-Treiber für Linux? Wobei auf der
>
> Nein, das meinte ich eben nicht! Du musst dann sogar Linux klar
> machen das es selber die Finger von Prolific USB/RS232 Wandlern
> laesst. Ich nutze aehnliches fuer einen Debugger. Auch da habe
> ich Linux gesagt das diese GeraeteID nicht begrabbelt werden
> soll, und das eben der Zugriff komplett durchgereicht wird.
> Dadurch musste ich dann unter dem virtualisierten Windows den
> Originalwindowstreiber vom Hersteller nutzen.

Hmm, ich dachte, dass Wine nicht vergleichbar ist mit einer
"richtigen" Virtualisierung, sondern nur eine zusätzliche
Windows-Schicht einzieht.

> Das koennte aber bei einem USB/RS232 Geraet kritischer sein weil
> du vielleicht andere Geraete dieses Typs unter Linux nutzen
> moechtest.

Nö, im Moment eigentlich nicht.

> Es ist daher schwer zu sagen was in deinem Fall die bessere
> Loesung ist.
>
>> Hersteller-Seite steht "NOTE: Linux Kernel 2.4.31 and above
>> already includes built-in drivers for PL-2303
>> (VID_067B&PID_2303)." Danach sollte das ja wohl eigentlich
>> notwendig sein.
>
> Das bezieht sie auf die Verwendung eines Geraetes unter Linux.

Klar, so hatte ich ja Dein 'und die Virtualisierung benoetigt den
Prolific-Treiber' verstanden, denn das Linux läuft ja virtualisiert,
wohingegen das Telefonanlagen-Programm nur per Wine unter dem Linux
lauffähig gemacht wird, was ich jetzt aber nicht als weitere
Virtualisierung bezeichnen würde.

Oder meintest Du, ich müsse irgendwie in Wine noch den
Prolific-Treiber installieren?

> Genau das willst du aber nicht.
>
> Olaf

[Franklin Schiftan]

Olaf Kaluza schrieb am 15.01.2016 um 20:05 Uhr:

> Franklin Schiftan <fraschi...@arcor.de> wrote:
>
> >> und die Virtualisierung benoetigt den Prolific-Treiber.
>
> >Du meinst einen Prolific-Treiber für Linux? Wobei auf der
>
> Nein, das meinte ich eben nicht! Du musst dann sogar Linux klar machen
> das es selber die Finger von Prolific USB/RS232 Wandlern laesst. Ich
> nutze aehnliches fuer einen Debugger. Auch da habe ich Linux gesagt
> das diese GeraeteID nicht begrabbelt werden soll, und das eben der
> Zugriff komplett durchgereicht wird. Dadurch musste ich dann unter dem
> virtualisierten Windows den Originalwindowstreiber vom Hersteller
> nutzen.

So, ich habe inzwischen einige weitere Dinge probiert.

Zum einen habe ich festgestellt, dass diese ttyS* und auch das
ttyUSB0-Gerät weder zur Gruppe 'tty', wie ich zunächst dachte, und
auch nicht zur Gruppe 'dialout', wie es wohl in anderen
Distributionen der Fall sein soll, gehört, sondern zur Gruppe
'uucp'. Ich habe daher meinen User auch noch der Gruppe 'uucp'
zugefügt. Dies hat mir allerdings immer noch keinen Zugriff aus Wine
heraus auf den USB2Serial-Adapter verschafft.

Unter Linux kann ich den Comport übrigens mit minicom ansprechen,
bloß aus Wine heraus gelingt es noch nicht.

Als nächstes habe ich die Seite <http://wiki.winehq.org/USB>
gefunden und gemäß der dortigen Beschreibung die beiden
Registry-Zweige aus dem alten Win-XP-Rechner innerhalb von Wine
erfolgreich in die Registry importiert und die im Service-Zweig
genannte Treiberdatei 'ser2pl.sys' ebenfalls aus dem Win-XP in Wine
nach /system32/drivers kopiert.

Anschließend den auf der Seite genannten chmod-Befehl für die
gefundene Bus- und Device-Number abgesetzt.

Leider klappt der Zugriff auf den Comport mit meinem
16-bit-Windows-Programm aus Wine heraus immer noch nicht. :-(

Hat jemand weitere Ideen, was ich noch ausprobieren könnte?

[Marcel Mueller]

On 15.01.16 18.47, Franklin Schiftan wrote:
>> Sicher, dass es 16 Bit, also Windows 3.1(1) ist?
>
> Ja ... es ist von 2001 und in den File-Headern steht unter anderem

Die Jahreszahl passt dazu aber nicht ganz. In 2001 hat wirklich
/niemand/ mehr freiwillig Win 3.1 Programme geschrieben.

>> Du braucht eine VM die den 16550 Controller emulieren kann. VirtualBox
>> kann das.
>> Dazu müsstest Du aber Win 3.11 (16 Bit) direkt in VBox installieren,
>> ohne ein Linux dazwischen.
>
> Wie gesagt, mit WinXP in einer VM ist es kein Problem.

Wenn es 32 Bit ist.

[...]

> Wie gesagt über diesen USB2Serial-Adapter kann es (unter der
> WinXP-VM) auf die Telefonanlage zugreifen.

Was spricht dann dagegen, eine vom Internet getrennte XP VM zu betreiben?


Marcel

[Franklin Schiftan]

Marcel Mueller schrieb am 17.01.2016 um 21:16 Uhr:

> On 15.01.16 18.47, Franklin Schiftan wrote:
>>> Sicher, dass es 16 Bit, also Windows 3.1(1) ist?
>>
>> Ja ... es ist von 2001 und in den File-Headern steht unter anderem
>
> Die Jahreszahl passt dazu aber nicht ganz. In 2001 hat wirklich
> /niemand/ mehr freiwillig Win 3.1 Programme geschrieben.

Ursprünglich war es ja ein auch schon unter DOS laufendes Programm,
was dann in 2001 vermutlich lediglich einfach etwas aktualisiert
wurde, aber seine eigentliche Herkunft noch "im Bauch trägt".

>>> Du braucht eine VM die den 16550 Controller emulieren kann. VirtualBox
>>> kann das.
>>> Dazu müsstest Du aber Win 3.11 (16 Bit) direkt in VBox installieren,
>>> ohne ein Linux dazwischen.
>>
>> Wie gesagt, mit WinXP in einer VM ist es kein Problem.
>
> Wenn es 32 Bit ist.

Offensichtlich auch für dieses 16-bit-Programm.

>> Wie gesagt über diesen USB2Serial-Adapter kann es (unter der
>> WinXP-VM) auf die Telefonanlage zugreifen.
>
> Was spricht dann dagegen, eine vom Internet getrennte XP VM zu betreiben?

Mein Wunsch, möglichst so viel erfolgreich auf Linux zu migrieren,
dass ich die XP-VM nicht mehr brauche. Irgendwie kann ich es noch
nicht ganz glauben, dass der Com-Port-Zugriff dieses Programms aus
Wine über den USB2Serial-Adapter nicht funktionieren soll ....

Danke dennoch auch für Deine Gedanken zu der Problematik.

> Marcel

[Bastian Blank]

Franklin Schiftan wrote:
>> Hier steht was dazu in der Doku:
>> <https://www.winehq.org/docs/wineusr-guide/misc-things-to-configure>
> Ich habe - wenn ich die Seite richtig verstanden habe - jetzt also
> in /.wine/dosdevices das Kommando 'sudo ln -s /dev/ttyUSB0 COM1'
> abgesetzt und finde anschließend in diesem Verzeichnis den
> symbolischen Link 'COM1'.

In der Dokumentation steht aber "ln -s /dev/ttyS0 com1", aka
kleingeschriebenes "com1". Hat es einen Grund warum du das ignorierst?

Bastian

[Franklin Schiftan]

Gute Frage ... ;-) ... ja, weil es in dem fraglichen
16-bit-Windowsprogramm, welches ja darauf zugreifen sollte,
großgeschrieben wurde.

Aber keine Bange, natürlich habe ich es nach diesem ersten
erfolglosen Test dann auch noch mit dem kleingeschriebenen
symbolischen Link - ebenfalls ohne Erfolg - probiert.

Aber danke der Nachfrage, hätte ja wirklich sein können, dass es
daran liegt.

> Bastian

[Bernd Klier]

>> Hier steht was dazu in der Doku:
>> <https://www.winehq.org/docs/wineusr-guide/misc-things-to-configure>
>
> Ich habe - wenn ich die Seite richtig verstanden habe - jetzt also
> in /.wine/dosdevices das Kommando 'sudo ln -s /dev/ttyUSB0 COM1'
> abgesetzt und finde anschließend in diesem Verzeichnis den
> symbolischen Link 'COM1'.

Falls das da oben kein Tippfehler war, dann ist dein Symlink im falschen
Verzeichnis.
In der Dokumentation steht ~/.wine/dosdevices und das ist ganz was
anderes als /.wine/dosdevices

Bernd

[Franklin Schiftan]

Echt? Danke für Dein aufmerksames Mitlesen, aber kannst Du mir bitte
kurz den Unterschied erklären?

In meinem Home-Verzeichnis gibt es das Verzeichnis '.wine', und in
diesem Verzeichnis wiederum gibt es das Verzeichnis 'dosdevices'.
Und in diesem Verzeichnis hab ich das besagte Kommando abgesetzt, so
dass *dort* also unter '/home/leser/.wine/dosdevices' nun auch die
besagten Symlinks liegen.

Wo sollten sie stattdessen liegen?

> Bernd

[Helmut Hullen]

Hallo, Franklin,

Du meintest am 02.02.16:

>> In der Dokumentation steht ~/.wine/dosdevices und das ist ganz was
>> anderes als /.wine/dosdevices

> Echt? Danke für Dein aufmerksames Mitlesen, aber kannst Du mir bitte
> kurz den Unterschied erklären?

> In meinem Home-Verzeichnis gibt es das Verzeichnis '.wine', und in
> diesem Verzeichnis wiederum gibt es das Verzeichnis 'dosdevices'.
> Und in diesem Verzeichnis hab ich das besagte Kommando abgesetzt, so
> dass *dort* also unter '/home/leser/.wine/dosdevices' nun auch die
> besagten Symlinks liegen.

> Wo sollten sie stattdessen liegen?

Das Home-Verzeichnis wird bei Linux gern mit "~" abgekürzt. Du hast den
Eintrag also ins richtige Verzeichnis gepackt, aber den Pfad zu diesem
Eintrag falsch beschrieben.

Du solltest Dir ein Grundlagen-Buch zulegen ...

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Franklin Schiftan]

Helmut Hullen schrieb am 02.02.2016 um 10:36 Uhr:

>>> In der Dokumentation steht ~/.wine/dosdevices und das ist
>>> ganz was anderes als /.wine/dosdevices
>
>> Echt? Danke für Dein aufmerksames Mitlesen, aber kannst Du mir
>> bitte kurz den Unterschied erklären?
>
>> In meinem Home-Verzeichnis gibt es das Verzeichnis '.wine', und
>> in diesem Verzeichnis wiederum gibt es das Verzeichnis
>> 'dosdevices'. Und in diesem Verzeichnis hab ich das besagte
>> Kommando abgesetzt, so dass *dort* also unter
>> '/home/leser/.wine/dosdevices' nun auch die

Ist ja lustig, beim Lesen meines Beitrages, sehe ich den Slash vor
dem Punkt gar nicht ... im Editor ist er aber enthalten ...

>> besagten Symlinks liegen.
>
>> Wo sollten sie stattdessen liegen?
>
> Das Home-Verzeichnis wird bei Linux gern mit "~" abgekürzt. Du
> hast den Eintrag also ins richtige Verzeichnis gepackt,

O.k., alles klar, danke.

> Viele Gruesse Helmut