March 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 5/5] mshtml: Added more attribute object tests

by Marvin

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=9625 Your paranoid android. === W2K3R2SESP2 (32 bit dom) === Timeout === W2K8SE (32 bit dom) === Timeout

March 2, 2011

Re: USB Osciloscope

by Uwe Bonnes

>>>>> "Shachar" == Shachar Shemesh <shachar(a)shemesh.biz> writes: >> I have a USB osciloscope (Link Instruments DSO 8002) that I am quite >> motivated to get working in wine. I have followed the instructions >> to install the USB patches. The osciloscope software works fine in >> demo mode, but it still cannot find the device. I have spent some >> time messing around with this, but I am new to wine, so I am a little >> lost. I am a half decent c programmer, so If somebody could point me >> in the right direction I should be able to get this working. >> >> I have gotten error message usbd.sys failed to load. >> >> I don't know if this program requires functions that wine does not >> support or I have just failed to install something correctly. >> >> I have attached lsusb and winedump -x output >> >> Any help would be greatly appreciated. >> Shachar> usbd.sys sounds like a kernel driver. I'm not sure those are Shachar> supported, even for USB. USB driver are not supported per se, but Alexander Morozov tried to build infrastructure for such driver loading. He provided patches and asked for discussion, but few to non feedback happened on this list. Also Damjan Jovanovic Jan 23 91/4337 "USB architecture: driver loading question" tried to take up the subject, again with no feedback. Linux users in the elektronic area would love to see Wine supporting USB drivers... Archie >> I have gotten error message usbd.sys failed to load. Try to get more information about that error. Is some kernel driver api missing? At some point I had at least usbd.sys loading, also the final device driver failed. Another approach: Can you look at the ezusb-imports of your application and compare against what linux-2.6.34.7-0.7/drivers/usb/serial/ezusb.xxx sipplies? Perhaps you can write a replacemment ezusb DLL. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 2, 2011

Re: WineHQ Bug 26271

by Dmitry Timoshkov

Andreas Bierfert <andreas.bierfert(a)lowlatency.de> wrote: > could you please stop arguing about the validity of the bug. What you > are stating in comment 6 is really not exclusive. The Fedora wine > packages are in fact 'prepackaged binary'. Using the term 'prepackaged binary' doesn't make the package suddenly valid for WineHQ bugzilla, since it clearly contains not supported patches. Same applies for instance to crossover, ies4linux, wineskin or any other. > For the Fedora users pulse support in wine is an important feature. This > is why the patches are in the Fedora build in the first place. I'd much > rather have them included with upstream... Maybe sometime wine will gain > openal support for audio input/output and this issue will go away. Once again, packages with custom patches can't be supported through WineHQ bugzilla for obvious reasons. If the packager knows what he/she is dooing by including such patches - he/she should take the full resposibility for that, including accepting bug reports for his package. If he/she doesn't want to carry the support burden then using Wine source without any custom patches is the way to go. -- Dmitry.

March 2, 2011

Problems with change to cursor and keyboard handling

by Erich Hoover

The recent changes to the cursor and keyboard handling absolutely kill performance in Fallout: New Vegas. The cursor changes cause the mouse to jump around (when you move the mouse while using the keyboard) and the keyboard-specific changes cause the entire game to lock up temporarily about once a second when moving solely by keyboard. I believe I've narrowed down the problem with the keyboard changes (the issue is caused by commit bc4afb078677095468d4ee8f9a15c18cbb47bbbf, see attached proposed fix), but I did not have time this evening to explore the root cause of the cursor problem. Since I'm not certain why this particular line in the commit was changed in the first place, I figured I'd bring it up here, in case I'm missing something, before sending the attached to wine-patches. Erich Hoover ehoover(a)mines.edu

March 2, 2011

Re: USB Osciloscope

by Shachar Shemesh

> > I have a USB osciloscope (Link Instruments DSO 8002) that I am quite > motivated to get working in wine. I have followed the instructions to > install the USB patches. The osciloscope software works fine in demo > mode, but it still cannot find the device. I have spent some time > messing around with this, but I am new to wine, so I am a little lost. > I am a half decent c programmer, so If somebody could point me in the > right direction I should be able to get this working. > > I have gotten error message usbd.sys failed to load. > > I don't know if this program requires functions that wine does not > support or I have just failed to install something correctly. > > I have attached lsusb and winedump -x output > > Any help would be greatly appreciated. > usbd.sys sounds like a kernel driver. I'm not sure those are supported, even for USB. I had a logic analyzer that I managed to get working (sort of - the GUI did not work well with Wine). It used the FTDI drivers, so I found Linux version of the same drivers, and created a winelib wrapper for them under the same name as the Windows version. Your driver seems to be for a driver called "ezusb". Try finding linux drivers for them ("ezusb linux drivers" returned http://www.linux-usb.org/ezusb/, for example. There is also http://www.cypress.com/?id=4&rID=29746) Hope this helps, Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

March 2, 2011

USB Osciloscope

by Archie Robertson

I have a USB osciloscope (Link Instruments DSO 8002) that I am quite motivated to get working in wine. I have followed the instructions to install the USB patches. The osciloscope software works fine in demo mode, but it still cannot find the device. I have spent some time messing around with this, but I am new to wine, so I am a little lost. I am a half decent c programmer, so If somebody could point me in the right direction I should be able to get this working. I have gotten error message usbd.sys failed to load. I don't know if this program requires functions that wine does not support or I have just failed to install something correctly. I have attached lsusb and winedump -x output Any help would be greatly appreciated.

March 2, 2011

Re: Please help me with document extraction.

by Ben Klein

On 2 March 2011 00:32, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: > First, it is _not_ a new approach. It has literally decades of > application. I first encountered it in the '80s and it was well > entrenched even then. Such people as D. Knuth have much to say on the > subject. I don't think anyone is arguing that it is a new concept, or even that it is a bad idea. > It is not even new to Wine. There is a lot of embedded > documentation already. It just is not being maintained. I think what's important to note is that there's a big difference between documenting Wine and documenting the API that Wine implements. If it makes sense for a 1 or 2 line documenting comment to go in to the code that explains the purpose of a function or a variable, then I'm sure AJ would not have an issue with that; but if you're looking at sticking the MSDN articles for win32/win64 into the Wine source, then that's: * bloating the code; * difficult to maintain (i.e., when MS decides to arbitrarily change the way the API works); * not necessary; and * generally a bad idea

March 1, 2011

Re: hhctrl.ocx: Decode HTML entities in contents and index

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > +static int cmp(const void *key, const void *element) > +{ > + HtmlEntity *entity = (HtmlEntity *) element; > + return strncmpW((LPCWSTR) key, entity->string, lstrlenW(entity->string)); > +} This won't work. -- Alexandre Julliard julliard(a)winehq.org

March 1, 2011

Re: Please help me with document extraction.

by Max TenEyck Woodbury

On 02/28/2011 11:34 AM, André Hentschel wrote: > Am 28.02.2011 17:20, schrieb Max TenEyck Woodbury: >>> I think the idea of building upon the existing "documentation" somewhere else >>> has a better chance than the "deal on the 100" >>> >> Frankly, I believe embedded documentation is the way to go. It is _not_ >> a panacea, but it is better than trying to maintain a separate set of >> functional documentation. I have seen cases where it worked. Not great >> but OK. I tried the separate document approach and got _very_ >> frustrated, and _no_one_ was really interested. > > Yeah, so let's see how interested people will be in the new aproach. > (Also OK might not be enough for Wine) > Hmm. First, it is _not_ a new approach. It has literally decades of application. I first encountered it in the '80s and it was well entrenched even then. Such people as D. Knuth have much to say on the subject. It is not even new to Wine. There is a lot of embedded documentation already. It just is not being maintained. Second, OK is better than nothing. I say it is OK because I have actually used such a system. It is a pain to maintain, but the results are usually very good. While the stuff I did never reached the public (It got hung at the informal Q/A stage), other similar material was sold at a profit and was generally rated as very good to excellent. Again, the reason I call it OK is because of the amount of work required. Max

March 1, 2011

Re: ddraw: Check for the Palette before using it

by Henri Verbeet

2011/2/28 André Hentschel <nerv(a)dawncrow.de>: > *Pal = wined3d_palette_get_parent(wined3d_palette); > - IDirectDrawPalette_AddRef(*Pal); > + if (*Pal) IDirectDrawPalette_AddRef(*Pal); > + else hr = DDERR_NOPALETTEATTACHED; This doesn't make sense, the parent shouldn't be NULL. You should figure out what sets it to NULL. You also may want to try warn+heap to see if it's getting free'd or corrupted somewhere.

March 1, 2011