Re: tests/msi.c fails when run twice on Wine?
James Hawkins wrote: On 7/27/07, Paul Vriens [EMAIL PROTECTED] wrote: Hi, The msi test currently fails for me on Wine when run the second time after getting a clean environment: rm -rf ~/.wine make msi.ok msi: 101 tests executed (0 marked as todo, 0 failures), 0 skipped. rm msi.ok make msi.ok msi.c:366: Test failed: Expected INSTALLSTATE_UNKNOWN, got 1 msi: 101 tests executed (0 marked as todo, 1 failure), 0 skipped. Anyone? Works fine for me. Hi James, Would the attached patch be OK? It makes sure that squash_guid always sets the out parameter and check the results of squash_guid in the callers (from registry.c). This fixes the msi test for me. I'm not sure about the returned error code ERROR_FILE_NOT_FOUND but it made the most sense to me. Cheers, Paul. diff --git a/dlls/msi/registry.c b/dlls/msi/registry.c index b9c0af4..bda4e28 100644 --- a/dlls/msi/registry.c +++ b/dlls/msi/registry.c @@ -233,6 +233,8 @@ BOOL squash_guid(LPCWSTR in, LPWSTR out) DWORD i,n=1; GUID guid; +out[0] = 0; + if (FAILED(CLSIDFromString((LPOLESTR)in, guid))) return FALSE; @@ -474,7 +476,8 @@ UINT MSIREG_OpenUserProductsKey(LPCWSTR szProduct, HKEY* key, BOOL create) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szProduct)); -squash_guid(szProduct,squished_pc); +if (!squash_guid(szProduct,squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_pc)); sprintfW(keypath,szUserProduct_fmt,squished_pc); @@ -493,7 +496,8 @@ UINT MSIREG_DeleteUserProductKey(LPCWSTR szProduct) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szProduct)); -squash_guid(szProduct,squished_pc); +if (!squash_guid(szProduct,squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_pc)); sprintfW(keypath,szUserProduct_fmt,squished_pc); @@ -508,7 +512,8 @@ UINT MSIREG_OpenUserPatchesKey(LPCWSTR szPatch, HKEY* key, BOOL create) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szPatch)); -squash_guid(szPatch,squished_pc); +if (!squash_guid(szPatch,squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_pc)); sprintfW(keypath,szUserPatch_fmt,squished_pc); @@ -528,7 +533,8 @@ UINT MSIREG_OpenUserFeaturesKey(LPCWSTR szProduct, HKEY* key, BOOL create) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szProduct)); -squash_guid(szProduct,squished_pc); +if (!squash_guid(szProduct,squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_pc)); sprintfW(keypath,szUserFeatures_fmt,squished_pc); @@ -553,7 +559,8 @@ UINT MSIREG_OpenFeaturesKey(LPCWSTR szProduct, HKEY* key, BOOL create) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szProduct)); -squash_guid(szProduct,squished_pc); +if (!squash_guid(szProduct,squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_pc)); sprintfW(keypath,szInstaller_Features_fmt,squished_pc); @@ -574,7 +581,8 @@ UINT MSIREG_OpenUserDataFeaturesKey(LPCWSTR szProduct, HKEY *key, BOOL create) LPWSTR usersid; TRACE(%s\n, debugstr_w(szProduct)); -squash_guid(szProduct, squished_pc); +if (!squash_guid(szProduct, squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_pc)); rc = get_user_sid(usersid); @@ -607,7 +615,8 @@ UINT MSIREG_OpenComponentsKey(LPCWSTR szComponent, HKEY* key, BOOL create) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szComponent)); -squash_guid(szComponent,squished_cc); +if (!squash_guid(szComponent,squished_cc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_cc)); sprintfW(keypath,szInstaller_Components_fmt,squished_cc); @@ -627,7 +636,8 @@ UINT MSIREG_OpenUserComponentsKey(LPCWSTR szComponent, HKEY* key, BOOL create) WCHAR keypath[0x200]; TRACE(%s\n,debugstr_w(szComponent)); -squash_guid(szComponent,squished_cc); +if (!squash_guid(szComponent,squished_cc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(squished_cc)); sprintfW(keypath,szUser_Components_fmt,squished_cc); @@ -648,7 +658,8 @@ UINT MSIREG_OpenUserDataComponentKey(LPCWSTR szComponent, HKEY *key, BOOL create LPWSTR usersid; TRACE(%s\n, debugstr_w(szComponent)); -squash_guid(szComponent, comp); +if (!squash_guid(szComponent, comp)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n, debugstr_w(comp)); rc = get_user_sid(usersid); @@ -677,7 +688,8 @@ UINT MSIREG_OpenUserDataProductKey(LPCWSTR szProduct, HKEY *key, BOOL create) LPWSTR usersid; TRACE(%s\n, debugstr_w(szProduct)); -squash_guid(szProduct, squished_pc); +if (!squash_guid(szProduct, squished_pc)) +return ERROR_FILE_NOT_FOUND; TRACE(squished (%s)\n,
Re: [advapi32/tests] Use skip when we don't have enough rights
This is a little offtopic, but the extra testresults might be because the test link was posted in the comments of a well-known dutch computer site (in dutch) http://tweakers.net/meuktracker/15817/Wine-0.9.42.html I thought you might want to know, and I'll try to link the test more often there :) (it wasnt me who posted it this time though) On 7/30/07, Paul Vriens [EMAIL PROTECTED] wrote: Hi, We suddenly have loads of new winetest results. Catched this one for Vista. Changelog Use skip when we don't have enough rights Cheers, Paul.
Re: [PATCH] winecfg: Add trackbar to set screen resolution in graphics tab (try 2)
Nigel Liang [EMAIL PROTECTED] writes:
+/* Utility functions to convert between WCHAR and long */
+long wcstolong(WCHAR * wcs)
+{
+int i;
+long lRet = 0;
+BOOL bNeg = FALSE;
+
+for (i = 0; wcs[i] != '\0'; i++) {
+if (i == 0 wcs[i] == '-') {
+bNeg = TRUE;
+continue;
+}
+
+lRet = lRet * 10 + (wcs[i] - '0');
+}
+return (bNeg ? -lRet : lRet);
+}
+
+WCHAR *longtow(long num, WCHAR *wcs)
+{
+static const WCHAR str[] = { '%', 'l', 'd', 0 };
+wsprintfW(wcs, str, num);
+return wcs;
+}
That's ugly. You should avoid using long if not really necessary,
since it doesn't have the same size in MSVC. You shouldn't name a
function wcs something since that's what wchar_t functions use. In any
case we already have atoiW for that purpose. Also I don't think
wrapping wsprintf is needed.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
Steven Edwards [EMAIL PROTECTED] wrote: In this case do you mean windres or rc? I ask because if its rc then shouldn't we fix wrc to not accept these sources also? If its windres thats broken I think there is a workaround for the problem. This patch is aimed to make winecfg resources compileable by microsoft's rc. I don't think that fixing wrc is worth the trouble. I just played with winecfg under Windows to see how well it behaves there :-) -- Dmitry.
Re: msvcr80 support!
Did you find a fix for this? As per Alexandre's suggestion I tried installing native common controls, and also copying all the manifest files from a Windows machine (even the whole winsxs directory), but I still get the same error as you when I try to run my application. No, I didn't find a fix, but I didn't spend much time searching for one either. I didn't try more than you did.
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Hans Leidekker wrote:
These APIs were introduced with Vista.
-Hans
Changelog
Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Hi Hans,
I was going through some test failures (already sent a patch for missing
defines).
It appears that a lot of the used strings, like System Up Time is depending on
the locale. Some Dutch tests show Systeem ingeschakeld instead.
Any idea how to fix that?
Another thing is that pdh.dll is not by default present on NT4 and below so
the tests have to be changed to cope with that as well. Should I have a go at that?
Cheers,
Paul.
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
On 30.07.2007 16:37, Dmitry Timoshkov wrote: Steven Edwards [EMAIL PROTECTED] wrote: In this case do you mean windres or rc? I ask because if its rc then shouldn't we fix wrc to not accept these sources also? If its windres thats broken I think there is a workaround for the problem. This patch is aimed to make winecfg resources compileable by microsoft's rc. I don't think that fixing wrc is worth the trouble. I just played with winecfg under Windows to see how well it behaves there :-) What's the actual problem? Also, wouldn't it be nicer to devise a fix that retains the “fancy” quote characters, instead of replacing them with boring 's? -f.r.
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
On Monday 30 July 2007 16:58:59 Paul Vriens wrote: It appears that a lot of the used strings, like System Up Time is depending on the locale. Some Dutch tests show Systeem ingeschakeld instead. Any idea how to fix that? Another thing is that pdh.dll is not by default present on NT4 and below so the tests have to be changed to cope with that as well. Should I have a go at that? I have patches pending so I'll fix these issues in one go. In fact, I had fixed some of the Vista failures already. -Hans
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Paul Vriens [EMAIL PROTECTED] writes: Another thing is that pdh.dll is not by default present on NT4 and below so the tests have to be changed to cope with that as well. Should I have a go at that? It may be a good idea to add generic support for that in winetest. It's a bit silly to have to manually fix all the tests that use new dlls. -- Alexandre Julliard [EMAIL PROTECTED]
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: Another thing is that pdh.dll is not by default present on NT4 and below so the tests have to be changed to cope with that as well. Should I have a go at that? It may be a good idea to add generic support for that in winetest. It's a bit silly to have to manually fix all the tests that use new dlls. And how would you do that? The first thing that winetest does is go through all the tests to retrieve all the subtests. If it finds a missing dll (or depending dll) we could/should catch that and not run the tests. Is it as simple as that? Cheers, Paul.
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Paul Vriens [EMAIL PROTECTED] writes: And how would you do that? The first thing that winetest does is go through all the tests to retrieve all the subtests. If it finds a missing dll (or depending dll) we could/should catch that and not run the tests. Is it as simple as that? Well, since the tests are named from the dll they are testing, I'd suggest that before running the test app 'foo_test.exe' we try a LoadLibrary(foo.dll), and if that fails we report the whole test as skipped. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvcr80 support!
Hi, Msn live messenger can be started by commenting out @ stdcall FindActCtxSectionStringA(long ptr long str ptr) @ stdcall FindActCtxSectionStringW(long ptr long wstr ptr) lines from kernel32.spec file. By the way it needs native gdiplus.dll, otherwise you won't get it's window. It is still unusable because of lack of textsrv functions of riched20.dll (native causes unhandled exception), and there is another problem that is present in msn 7.5, you can't sign in. 2007. július 27. 13.22 dátummal Alexandre Julliard ezt írta: Stefan Dösinger [EMAIL PROTECTED] writes: Windows Live messenger still refuses to start. Do I have to do anything special(other than updating wine), or should I report a bug for this: You need to install native common controls 6, or copy the common controls manifest from a Windows box, we don't have manifests for builtin dlls yet.
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
Frank Richter [EMAIL PROTECTED] wrote: What's the actual problem? rc simply doesn't handle \ or constructs. Also, wouldn't it be nicer to devise a fix that retains the “fancy” quote characters, instead of replacing them with boring 's? The problem is that those characters don't exist in some locales. -- Dmitry.
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: And how would you do that? The first thing that winetest does is go through all the tests to retrieve all the subtests. If it finds a missing dll (or depending dll) we could/should catch that and not run the tests. Is it as simple as that? Well, since the tests are named from the dll they are testing, I'd suggest that before running the test app 'foo_test.exe' we try a LoadLibrary(foo.dll), and if that fails we report the whole test as skipped. I'll have a look. How do yo want to report a missing test? In the normal report file? If that's the case we should also change the dissect/gather scripts: 'dissect' should cope with the new lines in the report files. 'gather' should make up some useful info in the generated html file. We only have information about subtests if one or more complete tests are run. If this thing works out, should we change the old tests back or use this new approach only for new (and currently failing) dll's? Cheers, Paul.
Re: #4 pdh: Implement and test PdhAddEnglishCounter{A, W} and PdhCollectQueryDataWithTime.
Paul Vriens [EMAIL PROTECTED] writes: I'll have a look. How do yo want to report a missing test? In the normal report file? If that's the case we should also change the dissect/gather scripts: It has to be part of the report data, so yes the scripts probably need to be updated. If this thing works out, should we change the old tests back or use this new approach only for new (and currently failing) dll's? If it simplifies the code we can certainly change the old tests too. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
On 30.07.2007 18:54, Dmitry Timoshkov wrote: Frank Richter [EMAIL PROTECTED] wrote: What's the actual problem? rc simply doesn't handle \ or constructs. Hm, I have some .rc files here with that work just fine with MS' rc. (Tho maybe it's braindead enough to have it supportted in one place but not some other.) And what about other substitutes, like \x22 or \042? Also, wouldn't it be nicer to devise a fix that retains the “fancy” quote characters, instead of replacing them with boring 's? The problem is that those characters don't exist in some locales. But when they exists in the codepage commonly used for a locale, I don't think there is a reason not to employ them? -f.r. signature.asc Description: OpenPGP digital signature
Re: tests/msi.c fails when run twice on Wine?
On 7/30/07, Paul Vriens [EMAIL PROTECTED] wrote: James Hawkins wrote: On 7/27/07, Paul Vriens [EMAIL PROTECTED] wrote: Hi, The msi test currently fails for me on Wine when run the second time after getting a clean environment: rm -rf ~/.wine make msi.ok msi: 101 tests executed (0 marked as todo, 0 failures), 0 skipped. rm msi.ok make msi.ok msi.c:366: Test failed: Expected INSTALLSTATE_UNKNOWN, got 1 msi: 101 tests executed (0 marked as todo, 1 failure), 0 skipped. Anyone? Works fine for me. Hi James, Would the attached patch be OK? It makes sure that squash_guid always sets the out parameter and check the results of squash_guid in the callers (from registry.c). This fixes the msi test for me. I'm not sure about the returned error code ERROR_FILE_NOT_FOUND but it made the most sense to me. hmm it should probably be ERROR_FUNCTION_FAILED, but otherwise it's fine. -- James Hawkins
Re: tests/msi.c fails when run twice on Wine?
James Hawkins wrote: On 7/30/07, Paul Vriens [EMAIL PROTECTED] wrote: James Hawkins wrote: On 7/27/07, Paul Vriens [EMAIL PROTECTED] wrote: Hi, The msi test currently fails for me on Wine when run the second time after getting a clean environment: rm -rf ~/.wine make msi.ok msi: 101 tests executed (0 marked as todo, 0 failures), 0 skipped. rm msi.ok make msi.ok msi.c:366: Test failed: Expected INSTALLSTATE_UNKNOWN, got 1 msi: 101 tests executed (0 marked as todo, 1 failure), 0 skipped. Anyone? Works fine for me. Hi James, Would the attached patch be OK? It makes sure that squash_guid always sets the out parameter and check the results of squash_guid in the callers (from registry.c). This fixes the msi test for me. I'm not sure about the returned error code ERROR_FILE_NOT_FOUND but it made the most sense to me. hmm it should probably be ERROR_FUNCTION_FAILED, but otherwise it's fine. Sound reasonable. I'll change that. I'll also have a look at the other callers of squash_guid. It's still strange though that it doesn't happen on your box (you are the only one that came back, and of course Alexandre cause I guess he runs the tests every time before he commits something). Cheers, Paul.
Re: tests/msi.c fails when run twice on Wine?
It's still strange though that it doesn't happen on your box (you are the only one that came back, and of course Alexandre cause I guess he runs the tests every time before he commits something). It also succeeds when running twice here. (make install.ok hangs here, though.) --Juan
Re: [PATCH] winecfg: Add trackbar to set screen resolution in graphics tab (try 2)
On 7/30/07, Alexandre Julliard [EMAIL PROTECTED] wrote:
Nigel Liang [EMAIL PROTECTED] writes:
+/* Utility functions to convert between WCHAR and long */
+long wcstolong(WCHAR * wcs)
+{
+int i;
+long lRet = 0;
+BOOL bNeg = FALSE;
+
+for (i = 0; wcs[i] != '\0'; i++) {
+if (i == 0 wcs[i] == '-') {
+bNeg = TRUE;
+continue;
+}
+
+lRet = lRet * 10 + (wcs[i] - '0');
+}
+return (bNeg ? -lRet : lRet);
+}
+
+WCHAR *longtow(long num, WCHAR *wcs)
+{
+static const WCHAR str[] = { '%', 'l', 'd', 0 };
+wsprintfW(wcs, str, num);
+return wcs;
+}
That's ugly. You should avoid using long if not really necessary,
since it doesn't have the same size in MSVC. You shouldn't name a
function wcs something since that's what wchar_t functions use. In any
case we already have atoiW for that purpose. Also I don't think
wrapping wsprintf is needed.
--
Alexandre Julliard
[EMAIL PROTECTED]
Yeah, I did not like those either. The reason that I used them is
because trying to use the _ltow and wcstol functions from
msvcrt/stdlib.h caused a bunch of conflicting type errors. I'll get
rid of them
-Nigel
Linuxworld BOF?
Anyone going to Linuxworld in San Francisco next week? It's free to go to the exhibits and BOFs if you register in advance; go here to register (and scroll to the bottom for the exhibit-only free choice): http://linuxworldexpo.com/live/12/TB296182 I'm probably going to hang out in the exhibit hall on Wed Aug 8th. Maybe we could organize a lunch BOF of Wine developers... - Dan
Re: tests/msi.c fails when run twice on Wine?
Juan Lang wrote: It's still strange though that it doesn't happen on your box (you are the only one that came back, and of course Alexandre cause I guess he runs the tests every time before he commits something). It also succeeds when running twice here. (make install.ok hangs here, though.) --Juan After a 'rm ~/.wine' ? Could this be a compiler/platform issue (difference). If you run 'WINEDEBUG=+msi make msi.ok' do you see garbage in the 'squished ...' output? Apart from the fact it only fails for me (for now), I guess the patch I've just sent makes sense anyhow. Cheers. Paul.
Re: tests/msi.c fails when run twice on Wine?
On 7/30/07, Paul Vriens [EMAIL PROTECTED] wrote: Juan Lang wrote: It's still strange though that it doesn't happen on your box (you are the only one that came back, and of course Alexandre cause I guess he runs the tests every time before he commits something). It also succeeds when running twice here. (make install.ok hangs here, though.) --Juan After a 'rm ~/.wine' ? Could this be a compiler/platform issue (difference). If you run 'WINEDEBUG=+msi make msi.ok' do you see garbage in the 'squished ...' output? Apart from the fact it only fails for me (for now), I guess the patch I've just sent makes sense anyhow. The garbage in the squished guid is not important...the regopen call will fail like it's supposed to because the squished guid doesn't match. -- James Hawkins
Re: tests/msi.c fails when run twice on Wine?
James Hawkins wrote: On 7/30/07, Paul Vriens [EMAIL PROTECTED] wrote: Juan Lang wrote: It's still strange though that it doesn't happen on your box (you are the only one that came back, and of course Alexandre cause I guess he runs the tests every time before he commits something). It also succeeds when running twice here. (make install.ok hangs here, though.) --Juan After a 'rm ~/.wine' ? Could this be a compiler/platform issue (difference). If you run 'WINEDEBUG=+msi make msi.ok' do you see garbage in the 'squished ...' output? Apart from the fact it only fails for me (for now), I guess the patch I've just sent makes sense anyhow. The garbage in the squished guid is not important...the regopen call will fail like it's supposed to because the squished guid doesn't match. Yeah I guess so, but I didn't have garbage all the time (remember I wrote that it succeeded when running with WINEDEBUG=+msi). So if it was just returned as an empty string (or at least interpreted as such) a RegOpenKey would succeed on the parent of the GUID (Software\Microsoft\Installer\Products) which is most of the time there. Cheers, Paul.
Re: [inkobj 2/2] Add stub test for inkobj.dll Try #2 with attachment
John Klehm wrote: Adds directory, makefile.in, and c file for simple test. This test tries to do LoadLibrary(inkobj.dll). I apologize for forgetting the attachment. Regards, John Hi, Are you planning on having more tests? It seems a lot of overkill if you just want to see if the library can be loaded/unloaded. The loadlibrary also doesn't make much sense as inkobj is already imported (Makefile.in). If it can't be loaded the test will not even run. Are you also sure that this dll exists on every platform we run tests on (win98Vista)? Cheers, Paul.
Re: [inkobj 2/2] Add stub test for inkobj.dll Try #2 with attachment
On 7/30/07, Paul Vriens [EMAIL PROTECTED] wrote: John Klehm wrote: Adds directory, makefile.in, and c file for simple test. This test tries to do LoadLibrary(inkobj.dll). I apologize for forgetting the attachment. Regards, John Hi, Are you planning on having more tests? It seems a lot of overkill if you just want to see if the library can be loaded/unloaded. Yes I am planning on adding more tests. The loadlibrary also doesn't make much sense as inkobj is already imported (Makefile.in). If it can't be loaded the test will not even run. I was just shooting for a minimal basic test. The main thing I wanted to get in this patch was the basic testing structure (directory, makefile, and whatnot). Are you also sure that this dll exists on every platform we run tests on (win98Vista)? No this dll should only work on Windows 2000 and above (atleast that's what the ms windows one supports). I'm not sure about how to limit it if it needs to be. Thanks for the feedback, John =)
Re: tests/msi.c fails when run twice on Wine?
It also succeeds when running twice here. (make install.ok hangs here, though.) After a 'rm ~/.wine' ? Yes. Could this be a compiler/platform issue (difference). Perhaps. If you run 'WINEDEBUG=+msi make msi.ok' do you see garbage in the 'squished ...' output? No. --Juan
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
On Sun, 2007-07-29 at 17:43 -0600, Vitaliy Margolen wrote: Peter Dons Tychsen wrote: OK. Please review this diff: I will re-submit it if you like it. /Pedro Alright looks good now (you might want to remove the extra white space your patch adds - git complains about those). Just left to make the same change to the other joystick interface :) BTW don't forget to cc: the wine-devel list when you replying. Vitaliy. OK. I still feel that trying to sync joystick_linuxinput.c and joystick_linux.c is out of scope for this patch. But as my steadiness has limits i have done some of it anyway... :). I have kept the changes modest. Please take a look at the new patch. On another note i will agree with you that it would be practical if the two files had similar (or maybe even shared) code. Redundant code is never very practical as it always ends up as this very example. The two implementations which were supposed to identical always drift apart. If things are supposed to do the same, keep them together to begin with. Thanks, /pedro
Re: dinput - Allow the use of the standard Joystick GUID when calling CreateDevice
On Mon, 2007-07-30 at 21:20 +0200, Peter Dons Tychsen wrote: On Sun, 2007-07-29 at 17:43 -0600, Vitaliy Margolen wrote: Peter Dons Tychsen wrote: OK. Please review this diff: I will re-submit it if you like it. /Pedro Alright looks good now (you might want to remove the extra white space your patch adds - git complains about those). Just left to make the same change to the other joystick interface :) BTW don't forget to cc: the wine-devel list when you replying. Vitaliy. OK. I still feel that trying to sync joystick_linuxinput.c and joystick_linux.c is out of scope for this patch. But as my steadiness has limits i have done some of it anyway... :). I have kept the changes modest. Please take a look at the new patch. On another note i will agree with you that it would be practical if the two files had similar (or maybe even shared) code. Redundant code is never very practical as it always ends up as this very example. The two implementations which were supposed to identical always drift apart. If things are supposed to do the same, keep them together to begin with. Thanks, /pedro Maybe i would be more successful if i actually attached the patch :-) Here it is 0001-Allow-the-use-of-the-standard-Joystick-GUID-when-cal.patch Description: application/mbox
winex11.drv compile failure
Compile fails for me with today's git: opengl.c: In function 'ConvertAttribWGLtoGLX': opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) opengl.c:676: error: (Each undeclared identifier is reported only once opengl.c:676: error: for each function it appears in.) opengl.c: In function 'get_render_type_from_fbconfig': opengl.c:845: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) opengl.c:846: error: 'GLX_RGBA_FLOAT_TYPE_ARB' undeclared (first use in this function) -- James Hawkins
Re: wine3d3: Check the destination recangle when for FastBlt().
On Sun, 2007-07-29 at 23:08 +0200, Stefan Dösinger wrote: Am Sonntag, 29. Juli 2007 21:28 schrieb Peter Dons Tychsen: Hello Wine! I have fixed a small bug in FastBlt(), which caused Wine to crash if the application tried to do FastBlt() to a surface using a bad destination setup. The problem is already fixed in normal Blt(), but was broken for FastBlt(). This fixes a crash for the little game Treasure Mole Winter Vacations: This check should be in ddraw, not wined3d. ddraw, d3d8 and d3d9 have different ideas about such checks, that's why the check was moved from WineD3D to the client libs. Originally it was in LockRect, and when it was moved the check was lost in Blt and BltFast. There should be a check in ddraw already, maybe it is not sufficient. Also please write a test case to verify that the fix is correct(look at dlls/ddraw/tests/dsurface.c). This will also prevent the problem from coming back. Treasure Mole broke after the ddraw rewrite because exactly this check was missing. I implemented it in LockRect, like in old ddraw, but I forgot to write a test for BltFast. Then a d3d9 game was broken because d3d9 LockRect behaved differently, a test was written for Lock(Rect) in ddraw, d3d8 and d3d9, and the range check moved to ddraw, d3d8 and d3d9 to be able to implement different checking in each version. Since I forgot to write a test when I originally fixed Treasure Mole the bug could creep back in again :-( Thanks for your comments Stefan, I have taken another look at it. I still think this specific problem should be fixed in wined3d. The problem occurs because BltFast (ddraw, d3d and d3d-gdi) all take two DWORDs as the offset write position, and then later casts them into a RECT structure which has signed values. This must for any caller be considered an error. No caller could get anything useful out of this. Code: IWineGDISurfaceImpl_BltFast(IWineD3DSurface *iface, DWORD dstx, DWORD dsty, IWineD3DSurface *Source, RECT *rsrc, DWORD trans) ... lock_dst.left = dstx; --- bad cast! lock_dst.top = dsty; --- bad cast! lock_dst.right = dstx + w; --- bad cast! lock_dst.bottom = dsty + h; --- bad cast! Why does this not trigger a warning? Not sure. I can still move the fix to ddraw, but as said, i am not sure it's the right move. Please comment, /pedro
Re: winex11.drv compile failure
On 30/07/07, James Hawkins [EMAIL PROTECTED] wrote: Compile fails for me with today's git: opengl.c: In function 'ConvertAttribWGLtoGLX': opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) opengl.c:676: error: (Each undeclared identifier is reported only once opengl.c:676: error: for each function it appears in.) opengl.c: In function 'get_render_type_from_fbconfig': opengl.c:845: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) opengl.c:846: error: 'GLX_RGBA_FLOAT_TYPE_ARB' undeclared (first use in this function) Looks like using extensions that aren't necessarily there again, except this time not for wined3d. I don't know if there's any mechanism for that in winex11.drv?
Re: winex11.drv compile failure
On Monday 30 July 2007 22:28, H. Verbeet wrote: On 30/07/07, James Hawkins [EMAIL PROTECTED] wrote: Compile fails for me with today's git: opengl.c: In function 'ConvertAttribWGLtoGLX': opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) opengl.c:676: error: (Each undeclared identifier is reported only once opengl.c:676: error: for each function it appears in.) opengl.c: In function 'get_render_type_from_fbconfig': opengl.c:845: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) opengl.c:846: error: 'GLX_RGBA_FLOAT_TYPE_ARB' undeclared (first use in this function) Looks like using extensions that aren't necessarily there again, except this time not for wined3d. I don't know if there's any mechanism for that in winex11.drv? The extensions are really needed. They are needed for WGL_ARB_pixel_format support. It works fine. I'll add the missing define. Roderick
Re: oleaut32: Constify some variables
On Mon, Jul 30, 2007 at 09:27:45PM +0100, Andrew Talbot wrote:
Changelog:
oleaut32: Constify some variables.
diff -urN a/dlls/oleaut32/typelib.c b/dlls/oleaut32/typelib.c
--- a/dlls/oleaut32/typelib.c 2007-07-30 17:23:19.0 +0100
+++ b/dlls/oleaut32/typelib.c 2007-07-30 21:23:13.0 +0100
@@ -147,7 +147,7 @@
/*
* Find a typelib key which matches a requested maj.min version.
*/
-static BOOL find_typelib_key( REFGUID guid, WORD wMaj, WORD *wMin )
+static BOOL find_typelib_key( REFGUID guid, const WORD *wMaj, WORD *wMin )
{
static const WCHAR typelibW[] = {'T','y','p','e','l','i','b','\\',0};
WCHAR buffer[60];
@@ -172,7 +172,7 @@
{
TRACE(found %s: %x.%x\n, debugstr_w(buffer), v_maj, v_min);
-if (wMaj == v_maj)
+if (*wMaj == v_maj)
{
if (*wMin == v_min)
{
@@ -274,7 +274,7 @@
TRACE_(typelib)((%s, %x.%x, 0x%x, %p)\n, debugstr_guid(guid), wMaj,
wMin, lcid, path);
-if (!find_typelib_key( guid, wMaj, wMin )) return
TYPE_E_LIBNOTREGISTERED;
+if (!find_typelib_key( guid, wMaj, wMin )) return
TYPE_E_LIBNOTREGISTERED;
get_typelib_key( guid, wMaj, wMin, buffer );
Alexandre committed a fixed version of this part of the patch already. See:
http://source.winehq.org/git/wine.git/?a=commitdiff;h=36720b4945f90896379e7af9dfea2b9a7a214cb9
The const fixup is no longer necessary, since the value now gets passed
as argument and not as pointer.
The rest might be necessary.
Ciao, Marcus
build regression, GLX_RGBA_FLOAT_BIT_ARB undeclared?
I just did a git pull, and compilation is failing with opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) I think that symbol reference was added just today: http://winehq.org/pipermail/wine-cvs/2007-July/034660.html and is supposed to come from glext.h. Do we need some #ifdef action here? I'm developing on dapper. $ cat /etc/issue Ubuntu 6.06.1 LTS \n \l $ dpkg-query -S glext.h mesa-common-dev: /usr/include/GL/glext.h $ dpkg-query -W mesa-common-dev mesa-common-dev 6.4.1-0ubuntu8
Re: build regression, GLX_RGBA_FLOAT_BIT_ARB undeclared?
Could you update to the latest GIT? :) Roderick On Monday 30 July 2007 23:39, Dan Kegel wrote: I just did a git pull, and compilation is failing with opengl.c:676: error: 'GLX_RGBA_FLOAT_BIT_ARB' undeclared (first use in this function) I think that symbol reference was added just today: http://winehq.org/pipermail/wine-cvs/2007-July/034660.html and is supposed to come from glext.h. Do we need some #ifdef action here? I'm developing on dapper. $ cat /etc/issue Ubuntu 6.06.1 LTS \n \l $ dpkg-query -S glext.h mesa-common-dev: /usr/include/GL/glext.h $ dpkg-query -W mesa-common-dev mesa-common-dev 6.4.1-0ubuntu8
Re: build regression, GLX_RGBA_FLOAT_BIT_ARB undeclared?
On 7/30/07, Roderick Colenbrander [EMAIL PROTECTED] wrote: Could you update to the latest GIT? :) Better, thanks!
Re: [PATCH] winecfg: Add menu font settings to desktop integration tab
On 7/27/07, Vitaliy Margolen [EMAIL PROTECTED] wrote: Nigel Liang wrote: On 7/25/07, Vitaliy Margolen [EMAIL PROTECTED] wrote: Nigel Liang wrote: diff --git a/programs/winecfg/En.rc b/programs/winecfg/En.rc index 5972c3b..e61bf29 100644 --- a/programs/winecfg/En.rc +++ b/programs/winecfg/En.rc @@ -200,6 +200,11 @@ BEGIN CONTROL Link to:,IDC_LINK_SFPATH,Button,BS_AUTOCHECKBOX|WS_TABSTOP|WS_DISABLED,15,195,50,13 EDITTEXT IDC_EDIT_SFPATH,65,195,145,13,ES_AUTOHSCROLL|WS_TABSTOP|WS_DISABLED PUSHBUTTON Browse,IDC_BROWSE_SFPATH,215,195,30,13,WS_DISABLED +GROUPBOX Menu Font ,IDC_STATIC,8,216,244,50 +LTEXT Font: ,IDC_STATIC,20,230,40,10 +COMBOBOX IDC_MENUFONT_COMBO,55,228,186,30,CBS_DROPDOWNLIST|CBS_SORT|WS_VSCROLL|WS_TABSTOP +LTEXT Size: ,IDC_STATIC,20,249,40,10 +COMBOBOX IDC_MENUFONT_SIZECOMBO,55,247,50,30,CBS_DROPDOWNLIST|WS_VSCROLL|WS_TABSTOP END There is already a drop down list where you can select menu and the Font button. You should use those instead. Of course you will need to make it work for all other items that might have font as an option (like a caption, window, etc). The underlying mechanism used to change menu fonts is totally different from the other controls. The whole group of controls grouped within the Appearance box is associated with setting color styles with calls to uxtheme.dll functions. The controls that I added with this patch wrote changes into win.ini using the Get/WriteProfileString functions. I think it would confuse people if the two were mixed together No, that part of winecfg has nothing to do with theming. Check the underlying code. Also I'm not sure what are you trying to archive with writing to win.ini? Wine reads all the settings from registry, and that's where it should go. Of course for that you should be using appropriate function - SystemParametersInfo. Vitaliy. I see what you mean now. The original way of modifying win.ini was taken from various posts on the web suggesting an easy way to adjust menu font size. (http://www.winehq.org/pipermail/wine-users/2004-May/013945.html for instance) Setting it with SystemParametersInfo seems like a much better way to integrate this function in winecfg. I'll make the changes and resubmit. Thanks! -Nigel
About new environment variable
After I add an environment avriable in the system.reg file, e.g. [System\\CurrentControlSet\\Control\\Session Manager\\Environment] 1185851455 MY_VARIABLE=VALUE I tried to read this variable thru the API GetEnvironmentVariable(), but it failed. Other variables, such as PATH, OS, are OK. Any idea is welcomed.
Re: [PATCH 3/5] winecfg: Make winecfg resources compilable by aWindows resource compiler
Frank Richter [EMAIL PROTECTED] wrote: What's the actual problem? rc simply doesn't handle \ or constructs. Hm, I have some .rc files here with that work just fine with MS' rc. rc doesn't support embedded or escaped quotes at all. So statements like LTEXT String with quotes,-1,7,7,120,8 or LTEXT String with \quotes\,-1,7,7,120,8 don't work. (Tho maybe it's braindead enough to have it supportted in one place but not some other.) And what about other substitutes, like \x22 or \042? No, that doesn't help. Also, wouldn't it be nicer to devise a fix that retains the “fancy” quote characters, instead of replacing them with boring 's? The problem is that those characters don't exist in some locales. But when they exists in the codepage commonly used for a locale, I don't think there is a reason not to employ them? That would create an additional problem for translators IMO. -- Dmitry.
Re: user32: erase parent when hiding child
Clinton Stimpson [EMAIL PROTECTED] wrote: ChangeLog: user32: erase parent when hiding child As I already pointed out erasing a parent is supposed to be done in the server. You need to look there why it doesn't happen and add a fix there. -- Dmitry.
Re: About new environment variable
Zhongli Xu wrote: After I add an environment avriable in the system.reg file, e.g. Don't ever do that. Use regedit or proper registry API. Also do not crosspost. If you asking in user channel, then ask there. If you asking developers, then ask on wine-devel only. Vitaliy.
