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

Re: [PATCH 3/3] kernel32/tests: Add a test for opening short paths of differing case.

by Charles Davis

On 10/27/10 8:43 PM, (Marvin) 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=6562 > > Your paranoid android. > > > === WINEBUILD (build) === > Failure running script in VM: Exceeded timeout limit of 300 sec Huh? I've never seen that happen before. I can't tell why my patch would cause this. Ge? Your thoughts? Chip

Oct. 27, 2010

Re: [PATCH 3/3] kernel32/tests: Add a test for opening short paths of differing case.

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=6562 Your paranoid android. === WINEBUILD (build) === Failure running script in VM: Exceeded timeout limit of 300 sec

Oct. 27, 2010

Re: loader: On Mac, reserve the process's original thread for the frameworks.

by Ken Thomases

On Oct 27, 2010, at 5:36 PM, Ken Thomases wrote: > > The frameworks expect the original thread to run its run loop, so input > sources (like distributed notifications) get processed. For example, > Core Audio on Snow Leopard doesn't track changes in the default ouput > device, such as when headphones are plugged in, without this. > --- > libs/wine/Makefile.in | 2 +- > libs/wine/loader.c | 114 +++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 115 insertions(+), 1 deletions(-) > > > <0001-loader-On-Mac-reserve-the-process-s-original-thread-.patch> Hold off on this one. I've encountered a strange issue after sending it (that I didn't encounter in earlier testing). err:process:start_wineboot failed to start wineboot, err 1359 Apparently, there's a failure of an execve() system call in a child process. It's getting EFAULT. Artificially avoiding the very top of the available address space for the secondary thread stack works around the problem. Either the fork() alters the address space (perhaps as a consequence of eliminating all but one thread when creating the child from the parent), or execve() is sensitive to the specific layout. Perhaps it needs to use the very top of the address space, but won't if it thinks that's where the thread's stack is. Or something. -Ken

Oct. 27, 2010

Re: First contact

by Andréas LIVET

Hi all, Back to my bug with Paraworld, I finally manage to get WINEDELAY patch working as I wanted and to stop the program execution with winedbg. Winedbg stop either into the glib or into NtDelayExecution or into binary code, so not so usefull for now... But, if launch the game with those options : WINEDEBUG=+relay,+seh,+tid I got some errors : > 001b:trace:seh:raise_exception code=c0000005 flags=0 addr=0x6004e3 > ip=006004e3 tid=001b > 001b:trace:seh:raise_exception info[0]=00000000 > 001b:trace:seh:raise_exception info[1]=1dd851fc > 001b:trace:seh:raise_exception eax=1dd85200 ebx=68464e10 ecx=0000001a > edx=00000016 esi=00a3db28 edi=00000340 > 001b:trace:seh:raise_exception ebp=00000000 esp=0033f364 cs=0073 ds=007b > es=007b fs=0033 gs=003b flags=00010202 > 001b:trace:seh:call_vectored_handlers calling handler at 0x68cf1180 > code=c0000005 flags=0 > 001b:trace:seh:call_vectored_handlers handler at 0x68cf1180 returned > ffffffff It apparently an exception raise somewhere but no idea what append. The game launch a server instance called PWServer while launding the game, maybe this exe isn't working? I try to run it with wine, but nothing append, it must need some arguments... Is there a way to know what causes this exception? Greetings, Andréas -- Not sent from an iPhone.

Oct. 27, 2010

Re: Linux kernel and game performance?

by Stefan Dösinger

Am 26.10.2010 um 01:26 schrieb Dan Kegel: > Hey folks, > I've run into two web sites that claim that the Linux kernel causes performance > problems in particular games (see below). Anybody know of others? UT 3 I think. It spends a lot of time in task switching, but I have no proof that it is indeed a kernel bug and not a wine bug or a red herring. Interestingly it only hits the unmodified game hard, games based on the engine(e.g. Mass Effect 2) seem to be less affected. Don't get fooled by oprofile though. A high amount of time spent in vmlinux may be because of time spent in the driver module or oprofile itself. > And has anybody found concrete improvements in performance > of a particular app (other than an audio workstation app) from using > a realtime kernel? I wouldn't expect a realtime kernel to improve performance in general, since realtime constraints make achieving overall performance harder(e.g. limit the ability to cache writes). I haven't experimented with a realtime kernel though.

Oct. 27, 2010

RE: [1/3] mscoree: Add tests for LoadLibraryShim.

by Vincent Povirk

Well, in practice, it's a detail that I don't expect to be very important, so it's probably not worth the trouble. Mostly I just want to elminiate the call fusion makes back into mscoree, since it is so blatantly wrong and causes the change I really want to break the tests. We could probably even get away with a hard-coded path, since our ngen.exe doesn't work anyway, and that's essentially what we're doing now given the semi-stub status of GetCORVersion. If/when we need to use the CLR version in fusion for something other than finding the precompiled assembly cache, this may become more important, but even then I don't think we'll need multiple simultaneous instances to work properly. We'll just need to know the correct version to use when only one instance is loaded. Multiple simultaneous runtimes is a case I'm thinking about and trying to account for, but I don't expect to ever see it used. If you prefer, I can add a test for fusion instead that compares the version we get out of GetCachePath(ASM_CACHE_ZAP) to the one we pass to LoadLibraryShim, in cases where more than one runtime is installed, assuming only one instance will be loaded at once. I can fix that without any changes to the loader, but it will mean adding a wine-specific export to fusion. OR mscoree could lie about which .NET versions are installed when Mono isn't available, until there's a real need to load Mono. -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Wednesday, October 27, 2010 2:15 PM To: Vincent Povirk Cc: WineHQ Development Mailing List Subject: Re: [1/3] mscoree: Add tests for LoadLibraryShim. "Vincent Povirk" <vincent(a)codeweavers.com> writes: > There is another minor problem highlighted by this test, which is that > I can make up any path and end up with a loaded dll, as long as > there's a builtin dll filename at the end. That's a feature, the idea is that builtin dlls are independent from the actual dll files. That's also why asking for the path name of a builtin doesn't make sense. This could conceivably be changed now that we have the fake dlls mechanism, but it would be a pretty fundamental redesign. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: [1/3] mscoree: Add tests for LoadLibraryShim.

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > There is another minor problem highlighted by this test, which is that > I can make up any path and end up with a loaded dll, as long as > there's a builtin dll filename at the end. That's a feature, the idea is that builtin dlls are independent from the actual dll files. That's also why asking for the path name of a builtin doesn't make sense. This could conceivably be changed now that we have the fake dlls mechanism, but it would be a pretty fundamental redesign. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

RE: [1/3] mscoree: Add tests for LoadLibraryShim.

by Vincent Povirk

Well, I don't think we can do it properly without having multiple instances of a builtin dll. I believe that native fusion.dll is different for each .NET version, and it probably has the version number baked in. If we can't have multiple instances of a builtin dll, I still believe testing the path is the best way to determine which version was given to LoadLibraryShim, if that's possible. If testing the path is not possible, we can have LoadLibraryShim use a wine-specific exported function to inform fusion.dll of the version, but this approach won't work if someone loads fusion.dll directly from a .NET system directory. There is another minor problem highlighted by this test, which is that I can make up any path and end up with a loaded dll, as long as there's a builtin dll filename at the end. -----Original Message----- From: Alexandre Julliard [mailto:julliard(a)winehq.org] Sent: Wednesday, October 27, 2010 1:31 PM To: Vincent Povirk Cc: WineHQ Development Mailing List Subject: Re: [1/3] mscoree: Add tests for LoadLibraryShim. "Vincent Povirk" <vincent(a)codeweavers.com> writes: > This is needed so that fusion.dll can find out which .NET version it's > expected to use without loading mscoree.dll. Native has the capability > of loading multiple .NET versions in a single process, so the current > approach is unworkable. Testing the filename doesn't seem much more workable, you can't load multiple instances of a builtin dll anyway. How are you planning to handle this? -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: [1/3] mscoree: Add tests for LoadLibraryShim.

by Alexandre Julliard

"Vincent Povirk" <vincent(a)codeweavers.com> writes: > This is needed so that fusion.dll can find out which .NET version it's > expected to use without loading mscoree.dll. Native has the capability > of loading multiple .NET versions in a single process, so the current > approach is unworkable. Testing the filename doesn't seem much more workable, you can't load multiple instances of a builtin dll anyway. How are you planning to handle this? -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (resend try 4)

by Charles Davis

On 10/27/10 10:48 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> On 10/27/10 3:49 AM, Alexandre Julliard wrote: >>> You still have extra stat() calls in the fast path, >> I couldn't get rid of all of them. The one in lookup_unix_name() has to >> stay AFAIK; otherwise SFNs break in some weird way that I can't seem to >> figure out. (kernel32's path test, for example, has 4 failures, all of >> them related to short paths.) > > That's of course the sign of a bigger problem, namely that you don't > handle short paths at all on case insensitive file systems. I just ran the tests on Linux, and oddly enough they don't fail without the extra stat() in lookup_unix_name(). So AFAIK it's peculiar to Mac OS. What's different about Wine on Linux vs. Wine on Mac OS that could cause this? Chip

Oct. 27, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (resend try 4)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > On 10/27/10 3:49 AM, Alexandre Julliard wrote: >> You still have extra stat() calls in the fast path, > I couldn't get rid of all of them. The one in lookup_unix_name() has to > stay AFAIK; otherwise SFNs break in some weird way that I can't seem to > figure out. (kernel32's path test, for example, has 4 failures, all of > them related to short paths.) That's of course the sign of a bigger problem, namely that you don't handle short paths at all on case insensitive file systems. If the tests didn't catch this sooner, it means that you should probably first write more tests with various case and short names combinations. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: [3/3] mscoree: Implement LoadLibraryShim.

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=6541 Your paranoid android. === W2K3R2SESP2 (32 bit mscoree) === mscoree.c:176: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === WVISTAADM (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === W2K8SE (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === W7PRO (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" === W7PROX64 (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" === W7PROX64 (64 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\fusion.DLL"

Oct. 27, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 4)

by Charles Davis

On 10/27/10 8:54 AM, Scott Ritchie wrote: > On 10/25/2010 03:03 PM, Charles Davis wrote: >> Any concerns? I've gone over this patch, and I don't see anything major. >> >> If it will make you feel any better, I just ran the tests under a WoW64 >> environment on Linux, and they passed. >> >> Chip >> >> > > Will your patch detect a Wine folder on ciopfs and work well in it? I > admit this isn't a common use case (yet), but I intend to change this. Yep. I incorporated your idea (testing for a hidden .ciopfs file in the directory), and I made sure I tested the patch on a ciopfs. I created the hidden file manually; we still have to make the FS driver create the file automatically. Chip

Oct. 27, 2010

Re: [1/3] mscoree: Add tests for LoadLibraryShim.

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=6540 Your paranoid android. === W2K3R2SESP2 (32 bit mscoree) === mscoree.c:176: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === WVISTAADM (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === W2K8SE (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 === W7PRO (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" === W7PROX64 (32 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\fusion.DLL" === W7PROX64 (64 bit mscoree) === mscoree.c:162: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:184: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\fusion.DLL" mscoree.c:190: Test failed: LoadLibraryShim failed, hr=80070006 mscoree.c:213: Test failed: incorrect fusion.dll path L"C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\fusion.DLL"

Oct. 27, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (resend try 4)

by Charles Davis

On 10/27/10 3:49 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> If the volume is indeed case insensitive, we skip searching through the >> whole directory ourselves, and just stat() each portion of the path. > > You still have extra stat() calls in the fast path, I couldn't get rid of all of them. The one in lookup_unix_name() has to stay AFAIK; otherwise SFNs break in some weird way that I can't seem to figure out. (kernel32's path test, for example, has 4 failures, all of them related to short paths.) > as well as some > unnecessary changes. Which ones? Perhaps you're referring to the changes to get_redirect_path() and match_redirect(). My upcoming try 5 forces check_case to false when calling get_redirect_path() on a case-insensitive FS, instead of threading that bit through. Is that better? Or do you want me to remove that altogether? Chip

Oct. 27, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 4)

by Scott Ritchie

On 10/25/2010 03:03 PM, Charles Davis wrote: > Any concerns? I've gone over this patch, and I don't see anything major. > > If it will make you feel any better, I just ran the tests under a WoW64 > environment on Linux, and they passed. > > Chip > > Will your patch detect a Wine folder on ciopfs and work well in it? I admit this isn't a common use case (yet), but I intend to change this. -Scott Ritchie

Oct. 27, 2010

Re: Sane.ds units

by Marcus Meissner

On Wed, Oct 27, 2010 at 11:58:22AM +0200, Yaron Shahrabani wrote: > Can someone please explain the units in the twain module (sane.ds)? > There are: > px - pixels > b - ? (bytes) > dpi - dots per inch > mm - milimeters > % - percent > ns - ? (nanosecond) > > I will add comments to the file so it will be clearer for other translators, > thanks! > Yaron Shahrabani It maps Sane defines... /usr/include/sane/sane.h: SANE_UNIT_NONE = 0, /* the value is unit-less (e.g., # of scans) */ SANE_UNIT_PIXEL, /* value is number of pixels */ SANE_UNIT_BIT, /* value is number of bits */ SANE_UNIT_MM, /* value is millimeters */ SANE_UNIT_DPI, /* value is resolution in dots/inch */ SANE_UNIT_PERCENT, /* value is a percentage */ SANE_UNIT_MICROSECOND /* value is micro seconds */ So apparently "ns" might be wrong, and dpi and mm might be switched even... Aric? Ciao, Marcus

Oct. 27, 2010

Re: First contact

by Andréas LIVET

Hi, Thanks for the usefull links Dan Welcome aboard. I hope you have more than 1 hour / week, it takes a > while to come up the learning curve. > :) I hope too, but as I am a professional developer, most of the time I haven't the energy to code at home... I think my time on wine will depend on my motivation, maybe I'll stop trying to hack wine next week? Maybe I'll start coding 2 hours per days :D ? I don't know, just wanted to try. Press Ctrl-C in the terminal where you run winedbg, or send the > program you're debugging a SIGINT manually > Thank you remco, I'll try that. Greetings, Andréas -- Not sent from an iPhone.

Oct. 27, 2010

Re: [PATCH] [Server]: fix access rights for console creation (#24792)

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > 2010/10/27 Alexandre Julliard <julliard(a)winehq.org> >> These should be fixed then. >> >> this will require moving more than half a dozen of operations done client > side to the server so that it does read the attributes > that's both: > 1/ a tremendous change > 2/ will either move most of console handling into the server, or more the > access control on the client side. and I'd bet none of those two options > you'll like I think the first step should be to fix the detection of bare console handles by checking for an fd instead of doing a console server call. That should make things faster, and avoid most of the problem already. Then if the client side really can't be fixed, then it's the client side that should be requesting extra permissions, not the server compensating for the client bugs. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: [1/2] gdi32: Make AddFontToList skip adding a face into global lists if the font is not supposed to be enumerated, and return a pointer to first loaded face.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -1207,15 +1207,17 @@ static void AddFaceToFamily(Face *face, Family *family) > > #define ADDFONT_EXTERNAL_FONT 0x01 > #define ADDFONT_FORCE_BITMAP 0x02 > -static INT AddFontToList(const char *file, void *font_data_ptr, DWORD font_data_size, char *fake_family, const WCHAR *target_family, DWORD flags) > +#define ADDFONT_HIDDEN 0x04 > +static INT AddFontToList(const char *file, void *font_data_ptr, DWORD font_data_size, > + char *fake_family, const WCHAR *target_family, DWORD flags, Face **face_to_return) The face_to_return pointer doesn't seem to be used anywhere. If it's really needed for something else it should be a separate patch. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: [PATCH] [Server]: fix access rights for console creation (#24792)

by Eric Pouech

2010/10/27 Alexandre Julliard <julliard(a)winehq.org> > > Eric Pouech <eric.pouech(a)orange.fr> writes: > > > + if (access & GENERIC_READ) access |= FILE_GENERIC_READ; > > + /* FIXME: we add FILE_READ_PROPERTIES access even in write-only > mode. > > + * As tested on Windows, this is not correct (ie GetConsoleMode() on > with GENERIC_WRITE only > > + * access fails). > > + * But, this is currently needed as part of kernel32/console.c > client side code relies on the > > + * fact that it can read properties: lots of 'set' functions like > WriteConsole, > > + * ScrollConsoleScreenBuffer, SetConsoleCursorPosition (and many > others) do call 'get' > > + * functions. > > + */ > > These should be fixed then. > > this will require moving more than half a dozen of operations done client side to the server so that it does read the attributes that's both: 1/ a tremendous change 2/ will either move most of console handling into the server, or more the access control on the client side. and I'd bet none of those two options you'll like A+ -- -- Eric Pouech

Oct. 27, 2010

Re: [PATCH] [Server]: fix access rights for console creation (#24792)

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > + if (access & GENERIC_READ) access |= FILE_GENERIC_READ; > + /* FIXME: we add FILE_READ_PROPERTIES access even in write-only mode. > + * As tested on Windows, this is not correct (ie GetConsoleMode() on with GENERIC_WRITE only > + * access fails). > + * But, this is currently needed as part of kernel32/console.c client side code relies on the > + * fact that it can read properties: lots of 'set' functions like WriteConsole, > + * ScrollConsoleScreenBuffer, SetConsoleCursorPosition (and many others) do call 'get' > + * functions. > + */ These should be fixed then. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Sane.ds units

by Yaron Shahrabani

Can someone please explain the units in the twain module (sane.ds)? There are: px - pixels b - ? (bytes) dpi - dots per inch mm - milimeters % - percent ns - ? (nanosecond) I will add comments to the file so it will be clearer for other translators, thanks! Yaron Shahrabani <Hebrew translator>

Oct. 27, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (resend try 4)

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > If the volume is indeed case insensitive, we skip searching through the > whole directory ourselves, and just stat() each portion of the path. You still have extra stat() calls in the fast path, as well as some unnecessary changes. -- Alexandre Julliard julliard(a)winehq.org

Oct. 27, 2010

Re: First contact

by Andréas LIVET

On Wed, Oct 27, 2010 at 1:04 AM, Austin English <austinenglish(a)gmail.com>wrote: > On Tue, Oct 26, 2010 at 10:58 PM, Andréas LIVET <andreas.livet(a)gmail.com> > wrote: > > For the patch, I think I understand the concept (I never use git before > and > > never apply a patch), I have to selection the diff text and save it into > a > > file (let's say debug.patch) and then type : > > > > git apply debug.patch > > > > Is that right? I got some error with this patch. > > Yes. > > > I've try with a more recent version found here : > > > http://repo.or.cz/w/wine/hacks.git/commitdiff/2daf55e8eeca89d5c2bb823811512… > > > > But I got some errors in keyboard.c. Anyone has a solution? > > You may have to manually fix the patch, keyboard.c may have changed > since the patch was made. > > BTW, please bottom post on wine mailing lists. > > -- > -Austin > Thanks for your response Austin, I finally manage to apply the patch (just the line number to change). Weirdly it did not work as expected (it's like the game is launch twice when I hit F12), but I'll investigate. Andreas -- Not sent from an iPhone.

Oct. 26, 2010

Re: First contact

by Dan Kegel

On Tue, Oct 26, 2010 at 10:58 PM, Andréas LIVET <andreas.livet at gmail.com> wrote: > For the patch, I think I understand the concept (I never use git before and > never apply a patch), I have to selection the diff text and save it into a > file (let's say debug.patch) Copy and paste sometimes screws up patches. Better to save the patch to a file some other way. In particular, I usually use wget. For the patch you mentioned, one command to fetch the patch is wget http://repo.or.cz/w/wine/hacks.git/patch/2daf55e8eeca89d5c2bb82381151277b6f… http://marc.info/?l=wine-patches is another good place to search for uncommitted patches; that site does a good job of saving the patches as hyperlinks you can use with wget. See also http://kegel.com/academy/opensource.html and http://kegel.com/wine/qa/ for a few tips. Welcome aboard. I hope you have more than 1 hour / week, it takes a while to come up the learning curve. - Dan

Oct. 26, 2010

Re: First contact

by remco47＠gmail.com

On Wed, Oct 27, 2010 at 00:44, Andréas LIVET <andreas.livet(a)gmail.com> wrote: > Other question, is there a way with winedbg to "pause" program execution > without having set any breakpoint. In my case, I don't know where to put the > breakpoint so I wanted to break the program execution and see where it ends. Press Ctrl-C in the terminal where you run winedbg, or send the program you're debugging a SIGINT manually. -- Remco

Oct. 26, 2010

Re: First contact

by Austin English

On Tue, Oct 26, 2010 at 10:58 PM, Andréas LIVET <andreas.livet(a)gmail.com> wrote: > For the patch, I think I understand the concept (I never use git before and > never apply a patch), I have to selection the diff text and save it into a > file (let's say debug.patch) and then type : > > git apply debug.patch > > Is that right? I got some error with this patch. Yes. > I've try with a more recent version found here : > http://repo.or.cz/w/wine/hacks.git/commitdiff/2daf55e8eeca89d5c2bb823811512… > > But I got some errors in keyboard.c. Anyone has a solution? You may have to manually fix the patch, keyboard.c may have changed since the patch was made. BTW, please bottom post on wine mailing lists. -- -Austin

Oct. 26, 2010

Re: First contact

by Andréas LIVET

For the patch, I think I understand the concept (I never use git before and never apply a patch), I have to selection the diff text and save it into a file (let's say debug.patch) and then type : git apply debug.patch Is that right? I got some error with this patch. I've try with a more recent version found here : http://repo.or.cz/w/wine/hacks.git/commitdiff/2daf55e8eeca89d5c2bb823811512… But I got some errors in keyboard.c. Anyone has a solution? Andréas On Wed, Oct 27, 2010 at 12:44 AM, Andréas LIVET <andreas.livet(a)gmail.com>wrote: > Hi all wine developers, > > I read this mailing list for about one year I guess but I think I never > send a message. Because until this Monday, I was a spectator, now I wanna > become an "actor", I want to learn how to hack wine :). > > I don't have a lot of time, 1 hour/week, maybe more, but I just want to fix > some bugs, if I find some, and maybe more in the future. I'll take my time. > > For info, I'm a video game developers for 2 years, so I'm a C++ programmer, > I know nothing about C (except what I know from the C++) and even if I'm > using exclusively linux (ubuntu) for 3/4 years at home, I'm not comfortable > with the POSIX development environment... Not that I'm a fan of Visual > C++/Visual Assist but I always use those tools (at school and then at work) > and wanted to learn something else. > > I decided to start with a game (Paraworld, but it could be anything) which > can't load a level : when I hit the start game button, I got the loading > screen, the music etc. but nothing append. The mouse is still reacting, the > music still playing but nothing is loading. > There is nothing in the trace too, so I tried with the "WINEDEBUG=+relay", > error!! I ended quickly with a log > 300Mo before seeing the main menu! > > I've seen that there is a patch which allows user to control when debug > trace will be display, but I don't know how to find it. > I found this page : > http://www.mail-archive.com/wine-devel(a)winehq.org/msg05542.html > > But I can't find the archive (the patch file), is there a place where we > could download patches? > > Maybe my question is very simple, but I'm a beginner so be indulgent, > please :). > > Other question, is there a way with winedbg to "pause" program execution > without having set any breakpoint. In my case, I don't know where to put the > breakpoint so I wanted to break the program execution and see where it ends. > This is possible with VCC, maybe it's not with winedbg? > > Anyway, thank you for your time, and I want to congratulate all the wine > developers for their amazing work, win is getting better and better everyday > thanks to you, > > Andréas > > --Not sent from an iPhone. > -- Not sent from an iPhone.

Oct. 26, 2010

First contact

by Andréas LIVET

Hi all wine developers, I read this mailing list for about one year I guess but I think I never send a message. Because until this Monday, I was a spectator, now I wanna become an "actor", I want to learn how to hack wine :). I don't have a lot of time, 1 hour/week, maybe more, but I just want to fix some bugs, if I find some, and maybe more in the future. I'll take my time. For info, I'm a video game developers for 2 years, so I'm a C++ programmer, I know nothing about C (except what I know from the C++) and even if I'm using exclusively linux (ubuntu) for 3/4 years at home, I'm not comfortable with the POSIX development environment... Not that I'm a fan of Visual C++/Visual Assist but I always use those tools (at school and then at work) and wanted to learn something else. I decided to start with a game (Paraworld, but it could be anything) which can't load a level : when I hit the start game button, I got the loading screen, the music etc. but nothing append. The mouse is still reacting, the music still playing but nothing is loading. There is nothing in the trace too, so I tried with the "WINEDEBUG=+relay", error!! I ended quickly with a log > 300Mo before seeing the main menu! I've seen that there is a patch which allows user to control when debug trace will be display, but I don't know how to find it. I found this page : http://www.mail-archive.com/wine-devel(a)winehq.org/msg05542.html But I can't find the archive (the patch file), is there a place where we could download patches? Maybe my question is very simple, but I'm a beginner so be indulgent, please :). Other question, is there a way with winedbg to "pause" program execution without having set any breakpoint. In my case, I don't know where to put the breakpoint so I wanted to break the program execution and see where it ends. This is possible with VCC, maybe it's not with winedbg? Anyway, thank you for your time, and I want to congratulate all the wine developers for their amazing work, win is getting better and better everyday thanks to you, Andréas --Not sent from an iPhone.

Oct. 26, 2010

Re: ddraw: Add tests for the foreground window set by SetCooperativeLevel

by Alexandre Julliard

David Adam <david.adam.cnrs(a)gmail.com> writes: > @@ -33,8 +33,9 @@ static LPDIRECTDRAW lpDD = NULL; > static LPDIRECTDRAWSURFACE lpDDSPrimary = NULL; > static LPDIRECTDRAWSURFACE lpDDSBack = NULL; > static WNDCLASS wc; > -static HWND hwnd; > +static HWND hwnd, hwnd2; > static int modes_cnt; > +static BOOL success; That boolean make much sense, especially with this name. If you want to check that you have a valid window you should test the window handle. Same with your createwindow function, it should simply return the handle. -- Alexandre Julliard julliard(a)winehq.org

Oct. 26, 2010

Re: [1/4] msxml3: libxml2 error/warning callback functions (try 2)

by Alexandre Julliard

Adam Martinson <amartinson(a)codeweavers.com> writes: > + len = vsnprintf(NULL, 0, msg, ap); > + buf = heap_alloc(len+1); > + vsnprintf(buf, len+1, msg, ap); vsnprintf can also return -1, check how this is done in other places. -- Alexandre Julliard julliard(a)winehq.org

Oct. 26, 2010

Re: (resend)[2/10]winegstreamer: add gstreamer splitter filter

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > + ERR("++++++++++++++++ perform byte seek ------------------\n"); You still have a ton of such debug ERRs in there. > + *buf = NULL; > + TRACE("Requesting %llu %u\n", ofs, len); Don't use %ll formats. -- Alexandre Julliard julliard(a)winehq.org

Oct. 26, 2010

Re: Linux kernel and game performance?

by Shachar Shemesh

On 26/10/10 14:09, Dan Kegel wrote: > On Tue, Oct 26, 2010 at 7:23 AM, Shachar Shemesh<shachar(a)shemesh.biz> wrote: > >> >> I thought TICKLESS did away with the timer resolution issues. >> > There might still be some, and there are lots of knobs to tweak on > the kernel, perhaps default settings are not optimal. > > More details would certainly be welcome. >> Also, I'm not aware of any easy high frequency timers in Windows. Which API >> does it use? >> > I think he said Sleep(). > My mistake. I was referring to sub-millisecond precision, which is irrelevant to this discussion. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Oct. 26, 2010

Re: Linux kernel and game performance?

by Dan Kegel

On Tue, Oct 26, 2010 at 7:23 AM, Shachar Shemesh <shachar(a)shemesh.biz> wrote: >> The game runs a secondary timing thread >> with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms >> and sends events to the main thread to tell it that a new frame is >> needed. On Linux the necessary timing accuracy is not available, so it >> wavers between 16ms and 20ms. > > I thought TICKLESS did away with the timer resolution issues. There might still be some, and there are lots of knobs to tweak on the kernel, perhaps default settings are not optimal. > Also, I'm not aware of any easy high frequency timers in Windows. Which API > does it use? I think he said Sleep().

Oct. 26, 2010

Re: [PATCH] kernel32: Export recent wer functions

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > @@ -1156,7 +1156,20 @@ > @ stdcall WaitForSingleObjectEx(long long long) > @ stdcall WaitNamedPipeA (str long) > @ stdcall WaitNamedPipeW (wstr long) > +@ stub WerGetFlags > @ stdcall WerRegisterFile(wstr long long) > +@ stub WerRegisterMemoryBlock > +@ stub WerRegisterRuntimeExceptionModule > +@ stub WerSetFlags > +@ stub WerUnregisterFile > +@ stub WerUnregisterMemoryBlock > +@ stub WerUnregisterRuntimeExceptionModule > +@ stub WerpCleanupMessageMapping > +@ stub WerpInitiateRemoteRecovery > +@ stub WerpNotifyLoadStringResource > +@ stub WerpNotifyLoadStringResourceEx > +@ stub WerpNotifyUseStringResource > +@ stub WerpStringLookup Adding stubs is not a good idea. If you have an app that calls these you need to provide a proper stub function. -- Alexandre Julliard julliard(a)winehq.org

Oct. 26, 2010

Re: [PATCH 2/2] wer/tests: Add initial 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=6514 Your paranoid android. === WINEBUILD (build) === Make failed

Oct. 26, 2010

Re: comdlg32: Added Hebrew translation.

by Paul Vriens

On 10/26/2010 10:59 AM, Yaron Shahrabani wrote: > What is wrong with the patch? > Yaron Shahrabani > > <Hebrew translator> > > > > > 2010/10/23 Yaron Shahrabani <sh.yaron(a)gmail.com <mailto:sh.yaron(a)gmail.com>> > > Verified by Paul Vriens > > > > > Nothing: http://source.winehq.org/git/wine.git/?a=commit;h=bf948338ae0d22c37dbbde427… -- Cheers, Paul.

Oct. 26, 2010

Re: comdlg32: Added Hebrew translation.

by Yaron Shahrabani

What is wrong with the patch? Yaron Shahrabani <Hebrew translator> 2010/10/23 Yaron Shahrabani <sh.yaron(a)gmail.com> > Verified by Paul Vriens >

Oct. 26, 2010

Re: Linux kernel and game performance?

by Shachar Shemesh

On 26/10/10 01:26, Dan Kegel wrote: > The game runs a secondary timing thread > with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms > and sends events to the main thread to tell it that a new frame is > needed. On Linux the necessary timing accuracy is not available, so it > wavers between 16ms and 20ms. > I thought TICKLESS did away with the timer resolution issues. Also, I'm not aware of any easy high frequency timers in Windows. Which API does it use? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Oct. 26, 2010

Re: ddraw: Add tests for the foreground window set by SetCooperativeLevel

by David Adam

Timeout does not seem related to my patch (Anyway, I dont see how this patch could cause a timeout) Second failure is harmless A+ David 2010/10/25 Stefan Leichter <Stefan.Leichter(a)camline.com> > Am Monday 25 October 2010 20:11:35 schrieb David Adam: > > Any problems with patch? > > > > A+ > > > > David > > > > ---------- Forwarded message ---------- > > From: David Adam <david.adam.cnrs(a)gmail.com> > > Date: 2010/10/24 > > Subject: ddraw: Add tests for the foreground window set by > > SetCooperativeLevel > > To: wine-patches <wine-patches(a)winehq.org> > > http://source.winehq.org/patches/ shows test failures on windows for your > patch. Not sure if the failures were caused by your patch. > > Bye > Stefan >

Oct. 26, 2010

Re: comdlg32/cdlg: removed 16 bit dependency

by Austin English

On Tue, Oct 26, 2010 at 1:21 AM, CJ <cjraffae(a)mtu.edu> wrote: > Removed wownt32.h from the includes of cdlg32.h and modified fontdlg.c so > that it no longer relies on the 16 bit dependency. Howdy Carl, Thanks for helping Wine, but patches should be sent to wine-patches(a)winehq.org. -- -Austin

Oct. 25, 2010

comdlg32/cdlg: removed 16 bit dependency

by CJ

Removed wownt32.h from the includes of cdlg32.h and modified fontdlg.c so that it no longer relies on the 16 bit dependency. -- Carl J. Raffaele

Oct. 25, 2010

Linux kernel and game performance?

by Dan Kegel

Hey folks, I've run into two web sites that claim that the Linux kernel causes performance problems in particular games (see below). Anybody know of others? And has anybody found concrete improvements in performance of a particular app (other than an audio workstation app) from using a realtime kernel? Thanks! - Dan First: http://wiki.archlinux.org/index.php/World_of_Warcraft#Kernel_Timing_Bug says in a section dated September 2008: "If you are having problems with choppy video every 15 seconds or so, it is related to the kernel scheduler... to fix, add CONFIG_SCHED_DEBUG=y to your kernel config, then set kernel.sched_features=21 kernel.sched_batch_wakeup_granularity_ns=25000000 kernel.sched_min_granularity_ns=4000000 in /etc/sysctl.cfg." Yikes. Any truth to that rumor? Second: http://hisouten.koumakan.jp/wiki/Linux_support#Resolved_bugs says "The game runs too slowly Symptoms: Instead of running at about 60-62fps, like the game is supposed to, it'll run closer to 53fps. This is not ideal. The bug: This is a Linux timing issue. The game runs a secondary timing thread with THREAD_PRIORITY_TIME_CRITICAL, where it simply sleeps for 16ms and sends events to the main thread to tell it that a new frame is needed. On Linux the necessary timing accuracy is not available, so it wavers between 16ms and 20ms. The fix: I hacked around this by setting the timer period to 14ms. This leads to a steady 62-63fps. Which is close enough for use, really. For a constant 60fps turn on vsync in your video drivers."

Oct. 25, 2010

Re: msxml3/domdoc: Handle passed BSTR argument as a WCHAR string in ::createProcessingInstruction()

by Nikolay Sivov

On 10/26/2010 01:41, Jacek Caban wrote: > On 10/25/10 10:38 PM, Nikolay Sivov wrote: >> Should help with http://bugs.winehq.org/show_bug.cgi?id=22607 >> >> >> > > + V_VT(&v) = VT_BSTR; > + V_BSTR(&v) = SysAllocString(data); > > - hr = node_put_value(node_obj,&v_data); > > Allocating a string only because it's needed for VariantChangeType (back to the string) seems like a bad design. How about moving xmlNodeSetContent call (and supporting xmlChar_from_wchar) to separated function (node_set_content?) from node_put_value and call it directly here? Agreed. New helper could use in some other places too. > > Jacek

Oct. 25, 2010

Re: msxml3/domdoc: Handle passed BSTR argument as a WCHAR string in ::createProcessingInstruction()

by Jacek Caban

On 10/25/10 10:38 PM, Nikolay Sivov wrote: > Should help with http://bugs.winehq.org/show_bug.cgi?id=22607 > > > + V_VT(&v) = VT_BSTR; + V_BSTR(&v) = SysAllocString(data); - hr = node_put_value(node_obj,&v_data); Allocating a string only because it's needed for VariantChangeType (back to the string) seems like a bad design. How about moving xmlNodeSetContent call (and supporting xmlChar_from_wchar) to separated function (node_set_content?) from node_put_value and call it directly here? Jacek

Oct. 25, 2010

Re: ddraw: Add tests for the foreground window set by SetCooperativeLevel

by Stefan Leichter

Am Monday 25 October 2010 20:11:35 schrieb David Adam: > Any problems with patch? > > A+ > > David > > ---------- Forwarded message ---------- > From: David Adam <david.adam.cnrs(a)gmail.com> > Date: 2010/10/24 > Subject: ddraw: Add tests for the foreground window set by > SetCooperativeLevel > To: wine-patches <wine-patches(a)winehq.org> http://source.winehq.org/patches/ shows test failures on windows for your patch. Not sure if the failures were caused by your patch. Bye Stefan

Oct. 25, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes. (try 4)

by Charles Davis

Any concerns? I've gone over this patch, and I don't see anything major. If it will make you feel any better, I just ran the tests under a WoW64 environment on Linux, and they passed. Chip

Oct. 25, 2010

ddraw: Add tests for the foreground window set by SetCooperativeLevel

by David Adam

Any problems with patch? A+ David ---------- Forwarded message ---------- From: David Adam <david.adam.cnrs(a)gmail.com> Date: 2010/10/24 Subject: ddraw: Add tests for the foreground window set by SetCooperativeLevel To: wine-patches <wine-patches(a)winehq.org>

Oct. 25, 2010

Re: (resend)[2/10]winegstreamer: add gstreamer splitter filter

by Aric Stewart

Ah yes. Working to clean up someone else's code and missed that. -aric On 10/10/25 9:00, Vitaliy Margolen wrote: > On 10/25/2010 07:45 AM, Aric Stewart wrote: >> --- > >> + ERR("++++++++++++++++ perform byte seek ------------------\n"); >> + if (1 || This->initial) { >> + ERR("Relinked\n"); >> + FIXME("Seeking %i %i\n", format, GST_FORMAT_BYTES); >> + FIXME("using \"%s\"\n", name); > Some debug leftovers? > >> + AM_MEDIA_TYPE amt = { }; >> .. >> + ZeroMemory(&amt, sizeof(amt)); > This is redundant. > >> sizeof(piOutput.achName) / sizeof(*piOutput.achName) > The more common construct in Wine is sizeof(array)/sizeof(array[0]). > IMHO it's better to stick with one > > Also could you please put an empty line in each function after variable > declarations? Your patches look inconsistent. > > Vitaliy. > >

Oct. 25, 2010