June 2010 - Wine-Devel - list.winehq.org

Two enhancement requests for winetricks

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Jan Hoogenraad wrote: >Each debugging request for wine states that I should remove all winetricks. AppDB should request something similar: minimal use of winetricks. >However I have no way to tell, and no way to safely remove them. IMHO one solution to your problem is to learn to use different .wine prefixes. Both developers and AppDB users want a repeatable process to make the app run (or crash). If you install all your software into a single .wine hierarchy (like you'd do on MS-Windows), then you cannot tell anyone what you did to make the app work in Wine. All you have is "I started with Wine-0.9.48, upgraded to wine-1.1.6 at some time, now to wine-1.2rc2, used "winetricks X" and Y, perhaps I used "winetricks directx" but I can't remember for sure, I installed apps A, B and C (they may have installed more components) and I edited the registry a few times. Given all that, app Z works fine in on my machine." This is a mess much like a typical MS-Windows installation. With Wine, you can do better than that. What people want to hear from you is as follows: - Create a fresh .wine prefix with wine-X.Y; - Install Indeo Video codecs via "winetricks indeo" because I found out that the app expects them but does not install them itself; - Install the app from CD; - From a DirectX install into a separate .wine-* prefix, solely copy d3dx9_36.dll into system32/ (or the app's directory) - Change setting Y in winecfg, e.g. native d3dx9_36; - App Z works (or crashes like that ...). That is a minimal instruction set. I have like a dozen .wine-* directory hierarchies. I never use .wine itself except for regression testing, such that I can rm -rf ~/.wine and create a fresh one at any time. That's why I don't need an uninstaller. rm -rf ~/.wine-xyz or rm -rf ~/wineapps/... *is* the uninstaller (.wine-xyz/drive_c/Programs/Apps/ symlinks to $HOME/wineapps such that the apps live independently on a particular .wine prefix). Regards, Jörg Höhle

June 11, 2010

Re: Three year sever outstanding bug requiring minor fix

by Stephen Eilert

On Wed, Jun 9, 2010 at 12:52 PM, velociraptor Genjix <aphidia(a)hotmail.com> wrote: > Hey, > Please look into this issue, > http://bugs.winehq.org/show_bug.cgi?id=15118 > It seems like a fairly trivial fix which renders this application useless. A > detailed description of the implementation needed is provided in that > ticket. > Thank you Seriously. I fail to see how you can find the fix "easy". I've read the problem description and it doesn't appear to be easy at all. How is Wine supposed to support transparent windows? With Compiz? With the Composite extension? How to check for them? What if they are not available? Yes, one could just set the appropriate xatom flags and be done with it, but if a compositing window manager is not present it won't do anything. Also, I am not sure about the click through flag, that would require some spelunking to find out how wine supports it, if at all. All in all, it doesn't appear to be trivial. It doesn't even have a proposed patch! Repeating assertions in the bug report and the mailing list is a good way to annoy people. One thing that you should understand is that "widely wanted features" mean exactly nothing. Being "widely wanted" won't make the feature easier to implement, test or integrate. You could offer a business proposition to CodeWeavers or Transgaming, for them to implement a feature, offer a bounty, code it yourself or even pay someone you know to do it for you. You could even work with other people in UK who like playing poker to pool the resources for such task. That would be more productive. -- Stephen Sent from my Emacs

June 11, 2010

Re: No test summary line found

by GOUJON Alexandre

Le 11/06/2010 13:54, Paul Vriens a écrit : > I don't know if you have an account on the testbot so I tested it for > you: "I submitted [to wineTestBot] my patch before sending it to wine-patches" But many thanks for your help !!! In that case, we have to use broken(), haven't we ?

June 11, 2010

Re: No test summary line found

by Paul Vriens

On 06/11/2010 01:20 PM, Paul Vriens wrote: > On 06/11/2010 01:13 PM, GOUJON Alexandre wrote: >> Le 11/06/2010 11:58, Paul Vriens a écrit : >>> Those are the results from the testbot: >> I know, I received the log by mail and I submitted my patch before >> sending it to wine-patches but I didn't understand it as an error. >> >>> This means this new test is crashing on (that) NT4. >> >> WNT4WSSP6.log >> advapi32:security start - - >> security.c:1427: Tests skipped: CreateWellKnownSid not available >> security.c:1084: AccessCheck with MAXIMUM_ALLOWED got Access 0x00060019 >> security.c:1140: Tests skipped: AddAccessAllowedAceEx is not available >> security.c:1223: Tests skipped: ConvertSidToStringSidA is not available >> security.c:1997: Tests skipped: NULL account name doesn't work on NT4 >> security.c:2073: Tests skipped: CreateWellKnownSid not available >> advapi32:security done (3221225477) >> >> No test summary line found >> >> >> 3221225477 = 0xC0000005 = STATUS_ACCESS_VIOLATION but where does it come >> from ? >> There is neither backtrace nor timeout log/explanation. > > Submit your patch to the testbot and run them on NT4 only. Make sure you > leave the WINETEST_DEBUG flag and set the WINETEST_REPORT_SUCCESS one. > That should show you the last successful ok-test. > >> >> Whatever its origin, the next test after test_LookupAccountName() is >> test_security_descriptor() whereas my patch just modified >> test_GetNamedSecurityInfoA(). >> >> And a last question : Does win_skip do return ? > > win_skip is just to show (on test.winehq.org) that one or more tests are > skipped. The difference between skip and win_skip is that skip can be > used on all platforms, win_skip only on Windows (it will show a failure > on Wine). > >> Some tests add a return after it, and others no. > > That depends on the kinds of tests. If you want to test a function and > the OS doesn't implement it than it makes no sense to continue so you > return. If you only need to skip a particular test you do continue. > I don't know if you have an account on the testbot so I tested it for you: https://testbot.winehq.org/JobDetails.pl?Key=2586&log_201=1&scrshot_201=1#k… What you can see is the last successful test was on line 2671. This means that most likely the first of your added tests already crashes on NT4: 2671 ok(group != NULL, "group should not be NULL\n"); 2672 2673 LocalFree(pSecDesc); 2674 2675 2676 /* NULL descriptor tests */ 2677 2678 error = pGetNamedSecurityInfoA(windows_dir, SE_FILE_OBJECT,DACL_SECURIT 2679 NULL, NULL, NULL, NULL, NULL); 2680 ok(error==ERROR_INVALID_PARAMETER, "GetNamedSecurityInfo failed with er 2681 -- Cheers, Paul.

June 11, 2010

Re: [PATCH 2/5] include: Add IEnumShellItems interface declaration.

by Huw Davies

On 11 Jun 2010, at 12:17, David Hedberg <david.hedberg(a)gmail.com> wrote: > --- > dlls/actxprxy/usrmarshal.c | 21 +++++++++++++++++++++ > include/shobjidl.idl | 30 ++++++++++++++++++++++++++++++ > 2 files changed, 51 insertions(+), 0 deletions(-) > > diff --git a/dlls/actxprxy/usrmarshal.c b/dlls/actxprxy/usrmarshal.c > index f2aacf8..85e534c 100644 > --- a/dlls/actxprxy/usrmarshal.c > +++ b/dlls/actxprxy/usrmarshal.c > + > +HRESULT CALLBACK IEnumShellItems_Next_Proxy( > + IEnumShellItems *This, > + ULONG celt, > + IShellItem **rgelt, > + ULONG *pceltFetched) > +{ > + TRACE("(%p)\n", This); > + return IEnumShellItems_RemoteNext_Proxy( This, celt, rgelt, > pceltFetched ); > +} pceltFetched could be a NULL ptr here, so you should pass the address of a local variable in that case. See ole32/usrmarshal.c for examples on how to marshal IEnum*_Next Huw.

June 11, 2010

Re: No test summary line found

by Paul Vriens

On 06/11/2010 01:13 PM, GOUJON Alexandre wrote: > Le 11/06/2010 11:58, Paul Vriens a écrit : >> Those are the results from the testbot: > I know, I received the log by mail and I submitted my patch before > sending it to wine-patches but I didn't understand it as an error. > >> This means this new test is crashing on (that) NT4. > > WNT4WSSP6.log > advapi32:security start - - > security.c:1427: Tests skipped: CreateWellKnownSid not available > security.c:1084: AccessCheck with MAXIMUM_ALLOWED got Access 0x00060019 > security.c:1140: Tests skipped: AddAccessAllowedAceEx is not available > security.c:1223: Tests skipped: ConvertSidToStringSidA is not available > security.c:1997: Tests skipped: NULL account name doesn't work on NT4 > security.c:2073: Tests skipped: CreateWellKnownSid not available > advapi32:security done (3221225477) > > No test summary line found > > > 3221225477 = 0xC0000005 = STATUS_ACCESS_VIOLATION but where does it come > from ? > There is neither backtrace nor timeout log/explanation. Submit your patch to the testbot and run them on NT4 only. Make sure you leave the WINETEST_DEBUG flag and set the WINETEST_REPORT_SUCCESS one. That should show you the last successful ok-test. > > Whatever its origin, the next test after test_LookupAccountName() is > test_security_descriptor() whereas my patch just modified > test_GetNamedSecurityInfoA(). > > And a last question : Does win_skip do return ? win_skip is just to show (on test.winehq.org) that one or more tests are skipped. The difference between skip and win_skip is that skip can be used on all platforms, win_skip only on Windows (it will show a failure on Wine). > Some tests add a return after it, and others no. That depends on the kinds of tests. If you want to test a function and the OS doesn't implement it than it makes no sense to continue so you return. If you only need to skip a particular test you do continue. -- Cheers, Paul.

June 11, 2010

Re: No test summary line found

by GOUJON Alexandre

Le 11/06/2010 11:58, Paul Vriens a écrit : > Those are the results from the testbot: I know, I received the log by mail and I submitted my patch before sending it to wine-patches but I didn't understand it as an error. > This means this new test is crashing on (that) NT4. WNT4WSSP6.log advapi32:security start - - security.c:1427: Tests skipped: CreateWellKnownSid not available security.c:1084: AccessCheck with MAXIMUM_ALLOWED got Access 0x00060019 security.c:1140: Tests skipped: AddAccessAllowedAceEx is not available security.c:1223: Tests skipped: ConvertSidToStringSidA is not available security.c:1997: Tests skipped: NULL account name doesn't work on NT4 security.c:2073: Tests skipped: CreateWellKnownSid not available advapi32:security done (3221225477) No test summary line found 3221225477 = 0xC0000005 = STATUS_ACCESS_VIOLATION but where does it come from ? There is neither backtrace nor timeout log/explanation. Whatever its origin, the next test after test_LookupAccountName() is test_security_descriptor() whereas my patch just modified test_GetNamedSecurityInfoA(). And a last question : Does win_skip do return ? Some tests add a return after it, and others no. Thanks

June 11, 2010

Re: Updating Ukrainian translations to kernel32

by Nikolay Sivov

On 6/11/2010 09:30, Dmitry Timoshkov wrote: > Igor Paliychuk<igor-hkr(a)mail.ru> wrote: > > >> Updating Ukrainian translations to kernel32(ukr.nls). >> file : ukrainian-kernel32-ukr-nls.patch >> > You forgot to mention what's wrong with current ukr.nls. > I asked Igor to update genitive months names, so it was basically incomplete. Also there's some typo fixes in a patch.

June 11, 2010

Re: No test summary line found

by Paul Vriens

On 06/11/2010 11:42 AM, GOUJON Alexandre wrote: > Hi, > > I'm wondering if my patch (62325) hasn't been reviewed yet or if you > expect a strict error-free patch. > Indeed, http://source.winehq.org/patches/data/62325.testfail shows a "No > test summary line found" for WNT4WSSP6. > If it's an issue, how to fix it ? > > Thanks > > Hi, Those are the results from the testbot: http://testbot.winehq.org/JobDetails.pl?Key=2467&scrshot_202=1#k202 This means this new test is crashing on (that) NT4. -- Cheers, Paul.

June 11, 2010

Re: gdi32: CreateFontIndirectEx implementation on top of CreateFontIndirect

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > From fb4317a2a39475c225fe04946795892c4891cd26 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <nsivov(a)codeweavers.com> > Date: Fri, 11 Jun 2010 01:42:06 +0400 > Subject: [PATCH] CreateFontIndirectEx implementation on top of CreateFontIndirect It should of course be the other way around. -- Alexandre Julliard julliard(a)winehq.org

June 11, 2010

No test summary line found

by GOUJON Alexandre

Hi, I'm wondering if my patch (62325) hasn't been reviewed yet or if you expect a strict error-free patch. Indeed, http://source.winehq.org/patches/data/62325.testfail shows a "No test summary line found" for WNT4WSSP6. If it's an issue, how to fix it ? Thanks

June 11, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()

by Andrew Nguyen

On Fri, Jun 11, 2010 at 3:34 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Hello Andrew, > > On 11-06-10 10:18, Andrew Nguyen wrote: >> >> On Sun, Jun 6, 2010 at 4:03 PM, Maarten Lankhorst >> <m.b.lankhorst(a)gmail.com> wrote: >> >>> >>> Is snd_pcm_recover the only function missing? If so change it to dlsym, >>> and >>> add a copy of snd_pcm_recover to wine if it cannot find the libalsa one.. >>> >> >> Is it a problem to eschew the use of dlsym? It feels like modifying >> winealsa.drv to dynamically load libasound correctly would be much >> more burdensome than simply replicating the snd_pcm_recover >> implementation. I have a provisional patch that replaces a half-baked >> snd_pcm_recover-like internal helper with the actual snd_pcm_recover >> implementation from libasound. I would welcome any feedback on it. >> > > Nah, I dislike the overuse of dlsym in wine too. > > Can you name the function wine_snd_pcm_recover, and fix the SNDERR() > macro's? Otherwise looks good to me. > > ~Maarten > Done. I've sent a final patch.

June 11, 2010

Re: IDL trouble (patch: adding IEnumShellItems interface declaration.)

by Huw Davies

On 11 Jun 2010, at 02:42, David Hedberg <david.hedberg(a)gmail.com> wrote: > Hello everyone, > > I'm having some trouble with this simple patch. Specifically, it > breaks compiling of dlls/actxprxy, producing the message: > > ***** > > /home/david/Projects/wine/git/dlls/actxprxy/actxprxy_shobjidl_p.c: > 6507: undefined reference to `IEnumShellItems_Next_Stub' > actxprxy_shobjidl_p.o:(.data.rel.ro+0xf0): undefined reference to > `IEnumShellItems_Next_Proxy' > ***** > > It compiles if I remove the [call_as] attribute, but I guess that > would kind of break the interface. Any obvious mistakes in the > patch, or grammar not supported by widl? You need to add an implementation of IEnumShellItems_Next_Proxy/Stub to usrmarshal.c Huw.

June 11, 2010

RE: Three year sever outstanding bug requiring minor fix

by velociraptor Genjix

Hey, Sorry I didn't mean any offence caused. It's just I saw that the new wine release is going to fix bugs and tried to bring it to your attention. I saw the guy Will Tipton in that bug ticket provided a detailed analysis of the problem so it looked easy since you already would know the problem (or at least a lot less difficult). Not only that but it has 9 votes and is a widely wanted asked for feature if you check google, http://www.google.co.uk/search?sourceid=chrome&ie=UTF-8&q=pokertracker+wine I didn't mean to be making people upset, it was more a helpful suggestion. Maybe caused by english language being not my first. > Date: Wed, 9 Jun 2010 11:00:16 -0700 > From: jjmckenzie51(a)earthlink.net > To: wine-devel(a)winehq.org > Subject: Re: Three year sever outstanding bug requiring minor fix > > velociraptor Genjix <aphidia(a)hotmail.com> wrote at Jun 9, 2010 8:52 AM > > > >Hey, > >Please look into this issue, > >http://bugs.winehq.org/show_bug.cgi?id=15118 > >It seems like a fairly trivial fix which renders this application useless. A detailed > >description of the implementation needed is provided in that ticket. > > If it were a 'trival' fix, it would have been a long time ago. Something that looks, on the surface, to be simple, maybe very complex. For instance, I have been working on a fix for one function in the richedit area has taken over four years. > > Now as to your concern, tough. This project, for the most part is volunteer. So, if you want it fixed, do it yourself or find someone who can. Otherwise, you'll have to wait for someone to come by, find this interesting and then fix it. There is a part of the project that is paid, and they work for a company called CodeWeavers. Maybe they have found a fix and incorporated it into their product line. That you'll have to pay for. > > Remember, we fix things as WE find the time and the incorporation process is very strict. This takes time and some folks will pick up a project, only to set it down because they become busy with other things in life or they just don't have the tenancity to see it through. > > James McKenzie > > > _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now

June 11, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()

by Maarten Lankhorst

Hello Andrew, On 11-06-10 10:18, Andrew Nguyen wrote: > On Sun, Jun 6, 2010 at 4:03 PM, Maarten Lankhorst > <m.b.lankhorst(a)gmail.com> wrote: > >> Is snd_pcm_recover the only function missing? If so change it to dlsym, and >> add a copy of snd_pcm_recover to wine if it cannot find the libalsa one.. >> > Is it a problem to eschew the use of dlsym? It feels like modifying > winealsa.drv to dynamically load libasound correctly would be much > more burdensome than simply replicating the snd_pcm_recover > implementation. I have a provisional patch that replaces a half-baked > snd_pcm_recover-like internal helper with the actual snd_pcm_recover > implementation from libasound. I would welcome any feedback on it. > Nah, I dislike the overuse of dlsym in wine too. Can you name the function wine_snd_pcm_recover, and fix the SNDERR() macro's? Otherwise looks good to me. ~Maarten

June 11, 2010

Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()

by Andrew Nguyen

On Sun, Jun 6, 2010 at 4:03 PM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Is snd_pcm_recover the only function missing? If so change it to dlsym, and > add a copy of snd_pcm_recover to wine if it cannot find the libalsa one.. Is it a problem to eschew the use of dlsym? It feels like modifying winealsa.drv to dynamically load libasound correctly would be much more burdensome than simply replicating the snd_pcm_recover implementation. I have a provisional patch that replaces a half-baked snd_pcm_recover-like internal helper with the actual snd_pcm_recover implementation from libasound. I would welcome any feedback on it.

June 11, 2010

Re: [1/3] d3dx9: Allow sampler declaration without sampler type.

by Stefan Dösinger

Am 11.06.2010 um 04:59 schrieb James McKenzie: > Stefan Dösinger wrote: >> It wasn't intended as an objection. It was mostly curiosity, because we have no test in d3d9 that checks for similar behavior, and trying to actually use such a shader for rendering would be somewhat odd. >> > It might be a good idea to create the test first before attempting to commit this patch. AJ probably would want this. We don't know the validator's interface. It is undocumented. We're currently testing what it accepts and rejects by running native vsa.exe or psa.exe and see if it accepts the shader with validation on or off. (the validator is implemented in d3d9.dll, not d3dx9.dll) So implementing such a test is not trivial.

June 11, 2010

Re: resources: Convert Polish resources to UTF8.

by GOUJON Alexandre

Le 11/06/2010 03:52, James McKenzie a écrit : > How can I get OLDER information on patches from previous releases? You should have a look at http://www.winehq.org/mailman/listinfo. Everything is archived (patches submitted, commits and of course this mailing list) It's very useful when someone tried to do something before but was rejected/incomplete.

June 11, 2010

Re: resources: Convert Polish resources to UTF8.

by Paul Vriens

On 06/11/2010 08:38 AM, Frédéric Delanoy wrote: > 2010/6/11 Dmitry Timoshkov<dmitry(a)codeweavers.com>: >> Frédéric Delanoy<frederic.delanoy(a)gmail.com> wrote: >> >>> I see this patch has been "Rejected" in >>> http://source.winehq.org/patches/, but I just wondered why: >>> - are the UTF8 resources not preferred over custom codepages? >>> - or is the patch simply too big to review? Splitting into many tiny >>> patches seemed a bit overkill for such a simple change, no? >>> >>> Or maybe is it simply because Polish translations is still in >>> progress, and it can/will cause conflict? >> >> There is no point in just converting the translations. If you update >> a translation, and simulataneously convert it - that's OK. >> >> -- >> Dmitry. > > Well, I proposed Łukasz to use UTF8 (since it appeared to be the new > standard charset) while he was updating Polish translations, but since > he wasn't too comfortable with the process, I offered to do it myself, > so wrote a script to check/convert files (and he tested the result). > > I could give him the script so he can use it when he updates a file, > but I don't see the added value not to do it directly. > > I don't see the problem with converting files without updating a > single translation: is it so regression-prone? > > Frédéric > > I talked to Alexandre about this the other day and he also said that we shouldn't convert the existing files to UTF-8. Post 1.2 we would most likely go with po files for the translations themselves and at that point everything would become UTF-8. -- Cheers, Paul.

June 11, 2010

Re: Tests crash

by GOUJON Alexandre

Le 10/06/2010 23:38, Austin English a écrit : > On Thu, Jun 10, 2010 at 3:49 PM, Peter Davies<ultratwo(a)gmail.com> wrote: > >> Some tests crash for me (eg. >> http://bugs.winehq.org/show_bug.cgi?id=22903 segfaults). This means I >> can't run the entire test suite with "make test", what should I do? >> > Assuming the tests that are crashing are not caused by a patch you > added to wine, either use 'make -k' to ignore the failure, or do, for > example: > $ touch dlls/d3d8/tests/visual.ok > to have make test skip that particular test. > I think he wants to fix them not to skip them. In that case, you should compile wine with CFLAGS="-g" ./configure Thus, you'll see relevant informations in the backtrace log (files, lines number, function parameters...) And finally running WINEDEBUG=+d3d8 ../../wine d3d8_test.exe.so visual should also display TRACE() messages.

June 11, 2010

Re: resources: Convert Polish resources to UTF8.

by Frédéric Delanoy

2010/6/11 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > >> I see this patch has been "Rejected" in >> http://source.winehq.org/patches/, but I just wondered why: >> - are the UTF8 resources not preferred over custom codepages? >> - or is the patch simply too big to review? Splitting into many tiny >> patches seemed a bit overkill for such a simple change, no? >> >> Or maybe is it simply because Polish translations is still in >> progress, and it can/will cause conflict? > > There is no point in just converting the translations. If you update > a translation, and simulataneously convert it - that's OK. > > -- > Dmitry. Well, I proposed Łukasz to use UTF8 (since it appeared to be the new standard charset) while he was updating Polish translations, but since he wasn't too comfortable with the process, I offered to do it myself, so wrote a script to check/convert files (and he tested the result). I could give him the script so he can use it when he updates a file, but I don't see the added value not to do it directly. I don't see the problem with converting files without updating a single translation: is it so regression-prone? Frédéric

June 11, 2010

Re: Updating Ukrainian translations to kernel32

by Dmitry Timoshkov

Igor Paliychuk <igor-hkr(a)mail.ru> wrote: > Updating Ukrainian translations to kernel32(ukr.nls). > file : ukrainian-kernel32-ukr-nls.patch You forgot to mention what's wrong with current ukr.nls. -- Dmitry.

June 11, 2010

Re: resources: Convert Polish resources to UTF8.

by Dmitry Timoshkov

Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > I see this patch has been "Rejected" in > http://source.winehq.org/patches/, but I just wondered why: > - are the UTF8 resources not preferred over custom codepages? > - or is the patch simply too big to review? Splitting into many tiny > patches seemed a bit overkill for such a simple change, no? > > Or maybe is it simply because Polish translations is still in > progress, and it can/will cause conflict? There is no point in just converting the translations. If you update a translation, and simulataneously convert it - that's OK. -- Dmitry.

June 11, 2010

Re: [PATCH] ntdll: Show one-time ERR if NOFILE limit is reached.

by James McKenzie

Octavian Voicu wrote: > On Sat, May 15, 2010 at 1:55 AM, Octavian Voicu > <octavian.voicu(a)gmail.com> wrote: > >> Forgot to mention, this fixes http://bugs.winehq.org/show_bug.cgi?id=19861. >> > > That bug was nominated for 1.2, but I see the patch is still pending. > Why not commit it? > AJ might have skipped over it. Can you resend noting that it fixes a bug nominated for Wine 1.2 and add the bug # to the message text? James McKenzie

June 11, 2010

Re: [1/3] d3dx9: Allow sampler declaration without sampler type.

by James McKenzie

Stefan Dösinger wrote: > Am 10.06.2010 um 18:28 schrieb Matteo Bruni: > >> That's a good objection. The shader validator errors out on these >> typeless declarations. So maybe it's not safe for us to allow them, as >> we lack the shader validator? They are also useless probably at this >> point... >> > It wasn't intended as an objection. It was mostly curiosity, because we have no test in d3d9 that checks for similar behavior, and trying to actually use such a shader for rendering would be somewhat odd. > It might be a good idea to create the test first before attempting to commit this patch. AJ probably would want this. James McKenzie

June 11, 2010

Re: size_t usage in wine

by James McKenzie

Marko Nikolic wrote: > Hi, > > I have found in wine documentation that it is recommended to avoid long data > type, since it is different in Win64 and Unix64. This is reasonable, > however, is there some similar policy regarding size_t/ssize_t usage? > > Actually, size_t should be avoided if at all possible, because different platforms implement different values for this variable type, if they do at all. James McKenzie

June 11, 2010

Re: resources: Convert Polish resources to UTF8.

by James McKenzie

Frédéric Delanoy wrote: > Hi. > > I see this patch has been "Rejected" in > http://source.winehq.org/patches/, > Could be formatted incorrectly or just basically contain invalid information (not incorrect) as the format of the patch does not include things like th #pragma line. However, I have a much better question. I track the patches to see which were applied and which were not. How can I get OLDER information on patches from previous releases? I'm truly interested in the series of patches that I have submitted and would like to get them 'out of the way' so I can move onto other items. Thank you for minding my interruption and back to the regularly scheduled Wine Development. James McKenzie

June 11, 2010

IDL trouble (patch: adding IEnumShellItems interface declaration.)

by David Hedberg

Hello everyone, I'm having some trouble with this simple patch. Specifically, it breaks compiling of dlls/actxprxy, producing the message: ***** ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. -fasynchronous-unwind-tables -shared ./actxprxy.spec usrmarshal.o actxprxy_activscp_p.o actxprxy_comcat_p.o actxprxy_docobj_p.o actxprxy_hlink_p.o actxprxy_htiframe_p.o actxprxy_objsafe_p.o actxprxy_ocmm_p.o actxprxy_servprov_p.o actxprxy_shobjidl_p.o actxprxy_urlhist_p.o dlldata.o -o actxprxy.dll.so -luuid -loleaut32 -lole32 -lrpcrt4 -lkernel32 -lntdll ../../libs/port/libwine_port.a -L/usr/local/valgrind-svn/lib actxprxy_shobjidl_p.o: In function `IEnumShellItems_RemoteNext_Stub': /home/david/Projects/wine/git/dlls/actxprxy/actxprxy_shobjidl_p.c:6507: undefined reference to `IEnumShellItems_Next_Stub' actxprxy_shobjidl_p.o:(.data.rel.ro+0xf0): undefined reference to `IEnumShellItems_Next_Proxy' ***** It compiles if I remove the [call_as] attribute, but I guess that would kind of break the interface. Any obvious mistakes in the patch, or grammar not supported by widl? Thanks, David --- include/shobjidl.idl | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/include/shobjidl.idl b/include/shobjidl.idl index 6bd0244..97cd82f 100644 --- a/include/shobjidl.idl +++ b/include/shobjidl.idl @@ -385,6 +385,36 @@ typedef enum tagNWMF { } NWMF; /***************************************************************************** + * IEnumShellItems interface + */ +[ + object, + uuid(70629033-E363-4A28-A567-0DB78006E6D7), + pointer_default(unique) +] +interface IEnumShellItems : IUnknown +{ + [local] HRESULT Next( + [in, annotation("__in")] ULONG celt, + [out, size_is(celt), length_is(*pceltFetched), annotation("__out_ecount_part(celt, *pceltFetched)")] + IShellItem **rgelt, + [out, annotation("__out_opt __deref_out_range(0, celt)")] ULONG *pceltFetched); + + [call_as(Next)] HRESULT RemoteNext( + [in] ULONG celt, + [out, size_is(celt), length_is(*pceltFetched)] IShellItem **rgelt, + [out] ULONG *pceltFetched); + + HRESULT Skip( + [in] ULONG celt); + + HRESULT Reset(); + + HRESULT Clone( + [out] IEnumShellItems **ppenum); +} + +/***************************************************************************** * FOLDERSETTINGS */ typedef char *LPVIEWSETTINGS; -- 1.7.1

June 11, 2010

Re: resources: Convert Polish resources to UTF8.

by Frédéric Delanoy

Hi. I see this patch has been "Rejected" in http://source.winehq.org/patches/, but I just wondered why: - are the UTF8 resources not preferred over custom codepages? - or is the patch simply too big to review? Splitting into many tiny patches seemed a bit overkill for such a simple change, no? Or maybe is it simply because Polish translations is still in progress, and it can/will cause conflict? I'm a bit confused here... Frédéric NB: I didn't touch any nls file in this patch so it shouldn't cause regressions (and had a subset of it tested by Łukasz Wojniłowicz, a native Polish speaker)

June 10, 2010

Re: [PATCH] ntdll: Show one-time ERR if NOFILE limit is reached.

by Octavian Voicu

On Sat, May 15, 2010 at 1:55 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > Forgot to mention, this fixes http://bugs.winehq.org/show_bug.cgi?id=19861. That bug was nominated for 1.2, but I see the patch is still pending. Why not commit it? I tested the fix briefly by lowering ulimit -n and the message is triggered. On the other hand, a ridiculously low value for ulimit -n gives weird errors -- there's nothing we can do about those. There might be some other places where the EMFILE error could be triggered, but having it just in CreateFile is a pretty good heuristic imho. Do we want to give more info on how to fix this, maybe point to a wiki page? Octavian

June 10, 2010

Re: [1/3] d3dx9: Allow sampler declaration without sampler type.

by Stefan Dösinger

Am 10.06.2010 um 18:28 schrieb Matteo Bruni: > That's a good objection. The shader validator errors out on these > typeless declarations. So maybe it's not safe for us to allow them, as > we lack the shader validator? They are also useless probably at this > point... It wasn't intended as an objection. It was mostly curiosity, because we have no test in d3d9 that checks for similar behavior, and trying to actually use such a shader for rendering would be somewhat odd. The patch is fine, and we should have the same behavior as Windows. If a game fails because the validator doesn't complain then the bug is the missing validator, not the assembler that behaves correctly.

June 10, 2010

Re: Tests crash

by Austin English

On Thu, Jun 10, 2010 at 3:49 PM, Peter Davies <ultratwo(a)gmail.com> wrote: > Some tests crash for me (eg. > http://bugs.winehq.org/show_bug.cgi?id=22903 segfaults). This means I > can't run the entire test suite with "make test", what should I do? Assuming the tests that are crashing are not caused by a patch you added to wine, either use 'make -k' to ignore the failure, or do, for example: $ touch dlls/d3d8/tests/visual.ok to have make test skip that particular test. -- -Austin

June 10, 2010

Tests crash

by Peter Davies

Some tests crash for me (eg. http://bugs.winehq.org/show_bug.cgi?id=22903 segfaults). This means I can't run the entire test suite with "make test", what should I do? Peter

June 10, 2010

Re: [1/3] d3dx9: Allow sampler declaration without sampler type.

by Matteo Bruni

2010/6/10 Stefan Dösinger <stefandoesinger(a)gmx.at>: > > Am 10.06.2010 um 16:06 schrieb Matteo Bruni: >> <0001-d3dx9-Allow-sampler-declaration-without-sampler-type.txt> > The patch looks ok, but I am wondering if the validator complains about typeless samplers. And if not, I guess the interesting question is how those declarations are treated at shader runtime... > That's a good objection. The shader validator errors out on these typeless declarations. So maybe it's not safe for us to allow them, as we lack the shader validator? They are also useless probably at this point...

June 10, 2010

"IWineGDISurfaceImpl_UnLoad: Please report to wine-devel"

by Marcin Baczyński

Hi, running a simple game on wine-1.2-rc2-250-g950919e fails with "Interface not supported" message box and following messages in the terminal: $ ./wine ~/.wine/drive_c/Program\ Files/MarBit/Clicks/clicks.exe fixme:dsalsa:IDsDriverBufferImpl_SetVolumePan (0x146740,0x146b78): stub fixme:win:EnumDisplayDevicesW ((null),0,0x32f480,0x00000000), stub! fixme:d3d:swapchain_init Add OpenGL context recreation support to context_validate_onscreen_formats err:d3drm:IDirect3DRMImpl_QueryInterface (0x135678)->({4516ecc8-8f20-11d0-9b6d-0000c0781bc3},0x5a2e90),not found err:d3d_surface:IWineGDISurfaceImpl_UnLoad (0x137d70): UnLoad is not supported on X11 surfaces! err:d3d_surface:IWineGDISurfaceImpl_UnLoad (0x137d70): Most likely the parent library did something wrong. err:d3d_surface:IWineGDISurfaceImpl_UnLoad (0x137d70): Please report to wine-devel fixme:d3d:IWineD3DDeviceImpl_Release (0x1e7a20) Device released with resources still bound, acceptable but unexpected fixme:d3d:IWineD3DDeviceImpl_Release Leftover resource 0x137d70 with type WINED3DRTYPE_SURFACE (0x1). The game can be downloaded here: http://marbit.com.pl/index.php?name=Downloads&req=getit&lid=1 Installation fails saying that it cannot create a shortcut, but the files get copied to the destination directory. Thanks, Marcin

June 10, 2010

Re: [1/3] d3dx9: Allow sampler declaration without sampler type.

by Stefan Dösinger

Am 10.06.2010 um 16:06 schrieb Matteo Bruni: > <0001-d3dx9-Allow-sampler-declaration-without-sampler-type.txt> The patch looks ok, but I am wondering if the validator complains about typeless samplers. And if not, I guess the interesting question is how those declarations are treated at shader runtime...

June 10, 2010

Re: winefile: Update English resource for AUS, NZ and UK

by Michael Stefaniuc

Hello Ken, Ken Sharp wrote: > Australian, British and New Zealand English prefers -ise over -ize > (strongly so in Aus and NZ). > > http://en.wikipedia.org/wiki/En-AU#Spelling > http://en.wikipedia.org/wiki/New_Zealand_English#Spelling if the translation is the same for UK, AU and NZ then please add only one copy of it and mark it as LANGUAGE LANG_ENGLISH, SUBLANG_NEUTRAL That will do as the LANG_ENGLISH family will inherit first from SUBLANG_NEUTRAL and only if that doesn't exist from SUBLANG_DEFAULT. thanks bye michael

June 10, 2010

size_t usage in wine

by Marko Nikolic

Hi, I have found in wine documentation that it is recommended to avoid long data type, since it is different in Win64 and Unix64. This is reasonable, however, is there some similar policy regarding size_t/ssize_t usage? Those types are often defined as long type, so they could produce the same problem with 64 bit. On the other hand, many standard functions expect or return size_t values, so I guess it could be ok to use it in such cases. Is there any advice/position on this? Thanks, Marko

June 10, 2010

Re: A Handle Cache?

by Vitaliy Margolen

On 06/09/2010 04:54 PM, Max TenEyck Woodbury wrote: > While Reading the developer's guide, I noticed that it said that > translating windows' handles was always done by the server. I may have > misunderstood this. Since interaction between the client and server > requires at least two context switches and context switches are fairly > heavy duty operations, would it make sense to cache handle lookups on > the client? You haven't read all the manual it seems. Wine already does cache file descriptors - the only piece of information related to handles that clients can cache. Everything else is inter-process and can't be cached / handled in client. Vitaliy.

June 10, 2010

A Handle Cache?

by Max TenEyck Woodbury

While Reading the developer's guide, I noticed that it said that translating windows' handles was always done by the server. I may have misunderstood this. Since interaction between the client and server requires at least two context switches and context switches are fairly heavy duty operations, would it make sense to cache handle lookups on the client?

June 9, 2010

Re: gameux.dll implementation stub

by Rico Schüller

Am 08.06.2010 12:56, schrieb Mariusz Pluciński: > Hello > As you maybe know, I'm working on implementation of Game Explorer in > the Google Summer of Code. Main part of my work is now implementing > gaming APIs stored in gameux.dll library. I already sent patches > with headers, and I'm currently in the stage when stubs are ready to > start real implementation. > > Unfortunately (for me) Wine is now in freeze stage, so I can't send > patches with new library to wine-patches. Instead, Vincent Povirk > suggested me to send them here to get feedback. It's very important > to me to know is my way of implementation valid, cause changing > something now is probably easier than modifying it in future. > > Attached patches creates initial implementation of gameux library, > adds implementation of IClassFactory interface and stubs of > four interfaces' implementations: IGameExplorer, IGameExplorer2, > IGameStatistics and IGameStatisticsMgr. They also add initial > tests for each interface. Each test now checks behavior of > CoCreateInstance function while trying to create given interface. > > To create library, I used parts of code created by Alistair > Leslie-Hughes, attached by him to bug 21261. > > Thanks in advance > > > > Hi Mariusz, It looks like you are mixing tabs and spaces. I guess spaces are always preferred, since tabs could be equal to 4 or 8 spaces (or any other value), which could make the code less readable. Cheers Rico

June 9, 2010

Re: Call for translators

by Ricardo Filipe

hey paul, i believe i can get to them this weekend as i said. 2010/6/9 Paul Vriens <paul.vriens.wine(a)gmail.com>: > On 05/27/2010 07:37 PM, Ricardo Filipe wrote: >> >> i'm adding myself to the list atm. i'll finish the portuguese portugal >> translations next week. > > Hi Ricardo, > > Will you be able to do the translations or should we let Miguel have a go? > > -- > Cheers, > > Paul. >

June 9, 2010

Re: Call for translators

by Paul Vriens

On 05/27/2010 07:37 PM, Ricardo Filipe wrote: > i'm adding myself to the list atm. i'll finish the portuguese portugal > translations next week. Hi Ricardo, Will you be able to do the translations or should we let Miguel have a go? -- Cheers, Paul.

June 9, 2010

Re: Change a malloc() to a HeapAlloc()

by Octavian Voicu

On Wed, Jun 9, 2010 at 9:08 PM, Peter Davies <ultratwo(a)gmail.com> wrote: >> The patch is also wrong. > Why? What difference does malloc() over HeapAlloc() make? (this is arguably a > case for not sending the patch in the first place) This is because wpp_lookup_mem is only referenced in the wpp_callbacks structure, which is passed to wpp_set_callbacks. Code where callbacks are set and invoked is in libs/wpp/, which is a native library (will not compile to a dll), so it will clean up using standard free(). HeapAlloc/HeapFree should always be used in windows-based code, except when it interfaces with other code that doesn't. In any case, HeapAlloc/HeapFree and malloc/free should never be mixed up (allocate with one, free with the other). Octavian

June 9, 2010

Re: Change a malloc() to a HeapAlloc()

by Reece Dunn

On 9 June 2010 19:08, Peter Davies <ultratwo(a)gmail.com> wrote: >> We use real names here. This patch probably will not be committed until it >> is resubmitted. > Ops! I've mis-configured my mail client > >> The patch is also wrong. > Why? What difference does malloc() over HeapAlloc() make? (this is arguably a > case for not sending the patch in the first place) > > There is nothing that bugs me more than not being told why I'm wrong. Where does the allocated variable get freed? Has that been changed from free to HeapFree? Does it get realloced? - Reece

June 9, 2010

Re: [PATCH] [WinHelp]: implemented ExecFile macro (fix for #23054)

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > +static void CALLBACK MACRO_ExecFile(LPCSTR pgm, LPCSTR args, LONG cmd_show, LPCSTR topic) > { > - WINE_FIXME("(\"%s\", \"%s\", %u, \"%s\")\n", str1, str2, u, str3); > + static HINSTANCE (WINAPI *shell_exec)(HWND, LPCSTR, LPCSTR, LPCSTR, LPCSTR, INT); > + HINSTANCE ret = 0; > + > + WINE_TRACE("(\"%s\", \"%s\", %u, \"%s\")\n", pgm, args, cmd_show, topic); > + if (!shell_exec) > + { > + HANDLE h; > + > + if ((!(h = GetModuleHandle("shell32.dll")) && !(h = LoadLibraryA("shell32.dll"))) || > + !(shell_exec = (void*)GetProcAddress(h, "ShellExecuteA"))) > + { > + WINE_ERR("Couldn't load shell32.ShellExecute\n"); > + } > + } Why not call ShellExecuteA directly? -- Alexandre Julliard julliard(a)winehq.org

June 9, 2010

Re: Change a malloc() to a HeapAlloc()

by Peter Davies

> We use real names here. This patch probably will not be committed until it > is resubmitted. Ops! I've mis-configured my mail client > The patch is also wrong. Why? What difference does malloc() over HeapAlloc() make? (this is arguably a case for not sending the patch in the first place) There is nothing that bugs me more than not being told why I'm wrong. Peter

June 9, 2010

Re: Three year sever outstanding bug requiring minor fix

by James Mckenzie

velociraptor Genjix <aphidia(a)hotmail.com> wrote at Jun 9, 2010 8:52 AM > >Hey, >Please look into this issue, >http://bugs.winehq.org/show_bug.cgi?id=15118 >It seems like a fairly trivial fix which renders this application useless. A detailed >description of the implementation needed is provided in that ticket. If it were a 'trival' fix, it would have been a long time ago. Something that looks, on the surface, to be simple, maybe very complex. For instance, I have been working on a fix for one function in the richedit area has taken over four years. Now as to your concern, tough. This project, for the most part is volunteer. So, if you want it fixed, do it yourself or find someone who can. Otherwise, you'll have to wait for someone to come by, find this interesting and then fix it. There is a part of the project that is paid, and they work for a company called CodeWeavers. Maybe they have found a fix and incorporated it into their product line. That you'll have to pay for. Remember, we fix things as WE find the time and the incorporation process is very strict. This takes time and some folks will pick up a project, only to set it down because they become busy with other things in life or they just don't have the tenancity to see it through. James McKenzie

June 9, 2010

Re: Two enhancement requests for winetricks

by Steven Edwards

On Wed, Jun 9, 2010 at 3:45 AM, Dan Kegel <dank(a)kegel.com> wrote: > I suppose winetricks could create uninstaller entries for even > the little verbs... that would be the windows way of doing things. +1 for this idea. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

June 9, 2010

Re: Three year sever outstanding bug requiring minor fix

by Maarten Lankhorst

Hello Fakename, 2010/6/9 velociraptor Genjix <aphidia(a)hotmail.com>: > Hey, > Please look into this issue, > http://bugs.winehq.org/show_bug.cgi?id=15118 > It seems like a fairly trivial fix which renders this application useless. A > detailed description of the implementation needed is provided in that > ticket. > Thank you Wine is run by volunteers, you cannot tell others what to do since they work on wine voluntary. If you want the bug fixed, your best bet is to try to fix it yourself. We can likely help you if you can program in C, but just posting 'please fix this bug for me' is rude and selfish. Cheers, Maarten

June 9, 2010

Three year sever outstanding bug requiring minor fix

by velociraptor Genjix

Hey, Please look into this issue, http://bugs.winehq.org/show_bug.cgi?id=15118 It seems like a fairly trivial fix which renders this application useless. A detailed description of the implementation needed is provided in that ticket. Thank you _________________________________________________________________ http://clk.atdmt.com/UKM/go/197222280/direct/01/ Do you have a story that started on Hotmail? Tell us now

June 9, 2010

Re: How to change text on winehq.org ?

by Frédéric Delanoy

On Wed, Jun 9, 2010 at 15:28, Marco Meijer <marco(a)mandrivaclub.nl> wrote: > Hi WineDevs, > > I made the patch to change the text on winehq and sent it to wine-patches > but still no change. > Do I have to do something else ? > > link to patch: > http://www.winehq.org/pipermail/wine-patches/2010-May/088377.html > > kind regards, > > Marco Meijer Your patch seems OK to me. It probably has been forgotten for some reason. Just resend it (you may add a (resend) to the subject line as well) Frédéric

June 9, 2010

Re: How to change text on winehq.org ?

by Marco Meijer

Hi WineDevs, I made the patch to change the text on winehq and sent it to wine-patches but still no change. Do I have to do something else ? link to patch: http://www.winehq.org/pipermail/wine-patches/2010-May/088377.html kind regards, Marco Meijer http://www.winehq.org/pipermail/wine-patches/2010-May/088377.html Op 6-5-10 17:57, James Mckenzie schreef: >> Hi WineDevs, >> >> If make the packages for mandriva on sourceforge. And the text on the >> download page on the website (winehq,org) for mandriva is getting old. >> Who can I write a mail to change the text ? I already tried web-admin ad >> winehq.org some weeks ago but no reaction so far. >> >> > The source code for winehq is available. You then make the changes you feel are necessary to the source code, create a difference file and submit this to wine-patches. > > Are you familiar with this process? > > James McKenzie > > >

June 9, 2010

Re: Two enhancement requests for winetricks

by Dan Kegel

On Wed, Jun 9, 2010 at 3:03 AM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > If you implement a status feature for every trick, you can change the > main UI into a list of checkboxes, with the installed tricks already > ticked. Right, of course. I had even realized that before. I guess I was just in 'no' mode... - Dan

June 9, 2010

Re: [1/3] msi: Create directories right before installing files.

by testbot＠testbot.winehq.org

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=2538 Your paranoid android. === W7PROX64 (32 bit install) === install.c:5408: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5427: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5452: Test failed: Expected "C:\Program Files (x86)\msitest\maximus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" install.c:5471: Test failed: Expected "01\msitest\augustus", got "Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\84A88FD7F6998CE40A22FB59F6B9C2BB\InstallProperties" === W7PROX64 (64 bit install) === install.c:8261: Test failed: RegQueryValueExA failed 2 (0) install.c:9173: Test failed: got 6 expected 0 install.c:9179: Test failed: got 6 expected 0 install.c:9182: Test failed: got 6 expected 0 install.c:9184: Test failed: file removed install.c:9329: Test failed: key not created

June 9, 2010

Re: wine in the news in spain

by Octavian Voicu

On Wed, Jun 9, 2010 at 10:49 AM, Dan Kegel <dank(a)kegel.com> wrote: > Hmm, I wonder what "Presto" is, Autotranslated from www.presto.es: "Presto is the program [for] budgets, measurements, times, health and safety, quality and cost control for building and civil works more prevalent in Hispanic countries." > and which CAD suites they use. They probably use the CAD programs that are compatible with Presto, maybe from the same company that makes Presto. Anyway, they are all proprietary and they don't even have demos, so don't see them working very soon unless it happens after fixing other applications that happen to have the same problems. Octavian

June 9, 2010

Re: Two enhancement requests for winetricks

by Octavian Voicu

On Wed, Jun 9, 2010 at 9:35 AM, Dan Kegel <dank(a)kegel.com> wrote: > If you or anyone else wants to submit patches to implement a way to > uninstall things, please go ahead. The user interface would be a challenge, > though. I'd rather not have an uninstall verb for each regular verb. If you implement a status feature for every trick, you can change the main UI into a list of checkboxes, with the installed tricks already ticked. Any change in tick state would result in the installation/uninstallation of that trick. After clicking ok, you would get a summary of the actions before proceeding: tricks to be installed and tricks to be uninstalled . Octavian

June 9, 2010

Re: Change a malloc() to a HeapAlloc()

by Henri Verbeet

On 9 June 2010 05:42, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > We use real names here. This patch probably will not be committed until it > is resubmitted. > The patch is also wrong.

June 9, 2010

wine in the news in spain

by Dan Kegel

Saw this just now: http://www.osor.eu/news/es-zaragozas-move-to-complete-open-source-desktop-g… "Zaragoza's move to complete open source desktop going to plan by Gijs Hillenius — published on Jun 08, 2010 The move by the city of Zaragoza to an open source desktop is making good progress. All of the city's civil servants now use open source tools including Thunderbird, VLC, Firefox and OpenOffice. And this year some seven hundred of the city's 2800 desktop PCs will have seen their proprietary operating system replaced by the Linux open source alternative. ... "It is not possible to move all applications to the open source platform. For example tools for Computer Aided Design and Optical Character Recognition, can't be replaced by open source alternatives. But proprietary and open source software can live together. And if we really can't find an open source option, we resort to Virtualbox and Wine to provide users their proprietary application." ... Their web site does mention a bit about wine, too: http://zaragozaciudad.net/azlinux/2009/septiembre.php (autotranslated): "24/09/2009 How we use WINE ... Microsoft Access: Access we have hundreds of applications that lack of time and means we can not migrate to an Open Source environment. WINE can emulate many of them even though the code should be reviewed, compiled and compacted again. A particular case is still unresolved are the Access applications that generate a mail merge with Word documents. OCR: for now we have not found an efficient alternative to the use of OCR software that "emulate" Windows OCR software with WINE Transactional environment: the client for our transactional environment is old and only works for Windows environments so that the use of WINE has been indispensable In contrast we must also say that some applications could not be emulated with WINE as Presto or Nokia PC Suite. So far WINE has not been useful to emulate CAD applications. In conclusion we can say that WINE is a useful tool in some cases and allows us to move forward in the migration to Open Source environment as alternatives to proprietary software are available and the height of these." Hmm, I wonder what "Presto" is, and which CAD suites they use. - Dan

June 9, 2010

Re: Two enhancement requests for winetricks

by Dan Kegel

On Wed, Jun 9, 2010 at 12:41 AM, Tom Wickline <twickline(a)gmail.com> wrote: > $ wine uninstaller ? > > Everything wont be listed in the uninstaller, single dll's and font changes > wont be listed. > The unistaller could maybe be used for Firefox, Steam etc.. I suppose winetricks could create uninstaller entries for even the little verbs... that would be the windows way of doing things.

June 9, 2010

Re: Two enhancement requests for winetricks

by Tom Wickline

On Wed, Jun 9, 2010 at 2:35 PM, Dan Kegel <dank(a)kegel.com> wrote: > > If you or anyone else wants to submit patches to implement a way to > uninstall things, please go ahead. The user interface would be a > challenge, > though. I'd rather not have an uninstall verb for each regular verb. > - Dan > > $ wine uninstaller ? Everything wont be listed in the uninstaller, single dll's and font changes wont be listed. The unistaller could maybe be used for Firefox, Steam etc.. Tom

June 9, 2010

Re: Two enhancement requests for winetricks

by Dan Kegel

On Tue, Jun 8, 2010 at 11:09 PM, Jan Hoogenraad <jan-winehq(a)h-i-s.nl> wrote: >> http://code.google.com/p/winezeug/issues/detail?id=127 "want uninstall" > > Could this useage (use winetricks ONLY on a relatively empty .wine directory > to troubleshoot) be documented on every place in the winetricks > documentation directories ? That's not quite true; it works perfectly fine on big .wine directories. It's just that they're not such a great idea, each additional thing you install has a chance to screw up the things already installed, and that has nothing to do with winetricks. > This is not the way the documentation feels at: > http://wiki.winehq.org/winetricks > > e.g. a short point explaining this, and that there is NO way to remove > winetricks will help here. OK, I added a note about it towards the bottom of the page. > At this point, even the Ubuntu standard wine packaging includes winetricks. > This leaves end-users with the impression that they are integral part of > wine, and thus maintained. Winetricks is maintained; the lack of uninstall doesn't mean it's unmaintained. > Wine has been maturing. > I now have a stable Windows environment, which required a few winetricks a > year ago. This was then reasonable. > I really will not anymore remove the .wine directory to delete all installed > applications including keys & settings. > > If I can help with starting an uninstaller, I am willing to put in some > time: A helpful step for me as a user would be to begin with a few cases > that can simply be implemented (e.g. cc580, which I could remove recently > due to a bug fix). > > I also see some application-like entries (7zip, firefox, gecko, python, vlc, > wmp) where the package uninstaller may work. If you or anyone else wants to submit patches to implement a way to uninstall things, please go ahead. The user interface would be a challenge, though. I'd rather not have an uninstall verb for each regular verb. - Dan

June 9, 2010

Re: Two enhancement requests for winetricks

by Jan Hoogenraad

Thanks a lot. Regarding your comment on id=127 "want uninstall": Could this useage (use winetricks ONLY on a relatively empty .wine directory to troubleshoot) be documented on every place in the winetricks documentation directories ? This is not the way the documentation feels at: http://wiki.winehq.org/winetricks e.g. a short point explaining this, and that there is NO way to remove winetricks will help here. At this point, even the Ubuntu standard wine packaging includes winetricks. This leaves end-users with the impression that they are integral part of wine, and thus maintained. Wine has been maturing. I now have a stable Windows environment, which required a few winetricks a year ago. This was then reasonable. I really will not anymore remove the .wine directory to delete all installed applications including keys & settings. If I can help with starting an uninstaller, I am willing to put in some time: A helpful step for me as a user would be to begin with a few cases that can simply be implemented (e.g. cc580, which I could remove recently due to a bug fix). I also see some application-like entries (7zip, firefox, gecko, python, vlc, wmp) where the package uninstaller may work. Dan Kegel wrote: > OK, filed > http://code.google.com/p/winezeug/issues/detail?id=127 "want uninstall" > and > http://code.google.com/p/winezeug/issues/detail?id=128 "want status" > - Dan > -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht

June 9, 2010

Re: Change a malloc() to a HeapAlloc()

by James McKenzie

Ultra two wrote: > --- > We use real names here. This patch probably will not be committed until it is resubmitted. James McKenzie

June 9, 2010

Two enhancement requests for winetricks

by Dan Kegel

OK, filed http://code.google.com/p/winezeug/issues/detail?id=127 "want uninstall" and http://code.google.com/p/winezeug/issues/detail?id=128 "want status" - Dan

June 9, 2010

Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel

by Joel Holdsworth

> > Does it fix a bug? If not, AJ may have placed it aside until after Wine 1.2 > > is released. > > Indeed. Adding new strings to translate will/should probably have to > wait until after Wine 1.2, so we can get as many languages as possible > at 100% when 1.2 is released. > > OTOH, if it new strings fix a problem, then go for it. The patch doesn't add any new strings - just modifies the dialog layout: http://www.airwebreathe.org.uk/space/new-about-screen.png . I'm trying to give the about panel a degree of graphical polish in time for the release.

June 8, 2010

Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel

by Joel Holdsworth

> It says apply failure for 3/3, so that's probably why 2/3 wasn't committed also. > > Problem is that there are a lot of translation updates these days and > some patches affect winecfg .rc files. I guess you should rebase on > git head and resend patch. However, I see there is still one patch on > the pipe that affects Es.rc from winecfg, so that might again cause > some problems. > > Octavian Ok, I've rebased now, fixed up the problems, and resubmitted.

June 8, 2010

Two enhancement requests for winetricks

by Jan Hoogenraad

I cannot access the login to Google (Google won't let me for some technical reason) , into http://code.google.com/p/winezeug/issues/list so I use this mail list to report 2 enhancement requests 1) Can winetricks also include a REMOVE script for each of the tricks ? It seems that a user is now advised to remove some (for the user often illogical) files in the windows directories. This is error prone, and lags the nice installation interface. 2) Can winetricks also include a status check for each of the tricks ? This could be as simple as checking if the files provided by wine have the latest wine time stamp and/or version signature. Alternately, a list of installed (by the UI selected) tricks can be provided. Each debugging request for wine states that I should remove all winetricks. However I have no way to tell, and no way to safely remove them. For example, my ~/.wine/drive_c/windows/sys*/* contains the files below, for which I suspect a wine trick, based on the time stamp. However, they may also be installed by some piece of windows software that I have installed. Thus, simply removing them does not make sense to me. Could somebody file this request in the issue database for me ? ------------------- 1032 2010-04-25 12:00 system32/ngen.exe 10204 2010-04-25 12:00 system32/view.exe 210420 2010-04-25 12:00 system32/cmdlgtst.exe 924432 2008-10-06 23:30 system32/MFC40.DLL 499712 2008-10-06 23:30 system32/msvcp71.dll 348160 2008-10-06 23:30 system32/msvcr71.dll 326656 2008-10-06 23:30 system32/MSVCRT40.DLL 492304 2008-10-06 23:30 system32/OLEAUT32.DLL 258352 2008-10-06 23:30 system32/unicows.dll 21936 2008-10-06 23:30 system32/help.exe 995383 2008-10-06 23:30 system32/MFC42.DLL 70656 2008-10-06 23:30 system32/MSVCIRT.DLL 195124 2008-10-06 23:30 system32/wcmd.exe 322832 2008-10-06 23:30 system/mfc30.dll 921872 2008-10-06 23:30 system/mfc40.dll 696 2003-12-04 16:07 system32/jetodbc.rsp 60224 2003-12-03 09:56 system32/odbcji32.dll 621104 2003-12-02 15:00 system32/mswstr10.dll 158256 2003-12-02 14:59 system32/msjint40.dll 354864 2003-11-12 13:17 system32/msjetoledb40.dll 559656 2003-11-12 13:17 system32/msrepl40.dll 326184 2003-11-12 13:16 system32/msexcl40.dll 1514024 2003-11-12 13:16 system32/msjet40.dll 354856 2003-11-12 13:16 system32/mspbde40.dll 285224 2003-11-12 13:16 system32/odbcjt32.dll 248360 2003-11-12 13:16 system32/msjtes40.dll 354856 2003-11-12 13:16 system32/msxbde40.dll 264744 2003-11-12 13:16 system32/mstext40.dll 27464 2003-11-12 13:15 system32/odexl32.dll 27464 2003-11-12 13:15 system32/odtext32.dll 27464 2003-11-12 13:15 system32/oddbse32.dll 27464 2003-11-12 13:15 system32/odfox32.dll 27464 2003-11-12 13:15 system32/odpdx32.dll 838240 2003-06-02 10:15 system32/mswdat10.dll 518752 2003-06-02 10:15 system32/msexch40.dll 428640 2003-06-02 10:15 system32/msrd2x40.dll 387680 2003-06-02 10:14 system32/expsrv.dll 322144 2003-06-02 10:14 system32/msrd3x40.dll 219744 2003-06-02 10:14 system32/msltus40.dll 60000 2003-06-02 10:14 system32/msjter40.dll 37472 2003-06-02 10:14 system32/vbajet32.dll 322832 2000-02-29 02:39 system32/MFC30.DLL -- Jan Hoogenraad

June 8, 2010

Re: gameux.dll implementation stub

by Vincent Povirk

+HRESULT IGameExplorer_create(IUnknown *pUnkOuter, REFIID riid, LPVOID *ppObj) +{ + TRACE("(%p, %s, %p)\n", pUnkOuter, debugstr_guid(riid), ppObj); + + if( IsEqualIID( riid, &IID_IGameExplorer )) This won't work if the caller asks for IUnknown. In general, if you get a REFIID and void**, you should use QueryInterface so the logic for getting an interface to your object is in one place. +static HRESULT WINAPI GameExplorerImpl_VerifyAccess(IGameExplorer *iface, + BSTR sGDFBinaryPath, BOOL *pHasAccess) +{ + TRACE("(%p, %s, %p)\n", iface, debugstr_w(sGDFBinaryPath), pHasAccess); + FIXME("stub\n"); + *pHasAccess = TRUE; + MESSAGE("returning value: %d\n", *pHasAccess); + /*return E_NOTIMPL;*/ + return S_OK; +} The MESSAGE() call is a bit odd. That should probably be a TRACE(). You seem to have some FIXME()s in calls that look fully implemented to me, such as DllMain() and your object constructors. There's an official description of the debug levels here (although not everyone strictly follows them): http://www.winehq.org/docs/winedev-guide/debugging#DBG-CLASSES Your implementation of IGameStatistics appears to be impossible to create when it's added. You should probably wait and add it when you implement GetGameStatistics. Your IGameExplorer and IGameExplorer2 objects should be combined into one implementation. One should be able to query that object for either interface. Since IGameExplorer2 is based on IGameExplorer, they can both use the same vtable (just like IUnknown can use any COM object vtable). This will be much simpler if you use QueryInterface in your class constructor.

June 8, 2010

Re: gameux.dll implementation stub

by James Mckenzie

Mariusz Pluciński <vshader(a)gmail.com> wrote at Jun 8, 2010 6:56 AM > >Hello Greetings. >As you maybe know, I'm working on implementation of Game Explorer in >the Google Summer of Code. Main part of my work is now implementing >gaming APIs stored in gameux.dll library. I already sent patches >with headers, and I'm currently in the stage when stubs are ready to >start real implementation. > To prevent some of us out here from thinking you sent your patches to the wrong place, could you preface the subject of your messages like this one with RFC: That will allow us to run the patches and look closely at them to give them a critical review. Also, you can still submit your patches, it looks like Alexandre committed the first two and might commit the remaining three you submitted. Lastly, it looks like Release Candidate three for Wine 1.2 will be out on Friday and this may be the last one before the final release. James McKenzie

June 8, 2010

Re: Implement ID3DXConstantTable::GetConstantDesc

by Matijn Woudt

On Tue, Jun 8, 2010 at 3:09 PM, Marvin <testbot(a)testbot.winehq.org> wrote: > 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=2526 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed > This one should be patch 4/4, then it will build correctly. Do I have to resend this one as 4/4 or do I have to resend the whole series?

June 8, 2010

Re: Implement ID3DXConstantTable::GetConstantDesc

by testbot＠testbot.winehq.org

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=2526 Your paranoid android. === WINEBUILD (build) === Patch failed

June 8, 2010

Re: msvcrt printf test failed on NT4,win95

by Alexander Scott-Johns

On 8 June 2010 00:56, Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> wrote: > Thomas, > > On 7 June 2010 20:04, Thomas Heckel <thomas.heckel(a)gmx.net> wrote: >> Hi Alexander, >> >> I was wondering why your patch b205fd8108eca2fd29705875e53ed852f56a6b6d >> "Proberly skip if functions are not available" made test errors on NT4 >> and Win95 test instead of a skip while it works on newer windows >> platforms as expected. > > I have no idea. > > I can't see the real difference between tests/printf.c and (say) > tests/locale.c: both use win_skip, but printf.c fails and locale.c > works. Maybe it's the _CRT_NON_CONFORMING_SWPRINTFS define? All, Could someone test the attached patch on Win95 or NT4, please? I want to see if it makes the tests fail. Best regards, Alex Scott-Johns PS: make crosstest doesn't work for me: ~/wine-git/dlls/msvcrt/tests$ make crosstest i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -DWINE_STRICT_PROTOTYPES -DWINE_CROSSTEST -I/home/user/include -g -O0 -o locale.cross.o locale.c ../../../tools/winegcc/winegcc -b i586-mingw32msvc -B../../../tools/winebuild --sysroot=../../.. --lib-suffix=.cross.a cpp.cross.o data.cross.o dir.cross.o environ.cross.o file.cross.o headers.cross.o heap.cross.o locale.cross.o misc.cross.o printf.cross.o scanf.cross.o signal.cross.o string.cross.o time.cross.o testlist.cross.o -o msvcrt_crosstest.exe -lkernel32 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -lwinecrt0 collect2: ld returned 1 exit status winegcc: i586-mingw32msvc-gcc failed make: *** [msvcrt_crosstest.exe] Error 2 ~/wine-git/dlls/msvcrt/tests$

June 8, 2010

Re: kernel32: CopyFile cannot overwrite a file with itself (try 2)

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * kernel32: CopyFile cannot overwrite a file with itself This breaks a number of things, particularly msi. It would need much more detailed tests. -- Alexandre Julliard julliard(a)winehq.org

June 8, 2010

Re: regedit: use binary mode when doing file import/export (try 2)

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > Changelog: > * regedit: use binary mode when doing file import/export I don't think it will work properly for output. -- Alexandre Julliard julliard(a)winehq.org

June 8, 2010

gameux.dll implementation stub

by Mariusz Pluciński

Hello As you maybe know, I'm working on implementation of Game Explorer in the Google Summer of Code. Main part of my work is now implementing gaming APIs stored in gameux.dll library. I already sent patches with headers, and I'm currently in the stage when stubs are ready to start real implementation. Unfortunately (for me) Wine is now in freeze stage, so I can't send patches with new library to wine-patches. Instead, Vincent Povirk suggested me to send them here to get feedback. It's very important to me to know is my way of implementation valid, cause changing something now is probably easier than modifying it in future. Attached patches creates initial implementation of gameux library, adds implementation of IClassFactory interface and stubs of four interfaces' implementations: IGameExplorer, IGameExplorer2, IGameStatistics and IGameStatisticsMgr. They also add initial tests for each interface. Each test now checks behavior of CoCreateInstance function while trying to create given interface. To create library, I used parts of code created by Alistair Leslie-Hughes, attached by him to bug 21261. Thanks in advance

June 8, 2010

Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel

by Frédéric Delanoy

On Tue, Jun 8, 2010 at 03:41, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Joel Holdsworth wrote: >> >> On Wed, 2010-06-02 at 23:56 +0100, Joel Holdsworth wrote: >> >>> >>> Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk> >>> --- >>> programs/winecfg/Bg.rc | 19 +++++---- >>> >>> >> >> Any thoughts about this patch? I guess there's a reason why 1/3 was >> merged but not 2/3 and 3/3. Anything I can fix? >> > Does it fix a bug? If not, AJ may have placed it aside until after Wine 1.2 > is released. Indeed. Adding new strings to translate will/should probably have to wait until after Wine 1.2, so we can get as many languages as possible at 100% when 1.2 is released. OTOH, if it new strings fix a problem, then go for it. Frédéric

June 8, 2010

Making AppDB look nice

by Alexandru Băluț

Hi, I think the AppDB pages look bad, and I want to spend some time to make them look better. For example: - In the page that shows a version of an application, the background color in the list of test results depends on the rating of each test result, and it looks very messy, that rating color should be used somehow only in the Rating column. - More generally, get rid of the colored gray background colors, and eventually use discrete alternate colors like Bugzilla when listing bugs. - Get rid of the whole-row clicking, for example in the Top-10 tables in the first page, because it works weird when you middle-click. (This is more than improving looks, but still, it's on my TODO list) If you have specific suggestions on how to make the AppDB pages look better, and consistent with the rest of the winehq sites, please tell me. Thanks, Alex

June 8, 2010

Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel

by Octavian Voicu

On Tue, Jun 8, 2010 at 1:17 AM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > Any thoughts about this patch? I guess there's a reason why 1/3 was > merged but not 2/3 and 3/3. Anything I can fix? It says apply failure for 3/3, so that's probably why 2/3 wasn't committed also. Problem is that there are a lot of translation updates these days and some patches affect winecfg .rc files. I guess you should rebase on git head and resend patch. However, I see there is still one patch on the pipe that affects Es.rc from winecfg, so that might again cause some problems. Octavian

June 8, 2010

Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel

by James McKenzie

Joel Holdsworth wrote: > On Wed, 2010-06-02 at 23:56 +0100, Joel Holdsworth wrote: > >> Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk> >> --- >> programs/winecfg/Bg.rc | 19 +++++---- >> >> > > Any thoughts about this patch? I guess there's a reason why 1/3 was > merged but not 2/3 and 3/3. Anything I can fix? > > Does it fix a bug? If not, AJ may have placed it aside until after Wine 1.2 is released.

June 8, 2010

Re: msvcrt printf test failed on NT4,win95

by Alexander Scott-Johns

Thomas, On 7 June 2010 20:04, Thomas Heckel <thomas.heckel(a)gmx.net> wrote: > Hi Alexander, > > I was wondering why your patch b205fd8108eca2fd29705875e53ed852f56a6b6d > "Proberly skip if functions are not available" made test errors on NT4 > and Win95 test instead of a skip while it works on newer windows > platforms as expected. I have no idea. I can't see the real difference between tests/printf.c and (say) tests/locale.c: both use win_skip, but printf.c fails and locale.c works. Maybe it's the _CRT_NON_CONFORMING_SWPRINTFS define? > Could this be the case because GetModuleHandle and these failing > platforms are not widechar compatible? So maybe it needs using > GetModuleHandleA? No -- GetModuleHandle expands to GetModuleHandleA here. And I think nt4 is a Unicode platform anyway. > kind regards > Thomas Best regards, Alex Scott-Johns

June 7, 2010

Re: Track the number of audio bytes played as a 64 bit number

by Maarten Lankhorst

Hello Dmitry, 2010/6/7 Dmitry Baryshev <ksquirrel.iv(a)gmail.com>: > Make wine-1.1.43 track the number of audio bytes played as a 64 bit number > rather than a 32 bit number to avoid overflows. It may happen happen on > constantly used audio content, possibly causing inbound voice to stop > working > in some voice applications. Please send patches in the format "module: Description", and your patch mangled the tabs in winealsa :) Likely other patches are affected too. Cheers, Maarten

June 7, 2010

Re: [PATCH 3/3] winecfg: Cosmetic improvements to the about panel

by Joel Holdsworth

On Wed, 2010-06-02 at 23:56 +0100, Joel Holdsworth wrote: > Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk> > --- > programs/winecfg/Bg.rc | 19 +++++---- > programs/winecfg/Cs.rc | 19 +++++---- > programs/winecfg/Da.rc | 19 +++++---- > programs/winecfg/De.rc | 19 +++++---- > programs/winecfg/En.rc | 19 +++++---- > programs/winecfg/Es.rc | 19 +++++---- > programs/winecfg/Fi.rc | 19 +++++---- > programs/winecfg/Fr.rc | 19 +++++---- > programs/winecfg/Hu.rc | 19 +++++---- > programs/winecfg/It.rc | 19 +++++---- > programs/winecfg/Ja.rc | 19 +++++---- > programs/winecfg/Ko.rc | 19 +++++---- > programs/winecfg/Lt.rc | 19 +++++---- > programs/winecfg/Nl.rc | 19 +++++---- > programs/winecfg/No.rc | 19 +++++---- > programs/winecfg/Pl.rc | 19 +++++---- > programs/winecfg/Pt.rc | 32 +++++++------- > programs/winecfg/Ro.rc | 19 +++++---- > programs/winecfg/Ru.rc | 19 +++++---- > programs/winecfg/Si.rc | 19 +++++---- > programs/winecfg/Sv.rc | 19 +++++---- > programs/winecfg/Tr.rc | 19 +++++---- > programs/winecfg/Zh.rc | 38 +++++++++-------- > programs/winecfg/about.c | 88 +++++++++++++++++++++++++++++++++++++++++ > programs/winecfg/idb_wine.bmp | Bin 14614 -> 0 bytes > programs/winecfg/resource.h | 7 +++- > programs/winecfg/winecfg.rc | 4 +- > 27 files changed, 342 insertions(+), 226 deletions(-) > delete mode 100644 programs/winecfg/idb_wine.bmp Any thoughts about this patch? I guess there's a reason why 1/3 was merged but not 2/3 and 3/3. Anything I can fix?

June 7, 2010

Re: msvcrt printf test failed on NT4,win95

by Paul Vriens

On 06/07/2010 09:04 PM, Thomas Heckel wrote: > Hi Alexander, > > I was wondering why your patch b205fd8108eca2fd29705875e53ed852f56a6b6d > "Proberly skip if functions are not available" made test errors on NT4 > and Win95 test instead of a skip while it works on newer windows > platforms as expected. The problem only looks to be present when run through/via winetest.exe. The testbot doesn't show any issues when only the single test is run: http://testbot.winehq.org/JobDetails.pl?Key=2505 -- Cheers, Paul.

June 7, 2010

msvcrt printf test failed on NT4,win95

by Thomas Heckel

Hi Alexander, I was wondering why your patch b205fd8108eca2fd29705875e53ed852f56a6b6d "Proberly skip if functions are not available" made test errors on NT4 and Win95 test instead of a skip while it works on newer windows platforms as expected. Could this be the case because GetModuleHandle and these failing platforms are not widechar compatible? So maybe it needs using GetModuleHandleA? kind regards Thomas

June 7, 2010

Re: Gecko64 status

by Marcus Meissner

On Mon, Jun 07, 2010 at 09:38:39AM +0200, Maarten Lankhorst wrote: > Hi Jacek, > > 2010/6/5 Jacek Caban <jacek(a)codeweavers.com>: > > Hi all, > > > > I'd like to share with you progress on gecko64. First of all, I think that > > it was never said in public, although I've been asked about it: there won't > > be gecko64 for 1.2 release. I think we will have Gecko release in the second > > half of this year it will support 64-bit, but it's not yet clear when > > exactly. We may try to do it near the next Firefox release, but time will > > show how it will work. > > > > However, it doesn't mean that nothing is going on around Wine Gecko. I've > > recently switched to mingw-w64 for 32-bit builds. I've very pleased with it. > > They are far better in co-operation, don't have senseless politics like > > mingw and their quality of headers and libraries is far better. We won't > > need to maintain fixes to build envinonment anymore. (I've been even talking > > about better co-operation between our projects, but that's OT here and I > > will report progress when there will be more to say). We're much nearer to > > allow packagers to build their own Gecko now. > > > > Back to gecko64, I've completed the first step. I have a working 64-bit > > Firefox crosscompiled with mingw-w64. See: > > https://bugzilla.mozilla.org/show_bug.cgi?id=570342 > > for details. It starts and runs on Windows. Now I wait for patches to be > > committed to Mozilla. It may take awhile :/ Before we may think about > > support for gecko64 in MSHTML, we have to fix its issues in Wine. Firefox > > is a good Gecko test and it needs to be fixed first. Unfortunately it > > currently doesn't even start. I've put a build on server in case anyone > > would like to try it: > > http://gerwazy.lo3.wroc.pl/~jcaban/wine/firefox-mingw-w64.tar.bz2 > > Volunteers on working on Wine side are very welcomed. There are also some > > other tests from Mozilla code. Note that before fixing any more > > sophisticated bug, it's worth to make sure on Windows, that the bug is in > > Wine, not in the build. All I verified is that Firefox should start and > > basic functionality works (and doesn't work on Wine). > > I cannot find it the reference for it at the moment, but I remember > that by default the stack is in memory < 4gb on 64-bits too, unless > you did something. I wish I could remember how you could override the > behavior, but this could be why it won't run in wine, but will in > windows. > > For a stack variable: > > Wine64: > &a = 0x7F9E9381FCDC > Win64: > &a = 0x22FE7C > win64_32: > &a = 0x28FF44 Is this really an issue with the above Firefox? I get a assertion in font handling on running here. Ciao, Marcus

June 7, 2010

Re: Gecko64 status

by Octavian Voicu

On Mon, Jun 7, 2010 at 10:38 AM, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > I cannot find it the reference for it at the moment, but I remember > that by default the stack is in memory < 4gb on 64-bits too, unless > you did something. I wish I could remember how you could override the > behavior, but this could be why it won't run in wine, but will in > windows. > > For a stack variable: > > Wine64: > &a = 0x7F9E9381FCDC > Win64: > &a = 0x22FE7C > win64_32: > &a = 0x28FF44 Seems stack is always at higher addresses and heap at lower ones. The only sysctl which seems to affect this is kernel.randomize_va_space, but it won't change virtual address very much. $ sudo sysctl kernel.randomize_va_space=0 kernel.randomize_va_space = 0 $ cat /proc/self/maps | grep 'stack\|heap' 0060f000-00630000 rw-p 00000000 00:00 0 [heap] 7ffffffea000-7ffffffff000 rw-p 00000000 00:00 0 [stack] $ sudo sysctl kernel.randomize_va_space=2 kernel.randomize_va_space = 2 $ cat /proc/self/maps | grep 'stack\|heap' 00b6d000-00b8e000 rw-p 00000000 00:00 0 [heap] 7fff8676f000-7fff86784000 rw-p 00000000 00:00 0 [stack] Or are you talking about a wineloader kind of option? Octavian

June 7, 2010

Re: [3/5] gameux: Add declaration of IGameStatistics interface (try 2)

by Alexandre Julliard

Mariusz Pluciński <vshader(a)gmail.com> writes: > [ > + object, > + uuid(3887C9CA-04A0-42ae-BC4C-5FA6C7721145) > + ] > + interface IGameStatistics : IUnknown > + { > + HRESULT GetCategoryTitle([in] WORD categoryIndex, > + [out, optional] LPWSTR* pTitle); > + > + HRESULT GetLastPlayedCategory([out] UINT* pCategoryIndex); > + > + HRESULT GetMaxCategories([out] WORD* pMax); > + > + HRESULT GetMaxCategoryLength([out] UINT* cch); > + > + HRESULT GetMaxNameLength([out] UINT* cch); > + > + HRESULT GetMaxStatsPerCategory([out] WORD* pMax); > + > + HRESULT GetMaxValueLength([out] UINT* cch); > + > + HRESULT GetStatistic([in] WORD categoryIndex, > + [in] WORD statIndex, > + [out, optional] LPWSTR* pName, > + [out, optional] LPWSTR* pValue); > + > + HRESULT Save([in] BOOL trackChanges); > + > + HRESULT SetCategoryTitle([in] WORD categoryIndex, > + [in] LPCWSTR title); > + > + HRESULT SetLastPlayedCategory([in] UINT categoryIndex); > + > + HRESULT SetStatistic([in] WORD categoryIndex, > + [in] WORD statIndex, > + [in, optional] LPCWSTR name, > + [in, optional] LPCWSTR value); This doesn't match the PSDK. -- Alexandre Julliard julliard(a)winehq.org

June 7, 2010

Re: advapi32: add HKCU\Software\Classes and HKLM\Software\Classes merge tests (try 3)

by testbot＠testbot.winehq.org

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=2512 Your paranoid android. === W2KPROSP4 (32 bit registry) === No test summary line found === WXPPROSP3 (32 bit registry) === Timeout

June 7, 2010

Re: advapi32: add HKCU\Software\Classes and HKLM\Software\Classes merge tests (try 2)

by testbot＠testbot.winehq.org

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=2510 Your paranoid android. === WNT4WSSP6 (32 bit registry) === registry.c:2003: Test failed: could not open user class key, error 2 === W2KPROSP4 (32 bit registry) === No test summary line found === WXPPROSP3 (32 bit registry) === Timeout

June 7, 2010

Re: kernel32: CopyFile cannot overwrite a file with itself

by testbot＠testbot.winehq.org

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=2509 Your paranoid android. === W98SE (32 bit file) === file.c:603: Test failed: copying a file to itself didn't fail (ret=0, err=80)

June 7, 2010

Re: advapi32: add HKCU\Software\Classes and HKLM\Software\Classes merge tests

by testbot＠testbot.winehq.org

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=2508 Your paranoid android. === WNT4WSSP6 (32 bit registry) === registry.c:2003: Test failed: could not open user class key, error 2 registry.c:2009: Test failed: could not create guid key, error 6 === W2KPROSP4 (32 bit registry) === No test summary line found === WXPPROSP3 (32 bit registry) === Timeout

June 7, 2010

Re: Gecko64 status

by Marcus Meissner

On Mon, Jun 07, 2010 at 12:05:09PM +0200, Jacek Caban wrote: > On 6/7/10 11:41 AM, Marcus Meissner wrote: > >On Sat, Jun 05, 2010 at 09:58:03PM +0200, Jacek Caban wrote: > >>Hi all, > >> > >>I'd like to share with you progress on gecko64. First of all, I > >>think that it was never said in public, although I've been asked > >>about it: there won't be gecko64 for 1.2 release. I think we will > >>have Gecko release in the second half of this year it will support > >>64-bit, but it's not yet clear when exactly. We may try to do it > >>near the next Firefox release, but time will show how it will work. > >> > >> > >>Any comments and suggestions are welcomed. > >It wants MSVCP100.DLL here. Where do I get that :( > > That's strange, it surely shouldn't, mingw doesn't use msvcp*.dll. I > guess you're running my build on Windows? Please make sure you don't > have any other instance of Firefox running. I confused your build with the Mozilla.org Win64 build ... sorry. Ciao, Marcus

June 7, 2010

Re: Gecko64 status

by Jacek Caban

On 6/7/10 11:41 AM, Marcus Meissner wrote: > On Sat, Jun 05, 2010 at 09:58:03PM +0200, Jacek Caban wrote: > >> Hi all, >> >> I'd like to share with you progress on gecko64. First of all, I >> think that it was never said in public, although I've been asked >> about it: there won't be gecko64 for 1.2 release. I think we will >> have Gecko release in the second half of this year it will support >> 64-bit, but it's not yet clear when exactly. We may try to do it >> near the next Firefox release, but time will show how it will work. >> >> >> Any comments and suggestions are welcomed. >> > It wants MSVCP100.DLL here. Where do I get that :( > That's strange, it surely shouldn't, mingw doesn't use msvcp*.dll. I guess you're running my build on Windows? Please make sure you don't have any other instance of Firefox running. Jacek

June 7, 2010

Re: Gecko64 status

by Nikolay Sivov

On 6/7/2010 13:41, Marcus Meissner wrote: > It wants MSVCP100.DLL here. Where do I get that :( > > Ciao, Marcus > Does it come with VS 2010? I see no runtime redistributable for it available.

June 7, 2010

Re: Gecko64 status

by Marcus Meissner

On Sat, Jun 05, 2010 at 09:58:03PM +0200, Jacek Caban wrote: > Hi all, > > I'd like to share with you progress on gecko64. First of all, I > think that it was never said in public, although I've been asked > about it: there won't be gecko64 for 1.2 release. I think we will > have Gecko release in the second half of this year it will support > 64-bit, but it's not yet clear when exactly. We may try to do it > near the next Firefox release, but time will show how it will work. > > > Any comments and suggestions are welcomed. It wants MSVCP100.DLL here. Where do I get that :( Ciao, Marcus

June 7, 2010

Re: Gecko64 status

by Maarten Lankhorst

Hi Jacek, 2010/6/5 Jacek Caban <jacek(a)codeweavers.com>: > Hi all, > > I'd like to share with you progress on gecko64. First of all, I think that > it was never said in public, although I've been asked about it: there won't > be gecko64 for 1.2 release. I think we will have Gecko release in the second > half of this year it will support 64-bit, but it's not yet clear when > exactly. We may try to do it near the next Firefox release, but time will > show how it will work. > > However, it doesn't mean that nothing is going on around Wine Gecko. I've > recently switched to mingw-w64 for 32-bit builds. I've very pleased with it. > They are far better in co-operation, don't have senseless politics like > mingw and their quality of headers and libraries is far better. We won't > need to maintain fixes to build envinonment anymore. (I've been even talking > about better co-operation between our projects, but that's OT here and I > will report progress when there will be more to say). We're much nearer to > allow packagers to build their own Gecko now. > > Back to gecko64, I've completed the first step. I have a working 64-bit > Firefox crosscompiled with mingw-w64. See: > https://bugzilla.mozilla.org/show_bug.cgi?id=570342 > for details. It starts and runs on Windows. Now I wait for patches to be > committed to Mozilla. It may take awhile :/ Before we may think about > support for gecko64 in MSHTML, we have to fix its issues in Wine. Firefox > is a good Gecko test and it needs to be fixed first. Unfortunately it > currently doesn't even start. I've put a build on server in case anyone > would like to try it: > http://gerwazy.lo3.wroc.pl/~jcaban/wine/firefox-mingw-w64.tar.bz2 > Volunteers on working on Wine side are very welcomed. There are also some > other tests from Mozilla code. Note that before fixing any more > sophisticated bug, it's worth to make sure on Windows, that the bug is in > Wine, not in the build. All I verified is that Firefox should start and > basic functionality works (and doesn't work on Wine). I cannot find it the reference for it at the moment, but I remember that by default the stack is in memory < 4gb on 64-bits too, unless you did something. I wish I could remember how you could override the behavior, but this could be why it won't run in wine, but will in windows. For a stack variable: Wine64: &a = 0x7F9E9381FCDC Win64: &a = 0x22FE7C win64_32: &a = 0x28FF44 Cheers, Maarten

June 7, 2010

Re: [7/7] msvcrt/test: Add some simple _vsnwprintf_s tests. (try 2)

by Austin English

On Sun, Jun 6, 2010 at 11:44 PM, Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> wrote: > On 7 June 2010 05:39, Austin English <austinenglish(a)gmail.com> wrote: >> On Sun, Jun 6, 2010 at 11:36 PM, Alexander Scott-Johns >> <alexander.scott.johns(a)googlemail.com> wrote: >>> try 2: todo_wines removed since _vsnwprintf_s is fixed by patch 5. >> >> The todo_wine's need to be removed in the same patch in which they are >> fixed, otherwise, the tests will "fail". > > I add the tests in this patch -- they weren't present in patch 5. Ah, sorry. Misread your comment and firefox/gmail wasn't cooperating with your patch. -- -Austin

June 7, 2010

Re: [7/7] msvcrt/test: Add some simple _vsnwprintf_s tests. (try 2)

by Alexander Scott-Johns

On 7 June 2010 05:39, Austin English <austinenglish(a)gmail.com> wrote: > On Sun, Jun 6, 2010 at 11:36 PM, Alexander Scott-Johns > <alexander.scott.johns(a)googlemail.com> wrote: >> try 2: todo_wines removed since _vsnwprintf_s is fixed by patch 5. > > The todo_wine's need to be removed in the same patch in which they are > fixed, otherwise, the tests will "fail". I add the tests in this patch -- they weren't present in patch 5. Best regards, Alex Scott-Johns

June 7, 2010

Re: [7/7] msvcrt/test: Add some simple _vsnwprintf_s tests. (try 2)

by Austin English

On Sun, Jun 6, 2010 at 11:36 PM, Alexander Scott-Johns <alexander.scott.johns(a)googlemail.com> wrote: > try 2: todo_wines removed since _vsnwprintf_s is fixed by patch 5. The todo_wine's need to be removed in the same patch in which they are fixed, otherwise, the tests will "fail". -- -Austin

June 7, 2010