Re: WineHQ Bug 26271
Andreas Bierfert 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.
Problems with change to cursor and keyboard handling
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 ehoo...@mines.edu From 1c222c2cbc4963abd468d26ae6f5010c99578142 Mon Sep 17 00:00:00 2001 From: Erich Hoover Date: Tue, 1 Mar 2011 22:52:49 -0700 Subject: server: Fix Fallout New Vegas when send_hardware_message is called with a NULL message. --- server/queue.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/server/queue.c b/server/queue.c index 58be426..6cdb3d7 100644 --- a/server/queue.c +++ b/server/queue.c @@ -1747,7 +1747,7 @@ DECL_HANDLER(send_hardware_message) } else if (!(desktop = get_thread_desktop( current, 0 ))) return; -if (!(data = mem_alloc( sizeof(*data) ))) goto done; +if (!req->msg || !(data = mem_alloc( sizeof(*data) ))) goto done; memset( data, 0, sizeof(*data) ); data->x= req->x; -- 1.7.1
Re: USB Osciloscope
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
Re: Please help me with document extraction.
On 2 March 2011 00:32, Max TenEyck Woodbury 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
Re: hhctrl.ocx: Decode HTML entities in contents and index
Owen Rudge 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
julli...@winehq.org
Re: Please help me with document extraction.
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
