Am 20.06.2013 17:55, schrieb Bruno Jesus:
On Thu, Jun 20, 2013 at 12:42 PM, Fabian Ebner wrote:
Allow winetest to output stuff inside a wineconsole.
Fixes http://bugs.winehq.org/show_bug.cgi?id=28191
---
programs/winetest/gui.c | 6 +++---
programs/winetest/main.c | 2
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 winecons
-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.
>
> 1. wineconsole with --backend=user (or more simply, 'wine
Le 16/05/2013 15:03, Rosanne DiMesio a écrit :
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
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
>>> se
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
>&
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
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. w
>>The first and second patches should be applied to source before compiling
>>Wine. If this is not done, the compiler will exit with errors. (The first is
>>a patch for server/protocol.def and requires tools/make_requests to be run).
>After each patch, Wine should be able to compile correctly (e
is achieved by moving logical calculations to wineconsole itself.
> kernel32.dll only receives the final values.
>
> The first and second patches should be applied to source before compiling
> Wine. If this is not done, the compiler will exit with errors. (The first
> is a pat
Eric Pouech wrote:
>to exchange information
>between wineconsole and kernel is not the right thing to do the correct way is
>to:
>- enhance the wine server protocol to grab max win size in kernel32
>from wine server
I've been
;and on top of that, using registry as a way to exchange information
>between wineconsole and kernel is not the right thing to do the correct way is
>to:
>- enhance the wine server protocol to grab max win size in kernel32
>from wine server
>- enhance wineconsole to set the max
From: Nikolay Sivov
Sent: Tuesday, 9 April 2013 12:03 AM
To: Hugh McMaster; wine-devel
Subject: Re: [3/13] wineconsole and kernel32: set GetLargestConsoleWindowSize
based on screen resolution
>If you need to access registry from kernel32 you'll need to use ntdll calls
>directly.
>
>Please don't send 13 patches with the same name.
>Also, for long patch series, you should describe the whole purpose of the
>series in the first patch [1/N] (or even better in a [0/N] patch)
>Finally,even if "one change per patch" is the rule, don't overdo it...
Frédéric
Fair enough. Thank you
;and on top of that, using registry as a way to exchange information between
>wineconsole and kernel is not the right thing to do
>the correct way is to:
>- enhance the wine server protocol to grab max win size in kernel32 from wine
>server
>- enhance wineconsole to set the max wine
On Mon, Apr 8, 2013 at 2:53 PM, Hugh McMaster <
hugh.mcmas...@masterindexing.com> wrote:
> This patch creates winecon_private.h in 'include/wineconsole'. The header
> is now a shared header. Note that the source code is the same as that in
> programs/wineconsole/wineco
To: wine-devel; Hugh McMaster
Subject: Re: [3/13] wineconsole and kernel32: set
GetLargestConsoleWindowSize based on screen resolution
>On Mon, Apr 8, 2013 at 3:53 PM, Hugh McMaster
mailto:hugh.mcmas...@masterindexing.com>> wrote:
>This file recreates most, if not
On Mon, Apr 8, 2013 at 4:47 PM, Hugh McMaster <
hugh.mcmas...@masterindexing.com> wrote:
> From: Nikolay Sivov [mailto:bungleh...@gmail.com]
> Sent: Monday, 8 April 2013 11:08 PM
> To: wine-devel; Hugh McMaster
> Subject: Re: [3/13] wineconsole and kernel32: set
> GetLar
From: Nikolay Sivov [mailto:bungleh...@gmail.com]
Sent: Monday, 8 April 2013 11:08 PM
To: wine-devel; Hugh McMaster
Subject: Re: [3/13] wineconsole and kernel32: set GetLargestConsoleWindowSize
based on screen resolution
>On Mon, Apr 8, 2013 at 3:53 PM, Hugh McMaster
> wrote:
>
From: Nikolay Sivov [mailto:bungleh...@gmail.com]
Sent: Monday, 8 April 2013 11:08 PM
To: wine-devel; Hugh McMaster
Subject: Re: [3/13] wineconsole and kernel32: set GetLargestConsoleWindowSize
based on screen resolution
>On Mon, Apr 8, 2013 at 3:53 PM, Hugh McMaster
> wrote:
>
On Mon, Apr 8, 2013 at 3:53 PM, Hugh McMaster <
hugh.mcmas...@masterindexing.com> wrote:
> This file recreates most, if not all, of the source found in
> dlls/advapi32/registry.c in dlls/kernel32. It provides registry
> functionality.
>
> Tested on Linux Mint 14 and Mac OS X 10.8 (Mountain Lion).
ple test of gcc for recent Wine git,
it is certainly looking good for the next Wine release as well!
Grant also told me that gcc had no obvious issues for wine-1.5.20 when
invoked directly with wine. Instead he had to follow my wineconsole +
bash method for invoking gcc to confirm the issue for wi
On 2012-12-28 13:45+0100 Frédéric Delanoy wrote:
Other users have issues with wine but they don't generally complain as
loudly as you did.
It is possible I was not cautious enough with my tone, but let's leave
it like this. Wine-1.5.20 has introduced an obvious regression for an
important Wind
> On Dec 23, 2012 7:22 PM, "Alan W. Irwin"
>>>> wrote:
>>>>>
>>>>> The subject line pretty much says it all. Running MinGW/gcc under
>>>>> wineconsole for any simple test programme should demonstrate the issue
>>>>> for win
On 2012-12-28 10:44+0100 Frédéric Delanoy wrote:
On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin
wrote:
On 2012-12-23 21:25-0600 Austin English wrote:
On Dec 23, 2012 7:22 PM, "Alan W. Irwin"
wrote:
The subject line pretty much says it all. Running MinGW/gcc under
wineconso
On Mon, Dec 24, 2012 at 8:58 AM, Alan W. Irwin
wrote:
> On 2012-12-23 21:25-0600 Austin English wrote:
>
>> On Dec 23, 2012 7:22 PM, "Alan W. Irwin"
>> wrote:
>>>
>>> The subject line pretty much says it all. Running MinGW/gcc under
>&g
On 2012-12-23 21:25-0600 Austin English wrote:
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" wrote:
The subject line pretty much says it all. Running MinGW/gcc under
wineconsole for any simple test programme should demonstrate the issue
for wine-1.5.20 which is not present in wine-1.
On Dec 23, 2012 7:22 PM, "Alan W. Irwin" wrote:
>
> The subject line pretty much says it all. Running MinGW/gcc under
> wineconsole for any simple test programme should demonstrate the issue
> for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
> sel
The subject line pretty much says it all. Running MinGW/gcc under
wineconsole for any simple test programme should demonstrate the issue
for wine-1.5.20 which is not present in wine-1.5.19 and a fairly large
selection of 1.5.x and MinGW versions I have tried over the last year
or so.
I would be
hmm, that was intended to work (and did work for try#1, even though I
didn't retest it in #2) :-(
I'll look at it
A+
2012/12/19 Alexandre Julliard
> Eric Pouech writes:
>
> >> Try #2 (changes from previous patch)
> >
> > > - fix changelog of first patch (wastWineHelp...)
> > > - fix dat
Eric Pouech writes:
>> Try #2 (changes from previous patch)
>
> > - fix changelog of first patch (was WineHelp...)
> > - fix date in header for new file
> > - remove setting title code (will be fixed in later patch)
>
>
> Actually the problem is not only the title. For i
> Try #2 (changes from previous patch)
> > - fix changelog of first patch (was WineHelp...)
> > - fix date in header for new file
> > - remove setting title code (will be fixed in later patch)
>
> Actually the problem is not only the title. For instance it's still
> sending escape sequences when s
Eric Pouech writes:
> The following series implements a new scheme for managing 'bare' consoles.
> We now force every program started without a wine parent to be run under
> wineconsole (transparently for the user).
> This is done using a new backend in wineconsole calle
Eric Pouech writes:
> +/**
> + * WCLINE_SetTitle
> + *
> + * Sets the title to the wine console
> + */
> +static void WCLINE_SetTitle(const struct inner_data* data)
> +{
> +WCHAR wbuf[256];
> +
> +if (WINECON_Get
On Mon, Dec 3, 2012 at 10:12 PM, Eric Pouech wrote:
> diff --git a/programs/wineconsole/line.c b/programs/wineconsole/line.c
> new file mode 100644
> index 000..4b7fd29
> --- /dev/null
> +++ b/programs/wineconsole/line.c
> @@ -0,0 +1,334 @@
> +/*
> + * a GUI appl
Le 15/12/2011 17:18, Akihiro Sagawa a écrit :
On Wed, 14 Dec 2011 19:35:34 +0100, Eric Pouech wrote:
this doesn't solve the printing issue as the always infer that any char has
the same size
how is this printed on real windows with your character set ?
See the attachment, please. It was taken i
On Wed, 14 Dec 2011 19:35:34 +0100, Eric Pouech wrote:
> this doesn't solve the printing issue as the always infer that any char has
> the same size
> how is this printed on real windows with your character set ?
See the attachment, please. It was taken in my Windows 7 PC with
Japanese Terminal fo
, but
> commit 570e68b82200bdd9981b2cd8fe9e68d35bad3cb9 updated the requirement,
> 2.1.4 or later. And it is not useful for DBCS fonts, as they have two
> different width (halfwidth and fullwidth) even in monospaced font such
> as MS Gothic.
> ---
> programs/wineconsole/user.c | 34 ++--
Am 06.09.2011 18:02, schrieb Alexandre Julliard:
> André Hentschel writes:
>
>> @@ -44,7 +44,7 @@ IDR_BROWSE_CONTEXT_MENU MENU
>> MENUITEM "Set as &Desktop Item", IDM_SETDESKTOPITEM
>> MENUITEM SEPARATOR
>> MENUITEM "Select &All",IDM_SELECTALL
>> -
André Hentschel writes:
> @@ -44,7 +44,7 @@ IDR_BROWSE_CONTEXT_MENU MENU
> MENUITEM "Set as &Desktop Item", IDM_SETDESKTOPITEM
> MENUITEM SEPARATOR
> MENUITEM "Select &All",IDM_SELECTALL
> -MENUITEM "&Paste", IDM_PASTE
> +ME
Le 11/12/2010 00:04, Alan W. Irwin a écrit :
The command
wineconsole --backend=curses cmd
hangs with the following error message for 1.3.8:
err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec "?" wait timed
out in thread 0065, blocked by , retryi
On 2010-12-10 15:14-0800 Juan Lang wrote:
Hi Alan,
you should open a bug for this rather than ask here. (Also, I just
tried on Ubuntu 10.04 with Wine 1.3.9 here, and I can't confirm.)
Thanks, Juan, for your reply which inspired me to build wine-1.3.9, and
indeed the issue has been fixed for t
On 2010-12-10 15:04-0800 Alan W. Irwin wrote:
I should have added that the configure step for my wine-1.3.8 build
used no options other than --prefix. That means I built the
32-bit version of wine-1.3.8 on my 64-bit (amd64) Intel box as confirmed
by
softw...@raven> file ~/wine/install/bin/wine
Hi Alan,
you should open a bug for this rather than ask here. (Also, I just
tried on Ubuntu 10.04 with Wine 1.3.9 here, and I can't confirm.)
--Juan
The command
wineconsole --backend=curses cmd
hangs with the following error message for 1.3.8:
err:ntdll:RtlpWaitForCriticalSection section 0x7ee17dec "?" wait timed
out in thread 0065, blocked by , retryi
Eric Pouech writes:
> +if (tcgetattr(fd, &term) < 0) fprintf(stderr, "Couldn't get
> termios\n");
> +console_input->termios = term;
> +term.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN);
> +term.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON);
Errors need to
I thought this patch was pretty straightforward, comments?
http://www.winehq.org/pipermail/wine-patches/2009-October/080779.html
Erich Hoover
ehoo...@mines.edu
Dmitry Timoshkov wrote:
> "James McKenzie" <[EMAIL PROTECTED]> wrote:
>
>> Martin Storsjö wrote:
>>>
>>> poll can't handle terminal devices on Darwin, since Tiger. See the
>>> following discussion:
>>> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html
>>>
>> This will have to be set
can be
passed to it. (e.g. when you're using it in a program
that does not open many file descriptors, or when
you're using it with no file descriptors, as a nice sleep).
I think wineconsole is an example of an app that does
not open many file descriptors, so select is fine there.
- Dan
Hi,
In addition to the select vs poll patch to wineconsole, I sent two other
unrelated minor patches for wineconsole last Friday (attached here); are
there any obvious problems with these, prohibiting them from getting
merged?
The first one simply makes fallbacks from the curses to the user
On Thu, 4 Dec 2008, Damjan Jovanovic wrote:
On Mon, Dec 1, 2008 at 11:57 AM, Martin Storsjö <[EMAIL PROTECTED]> wrote:
But there may of course be other reasons for using poll, which I don't know
about.
select() not only has a hard limit on the number of file descriptors
(1024 or whatever) th
elect
> (directly) before, it used WaitForMultipleObjects, which was changed into a
> poll in 267d38e1bc78541221d20cc72a759acc78908e8e, "wineconsole: Don't use a
> Win32 wait on a Unix file descriptor."
>
> But there may of course be other reasons for using poll, wh
"James McKenzie" <[EMAIL PROTECTED]> wrote:
> Martin Storsjö wrote:
>>
>> poll can't handle terminal devices on Darwin, since Tiger. See the
>> following discussion:
>> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html
>>
> This will have to be setup so that it only works for Macs.
Martin Storsjö wrote:
>
> poll can't handle terminal devices on Darwin, since Tiger. See the
> following discussion:
> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html
>
This will have to be setup so that it only works for Macs. Maybe this
can be a static patch in the Darwine code
select to poll. You can't just switch back to
As far as I can tell from the history of curses.c, it never used select
(directly) before, it used WaitForMultipleObjects, which was changed into
a poll in 267d38e1bc78541221d20cc72a759acc78908e8e, "wineconsole: Don't
use a
On Sunday 30 November 2008 00:52:57 Martin Storsjö wrote:
> poll can't handle terminal devices on Darwin, since Tiger. See the
> following discussion:
> http://lists.apple.com/archives/Darwin-dev/2006/Apr/msg00066.html
There's reasons we switched from select to poll. You can't just switch back to
ible?
> Ideally - should. But...
> 1) There isn't any 'select.h' substring in whole wine tree.
> 2) There is a file libs/port/usleep.c which uses select() but it does not
> include any meaningful headers except "config.h" and "wine/port.h". Are these
&g
select.h' substring in whole wine tree.
2) There is a file libs/port/usleep.c which uses select() but it does not
include any meaningful headers except "config.h" and "wine/port.h". Are these
two headers enough wineconsole - I have no idea. Alexandre knows better ;-)
Try an
Hi Kirill,
On Sat, 29 Nov 2008, Kirill K. Smirnov wrote:
>> +ret = select(pipefd + 1, &readfds, &writefds, &errorfds, NULL);
> Passing NULL instead of &writefds in this case is better, IMO. It is not used
> anyway.
Ok
> I strongly believe that errorfds parameter os select() is useful fo
Hi, Martin,
>+ret = select(pipefd + 1, &readfds, &writefds, &errorfds, NULL);
Passing NULL instead of &writefds in this case is better, IMO. It is not used
anyway.
...and...
I strongly believe that errorfds parameter os select() is useful for sockets
only, not for stdio (I am not sure
Dan Kegel a écrit :
> One more of the 100 valgrind warnings; this one is
> in kernel32/tests/console.c (but really in wineconsole).
> It's code Eric wrote six years ago, and the fix might be
> as straightforward as using memcpy(&ir, 0, sizeof(ir)) in
> WCUSER_GenerateMouseI
One more of the 100 valgrind warnings; this one is
in kernel32/tests/console.c (but really in wineconsole).
It's code Eric wrote six years ago, and the fix might be
as straightforward as using memcpy(&ir, 0, sizeof(ir)) in
WCUSER_GenerateMouseInputRecord().
Is there a better fix?
S
a6 is on thread 1's stack
Uninitialised value was created by a stack allocation
at WCUSER_GenerateKeyInputRecord (user.c:1019)
That user.c is in programs/wineconsole.
This might just be a matter of INPUT_RECORD being holey,
I haven't checked.
Hi, Alexandre,
> >
> > Is there something wrong with my patch? Did I miss something important?
>
> I'm not at all convinced that the conversion has to happen at that
> point. Do you have a test app that demonstrates this?
I've written test application, which writes control chars and performs
re
[programs/wineconsole: Correctly display chars 00..1F and 7F]
Thanks in advance,
--
Kirill
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
struct dialog_info* di;
unsigned idc;
+unsigned nMaxHistUD = 500;
switch (msg)
{
@@ -66,6 +67,8 @@ static INT_PTR WINAPI WCUSER_OptionDlgPr
di = (struct dialog_info*)((PROPSHEETPAGEA*)lParam)->lParam;
di->hDlg = hDlg;
SetWindowL
the test could force the user backend (see the console test in
kernel32 directory)
I see - I haven't noticed that --use-event automatically chooses the
user backend.
Mikolaj Zalewski
is not implemented in Wine yet. Also, it's not
clear whether it's the top level window or the child window. You could
send the mouse events to that window. But that's not a top priority
feature. It's better to fix the broken parts of wineconsole ;-)
Also it would fail o
but your code doesn't release the selection on button up, which is
rather strange when you do only mouse selection
A+
I've checked it and currently the whole section is dead code as on
WM_LBUTTONUP the (wParam&MK_LBUTTON) is always false.
However if I remove this condition I think my code
Mikołaj Zalewski wrote:
case WM_LBUTTONUP:
-if (data->curcfg.quick_edit)
+if (data->curcfg.quick_edit || PRIVATE(data)->has_selection)
{
if (GetCapture() == PRIVATE(data)->hWnd &&
PRIVATE(data)->has_selection &&
(wParam& MK_LBUTTON))
Mikołaj Zalewski wrote:
did you check that this behavior is done for every mode of the console ?
A+
What do you mean by every mode?
Mikolaj Zalewski
consoles have several modes (set SetConsoleMode()), which may interfer
with this behavior
and btw, a test case for windows behavior woul
did you check that this behavior is done for every mode of the console ?
A+
What do you mean by every mode?
Mikolaj Zalewski
as a principle, why do oppose keyboard selection to mouse selection
looks to me you could in principle do both... so any key except
return, arrow keys should end the selection
and you woun't need the extraneous mouse_selection
I wanted to make it in the same way as on Windows. But I think it
case WM_LBUTTONUP:
-if (data->curcfg.quick_edit)
+if (data->curcfg.quick_edit || PRIVATE(data)->has_selection)
{
if (GetCapture() == PRIVATE(data)->hWnd &&
PRIVATE(data)->has_selection &&
(wParam& MK_LBUTTON))
{
Mikołaj Zalewski wrote:
diff --git a/programs/wineconsole/user.c b/programs/wineconsole/user.c
index c4250e5..19a1625 100644
--- a/programs/wineconsole/user.c
+++ b/programs/wineconsole/user.c
@@ -705,6 +705,12 @@ static
Mikołaj Zalewski wrote:
The user may start the selection from the popup menu. The mouse should
work then
diff --git a/programs/wineconsole/user.c b/programs/wineconsole/user.c
index 557ccfc..c4250e5 100644
--- a
Mikołaj Zalewski wrote:
This is very practical and matches the Windows behaviour
diff --git a/programs/wineconsole/user.c b/programs/wineconsole/user.c
index e1efda2..557ccfc 100644
--- a/programs/wineconsole/user.c
Ekkehard Morgenstern <[EMAIL PROTECTED]> writes:
> Well, WCMD allows only 2 arguments, for instance. IMNSHO the code is
> effed-up beyond repair, and I would rather rewrite it than expand on
> it.
>
> But I won't bother writing a replacement if it's not desired by the
> WINE community.
wcmd certa
Alexandre Julliard wrote:
Try to create the console window, it should fail if X is not
available.
Well, I'll look into that when I find time.
Alexandre Julliard wrote:
The usual way is to fix one bug at a time... If you are suggesting a
complete rewrite you'll need to make a very convincing case that
throwing away the existing code is preferable to fixing it.
Well, WCMD allows only 2 arguments, for instance. IMNSHO the code is
e
Ekkehard Morgenstern <[EMAIL PROTECTED]> writes:
> How should I check if the X Display is available?
Try to create the console window, it should fail if X is not
available.
--
Alexandre Julliard
[EMAIL PROTECTED]
Alexandre Julliard wrote:
I don't think that's an improvement, please let's not add more obscure
environment variables. You should try to use the user backend when the
X display is available and fall back to curses otherwise.
How should I check if the X Display is available?
The DISPLAY e
Ekkehard Morgenstern <[EMAIL PROTECTED]> writes:
> I would also like to replace WCMD with a compatible, but much better
> version, sometime. How would I go about that? Can I provide a patch
> for a whole folder?
The usual way is to fix one bug at a time... If you are suggesting a
complete rewrite
Ekkehard Morgenstern <[EMAIL PROTECTED]> writes:
> This patch is akin to the previously posted; however, instead of making
> the user backend
> the default, I read an environment variable WINECONBACKEND to determine
> the default.
I don't think that's an improvement, please let's not add more o
You patch wrapped again. Please attach it to the e-mail instead.
Vitaliy.
Are you sure? It doesn't wrap in Mozilla Mail unless it crosses window
borders. I've checked it multiple times and tried out different window
sizes in the mail viewer. In the Mail config, I set the margin to 512
c
Wednesday, August 9, 2006, 2:33:17 AM, Ekkehard Morgenstern wrote:
> This patch is akin to the previously posted; however, instead of making
> the user backend
> the default, I read an environment variable WINECONBACKEND to determine
> the default.
> If the value isn't set, "curses" will be the d
Alexandre Julliard wrote:
Your mailer wrapped the patch, please resend it.
How? Do you think it will work as an attachment?
I'm using Mozilla Mail.
Also please send separate changes as separate patches,
OK
and try to follow the coding conventions of the surrounding code.
I will have
Kuba Ober wrote:
Popping up console windows is equal to not working for me. (...)
Also, I'd love it a lot if all the ncurses crap was avoided. The compilers
output plain text on the standard output (whatever that is on windows).
Why don't you just use "wcmd "?
As I
> > If anyone needs me to put money where my mouth is, I offer $100 via
> > PayPal if someone in charge wants financial coercion to avoid putting in
> > the X/graphical/ncurses crap for console applications. I'm dead serious.
>
> I'll see your bet, and raise you $150.
Wow, so you're saying that
> > I know that not too many people are using wine like that, but right now
> > it works fine and I'd kindly ask for it to keep working, rather than get
> > broken.
>
> Nobody is suggesting to change the behavior for apps that don't use
> wineconsole. The onl
On 8/8/06, Kuba Ober <[EMAIL PROTECTED]> wrote:
On Tuesday 08 August 2006 04:18, Alexandre Julliard wrote:
> Eric Pouech <[EMAIL PROTECTED]> writes:
> > also changing the default to user is a bad idea... especially for
> > users wanting to run a text only win32 app from a linux console
> > withou
t not too many people are using wine like that, but right now it
> works fine and I'd kindly ask for it to keep working, rather than get broken.
Nobody is suggesting to change the behavior for apps that don't use
wineconsole. The only suggested change is to default to X instead of
cur
"Dimi Paun" <[EMAIL PROTECTED]> writes:
> I used Wine for a while to run some command line tools (like some
> embedded assembler and linker). I certainly did not want a new console
> popup on each invocation. Not sure if this would be the case here,
> but it's certainly one of the most irritating
On Tuesday 08 August 2006 04:18, Alexandre Julliard wrote:
> Eric Pouech <[EMAIL PROTECTED]> writes:
> > also changing the default to user is a bad idea... especially for
> > users wanting to run a text only win32 app from a linux console
> > without X started
>
> I think that's a very small minori
On Tue, August 8, 2006 4:18 am, Alexandre Julliard wrote:
> I think that's a very small minority, what most people want is a real
> console in a separate window. We could certainly fall back to the
> curses backend when we aren't under X and can't create a user32
> window.
I used Wine for a while
Eric Pouech <[EMAIL PROTECTED]> writes:
> also changing the default to user is a bad idea... especially for
> users wanting to run a text only win32 app from a linux console
> without X started
I think that's a very small minority, what most people want is a real
console in a separate window. We
Alexandre Julliard wrote:
Ekkehard Morgenstern <[EMAIL PROTECTED]> writes:
This small patch provides command line option output, a "--help" option
and a default user backend ("--backend=user" is default) to "wineconsole".
Your mailer wrapped the
Ekkehard Morgenstern <[EMAIL PROTECTED]> writes:
> This small patch provides command line option output, a "--help" option
> and a default user backend ("--backend=user" is default) to "wineconsole".
Your mailer wrapped the patch, please resend it. Als
instruction to run wineconsole for my console executable. So I ran "wineconsole
my.exe" in wine-0.9.16 on Mac OSX 10.4.6 on Intel Core Duo. I received so many errors that they scrolled across the shell too fast ad infinitum. I Quit the X11 xterm and figured I'd try "wine my.
Am Mittwoch, den 31.05.2006, 16:28 +0900 schrieb Mike McCormack:
> index 169f4e1..73a0987 100644
> --- a/programs/wineconsole/dialog.c
> +++ b/programs/wineconsole/dialog.c
> +return GetWindowLongPtr(hWnd, 0);
> +HFONT hFont = (HFONT)GetWindowLongPtr(hWnd, 0L)
1 - 100 of 131 matches
Mail list logo
