wine-devel March 2012

wine-devel@winehq.org

93 participants
206 discussions

Re: strmbase: add beginnings of BaseWindow
by Alexandre Julliard 28 Mar '12

28 Mar '12

Aric Stewart <aric(a)codeweavers.com> writes: > +HRESULT WINAPI BaseWindow_Destroy(BaseWindow *This) > +{ > + if (This->hWnd) > + BaseWindowImpl_DoneWithWindow(This); > + > + UnregisterClassW(This->pClassName, NULL); You most likely don't want to unregister the class every time. > + wnd_class_registered = GetClassInfoW(This->hInstance, This->pClassName, > + &winclass); > + > + if (!wnd_class_registered) > + { There shouldn't be any reason to do this. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/5] winex11: Use GLX_DONT_CARE instead of ~0 in ConvertAttribWGLtoGLX().
by Chris Robinson 28 Mar '12

28 Mar '12

On Tuesday, March 27, 2012 8:35:49 PM Henri Verbeet wrote: > - int pixelattrib = ~0; > + int pixelattrib = GLX_DONT_CARE; I want to say there's a reason we used ~0 instead of GLX_DONT_CARE, but it's been too long that I can't remember. I think it was because GLX_DONT_CARE didn't include all possibilities that ~0 would, like what WGL wanted.

2 1

Re: [4/4] scrrun: Add scrrun tests (try 2)
by Marvin 28 Mar '12

28 Mar '12

1 0

Re: [PATCH] devenum: Add tests for devenum. (try 2)
by Marvin 27 Mar '12

27 Mar '12

1 0

Re: [PATCH] devenum: Add tests for devenum.
by Marvin 27 Mar '12

27 Mar '12

1 0

Re: [PATCH 1/2] winmm: Support DRVM_MAPPER_PREFERRED_GET in waveXxxMessage
by Marvin 27 Mar '12

27 Mar '12

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=17495 Your paranoid android. === WNT4WSSP6 (32 bit capture) === capture.c:648: Test failed: waveInMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 capture.c:653: Test failed: Got invalid preferred device: 0x22fe5c === W2KPROSP4 (32 bit capture) === capture.c:648: Test failed: waveInMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 capture.c:653: Test failed: Got invalid preferred device: 0x235370 === WNT4WSSP6 (32 bit wave) === wave.c:1386: Test failed: waveOutMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 wave.c:1391: Test failed: Got invalid preferred device: 0x234098 === W2KPROSP4 (32 bit wave) === wave.c:1386: Test failed: waveOutMessage(DRVM_MAPPER_PREFERRED_GET) failed: 6 wave.c:1391: Test failed: Got invalid preferred device: 0x41

1 0

Re: winex11.drv: Do not trash existing clip rectangle if XInput2 is not available.
by Alexandre Julliard 27 Mar '12

27 Mar '12

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > This patch makes dlls/user32/input.c and dlls/user32/monitor.c tests pass > on a system without XInput2. It will break dinput, we rely on the clip rectangle being reset. -- Alexandre Julliard julliard(a)winehq.org

3 12

[PATCH] mciqtz: Actually assign result to the output structure
by Joerg-Cyril.Hoehle＠t-systems.com 27 Mar '12

27 Mar '12

Andrew, Aric, Maarten, I'm pleased to see that patches to quartz and mciqtz keep flowing in. For the last years, I've wondered whether I should open a sort of generic bug that mciqtz/quartz still is a mostly broken MCI device, missing many basic functions. Every time I try it out using my MCI shell, it has improved a little bit, but it's still in a very bad shape overall. Alas, I've never written a significant mciavi testsuite. That could be used to check mciqtz too. For instance, basic commands like the following are either partially implemented or completely missing: open xyz.avi type mpegvideo alias q notify status q length status q time format notify seek q to 0 set q time format xyz play q from 50 to 500 notify status q position window q state show seek q to end Furthermore, mciqtz should be able to access other files, e.g. play .wav and even IIRC .mid files. open sound.wav type mpegvideo alias w notify status w time format play w from 4 status w length status w position In theory, one could use the mciwave testsuite, add type mpegvideo to every open, and it should mostly pass. Even without "type mpegvideo", using mciqtz to open an .mpg file with audio and/or video yields many fixme lines and has issues, e.g. IIRC it doesn't manage to stop! close all Often, the missing bits are in quartz or associated dlls, not mciqtz. Every time I look at quartz code, I'm lost among lots of methods that do nothing but delegate to other methods. Typical OO :-( A quartz working well would allow to close bug #19496. See comment #13. I believe msvfw should always delegate to one of mciavi or mciqtz. But currently, mciqtz+quartz is in too bad shape to switch msvfw. I'd be happy to see mciqtz work at least as well as most other mci drivers. Please keep sending patches! Thank you, Jörg Höhle

2 3

Need suggestion to choose a GSoC idea
by Qian Hong 27 Mar '12

27 Mar '12

Hi all, I'm a student in Department of Mathematics, Sun Yat-sen University. My irc nick name is fracting, my real name is Qian Hong. I'm in GMT+8 time zone, availible on 10:00 to 18:00 (GMT+8) on #winehackers. I know C/bash and some Linux skills. Currently I'm an intern in Redhat, working in the kernel-qe group. I have great interesting in the Wine project. Last year I spent most of my spare time on reporting bugs to Wine. When I doing this I found lots of bugs regarding Chinese software have beem complained in local Linux forum for years but no one reported them to Wine project. In other words, I found most Chinese Linux users didn't report bugs to open source projects, well, I think that is a bug too :) After reported 100+ bugs, I'm surprised so many bugs have been fixed in just one year. I wish I can do some more then reporting bugs for Wine project, great if I can get start with the 2012 GSoC and keep submitting patches to Wine after that. I have lots of ideas in my TODO list, unfortunately most of them might too hard to do as a GSoC project. Anyway, I'll post my ideas here, wait for feedbacks, choose one of them as my GSoC idea, and leave others as my job in the coming years. Certainly I'm glad to see any others working on those ideas :) Here is my list: - Implement ndis.sys This idea come from the off-standard network authentication in China. Lots of Universities in China using some off-standard network authentication methods for campus network connection, the authentication protocols are usually private and changed frequently, the authentication clients are usually Windows-only. This issue is the main blocker for students in those Universities to change to Linux desktop or Mac. I've filed some bugs regarding some network authentication clients, such as [1],[2],[3],[4],[5]. However, even the above bugs are fixed, these clients might not work on wine because they depends on ndis.sys which is not implemented yet. As an intern in Redhat network-qe group focus on NIC testing, I have great interesting in implement ndis.sys, though I think it is too hard for a GSoC project. The ndiswrapper code is a great resource but not complete, also I known ReactOS project has a ndis.sys too but obviously it won't work on Wine. Is it allowed to read ReactOS implementation to learn how things work? Anyway I'm interesting in what you think :) - Implement/improve wpcap proxy This idea is similar with the first one, in fact André H has already done the most important part [6],[7]. I hope André's patch will be accepted, and I'm interesting in improving it. I have done some proof-of-concept to show that some kinds of network auth client wich depends on winpcap will work on wine with André's patch. - Improve builtin iexplore This idea is come from another main blocker for using Linux/Mac in China. Most Chinese online banks are ie-only, depends on ActiveX and some ie-only style JavaScript or even VBScript. Jacek and other wine developers has done lots of work on them, and I'm interesting in participating. I've filed 40+ bugs regarding online bank support with Wine [8]. My goal is to make wine builtin iexplore works for as many online banks, currently I have more then 6 different online bank accounts for testing, guys in openbank-discuss group [9] will help on testing too. - Improve USB support Yeah, this might be another idea which is too hard for a GSoC project. We already have a third party patch, I wonder will Wine-1.6 have official USB support? This idea is similar with the above one, my goal is to solve the online bank USB-key issues. After testing on 8 different USB-keys with the USB patch [10], I noticed they won't work on wine without hidusb.sys. ReactOS project has implement hidusb.sys in the last few months, again, is it allow to learn ReactOS code if I would like to contribute to Wine? - Improve Wine CJK font support The main idea is fix Bug 16325 [11], Aric and others have done a lot of work on it, and I'm glad to participating too. I think the main blocker for Wine CJK font support is Font Association now, is it suitable for a GSoC project? Also I've filed some other Wine font bugs [12],[13],[14],[15],[16], I'm happy to working on them. - Improve Wine font test case This idea is similar with the above one, however, instead of fixing real bugs, this idea is to prevent new bugs(regression). As having filed 100+ bugs I know the pain of doing regression test if we can't script the test, this happens on font related bugs. The main idea is to integrate an OCR engine to wine testcase, use ORC method to detect whether the fonts display correctly. We already have very good open source ORC engine [17] which is in Apache License. However tesseract-ocr is written in C++ an I am worring that will not be integrated to Wine code tree. - Improve Wine App install / App running testing This idea is similar with Austin's early work [18], my idea is using sikuli [19] instead of autohotkey, since sikuli is more powerful for complex work. Sikuli using tesseract as orc engine, so if we done this job we can prevent many font relate regression as well. - I'm also open to other ideas... I'm sorry for my long post, and thank you for your time to read it. In fact I have much more things on my todo list regarding to Wine, but time is limit and I have to give up most of them in the near future. I'm happy to know whether there is anyone working on these ideas, also I'm happy if any others take them as GSoC project :) Rather than to be accepted by GSoC, I'm more glad to see Wine is improved, especially on parts I've mentioned above, that is why I post this long mail. Wish we can see them in Wine 1.6. Of cause, GSoC is awesome to me :) Any suggestion is appreciated, and feel free to ping me on IRC (fracting). Last but not least, thanks wine community for such a great project. Reference: [1] Bug 29460 - Ruijie Supplicant Su1xDriver.sys crashes in driver entry due to ntoskrnl.exe IoGetCurrentProcess() being a stub [2] Bug 27060 - installation of iNodeSetup3.60-6208.exe needs netcfgx.dll [3] Bug 27061 - iNode Client exit silently on start up [4] Bug 30041 - npptools.dll is needed by ishare_user.exe of Dr.com [5] Bug 30208 - NKSetup (Shan Xun 802.1x client) infinite loop while installing [6] Bug 21571 - WinPcap 4.0.1: Setup cannot install Microsoft Network Monitor Driver (NetMon) [7] http://www.winehq.org/pipermail/wine-patches/2011-March/099838.html [8] http://code.google.com/p/online-banking-with-wine/wiki/buglist [9] https://groups.google.com/forum/?fromgroups#!forum/non-ie-online-banking [10] http://wiki.winehq.org/USB [11] Bug 16325 - incorrect font rendering for CJK programs [12] Bug 29851 - Some part of PDFCreator installer cannot display Chinese correctly even Font Replacement is setting correctly [13] Bug 29853 - QQ2011 does not display Chinese correctly with builtin usp10 if font link setting is incomplete [14] Bug 29850 - Scilab does not display Chinese [15] Bug 27285 - Miro does not display Chinese [16] Bug 30263 - builtin iexplore does not display Chinese [17] http://code.google.com/p/tesseract-ocr/ [18] http://wiki.winehq.org/Appinstall [19] http://sikuli.org/ -- Regards, Qian Hong - Sent from Ubuntu http://www.ubuntu.com/

3 4

Re: [3/8] scrrun: Add IFileSystem3 support
by Jacek Caban 27 Mar '12

27 Mar '12

Hi Alistair, On 03/27/12 11:41, Alistair Leslie-Hughes wrote: > +typedef struct FileSystem > +{ > + IFileSystem3 IFileSystem3_iface; > + LONG ref; > +} FileSystem; > + > +static inline FileSystem *impl_from_IFileSystem3( IFileSystem3 *iface ) > +{ > + return CONTAINING_RECORD(iface, FileSystem, IFileSystem3_iface); > +} Is there any reason for this to be heap-based object? It looks to me like it would better be a static object (AFAICS you don't even need FileSystem struct since you're not going to store anything in it). Cheers, Jacek

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2012