On Thu, Aug 21, 2008 at 11:08 PM, Vincent Povirk
<[EMAIL PROTECTED]> wrote:
> I think the proper fix is for appwiz.cpl to process the CPL_STOP and
> CPL_EXIT messages (see
> http://msdn.microsoft.com/en-us/library/aa454656.aspx)
I still think there could be a bug as I have IE installed and I assum
WM_CLOSE is already handled by the default window procedure,
DefWindowProcW, which calls DestroyWindow. It's only necessary to
override the default for WM_CLOSE if you want to prevent the window
from being destroyed.
Vincent Povirk
On Thu, Aug 21, 2008 at 10:44 PM, James McKenzie
<[EMAIL PROTEC
Vincent Povirk wrote:
> Why doesn't the WM_DESTROY case handle this properly? At first glance,
> it appears to have code for stopping the running applets and quitting
> from the main loop.
>
>
WM_CLOSE is different than WM_DESTROY. This is a missing case that
needs to be handled whenever the Wi
I think the proper fix is for appwiz.cpl to process the CPL_STOP and
CPL_EXIT messages (see
http://msdn.microsoft.com/en-us/library/aa454656.aspx)
Vincent Povirk
On Thu, Aug 21, 2008 at 9:55 PM, Vincent Povirk
<[EMAIL PROTECTED]> wrote:
> Commenting out FreeLibrary(applet->hModule); in Control_
On Thu, Aug 21, 2008 at 9:41 PM, Stefan Dösinger <[EMAIL PROTECTED]>wrote:
> These changes may be correct, but they need a test. Take a look at
> dlls/d3d9/tests/device.c to see how the other tests look. I guess the
> changes are likely to be correct, but they have to be tested
I'll add a test
Commenting out FreeLibrary(applet->hModule); in Control_UnloadApplet
avoids the crash. The problem is that the applet's dialog still exists
when FreeLibrary is called. Since its dialog procedure was in the
freed library, the program crashes when that dialog gets a message.
I don't know what the pr
On Thu, Aug 21, 2008 at 9:00 PM, Vincent Povirk
<[EMAIL PROTECTED]> wrote:
> Why doesn't the WM_DESTROY case handle this properly? At first glance,
> it appears to have code for stopping the running applets and quitting
> from the main loop.
>
> Calling ExitProcess from WM_CLOSE is anything but gra
Why doesn't the WM_DESTROY case handle this properly? At first glance,
it appears to have code for stopping the running applets and quitting
from the main loop.
Calling ExitProcess from WM_CLOSE is anything but graceful.
Vincent Povirk
On Thu, Aug 21, 2008 at 2:25 PM, Steven Edwards <[EMAIL PR
Louis wrote:
> Hi, apparently none of my patches is making it into git, nor did i recieve
> any response from Alexandre about what's wrong with them. I guess i'm kind of
> "blacklisted"
I don't think so. LOTS of people, me included, have trouble getting
patches into git. You just have to have
Am Donnerstag, den 21.08.2008, 17:35 -0500 schrieb John Klehm:
> On Thu, Aug 21, 2008 at 4:35 PM, Michael Karcher
> <[EMAIL PROTECTED]> wrote:
> > page, stating that
> > lstrcpyn(dest,"abcdefghi",4)
> > puts "abc" into dest.
> Seems like Wine's version at least always null terminates it, so
> "abc
On Thu, Aug 21, 2008 at 4:35 PM, Michael Karcher
<[EMAIL PROTECTED]> wrote:
> page, stating that
> lstrcpyn(dest,"abcdefghi",4)
> puts "abc" into dest.
>
Seems like Wine's version at least always null terminates it, so
"abc\0". Just so anyone, who like me had to look it up, can see.
http://sour
2008/8/21 Rico Schüller <[EMAIL PROTECTED]>:
> +/* Set the scissor rect values */
> +scissor.left=0;
> +scissor.right=ThisDevice->ddraw_width;
> +scissor.top=0;
> +scissor.bottom=ThisDevice->ddraw_height;
> +IWineD3DDevice_SetScissorRect(device, &scissor);
> +
Are you sure y
On Wednesday 20 of August 2008 01:14:10 Maarten Lankhorst wrote:
> I would like to request from the mentors to fill in the final evaluation
> form and from the students to give a final write up: What went well? Did
> you meet the goals you set? Did you have fun? Is there anything we can
> do to mak
Am Donnerstag, den 21.08.2008, 13:26 -0500 schrieb James Hawkins:
> Also, you're copying 4 bytes of filename into volumepathname. I don't
> think you understand what lstrcpyn does. Imagine this case:
>
> volumepathname = ""
> buflen = 8
> filename = "C:\\file"
>
> After the call to lstr
On Thu, Aug 21, 2008 at 3:59 PM, Louis. Lenders
<[EMAIL PROTECTED]> wrote:
>
>
> - Original Message
> From: James Hawkins <[EMAIL PROTECTED]>
> To: Louis. Lenders <[EMAIL PROTECTED]>
> Cc: wine-devel@winehq.org
> Sent: Thursday, 21 August, 2008 3:55:07 PM
> Subject: Re: kernel32: Tiny impr
- Original Message
From: James Hawkins <[EMAIL PROTECTED]>
To: Louis. Lenders <[EMAIL PROTECTED]>
Cc: wine-devel@winehq.org
Sent: Thursday, 21 August, 2008 3:55:07 PM
Subject: Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
>That whole paragraphs reads "hack no
Thanks. But Julliard has pointed out that my fix in patch [2/6] is
wrong, and it is. It works, but not for the right reason. I didn't
(and still don't) understand how everything in wineserver works
together very well. Without the patch [2/6] the conformance tests will
fail due to a thread race cond
On Thu, Aug 21, 2008 at 2:46 PM, Louis. Lenders
<[EMAIL PROTECTED]> wrote:
>
>
>>You've handled *a* successful case, but what about the error case?
>
> As i said already in the mail with the patch, it might be *a* case, but this
> is the case
> that most apps will follow as far as i can see. Futher
>You've handled *a* successful case, but what about the error case?
As i said already in the mail with the patch, it might be *a* case, but this is
the case
that most apps will follow as far as i can see. Futhermore, when apps are
really crashing
into the other cases, it can be added later o
>The "I'll send the rest later" is a warning light. You should further develop
>this and send it all later so >we know this is actually going somewhere.
The whole patch, that lets Governor of Poker start i have attached to the bug
http://bugs.winehq.org/attachment.cgi?id=15297
a few weeks ago.
On Thu, Aug 21, 2008 at 2:13 PM, Louis. Lenders
<[EMAIL PROTECTED]> wrote:
> Thanks for reviewing the patch James
> @@ -6,7 +6,7 @@
> 8 stub ADsBuildVarArrayInt
> 9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
> 12 stub ADsSetLastError
> -13 stub ADsGetLastError
> +13 stdcall ADsGetLastErr
Thanks for reviewing the patch James
@@ -6,7 +6,7 @@
8 stub ADsBuildVarArrayInt
9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
12 stub ADsSetLastError
-13 stub ADsGetLastError
+13 stdcall ADsGetLastError(ptr wstr long wstr long)
>Both of those wstr parameters are out pointers so they sho
slindeneau at gmail.com wrote:
> This patch will allow the patch [1/6] to successfully complete on wine
> and windows. Prior to this patch the conformance tests submitted in
> [1/6] of this series will fail on wine.
It's exciting to see such progress on AcceptEx!
But the wine project likes to hav
On Mon, Aug 18, 2008 at 4:18 AM, Louis. Lenders
<[EMAIL PROTECTED]> wrote:
> (the return TRUE statement got lost from last patch, thanks Michael for
> noticing)
>
>
> Hi, this fixes Adobe Lightroom 2.0 start up bug, mentioned in
> http://bugs.winehq.org/show_bug.cgi?id=8224#c4
>
> as long wine doe
On Wed, Aug 20, 2008 at 3:24 AM, Louis. Lenders
<[EMAIL PROTECTED]> wrote:
> Hi , this interface is needed to get governor if poker running
> (http://bugs.winehq.org/show_bug.cgi?id=14139). these first 3 patches is
> only preliminary stuff, the rest of the stuff i'll send later on.
>
The "I'll sen
"Scott Lindeneau" <[EMAIL PROTECTED]> writes:
> Fixes a bug in the async implementation. When checking for waiting
> elements on a queue you need to check to see if ANY element is waiting,
> not just the first element. When waking elements up you should ALERT an
> element that is not already al
On Tue, Aug 19, 2008 at 4:14 PM, Louis. Lenders
<[EMAIL PROTECTED]> wrote:
> Fixes a crash in Dameware utilities
>
@@ -6,7 +6,7 @@
8 stub ADsBuildVarArrayInt
9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr)
12 stub ADsSetLastError
-13 stub ADsGetLastError
+13 stdcall ADsGetLastError(ptr wst
Hi, apparently none of my patches is making it into git, nor did i recieve any
response from Alexandre about what's wrong with them. I guess i'm kind of
"blacklisted" because of my dxdiag patch from a few months ago, where i took
some code from a directX tutorial ( i thought tutorials were free
On Thu, Aug 21, 2008 at 12:59 PM, Scott Lindeneau <[EMAIL PROTECTED]> wrote:
> Simple overlapped server based on AcceptEx added to the test list
> using simple clients.
>
Tests must always 'pass'. That is, the individual ok tests must all
pass, or if they fail you must wrap the failing tests in t
>
> diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c
> index ddeaca3..dfbf818 100644
> --- a/dlls/d3d9/device.c
> +++ b/dlls/d3d9/device.c
> @@ -746,7 +746,8 @@ static HRESULT WINAPI
> IDirect3DDevice9Impl_GetDepthStencilSurface(LPDIRECT3DDE
> }
> } else {
> WARN("Cal
Don't all go out and vote - we don't want to skew the results - but check out
http://www.linuxjournal.com/node/1007221/results
What do you use to run Windows applications on your Linux desktop?
August 19th, 2008 by LJ Staff
Cedega 1% (8 votes)
Crossover 4% (38 votes)
VirtualBox 22% (195 votes)
VM
I noticed a patch that was submitted by John Griffiths on the 13th of
July that forwards functions by mwsock.c using the following code:
(commit: 2da98052d90591474c65bed853ca75e1da714823)
+static void get_fn(SOCKET s, GUID* guid, FARPROC* fn)
+{
+FARPROC func;
+DWORD len;
+if (!WSAIoctl
Alexander Nicolaysen Sørnes <[EMAIL PROTECTED]> writes:
> HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN
> punkOuter, REFIID riid, LPVOID *ppobj) {
> - WARN("(%p, %s, %p): stub.\n", punkOuter, debugstr_guid(riid), ppobj);
> - return CLASS_E_CLASSNOTAVAILABLE;
> +IDirec
Roy Shea <[EMAIL PROTECTED]> writes:
> +TaskImpl *This = (TaskImpl*)
> +((char*)(iface) - offsetof(TaskImpl, persistVtbl));
Please define an inline function for this like many other interfaces do.
--
Alexandre Julliard
[EMAIL PROTECTED]
2008/8/21 Stefan Dösinger <[EMAIL PROTECTED]>:
> These changes may be correct, but they need a test. Take a look at
> dlls/d3d9/tests/device.c to see how the other tests look. I guess the changes
> are likely to be correct, but they have to be tested
>
Not in its current form, there's a C++ comme
These changes may be correct, but they need a test. Take a look at
dlls/d3d9/tests/device.c to see how the other tests look. I guess the changes
are likely to be correct, but they have to be tested
On Wednesday 20 August 2008 20:34:43 Gerald Pfeifer wrote:
> This minor change on top of Hans' contributions in the recent days
> unbreaks the build on FreeBSD (and likely other BSDs and possibly
> Darwin/MacOS).
Thanks. I didn't want to copy all of the ifdef blocks from wininet
because I can't v
37 matches
Mail list logo
