From: Jacek Caban <jacek@codeweavers.com>
To: jcb62281@gmail.com, fortran@gcc.gnu.org,
NightStrike <nightstrike@gmail.com>
Cc: Eric Pouech <eric.pouech@orange.fr>
Subject: Re: testsuite under wine
Date: Wed, 21 Dec 2022 18:37:20 +0100 [thread overview]
Message-ID: <7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com> (raw)
In-Reply-To: <639FE88D.7090408@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]
Hi all,
I'm responsible for Wine changes that cause your problems. I'm also
CCing Eric, who is Wine console expert, maybe he has better ideas. Eric,
see [1] if you're interested in the context.
Recent Wine versions implement Windows pseudo-consoles, see [2] for a
bit more details. It's generally Microsoft's semi-recent API that's
intended to be more compatible with POSIX than what was present in
previous versions of Windows. In theory, with that implemented, we could
just plug tty fds that we get from Unix and have Unix consoles working
using those Windows APIs. In practice, it's not quite as good as
promised and we need some tweaks to make it work nicely. We could
improve those tweaks, but there are architectural limitations that will
come to play sooner or later.
> I think that the long-term solution is that Wine should properly honor
> the TERM environment variable and not produce escape codes that the
> declared terminal does not support.
I think that it would not be enough. The way Windows consoles work is
that we manage complete internal screen buffer and emit output that
synchronizes the buffer with Unix terminal inside conhost.exe process.
It means that its output heavily processed and may be very different
from what application writes to its console handle. While escape codes
discussed in this thread are the most prominent difference (and that
part could, in theory, be improved on our side), there are more
differences. For example, if application writes "\rA\rB\rC", conhost
will process it, update its internal buffer which changes just one
character and cursor position, and emit sequence to update it in Unix
terminal, which could be just "\rC" (or even "C" if cursor was already
at the beginning of the line). Another example would be long lines:
conhost will emit additional EOLs instead of depending on embedder to
wrap the line. I'm not really familiar with DejaGnu, but if you want to
match application output, that's probably not what you're looking for.
The reason the previous workaround of compiling Wine without ncurses
worked is that if made Wine treat tty stdin/stdout in a way very similar
to regular pipes, so no extra processing was performed. This was more of
a side effect than a design choice. It should be possible to provide
some way to achieve that with the new Wine architecture. I'm attaching
an example of Wine patch that would allow it. With that patch, you may
disable conhost.exe (via winecfg or WINEDLLOVERRIDES=conhost.exe=d
environment variable) and achieve something similar to previous workaround.
Long term, I think that it would be best to get rid of console behaviour
expectations by using Windows build of DejaGnu. My understanding is that
it requires Cygwin, so the stack would be: Windows DejaGnu on Cygwin on
Wine on Linux. This would make all similar mismatches in expectations
non-existent. Cygwin is tricky to run on Wine, there are a few known
problems like [3], but we're getting there.
Jacek
[1] https://gcc.gnu.org/pipermail/fortran/2022-December/058645.html
[2]
https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/
[3] https://bugs.winehq.org/show_bug.cgi?id=47808
[-- Attachment #2: console.diff --]
[-- Type: text/x-patch, Size: 2400 bytes --]
diff --git a/dlls/kernelbase/console.c b/dlls/kernelbase/console.c
index 7cd87f53b3c..61569fda9a6 100644
--- a/dlls/kernelbase/console.c
+++ b/dlls/kernelbase/console.c
@@ -2307,33 +2307,45 @@ void init_console( void )
COORD size;
if (is_tty_handle( params->hStdInput ))
- {
tty_in = params->hStdInput;
- params->hStdInput = NULL;
- }
if (is_tty_handle( params->hStdOutput ))
- {
tty_out = params->hStdOutput;
- params->hStdOutput = NULL;
- }
- if (is_tty_handle( params->hStdError ))
- {
- if (tty_out) CloseHandle( params->hStdError );
- else tty_out = params->hStdError;
- params->hStdError = NULL;
- }
+ else if (is_tty_handle( params->hStdError ))
+ tty_out = params->hStdError;
size.X = params->dwXCountChars;
size.Y = params->dwYCountChars;
TRACE( "creating unix console (size %u %u)\n", size.X, size.Y );
params->ConsoleHandle = create_pseudo_console( size, tty_in, tty_out, NULL, 0, &process );
- CloseHandle( process );
- CloseHandle( tty_in );
- CloseHandle( tty_out );
-
- if (params->ConsoleHandle && create_console_connection( params->ConsoleHandle ))
+ if (params->ConsoleHandle)
+ {
+ CloseHandle( process );
+
+ if (is_tty_handle( params->hStdInput ))
+ {
+ CloseHandle( params->hStdInput );
+ params->hStdInput = NULL;
+ }
+ if (is_tty_handle( params->hStdOutput ))
+ {
+ CloseHandle( params->hStdOutput );
+ params->hStdOutput = NULL;
+ }
+ if (is_tty_handle( params->hStdError ))
+ {
+ CloseHandle( params->hStdError );
+ params->hStdError = NULL;
+ }
+
+ if (params->ConsoleHandle && create_console_connection( params->ConsoleHandle ))
+ {
+ init_console_std_handles( FALSE );
+ }
+ }
+ else
{
- init_console_std_handles( FALSE );
+ WARN( "Failed to create console process\n" );
+ params->ConsoleHandle = CONSOLE_HANDLE_SHELL_NO_WINDOW;
}
}
else if (params->ConsoleHandle == CONSOLE_HANDLE_ALLOC ||
next prev parent reply other threads:[~2022-12-21 17:38 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 2:20 NightStrike
2022-12-16 6:44 ` Thomas Koenig
2022-12-17 0:26 ` NightStrike
2022-12-17 10:52 ` Thomas Koenig
2022-12-17 23:24 ` NightStrike
2022-12-18 3:44 ` Jacob Bachmeyer
2022-12-18 21:13 ` NightStrike
2022-12-19 4:29 ` Jacob Bachmeyer
2022-12-19 10:43 ` Torbjorn SVENSSON
2022-12-19 11:00 ` NightStrike
2022-12-19 11:13 ` NightStrike
2022-12-20 3:51 ` Jacob Bachmeyer
2022-12-21 17:37 ` Jacek Caban [this message]
2022-12-22 1:01 ` NightStrike
2022-12-22 4:37 ` Jacob Bachmeyer
2022-12-23 10:36 ` NightStrike
2022-12-23 12:43 ` Eric Pouech
2022-12-24 4:00 ` Jacob Bachmeyer
2022-12-24 11:05 ` Mark Wielaard
2023-01-05 2:50 ` NightStrike
2023-01-06 3:33 ` Jacob Bachmeyer
2023-01-06 3:44 ` Jerry D
2023-01-08 7:12 ` NightStrike
2023-01-11 2:30 ` Jacob Bachmeyer
2023-01-11 9:33 ` NightStrike
2023-01-12 4:11 ` Jacob Bachmeyer
2023-01-06 3:41 ` Jerry D
2022-12-22 4:16 ` Jacob Bachmeyer
2022-12-22 8:40 ` Eric Pouech
2022-12-23 3:51 ` Jacob Bachmeyer
2022-12-23 23:32 ` Jacek Caban
2022-12-24 5:33 ` Jacob Bachmeyer
2023-01-07 1:45 ` Jacek Caban
2023-01-07 3:58 ` Jacob Bachmeyer
2023-01-09 16:03 ` Jacek Caban
2023-01-10 9:19 ` NightStrike
2023-01-11 9:10 ` NightStrike
2023-01-11 18:41 ` NightStrike
2023-01-14 23:36 ` NightStrike
2023-01-11 2:44 ` Jacob Bachmeyer
2023-01-08 6:47 ` NightStrike
2023-01-04 15:21 ` Pedro Alves
2023-01-04 15:45 ` Eric Pouech
2023-01-04 15:52 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7cb45ab2-cc6e-c502-5592-51ffabcbc6f8@codeweavers.com \
--to=jacek@codeweavers.com \
--cc=eric.pouech@orange.fr \
--cc=fortran@gcc.gnu.org \
--cc=jcb62281@gmail.com \
--cc=nightstrike@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).