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 you
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 wineconsole'
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 dlls/ke
Solved. server/protocol.def is the correct place to adjust the request_max_size
value.
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
gen
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'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
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'
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 w
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 i
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
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'
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 != N
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.
t;
wine reg.exe query "HKCU\Software" /s
---
programs/reg/reg.c | 232 +---
1 file changed, 221 insertions(+), 11 deletions(-)
From f1fc5e53eef89380b4ce10e231eced591b21882a Mon Sep 17 00:00:00 2001
From: Hugh McMaster
Date: Thu, 1 Aug 201
>>> * 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 t
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 pe
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
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 sub
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 actua
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.
Th
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 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
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
>&
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
>>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
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 = wor
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
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 shou
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 cod
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 get
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.
/***
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
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
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
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:
>
-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, effe
-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
]
Sent: Tuesday, 26 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
>
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
#include
[snip]
COORD GetLarg
42 matches
Mail list logo
