Hi,
I've written a function to determine the largest possible screen buffer that
wineconsole is able to display. This function replaces the hard-coded constants
listed in both instances of GetLargestConsoleWindowSize in
dlls/kernel32/console.c.
[snip]
#include windows.h
#include winuser.h
March 2013 1:54 PM
To: Hugh McMaster
Cc: wine-devel@winehq.org
Subject: Re: Linker error when improving GetLargestConsoleWindowSize
On Mar 25, 2013, at 8:51 PM, Hugh McMaster wrote:
I've written a function to determine the largest possible screen buffer that
wineconsole is able to display
-Original Message-
From: Ken Thomases [mailto:k...@codeweavers.com]
Sent: Wednesday, 27 March 2013 11:25 PM
To: Hugh McMaster
Cc: Wine Developers
Subject: Re: [1/3] kernel32: Set GetLargestConsoleWindowSize based on screen
resolution
On Mar 27, 2013, at 6:41 AM, Hugh McMaster wrote
-Original Message-
From: Eric Pouech [mailto:eric.pou...@orange.fr]
Sent: Wednesday, 27 March 2013 8:54 AM
To: wine-devel@winehq.org
Subject: Re: Linker error when improving GetLargestConsoleWindowSize
Ken Thomases wrote:
This won't be able to work. The linker error is telling you,
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
hugh.mcmas
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
hugh.mcmas
Eric Pouech wrote:
Le 08/04/2013 16:03, Nikolay Sivov a écrit :
If you need to access registry from kernel32 you'll need to use ntdll calls
directly.
This functionality belongs to advapi32. Do you really need anything more than
ntdll calls provide?
and on top of that, using registry as a way
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 for
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.
Do you really
Eric Pouech wrote:
Le 08/04/2013 16:03, Nikolay Sivov a écrit :
If you need to access registry from kernel32 you'll need to use ntdll calls
directly.
This functionality belongs to advapi32. Do you really need anything more than
ntdll calls provide?
and on top of that, using registry as a way
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 able to achieve this.
I've been adding a new handler to Wine's server. Unfortunately, I've run into
a problem with C_ASSERT that I can't seem to resolve.
In server/request.h, I've added the following code:
C_ASSERT( FIELD_OFFSET(struct get_desktop_workarea_request, spi_workarea) == 16
);
C_ASSERT( sizeof(struct
Am 13.04.2013 15:39, schrieb Hugh McMaster:
I've been adding a new handler to Wine's server. Unfortunately, I've run
into a problem with C_ASSERT that I can't seem to resolve.
In server/request.h, I've added the following code:
C_ASSERT( FIELD_OFFSET(struct get_desktop_workarea_request
On Apr 13, 2013, at 7:39 AM, Hugh McMaster wrote:
I've been adding a new handler to Wine's server. Unfortunately, I've run
into a problem with C_ASSERT that I can't seem to resolve.
In server/request.h, I've added the following code:
STOP! You should modify server/protocol.def instead
On Apr 13, 2013, Charles Davis wrote:
STOP! You should modify server/protocol.def instead. The file you changed is
automatically generated from protocol.def, along with a bunch of other files
needed to make the server interface magic work.
On Apr 13, 2013, at 7:39 AM, Hugh McMaster wrote
On Apr 14, 7:20 PM, Hugh McMaster wrote:
Is there something special/different that needs to be done for the server to
accept input?
I can answer this myself now.
SERVER_START_REQ
{
req-spi_workarea.right = workarea.right;
req-spi_workarea.bottom = workarea.bottom;
wine_server_call
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.g.
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
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
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
order.
Anyway, I can resubmit without the formatting and white space changes, if you
think it necessary.
Hugh
-Original Message-
From: Dmitry Timoshkov [mailto:dvtimosh...@gmail.com] On Behalf Of Dmitry
Timoshkov
Sent: Tuesday, 21 May 2013 12:42 PM
To: Hugh McMaster
Cc: wine-devel
On Monday May 20 at 22:24:58, Alan W. Irwin wrote:
wine at raven wine64
wine64: error while loading shared libraries: libwine.so.1: cannot
open shared object file: No such file or directory
Hi Alan,
This error is caused by a regression in Wine 1.5.30. It is not present in
version 1.5.29.
The
On Thursday, 6 June 2013 6:22 AM, Jason Edmeades wrote:
I do not think this patch is enough - From memory (I once tried something
similar) the problem with resolving it the way you have is you then lose
the ability of breaking out of a batch program. I think the right solution
needs an actual
Hi everyone,
Wine patches currently have a status described in
http://source.winehq.org/patches, yet for patches with the status of 'New', the
status becomes confusing.
The legend describes 'New' status as Patch not even looked at yet, there's
still hope This is ideal for new patches
On Tuesday, 30 July 2013 9:04 PM, Ken Sharp wrote:
There's also Pending.
Hi Ken,
Yes, I know about the 'Pending' status. The patches page describes this status
in two ways:
1. The patch is not obviously correct at first glance. Making a more convincing
argument, preferably in the form of a
Hi Vincent,
You raise some very good points.
On Wednesday, 31 July 2013 2:53 AM, Vincent Povirk wrote:
I think I've seen patches stay in the New state in the following cases:
* He's convinced you do not have the ability to write a patch he would
accept. (There's a common pattern where people
* The patch is difficult to review, and he's putting it off.
There are some statuses (e.g. 'needs splitting) to counteract this. But
patches are/can be difficult to review. Again, a status such as 'Not yet
reviewed' would help.
* He's travelling and does not have access to a machine
---
programs/reg/reg.c | 232 +---
1 file changed, 221 insertions(+), 11 deletions(-)
From f1fc5e53eef89380b4ce10e231eced591b21882a Mon Sep 17 00:00:00 2001
From: Hugh McMaster hugh.mcmas...@masterindexing.com
Date: Thu, 1 Aug 2013 23:34:33 +1000
Subject: reg
On Thursday, 1 August 2013 11:43 PM, Bruno Jesus wrote:
The patch was sent to wine-devel.
Yes, you're right. Apologies for that. I've now submitted the patch to
wine-patches.
On Thursday, 1 August 2013 11:55 PM, Nikolay Sivov wrote:
+p = strchrW(key_name,'\\');
+if (!p)
+{
+p = 0;
+}
+else p++;
I'm not sure what this is supposed to do.
It is equivalent to the following code;
p = strchrW(key_name, '\\');
if (p != NULL) p++;
On Friday, 2 August 2013 6:58 PM, Nikolay Sivov wrote:
There's no need for separate variable here nor for incrementing pointer.
The incrementing pointer is needed because the 'value' is a Byte array. But
the separate variable is not needed.
Yes, so value[i] will do the same.
Yes, you're
On Monday, 12 August 2013, Ruslan Kabatsayev wrote:
I've tried applying your both patches, and it appears that Ctrl+C at
cmd prompt still closes cmd, although pressing it while dir /s /w is running
works as expected.
Hi Ruslan,
I've just tested the Ctrl-C patches on the most recent version of
On Monday, 12 August 2013 at 10:57 PM, Ruslan Kabatsayev wrote:
You're right, I had to run cmd via wineconsole, and I tried it before with
plain wine. OK, this way your patches do indeed work. Thanks.
No problems, Ruslan. I'm not sure Ctrl-C can be intercepted when running 'wine
cmd.exe' but
On Thursday, 1 August 2013 12:19 AM, Vincent Povirk wrote:
The problem is there are situations where patches are never reviewed and no
one is told why.
After some thought, it occurred to me that the said patches are being reviewed;
they just never have their status altered.
So, one possible
On Monday, 26 August 2013 5:20 AM, Maarten Lankhorst wrote:
Op 25-08-13 14:09, Susan Cragin schreef:
Was thinking of running some tests but the list of dependencies on the
website seems outdated, apt-get build-dep does not work.
Is that with the ubuntu-wine ppa enabled?
The Wine PPA isn't
I'm testing support for GetConsoleScreenBufferInfoEx.
At the moment, I've extended the screen_buffer struct in server/console.c to
look like this:
struct screen_buffer
{
struct object obj; /* object header */
struct list entry; /* entry in list of all
Any help for this?
--
I'm testing support for GetConsoleScreenBufferInfoEx.
At the moment, I've extended the screen_buffer struct in server/console.c to
look like this:
struct screen_buffer
{
struct object obj;
I need to increase the $max_req_size in tools/make_requests. A new request
structure for GetConsoleScreenBufferInfoEx is 80 bytes and primarily made up of
16 unsigned long integers. This is fine, but raises the error:
wineserver: request.c:755: open_master_socket: Assertion `sizeof(union
Solved. server/protocol.def is the correct place to adjust the request_max_size
value.
Hi everyone,
I just wanted to know if anyone would mind helping/mentoring me with a few
small patches.
I am working primarily on wineconsole's screen buffer problems (to which I
believe I have the solution), but am also looking at implementing some stub
Win32 console functions found in
Can anyone help me on this? I do realize that wineconsole is only a minor focus
of development.
Hugh
-
Hi everyone,
I just wanted to know if anyone would mind helping/mentoring me with a few
small patches.
I am working primarily on
On Monday, 14 October 2013 9:50 PM, Ricardo Filipe wrote:
I'd be more than happy to help you review your patches, although I am no
wineconsole expert, I believe I could help you get your changes into wine.
Contact me if no better offer comes around :) cheers
Hello Ricardo,
Thank you for your
42 matches
Mail list logo
