[Bug 49923] New: [Wine 5.18] Wineconsole curses backend support was removed.
https://bugs.winehq.org/show_bug.cgi?id=49923 Bug ID: 49923 Summary: [Wine 5.18] Wineconsole curses backend support was removed. Product: Wine Version: 5.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P5 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ttallink(a)googlemail.com Distribution: ArchLinux Hello, Today, after an update of my ArchLinux based server I was saddened and frustrated to find out that in Wine 5.18, the curses backend was removed from the available command line options of 'wineconsole'. I personally rely on wineconsole and _ESPECIALLY_, the curses backend - wineconsole is spawned as a systemd service configured to attach a pseudo terminal (/dev/ptmx), in order to run a backend for a Windows application I wrote. However, in Wine 5.18, the curses backend was removed, quoting the changelog: wineconsole: Remove curses backend. This is a total no-go for me and many others running Windows binaries through wineconsole on servers, since we need to be able to run wineconsole without a display / using a terminal session. Can you please elucidate as for why the curses backend was removed in the first place? I now have to downgrade to downgrade to 5.17 in order to be able to host the service again. This is a HUGE loss of functionality for those using Wine / wineconsole on servers. PLEASE consider adding the curses backend again. Best Regards, William Kane -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[Wine 5.18] Wineconsole |Wineconsole curses backend |curses backend support was |support was removed. |removed. | Severity|blocker |normal CC| |jacek(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #1 from Jacek Caban <jacek(a)codeweavers.com> --- Why do you need wineconsole in the first place? Before removing the backend, default Wine console handling was extended to support most of curses backend functionality (without relying on curses library). Ideally, you should be able to change your systemd service to run your application directly by wine instead of through wineconsole. Please give it a try. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #2 from ttallink(a)googlemail.com --- (In reply to Jacek Caban from comment #1)
Why do you need wineconsole in the first place? Before removing the backend, default Wine console handling was extended to support most of curses backend functionality (without relying on curses library). Ideally, you should be able to change your systemd service to run your application directly by wine instead of through wineconsole. Please give it a try.
The whole purpose of wineconsole is to run applications that don't have a GUI.. I tried the main wine binary but it requires a running X.Org server as well as a display, even if the binary you are running does not need either of those. I tried working around the issue, but on a server where I only have terminal / ssh sessions, it's simply impossible - wineconsole with the curses backend works perfectly fine with a very small memory footprint (< 10mb's) and there is no replacement for it (except for maybe rewriting my application but it relies on Windows-exclusive header files / structures and I don't feel like copying them all to convert my app into a native binary). So, my request remains: Please re-add the curses backend, without it, I can no longer spawn wineconsole as a service to host the backend of my software - many other people doing the same will also be affected while there is no need to remove the curses backend in the first place, it was working without any problems. Best Regards, William -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 ttallink(a)googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #3 from Jacek Caban <jacek(a)codeweavers.com> --- (In reply to ttallink from comment #2)
The whole purpose of wineconsole is to run applications that don't have a GUI.. I tried the main wine binary but it requires a running X.Org server as well as a display, even if the binary you are running does not need either of those.
Wine may try to load display driver, but it should work fine if it can't be loaded. What's the exact problem? Please attach console,conhost,wineconsole logs of the problem when running the application directly, without explicit wineconsole. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 Roman Pišl <rpisl(a)seznam.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rpisl(a)seznam.cz --- Comment #4 from Roman Pišl <rpisl(a)seznam.cz> --- I must say that I also don't like this approach of removing features that just work especially in a "compatibility layer". If there is a new and better implementation, use it, but preserve that option. If it is not possible at least print an explanatory message. Wineconsole with this option is useful and probably used in many scenarios and now these are broken. And my question is: will the new console handling support ALL the curses functionality? What are the testing applications during the development? Far Manager is a classic open source console app and now it behaves badly in the text console. Should I open several bugs? Not that I need this for my work, but it is a good testing case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 ttallink(a)googlemail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |critical -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #5 from ttallink(a)googlemail.com --- (In reply to Jacek Caban from comment #3)
(In reply to ttallink from comment #2)
The whole purpose of wineconsole is to run applications that don't have a GUI.. I tried the main wine binary but it requires a running X.Org server as well as a display, even if the binary you are running does not need either of those.
Wine may try to load display driver, but it should work fine if it can't be loaded. What's the exact problem? Please attach console,conhost,wineconsole logs of the problem when running the application directly, without explicit wineconsole.
My server is a production server and I can't afford to play around on it just to provide logs - run wineconsole from a terminal session, you will get the exact same errors I'm getting. And no, it does not work fine - wineconsole with the curses backend was the ONLY way to run my application, and it worked fine for many years, until someone decided to remove it for absolutely no reason. My application is also not opening a console nor any windows, so there are no logs to provide from the app's console, it all gets logged to a log file inside the application sandbox and those logs are completely unrelated to wineconsole. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #6 from Jacek Caban <jacek(a)codeweavers.com> --- (In reply to Roman Pišl from comment #4)
And my question is: will the new console handling support ALL the curses functionality?
On the Windows API side, it already supports all the functionality. On Unix console side, a few things like resize or mouse events don't work yet. It shouldn't prevent applications from running, through.
What are the testing applications during the development? Far Manager is a classic open source console app and now it behaves badly in the text console. Should I open several bugs?
This patch should fix it: https://source.winehq.org/patches/data/193837 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal Keywords| |download, patch --- Comment #7 from Austin English <austinenglish(a)gmail.com> --- Not critical, please stop changing the severity. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #8 from Roman Pišl <rpisl(a)seznam.cz> ---
What are the testing applications during the development? Far Manager is a classic open source console app and now it behaves badly in the text console. Should I open several bugs?
This patch should fix it: https://source.winehq.org/patches/data/193837
Yes, it does. Now I also understand to the whole concept of rework, so my comment is not relevant any more. The console works pretty well now, but there are still some regressions. I will eventually open bugs for them. Great work, thanks. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #9 from ttallink(a)googlemail.com --- I'll explain, in great detail, my problem again: wineconsole is still broken for me - granted, I did not try 5.19 due to the nature of my servers (that is, thousands of users being connected at once, any reboot means a forced disconnect and distress to my users so I try to avoid it until it's absolutely necessary, i.e. necessary security updates and the likes). To add some clarification: My application, a 12kb sized Windows PE binary, has been compiled in a way so that it does not open any windows or console (-mwindows compiler directive, using GCC 8.1 from mingw-w64), it silently runs in the background, waiting for connections from users using the Winsock API. This is the systemd unit file used to launch the service: [Unit] Description=*redacted* After=syslog.target network.target nss-lookup.target [Service] Type=simple ExecStart=/usr/bin/wineconsole --backend=curses /*redacted*/*redacted*.exe WorkingDirectory=/*redacted* User=*redacted* Group=users Environment=TERM=dumb StandardInput=tty-force TTYPath=/dev/pts/ptmx KillSignal=SIGINT [Install] WantedBy = multi-user.target You can see that I am attaching the /dev/pts/ptmx pseudo-terminal in order to make the curses backend happy - any output written to that terminal is of course discarded, but since there is no output in the first place, this was a nice work-around in order to make wineconsole work through systemd without having a 99% CPU usage after starting the service (other, unrelated bug). Now, that the curses backend was removed, the option to use wineconsole through a systemd service with a pseudo-terminal attached has vanished - it now requires a fully fledged desktop environment along with a display (or so it seems). Is this wanted behavior? In my opinion, definitely not - there should be a way to run wineconsole as a service, without any desktop environment, X Server or displays available - however, since Wine 5.18, and the removal of the curses backend, this is no longer possible - only option for me and others is to stay on 5.17 indefinitely , however, I would still like to receive security and optional updates for Wine. Please consider working around this issue by making wineconsole not require a desktop session / display, optionally only if some certain command line is passed, so we can run it as a service with a pseudo terminal attached. If anyone has any ideas on how to get this service running on Wine 5.18 or later, on a remote server with no graphics hardware, desktop environment or X Server, then please enlighten me, I'd be truly grateful. Yours truly, William -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49923 --- Comment #10 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to ttallink from comment #9)
Now, that the curses backend was removed, the option to use wineconsole through a systemd service with a pseudo-terminal attached has vanished - it now requires a fully fledged desktop environment along with a display (or so it seems).
Is this wanted behavior?
No, something like the following is supposed to work: unset DISPLAY wine cmd I.e., if "wineconsole --backend=curses <executable>" previously worked without DISPLAY set, "wine <executable>" should currently work under the same circumstances. If it doesn't, that's a bug, but there should be no need for wineconsole to be involved. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla