February 2009 - Wine-Devel - list.winehq.org

[winetest] Make sure we can test .NET dlls on Windows (need some advice)
by Paul Vriens Feb. 3, 2009

Feb. 3, 2009

Hi, Sent to wine-devel so I don't jeopardize my rating too much ;) .NET dlls cannot be found with the existing logic in winetest, mainly because they are not in the search path. If the normal loading of a dll fails we now check against a fixed set of names (fusion only for now). If it's a .NET dll we check if this one is there (according to .NET's mscoree) and get the file information. We can use to existing version checking stuff for that part as it's a normal dll. Remarks, suggestions? Changelog Make sure we can test .NET dlls on Windows -- Cheers, Paul.

1 0

Re: ntdll: add a warning about running wine as root (try 2)
by Vincent Povirk Feb. 2, 2009

Feb. 2, 2009

The patch does not apply to current master. Vincent Povirk On Mon, Feb 2, 2009 at 8:01 PM, Austin English <austinenglish(a)gmail.com> wrote: > Been seeing it quite a bit recently in the forums. While the patches > to break using sudo/su have helped a bit, seems some users are > convinced they need to run wine as root. This adds a non fatal > message, so no functionality is lost for those that _do_ need to run > as root. > > Try 2: > Made warning a bit more verbose. Changed geteuid to getuid, since we > already check for that function, and geteuid is a bit is superfluous, > since sudo should already be prevented. > > -- > -Austin > > > >

2 1

Re: jscript: Don't fail tests if IActiveScriptParse isn't supported
by Jacek Caban Feb. 2, 2009

Feb. 2, 2009

Hi Juan, These failures are on Win64 where we should query for different interface. I've sent a patch to fix it: http://www.winehq.org/pipermail/wine-patches/2009-February/068760.html Jacek

2 1

Re: Simplify dlls/comctl32/rebar.c
by Francois Gouget Feb. 2, 2009

Feb. 2, 2009

On Fri, 30 Jan 2009, Gerald Pfeifer wrote: > (It's not clear which parameters we'd really need if it is ever fully > implemented.) > > ChangeLog: > Simplify. [...] > > Index: dlls/comctl32/rebar.c [...] > @@ -3618,7 +3618,6 @@ REBAR_WindowProc (HWND hwnd, UINT uMsg, > > /* case RB_SETCOLORSCHEME: */ > /* case RB_SETPALETTE: */ > -/* return REBAR_GetPalette (infoPtr, wParam, lParam); */ > > case RB_SETPARENT: Once the commented out return has been removed it looks like RB_SETCOLORSCHEME and RB_SETPALETTE are meant to fall through to RB_SETPARENT, which does not seem right... So I'd leave a comment there, maybe /* return ...; */. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Research is the transformation of money to knowledge. Innovation is the transformation of knowledge to money. -- Dr. Hans Meixner

2 1

Re: Simple but awesome demos of Wine?
by Brian Vincent Feb. 2, 2009

Feb. 2, 2009

Oh, by the way, I was using Fedora Core 10. I was pretty impressed with the distro - my Intel wireless card worked out of the box and so did sound. That's the first time I've had that happen on a Dell Latitude notebook. However, sound in Wine didn't work at all. I made absolutely no effort to fix it, but a quick look at the settings showed it was trying to use ALSA. I was hoping Wine's sound had progressed to the point where it would at least work if the underlying distro was using sound in sane manner, which I'm kind of assuming Core 10 does. Is it a packaging issue? -Brian

2 1

deb packages archive down?
by Tom Wickline Feb. 2, 2009

Feb. 2, 2009

Hello, I have been trying to access the Wine deb archives for about six hours now and Ive been receiving a "connection to the server was reset" error. I'm not sure how long this has been the case but can the maintainer of the archive please look into this failure? http://wine.budgetdedicated.com/archive/index.html Cheers, Tom -- http://www.wine-reviews.net/ http://bordeauxgroup.com/

4 3

DIB Engine - Separated in small patches
by Massimo Del Fedele Feb. 2, 2009

Feb. 2, 2009

As requested I separated the engine in small patches, trying to keep original authors when possible. As the post didn't appear here (problem with zipped files, maybe ?), I've put it on bug 421 page. I whish to know if it can be ok for including on wine tree. Ciao Max

3 2

wine.budgetdedicated.com down?
by Dan Kegel Feb. 2, 2009

Feb. 2, 2009

I can't download debian wine packages from wine.budgetdedicated.com today...

4 4

Re: [2/2] mshtml: Add support for IHTMLStyle4 interface
by Jacek Caban Feb. 2, 2009

Feb. 2, 2009

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Add support for IHTMLStyle4 interface > --- dlls/mshtml/Makefile.in | 1 + dlls/mshtml/htmlstyle.c | 4 ++ dlls/mshtml/htmlstyle.h | 3 + dlls/mshtml/htmlstyle4.c | 135 ++++++++++++++++++++++++++++++++++++++++++++++ dlls/mshtml/tests/dom.c | 7 +++ 5 files changed, 150 insertions(+), 0 deletions(-) create mode 100644 dlls/mshtml/htmlstyle4.c This interface has very few methods so it doesn't make sense to add new file for it. Jacek

1 0

Re: [1/2] mshtml: Add support for IHTMLStyle3 interface
by Jacek Caban Feb. 2, 2009

Feb. 2, 2009

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Add support for IHTMLStyle3 interface > + + hres = IHTMLStyle_QueryInterface(style, &IID_IHTMLStyle3, (void**)&style3); + ok(hres == S_OK, "Could not get IHTMLStyle3 iface: %08x\n", hres); + if(SUCCEEDED(hres)) { + IHTMLStyle3_Release(style3); + } Please use style_iids to test QueryInterface calls. Jacek

1 0

Re: Anything wrong with this patch?
by Ben Klein Feb. 2, 2009

Feb. 2, 2009

2009/1/24 Jérôme Gardou <jerome.gardou(a)gmail.com>: > Ben Klein a écrit : >> >> 2009/1/24 Jerome Leclanche <adys.wh(a)gmail.com>: >> >>> (Damnit, gmail interface) >>> Pipermail shows as empty, here. >>> >>> On Fri, Jan 23, 2009 at 10:05 PM, Jérôme Gardou <jerome.gardou(a)gmail.com> >>> wrote: >>> >>>> http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html >>>> Any comment on this one? Related to bug 15616. >> >> Looks like >> http://www.winehq.org/pipermail/wine-patches/2009-January/067564.html >> has a brief description that says "See bug 15616", but the previous >> mail http://www.winehq.org/pipermail/wine-patches/2009-January/067565.html >> has the actual patch. >> >> Jérôme, be more careful when submitting patches! :) > > strange... the first one is the original message, the second one looks like > the attachment... Maybe something wrong with thunderbird. I'll resend if > needed. > I just looked at bug 15616. Maybe you should look at it too. Also, please hit "Reply to all" so your message gets sent to the mailing list too :)

3 7

Re: [2/2] mlang: Export a couple of functions by ordinal.
by Dmitry Timoshkov Feb. 2, 2009

Feb. 2, 2009

"Hans Leidekker" <hans(a)codeweavers.com> wrote: > IE7 imports these and possibly others by ordinal. > > -Hans > > diff --git a/dlls/mlang/mlang.spec b/dlls/mlang/mlang.spec > index 1e8f022..689ad27 100644 > --- a/dlls/mlang/mlang.spec > +++ b/dlls/mlang/mlang.spec > @@ -1,14 +1,15 @@ > +112 stdcall ConvertINetUnicodeToMultiByte(ptr long ptr ptr ptr ptr) > +120 stdcall LcidToRfc1766A(long ptr long) > +121 stdcall LcidToRfc1766W(long ptr long) > + > @ stdcall ConvertINetMultiByteToUnicode(ptr long ptr ptr ptr ptr) > @ stub ConvertINetReset > @ stdcall ConvertINetString(ptr long long ptr ptr ptr ptr) > -@ stdcall ConvertINetUnicodeToMultiByte(ptr long ptr ptr ptr ptr) > @ stdcall -private DllCanUnloadNow() > @ stdcall -private DllGetClassObject(ptr ptr ptr) > @ stdcall -private DllRegisterServer() > @ stdcall -private DllUnregisterServer() > @ stdcall GetGlobalFontLinkObject() > @ stdcall IsConvertINetStringAvailable(long long) > -@ stdcall LcidToRfc1766A(long ptr long) > -@ stdcall LcidToRfc1766W(long ptr long) > @ stdcall Rfc1766ToLcidA(ptr str) > @ stdcall Rfc1766ToLcidW(ptr wstr) I've compared the exports of win98 and winxp versions of mlang.dll and they have exactly the same ordinals assigned. So it should be safe to assign ordinals to all mlang exports (it's worth to mention that PSDK doesn't ship an mlang.lib). -- Dmitry.

1 0

Re: BOOL WINAPI versus BOOL in d3dx9 and d3dx8
by Tony Wasserka Feb. 2, 2009

Feb. 2, 2009

> Hi, > > the declaration of IntersectionTri is > BOOL IntersectionTri(.....) in d3dx8mesh.h and > BOOL WINAPI? IntersectionTri(.....) in d3dx9mesh.h . > > Is the latter one compatible with the former one (so I can forward d3dx9 function to the d3dx8 one) > or must I implement them separately? > > David It's already forwarded in d3dx9_36.spec to d3dx8, so you don't need to implement it twice. I was pretty careful when creating that specfile, i.e. it's in 99% safe to trust it ;) As a rule of thumb, every d3dx9 function which has no device (or any other D3D9 specific interface) parameter and has the exact same parameter list can safely be forwarded to d3dx8. However, are you sure it's only BOOL in d3dx8? AFAIK, dll functions always have to be WINAPI, as the calling convention gets screwed up otherwise... Best regards, Tony

2 1

wined3d and winex11 hand in hand...
by Jérôme Gardou Feb. 2, 2009

Feb. 2, 2009

Quite oddly enough, wined3d and winex11 don't communicate with each other at all (well, wined3d uses WGL in gdi32, and gdi32 is based on winex11), and this leads to problems which are tricky to resolve... For instance, when a d3d application wants to disable screensavers, there is no way to do this through the windows api, but xlib provides XSetScreenSaver which is axactly what we need there. Would it be a good way to do this, as in user32 and gdi32, to create a driver structure holding each function pointer we would need, and forward them to stub if unavailable?

2 2

performance issue when OffscreenRenderingMode = "pbuffer"
by Jérôme Gardou Feb. 1, 2009

Feb. 1, 2009

I tried to play Supreme Commander using pbuffer option instead of fbo. I was quite happy with it, since I gained quite a bunch of performance (I mean, something I really COULD see), but after a while, the performance dropped dramatically, to ~4-5 fps. I tested quite a few thing, and I finally found that pixel bufers were not taken in account when calculating available texture memory. The game then allocated more textures, and good opengl didn't dare complain when putting them in system memory. Attached is a patch which should solve the problem. For those who are curious, try setting VideoMemorySize to 200 instead of 256. It works just like a charm. >From 8e7b7e517b15e2ddb2cdd1526dfab3dfbf856bd5 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?J=C3=A9r=C3=B4me=20Gardou?= <jerome.gardou(a)laposte.net> Date: Sun, 25 Jan 2009 02:34:03 +0100 Subject: [PATCH] wined3d: take pixel buffers in account when calculating texture ram. --- dlls/wined3d/context.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/dlls/wined3d/context.c b/dlls/wined3d/context.c index da3053a..9fad82d 100644 --- a/dlls/wined3d/context.c +++ b/dlls/wined3d/context.c @@ -898,6 +898,9 @@ WineD3DContext *CreateContext(IWineD3DDeviceImpl *This, IWineD3DSurfaceImpl *tar } This->frag_pipe->enable_extension((IWineD3DDevice *) This, TRUE); + if(create_pbuffer) + WineD3DAdapterChangeGLRam(This, ((IWineD3DSurfaceImpl*)(ret->surface))->currentDesc.Width * ((IWineD3DSurfaceImpl*)(ret->surface))->currentDesc.Height * ((IWineD3DSurfaceImpl*)(ret->surface))->bytesPerPixel) ; + return ret; out: @@ -988,6 +991,7 @@ void DestroyContext(IWineD3DDeviceImpl *This, WineD3DContext *context) { if(context->isPBuffer) { GL_EXTCALL(wglReleasePbufferDCARB(context->pbuffer, context->hdc)); GL_EXTCALL(wglDestroyPbufferARB(context->pbuffer)); + WineD3DAdapterChangeGLRam(This,(-1) * ((IWineD3DSurfaceImpl*)(context->surface))->currentDesc.Width * ((IWineD3DSurfaceImpl*)(context->surface))->currentDesc.Height * ((IWineD3DSurfaceImpl*)(context->surface))->bytesPerPixel) ; } else ReleaseDC(context->win_handle, context->hdc); pwglDeleteContext(context->glCtx); -- 1.6.0.6

5 8

[RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.14
by Paul TBBle Hampson Feb. 1, 2009

Feb. 1, 2009

>From the discussion regarding the drawStridedSlow implementation of vertex blending, what shook out was the suggestion that WineD3D will need a vertex-program fixed function vertex pipeline at some point anyway, and therefore it doesn't make sense to add another software implementation to drawStridedSlow but to instead get the vertex pipeline in place and build the vertex blending functionality on top of that. Towards that aim, I've ported Stefan Dösinger's initial implementation of this from October last year [1] to what turned out to be 1.1.14. It fails two more D3D9 tests than 1.1.14: visual.c:914: Test failed: Transformed vertex with linear vertex fog has color 0000ff00 visual.c:986: Test failed: Transformed vertex with linear vertex fog has color 0000ff00 (I don't know if these failed when it was first implemented, so I don't know if the problem is the patch, the port, or even the test. This is on my nVidia 8600 w/180.22 binary drivers, in case it makes a difference.) I haven't run it with any games yet, or profiled it. Stefan's commented since that it was slower than the current system, albeit unoptimised, and that was the reason he didn't undertake any further work on it. I don't know what games use the fixed-function pipeline, so I'm open to suggestions and bug report references. All but the last patch in this tarball are ports of Stefan's original, and were done using git-am so still retain his original headers. The sorta-nasty no_d3dcolor_swizzle code in get_color and its caller in the last patch is entirely my fault though. ^_^ The last patch is actually also from Stefan's code, but it's an attempt by me to reinsert fog code I have removed, possibly incorrectly. However, it didn't fix the above fog failures, so I left it as a separate patch. I'm not totally sure I've got all the hard parts of the port right. The two relevant changes since these patches were applied were the implementation of EXT_vertex_buffer_bgra and the rearrangement of the fog code. For EXT_vertex_array_bgra and vertex_pipe->can_convert_d3dcolor, I'm not sure if there are places that check one and should check the other, and I'm not sure if the test in state.c line 4280 (streamsrc) is doing the right thing. I think it is doing the right thing. The vertex program recognises and handles a position_transformed vertex declaration itself. Of the original 13-patch series, patches 4 and 5 were rendered completely uninteresting by the fog changes, and 7 and 13 had already gone into the main tree. There was also what I believe was a bug in patch 2, which basically left pCaps->MaxUserClipPlanes uninitialised rather than fetching the value from the vertex_pipeline's get_caps method result. Anyway, here it is. I hope this is of benefit to someone. The next thing I plan to do with this is try and wrap my head around the internals of the arbvp vertex program so I can implement vertex blending there. [1] http://www.mail-archive.com/wine-devel(a)winehq.org/msg49501.html -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

2 1

[patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)
by Luke Kenneth Casson Leighton Feb. 1, 2009

Feb. 1, 2009

http://bugs.winehq.org/attachment.cgi?id=19132 ok this is the beginnings of an implementation of messagemode, it passes the test1 and send2recv2 tests and fails the shortread test as part of PeekNamedPipe(). i'm not exactly sure why, yet. i get the distinct feeling that there's confusion over who writes into the wineserver data structures what the "availdata" is. msrpc.exe says "set availdata to 9", msrpcd.exe says "set it to 0, we did a write!" and it's all just ohhhh dear. also i have double-copies of server_set_named_pipe_info(), one in kernel32 and another in ntdll because i am using it in both places, i think SetNamedPipeHandleState() should be calling an NtFsControlIo rather than using server_set_named_pipe_info() but for the life of me i _really_ don't want to be finding out what the heck that function is :) hmm, maybe i can find out by copying ntdll.dll over to wine and doing a WINEDEBUG=trace+ntdll,kernel32 to see what functions get called. anyway the primary purpose of submitting the patch is to ask people if i'm along the right lines. anything seriously objectionable, etc. etc. l.

3 6

Fwd: A basic implementation for increased security in wine proposal
by Guillaume SH Feb. 1, 2009

Feb. 1, 2009

---------- Forwarded message ---------- From: Guillaume SH <gsh.debianlists(a)gmail.com> Date: 2009/2/1 Subject: Re: A basic implementation for increased security in wine proposal To: Marcus Meissner <marcus(a)jet.franken.de> Hi Marcus, I stand corrected, as it appears I was way too naive in my understanding of software security, hence the example I provided. Regarding you explanation justifying there is no need to protect API against misuse, I am still not convinced, but I will think about it and try to get to a thorough understanding. Thank you for clarifying, Guillaume 2009/2/1 Marcus Meissner <marcus(a)jet.franken.de> > On Sun, Feb 01, 2009 at 10:41:25AM +0100, Guillaume SH wrote: > > > Hi Paul, > > > > You asked me to actually describe the security I am concerned about, so I > am > > going for it : > > > > Imagine an ill-intentioned people, call it the attackers. By the mean of > > simply creating the following C application (based on classical "Hello > > word") : > > > > > > #include needed header > > > > int main (int argc, char * argv[]) > > { > > /* printf ( "Hello world!" ); */ > > GetOverlappedResult(0, NULL, NULL, FALSE); > > > > return EXIT_SUCCESS; > > } > > > > > > Running this application on wine, I get to have my crash, with the > > possibility of an exploit. So all I have to do know is to find a vector > to > > make you and some other people willing to run my application. > > > > I won't describe in detail the way to perform the exploit as : > > 1 - I don't know how to proceed and I don't want to > > 2 - It would be showing poor sense of responsibilities > > If you can run an application ... it already can do everything! > > No need to protect APIs against misuse, they run at the same privilege > level as your code. > > Ciao, Marcus >

2 1

Re: [PATCH] kernel32: handle section=NULL in WritePrivateProfileStructW (Coverity)
by Nikolay Sivov Feb. 1, 2009

Feb. 1, 2009

Marcus Meissner wrote: > Hi, > > CID 69, section name NULL will just crash in the calls below and > without it we cannot work anyway. So return FALSE; > > Ciao, Marcus > --- > dlls/kernel32/profile.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/dlls/kernel32/profile.c b/dlls/kernel32/profile.c > index 3c5ef1c..5dddc23 100644 > --- a/dlls/kernel32/profile.c > +++ b/dlls/kernel32/profile.c > @@ -1799,6 +1799,8 @@ BOOL WINAPI WritePrivateProfileStructW (LPCWSTR section, LPCWSTR key, > > if (!section && !key && !buf) /* flush the cache */ > return WritePrivateProfileStringW( NULL, NULL, NULL, filename ); > + if (!section) > + return FALSE; > > /* allocate string buffer for hex chars + checksum hex char + '\0' */ > outstring = HeapAlloc( GetProcessHeap(), 0, (bufsize*2 + 2 + 1) * sizeof(WCHAR) ); > What about a test on this? Does native module crash or not?

1 0

Re: [PATCH] winspool.drv: Check return value of EnumPrintersA
by Detlef Riekenberg Feb. 1, 2009

Feb. 1, 2009

On Sa, 2009-01-31 at 11:09 +0100, Marcus Meissner wrote: > - EnumPrintersA(PRINTER_ENUM_LOCAL, NULL, 5, NULL, 0, &needed, > &num); > - if(needed) { > + if (EnumPrintersA(PRINTER_ENUM_LOCAL, NULL, 5, NULL, 0, &needed, > &num) && needed) { EnumPrinterA must always update "needed". "nedded" is 0, when EnumPrintersA failed or when no printer is installed. Line 1555 has similar code -- By by ... Detlef

2 1

A basic implementation for increased security in wine proposal
by Guillaume SH Feb. 1, 2009

Feb. 1, 2009

Hi project, Following the two previous threads, I am posting here a draft patch implementing my proposal. So, to begin with I will remind you the principle : All function callable from outside wine, should be added sanity checks : if safe_mode_on and (sanity_check1_failed or sanity_check2_failed [...] ) { ExitWineCleanlyAndAdvertiseUser; } safe_mode_on value being read from registry (one and only time at wine startup). So if safe_mode_on is set to true, sanity check are performed and in case of failure wine advertise user and terminate cleanly Else, sanity check aren't performed and on a bad input wine is crashing. I've only produced a basic implementation, clearly marking as TODO items left to be done (by the way they are too much for me to handle, as I am no match for you when it comes to implementation). My goal here is firstly to demonstrate feasibility (hardly reached) and usefulness of the proposal. Secondly it is to provide something concrete. Please note than "unsafe" mode behave exactly the same than latest git version of wine (some more operations occur, however, so is not strictly equal in term of performance) I tested the two modes with the help of wine test suite, restricted to kernel/file.c, test_overlapped and I considered only : all must-be-successful tests GetOverlappedResult(0, NULL, &result, FALSE); GetOverlappedResult(0, &ov, NULL, FALSE); (these last two cannot be used in the same run, in either mode) Results are as follow (test are wine_test calls wine on linux(1) platform only ) : 1 - all must-be-successful tests 100% succeed in the two modes 2 - in safe mode, the last two triggers the user message and wine exit 3 - in unsafe mode, the last two triggers a crash Consequently, based on theses results no regression is identified. As I received some more informations in last thread (thank you for enhancing my comprehension of the problem), I will again expose the problem, taking them into account : The problem I am considering (and I may be mistaken here as I am not an expert) is called "Unchecked Error Condition"(2) and it is a referenced weakness (CWE id 391), rated "Medium" in likelihood of exploit, by serious people. Personally, I don't mind that Microsoft is ignoring it and promote usage of early crash or whatever. You are providing a software, presenting security defects that you choose not to fix because they are compliant with your goals. Consequently, at the very least you should explicitly advertise your users, confronting them with their responsibilities. I have read(3) on winehq a warning stating that wine is beta software, not ready for general use. I have read too about the "bug for bug" compatibility. So user's advertisement about security is rather thin and implicit. Please consider the problem, you need to do something about it, it is your responsibility. And continue the good work, you rocks ! Guillaume (1) wine version : wine 1.1.14 with the attached patch applied on top of it OS : debian testing amd64 (2) http://cwe.mitre.org/data/definitions/391.html (3) http://www.winehq.org/about/ PS : I have observed that you are very active about fixing other security issues : + buffer overflow + NULL pointer dereference + variable signedness + ... I seems to me that hopefully, you performs those fixes without consideration for "Is windows doing the same ?". I will be sad the day I will see a commit "Remove resource release because Windows is doing the same" or "Remove buffer overflow fix because app A (2 million copies sold) rely on it".

4 7

Re: dinput: Move gain support from effect to device
by Vitaliy Margolen Feb. 1, 2009

Feb. 1, 2009

Vincent Pelletier wrote: > Hi. > > Windows supports setting force feedback effect gain at 2 levels: > - device > - effect > There is support for the former on Linux, but not for the latter. > > > + DWORD ff_gain; > }; ... > + This->ff_gain = max(0, (int) pd->dwData); First why do you typecase DWORD to (int) to assign to DWORD? Second DWORD will always be > 0. If you want to check it against limit then just check it being <= 10000 otherwise return error. > + if (This->joyfd != -1) { You should be checking This->base.acquired instead of fd. > + event.value = This->ff_gain * 0xFFFF / 10000; You should use MulDiv instead because this can be optimized out by compiler into something that won't be as accurate. Vitaliy.

2 1

Wine magazine articles?
by Dan Kegel Jan. 31, 2009

Jan. 31, 2009

Hey everyone, does Wine have a gallery of press clippings anywhere? I couldn't find one, so I started one at http://wiki.winehq.org/Reviews just for long-form reviews. If you remember any good reviews of Wine (1.0 or later especially), please link them in there. - Dan

1 0