Re: WGL patches cause problems with RBR and LFS
On Wed, Sep 06, 2006 at 07:42:03PM +0200, Roderick Colenbrander wrote: Hi Roderick, The WGL patches which are in mike's tree are different ones. They move the WGL-specific opengl code from opengl32.dll to x11drv. The code itself isn't changed. So first try if the problems appeared on 0.9.20 and then we will see further. sorry for making this not clear in the first mail. i was bisecting from wine-0.9.20 to current. in 0.9.20 everything is fine. i actually meant the patches that moved the WGL stuff. -- cu pgpfDH04jgwbV.pgp Description: PGP signature
Re: WGL patches cause problems with RBR and LFS
Hmm, strange. Could you run the programs using WINEDEBUG=+wgl appname.exe and post me the logs? Roderick On Wed, Sep 06, 2006 at 07:42:03PM +0200, Roderick Colenbrander wrote: Hi Roderick, The WGL patches which are in mike's tree are different ones. They move the WGL-specific opengl code from opengl32.dll to x11drv. The code itself isn't changed. So first try if the problems appeared on 0.9.20 and then we will see further. sorry for making this not clear in the first mail. i was bisecting from wine-0.9.20 to current. in 0.9.20 everything is fine. i actually meant the patches that moved the WGL stuff. -- cu -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Visual C++ does not seem to have snprinft
When compiling dlls/gdi/tests/metafile.c on line 1357 I get a warning C4013: snprintf is undefined. Looking around, it seems that snprinft is in fact _snprintf in Visual C++. I have found a define #if !defined(HAVE_SNPRINTF) defined(HAVE__SNPRINTF) #define snprintf _snprintf #endif in wine/port.h but it requires config.h and they don't appear in my Visual C++ system. What is the best way to address this problem? It seems to be fairly common but I have not found an example in a test. Jeff Latimer
Re: user: test and fix SwitchToThisWindow [2nd try]
On 9/7/06, Jan Zerebecki [EMAIL PROTECTED] wrote: Bugreport about this patch: http://bugs.winehq.org/show_bug.cgi?id=5725 I compiled-tested this and successfully ran the test on wine and (thx kblin) on native, because the author said that he is not able to compile wine. If this patch is rejected from inclusion, please tell me why, as I would have to ask anyway. From: Neil Rashbrook [EMAIL PROTECTED] Changelog: user: test and fix SwitchToThisWindow --- dlls/user/tests/Makefile.in |1 dlls/user/tests/win_sttw.c | 127 +++ dlls/user/winpos.c | 15 + 3 files changed, 142 insertions(+), 1 deletions(-) diff --git a/dlls/user/tests/Makefile.in b/dlls/user/tests/Makefile.in index 7a78a5b..4e10563 100644 --- a/dlls/user/tests/Makefile.in +++ b/dlls/user/tests/Makefile.in @@ -23,6 +23,7 @@ CTESTS = \ sysparams.c \ text.c \ win.c \ + win_sttw.c \ winstation.c \ wsprintf.c Why is this in a new file? It should be in win.c. -- James Hawkins
Re: tools: Remove redundant NULL checks before free() (found by Smatch).
I think the checks are necessary to be compatible with libc's on other platforms. -- Rob Shearman
Re: Visual C++ does not seem to have snprinft
Jeff L [EMAIL PROTECTED] writes: When compiling dlls/gdi/tests/metafile.c on line 1357 I get a warning C4013: snprintf is undefined. Looking around, it seems that snprinft is in fact _snprintf in Visual C++. I have found a define #if !defined(HAVE_SNPRINTF) defined(HAVE__SNPRINTF) #define snprintf _snprintf #endif in wine/port.h but it requires config.h and they don't appear in my Visual C++ system. What is the best way to address this problem? It seems to be fairly common but I have not found an example in a test. Just replace it by sprintf, tests should be made as portable as possible. -- Alexandre Julliard [EMAIL PROTECTED]
Re: tools: Remove redundant NULL checks before free() (found by Smatch).
Robert Shearman wrote: I think the checks are necessary to be compatible with libc's on other platforms. No they aren't. free() doing nothing with NULL pointers is ANSI-C standard: free deallocates the space pointed to by p: it does nothing if p is NULL. Quoted from The C Programming Language second edition by Kernighan and Ritchie with the subtitle ANSI C. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
wine and dos support
Hi, A friend of mine is asking me to get dos based games to work using wine. Well, I generally tell to use dosbox for that. Is it possible make them work in wine. If yes, what effort should we put into that. I mean what should we need to implement. Is it possible to lift some parts of other LGPL dos projects. Thanks, VJ
Re: Should I give up? = Please do not give up
Hi Damjan:
My work on the still image system for wine has
while wine incorrectly tries to open
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Class\----
ie. no curly braced around the guid.
And in addition it incorrectly returns FALSE for a
return type of HKEY (instead of INVALID_HANDLE_VALUE).
It's always a good Idea, to fix only one Bug at once.
I've submitted a test and patch to wine-patches 7
times now, and received very little feedback, which
I've always followed.
Please do not give up.
When a Patch goes in, depends not only on the actual
Patch-Quality / Size and what Patches came from the
Creator before, but also the actual amount of Patches
in the Pipeline and the Area, the Patch is for.
(I have similar Problems for my Patches about printing,
but at the moment, there was/is: Google SoC,
Crossover-Office Mac beta, AJ on Holiday, wineconf)
Also comments from other Developer about Patch-review
can affect the time, a Patch needs to go in the tree.
When there are some People working for the same Area
(d3d as example), patches are commented / reviewed by
others from the group (most times on #winehackers).
Reviewing Patches for an unusual Area is boring
and Applications do not use Device-installation
very often, but I took a look.
You mixed TAB and SPACE. (Common used for idention is 4 SPACE)
As already mentioned, testing the ANSI-version is prefered
and simplifies the test.
UNICODE - Tests do not test the String - convertations.
@@ -1453,21 +1454,30 @@
if (UuidToStringW((UUID*)ClassGuid, lpGuidString) != RPC_S_OK)
+lpBracedGuidString = (LPWSTR) HeapAlloc(GetProcessHeap(), 0,
+(1 + strlenW(lpGuidString) + 1 + 1) * sizeof(WCHAR));
+lpBracedGuidString[0] = (WCHAR) '{';
+memcpy(lpBracedGuidString[1], lpGuidString,
+strlenW(lpGuidString) * sizeof(WCHAR));
+lpBracedGuidString[1 + strlenW(lpGuidString)] = (WCHAR) '}';
+lpBracedGuidString[1 + strlenW(lpGuidString) + 1] = (WCHAR) 0;
+RpcStringFreeW(lpGuidString);
After looking in rpcrt4_main.c, RpcStringFreeW looks ok.
- RpcStringFreeW(lpGuidString);
+RpcStringFreeW(lpBracedGuidString);
You should use HeapFree here, because you used HeapAlloc above.
This makes you independant from changes inside rpcrt4.
RegCloseKey(hClassesKey);
- return FALSE;
+ return INVALID_HANDLE_VALUE;
}
With one fix as a time, the patch get's smaller and can be
reviewed more easy.
-RpcStringFreeW(lpGuidString);
+RpcStringFreeW(lpBracedGuidString);
Same as above: HeaAlloc - HeapFree
+static void test_SetupDiOpenClassRegKeyExW()
Parameter not used requires: (VOID)
+if (rpcStatus != RPC_S_OK)
+{
+ok(FALSE, failed to generate test guid, error %ld,
rpcStatus);
Already mentioned in other Mails.
+/* Check return value for non-existant key */
+hkey = pSetupDiOpenClassRegKeyExW(guid, KEY_ALL_ACCESS,
+DIOCR_INSTALLER, NULL, NULL);
+ok(hkey == INVALID_HANDLE_VALUE,
+invalid return value %p from SetupDiOpenClassRegKeyExW
+for non-existant key, expected %p\n, hkey,
INVALID_HANDLE_VALUE);
The Message is very long. I suggest not more as:
ok(hkey == INVALID_HANDLE_VALUE,
returned %p (expected INVALID_HANDLE_VALUE)\n, hkey)
Test failed: is prefixed by ok()
+bracedGuid = HeapAlloc(GetProcessHeap(), 0,
+(lstrlenW(unbracedGuid) + 3) * sizeof(WCHAR));
+if (bracedGuid != NULL)
+{
When the allocation failed, return from the test here.
This saves you a lot of idention.
But since you are testing for a non-existend value,
do you really need an unique Value here?
Can this be tested with all '0' or all 'F' ?
In this case, all value can be const string.
The test will be a lot short and even rpcrt4.dll
is not needed.
--
By by ... Detlef
Re: Help required to change function prototype
Vitaliy Margolen wrote: Dmitry Timoshkov wrote: Robert Shearman [EMAIL PROTECTED] wrote: Use LPCVOID instead of PCVOID. This is ntdll code and LPCVOID is a Win32 type. Don't use Win32 types in ntdll code. Then simple 'const void *' should do the trick, since introducing PCVOID is not an option (a quick search reveals that it doesn't exist in PSDK). Except that PSDK has it as PVOID. So we should stay away as much as possible from modifying what's in DDK/SDK. So I'm guessing this one will have to stay the way it is. Vitaliy. Thanks to you all! I shall hide my disappointment and move on to the next challenge. :) -- Andy.
Re: *** GMX Spamverdacht *** Re : [DDRAW] Only detach surfaces when releasing a non-texture surface attached to a complex root.
Hi,
Well I don't understand, what leaks ? Complex attached surfaces are still
destroyed when we fire the root. The new patch takes Moto Racer 2 memleak
issues in hand, and Nomad Soul leaks may not be related to this — not a
regression because exiting led to crash before ( and remaining surfaces are
simple surfaces ). In fact i was a bit unfresh when i posted the patch :P
..
My wait, I think I still do not really get what happens here...
Nomad Soul calls Release on the back buffer until it returns 0? Something like
while(Backbuffer-Release()); ?
Does it do that before releasing the front buffer, or after? I thought after
releasing the front buffer, because that was some odd behavior reported with
dune2000 which went away mysteriously...
Your patch, if I get it correctly, calls DeleteAttachedSurface only on the
surface that is actually destroyed. If a surface is destroyed that is
attached to a complex root then nothing else is done.
Just some questions to make sure I understand correctly:
* If the front buffer is destroyed and a z buffer attached to the back buffer,
the z buffer will not get detached when back buffer is destroyed? So the
reference to the z buffer will hang and the app crash will eventually when
zbuffer-first_attached is accessed?
* If the back buffer is explicitly released so its refcount falls to 0 before
the front buffer is destroyed, the z buffer is detached but nothing else
happens. The back buffer will be destroyed when the front buffer is
destroyed?
What does nomad soul do if you just return 0 when the ref of the back buffer
falls to 0?
E.g
if(ref == 0)
{
if(This-first_complex != this)
{
WARN(Attempt to destroy a surface that is attached to a complex
root\n);
return 0;
}
}
And leave the rest as it is. That would be correct according to the msdn(A
complex attached surface can only be destroyed by destroying the root). I
always thought this is enforced simply by the refcount, but well...
DDraw refcouting is horrible :-/ MS placed a lot of appcompat hacks into
it(see the tests), and I already had loads of fun with it. I'm afraid that
this will be fun for the future too...
pgpBDQXj5hYXA.pgp
Description: PGP signature
Re: include: Add new Vista SDK constants, fields and structures documented at http://ian.joeuser.com/index.asp?AID=738
Francois Gouget [EMAIL PROTECTED] wrote: --- a/include/commctrl.h +++ b/include/commctrl.h @@ -119,7 +119,9 @@ #define NM_TOOLTIPSCREATED (NM_FIRS #define NM_LDOWN(NM_FIRST-20) #define NM_RDOWN(NM_FIRST-21) #define NM_THEMECHANGED (NM_FIRST-22) - +#define NM_FONTCHANGED (NM_FIRST-23) +#define NM_CUSTOMTEXT (NM_FIRST-24) +#define NM_TVSTATEIMAGECHANGING (NM_FIRST-24) Do the two above really have the same values? -- Dmitry.
Re: Add comments so we know why we are not self-registering some dlls, which most of the time is because it is not doing anything anyway.
On Thu, 2006-09-07 at 19:54 +0200, Francois Gouget wrote: +;11,,wintrust.dll,1 FIXME: Just a stub Hi Francois, I'm pretty busy with the registering of wintrust currently, so why is this marked as a stub? Cheers, Paul.
