Re: [2/3] mshtml: Add tests for get_scrollLeft
Alistair Leslie-Hughes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Changelog: mshtml: Add tests for get_scrollLeft Best Regards Alistair Leslie-Hughes Hi, Swap the order of patch 2 and 3 and everything all tests will pass ok. Best Regards Alistair Leslie-Hughes
Re: coverity ... new run finally
On Tue, Sep 09, 2008 at 09:12:55PM +0300, Alexander Dorofeyev wrote: Dan Kegel wrote: Still a lot of NULL ptr migration issues which suck to fix, but well. 709 DEADCODEDEVENUM_ReadPinTypesdevenum/createdevenum.c 717 FORWARD_NULLDEVENUM_ReadPinTypesdevenum/createdevenum.c NULL-dereference may be a false positive from the way memory for lpMediaType is allocated there. Not sure though, will look some more later; BTW, a stupid question - is there more details available on what and where it detects in the function (free of charge)? Couldn't really find it by quick look around their website and google, except short definition of FORWARD_NULL meaning etc. Of course, if you click on a specifiy ID it will show the sourcecode with the decisions the analyzer did, including the path where it thought this can happen. Ciao, Marcus
Re: coverity ... new run finally
Marcus Meissner wrote: On Tue, Sep 09, 2008 at 09:12:55PM +0300, Alexander Dorofeyev wrote: Dan Kegel wrote: Still a lot of NULL ptr migration issues which suck to fix, but well. 709 DEADCODEDEVENUM_ReadPinTypesdevenum/createdevenum.c 717 FORWARD_NULLDEVENUM_ReadPinTypesdevenum/createdevenum.c NULL-dereference may be a false positive from the way memory for lpMediaType is allocated there. Not sure though, will look some more later; BTW, a stupid question - is there more details available on what and where it detects in the function (free of charge)? Couldn't really find it by quick look around their website and google, except short definition of FORWARD_NULL meaning etc. Of course, if you click on a specifiy ID it will show the sourcecode with the decisions the analyzer did, including the path where it thought this can happen. Ciao, Marcus But I don't think Alexander has an account. This is the list of currently defined users for Wine: mmccMike McCormack rollo Troy Rollo reifRobert Reif rshearman Robert Shearman scottb Scott Bambrough mhearn Mike Hearn cmorgan Chris Morgan jacek Jacek Caban detlef Detlef Riekenberg dankDaniel Kegel timoshkov Dmitry Timoshkov lenders Louis Lenders latsJeff Latimer vriens Paul Vriens atalbot Andrew Talbot ploujnikov Michael Ploujnikov kblin Kai Blin jhawk James Hawkins jan.wineJan Zerebecki stefan Stefan Dösinger marcus Marcus Meissner bvincentBrian Vincent juanJuan Lang -- Cheers, Paul.
Re: Praise of sorts for Wine re Softmaker Office 2008
On Wednesday 10 September 2008 03:53:12 Dan Kegel wrote: That's praise of sorts... although I hope it doesn't dissuade other vendors from doing native ports. It'd be interesting to know who wrote this. Grammar errors like in the sentence you quoted aside, this article leaves me wondering about the author's background. It's also unclear what better, faster and more stable means in respect to the software running in Wine. E.g. it wouldn't surprise me if the Wine printer integration was better than what the office software has, according to the article. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: include: Define sigset_t in pthread.h if HAVE_SIGSET_T isn't defined.
Rob Shearman wrote: --- include/wine/pthread.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Hi Rob, MingW has it's own definition of sigset_t (include/sys/types.h) which conflicts with this. Do we need to guard the definition in pthread.h with a !defined(__MINGW32__) or is this something that needs to be fixed on the MingW side. (Maybe change our configure?) -- Cheers, Paul.
Re: [1/3] mshtml: Implement HTMLElement2 get_scrollLeft (try 2)
Alistair Leslie-Hughes [EMAIL PROTECTED] writes:
+nsres = nsIDOMHTMLElement_QueryInterface(This-nselem,
IID_nsIDOMNSHTMLElement, (void**)nselem);
+if(NS_SUCCEEDED(nsres))
+{
+nsres = nsIDOMNSHTMLElement_GetScrollLeft(nselem, left);
+nsIDOMNSHTMLElement_Release(nselem);
+if(NS_FAILED(nsres))
+ left = 0;
+}
+else
+{
+ERR(Could not get nsIDOMNSHTMLElement interface: %08x\n, nsres);
+}
This ERR obviously needs the same treatment as the other one. Also
please fix your tab size.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH] kernel32/test: Test import entries of a core windows DLL (riched20.dll) (Revision)
Roy Shea [EMAIL PROTECTED] writes: This revision adds copyright information, removes todo_wine statements to reflect the current wine head, and fixes an implicit typecast warning. --- dlls/kernel32/tests/Makefile.in|1 + dlls/kernel32/tests/loader_image.c | 98 2 files changed, 99 insertions(+), 0 deletions(-) create mode 100644 dlls/kernel32/tests/loader_image.c Please merge that into the other loader tests, no need to create a new file. Also you should test this on kernel32.dll, there's no reason to create a dependency on richedit. -- Alexandre Julliard [EMAIL PROTECTED]
Re: typelib: Implement LoadTypeLib16
Detlef Riekenberg [EMAIL PROTECTED] writes:
+HRESULT WINAPI LoadTypeLib16(LPSTR szFile, ITypeLib** pptLib)
{
-FIXME((%s,%p): stub\n,debugstr_a(szFile),pptLib);
+LPWSTR nameW = NULL;
+HRESULT hr;
+DWORD len;
-if (pptLib!=0)
- *pptLib=0;
+TRACE((%s, %p)\n, debugstr_a(szFile), pptLib);
+
+if (szFile) {
+len = MultiByteToWideChar(CP_ACP, 0, szFile, -1, NULL, 0);
+nameW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR));
+MultiByteToWideChar(CP_ACP, 0, szFile, -1, nameW, len);
+}
-return E_FAIL;
+hr = LoadTypeLib(nameW, pptLib);
+HeapFree(GetProcessHeap(), 0, nameW);
+return hr;
Most likely you need to return a 16-bit interface here.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: include: Define sigset_t in pthread.h if HAVE_SIGSET_T isn't defined.
2008/9/10 Paul Vriens [EMAIL PROTECTED]: Rob Shearman wrote: --- include/wine/pthread.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Hi Rob, MingW has it's own definition of sigset_t (include/sys/types.h) which conflicts with this. Do we need to guard the definition in pthread.h with a !defined(__MINGW32__) or is this something that needs to be fixed on the MingW side. (Maybe change our configure?) Yes, configure should detect it. If it doesn't then it's a bug in our configure check. -- Rob Shearman
Re: include: Define sigset_t in pthread.h if HAVE_SIGSET_T isn't defined.
Rob Shearman wrote: 2008/9/10 Paul Vriens [EMAIL PROTECTED]: Rob Shearman wrote: --- include/wine/pthread.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Hi Rob, MingW has it's own definition of sigset_t (include/sys/types.h) which conflicts with this. Do we need to guard the definition in pthread.h with a !defined(__MINGW32__) or is this something that needs to be fixed on the MingW side. (Maybe change our configure?) Yes, configure should detect it. If it doesn't then it's a bug in our configure check. Hi Rob, AJ put in a fix for this. -- Cheers, Paul.
Re: [2/3] mshtml: Add tests for get_scrollLeft
Did you forget a todo_wine? ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so dom.c ... fixme:mshtml:HTMLTextContainer_get_scrollLeft (0x15371b8)-(0x32fd34) dom.c:1077: Test failed: IHTMLTextContainer::get_scrollLeft failed: -1 dom.c:1078: Test failed: unexpected left -1, expected 0 ... make[2]: *** [dom.ok] Error 2 On Tue, Sep 9, 2008 at 8:48 PM, Patchwatcher [EMAIL PROTECTED] wrote: Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch [2/3] mshtml: Add tests for get_scrollLeft Result: the patch failed regression tests. You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/1347.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/1347.txt See http://kegel.com/wine/patchwatcher/results for more info.
Re: Patchwatcher security improvements
On Mon, 8 Sep 2008, Ambroz Bizjak wrote: Hi, I've abandoned my chroot aproach to improving security in patchwatcher. Instead I've implemented the ability to run untrusted code as a user different than the one running patchwatcher. This is because creating a chroot where Wine could be compiled and tested proved to be too difficult and platform-dependent. This seems like an almost perfect task for a virtual machine: * set up you virtual machine to taste * take a snapshot * to test a patch, fire up the virtual machine * have it test the patch * after the test or when it times out, revert it to the snapshot * rinse (done in the step above), repeat This could be done with VirtualBox, but maybe other alternatives based on Xen or KVM or some such would be better. The main issue I see with this is that the OpenGL / DirectSound tests will not run on the real hardware (as usual), but maybe a Xen-like approach could help there. It would also make it easy to test on FreeBSD / Solaris, at least if based on something like VirtualBox (not sure about the Xen-like approaches). -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong
Re: Praise of sorts for Wine re Softmaker Office 2008
Dan Kegel wrote: http://forum.ubuntuusers.de/topic/softmaker-office-2008--eine-alternative--vora/ has a review of an office suite named Softmaker Office 2008, available for Windows and now also Linux. The review says in part Irritiert hat uns, daß die Windows-Version von Office 2008, die von Stick gestartet werden kann, unter Wine besser, schneller und stabiler läuft, wie die native Office 2008 für Linux. Wer also die Windows-Version legal erworben hat, kann hier Geld sparen. (It irritated us that the Windows version runs better on Wine than the native Linux version. If you have the Windows version already, save your money and run it on Wine.) That's praise of sorts... although I hope it doesn't dissuade other vendors from doing native ports. - Dan I noticed the same type of thing when I was playing with DVD Shrink a couple days ago. Ripping speed in DVD Shrink via Wine was significantly faster than on Windows. What usually is a 2.5 hour process was about 1.5-1.75 hour process. I agree though, hopefully the software vendors will do native ports :). -Zac
Re: Patchwatcher security improvements
Francois Gouget wrote: On Mon, 8 Sep 2008, Ambroz Bizjak wrote: Hi, I've abandoned my chroot aproach to improving security in patchwatcher. Instead I've implemented the ability to run untrusted code as a user different than the one running patchwatcher. This is because creating a chroot where Wine could be compiled and tested proved to be too difficult and platform-dependent. This seems like an almost perfect task for a virtual machine: * set up you virtual machine to taste * take a snapshot * to test a patch, fire up the virtual machine * have it test the patch * after the test or when it times out, revert it to the snapshot * rinse (done in the step above), repeat This could be done with VirtualBox, but maybe other alternatives based on Xen or KVM or some such would be better. The main issue I see with this is that the OpenGL / DirectSound tests will not run on the real hardware (as usual), but maybe a Xen-like approach could help there. It would also make it easy to test on FreeBSD / Solaris, at least if based on something like VirtualBox (not sure about the Xen-like approaches). Yep. Virtualizaion has 3D shortcomings. I can see the way how to use pbuilder/pdebuild toolchain on dedicated user account in Debian to automate this in pretty safe and easy way. pbuilder uses fakeroot/chroot for this and its use is a nobrainer, hellish easy and effective. But this is limited to Debian systems only. Positive is that we still have access to 3DHW (although not concurrent/parallel). Anybody has experience with User-mode Linux kernels for that? ~*~ Another environment is OpenSolaris. There we can leverage technologie of zones ZFS for cheap pseudovirtualization and fast FS recovery using FS snapshots. ~*~ IMO there is no silver bullet to bite all problems on all OS. We can build OS-specific toolchains around patchwatcher and I think that's more viable alternative. Cheers Hark
Re: Patchwatcher security improvements
On Wed, Sep 10, 2008 at 4:37 AM, Francois Gouget [EMAIL PROTECTED] wrote: This seems like an almost perfect task for a virtual machine: ... The main issue I see with this is that the OpenGL / DirectSound tests will not run on the real hardware (as usual) I just came off a project (Zumastor) which used a virtual machine in its test loop as you suggest. We ended up using qemu because kvm was too broken at the time. The whole experience left a bad taste in my mouth, so I'm pushing ahead with a more lightweight approach to be able to make progress on the key problem. If somebody wants to run patchwatcher inside VMs, great, that's definitely a safe way to go, and events might push us in that direction someday.
Re: Patchwatcher security improvements
On Wed, Sep 10, 2008 at 5:06 AM, Vit Hrachovy [EMAIL PROTECTED] wrote: I can see the way how to use pbuilder/pdebuild toolchain on dedicated user account in Debian to automate this in pretty safe and easy way. pbuilder uses fakeroot/chroot for this and its use is a nobrainer, hellish easy and effective. But this is limited to Debian systems only. Positive is that we still have access to 3DHW (although not concurrent/parallel). Yes. We used pbuilder in the automated test for zumastor, and were tied to Debian as a result. We obviously need to avoid requiring that for patchwatcher, which has to run on non-Debian systems. (BTW, we had some difficulty with unreliable distribution mirrors; the only way to get pbuilder to be reliable was to point to a local archive of all the packages.) Anybody has experience with User-mode Linux kernels for that? That's getting even further away from the hardware... IMO there is no silver bullet to bite all problems on all OS. We can build OS-specific toolchains around patchwatcher and I think that's more viable alternative. Indeed.After I finish refactoring patchwatcher, the build slaves will be pretty simple, and it'll be easy to put together custom build slaves for various environments. In particular, a pbuilder-based build slave for Debian / Ubuntu seems like a good idea (as long as you use a local package archive to avoid the flakiness I mentioned above). - Dan
Re: Patchwatcher security improvements
On Wed, Sep 10, 2008 at 5:02 AM, Dan Kegel [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 4:37 AM, Francois Gouget [EMAIL PROTECTED] wrote: This seems like an almost perfect task for a virtual machine: Incidentally, I documented how to produce a really small vmware image for Ubuntu at http://kegel.com/linux/jeos-vmware-player/ (I used this as a demo platform for Zumastor, and wanted the demo to be as easy to download as possible.)
Re: explorer.exe: Implement SC_SCREENSAVE by starting xdg-screensaver
On Wed, Sep 10, 2008 at 7:28 AM, Paul Chitescu [EMAIL PROTECTED] wrote: Changelog: explorer.exe: Implement SC_SCREENSAVE by starting xdg-screensaver with option to lock the screen. The desktop window reacts to SC_SCREENSAVE by starting the screen saver, just like it happens in Windows. No action is taken (and returns FALSE) if running in a virtual desktop. Alternatively, a non-zero lparam is used to signal that the screen should be locked. This cooperates with the user32.dll patch that implements LockWorkStation(). This is an extension, there is no equivalent in Windows but all the programs I've seen that trigger the system screen saver set lparam=0. You forgot to attach the patch. Also you can send both patches together as one diff. There is no reason to split them up in this case. -- 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
Re: Patchwatcher security improvements
Francois Gouget wrote: This seems like an almost perfect task for a virtual machine: * set up you virtual machine to taste * take a snapshot * to test a patch, fire up the virtual machine * have it test the patch * after the test or when it times out, revert it to the snapshot * rinse (done in the step above), repeat This could be done with VirtualBox, but maybe other alternatives based on Xen or KVM or some such would be better. The main issue I see with this is that the OpenGL / DirectSound tests will not run on the real hardware (as usual), but maybe a Xen-like approach could help there. It would also make it easy to test on FreeBSD / Solaris, at least if based on something like VirtualBox (not sure about the Xen-like approaches). Seems like a good idea. I suggest only to use Linux as the host OS and run guests with KVM or VirtualBox, or even UML for Linux builds. Then we can run any OS that uses X as a guest and configure it to use the host's X display (through the virtual network). This should theoretically allow OpenGL through the XGL protocol, but VMGL can also be used if it doesn't work well. And sound hardware would be emulated by the VM software. I think I'll try getting a small Gentoo system to run in UML with a read-only root fs and make it boot as fast as possible. To try a patch, I would give it read access to the master Wine tree on the host, it would copy it to a writable temp folder and try it out. After it's finished or if the external timeout elapses, the UML process will be terminated and all of its writable storage will be reverted.
Re: [msi/tests] Create only one log file and delete it afterwards
On Wed, Sep 10, 2008 at 7:39 AM, Paul Vriens [EMAIL PROTECTED] wrote: Hi, Instead of having 200 logfiles we now create one that we can delete afterwards as we know the name. This is not to speed up the tests but merely to get rid of the log files. We have to pass something for the log mode otherwise we would still have multiple files. (It also looks like Wine is still appending to that one file which is not the same as on Windows). Changelog Create only one log file and delete it afterwards Why don't you just disable logging? MsiEnableLog(0, NULL, 0); -- James Hawkins
Re: [msi/tests] Create only one log file and delete it afterwards
James Hawkins wrote: On Wed, Sep 10, 2008 at 7:39 AM, Paul Vriens [EMAIL PROTECTED] wrote: Hi, Instead of having 200 logfiles we now create one that we can delete afterwards as we know the name. This is not to speed up the tests but merely to get rid of the log files. We have to pass something for the log mode otherwise we would still have multiple files. (It also looks like Wine is still appending to that one file which is not the same as on Windows). Changelog Create only one log file and delete it afterwards Why don't you just disable logging? MsiEnableLog(0, NULL, 0); Hi, Because that doesn't work. After you mailed that suggestion the other day I of course gave it a try. -- Cheers, Paul.
Re: Patchwatcher security improvements
Ambroz wrote: I think I'll try getting a small Gentoo system to run in UML with a read-only root fs and make it boot as fast as possible. To try a patch, I would give it read access to the master Wine tree on the host, it would copy it to a writable temp folder and try it out. After it's finished or if the external timeout elapses, the UML process will be terminated and all of its writable storage will be reverted. Right. That's how the refactored patchwatcher is designed. There's a shared directory containing one subdirectory for each build slave. Each slave is expected to somehow get a read/write mount to its own subdirectory of the shared directory. The master watches the mailing list and puts incoming patches into an inbox directory. Each patch series is called a job, and gets its own subdirectory of inbox. The master dispatches a job to a build slave by moving the job directory into one of the build slave's directories. The build slaves watch for jobs to appear in their directory. When one appears, then do all the builds it implies, then create a log file. The master notices the log file and moves that job out of the slave's subdirectory. So the slave can be in another real machine, another virtual machine, or running as another user; anything as long as it can get read/write access to its subdirectory of the shared directory. - Dan
RE: Debugging Wine thoughts
You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 10:17 AM To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Debugging Wine thoughts Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it. Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI. That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI? Thoughts Problems I have noticed when debugging... If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves
Re: Patchwatcher security improvements
Dan Kegel wrote: So the slave can be in another real machine, another virtual machine, or running as another user; anything as long as it can get read/write access to its subdirectory of the shared directory. The problem with your design right now is that you want to run the slave in some isolated environment and expect it to be secure. The build slave itself is a mission-critical process and putting it in a quarantine to run together with untrusted code allows malicious patches to interfere with its operation. This means an attacker can just kill it from inside his patch, causing the whole patch building operation to fail, or corrupt the baseline tree, or send hundreds of fake emails through the slave interface. So I plan to run the build slave itself in a trusted environment, but make it quarantine individual build operations (similar to my previous design with user switching). This way the impact of an attack is highly limited - all it can theoretically do is fake his own patch results.
Re: d3dx9_36: Fix the tests for native Windows.
Hi, At least for all Windows versions below Vista, the d3dx9 importlib does exist (and d3dx9_36 does not), so either something is screwed up with your system or Vista is handling it otherwise (in that case we need another solution though). Best regards, Tony
Size of SUBHEAP in heap.c
Hello, when trying to fix an issue with Guitar Rig 3 on Wine (Bug 10129, Guitar Rig 3 crashes), I found out something odd: The crash is affected by the size of the SUBHEAP structure in dlls/ntdll/heap.c. Just by adding 8 unused bytes to SUBHEAP, GR3 does not crash anymore. Add another 8 bytes, GR3 crashes again, yet another 8 bytes - no crash and so on. The bug surfaced with this commit: [1d063ae18d990343fc077dcbf650add797924018] ntdll: Remove assumptions that the subheap is at the beginning of the memory block. I don't think the commit is the cause of the problem. It merely changed the size of SUBHEAP to a problematic value. I don't really understand the inner workings of heap.c. Does anyone have an idea what the cause might be, or where to look for more information? Cheers, Martin P.S. Link to the bug: http://bugs.winehq.org/show_bug.cgi?id=10129 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: gdi32: Don't crash when copying to an EMF from a NULL bitmap.
On Mon, Sep 8, 2008 at 3:03 PM, Austin English [EMAIL PROTECTED] wrote: Based on an original patch by Mike McCormack. Rediffed against current git. Testcase included, passes in WinXP. Fixes bug 4543. Anything wrong with this one?
Re: Debugging Wine thoughts
Is there any documentation on the wine site how to set this up stefan??? It may be a start to what I am thinking. chris -Original Message- From: Stefan Dösinger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 11:32 am Subject: RE: Debugging Wine thoughts You can attach any debugger to a Win32 process running in Wine. This includes Linux debuggers like gdb, or any graphical frontends, as well as Windows debuggers like visual studio. If you built wine from source, the Linux debuggers will see the Wine source. Probably they can also read the Windows apps source if you have it. I'm not sure if Windows debuggers can access the Wine source, but maybe dbghelp.dll can do that From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 10:17 AM To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org Subject: Debugging Wine thoughts Dan / All, I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). Then when looking at stacks you click on a variable or stack and it either winds it back or display's it. Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine So my wish list would be: 1) Some form of a Standard Gui Debugger 2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc 3) When you do +relay you could open separate output windows for each thread 4) The ability to turn each of the +relay wine thread output on or off... 4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring. Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off. So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on individually is as well, so there needs to be some sort of happy medium somewhere. 5) A window with a list of the important wine structures or resources that can be watched as the application runs. 6) Source code debugging in the GUI with step through, break points, etc..( not like no w in winedbg but more like one of the GUI's mentioned before) 7) Loading of application from gui debugger and run it 8) Ability to look at a stack and backtrace in the GUI 9) Value Watches within the GUI. 10) Code Checking Some sort of bounds checking... Uninitialized variable checking Unreachable Code Checking 11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding. This would help the new people understand and follow the coding standards set up... instead of guessing like they do now. 12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes 13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things... like I said screen shots... logs, traces, variables, hardware config, etc... 14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it... 15) Link to whats fixed in the new GIT tree... or a list of it... 16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad... 17) Generation of the GIT patch and then mail it to the list through a button... 18) GIT integration You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about. Most of these things I think could
Re: d3dx9_36: Fix the tests for native Windows.
yeah, but your patch is only semi-correct in that regard. What you are referring to (d3dx9.dll) is an import (IMPORTS) of the test program, i.e. a dll which is needed to run the program. What your patch is doing with that var is correct (i.e. we must use d3dx9_36 instead of d3dx9). However, the IMPORTLIB is the lib which is used to compile the program. And if Vista didn't change anything about it (and I'm quite sure it didn't), this MUST be d3dx9(.lib), for some reason, which is only known by the Microsoft programmers. So this means, your patch indeed fixed RUNNING the test applications under Windows, but now they won't COMPILE anymore, because the linker won't be able to find d3dx9_36.lib (the IMPORTLIB) This is assuming you didn't install Wines implementation of course; one should be able to compile the Wine D3DX9 tests out of the box with the official DirectX SDK. Best regards, Tony Hi, Yes, I learnt that in IRC. But there is a real problem. With a native box, there is no d3dx9.dll. So, wine-test mustn't call it. Currently, wine-test calls it and all the tests are skipped in a real windows box. You can check it in the wine-webpage that collects all the test results. David 2008/9/10 Tony [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi, At least for all Windows versions below Vista, the d3dx9 importlib does exist (and d3dx9_36 does not), so either something is screwed up with your system or Vista is handling it otherwise (in that case we need another solution though). Best regards, Tony
Re: Size of SUBHEAP in heap.c
This sounds like a segment / Boundry issue... how far up does it repeat this action? or have you tried??? is it an even number of blocks that the error does not occur? Chris -Original Message- From: Martin Profittlich [EMAIL PROTECTED] To: wine-devel@winehq.org Sent: Wed, 10 Sep 2008 12:52 pm Subject: Size of SUBHEAP in heap.c Hello, when trying to fix an issue with Guitar Rig 3 on Wine (Bug 10129, Guitar Rig 3 crashes), I found out something odd: The crash is affected by the size of the SUBHEAP structure in dlls/ntdll/heap.c. Just by adding 8 unused bytes to SUBHEAP, GR3 does not crash anymore. Add another 8 bytes, GR3 crashes again, yet another 8 bytes - no crash and so on. The bug surfaced with this commit: [1d063ae18d990343fc077dcbf650add797924018] ntdll: Remove assumptions that the subheap is at the beginning of the memory block. I don't think the commit is the cause of the problem. It merely changed the size of SUBHEAP to a problematic value. I don't really understand the inner workings of heap.c. Does anyone have an idea what the cause might be, or where to look for more information? Cheers, Martin P.S. Link to the bug: http://bugs.winehq.org/show_bug.cgi?id=10129 -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: gdi32: Don't crash when copying to an EMF from a NULL bitmap.
Austin English [EMAIL PROTECTED] writes: On Mon, Sep 8, 2008 at 3:03 PM, Austin English [EMAIL PROTECTED] wrote: Based on an original patch by Mike McCormack. Rediffed against current git. Testcase included, passes in WinXP. Fixes bug 4543. Anything wrong with this one? Yes, and it has been rejected already IIRC. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patchwatcher security improvements
Ambroz wrote: The problem with your design right now is that you want to run the slave in some isolated environment and expect it to be secure. The build slave itself is a mission-critical process and putting it in a quarantine to run together with untrusted code allows malicious patches to interfere with its operation. This means an attacker can just kill it from inside his patch, causing the whole patch building operation to fail, or corrupt the baseline tree, or send hundreds of fake emails through the slave interface. It can't directly send fake emails, since the build slave doesn't have the email password, but it could certainly disrupt the build slave and make it give bogus and malicious results. The design isn't for security, it's for ease of prototyping and plugging in new build slaves. So I plan to run the build slave itself in a trusted environment, but make it quarantine individual build operations (similar to my previous design with user switching). This way the impact of an attack is highly limited - all it can theoretically do is fake his own patch results. Yes, good, just please don't change the interface to the build master, all your changes should be encapsulated in a custom build slave. - Dan
Re: [PATCH 1/2] kernel32/test: Test import entries of a core windows DLLs (Revision 2)
Roy Shea wrote: This revision places the new test with the other loader tests in loader.c, and for testing loads kernel32.dll rather than riched20.dll The prior version of this patch is available for reference at: http://www.winehq.org/pipermail/wine-patches/2008-September/061226.html --- dlls/kernel32/tests/loader.c | 72 ++ 1 files changed, 72 insertions(+), 0 deletions(-) Hi, Minor things : typo in kerenl32_module and shouldn't you free the library after the test? (Or maybe use GetModuleHandle, or does that defeat the test?) -- Cheers, Paul.
Re: Fixed an infite loop in winedbg: review wanted
Florian Köberle a écrit : Hello This patch address the infinite loop found at bug 15209: http://bugs.winehq.org/show_bug.cgi?id=15209 At least one of the lines I moved in the loop doesn't make sense outsite: count -= min(count, 256); because the value of count will be always 0 after the loop. I also moved the following line which might be at the wrong position too. About that I am not sure: +fcp-Start += 256; Best regards, Florian Koeberle looks a correct fix to me (moving both lines) A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [jscript/tests] Prevent a crash on win9x
Paul Vriens wrote: Hi, This at least prevents the crash on win9x. There are still numerous failures on win9x but they are visible now. (I'm not so sure about returning S_FALSE in this case btw). IMO it would be better to return error code and break whole test on win9x or find a way to do so before running script. If we wanted to support win9x we'd probably need to add objects representing each function, which is not worth the trouble. Thanks, Jacek
Re: Debugging Wine thoughts
dbghelp supports both linux debug formats (stabs, dwarf) as well as microsoft's one so any debugger using dbghelp as it's debug info provide should debug with all bells whistles native builtin applications I had some success with windbg (with a an 'e' between n d ;-) unfortunately, http://www.winehq.org/site/docs/winedev-guide/dbg-others isn't fully uptodate A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [setupapi/tests] Fix a failure on Windows 2000
On Wed, Sep 10, 2008 at 10:03 AM, Paul Vriens [EMAIL PROTECTED] wrote: Hi, W2K doesn't fail with ERROR_INVALID_NAME but with ERROR_GENERAL_SYNTAX (setupapi error). That error was added for a reason; it was seen on a win2k box. Please don't remove it. -- James Hawkins
Re: [setupapi/tests] Fix a failure on Windows 2000
On Sep 10, 2008, at 22:11, James Hawkins [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 10:03 AM, Paul Vriens [EMAIL PROTECTED] wrote: Hi, W2K doesn't fail with ERROR_INVALID_NAME but with ERROR_GENERAL_SYNTAX (setupapi error). That error was added for a reason; it was seen on a win2k box. Please don't remove it. -- James Hawkins I checked all w2k tests from the last 30 runs and they all came back with that same error. Cheers, Paul
Re: [PATCH] static buffer overflow checking
Am Mittwoch, den 10.09.2008, 22:12 +0200 schrieb Marcus Meissner: This approach will not work with -O0, which might be a problem. If I were to decide, that would kill the patch. I really like to recompile the dlls I am currently debugging with -O0, as that makes following the code flow much easier. Having MultiByteToWideChar calls fail in that case seems to make recompilation of most DLLs (that export A and W functions) with -O0 impossible. Regards, Michael Karcher
Re: devenum: Fix order of operations bug (Coverity id 709)
On Wednesday 10 September 2008 11:34:03 am Juan Lang wrote: dwMediaTypeSize + (dwMediaTypeSize 2 ? 1 : dwMediaTypeSize / 2) I'm pretty sure this would come out as: dwMediaTypeSize + (dwMediaTypeSize (2 ? 1 : dwMediaTypeSize) / 2) But even if it doesn't, I don't think it'd hurt to be more explicit: dwMediaTypeSize + ((dwMediaTypeSize 2) ? 1 : (dwMediaTypeSize/2))
Re: devenum: Fix order of operations bug (Coverity id 709)
I'm pretty sure this would come out as: dwMediaTypeSize + (dwMediaTypeSize (2 ? 1 : dwMediaTypeSize) / 2) It doesn't, check the order of operations again. But even if it doesn't, I don't think it'd hurt to be more explicit: dwMediaTypeSize + ((dwMediaTypeSize 2) ? 1 : (dwMediaTypeSize/2)) Why use two parentheses when 6 will do, eh? Sorry, I don't agree that this is clearer. --Juan
Re: [PATCH] static buffer overflow checking
On Wed, Sep 10, 2008 at 10:27:06PM +0200, Michael Karcher wrote: Am Mittwoch, den 10.09.2008, 22:12 +0200 schrieb Marcus Meissner: This approach will not work with -O0, which might be a problem. If I were to decide, that would kill the patch. I really like to recompile the dlls I am currently debugging with -O0, as that makes following the code flow much easier. Having MultiByteToWideChar calls fail in that case seems to make recompilation of most DLLs (that export A and W functions) with -O0 impossible. Hmm, I might stand corrected for newer gccs. I just tested some code with -O0 and the functioncall still gets optimized away. This is with gcc 4.1 and gcc 4.3. gcc 2.95 does not. But frankly, I can debug similar easily with -O2. Its not that confusing. Ciao, Marcus
Re: d3dx9_36: Fix the tests for native Windows.
On Mi, 2008-09-10 at 18:16 +0200, Tony wrote: Hi, At least for all Windows versions below Vista, the d3dx9 importlib does exist (and d3dx9_36 does not), I installed a recent dx9-runtime on my w2k test system, but a d3dx9.dll is not present (d3dx9_36.dll exist). I get always a blocking popup, when the testlist is created. -- By by ... Detlef
Re: [PATCH] static buffer overflow checking
Am Mittwoch, den 10.09.2008, 22:38 +0200 schrieb Marcus Meissner: I just tested some code with -O0 and the functioncall still gets optimized away. This is with gcc 4.1 and gcc 4.3. gcc 2.95 does not. If it's just a performance pessimisation with -O0, I don't care. If I get compiler or linker errors, it would be bad. I don't care about gcc 2.95 at all, so if it breaks this ancient version, so be it. But frankly, I can debug similar easily with -O2. Its not that confusing. How do you set a breakpoint into a function that has been inlined? Bonus points: That has been inlined at three different places. Regards, Michael Karcher
Re: devenum: Fix order of operations bug (Coverity id 709)
On Wed, Sep 10, 2008 at 01:38:03PM -0700, Juan Lang wrote: I'm pretty sure this would come out as: dwMediaTypeSize + (dwMediaTypeSize (2 ? 1 : dwMediaTypeSize) / 2) It doesn't, check the order of operations again. But even if it doesn't, I don't think it'd hurt to be more explicit: dwMediaTypeSize + ((dwMediaTypeSize 2) ? 1 : (dwMediaTypeSize/2)) Why use two parentheses when 6 will do, eh? Sorry, I don't agree that this is clearer. Agreed, if you add too many parenthesis it gets difficult to see where they line up (which some tool to show you). I get peeved that gcc always warns about and || - where the order is obvious and correctly defined. Blindly putting parenthesis around conditional expressions leads people to write: dwMediaTypeSize + (dwMediaTypeSize 2) ? 1 : dwMediaTypeSize / 2 which is unlikely to have the desired effect! David -- David Laight: [EMAIL PROTECTED]
Re: [PATCH] static buffer overflow checking
On Wed, Sep 10, 2008 at 10:50:42PM +0200, Michael Karcher wrote: Am Mittwoch, den 10.09.2008, 22:38 +0200 schrieb Marcus Meissner: I just tested some code with -O0 and the functioncall still gets optimized away. This is with gcc 4.1 and gcc 4.3. gcc 2.95 does not. If it's just a performance pessimisation with -O0, I don't care. If I get compiler or linker errors, it would be bad. I don't care about gcc 2.95 at all, so if it breaks this ancient version, so be it. But frankly, I can debug similar easily with -O2. Its not that confusing. How do you set a breakpoint into a function that has been inlined? Bonus points: That has been inlined at three different places. Difficult. ;) Ciao, Marcus
Re: devenum: Fix order of operations bug (Coverity id 709)
On Wednesday 10 September 2008 01:52:02 pm David Laight wrote: On Wed, Sep 10, 2008 at 01:38:03PM -0700, Juan Lang wrote: Why use two parentheses when 6 will do, eh? Sorry, I don't agree that this is clearer. Agreed, if you add too many parenthesis it gets difficult to see where they line up (which some tool to show you). Any good editor should be able to highlight parenthesis and bracket pairs. I get peeved that gcc always warns about and || - where the order is obvious and correctly defined. The order may be properly defined, but it's hardly obvious to everyone, all of the time. And just because you know it doesn't mean someone who'll look over the code later will, and make an incorrect assumption based off it. Blindly putting parenthesis around conditional expressions leads people to write: dwMediaTypeSize + (dwMediaTypeSize 2) ? 1 : dwMediaTypeSize / 2 which is unlikely to have the desired effect! That's exactly the point. It's better to be verbose than to confuse oneself. I've personally had several cases where I thought the order of operation was obvious (mostly with the ?: op), didn't use parenthesis, and ran into inexplicable bugs. It wasn't until I went back over the code and added explicit parenthesis that I found out the problem. Of course, I never went to school to learn this stuff. All I know about programming has largely been self-taught. But, for me at least, it helps visualizing what happens when things are properly grouped (spacing helps, eg. foo2 ? 1 : bar/2, but it still leaves a question since the spacing can be wrong given the order of operations, and give unexpected results; parenthesis gaurantees the evaluation is as specified).
Re: Wine mouse input: Fwd: [RFC] Preliminary XI 2 feature list
Roderick Colenbrander wrote: Hi all, Today Peter Hutterer posted a preliminary feature list of Xinput 2. I have forwarded the email to here so that Vitaly and others can check it out and see if it offers what we need in Wine. If you have comments I would send them to the xorg list. Regards, Roderick Colenbrander --- Xorg mail --- Subject: [RFC] Preliminary XI 2 feature list Following XDS, various notes, the discussions and preliminary executive decisions by me, here's a first draft of XI2 features. If you have anything to add, please speak up. Time-line: I'd like to get it into server 1.6 but it doesn't look particularly likely. 7.5 is more likely. - Compatibility with XI 1.x, although some requests will be deactivated or of limited functionality. - 16 bit device IDs - All events available as XGE events. - Event selection through event masks (instead or in addition to the event classes). i.e. the common cases of select from all devices and select from all master devices will be simplified. - Devices may have relative + absolute axes simultaneously, and change the mode on any of these axes at runtime. - Relative coordinates as a separate event. - 32 bit keycodes (reliant on XKB2) - ListInputDevices will include the currently attached Slave - Axis and button labelling through device properties. - subpixel resolution (from relative devices) available to clients. i.e. you get the data in screen coordinates, but with subpixel resolution available as fixed floating point. - no window access protocol, this will be thrown out. - dynamic device classes - device may add/remove classes at runtime. - aspect-ratio scaling of valuators. Probable implementation details: - libXi: namespacing: i.e. Xdosomething will be XIdosomething - server-internal use of XGE events, XI 1.x events emulated when needed. - some standardisation on axis label Atom names. - Clients have to announce XI2 support, otherwise they will be treated as XI 1.x clients. Once the feature discussion is complete, I'll get a protocol spec out. Cheers, Peter I'm still not clear which one will provide the exact events from the device? Relative events doesn't mean the device events. If this is pointer events, then it won't help. Pointer gets stuck on the border of the screen. But not mouse/trackball. Also it would be nice to have a way to completely stop pointer from moving. Right now it's impossible, even with Xevie which was supposed to add exactly that. Vitaliy.
Re: [PATCH 1/2] kernel32/test: Test import entries of a core windowsDLLs (Revision 2)
Roy Shea [EMAIL PROTECTED] wrote: This revision places the new test with the other loader tests in loader.c, and for testing loads kernel32.dll rather than riched20.dll Please move an existing and new tests to their own bodies, and use GetModuleHandle instead of LoadLibrary. -- Dmitry.
Re: Debugging Wine thoughts
On Wed, Sep 10, 2008 at 8:17 PM, [EMAIL PROTECTED] wrote: Question : Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such a fuss why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines have the option of setting the maximum amount of memory which is available). Windows applications assume a certain memory layout, which sometimes conflicts with what *nix does. For example applications don't expect to see pointers into the upper 1-2 GB of the 4 GB virtual memory address space because on Windows the kernel's memory is mapped there. But, ld-linux.so.2 could load libraries there, including libraries hosting Wine's DLLs, and pointers to memory in those would leak into the Windows code. So Wine prevents the special areas of Windows memory from being used by *nix libraries and functions like malloc() by mmap()ing that memory in advance. In my opinion, it would be better if we used a custom dynamic linker (ie. an ld-wine.so) that could control where all libraries get loaded so we wouldn't have to steal memory in advance and go through one of the most elaborate startup processes in existence, where an assembly _start routine in wine-preloader loads before ld-linux.so.2 and then pretends to be the kernel. Bye Damjan Jovanovic
