2013/9/4 Zhenbo Li :
> This patch could fix bug 34431, which is caused by missing atl90.dll
>
> ---
> configure | 1 +
> configure.ac | 1 +
> dlls/atl90/Makefile.in | 7
> dlls/atl90/atl90.c | 93
> ++
> dlls/atl90
Sorry, I've made a typo.
This patch is for bug 34432
2013/9/4 Zhenbo Li
> This patch could fix bug 34431, which is caused by missing atl90.dll
>
> ---
> configure | 1 +
> configure.ac | 1 +
> dlls/atl90/Makefile.in | 7
> dlls/atl90/atl90.c | 93 +++
On 09/03/13 13:51, Qian Hong wrote:
> On Tue, Sep 3, 2013 at 7:42 PM, Jacek Caban wrote:
>> Not really, good catch. We should make them consistent. Honestly, I'm
>> not sure which one is better. Both have their problems. Some functions
>> are forwarded, others are not, so having one debug channel
On Tue, Sep 3, 2013 at 7:42 PM, Jacek Caban wrote:
> Not really, good catch. We should make them consistent. Honestly, I'm
> not sure which one is better. Both have their problems. Some functions
> are forwarded, others are not, so having one debug channel would be
> guarantee that we don't miss s
On 09/03/13 13:28, Qian Hong wrote:
> On Tue, Sep 3, 2013 at 7:27 PM, Qian Hong wrote:
>> Hi Jacek, we already have a debug channel atl100 for atl100.dll, but
>> we currently use atl for both atl.dll and atl80.dll, do you think it
>> is better to use atl for all, or one debug channel per each dll?
On Tue, Sep 3, 2013 at 7:27 PM, Qian Hong wrote:
> Hi Jacek, we already have a debug channel atl100 for atl100.dll, but
> we currently use atl for both atl.dll and atl80.dll, do you think it
> is better to use atl for all, or one debug channel per each dll?
Oh, I just found dlls/atl100/atl_ax.c
> +WINE_DEFAULT_DEBUG_CHANNEL(atl);
Hi Jacek, we already have a debug channel atl100 for atl100.dll, but
we currently use atl for both atl.dll and atl80.dll, do you think it
is better to use atl for all, or one debug channel per each dll?
Damian wrote:
> 1) ATI or nVidia for new GPU? Does SLI/Crossfire work with wine?
Don't know. I just use nvidia cards I find in the trash :-) But then
I don't actually play games, so I don't care about 3d performance.
> 2) FX 8320 or intel same price class CPU? As the
Hi guys,
As you have a track of open bugs:
1) ATI or nVidia for new GPU? Does SLI/Crossfire work with wine?
2) FX 8320 or intel same price class CPU? As the AMD has far inferior
single thread performance but far superior multi thread performance -
does wine run a win32 single thread app as multi
Hello,
I attached adjusted patch (including man-page entry).
Regards,
Kai
From ebb6cb67764e3a383edddb4b78e40dc8140736ba Mon Sep 17 00:00:00 2001
From: Kai Tietz
Date: Thu, 8 Aug 2013 12:29:33 +0200
Subject: [PATCH 01/12] widl: New option --rt for enabling rt's specific
language exten
Kai Tietz writes:
> Due line wrap, I sent patch as attachment.
>
> Kai
>
> From 3fcedb770626535b56a789467951a4c9be5f08dc Mon Sep 17 00:00:00 2001
> From: Kai Tietz
> Date: Thu, 8 Aug 2013 12:29:33 +0200
> Subject: [PATCH 01/11] widl: New option --rt for enabling r
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 08/08/13 19:56, Kai Tietz wrote:
> 2013/8/8 André Hentschel :
>> Am 08.08.2013 17:51, schrieb Kai Tietz:
>>> Hi,
>>>
>>> this patch adds new --rt option to widl. By it you can control, if
>>> RT's IDL-language-extension(?s) getting active.
&g
2013/8/8 André Hentschel :
> Am 08.08.2013 17:51, schrieb Kai Tietz:
>> Hi,
>>
>> this patch adds new --rt option to widl. By it you can control, if
>> RT's IDL-language-extension(?s) getting active.
>> This initial patch just adds the option-scanning a
Am 08.08.2013 17:51, schrieb Kai Tietz:
> Hi,
>
> this patch adds new --rt option to widl. By it you can control, if
> RT's IDL-language-extension(?s) getting active.
> This initial patch just adds the option-scanning and the global
> flag-variable to widl.
>
> O
lp.
>>
>>> * He's travelling and does not have access to a machine that can
>>>successfully run the Wine test suite, and he thinks the patch might break
>>>the tests.
>> A 'Not yet reviewed' status or similar would probably be best.
>But &qu
and does not have access to a machine that can
>> successfully run the Wine test suite, and he thinks the patch might break the
>>tests.
> A 'Not yet reviewed' status or similar would probably be best.
But "Not yet reviewed" is what "New" is supposed to be. The problem is
there are situations where patches are never reviewed and no one is
told why.
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. (T
accepted as is.
Anyway, to come back to the point, leaving a patch as 'New' is problematic.
'Pending' is more informative, yet perhaps not descriptive enough to cover
patches that stay as 'New' over a 24-hour patch cycle.
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 will take
feedback and attempt to revise their patch to account for it, but
There's also "Pending".
On 30/07/13 04:16, Hugh McMaster wrote:
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 '
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...&q
modules as well as Samba and
NFS file servers that export the same directory for Windows clients,
or Wine applications that access the same files simultaneously.
These flags are only take affect for opens on mounts with new sharelock
option. They are translated to flock's flags:
!O_DE
So while the translators are busy updating Wine's translations, what
better time than a freeze for developers to fix Wine's conformance
tests, particularly on the new WineTestBot:
http://newtestbot.winehq.org
It does not have as many VMs as the old one but it does have some
i
ms CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
> this change can benefit cifs and nfs modules as well as Samba and
> NFS file servers that export the same directory for Windows clients,
> or Wine applications that access the same files simultaneously.
>
> These flags are only ta
On 06/04/13 21:56, Alexandre Julliard wrote:
Piotr Caban writes:
@@ -890,6 +890,7 @@ struct rawinput_device
obj_handle_t handle; /* duplicated handle in dst process */
int self; /* is the source the current process? */
int closed; /* whet
Piotr Caban writes:
> @@ -890,6 +890,7 @@ struct rawinput_device
> obj_handle_t handle; /* duplicated handle in dst process */
> int self; /* is the source the current process? */
> int closed; /* whether the source handle has been closed
> */
code, until the cause can be fully
> investigated and a new patch issued if necessary
Please fix the code instead of removing it.
--
Alexandre Julliard
julli...@winehq.org
first one: Tools - Implement new control panel
> applets, but am wondering what I would actually be able to do.
> I've done basic opengl applications before but using a library like SDL to do
> the lowerlevel stuff.
>
> What kind of opengl test would be preferred?
I can'
Hey Everyone,
I've been wanting to get into Google Summer of Code and Wine development
for quite a while now.
I was looking on the wine ideas page : http://wiki.winehq.org/SummerOfCode
I'm interested in doing the first one: Tools - Implement new control panel
applets, but am wonder
t;I'm Kaiyi Zhang,A Computer Science and Engineering student from
> Civil Aviation University
> > of China.I hear the GSOC and I'm very Interested in this,I look through
> many projects until i see
> >
> > the "Tools - Implement new control panel applet
Am 29.04.2013 05:34, schrieb Kaiyi Zhang:
>I'm Kaiyi Zhang,A Computer Science and Engineering student from Civil
> Aviation University
> of China.I hear the GSOC and I'm very Interested in this,I look through many
> projects until i see
>
> the "To
I'm Kaiyi Zhang,A Computer Science and Engineering student from
Civil Aviation University
of China.I hear the GSOC and I'm very Interested in this,I look through
many projects until i see
the "Tools - Implement new control panel applets".
I have used wine for a
modules as well as Samba and
NFS file servers that export the same directory for Windows clients,
or Wine applications that access the same files simultaneously.
These flags are only take affect for opens on mounts with new sharelock
option. They are translated to flock's flags:
!O_DE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please ignore this patch. I figured that my series might collide with
Henri's, so I canceled the send process. And indeed there are
conflicts, so I'll resend my patches rebased on top of Henri's.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GN
conflicts with another open with O_DENY* flags, the -EBUSY error
> >> code is returned.
> >>
> >> Create codepath is slightly changed to prevent data races on
> >> newely created files: when open with O_CREAT can return with -EBUSY
> >> error for success
t be locked
> due conflicts with another open with O_DENY* flags, the -EBUSY error
> code is returned.
>
> Create codepath is slightly changed to prevent data races on
> newely created files: when open with O_CREAT can return with -EBUSY
> error for successfully created files due to a d
; newely created files: when open with O_CREAT can return with -EBUSY
>> error for successfully created files due to a deny lock set by
>> another task.
>>
>
> It's good that this is consistent with the new patchset. I'm still not
> 100% sure that -EBUSY is
This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename,
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules as well a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-09 13:01, schrieb Stefan Dösinger:
> I'm also running some of those tests
That sentence got cut off: I'm also running some of those tests on a
nightly basis to monitor Wine's performance.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-05 10:54, schrieb Gediminas Jakutis:
> This was discussed on the IRC a bit. The idea is to write
> [performance?] tests that are to be used for dxdiag. (I suppose
> that includes that funny spinning dx logo cube test found on the
> native d
This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename,
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules as well a
On Fri, Apr 5, 2013 at 10:08 AM, Stefan Dösinger
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-04-04 22:52, schrieb Gediminas Jakutis:
> There is some merit to the proposal, but it needs a lot more detail.
> We already have a lot of d3d tests (see
> dlls/{ddraw,d3d8,d3d9,d3d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-04-04 22:52, schrieb Gediminas Jakutis:
> Hello!
>
> My previous application[1] turned out to be a total failure, hence
> making a completely different one. My proposal this time goes as
> follows: Write various D3D tests, mostly focusing on
Hello!
My previous application[1] turned out to be a total failure, hence
making a completely different one.
My proposal this time goes as follows:
Write various D3D tests, mostly focusing on ones that can be later
re-used for dxdiag in one way or another. Along with writing a tool
that would allo
Am 01.04.2013 um 16:55 schrieb André Hentschel :
> Maybe you should continue with your work until wined3d supports webGL as
> backend ;)
No, nobody will need regular d3d once all games are written in webD3D.
Am 01.04.2013 14:22, schrieb Ken Thomases:
> On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote:
>
>> There are still some missing features. Most notably, it lacks support
>> for system tray baloons.
>
> I know; that's, like, the hardest thing to do!
>
> Great work, though! Actually, since HTML is a
On 04/01/2013 07:22 AM, Ken Thomases wrote:
> On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote:
>
>> There are still some missing features. Most notably, it lacks support
>> for system tray baloons.
>
> I know; that's, like, the hardest thing to do!
In other news, Alexandre has accepted a job at Mi
On Apr 1, 2013, at 6:41 AM, Jacek Caban wrote:
> There are still some missing features. Most notably, it lacks support
> for system tray baloons.
I know; that's, like, the hardest thing to do!
Great work, though! Actually, since HTML is available everywhere, there's
little reason for me to con
On Mar 27, 2013, at 3:31 PM, Ken Thomases wrote:
> dlls/winemac.drv/macdrv.h | 12 +++-
> dlls/winemac.drv/surface.c | 16 ++--
> dlls/winemac.drv/window.c | 17 ++---
> 3 files changed, 27 insertions(+), 18 deletions(-)
>
> <0001-winemac-Track-drawn-surface-r
This patch adds 4 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename,
4) O_DENYMAND that enables O_DENY* flags checks.
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this
While this may be a useful exercise (and I'd personally like to see
some demangler improvements, particularly support for managed
references), this sort of broad test doesn't make sense for the Wine
test suite, especially if we can't be sure it will always work on
Windows. It's the sort of thing yo
On 02/24/2013 04:18 AM, Nikolay Sivov wrote:
By the way, do you see something broken or it's just something you want
to work on?
Partly broken. If fed a bad string, it sometimes blows up and sometimes
returns an error code. The 'real' routine also blows up on some
strings. Which strings depe
On 2/24/2013 15:13, Eric Pouech wrote:
Le 24/02/2013 10:18, Nikolay Sivov a écrit :
On 2/24/2013 10:07, Max TenEyck Woodbury wrote:
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
On 2/24/2013 10:07, Max TenEyck Woodbury wrote:
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spec' files for mangled names, and
2) Tries to decode thos
Le 24/02/2013 07:07, Max TenEyck Woodbury a écrit :
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spec' files for mangled names, and
2) Tries to decode
On 02/23/2013 02:54 AM, Eric Pouech wrote:
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spec' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names
Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit :
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spac' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names and where they occur.
Success would be tha
Would it be appropriate to add a test to the name demangler that:
1) Scans all '.dll' and '.spac' files for mangled names, and
2) Tries to decode those names.
3) Prints the mangled and decoded names and where they occur.
Success would be that all names decode without the decoder blowing up
or
On Thu, 2013-02-21 at 18:47 +1100, Alistair Leslie-Hughes wrote:
> +#include "wine/debug.h"
> +
> +WINE_DEFAULT_DEBUG_CHANNEL(wincodecs);
That channel is already taken :)
Akihiro Sagawa writes:
> ---
> dlls/gdi32/tests/font.c |6 ++
> 1 file changed, 6 insertions(+)
There's no reason to require Times New Roman in that test, it could fall
back to some other font.
--
Alexandre Julliard
julli...@winehq.org
This patch adds 4 flags:
1) O_DENYREAD that doesn't permit read access,
2) O_DENYWRITE that doesn't permit write access,
3) O_DENYDELETE that doesn't permit delete or rename,
4) O_DENYMAND that enables O_DENY* flags checks.
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this
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
This patch adds 3 flags:
1) O_DENYREAD that doesn't permit read access
2) O_DENYWRITE that doesn't permit write access
3) O_DENYDELETE that doesn't permit delete or rename
Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags -
this change can benefit cifs and nfs modules. While this
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
Thanks for spotting. I will send an additional patch for that or do an
update.
2012/11/6 Nikolay Sivov
> On 11/6/2012 14:09, Alistair Leslie-Hughes wrote:
>
>> Hi,
>>
>> On 6/11/2012 7:05 PM, Christian Costa wrote:
>>
>>static HRESULT WINAPI IDirectMusicLoaderImpl_**
>>> IDirectMusicLoader_G
On 11/6/2012 14:09, Alistair Leslie-Hughes wrote:
Hi,
On 6/11/2012 7:05 PM, Christian Costa wrote:
static HRESULT WINAPI
IDirectMusicLoaderImpl_IDirectMusicLoader_GetObject(LPDIRECTMUSICLOADER8
iface, LPDMUS_OBJECTDESC pDesc, REFIID riid, LPVOID* ppv)
@@ -880,7 +884,7 @@ HRESULT WINAPI DMUS
Hi,
On 6/11/2012 7:05 PM, Christian Costa wrote:
static HRESULT WINAPI
IDirectMusicLoaderImpl_IDirectMusicLoader_GetObject(LPDIRECTMUSICLOADER8 iface,
LPDMUS_OBJECTDESC pDesc, REFIID riid, LPVOID* ppv)
@@ -880,7 +884,7 @@ HRESULT WINAPI DMUSIC_CreateDirectMusicLoaderImpl (LPCGUID
lpcGUID,
)
{
-return BaseFilterImpl_AddRef((IBaseFilter*)iface);
+ULONG ref = BaseFilterImpl_AddRef((IBaseFilter*)iface);
+
+TRACE("(%p)->(): new ref = %u\n", iface, ref);
+
+return ref;
}
You should get rid of casts like that. Also I don't see a reason to
print anything but refcou
);
+ULONG ref = BaseFilterImpl_AddRef((IBaseFilter*)iface);
+
+TRACE("(%p)->(): new ref = %u\n", iface, ref);
+
+return ref;
}
You should get rid of casts like that. Also I don't see a reason to
print anything but refcount itself life (%p)->(%u).
Chris wrote:
> 1. I discovered later that I don't think this is the root of my
> original bug - and in fact doesn't seem to affect behavior of my
> program. Is it still worth submitting?
Generally, fixes are more likely to get committed when they
don't break anything (did you run all the conforma
On Fri, Sep 21, 2012 at 8:41 PM, Chris Teague wrote:
> I submitted bug 31753 for an application that I use, and started
> making an attempt to fix it. I started with the last few messages
> from the log:
>
> fixme:win:LockWindowUpdate (0x501c4), partial stub!
> fixme:win:LockWindowUpdate ((nil)),
kefile.in
+++ b/dlls/user32/tests/Makefile.in
@@ -17,6 +17,7 @@ C_SRCS = \
menu.c \
monitor.c \
msg.c \
+ painting.c \
resource.c \
scroll.c \
static.c \
diff --git a/dlls/user32/tests/painting.c b/dlls/user32/tests/painting.c
new file mode 1
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=21637
Your par
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=21488
Your par
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=21489
Your par
Hi all,
It's a bit sooner for another Gecko update than usually. This is caused
by the fact, that many existing bugs in our MSHTML are blocked by
another bugs, which require Gecko changes for proper fix. These changes
enable using Gecko's cycle collector to understand our objects. This
solves quit
Den 18-04-2012 17:42, Piotr Caban skrev:
On 04/16/12 22:03, Morten Rønne wrote:
Add a new common module information struct for urlcache and functions to
do initialization of the struct. This is intended to be a new way to
more easily create Ansi and Unicode version of the functions, by doing a
On 04/16/12 22:03, Morten Rønne wrote:
Add a new common module information struct for urlcache and functions to
do initialization of the struct. This is intended to be a new way to
more easily create Ansi and Unicode version of the functions, by doing a
Ansi/Unicode preamble code that calls a
Hi Morten,
On 04/16/12 22:03, Morten Rønne wrote:
> typedef struct _HASH_CACHEFILE_ENTRY
> {
> CACHEFILE_ENTRY CacheFileEntry;
> DWORD dwAddressNext;
> DWORD dwHashTableNumber;
> -struct _HASH_ENTRY HashTable[HASHTABLE_SIZE];
> -} HASH_CACHEFILE_ENTRY;
> +HASH_ENTRY HashTab
Stefan Leichter writes:
> @@ -0,0 +1,49 @@
> +# imported from D-Link EMS by ordinal
> +320 stub SnmpSetPort
> +#
> +@ stub SnmpCancelMsg
> +@ stub SnmpCleanup
> +@ stub SnmpClose
> +@ stub SnmpContextRoStr
> +@ stub _SnmpConveyAgentAddress
> +@ stub SnmpCountVbl
> +@ stub SnmpCreatePdu
> +@ stub
that.
-N
On 04/17/2012 10:10 AM, Jeremy Newman wrote:
Someday.
-N
On 04/16/2012 08:30 PM, Vitaliy Margolen wrote:
Can I ask when we'll have the new forum software installed? It's been
discussed ages ago and we still using the same old crappy version.
Vitaliy.
Someday.
-N
On 04/16/2012 08:30 PM, Vitaliy Margolen wrote:
Can I ask when we'll have the new forum software installed? It's been
discussed ages ago and we still using the same old crappy version.
Vitaliy.
On Tue, Apr 17, 2012 at 11:13 AM, Frédéric Delanoy <
frederic.dela...@gmail.com> wrote:
> On Tue, Apr 17, 2012 at 03:30, Vitaliy Margolen
> wrote:
> > Can I ask when we'll have the new forum software installed? It's been
> > discussed ages ago and we still
On Tue, Apr 17, 2012 at 03:30, Vitaliy Margolen wrote:
> Can I ask when we'll have the new forum software installed? It's been
> discussed ages ago and we still using the same old crappy version.
IIRC there were some issues with the forum <=> mailing list interactions.
B
Can I ask when we'll have the new forum software installed? It's been
discussed ages ago and we still using the same old crappy version.
Vitaliy.
On 4/7/12 12:48 PM, Morten Rønne wrote:
How should I go about moving it? Should the patch (as it has been
commited) be removed from wine or should I send a new one, based on
the current state?
Send a new patch based on current state. You can also change it a little
later, e.g. while improving
uld I go about moving it? Should the patch (as it has been
commited) be removed from wine or should I send a new one, based on the
current state?
Best Regards
Morten Rønne
Den 06-04-2012 13:27, Piotr Caban skrev:
Hi,
On 04/05/12 08:50, Morten Rønne wrote:
diff --git a/include/wininet.h b/in
Hi,
On 04/05/12 08:50, Morten Rønne wrote:
diff --git a/include/wininet.h b/include/wininet.h
#define URLHISTORY_CACHE_ENTRY 0x0020
+#define DELETED_CACHE_ENTRY 0x0040
#define TRACK_OFFLINE_CACHE_ENTRY 0x0010
DELETED_CACHE_ENTRY is not defined in native w
On 3/31/12 3:36 PM, John Klehm wrote:
On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban wrote:
On 03/30/12 17:55, Aric Stewart wrote:
diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h
index 35cd52b..d2f680c 100644
--- a/dlls/quartz/quartz_private.h
+++ b/dlls/quartz/quartz_p
On Fri, Mar 30, 2012 at 11:08 AM, Jacek Caban wrote:
> On 03/30/12 17:55, Aric Stewart wrote:
>> diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h
>> index 35cd52b..d2f680c 100644
>> --- a/dlls/quartz/quartz_private.h
>> +++ b/dlls/quartz/quartz_private.h
>> @@ -38,7 +38,7 @
ok thanks,
Glad I got this feedback before I started submitting my com cleanup
patches that used it.
-aric
On 3/30/12 11:26 AM, Jacek Caban wrote:
On 03/30/12 18:09, Aric Stewart wrote:
Meaning that I should not shift TO using that macro instead shift AWAY
from using it?
I have been doing
On 03/30/12 18:09, Aric Stewart wrote:
> Meaning that I should not shift TO using that macro instead shift AWAY
> from using it?
>
> I have been doing some cleanup and been shifting to using it more.
ICOM_THIS_MULTI macro should go away. Your patch made ICOM_THIS_MULTI
look a bit better by using C
Meaning that I should not shift TO using that macro instead shift AWAY
from using it?
I have been doing some cleanup and been shifting to using it more.
-aric
On 3/30/12 11:08 AM, Jacek Caban wrote:
On 03/30/12 17:55, Aric Stewart wrote:
diff --git a/dlls/quartz/quartz_private.h b/dlls/quart
On 03/30/12 17:55, Aric Stewart wrote:
> diff --git a/dlls/quartz/quartz_private.h b/dlls/quartz/quartz_private.h
> index 35cd52b..d2f680c 100644
> --- a/dlls/quartz/quartz_private.h
> +++ b/dlls/quartz/quartz_private.h
> @@ -38,7 +38,7 @@
> #define BYTES_FROM_MEDIATIME(time) SEC_FROM_MEDIATIME(ti
On Thu, Feb 16, 2012 at 10:10:09AM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> Hi,
>
> this fixes bug #28413.
>
Thanks Jörg, looks sane to me and I can confirm it fixes the problem.
Andrew
Only adds the minimum definitions needed to use SCSIOP_READ_DVD_STRUCTURE.
From 598e9521bf585e0d610f1add305c271a04b4c714 Mon Sep 17 00:00:00 2001
From: Dan Kegel
Date: Thu, 9 Feb 2012 14:13:54 -0800
Subject: [PATCH 1/6] include: new file ddk/scsi.h
Only adds the minimum definitions needed to use
2012/1/3 Frédéric Delanoy :
> Might be difficult to explain to "plain" users though. Some already
> struggle performing a regression test (most won't even bother), let
> alone understanding the fine details of what a regression really
> represents.
>
The original thread starter excluded, I don't us
tter seems much more common.)
Unfortunately doing things like that requires a certain amount of good
judgment about what is reasonable to mark as a regression and what
isn't, as opposed to rigidly applying a set of rules. For example, if
adding a new dll exposes the fact that we need a HLSL
en doing The Right Thing (TRT)?
>>
>> Yes, it reduces the noise to let you concentrate on the real
>> regressions, i.e. the ones where working code got broken, and where you
>> can get useful information from the previous state.
>>
>> Having a new piece of co
1 - 100 of 1707 matches
Mail list logo
