In my effort to improve wineconsole and its calculations of the largest possible window size, three scenarios come into play.
1. wineconsole with --backend=user (or more simply, 'wineconsole app.exe, in which case 'user' is the default). 2. wineconsole with --backend=curses. 3. wineconsole with --backend=curses, but no X server running.
Detecting the screen resolution is a simple task with (1) and (2). SystemParametersInfo for (1) and wine's own XRandR for (2) can be used.
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
The question is, should I worry about supporting such a scenario?
On Thu, 16 May 2013 08:04:07 -0400 Hugh McMaster hugh.mcmaster@masterindexing.com wrote:
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
It's not common, but we have had users on the forum who are using wineconsole to run DOS apps. They're usually pretty adament about not wanting or needing X.
On Thursday, 16 May 2013 Rosanne DiMesio wrote:
On Thu, 16 May 2013 08:04:07 -0400 Hugh McMaster wrote:
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
It's not common, but we have had users on the forum who are using wineconsole to run DOS apps. They're usually pretty adament about not wanting or needing X.
Is it safe to assume then, that such users do not have any X libraries installed? Or do they simply choose not to use an X server?
On 05/16/2013 03:34 PM, Hugh McMaster wrote:
On Thursday, 16 May 2013 Rosanne DiMesio wrote:
On Thu, 16 May 2013 08:04:07 -0400 Hugh McMaster wrote:
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
It's not common, but we have had users on the forum who are using wineconsole to run DOS apps. They're usually pretty adament about not wanting or needing X.
Is it safe to assume then, that such users do not have any X libraries installed? Or do they simply choose not to use an X server?
Yes, that is a safe assumption. Wine is *not* X specific anymore. On MacOSX you can use the native quartz driver. And I wouldn't wonder if Alexandre plans for a native driver for Android too.
bye michael
Le 16/05/2013 15:03, Rosanne DiMesio a écrit :
On Thu, 16 May 2013 08:04:07 -0400 Hugh McMaster hugh.mcmaster@masterindexing.com wrote:
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
It's not common, but we have had users on the forum who are using wineconsole to run DOS apps. They're usually pretty adament about not wanting or needing X.
+1
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 16/05/13 13:04, Hugh McMaster wrote:
In my effort to improve wineconsole and its calculations of the largest possible window size, three scenarios come into play.
- wineconsole with --backend=user (or more simply, 'wineconsole
app.exe, in which case 'user' is the default). 2. wineconsole with --backend=curses. 3. wineconsole with --backend=curses, but no X server running.
Detecting the screen resolution is a simple task with (1) and (2). SystemParametersInfo for (1) and wine's own XRandR for (2) can be used.
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
The question is, should I worry about supporting such a scenario?
wine works really well with windows-only embedded compilers. With wine as it is, you can just shove them in a Makefile like any other tool. Magic!
This is an very useful use-case, and definitely important to preserve console support in X-less environments for this.
On Sunday, 19 May 2013 1:55 AM, Joel Holdsworth wrote:
On 16/05/13 13:04, Hugh McMaster wrote: 3. wineconsole with --backend=curses, but no X server running
My concern is with scenario (3). Wine is designed to be used with an X server, but wineconsole can be used in non-X-based environment. While this is possible, it would seem unlikely. Nonetheless, the issue has come up on the wine-devel list before.
The question is, should I worry about supporting such a scenario?
wine works really well with windows-only embedded compilers. With wine as it is, you can just shove them in a Makefile like any other tool. Magic!
This is an very useful use-case, and definitely important to preserve console support in X-less environments for this.
Thank you for your response. As you may have seen, there's been quite a lot of support for using wineconsole in an X-less environment.
So don't worry, nothing will change. In fact, I've come up with a way to keep this functionality amongst a lot of other changes to wineconsole in an GUI-based environment.
-
Hugh McMaster -
Joel Holdsworth -
Michael Stefaniuc -
Rosanne DiMesio -
Vincent Hardy