On 12.02.2016 00:32, André Hentschel wrote:
Signed-off-by: André Hentschel nerv@dawncrow.de
For https://bugs.winehq.org/show_bug.cgi?id=11811
programs/wineboot/wineboot.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Are you sure there are no keys for com ports >= 10? In general, such serial ports are also possible.
Nevertheless, more important: If I don't miss anything, the user still has to manually create a symlink in dosdevices/, otherwise this method will not work. Accessing serial ports on the other hand doesn't require any manual configuration when get_default_com_device() recognizes them (and the user has access). What is the benefit when it still requires manual user interaction?
Am 12.02.2016 um 09:46 schrieb Sebastian Lackner:
On 12.02.2016 00:32, André Hentschel wrote:
Signed-off-by: André Hentschel nerv@dawncrow.de
For https://bugs.winehq.org/show_bug.cgi?id=11811
programs/wineboot/wineboot.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Are you sure there are no keys for com ports >= 10? In general, such serial ports are also possible.
In other places the symlink method seems to be limited from 1 to 9 (e.g. QueryDosDeviceW)
Nevertheless, more important: If I don't miss anything, the user still has to manually create a symlink in dosdevices/, otherwise this method will not work. Accessing serial ports on the other hand doesn't require any manual configuration when get_default_com_device() recognizes them (and the user has access). What is the benefit when it still requires manual user interaction?
I think get_default_com_device() isn't a normal way to use com ports in Wine. For example, I have /dev/ttyS0 to 31, most likely announced by my laptop motherboard, but would never intend to use those ports, which are not wired out. Normal usecase would be to plug in a USB-Serial-Adapter and make a symlink to e.g. /dev/ttyUSB0
On 12.02.2016 20:15, André Hentschel wrote:
Am 12.02.2016 um 09:46 schrieb Sebastian Lackner:
On 12.02.2016 00:32, André Hentschel wrote:
Signed-off-by: André Hentschel nerv@dawncrow.de
For https://bugs.winehq.org/show_bug.cgi?id=11811
programs/wineboot/wineboot.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Are you sure there are no keys for com ports >= 10? In general, such serial ports are also possible.
In other places the symlink method seems to be limited from 1 to 9 (e.g. QueryDosDeviceW)
Nevertheless, more important: If I don't miss anything, the user still has to manually create a symlink in dosdevices/, otherwise this method will not work. Accessing serial ports on the other hand doesn't require any manual configuration when get_default_com_device() recognizes them (and the user has access). What is the benefit when it still requires manual user interaction?
I think get_default_com_device() isn't a normal way to use com ports in Wine. For example, I have /dev/ttyS0 to 31, most likely announced by my laptop motherboard, but would never intend to use those ports, which are not wired out. Normal usecase would be to plug in a USB-Serial-Adapter and make a symlink to e.g. /dev/ttyUSB0
Well, but this depends on the exact use-case. I guess the forwarding of /dev/ttyS* was not added just for fun, but because its useful for at least some people. What about adding an explicit test which uses kernel32/ntdll functions, so that all serial ports are added to the registry? To do that, it would be necessary to make the /dev/ttyS* detection a bit more strict, like Alex Henrie tried to do with one of his patches:
https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Ser...
Am 12.02.2016 um 21:26 schrieb Sebastian Lackner:
On 12.02.2016 20:15, André Hentschel wrote:
Am 12.02.2016 um 09:46 schrieb Sebastian Lackner:
On 12.02.2016 00:32, André Hentschel wrote:
Signed-off-by: André Hentschel nerv@dawncrow.de
For https://bugs.winehq.org/show_bug.cgi?id=11811
programs/wineboot/wineboot.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Are you sure there are no keys for com ports >= 10? In general, such serial ports are also possible.
In other places the symlink method seems to be limited from 1 to 9 (e.g. QueryDosDeviceW)
Nevertheless, more important: If I don't miss anything, the user still has to manually create a symlink in dosdevices/, otherwise this method will not work. Accessing serial ports on the other hand doesn't require any manual configuration when get_default_com_device() recognizes them (and the user has access). What is the benefit when it still requires manual user interaction?
I think get_default_com_device() isn't a normal way to use com ports in Wine. For example, I have /dev/ttyS0 to 31, most likely announced by my laptop motherboard, but would never intend to use those ports, which are not wired out. Normal usecase would be to plug in a USB-Serial-Adapter and make a symlink to e.g. /dev/ttyUSB0
Well, but this depends on the exact use-case. I guess the forwarding of /dev/ttyS* was not added just for fun, but because its useful for at least some people. What about adding an explicit test which uses kernel32/ntdll functions, so that all serial ports are added to the registry? To do that, it would be necessary to make the /dev/ttyS* detection a bit more strict, like Alex Henrie tried to do with one of his patches:
https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Ser...
I like your idea and the patch. What about something simpler like:
diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 93fe594..c5fd654 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -329,7 +329,7 @@ static void flush_dir_queue(void) */ static char *get_default_com_device( int num ) { - char *ret = NULL; + char *ret;
if (num < 1 || num > 256) return NULL; #ifdef linux @@ -346,7 +346,15 @@ static char *get_default_com_device( int num ) sprintf( ret, "/dev/cuaa%d", num - 1 ); #else FIXME( "no known default for device com%d\n", num ); + return NULL; #endif + + if (access( ret, R_OK | W_OK )) + { + RtlFreeHeap( GetProcessHeap(), 0, ret ); + return NULL; + } + return ret; }
On 12.02.2016 21:39, André Hentschel wrote:
Am 12.02.2016 um 21:26 schrieb Sebastian Lackner:
On 12.02.2016 20:15, André Hentschel wrote:
Am 12.02.2016 um 09:46 schrieb Sebastian Lackner:
On 12.02.2016 00:32, André Hentschel wrote:
Signed-off-by: André Hentschel nerv@dawncrow.de
For https://bugs.winehq.org/show_bug.cgi?id=11811
programs/wineboot/wineboot.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Are you sure there are no keys for com ports >= 10? In general, such serial ports are also possible.
In other places the symlink method seems to be limited from 1 to 9 (e.g. QueryDosDeviceW)
Nevertheless, more important: If I don't miss anything, the user still has to manually create a symlink in dosdevices/, otherwise this method will not work. Accessing serial ports on the other hand doesn't require any manual configuration when get_default_com_device() recognizes them (and the user has access). What is the benefit when it still requires manual user interaction?
I think get_default_com_device() isn't a normal way to use com ports in Wine. For example, I have /dev/ttyS0 to 31, most likely announced by my laptop motherboard, but would never intend to use those ports, which are not wired out. Normal usecase would be to plug in a USB-Serial-Adapter and make a symlink to e.g. /dev/ttyUSB0
Well, but this depends on the exact use-case. I guess the forwarding of /dev/ttyS* was not added just for fun, but because its useful for at least some people. What about adding an explicit test which uses kernel32/ntdll functions, so that all serial ports are added to the registry? To do that, it would be necessary to make the /dev/ttyS* detection a bit more strict, like Alex Henrie tried to do with one of his patches:
https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Ser...
I like your idea and the patch. What about something simpler like:
diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 93fe594..c5fd654 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -329,7 +329,7 @@ static void flush_dir_queue(void) */ static char *get_default_com_device( int num ) {
- char *ret = NULL;
char *ret;
if (num < 1 || num > 256) return NULL;
#ifdef linux @@ -346,7 +346,15 @@ static char *get_default_com_device( int num ) sprintf( ret, "/dev/cuaa%d", num - 1 ); #else FIXME( "no known default for device com%d\n", num );
- return NULL;
#endif
- if (access( ret, R_OK | W_OK ))
- {
RtlFreeHeap( GetProcessHeap(), 0, ret );return NULL;- }
- return ret;
}
The purpose was not only to filter serial devices without access permissions, but also detect if they are really present on the system, which is not solved with your version of the patch. At least on my system here non-existent serial ports open fine (after giving permissions) but hang when trying to read/write.
Am 12.02.2016 um 21:43 schrieb Sebastian Lackner:
On 12.02.2016 21:39, André Hentschel wrote:
Am 12.02.2016 um 21:26 schrieb Sebastian Lackner:
On 12.02.2016 20:15, André Hentschel wrote:
Am 12.02.2016 um 09:46 schrieb Sebastian Lackner:
On 12.02.2016 00:32, André Hentschel wrote:
Signed-off-by: André Hentschel nerv@dawncrow.de
For https://bugs.winehq.org/show_bug.cgi?id=11811
programs/wineboot/wineboot.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
Are you sure there are no keys for com ports >= 10? In general, such serial ports are also possible.
In other places the symlink method seems to be limited from 1 to 9 (e.g. QueryDosDeviceW)
Nevertheless, more important: If I don't miss anything, the user still has to manually create a symlink in dosdevices/, otherwise this method will not work. Accessing serial ports on the other hand doesn't require any manual configuration when get_default_com_device() recognizes them (and the user has access). What is the benefit when it still requires manual user interaction?
I think get_default_com_device() isn't a normal way to use com ports in Wine. For example, I have /dev/ttyS0 to 31, most likely announced by my laptop motherboard, but would never intend to use those ports, which are not wired out. Normal usecase would be to plug in a USB-Serial-Adapter and make a symlink to e.g. /dev/ttyUSB0
Well, but this depends on the exact use-case. I guess the forwarding of /dev/ttyS* was not added just for fun, but because its useful for at least some people. What about adding an explicit test which uses kernel32/ntdll functions, so that all serial ports are added to the registry? To do that, it would be necessary to make the /dev/ttyS* detection a bit more strict, like Alex Henrie tried to do with one of his patches:
https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Ser...
I like your idea and the patch. What about something simpler like:
diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c index 93fe594..c5fd654 100644 --- a/dlls/ntdll/directory.c +++ b/dlls/ntdll/directory.c @@ -329,7 +329,7 @@ static void flush_dir_queue(void) */ static char *get_default_com_device( int num ) {
- char *ret = NULL;
char *ret;
if (num < 1 || num > 256) return NULL;
#ifdef linux @@ -346,7 +346,15 @@ static char *get_default_com_device( int num ) sprintf( ret, "/dev/cuaa%d", num - 1 ); #else FIXME( "no known default for device com%d\n", num );
- return NULL;
#endif
- if (access( ret, R_OK | W_OK ))
- {
RtlFreeHeap( GetProcessHeap(), 0, ret );return NULL;- }
- return ret;
}
The purpose was not only to filter serial devices without access permissions, but also detect if they are really present on the system, which is not solved with your version of the patch. At least on my system here non-existent serial ports open fine (after giving permissions) but hang when trying to read/write.
OK, interesting, here on Linux Mint I can't even write to ttyS* as root
-
André Hentschel -
Sebastian Lackner