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

IMM / IME work
by Aric Stewart June 16, 2016

June 16, 2016

Hello all, I know this will only interest a small portion of you but thought i would give a quick update on the state of IMM32 since I have brought it to a major milestone. All the main patches are in which now separate IMM32 and IMEs. There is still more work to do but the major framework is in place. X11 XIM processing should be unchanged. However wine can now begin to load native windows IMEs as well. I have tested with windows ATOK20 (a popular Japanese IME) and successfully had text processing in a fully IME aware application. There are still clear issues to resolve in many aspects of this processing but we have forward progress. ImmInstallIME does not work yet, nor does switching keyboards. So to get the native IME to work you need to add this registry key. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\<keyboard layout>] "Ime File"=<IME filename> so for example for ATOK20 in Japanese i used. [System\\CurrentControlSet\\Control\\Keyboard Layouts\\e0010411] "Ime File"="ATOK20W.IME" I would love to hear how well things work. I am sure using native IMEs will quickly show us many places where IMM32 needs to be improved. One issues I am going to investigate next is that sometimes non x11drv ime initialization, if occurring too early, causes x11drv to fail to create windows. I have not investigated with the latest changes to xim.c (which may already correct this problem) but if you see this problem this patch may help and i believe the IME_UpdateAssociation(NULL) is already unneeded. diff --git a/dlls/winex11.drv/xim.c b/dlls/winex11.drv/xim.c index d4df9f7..0c98136 100644 --- a/dlls/winex11.drv/xim.c +++ b/dlls/winex11.drv/xim.c @@ -475,7 +475,6 @@ static void X11DRV_OpenIM(Display *display, XPointer ptr, XP XUnregisterIMInstantiateCallback(display, NULL, NULL, NULL, X11DRV_OpenIM, wine_tsx11_unlock(); IME_XIMPresent(TRUE); - IME_UpdateAssociation(NULL); } thanks, -aric

5 7

What happened to the Fedora packages?
by Neal Gompa Aug. 2, 2014

Aug. 2, 2014

What happened to the Fedora packages? They have not been updated since 0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro supported has the up to date packages!!! And why does the Red Hat packages site not go to the SourceForge site as it does for SUSE packages and the others?? I have not really had the guts to ask until now, because I thought that maybe there was a slump, but now, its getting annoying!! And Fedora just released Fedora Core 5 yesterday!!! Please tell me new packages will be ready soon!!! Compiling WINE always crashes my computer, so I prefer to use the RPMs...

10 18

winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?
by Detlef Riekenberg Oct. 9, 2013

Oct. 9, 2013

Hi. >From which configuration does the "ERROR_INVALID_NAME" came from, when calling GetDefaultPrinter(NULL, &size) and no Printer is installed? This Test is Present in the current "dlls/winspool/tests/info.c". MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer is installed: http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in this Situation. -- By By ... ... Detlef

3 3

Wine runs IE7!
by Hans Leidekker Nov. 26, 2010

Nov. 26, 2010

Well, sort of. I found bugs in shell32, rpcrt4, comctl32 and wininet that I had to implement, stub and override my way past before it would render a page, but finally, here's the obligatory screenshot. -Hans

3 2

meaning of "Hardware" field in bugzilla?
by Dan Kegel Dec. 13, 2009

Dec. 13, 2009

Does "mac" mean "powerpc mac only"? I rather thought it meant "apple macintosh", regardless of cpu. I ask because Austin has just gone through and changed lots of "mac" bugs to "pc" even though the bugs were on Intel macs, which just seems wrong.

8 8

re: Wine t-shirts?
by Dan Kegel Sept. 3, 2009

Sept. 3, 2009

Maarten wrote: > Why don't we have wine t-shirts any more? I dunno, where were they before? I just looked, couldn't find any on cafepress.com. I'd like to bring back the Codeweavers drunken penguin t-shirts, perhaps with a slightly more generic Wine design. Coincidentally, I found some site on the net had taken the logo from that shirt and erased the Crossover logo from the wine bottle; here's a cleaned-up copy: http://kegel.com/wine/wine-penguin-corkscrew.png

15 34

winequartz.drv Mac OS X UI discontinued?
by Adam Strzelecki July 11, 2009

July 11, 2009

Hi, I know that CodeWeavers supports quite nicely Mac builds of Wine, and CrossOver for Mac, yet all of them are X11. There was also once Darwine - an effort to provide Carbon Wine UI driver and Mac optimizations & L&F. Pretty many of those were merged back to Wine, but not winequartz.drv. Do you guys think about reviving winequartz.drv? This would greatly improve Wine on Mac as we could have native Mac fonts handling that's faster than FreeType, Dock icons for Wine applications, and few others. There's still old copy of the it hanging around, but it is abandoned, and no longer compiles with Wine. Or I think it would be cool to write new winecocoa.drv or sthing like that, as Apple officially states that Carbon is deprecated. While it is not well documented, it is pretty easy with Cocoa to make console non-bundled process to be UI foreground process and handle events and Dock: (This code is copyrighted by myself ;P) > int main(int argc, const char * argv[]) { > ProcessSerialNumber psn = {0, kCurrentProcess}; > OSStatus returnCode = TransformProcessType(&psn, > kProcessTransformToForegroundApplication); > SetFrontProcess(&psn); > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > [NSApplication sharedApplication]; > > NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"]; > [NSApp setApplicationIconImage:icon]; > > [NSApp finishLaunching]; > > NSWindow *window = [[NSWindow alloc] > initWithContentRect:NSMakeRect(0, 0, 100, 100) > styleMask:NSTitledWindowMask| > NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask > backing:NSBackingStoreBuffered defer:NO]; > [window center]; > [window setTitle:@"Test"]; > > NSButton *button = [[NSButton alloc] > initWithFrame:NSMakeRect(10, 10, 80, 80)]; > [button setTitle:@"What?"]; > [button setBezelStyle:1]; > [[window contentView] addSubview:button]; > [button release]; > > [window makeKeyAndOrderFront:NSApp]; > > while(1) { > NSEvent *event = [NSApp > nextEventMatchingMask:NSAnyEventMask > untilDate > :[NSDate distantFuture] > inMode:NSDefaultRunLoopMode > dequeue:YES > ]; > if(event) [NSApp sendEvent:event]; > } > [pool release]; > return 0; > } BTW. I heard that someone previously working for Wine project is now in Apple, it is true? Regards, -- Adam Strzelecki |: nanoant.com :|

20 55

Wine translation statistics sources
by Mikołaj Zalewski June 22, 2009

June 22, 2009

Hi, I didn't update the translation statistics (http://www.mikolaj.zalewski.pl/wine-transl/) very regularly lately - my server is a bit broken and I can't run the scripts from cron but have remember to do it manually from a different computer. I have plans to fix it, but in the mean time, as some people may want fresh data, I have finished the changes I've been working on and uploaded the sources. It should be very easy to run them on ones machine and check the tree one has on disk - there is a README with explanations. The archive is available at http://www.mikolaj.zalewski.pl/dl/wine-transl.tgz . It is the latest version that adds support for dumping/diffing dialogs. Mikolaj Zalewski

8 17

Wine on Windows - wiki notes
by David Gerard March 12, 2009

March 12, 2009

Wine on Windows is an idea of real-world usefulness, as newer versions of Microsoft Windows increasingly fail to support apps Wine still supports. I've started a wiki page: http://wiki.winehq.org/WineOnWindows This covers my experiments with the three main POSIX layers (Cygwin, MinGW and Interix) on XPsp3. Various people have told me they've got it to work before (native compilation and install on Windows), but I seem to be the one gathering data :-) If anyone who's done it could please (a) put there what they did with what versions of Wine and tools (b) check with current Wine, that would be most appreciated. - d.

4 7

Re: D3D: Implement vertex blending in drawStridedSlow
by David Adam March 4, 2009

March 4, 2009

2009/1/25 Claudio Ciccani <klan(a)users.sf.net> > > The patch implements a software fallback for vertex blending in > drawStridedSlow, fixing Bug #6955. > Although vertex blending is an old and outdated extension, there are > still many applications(games) relying on it nowadays. This because the > extension is generally supported by Direct3D, either directly in > hardware (using vertex programs) or in software. > This patch makes NOLF2 demo crashes. > > > Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e6095c7 ESP:0033f0b4 EBP:0033f1ec EFLAGS:00010246( - 00 -RIZP1) EAX:00ec1b28 EBX:7e6bbc54 ECX:0000014c EDX:00000000 ESI:00000048 EDI:00000000 Stack dump: 0x0033f0b4: 00000000 00000000 00000000 3f800000 0x0033f0c4: 0033f110 7d05e000 7c03d008 7c7aa346 0x0033f0d4: 00000000 00000003 7e6bc7a0 7e69ee95 0x0033f0e4: 7e69e648 00000001 0000000c 00000010 0x0033f0f4: 795a5f68 7d09c0ac 0002d008 00ebd44c 0x0033f104: 00eba698 00ebd7a8 00000000 00000007 Backtrace: =>0 0x7e6095c7 drawStridedSlow+0x697(iface=0xeba698, sd=0xebd44c, NumVertexes=72, glPrimType=4, idxData=0x31dca00, idxSize=2, minIndex=0, startIdx=0) [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d (0x0033f1ec) 1 0x7e60ea1b drawPrimitive+0x101b(iface=0xeba698, PrimitiveType=4, NumPrimitives=24, numberOfVertices=24, StartIdx=0, idxSize=<is not available>, idxData=(nil), minIndex=0) [/home/david/wine/dlls/wined3d/drawprim.c:1024] in wined3d (0x0033f55c) 2 0x7e5e41f9 IWineD3DDeviceImpl_DrawIndexedPrimitive+0xe9(iface=0xeba698, PrimitiveType=WINED3DPT_TRIANGLELIST, minIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/wined3d/device.c:5314] in wined3d (0x0033f5cc) 3 0x7e6d43b6 IDirect3DDevice8Impl_DrawIndexedPrimitive+0x96(iface=<register ESI not in topmost frame>, PrimitiveType=D3DPT_TRIANGLELIST, MinVertexIndex=0, NumVertices=24, startIndex=0, primCount=24) [/home/david/wine/dlls/d3d8/device.c:1419] in d3d8 (0x0033f5fc) 0x7e6095c7 drawStridedSlow+0x697 [/home/david/wine/dlls/wined3d/drawprim.c:307] in wined3d: flds 0x0(%ecx) 307 m = &stateBlock->transforms[WINED3DTS_WORLDMATRIX((indices ? indices[0] : 0))].u.m[0][0]; Modules:

3 4

Wine desktop integration: current directory of app launched with doubleclick?
by Dan Kegel Feb. 15, 2009

Feb. 15, 2009

I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files. My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing. ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work. If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME. I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@" That worked better; it let ViewSel.exe launch the DICOM viewer. So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan

4 9

RE: First complete test run passing on a Windows platform
by Ge van Geldorp Feb. 9, 2009

Feb. 9, 2009

> From: Reece Dunn <msclrhd(a)googlemail.com> > > The Wine tests are now passing on a Windows XP machine > (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group _XP). Actually, that was not the first time. On 20 Jan an XP machine passed: http://test.winehq.org/data/e9d8c9f572998054b1f9c386ea81a3570c65f2d2/#group_ XP And on 27 Jan a 2003 machine: http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/#group_ 2003 > Two of the other four only have 2 or 3 failures. > > The 2003 group has 3 machines with 1 failure each > (urlmon:protocol on one, user32:menu on the others). I've sent a patch for the user32:menu failure a couple of weeks back but it got blackholed http://www.winehq.org/pipermail/wine-patches/2009-January/067483.html I won't be submitting test results next week but don't worry, I'll be back... Ge.

5 11

Re: Support for Dragon NS in Wine
by Susan Cragin Feb. 8, 2009

Feb. 8, 2009

3 2

http://wiki.winehq.org/NamedPipes
by Luke Kenneth Casson Leighton Feb. 6, 2009

Feb. 6, 2009

rob, hi, regarding the above wiki page - there is no "obstacle". you can use any of the code that i wrote for samba (about 100,000 lines of code), i released all of it into the public domain, on dec 16th, 2005. there's enough there so that you can do an entirely "hands off" approach, getting packets in and out using (see last post!) surprise,surprise, emulated named pipes. what i did for tng was to create a "packaging" system which sent security contexts (complete security descriptors and other identifiying information) over a unix socket. it was completely transparent as far as smbd was concerned, which just "handed it around" to the appropriate daemons. i asked jeremy to add in simple support for this into main samba several times. the last time (dec 2005) once _again_ he fucked about, but did actually agree that it was a good idea. samba having "break-out" for named pipes traffic is one of those absolutely _essential_ things that should have fucking well gone into the samba source code a _long_ time ago. around 1998 would have been good. _several_ projects would enormously benefitted - including samba - if that had happened. sun microsystems, who bought the [well known to be a complete piece-of-crap] port of nt to unix, AFPS, for $USD 4m and were utterly appalled by the poor quality of the implementation of the smb server gave serious consideration to dumping it, keeping the MSRPC services, and riding off the back of samba.... .. via _guess what_! a named pipe "break-out" interface. which, of course, doesn't exist. so they couldn't do it. but gordon did discuss it with me, saying things like, "y'know, if samba had a way in to its named pipes interface..." and guess what? in order for you to do named pipes via samba, you need a named pipe "break-out" interface. guess how luke howard implemented XAD (which he sold to novell a couple of years ago)? he implemented a patch to samba which provided a named pipe "break-out" interface. that patch was released back in about 2002 and has never been incorporated into samba. the protocol for a break-out interface is very simple: you need four functions ( and they can be done in as little as about 300 lines of c-code, as a patch to samba) 1) open named pipe connection 2) read pipe 3) write pipe 4) close pipe if you implement that in a dynamically-loadable .so, style, as a vector table (see e.g. apache2 module interface for example) then you can dump a .so into a directory which samba can pick up. any data that comes in from SMB will then "activate" the .so, call the open_named_pipe function in the vector table, and you're away. you release the code of the .so under the LGPL, that gets "GPL'd" by samba, license problem is solved. so, with a small patch to samba, the means to take control of the direction of wine is within _your_ hands. because the dynamically loadable .so conforms to the "break-out" interface and is loaded _by_ samba, on demand, and the code in it is part of Wine and communicates using Wine protocols - entirely under your control. ... you know... it would actually be a lot easier to integrate wine with samba tng, because the infrastructure to communicate by emulated NamedPipes already exists. take a look at the following functions: ncalrpc_l_connect ncalrpc_l_close_socket receive_msrpc msrpc_send all of which are in lib/msrpc-client.c - you'll see in there that there are corresponding functions for the samba tng win32 port - CreateNamedPipe, ReadFile, WriteFile, WaitNamedPipeHandleState, CloseHandle etc. which will help give you some _really_ big clue-handles to understand the corresponding "emulating" functions using unix sockets. you _should_ also recognise the ncalrpc_srv_get_user_creds function and its equivalent client-side "sender" ncalrpc_l_authenticate. these two are a matched pair of functions which marshal and unmarshal an NT security context [based on a NET_USER_INFO_3 structure - recognise that one? :) it's a stub in wine - now you have some code that gives it purpose! ] basically after a connect (ncalrpc_l_connect) the client sends the user creds _immediately_, and the server picks them up, and saves them in its internal context (for later passing around etc). also they end up getting used to do seteuid() but as the entire protocol was used by root _only_ it was perfect safe to do this. the unix sockets were protected 600 with the directory they were in being protected 755 because some unixen _still_ bloody well let you access a unix domain socket even if its permissions were 600, all owned by root, all services running _as_ root, so one daemon being a client passing over a security context that told _another_ daemon running as root to seteuid to a user's uid was no big hairy deal. except that andrew thought that i was some sort of fucking 17-year-old incompetent student, and he didn't like the thought of me actually being a capable unix systems programmer. thus, this code could be justified as never going into samba (even though a similar implementation was designed _by_ him for use in winbind). _really_ interesting bit of hypocrisy going on there. the sad thing is that it's stopped _so_ much progress in free software, it's unreal. anyway - you can pick up that code with: cvs -d anoncvs(a)anoncvs.samba-tng.org:/home/cvsroot co tng it's anoncvs - just press return look in tng/source/lib/msrpc-client.c btw don't be fooled into thinking that just because you're on loopback - running samba and wine on the same machine and only processing requests that come in or go out over 127.0.0.1 - don't be fooled into thinking that you can throw away the security context (the NET_USER_INFO_3 stuff) - you can't. you _really_ need to keep it around, and pass it back-and-forth. so - to recap what the protocol / procedure is: * a small .so has already been dropped into samba's lib/ directory which has been dynamically-loaded; any SMB-based "NamedPipe" traffic that is NOT destined for internal samba services (such as \\PIPE\lsarpc etc) is handed to this .so. the .so, when an incoming "ConnectNamedPipe" request is made, will direct the contents, pretty much verbatim BUT pre-pending the security context "blob" (see above) to any initial connects. * any win32 programs that call CreateNamedPipe will result in a call .. ... you know what? this is getting complex - and i'm spending quite a bit of time writing it. i designed this stuff, once, and it worked. wine needs it. samba needs it. so, i'm really _really_ sorry to have to bring this up - but it's a quite important point: if you can find someone to pay for the necessary development, i'm more than happy to do the work. i'm also happy to help advise people on how this can be implemented (if the above clues and directional guides aren't enough) it's been ten years since this kind of cross-project integration stalled: i've watched the development of wine go its way, and samba go its way, and ntfs filesystem drivers for linux go _their_ way, and all of these projects don't _actually_ cooperate or link together properly. nobody's actually _paid_ any fucking money to coordinate and liase with these projects. there's people paid to work on linux; there's people paid to work on wine; there's people paid to work on samba. and the only people who really suffer for lack of this really important strategic interoperability is: users. so can we _please_ pull our collective fingers out of our arses, get some sponsorship and funding from _somewhere_ and get moving? that last said with the utmost of respect :) l.

2 5

Quick and dirty testcases for MS-DOS API?
by Dan Kegel Feb. 4, 2009

Feb. 4, 2009

Looking at http://bugs.winehq.org/show_bug.cgi?id=17181 I get a feeling that we really need some testcases to verify we conform to the 16 bit MS-DOS API. Yeah, even though 16 bit is on the way out, there's still some use for a few win16 programs, and they use MS-DOS for file I/O. We could merge in http://win16test.googlecode.com, but that requires the Watcom C compiler, and "apt-cache search watcom" still comes up empty (unless you're on Ark Linux, see http://www.openwatcom.org/index.php/Installing_Open_Watcom_on_Linux ) And the Linux build had problems building DOS apps last time I tried anyway. But "apt-get install nasm" works great, so let's use it to run just a few crucial testcases, in particular, the one that keeps DOS apps from recursively deleting directories. What I'm thinking is to add a configure check for nasm. If it's present, and the target is 32 bit Intel, dlls/winedos/tests would use it to assemble a few simple assembly testcases. The test cases would be run from a normal test case (so no deep integration), and only when running on a machine capable of running 16 bit code. I'll probably have an include file for routines to print PASS and FAIL, but otherwise it'll be very, very bare bones. 'Course, I have no idea when I'll have time to do this, but I imagine it won't be too complicated. It wouldn't bother me at all if somebody beat me to it. - Dan

7 13

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

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

Feb. 2, 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

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

Fw : BOOL WINAPI versus BOOL in d3dx9 and d3dx8
by paulo lesgaz Jan. 31, 2009

Jan. 31, 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

1 0

Running the fusion tests
by Paul Vriens Jan. 31, 2009

Jan. 31, 2009

Hi, I didn't look into this yet but currently the fusion tests are only run on Wine. I can happily run the fusion tests on my XP box if I just crossbuild these tests. It's only when run through winetest that these tests are not run. I guess it has to do with how this library should be loaded (not directly through LoadLibrary)? -- Cheers, Paul.

1 0

Reliable Datagram / Stream behaviour of NT Pipes
by Luke Kenneth Casson Leighton Jan. 31, 2009

Jan. 31, 2009

folks, hi, if you recall, i implemented nt named pipes in samba tng, and also implemented the use of nt named pipes as a transport in freedce, for when i ported freedce to win32. so i have quite a bit of experience when it comes to nt named pipes. i've encountered some bugs (thanks to python again :) ) in the wine implementation of nt named pipes, and have raised it as a bug http://bugs.winehq.org/show_bug.cgi?id=17195 but it started getting complicated so i thought i'd best raise it here. the behaviour of nt named pipes is a cross between datagrams and streams - it's the best of both worlds: * absolute inviolate message sizes (datagrams) * absolute inviolate message order (streams). the issue with the implementation of nt named pipes on top of _just_ streams (unix sockets) is this: two packets sent get blatted into one read. you _cannot_ allow this to happen - it screws applications up _royally_, as applications _critically_ depend on the number of reads and writes being interleaved, thanks to the characteristics of NamedPipes. standard unix applications / protocols (SMTP, etc) have no choice but to do manual synchronisation built-in to the protocol, because standard unix streams don't _have_ this "free feature". so, in samba tng, the emulated-implementation of nt named pipes (on top of unix sockets) i was forced to send a (32-bit) length field actually _in_ the data stream, just like is done in NetBIOS. the NetBIOS protocol (which was implemented by IBM, not microsoft) sends a 16-bit length field followed by that exact number of bytes. again, NetBIOS implements a "reliable datagram-stream" protocol on top of standard unix streams (tcp stream, this time) inexplicably, unix simply... is ... entirely... missing this concept. so, i'm sorry to have to tell you this, but you are absolutely forced to emulate it (by sending length, data, length data), just like everyone else ever has. so, send (write) is simple: write out the length field, write out the data. done. dead simple. read is... tricky. you _may_ have to keep track of having read the length, already. or, of how _much_ has been read already, of the "current packet being read". .... *walks through source code a bit...* ... i'm veery tempted to say "can i have a go at implementing this?" but... i know it'll be ... how-to-say... eeenteresting :) should i try? would an extra server message need to be added (for read), so that the server can keep track of how much data has been read back (of the current datagram)? l.

2 3

New Coverity run
by Paul Vriens Jan. 31, 2009

Jan. 31, 2009

Hi, I've been in touch with David Maxwell and he looked into the 'lack' of reports since the end of October. -- Cheers, Paul.

2 2

Re: gdi32: Remove unneeded check. (Coverity)
by Rob Shearman Jan. 31, 2009

Jan. 31, 2009

2009/1/27 Kai Blin <kai.blin(a)gmail.com>: > > lcdfilter = FT_LCD_FILTER_DEFAULT is hardcoded, so the check is always true. > > This fixes Coverity CID 816 > > diff --git a/dlls/gdi32/freetype.c b/dlls/gdi32/freetype.c > index 1ca6953..dfbcf2f 100644 > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -4783,18 +4783,15 @@ DWORD WineEngGetGlyphOutline(GdiFont *incoming_font, UINT glyph, UINT format, > (format == WINE_GGO_HRGB_BITMAP || format == WINE_GGO_HBGR_BITMAP)? > FT_RENDER_MODE_LCD: FT_RENDER_MODE_LCD_V; > > - if ( lcdfilter == FT_LCD_FILTER_DEFAULT || lcdfilter == FT_LCD_FILTER_LIGHT ) > + if ( render_mode == FT_RENDER_MODE_LCD) > { > - if ( render_mode == FT_RENDER_MODE_LCD) > - { > - lpgm->gmBlackBoxX += 2; > - lpgm->gmptGlyphOrigin.x -= 1; > - } > - else > - { > - lpgm->gmBlackBoxY += 2; > - lpgm->gmptGlyphOrigin.y += 1; > - } > + lpgm->gmBlackBoxX += 2; > + lpgm->gmptGlyphOrigin.x -= 1; > + } > + else > + { > + lpgm->gmBlackBoxY += 2; > + lpgm->gmptGlyphOrigin.y += 1; > } > > width = lpgm->gmBlackBoxX; It doesn't make much sense to leave the lcdfilter variable in the function if you're going to remove the if condition depending on it, since it only has one other use. However, It might have been the intention of the author of this code that this is setting to be changed at compile time (or runtime through a registry tweak) and have the code do the appropriate thing - in that case it would have been better to put the variable at the top of the file. -- Rob Shearman

3 2

Re: msadp32.acm : block align and adpcm extra data
by Vincent Pelletier Jan. 30, 2009

Jan. 30, 2009

Le Thursday 22 January 2009 16:25:42 Stefano Guidoni, vous avez écrit : > This patch solves bug 7385: > Function ADPCM_StreamSize must return a > buffer size, which is a multiple of block align. > This buffer size is > calculated taking into account input-blockalign, output-blockalign and > adpcm-samplesperblock. Hi. Excuse me for contacting you directly, but that patch didn't enter the source tree, because of the "while" loops. I've been trying for hours to guess by trial and (tons of) error the right formula not involving any "magic" number (besides 7, which is the number of bytes per channel in adpcm block header afaik), but I could not reach the right result: after ~ten seconds, the result of my computation diverges from yours, and audio starts repeating/skipping. Probably operation rounding errors. and/or integer overflows. Could you explain me how you reached that formula ? Mainly, I don't understand why there is no trace of the number of samples per seconds, nor why you multiply a plock align with another block align in the denominator of source size computation when source is adpcm. By advance, many thanks for enlightening me. -- Vincent Pelletier

1 0

request for windows test: GetPrivateProfileSectionNamesA
by Marcus Meissner Jan. 30, 2009

Jan. 30, 2009

Hi, Could someone please test those, I want to see if the second or third crash on Windows to handle those borderline cases. Ciao & Thanks, Marcus --- dlls/kernel32/tests/profile.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/dlls/kernel32/tests/profile.c b/dlls/kernel32/tests/profile.c index 5292c33..feeb7b2 100644 --- a/dlls/kernel32/tests/profile.c +++ b/dlls/kernel32/tests/profile.c @@ -214,6 +214,13 @@ static void test_profile_sections_names(void) WriteFile( h, content, sizeof(content), &count, NULL); CloseHandle( h); + ret = GetPrivateProfileSectionNamesA( NULL, 0, testfile3 ); + ok (ret == 0, "GetPrivateProfileSectionNamesA(NULL,0) returned %d instead of 0\n", ret); + ret = GetPrivateProfileSectionNamesA( buf, 0, testfile3 ); + ok (ret == 0, "GetPrivateProfileSectionNamesA(buf,0) returned %d instead of 0\n", ret); + ret = GetPrivateProfileSectionNamesA( NULL, 1, testfile3 ); + ok (ret == 0, "GetPrivateProfileSectionNamesA(NULL,1) returned %d instead of 0\n", ret); + /* Test with sufficiently large buffer */ memset(buf, 0xc, sizeof(buf)); ret = GetPrivateProfileSectionNamesA( buf, 29, testfile3 ); -- 1.5.6

2 1

Re: [2/13]msctf: implement SetFocus and GetFocus
by Jacek Caban Jan. 30, 2009

Jan. 30, 2009

Hi Aric, Aric Stewart wrote: > --- > dlls/msctf/threadmgr.c | 28 ++++++++++++++++++++++++---- > 1 files changed, 24 insertions(+), 4 deletions(-) > + if (!pdimFocus || FAILED(IUnknown_QueryInterface(pdimFocus,&IID_ITfDocumentMgr,(LPVOID*) &check))) + return E_INVALIDARG; + + This->focus = check; Shouldn't This->focus be released if it's already set? Jacek

2 1

Highest commits per month (ever)
by Paul Vriens Jan. 30, 2009

Jan. 30, 2009

Hi, This month we hit the highest number of commits per month ever : 1307. It's a shame there is weekend coming ;) -- Cheers, Paul.

1 1

DIB Engine - Rebased on wine-1.1.14
by Massimo Del Fedele Jan. 30, 2009

Jan. 30, 2009

As before, separated in 2 patches. Ciao Max

1 0

SHGetFileInfo flag SHGFI_USEFILEATTRIBUTES together with SHGFI_PIDL (regression)
by Petr Sumbera Jan. 30, 2009

Jan. 30, 2009

Hi All, What is story behind following commit? This seems to broke Zoner Photo Studio (tested on OpenSolaris). According to some documentation combination of these flags is not allowed.. http://source.winehq.org/git/wine.git/?a=blobdiff;f=dlls/shell32/shell32_ma… --- a/dlls/shell32/shell32_main.c +++ b/dlls/shell32/shell32_main.c @@ -350,10 +350,6 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, (flags & SHGFI_PIDL)? "pidl" : debugstr_w(path), dwFileAttributes, psfi, psfi->dwAttributes, sizeofpsfi, flags); - if ( (flags & SHGFI_USEFILEATTRIBUTES) && - (flags & (SHGFI_ATTRIBUTES|SHGFI_EXETYPE|SHGFI_PIDL))) - return FALSE; - /* windows initializes these values regardless of the flags */ if (psfi != NULL) { --- Petr

1 0

Re: comctl32: Fix propsheet size calculation (resent)
by Alexandre Julliard Jan. 30, 2009

Jan. 30, 2009

Vitaliy <vitaliy(a)kievinfo.com> writes: > + /* Get non-client size */ > + if (!psInfo->isModeless) > + { > + RECT rc1; > + > + GetWindowRect(hwndDlg, &rc); > + GetClientRect(hwndDlg, &rc1); > + tabOffsetX = rc.right - rc.left - (rc1.right - rc.left); > + tabOffsetY = rc.bottom - rc.top - (rc1.bottom - rc.top); That doesn't make sense. What are you trying to compute here? -- Alexandre Julliard julliard(a)winehq.org

2 3

DIB Engine - Rebased on current tree (Takes 2) - Part 2 - winedib.drv initial implementation
by Massimo Del Fedele Jan. 30, 2009

Jan. 30, 2009

Here part 2. Ciao Max

1 0

DIB Engine - Rebased on current tree (Takes 2) - Part one - GDI32 patches
by Massimo Del Fedele Jan. 30, 2009

Jan. 30, 2009

As there where some changes on GDI32 in latest commits, previous testing DIB Engine had to be modified too. I'm posting here (and in bug 421 page) the 2 needed patches, separated by GDI32 changes and winedib.drv folder. In order to keep patches smaller, I dropped the autogenerated 'configure', but leaving 'configure.ac'.... I guess this is the correct way, probably an autoconf is needed to regenerate the configure file. I was asked to separate the commits from Huw Davies, Jesse Allen and me, but as I changed most of the original author's code It'll be somehow difficult and, imho, will make few sense. It can be done, but that would mean to post a great number of patches with the final result quite different from the original one. I let of course the original copyright notices inside files; I'd like original author's opinion if for them is enough. Instructions on how to enable/disable the engine as the same as previous post, and are detailed in BUG 421 page. First part -- GDI32 patches Ciao Max

1 0

Re: gdiplus: GdipCreateBitmapFromHICON implemented (with some tests)
by Alexandre Julliard Jan. 30, 2009

Jan. 30, 2009

Nikolay Sivov <bunglehead(a)gmail.com> writes: > @@ -4,7 +4,7 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = gdiplus.dll > IMPORTLIB = gdiplus > -IMPORTS = uuid shlwapi oleaut32 ole32 user32 gdi32 kernel32 > +IMPORTS = uuid shlwapi oleaut32 ole32 user32 gdi32 kernel32 shell32 It's a bit wasteful to import shell32 just to copy an icon. -- Alexandre Julliard julliard(a)winehq.org

2 1

Wined3d being used with VirtualBox D3D
by Zachary Goldberg Jan. 30, 2009

Jan. 30, 2009

All, An interesting piece from Phoronix about new VirtualBox Direct3D support; which apparently uses WineD3D in the backend. I haven't noticed anything in particular but has Sun been filing bugs / sending patches? http://www.phoronix.com/scan.php?page=news_item&px=NzAyNA --Zach

3 2

Another MSVCRT problem, perhaps __RTDynamicCast()
by Uwe Bonnes Jan. 30, 2009

Jan. 30, 2009

Hello, after registering at http://forms.analog.com/form_pages/rfcomms/adisimpll.asp?ref=ASC-PR-067 you can download ADIsimPLL Version 3.1 for free. Running the program (with richedit from winetricks) it offers to run a tutorial. In the course of clicking next in this tutorial, at some point some form gets filled with \ nonsense double values. This doesn't happen with native msvcrt. I have instrumented msvcrt._ecvt() to print out the number. The number printed is the nonsens number in the form. Appended +relay,+msvcrt looks fishy: 0023:Call msvcrt.__RTDynamicCast(006f7a58,00000000,00543030,00544838,00000000) ret=0044019e trace:msvcrt:MSVCRT___RTDynamicCast obj: 0x6f7a58 unknown: 0 src: 0x543030 {vtable=0x521568 name=.?AVYASymbol@@ ()} dst: 0x544838 {vtable=0x521568 name=.?AVLibDouble@@ ()} do_throw: 0) trace:msvcrt:dump_obj_locator 0x524218: sig=00000000 base_offset=00000000 flags=00000000 type=0x544838 {vtable=0x521568 name=.?AVLibDouble@@ ()} hierarchy=0x524208 trace:msvcrt:dump_obj_locator hierarchy: sig=00000000 attr=00000000 len=3 base classes=0x5241f8 trace:msvcrt:dump_obj_locator base class 0x5241e0: num 2 off 0,-1,0 attr 00000000 type 0x544838 {vtable=0x521568 name=.?AVLibDouble@@ ()} trace:msvcrt:dump_obj_locator base class 0x524190: num 1 off 0,-1,0 attr 00000000 type 0x544818 {vtable=0x521568 name=.?AVLibVariable@@ ()} trace:msvcrt:dump_obj_locator base class 0x5234d8: num 0 off 0,-1,0 attr 00000000 type 0x543030 {vtable=0x521568 name=.?AVYASymbol@@ ()} 0023:Ret msvcrt.__RTDynamicCast() retval=006f7a58 ret=0044019e 0023:Call msvcrt._ecvt(00000001,5f40255f,0000000a,00328dd4,00328ddc) ret=0040a952 0023:Call KERNEL32.TlsGetValue(00000000) ret=7ec3e471 0023:Ret KERNEL32.TlsGetValue() retval=001b0678 ret=7ec3e471 trace:msvcrt:_ecvt num 6606512752554031389059083466263841847175093544956949844249843220093860018640324866\ 420498348423671822060046924282328257865959227190774155226910868635648.000000, digits 10 0023:Call ntdll.RtlAllocateHeap(00110000,00000000,00000050) ret=7ec2de07 0023:Ret ntdll.RtlAllocateHeap() retval=006e4550 ret=7ec2de07 0023:Ret msvcrt._ecvt() retval=006e4550 ret=0040a952 I suspect __RTDynamicCast() to cause the error. Having not much C++ understanding, I don't feel like writing a sensible testcase. Can anybody perhaps have a look? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

report on obscure issues: running out of file handles with python under wine
by Luke Kenneth Casson Leighton Jan. 30, 2009

Jan. 30, 2009

hiya folks, well the saga continues with using python under wine - i thought i'd let you know the analysis and clues so far, in case it rings any bells with anyone, now or in the future. as you're probably aware, there's a limit in nt of 2048 file descriptors which has caused a large number of free software projects quite a lot of grief , e.g. this: http://bugs.mysql.com/bug.php?id=24509. it turns out that python is no different, and i'm just in the process of investigating whether compiling every single c-based module as a builtin saves me enough file handles to be able to not hit the 2048 handles limit. it's really quite stunning. even something as simple as running a single small test script can result in 1,400 file handles being used up. by the time you get to things like the popen-replacement (see msdn KB: Q190351 for a simple code example). anyway - what prompted me to write was that i ran the python.exe with msvcr80 on wine, and the popen-like code segfaulted. under win32 naitive (an actual XP qemu) it failed - gracefully. but, weirdly, python.exe _without_ msvcr80 did _not_ segfault, but, again, same code on XP qemu'd failed gracefully. so, matrix: wine xp-qemu'd vc80 segfault error vc71 ok error in other words, i'm beginning to suspect that the reason for that msvcr80 segfault i was investigating last week is because of running out of file handles, and wine doesn't _have_ that 2048 file descriptor limit that msvcr80 is assuming actually exists. either that, or when you _do_ reach that limit, it results in corruption that an app running msvcr71 doesn't notice. or something. the reason i haven't raised this as a bugreport is because i really don't exactly know what's going on - there are just rather a lot of empirical observations that are ... "out there" :) so i apologise for this being a bit long, and not very specific, and if ever i get anything specific i'll of course raise it as a bugreqeuest, but i didn't want to leave this undocumented. l.

4 5

Re: D3D: Implement vertex blending in drawStridedSlow
by Henri Verbeet Jan. 30, 2009

Jan. 30, 2009

2009/1/25 Claudio Ciccani <klan(a)users.sf.net>: > > + WORD vertexBlendSW : 1; /* vertexBlend software fallback used */ I'm not sure we want to implement vertex blending in software in the first place (rather than through a shader), but you can't just add a bitfield here without changing the padding.

3 9

First complete test run passing on a Windows platform
by Reece Dunn Jan. 30, 2009

Jan. 30, 2009

Hi, The Wine tests are now passing on a Windows XP machine (http://test.winehq.org/data/4b27dfec939d131c9d7e09f97f14dfc7dabe8843/#group…) Two of the other four only have 2 or 3 failures. The 2003 group has 3 machines with 1 failure each (urlmon:protocol on one, user32:menu on the others). Congratulations to everyone involved fixing the tests! - Reece

2 1

re: First complete test run passing on a Windows platform
by Dan Kegel Jan. 30, 2009

Jan. 30, 2009

Wow, that's awesome! A day seven years in the making... 2002: the C test suite is started: http://source.winehq.org/git/wine.git/?a=commit;h=caa03388bcccc64f444f9b4ef… 2003: winetest committed: http://www.winehq.org/wwn/199#Winetest%20Integrated%20&%20Future%20Steps 2004: server to build winetest and parse winetest results set up http://www.winehq.org/wwn/216#A%20Distributed%20Test%20Environment 2009: the test suite passes for somebody besides Alexandre on Wine: http://www.winehq.org/wwn/355#Test%20Suite%20Passes! Anyone have a graph of test suite size vs. time?

2 1

A proposal for increased security in wine - respecting previously expressed needs
by Guillaume SH Jan. 29, 2009

Jan. 29, 2009

Hi wine community, I took some time for reflexion following the thread "A step in the wrong direction, in an ocean of steps in the right direction" and to the explanations some of you kindly exposed to me. As a follow-up I am making a proposal. A - The proposal A1 - The core proposal All function callable from outside wine should implement, as the first task they perform(1), a sanity parameter check. This check hasn't to be systematic, only really used parameters should be checked and only checks assuring those parameters can be safely used the way they are in the function implementation (or in a function called by it). Other check are superfluous and must be discarded. So to decline the proposal operationally, I will take an example(2) : BOOL WINAPI GetOverlappedResult(HANDLE hFile, LPOVERLAPPED lpOverlapped, [...]) if ( lpOverlapped == NULL ) { #Call the function ExitWineCleanlyAndAdvertiseUser } This call being justified by the statement, following some lines later : status = lpOverlapped->Internal; The function ExitWineCleanlyAndAdvertiseUser being something like that : <Result to be determined> ExitWineCleanlyAndAdvertiseUser <Parameters to be determined> #1 - Advertise user outputting a message, for example : "The application you used present a defect. Using it directly expose you to some security issue and indirectly expose others users to some other security issue." #2 - Cleanly release all still allocated resources #3 - Cleanly exit wine A2 - offering flexibility As I have understood that wine community is willing to be able to run all applications written for a Windows platform, even those relying on the worse behaviours of windows, I will propose too to add a registry key for the purpose of enabling / disabling wine "safe" mode. In this case it would make sense that "safe" mode is the default, with possibility to fall-back to "unsafe" mode when needed. B - Advantages / Drawbacks to the proposal Drawback of this solution I can think of are : 1 - It is contrary to the current consensus 2 - It implies a lot of work (even if this can be done bit by bit over a long period time, direction is what matters here) 3 - Detailed implementation of what I presented may very well not be as simple as I imagine, or even impossible 4 - Maybe all the reasons have not been expressed in the previous thread, thus not considered here 5 - It can go against the interest of the author of those apps relying on Windows's bad behaviors (large firms for example) 6 - It doesn't cover all security issue in wine and it doesn't cover at all security issue in the calling app 7 - Performance drop-down may be expected (0,01%, 0,1%, 1%, more ? I don't know how to evaluate) Advantage of this solution I can think of are : 1 - Top-notch level of service to user : I can be informed when I use an unsafe software ! 2 - Encouragement to software industry : I must provide some clean and safe software or wine can judge me "unsafe" (=promoting "best-practices") 3 - Wine is better from it, so people will have a better opinion of wine 4 - Goal reached by wine are far beyond "Windows behaviours on free-OS platform" 5 - Wine is safer so more people will want to use it and to promote its usage I think I will go no further than this proposal, so I leave the rest to you, from simply ignoring it to demonstrate me than I'm wrong or applying a variation, Guillaume (1) TRACE, variable declaration or other task may come before though (2) Please don't argue about the coding style, I am not a technical expert (unlike you) and it would be off-topic

6 5

Re: [1/3] d3dxof: Make parsing more permissive about semicolon and comma in objects
by Paul Vriens Jan. 29, 2009

Jan. 29, 2009

Christian Costa wrote: > > > ------------------------------------------------------------------------ > > Hi Christian, + if ((token != TOKEN_SEMICOLON) && (token != TOKEN_COMMA)) { /* Allow comma instead of semicolon in some specific cases */ if (!((token == TOKEN_COMMA) && ((i+1) < pt->nb_members) && (pt->members[i].type == pt->members[i+1].type) This introduced a DEADCODE warning in Coverity. The code changed was in d3dxof.c but was moved in a later patch to parsing.c. Could you have a look? -- Cheers, Paul.

2 1

Today's git installation error...
by Susan Cragin Jan. 29, 2009

Jan. 29, 2009

When I installed DNS10 today, the included Visual C++ 8.0 runtime does not load, with the following message. fixme:advapi:LookupAccountNameW (null) L"susan" (nil) 0x33f80c (nil) 0x33f810 0x33f804 - stub fixme:advapi:LookupAccountNameW (null) L"susan" 0x131958 0x33f80c 0x132430 0x33f810 0x33f804 - stub ALSA lib pcm_dmix.c:1008:(snd_pcm_dmix_open) unable to open slave fixme:reg:GetNativeSystemInfo (0x7e1487b4) using GetSystemInfo() wine: Unhandled page fault on write access to 0x7de61520 at address 0x7de61520 (thread 0020), starting debugger... p\{EB7D44B1-C2F5-4B7B-9128-CE4C3D427024}\Visual C++ Runtime for Dragon NaturallySpeaking.msi: server.c:594: server_get_unix_fd: Assertion `wine_server_ptr_handle(fd_handle) == handle' failed. err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception. Then I try again, and it does load, and the program installs and runs. ?? I imagine other people have reported this. No need to respond.

2 1

Re: wininet: Implement IsDomainLegalCookieDomainW.
by Juan Lang Jan. 29, 2009

Jan. 29, 2009

Hi Hans, minor point: + FIXME("(%s, %s)\n", debugstr_w(s1), debugstr_w(s2)); Shouldn't that be TRACE? --Juan

2 3

Re: Ge van Geldorp : ole32/tests: Some Windows versions need the class to be registered.
by Rob Shearman Jan. 29, 2009

Jan. 29, 2009

2009/1/26 Alexandre Julliard <julliard(a)winehq.org>: > hr = StringFromCLSID(&CLSID_WineTest, &pszClsid); > ok_ole_success(hr, "StringFromCLSID"); > - strcpy(buffer, "CLSID\\"); > + strcpy(buffer, "Software\\Classes\\CLSID\\"); > WideCharToMultiByte(CP_ACP, 0, pszClsid, -1, buffer + strlen(buffer), sizeof(buffer) - strlen(buffer), NULL, NULL); > CoTaskMemFree(pszClsid); > strcat(buffer, "\\InprocHandler32"); > - error = RegCreateKeyEx(HKEY_CLASSES_ROOT, buffer, 0, NULL, 0, KEY_SET_VALUE, NULL, &hkey, &dwDisposition); > - ok(error == ERROR_SUCCESS, "RegCreateKeyEx failed with error %d\n", error); > - error = RegSetValueEx(hkey, NULL, 0, REG_SZ, (const unsigned char *)"ole32.dll", strlen("ole32.dll") + 1); > - ok(error == ERROR_SUCCESS, "RegSetValueEx failed with error %d\n", error); > - RegCloseKey(hkey); > + if (Register) > + { > + error = RegCreateKeyEx(HKEY_CURRENT_USER, buffer, 0, NULL, 0, KEY_SET_VALUE, NULL, &hkey, &dwDisposition); > + ok(error == ERROR_SUCCESS, "RegCreateKeyEx failed with error %d\n", error); > + error = RegSetValueEx(hkey, NULL, 0, REG_SZ, (const unsigned char *)"ole32.dll", strlen("ole32.dll") + 1); > + ok(error == ERROR_SUCCESS, "RegSetValueEx failed with error %d\n", error); > + RegCloseKey(hkey); > + } > + else > + { > + RegDeleteKey(HKEY_CURRENT_USER, buffer); > + *strrchr(buffer, '\\') = '\0'; > + RegDeleteKey(HKEY_CURRENT_USER, buffer); > + } > +} Ge, This appears to have caused some regressions in running the tests on older versions of Windows: http://test.winehq.org/data/d0e77f8a47016c6f69e3a6b5a8bed8f620f1a8f1/nt4_cw… versus before: http://test.winehq.org/data/f63d950df75bdebbad3278790c6c9d11bfe1b226/nt4_cw… While I can see how using HKEY_CURRENT_USER instead of HKEY_CLASSES_ROOT can help developers using a standard user rather than Admin on Windows, I don't see it as useful in general as a lot of the tests emulate what installers do and hence depend on having full access to the system. -- Rob Shearman

2 1

Wine gecko: javascript in the frame
by Konstantin Kondratyuk Jan. 29, 2009

Jan. 29, 2009

Hi! Javascript which is defined in the frame doesn't work. There is a test in attachement. Run index.html in 'wine iexplore' Correct events for this test (checked up in IE and Firefox): 1. "call f_right script" message 2. "call onLoad" message during loading 3. "call myOnClick" message after click to link Wine gecko ignores all these events. Do you have any advice? Thanks. -- Best regards, Konstantin Kondratyuk.

2 1

Re: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn)
by Rob Shearman Jan. 29, 2009

Jan. 29, 2009

2009/1/26 Aurimas Fišeras <aurimas(a)gmail.com>: > Saturn's error report: > (INCONSISTENT USE) Possible null dereference of variable data+(count-1). > This variable is checked for Null at lines: registry.c:1051 > > Tested on Windows XP > > Changelog: > advapi32: Fix potential NULL pointer dereference in RegSetValueExA > [with test] (Saturn) Excellent, this tool has spotted a corner-case that the code doesn't handle correctly. > From ea7773cc046992e327030fb99935afc5b25c1b4b Mon Sep 17 00:00:00 2001 > From: Aurimas Fischer <aurimas(a)gmail.com> > Date: Mon, 26 Jan 2009 21:55:05 +0200 > Subject: advapi32: Fix potential NULL pointer dereference in RegSetValueExA [with test] (Saturn) > > --- > dlls/advapi32/registry.c | 1 + > dlls/advapi32/tests/registry.c | 4 ++++ > 2 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/advapi32/registry.c b/dlls/advapi32/registry.c > index 52de6c5..88a89db 100644 > --- a/dlls/advapi32/registry.c > +++ b/dlls/advapi32/registry.c > @@ -1055,6 +1055,7 @@ LSTATUS WINAPI RegSetValueExA( HKEY hkey, LPCSTR name, DWORD reserved, DWORD typ > else if (count && is_string(type)) > { > /* if user forgot to count terminating null, add it (yes NT does this) */ > + if (!data) return ERROR_NOACCESS; This should be moved before the comment to avoid the comment relating to the wrong line. > if (data[count-1] && !data[count]) count++; > } > > diff --git a/dlls/advapi32/tests/registry.c b/dlls/advapi32/tests/registry.c > index b63b3e2..0e1b673 100644 > --- a/dlls/advapi32/tests/registry.c > +++ b/dlls/advapi32/tests/registry.c > @@ -383,6 +383,10 @@ static void test_set_value(void) > test_hkey_main_Value_A(name2A, string2A, sizeof(string2A)); > test_hkey_main_Value_W(name2W, string2W, sizeof(string2W)); > > + /* test RegSetValueExA with invalid parameters*/ > + ret = RegSetValueExA(hkey_main, name1A, 0, REG_SZ, NULL, 1); > + ok(ret == ERROR_NOACCESS, "got %d (expected ERROR_NOACCESS)\n", ret); >From the source of RegSetValueExA, this appears to return ERROR_INVALID_PARAMETER on Win9x, so this test case needs to be run on Win9x and fixed if necessary to take this into account. -- Rob Shearman

3 9

Bug in INT32_FindNext blocking Winbench '96?
by Dan Kegel Jan. 29, 2009

Jan. 29, 2009

http://bugs.winehq.org/show_bug.cgi?id=17181 seems to be a bug in our implementation of DOS FindNext. It's one of the bugs blocking Winbench 96 from running. I'm interested in Winbench 96 simply because it's the only mainstream magazine system benchmark for Windows I've ever even remotely gotten to run on Wine. And bless its soul, it carefully checks return values from DOS system calls. I've already sent in a patch for one problem, but would appreciate some help with this FindNext issue. The code is old and tricky; the interesting bit seems to have been written by Eric ficw years ago during dll separation. If anybody wants my copy of Winbench 96 to help get it running, I'd gladly send it... - Dan

1 0

Worldbench?
by Dan Kegel Jan. 29, 2009

Jan. 29, 2009

It's hard to keep the benchmark programs straight. I ran into one called Worldbench today in this review http://www.washingtonpost.com/wp-dyn/content/article/2009/01/27/AR200901270… and I see it's used quite a bit: http://www.networkworld.com/reviews/2008/102908-hps-mini-1000-a-new.html It would be nice if we didn't see reviews like this: http://www.pcworld.com/article/142724/200_linux_desktop_systems_are_no_barg… which say "Because these PCs run Linux, not Windows, we couldn't run our WorldBench 6 Beta 2 test suite on them." It looks like Worldbench 6 has been stuck at beta 2 for a long time, so people still reference Worldbench 5 scores. More info: http://www.worldbench.com/ http://www.pcworld.com/article/122812/how_we_test.html http://www.pcworld.com/article/116888/pc_worlds_worldbench_50.html The benchmark costs $250. Has anybody here tried it on Wine? - Dan

2 2

Should winetest retrieve msi log file on msi test failures?
by Dan Kegel Jan. 28, 2009

Jan. 28, 2009

Looking at test.winehq.org's XP results, it seems we're doing quite well; some of the remaining failures seem to be unusual situations. For instance: msi:msi.c is passing flawlessly on 7 out of 10 computers, and on one of the computers, it has just one failure: http://test.winehq.org/data/8f829034f3fe4da3e7adce2f4685e10ba2e2fe82/xp_fg-… says dlls/msi/tests/msi.c msi.c:254: Test failed: wrong error 1618 1618 is ERROR_INSTALL_ALREADY_RUNNING. Say, can winetest retrieve and display the msi log file on failure? That might be informative...

2 3

Re: Implement BiDi mirroring
by Juan Lang Jan. 28, 2009

Jan. 28, 2009

Hi Khaled, +void doMirror(WCHAR* ch) This should be static. + else if(*ch == mirrored[k].first) + { + *ch = mirrored[k].mirror; + return; + } The else if block is indented one level too many. Thanks, --Juan

2 2

Consistency in programs/winecfg/drivedetect.c
by Ben Klein Jan. 28, 2009

Jan. 28, 2009

I just noticed my first patch got accepted, yay :) commit 8df74a0edb3304dfc26bd524327f9128f63de47f Author: Ben Klein <shacklein(a)gmail.com> Date: Wed Jan 21 21:02:12 2009 +1100 winecfg: Fix a typo in autodetect_drives. I also noticed someone removed the superfluous () around the expression in my patch. I included this for consistency in the file, and note that the same superfluous () appears on lines 244 and 272 in drivedetect.c in current git HEAD. Since this is not a functional thing in any way, and it doesn't matter on the compiler level whether it's (a == (b + c)) or (a == b + c), I'm not sure if it's worth me submitting a patch to correct the consistency. What's the prefered coding style for this situation? :)

1 0

Re: server: Use kernel support for process affinity when available (try 2)
by Alexandre Julliard Jan. 28, 2009

Jan. 28, 2009

Juan Lang <juan.lang(a)gmail.com> writes: > Is this better? This trades a single call to sched_getaffinity per > process to one every time the process affinity is queried. This seems > safer, since a non-Wine process can also change a process's affinity, > but it can have higher overhead. Yes, that's better. But AFAICT sched_get/setaffinity applies to a single thread, not to the whole process. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [twain_32 2/7] Add an interactive set of tests for a selected scanner.
by Jeremy White Jan. 28, 2009

Jan. 28, 2009

> + rc = pDSM_Entry(appid, source, DG_CONTROL, DAT_CAPABILITY, MSG_GET, > &cap); Bletch. Forgot to add --attach. I'll resend the series. Sorry :-/. Cheers, Jeremy

1 0

Re: setupapi: implement pSetupInstallCatalog
by Alexandre Julliard Jan. 28, 2009

Jan. 28, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > + if (!CryptCATAdminAcquireContext(&admin,NULL,0)) > + { > + ERR("Could not acquire security context\n"); > + return ERROR_GEN_FAILURE; > + } > + if (!(cat = CryptCATAdminAddCatalog(admin,catalog,basename,0))) > + { > + ERR("Could not add catalog\n"); > + CryptCATAdminReleaseContext(admin, 0); > + return ERROR_GEN_FAILURE; You should return proper error codes based on the result of the called functions instead of a generic ERROR_GEN_FAILURE. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2]reg.exe: Implement ADD for REG_SZ
by Alexandre Julliard Jan. 28, 2009

Jan. 28, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > + if (key_name[0]=='\\' && key_name[1]=='\\') > + { > + static const WCHAR remoteW[] = {'U','n','a','b','l','e',' ','t','o',' ','a','d','d',' ','k','e','y','s',' ','t','o',' ','r','e','m','o','t','e',' ','m','a','c','h','i','n','e',' ','%','s','\n',0}; This should go in the resources like the other messages. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shdocvw: OnAmbientPropertyChange should refresh all properties with a DISPID_UNKNOWN
by Jacek Caban Jan. 28, 2009

Jan. 28, 2009

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > shdocvw: OnAmbientPropertyChange should refresh all properties > with a DISPID_UNKNOWN It would be better to add test for it so we know which properties should we refresh (even if most of them would be todo_wine ATM). Thanks, Jacek

1 0

Updated DIB Engine
by Massimo Del Fedele Jan. 28, 2009

Jan. 28, 2009

Here some news on my DIB Engine : Corrected some small bugs in text handling (still VERY poor) Corrected a couple of crashes Added code to enable/disable by environment or registry Made optionals all engine stubs FIXMEs (speeds up a lot....) The engine is disabled by default; can be changed by environment variable : export WINEDIB=ON (or ENABLE or ENABLED or TRUE) enables it export WINEDIB=OFF (or DISABLE or DISABLED or FALSE) disables it or by registry key : HKCU/Software/Wine/DIB Engine/Enable='Y' enables it HKCU/Software/Wine/DIB Engine/Enable='N' disables it the environment variable has precedence on registry, so for example if WINEDIB=ON and HKCU/Software/Wine/DIB Engine/Enable='N' the engine is enabled. I suggest to use the environment for the moment, at less you have an app that runs much better with the engine (autocad, for example...) which benefits from a default enabled engine in registry. Still many many things to do, the most noticeable by now is the missing ROP operations on blitting (and the semi-stub stretchblt...) which is quite noticeable in autocad, for example. I'm pasting a zipped patch of today's current git. Ciao Max

7 16

Re: DNS10 goes 12 minutes rather than 10 before crashing.
by Susan Cragin Jan. 28, 2009

Jan. 28, 2009

>> As you may know, Dragon NaturallySpeaking 10 crashes on use with predictable regularity. >> Used to be every 10 minutes. >> However, yesterday (and today) that creeped up to 12 minutes. >> It could be due to anything, but I thought one of you might say EUREKA!! it's the foobar.c part of oleacc!! or something like that. >> If not, have a good day. >> Susan > >Hi Susan, > >Is there a demo for DNS 10 and do you need to do anything special for >it to crash? I presume you need to train it and then start speaking. > >- Reece Hi, Reece. There is no demo. DNS10 Standard costs $100. I have been somewhat successful in getting complimentary copies for developers. I'm meeting with one of the senior developers the second Tuesday in Feb. If you want a copy, send me something about you or a link to something about you, and a street address for mailing. What I do: Every day, I compile git and re-install DNS on a new .wine. Then I train it and run it. I use it in my work, which is writing. DNS10 used to be sort of flaky but it's getting better. Right now sometimes it crashes immediately on first run but then it runs GREAT -- fast and accurate -- for 10 minutes (now 12). Then it crashes. Always. Inevitably. It's always the time factor. Always just about the same amount of seconds between the time the recognition engine initializes and when it crashes. I can be dictating like a maniac -- hundreds of words per minute, or I can dictate nothing at all. I can transfer text every 10 seconds or leave it all in DictationBox. I can change the settings to save trained text or not. Nothing makes any difference other than time. BTW -- I always dictate into DictationBox, for transfer into Notepad. That is the way (under ALL configurations including Windows) that the program runs the best. Susan

1 0

DNS10 goes 12 minutes rather than 10 before crashing.
by Susan Cragin Jan. 27, 2009

Jan. 27, 2009

As you may know, Dragon NaturallySpeaking 10 crashes on use with predictable regularity. Used to be every 10 minutes. However, yesterday (and today) that creeped up to 12 minutes. It could be due to anything, but I thought one of you might say EUREKA!! it's the foobar.c part of oleacc!! or something like that. If not, have a good day. Susan

2 1

Re: include(1/1): Define flags used by CryptUIWizExport
by Alexandre Julliard Jan. 27, 2009

Jan. 27, 2009

Juan Lang <juan.lang(a)gmail.com> writes: > @@ -297,6 +297,12 @@ typedef struct _CRYPTUI_WIZ_EXPORT_CERTCONTEXT_INFO > typedef const CRYPTUI_WIZ_EXPORT_CERTCONTEXT_INFO * > PCCRYPTUI_WIZ_EXPORT_CERTCONTEXT_INFO; > > +/* Values for CryptUIWizExport's dwFlags */ > +#define CRYPTUI_WIZ_IGNORE_NO_UI_FLAGS_FOR_CSPS 0x00000002 > +#define CRYPTUI_WIZ_NO_UI_EXCEPT_CSP 0x00000003 > +#define CRYPTUI_WIZ_EXPORT_PRIVATE_KEY 0x00000100 > +#define CRYPTUI_WIZ_EXPORT_NO_DELETE_PRIVATE_KEY 0x00000200 MSDN explicitly states that these are not defined in a public header. -- Alexandre Julliard julliard(a)winehq.org

2 1

Wine menu creation questions
by Reece Dunn Jan. 27, 2009

Jan. 27, 2009

Hi, I have noticed that when wine creates a menu item (that for example, on Ubuntu gets put in the Applications > Wine > Programs menu), the command that gets written uses 'wine' as the program to run. This means that you need to have Wine in your PATH and cannot use more than one version of Wine. For example, if I wanted to use /opt/wine-1.0, /opt/crossover and /opt/wine for different applications I cannot access these correctly from the menu items created. Additionally, the user experience (yes, I have been watching Owen's Google talk :)) is that the application does not start (especially if the only version of Wine is not on the PATH). The solution to this is to add the full path to wine, e.g. '/opt/wine-1.0/bin/wine' when generating the menus. Are there any objections to this? Along similar lines, building on what Owen said in the talk that if all goes well Jane user will not notice that she is using Wine to run her Windows software: why is there an entry in the Applications section that says 'Wine' (and why does it have the folder icon and not the Wine icon)! It would be better if this said something like "Program Files", replacing Wine > Programs -- this removes a level of indirection and gives the user something that they are familiar with and is more discoverable than 'Wine'. Thoughts? - Reece

6 7

Re: comctl32: Fix propsheet size calculation
by Vitaliy Margolen Jan. 27, 2009

Jan. 27, 2009

Vitaliy Margolen wrote: > Size of tabs has nothing to do with the size of a window title. > Fixes bug 8522. > --- > dlls/comctl32/propsheet.c | 17 ++++++++++++++--- > 1 files changed, 14 insertions(+), 3 deletions(-) > Was there anything wrong with this patch? Adding tests for this won't work all that well - size of non-client varies from distro to distro to WM to user settings. Vitaliy

1 0

Re: [PATCH] d3d9: initialize hr (coverity)
by Alexandre Julliard Jan. 27, 2009

Jan. 27, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > Spotted in CID 864 that hr is used uninitialized > in a codepath. Using S_OK as default return. Is S_OK really appropriate here? A test case is probably in order. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: comctl32[1/2]: toolbar: Str_SetPtr* assumes the destination pointer points to allocated memory or is NULL
by Alexandre Julliard Jan. 27, 2009

Jan. 27, 2009

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > @@ -2924,6 +2925,7 @@ TOOLBAR_AddStringW (HWND hwnd, WPARAM wParam, LPARAM lParam) > } > > infoPtr->strings = ReAlloc(infoPtr->strings, sizeof(LPWSTR)*(infoPtr->nNumStrings+1)); > + infoPtr->strings[infoPtr->nNumStrings] = NULL; > Str_SetPtrW(&infoPtr->strings[infoPtr->nNumStrings], p); > infoPtr->nNumStrings++; > > @@ -2942,6 +2944,7 @@ TOOLBAR_AddStringW (HWND hwnd, WPARAM wParam, LPARAM lParam) > > TRACE("len=%d %s\n", len, debugstr_w(p)); > infoPtr->strings = ReAlloc(infoPtr->strings, sizeof(LPWSTR)*(infoPtr->nNumStrings+1)); > + infoPtr->strings[infoPtr->nNumStrings] = NULL; > Str_SetPtrW (&infoPtr->strings[infoPtr->nNumStrings], p); > infoPtr->nNumStrings++; ReAlloc initializes to 0, so this shouldn't make any difference. -- Alexandre Julliard julliard(a)winehq.org

1 0

Could someone test this wineinet:http fix on an XP or 2003 box without IE7
by Reece Dunn Jan. 27, 2009

Jan. 27, 2009

Hopefully, we will then get a clean test run on some XP boxes and have several more 2003 boxes with 1 test failure :). Thanks, - Reece

4 4

Re: shell32: Fix SHFileOperation on empty destination (FO_COPY)
by James Hawkins Jan. 27, 2009

Jan. 27, 2009

On Tue, Jan 27, 2009 at 3:20 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > http://bugs.winehq.org/show_bug.cgi?id=13394 > > Changelog: > - on FO_COPY and empty destination SHFileOperation should use > current directory > > >From 1684fd3c0d47fce3fcff31d316ec7b18291cd5af Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Tue, 27 Jan 2009 12:17:42 +0300 > Subject: Fix SHFileOperation on empty destination (FO_COPY) > > --- > dlls/shell32/shlfileop.c | 8 ++++++++ > dlls/shell32/tests/shlfileop.c | 14 ++++++++++++++ > 2 files changed, 22 insertions(+), 0 deletions(-) > > diff --git a/dlls/shell32/shlfileop.c b/dlls/shell32/shlfileop.c > index ec7ba54..78b7352 100644 > --- a/dlls/shell32/shlfileop.c > +++ b/dlls/shell32/shlfileop.c > @@ -1498,6 +1498,7 @@ int WINAPI SHFileOperationW(LPSHFILEOPSTRUCTW lpFileOp) > FILE_OPERATION op; > FILE_LIST flFrom, flTo; > int ret = 0; > + WCHAR currd[MAX_PATH]; > > if (!lpFileOp) > return ERROR_INVALID_PARAMETER; > @@ -1510,6 +1511,13 @@ int WINAPI SHFileOperationW(LPSHFILEOPSTRUCTW lpFileOp) > if ((ret = parse_file_list(&flFrom, lpFileOp->pFrom))) > return ret; > > + if ((lpFileOp->wFunc == FO_COPY) && > + (lpFileOp->pTo[0] == 0)) > + { > + GetCurrentDirectoryW(MAX_PATH, currd); > + parse_file_list(&flTo, currd); > + } > + else > if (lpFileOp->wFunc != FO_DELETE) > parse_file_list(&flTo, lpFileOp->pTo); > Style is wrong. Should be 'else if' all on one line. Regardless, this functionality should be in copy_files, not SHFileOperationW. > diff --git a/dlls/shell32/tests/shlfileop.c b/dlls/shell32/tests/shlfileop.c > index 433a131..3c85ecd 100644 > --- a/dlls/shell32/tests/shlfileop.c > +++ b/dlls/shell32/tests/shlfileop.c > @@ -1673,6 +1673,20 @@ static void test_copy(void) > ok(DeleteFileA("ab.txt"), "Expected file to exist\n"); > ok(RemoveDirectoryA("one"), "Expected dir to exist\n"); > ok(RemoveDirectoryA("two"), "Expected dir to exist\n"); > + > + /* pFrom contains a name larger than 8.3, pTo is an empty string */ > + CreateDirectoryA("one", NULL); > + createTestFile("one\\abcdefghi.abc"); > + shfo.pFrom = "one\\abcdefghi.abc\0"; > + shfo.pTo = "\0"; > + shfo.fFlags = FOF_NOCONFIRMATION | FOF_SILENT | FOF_NOERRORUI | FOF_FILESONLY | > + FOF_NOCONFIRMMKDIR; > + > + retval = SHFileOperationA(&shfo); > + ok(retval == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", retval); > + ok(DeleteFileA("abcdefghi.abc"), "Expected file to exist\n"); > + ok(DeleteFileA("one\\abcdefghi.abc"), "Expected file to exist\n"); > + ok(RemoveDirectoryA("one"), "Expected dir to exist\n"); > } > > /* tests the FO_MOVE action */ > -- > 1.5.6.5 > > > > > > -- James Hawkins

1 0

Is there a way to set Z:\ as the whatever user's home folder?
by Scott Ritchie Jan. 27, 2009

Jan. 27, 2009

I want to have a read-only wine prefix that multiple users might access, however I also want to have a Z:\ drive that refers to a dynamic location - a folder inside the current user's home folder. This isn't possible as far as I can tell, as Wine requires a symlink to the folder in the prefix's dosdevices directory, and a symlink can only point to a static file. Assuming this is possible, are there any downsides to using this read-only prefix? Assume for a moment that the application doesn't need write access to the registry or to its own folder. Thanks, Scott Ritchie

2 1

Re: [PATCH] wineps.drv: Add a simple implementation of PSDRV_SelectBitmap.
by Alexandre Julliard Jan. 27, 2009

Jan. 27, 2009

Lei Zhang <thestig(a)google.com> writes: > Hi, > > This fixes bug 17103 for me. I'm not sure if PSDRV_SelectBitmap() need > to do more, but this is a start and it's better than a stub. If it doesn't do more, then removing it completely should work just as well. There doesn't seem to be much point in just storing the bitmap, this is easy to retrieve when needed. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi32: Implement QueryFontAssocStatus
by ricardo_barbano＠hotmail.com Jan. 27, 2009

Jan. 27, 2009

i don't know what might be wrong, but in case noone answers you: maybe divide this in much smaller patches? this way you can easily pinpoint areas where the problem is, because the patch is quite big. or you could try pinging julliard by mail or on IRC... regards, ricardo -------------------------------------------------- From: "Byeongsik Jeon" <bsjeon(a)hanmail.net> Sent: Monday, January 26, 2009 11:33 PM To: <wine-devel(a)winehq.org> Subject: Re: gdi32: Implement QueryFontAssocStatus > Again... > What's the problem? > > > 2009-01-20 (Tue), 06:39 +0900, Byeongsik Jeon wrote: >> 2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: >> > QueryFontAssocStatus() is the undocumented function. >> > This is a base patch for bug#16325. >> > >> > http://bugs.winehq.org/show_bug.cgi?id=16325 >> > >> Hmm... >> What is the problem of this patch? >> >> >> > --- >> > dlls/gdi32/font.c | 12 +++++++ >> > dlls/gdi32/freetype.c | 66 >> > ++++++++++++++++++++++++++++++++++++++++++ >> > dlls/gdi32/gdi32.spec | 2 +- >> > dlls/gdi32/gdi_private.h | 1 + >> > dlls/gdi32/tests/Makefile.in | 2 +- >> > dlls/gdi32/tests/font.c | 63 >> > ++++++++++++++++++++++++++++++++++++++++ >> > include/wingdi.h | 1 + >> > 7 files changed, 145 insertions(+), 2 deletions(-) >> > >> >> >> >> > > > >

1 0

Re: [PATCH] ddrawex: use stack ctx instead of uninitialized variable
by Austin English Jan. 27, 2009

Jan. 27, 2009

On Mon, Jan 26, 2009 at 11:06 AM, Marcus Meissner <meissner(a)suse.de> wrote: > --- > dlls/ddrawex/ddraw.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/ddrawex/ddraw.c b/dlls/ddrawex/ddraw.c > index b581529..6607c78 100644 > --- a/dlls/ddrawex/ddraw.c > +++ b/dlls/ddrawex/ddraw.c > @@ -678,11 +678,11 @@ IDirectDraw4Impl_EnumSurfaces(IDirectDraw4 *iface, > LPDDENUMSURFACESCALLBACK2 Callback) > { > IDirectDrawImpl *This = impl_from_dd4(iface); > - struct enumsurfaces4_ctx *ctx; > + struct enumsurfaces4_ctx ctx; > TRACE("(%p)->(0x%08x,%p,%p,%p)\n", This, Flags, DDSD, Context, Callback); > > - ctx->orig_cb = Callback; > - ctx->orig_ctx = Context; > + ctx.orig_cb = Callback; > + ctx.orig_ctx = Context; > return IDirectDraw4Impl_EnumSurfaces(This->parent, Flags, DDSD, &ctx, enum_surfaces_wrapper); > } > > -- > 1.6.0.2 > > > This fixes Coverity 867. Pointing out so that AJ can add that to the patch title, so we can find it in the git log :-). -- -Austin

1 0

Re: [REGRESSION] Fix dlls/iphlpapi/ipstats.c on FreeBSD 6.4/i386
by Austin English Jan. 27, 2009

Jan. 27, 2009

On Mon, Jan 26, 2009 at 5:43 PM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > After Austin's recent changes (that were committed in the last 24h), > Wine no longer builds for me on FreeBSD 6.4/i386 with the following > failure mode. > > In file included from ipstats.c:71: > /usr/include/netinet/ip.h:160: error: expected specifier-qualifier-list before 'n_long' > gmake[2]: *** [ipstats.o] Error 1 > gmake[2]: Leaving directory `/sw/test/Wine/dlls/iphlpapi' > gmake[1]: *** [iphlpapi] Error 2 > gmake[1]: Leaving directory `/sw/test/Wine/dlls' > gmake: *** [dlls] Error 2 > > The patch below fixes this. > > Gerald > > ChangeLog: > Move #include <netinet/in_systm.h> before #include <netinet/ip.h> to > fix FreeBSD 6.4. > > Index: dlls/iphlpapi/ipstats.c > =================================================================== > RCS file: /home/wine/wine/dlls/iphlpapi/ipstats.c,v > retrieving revision 1.43 > diff -u -3 -p -r1.43 ipstats.c > --- dlls/iphlpapi/ipstats.c 23 Jan 2009 16:07:29 -0000 1.43 > +++ dlls/iphlpapi/ipstats.c 26 Jan 2009 22:42:34 -0000 > @@ -67,6 +67,9 @@ > #ifdef HAVE_NETINET_IF_INARP_H > #include <netinet/if_inarp.h> > #endif > +#ifdef HAVE_NETINET_IN_SYSTM_H > +#include <netinet/in_systm.h> > +#endif > #ifdef HAVE_NETINET_IP_H > #include <netinet/ip.h> > #endif > @@ -88,9 +91,6 @@ > #ifdef HAVE_NETINET_TCP_VAR_H > #include <netinet/tcp_var.h> > #endif > -#ifdef HAVE_NETINET_IN_SYSTM_H > -#include <netinet/in_systm.h> > -#endif > #ifdef HAVE_NETINET_IP_ICMP_H > #include <netinet/ip_icmp.h> > #endif > I've already sent a patch for this: http://www.winehq.org/pipermail/wine-patches/2009-January/068396.html -- -Austin

1 0

Making the file dialog resizable(implementing OFN_ENABLESIZING)
by Diaa Sami Jan. 26, 2009

Jan. 26, 2009

Hi, The attached patch fixes the bug at http://bugs.winehq.org/show_bug.cgi?id=10394 , can you have a look at it. It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami

1 1

Re: gdi32: Implement QueryFontAssocStatus
by Byeongsik Jeon Jan. 26, 2009

Jan. 26, 2009

2009-01-19 (Mon), 09:40 +0900, Byeongsik Jeon wrote: > QueryFontAssocStatus() is the undocumented function. > This is a base patch for bug#16325. > > http://bugs.winehq.org/show_bug.cgi?id=16325 > Hmm... What is the problem of this patch? > --- > dlls/gdi32/font.c | 12 +++++++ > dlls/gdi32/freetype.c | 66 ++++++++++++++++++++++++++++++++++++++++++ > dlls/gdi32/gdi32.spec | 2 +- > dlls/gdi32/gdi_private.h | 1 + > dlls/gdi32/tests/Makefile.in | 2 +- > dlls/gdi32/tests/font.c | 63 ++++++++++++++++++++++++++++++++++++++++ > include/wingdi.h | 1 + > 7 files changed, 145 insertions(+), 2 deletions(-) >

1 1

[RFC] msvcrt: Implement _mbcjistojms
by David Hedberg Jan. 26, 2009

Jan. 26, 2009

Hello, This function is supposed to convert a jis-encoded (Japanese) character to sjis encoding. I think I botched my last attempt up in more than one way so I've now reworked it slightly and thought I'd try again, but perhaps I should first ask if there is anything else obviously wrong with it. For example, the implementation is a bit of a (as far as I can tell working) black box, and the test of it basically tests two different things depending on the codepage, which I am not sure is a good thing. A very insignificant patch perhaps, but all comments are welcome. :) -- David

1 0

Re: Two simple fixes for ListView
by Austin English Jan. 26, 2009

Jan. 26, 2009

On Mon, Jan 26, 2009 at 4:29 PM, Michael James <james.me(a)gmail.com> wrote: > Here are two simple fixes before I attempt anything more complex here. > > Michael James > > From d978eb3c3eff3b44fce6257892749c2c1c34277d Mon Sep 17 00:00:00 2001 > From: Michael James <james.me(a)gmail.com> > Date: Sun, 25 Jan 2009 20:09:33 -0800 > Subject: [PATCH 1/2] Added logic to eliminate a valgrind warning in > LISTVIEW_GetItemExtT > > The original code used correct but somewhat obscure logic. Added a test to > avoid testing uninitialized pointer for pszText when LVIF_TEXT is not indicated > in the flags. With this change, the code functions identically to what it was > doing before but will not cause a warning from valgrind. > --- > dlls/comctl32/listview.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c > index 172925f..f28a70e 100644 > --- a/dlls/comctl32/listview.c > +++ b/dlls/comctl32/listview.c > @@ -5685,7 +5685,7 @@ static BOOL LISTVIEW_GetItemExtT(const > LISTVIEW_INFO *infoPtr, LPLVITEMW lpLVIte > > pszText = lpLVItem->pszText; > bResult = LISTVIEW_GetItemT(infoPtr, lpLVItem, isW); > - if (bResult && lpLVItem->pszText != pszText) > + if (bResult && (lpLVItem->mask & LVIF_TEXT) && lpLVItem->pszText > != pszText) > textcpynT(pszText, isW, lpLVItem->pszText, isW, lpLVItem->cchTextMax); > lpLVItem->pszText = pszText; > > -- > 1.6.1 > > From 8f05ae1ceca1b787f09ede7e7ab0883ee38c63b9 Mon Sep 17 00:00:00 2001 > From: Michael James <james.me(a)gmail.com> > Date: Sun, 25 Jan 2009 21:09:42 -0800 > Subject: [PATCH 2/2] Defined missing macro ListView_GetCheckState > > --- > include/commctrl.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/commctrl.h b/include/commctrl.h > index 426d70a..9cea03c 100644 > --- a/include/commctrl.h > +++ b/include/commctrl.h > @@ -3715,6 +3715,8 @@ typedef struct NMLVSCROLL > SNDMSGA(hwnd, LVM_SETITEMSTATE, (WPARAM)(UINT)i, (LPARAM) (LPLVITEMA)&_LVi);} > #define ListView_GetItemState(hwnd,i,mask) \ > (BOOL)SNDMSGA((hwnd),LVM_GETITEMSTATE,(WPARAM)(UINT)(i),(LPARAM)(UINT)(mask)) > +#define ListView_GetCheckState(hwnd,i) \ > + ((ListView_GetItemState(hwnd,i,LVIS_STATEIMAGEMASK)>>12)-1) > #define ListView_GetCountPerPage(hwnd) \ > (BOOL)SNDMSGW((hwnd),LVM_GETCOUNTPERPAGE,0,0L) > #define ListView_GetImageList(hwnd,iImageList) \ > -- > 1.6.1 > > > One patch per e-mail please. -- -Austin

1 0

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie Jan. 26, 2009

Jan. 26, 2009

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Jan 26, 2009 11:48 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Alexandre Julliard <julliard(a)winehq.org>, Paul Vriens <paul.vriens.wine(a)gmail.com>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >On Mon, Jan 26, 2009 at 12:34 PM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> Alexandre Julliard <julliard(a)winehq.org> >>>Sent: Jan 26, 2009 7:21 AM >>>To: Paul Vriens <paul.vriens.wine(a)gmail.com> >>>Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >>>Subject: Re: Bugzilla question with respect to .NET 1.1SP1 >>> >>>Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >>> >>>> So that means bug 14850 needs to be reopened with a link to 13995? >>> >>>No, if it's the same bug it should be a single report. If .NET doesn't >>>install then obviously all apps that try to install it will be broken, >>>it doesn't make sense to create a separate bug for each app that suffers >>>from the problem. >>> >> Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. >> >> What do you say about doing this? >> >> James McKenzie >> >> >> >> > >That's messy. Have them cc themselves to the original bug, and when >its fixed, retest. No need to file a bug only to close it immediately >as a duplicate. > I realize it's ugly, but I'm thinking like a software tester not a developer. If I found three bugs in a program, I opened three bugs. If I found the same bug in a different program, I opened a second bug and attached it to the first. >If, however, you're able to workaround that bug, then make a new bug, >and have the second depend on the first. > >E.g., program foo needs native gdiplus and native richedit to install. >File bug for gdiplus problem, then file a second one for richedit, >marking it as depending on the gdiplus bug. What if the richedit bug is fixed first? Would it be impossible to test to see if the bug is fixed? If that were the case, then this is a correct scenario. If the richedit bug can be tested independently of the gdiplus bug, then this scenario is incorrect. If the gdiplug bug depends on the richedit bug being fixed first, then the linkage should be reversed. Linking two separate bugs in this case may not pass the sense test. There has to be an added, simple mechanism where a user (not a developer, or triage) can add to a list of applications affected by a specific bug. See above for what I consider a bug, this is a single application affected by a single problem. Linking together independent bugs needs to be done in a rational manner. If three applications are affected by the same bug, then they either should be linked together, reported under one bug with additional votes for the added applications and users with an updated description, or held as separate bug reports. Sorry to be so long winded about this, but proper bug reporting was and still is my primary business. James McKenzie

2 1

Making the file dialog resizable(implementing OFN_ENABLESIZING)
by Diaa Sami Jan. 26, 2009

Jan. 26, 2009

Hi, Can you please have a look at the patch at http://bugs.winehq.org/show_bug.cgi?id=10394 ? It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami

1 0

re: advapi32: Fix potential NULL pointer dereference in LookupPrivilegeNameW [with test] (Saturn)
by Dan Kegel Jan. 26, 2009

Jan. 26, 2009

Cool, I didn't know about Saturn. I've updated http://wiki.winehq.org/StaticAnalysis with info about it. Offhand it looks like neither of these were caught by Coverity...?

1 0

Making the file dialog resizable(implementing OFN_ENABLESIZING)
by Diaa Sami Jan. 26, 2009

Jan. 26, 2009

Hi, Can you please have a look at the patch at http://bugs.winehq.org/show_bug.cgi?id=10394 ? It's pretty much done except for some nasty bug and the repainting problem. -- Regards, Diaa Sami

1 0

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie Jan. 26, 2009

Jan. 26, 2009

Alexandre Julliard <julliard(a)winehq.org> >Sent: Jan 26, 2009 7:21 AM >To: Paul Vriens <paul.vriens.wine(a)gmail.com> >Cc: James Mckenzie <jjmckenzie51(a)earthlink.net>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> So that means bug 14850 needs to be reopened with a link to 13995? > >No, if it's the same bug it should be a single report. If .NET doesn't >install then obviously all apps that try to install it will be broken, >it doesn't make sense to create a separate bug for each app that suffers >from the problem. > Actually, I have a different opinion as the reason a program will not install may, at first appearance, be the lack of .NET1.1SP1 but may be another function that Wine does not provide. Paul is 'smart enough' to figure that the problem IS the lack of .NET functionality or the inability to install, but the common user may not. I say, open the bug, mark it as a duplicate of the existing bug and then close it. Add the reporter as a cc to the original bug. When the bug is resolved, then have the user attempt to install the program, if it still fails, reopen the duplicate with whatever does not work now. This keeps the number of bugs down and lets us know how much the lack of functionality affects the Wine user base. Some users complain of being lost in the shuffle because they add to an existing bug that another program is affected. What do you say about doing this? James McKenzie

2 1

Fwd: wine-bugs Digest, Vol 42, Issue 330
by Austin English Jan. 26, 2009

Jan. 26, 2009

---------- Forwarded message ---------- From: <wine-bugs-request(a)winehq.org> Date: Tue, Jan 13, 2009 at 9:20 AM Subject: wine-bugs Digest, Vol 42, Issue 330 To: wine-bugs(a)winehq.org ---------------------------------------------------------------------- Message: 1 Date: Tue, 13 Jan 2009 08:40:35 -0600 From: wine-bugs(a)winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-bugs(a)winehq.org Message-ID: <E1LMkRX-0004cJ-Iv(a)wine.codeweavers.com> Content-Type: text/plain; charset="UTF-8" http://bugs.winehq.org/show_bug.cgi?id=14413 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|REMIND |ABANDONED --- Comment #5 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-01-13 08:40:35 --- REMIND is not an appropriate resolution in Wine bugzilla. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes. ------------------------------ Message: 3 Date: Tue, 13 Jan 2009 08:45:37 -0600 From: wine-bugs(a)winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-bugs(a)winehq.org Message-ID: <E1LMkWP-0004zA-63(a)wine.codeweavers.com> Content-Type: text/plain; charset="UTF-8" http://bugs.winehq.org/show_bug.cgi?id=14413 Maki <Makitk(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|ABANDONED |LATER --- Comment #6 from Maki <Makitk(a)gmail.com> 2009-01-13 08:45:36 --- (In reply to comment #5) > REMIND is not an appropriate resolution in Wine bugzilla. > Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. ------------------------------ Message: 6 Date: Tue, 13 Jan 2009 08:53:34 -0600 From: wine-bugs(a)winehq.org Subject: [Bug 14413] Freedom: First Resistance problems To: wine-bugs(a)winehq.org Message-ID: <E1LMke6-0005WL-SX(a)wine.codeweavers.com> Content-Type: text/plain; charset="UTF-8" http://bugs.winehq.org/show_bug.cgi?id=14413 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|LATER |ABANDONED --- Comment #7 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-01-13 08:53:34 --- > Fun, fun. It shouldn't BE IN bugzilla's dropdown menu then. It doesn't matter what in the bugzilla's dropdown menu. LATER and REMIND are considered as not appropriate resolutions in WineHQ bugzilla, they are meaningless. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes. How do we expect users to know not to use these resolutions? It's not listed anywhere, and those are appropriate resolutions in other bugzillas. We've already went through and removed all of them from bug entries in bugzilla, so can an admin please remove these resolutions? -- -Austin

2 1

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie Jan. 26, 2009

Jan. 26, 2009

Paul Vriens <paul.vriens.wine(a)gmail.com> >Sent: Jan 26, 2009 4:45 AM >To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Bugzilla question with respect to .NET 1.1SP1 > >Hi, > >I have an application that won't install because it's trying to first do an >install of .NET 1.1 and straight after that an upgrade/update to SP1. > >.NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995) > >Should I create a new bug report and say that it depends on 13995, should I >create a bugreport that is then marked as a duplicate of 13995 or should I just >add my findings to 13995? > If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. James McKenzie

3 5

Re: Bugzilla question with respect to .NET 1.1SP1
by James Mckenzie Jan. 26, 2009

Jan. 26, 2009

Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >Sent: Jan 26, 2009 7:10 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Bugzilla question with respect to .NET 1.1SP1 > >James Mckenzie wrote: >> Paul Vriens <paul.vriens.wine(a)gmail.com> >>> Sent: Jan 26, 2009 4:45 AM >>> To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >>> Subject: Bugzilla question with respect to .NET 1.1SP1 >>> >>> Hi, >>> >>> I have an application that won't install because it's trying to first do an >>> install of .NET 1.1 and straight after that an upgrade/update to SP1. >>> >>> .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995) >>> >>> Should I create a new bug report and say that it depends on 13995, should I >>> create a bugreport that is then marked as a duplicate of 13995 or should I just >>> add my findings to 13995? >>> >> If it is a separate application, separate bug report. If the same application is affected, update. Since it appears that you are using a different application to install .NET 1.1 SP1, then a new report should be submitted and then linked to issue 13995. The reason I state this is that additional problems may be discovered, even after .NET 1.1 SP1 runs and installs. It may also be possible to get your application to run, even if .NET 1.1 SP1 will not fully install. >> >> I would classify this as an application does not install because .NET 1.1 SP1 will not install properly. >> >> James McKenzie >> >> >So that means bug 14850 needs to be reopened with a link to 13995? > If the problem may be outside of .NET 1.1 SP1, yes. If not, then the answer is no. I'll have to look at the two bug reports and see if they are related and true duplicates. James McKenzie

1 0

Bugzilla question with respect to .NET 1.1SP1
by Paul Vriens Jan. 26, 2009

Jan. 26, 2009

Hi, I have an application that won't install because it's trying to first do an install of .NET 1.1 and straight after that an upgrade/update to SP1. .NET 1.1SP1 install fails (see bug http://bugs.winehq.org/show_bug.cgi?id=13995) Should I create a new bug report and say that it depends on 13995, should I create a bugreport that is then marked as a duplicate of 13995 or should I just add my findings to 13995? Bug 9140 for example is a separate report with a dependence on 13995. And bug 14850 is marked as a duplicate of 13995. -- Cheers, Paul.

1 0

Re: d3d8/tests: Make tests pass on W2K8
by Ge van Geldorp Jan. 26, 2009

Jan. 26, 2009

Hi Henri, > From: Henri Verbeet > 2009/1/26 Ge van Geldorp <ge at gse.nl>: > > Changelog: > > d3d8/tests: Make tests pass on W2K8 > > > > >- ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL, "IDirect3D8_CreateDevice failed with %#08x\n", hr); > >+ ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL || hr == D3DERR_NOTAVAILABLE, "IDirect3D8_CreateDevice failed with %#08x\n", hr); > > This looks more like something certain VMs would return than something specific to a particular Windows version. You're probably right, this was run on a VM. However, I don't see the same failure on other Windows versions. And I guess the test should still pass, even when it runs on a VM? Gé.

2 1

Checking an empty CDROM drive
by Paul Vriens Jan. 26, 2009

Jan. 26, 2009

Hi, I'm trying to come up with some test to show that GetDriveType returns DRIVE_CDROM regardless whether there is or isn't a CD mounted. I have the following: diff --git a/dlls/kernel32/tests/drive.c b/dlls/kernel32/tests/drive.c index a94cbdf..53b0262 100644 --- a/dlls/kernel32/tests/drive.c +++ b/dlls/kernel32/tests/drive.c @@ -46,6 +46,24 @@ static void test_GetDriveTypeA(void) "GetDriveTypeA should return DRIVE_NO_ROOT_DIR for inexistent drive %c: but not %u\n", drive[0], type); + /* Check if type is still DRIVE_CDROM even when no CD is mounted */ + if (type == 5) + { + DWORD attrs; + + SetLastError(0xdeadbeef); + attrs = GetFileAttributesA(drive); + if (attrs == INVALID_FILE_ATTRIBUTES) + { + trace("Unmounted CDROM with type DRIVE_CDROM\n"); + ok(GetLastError() == ERROR_NOT_READY, + "Expected ERROR_NOT_READY for an unmounted CDROM\n"); + } + else + ok((attrs & FILE_ATTRIBUTE_DIRECTORY) == FILE_ATTRIBUTE_DIRECTORY, + "Expected FILE_ATTRIBUTE_DIRECTORY for a mounted CDROM\n"); + } + logical_drives >>= 1; } } The idea however is to show that Wine is wrong in returning DRIVE_NO_ROOT_DIR for an unmounted CD. The test above of course doesn't show that, it only proves that Windows does it this way. (All is related to bug http://bugs.winehq.org/show_bug.cgi?id=16592) -- Cheers, Paul.

1 1

Re: d3d8/tests: Make tests pass on W2K8
by Henri Verbeet Jan. 26, 2009

Jan. 26, 2009

2009/1/26 Ge van Geldorp <ge(a)gse.nl>: > Changelog: > d3d8/tests: Make tests pass on W2K8 > >- ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL, "IDirect3D8_CreateDevice failed with %#08x\n", hr); >+ ok(hr == D3D_OK || hr == D3DERR_INVALIDCALL || hr == D3DERR_NOTAVAILABLE, "IDirect3D8_CreateDevice failed with %#08x\n", hr); This looks more like something certain VMs would return than something specific to a particular Windows version.

1 0

user32: Resend: Move character conversion logic to dde_server.d & remove todo's
by Jeff Latimer Jan. 26, 2009

Jan. 26, 2009

I have resubmitted this patch for discussion purposes. Patch "user32/tests: Clarify the msgs to differentiate Unicode and ASCII in tests" cleans up existing tests for this situation and demonstrates the functionality. The problem remains that the application passes to the dde/ddeml data that is of type LPBYTE. This can occur as a message post or a DDEML call. DDE operates in two ways. * The first is the native DDE using POST and GET messaging. In this case data is passed without translation. * The second case uses DDEML. When using DDEML, the data is translated to and from Unicode depending on the server client window type. * However, there is a third case, the hybrid. In this case if the client uses messaging and posts a message, and the server uses DDEML translation will occur. If the client uses DDEML and the server uses a get to retrieve the message translation will not occur. The data passed to DDE/DDEML is LPBYTE but it can be Unicode or ASCII regardless of the interface type of the client. In all cases the data is translated into the type of the server. The issue is that the client passes data using messaging or DDEML there is no method in the api to inform the server whether the data is Unicode or not. The only method I have determined is to use IsTextUnicode() but that is guessing. However, it looks like Windows guesses too. Can I get some advice on this as the existing code does need to be fixed. Jeff

2 9

Re: re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
by Uwe Bonnes Jan. 25, 2009

Jan. 25, 2009

>>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> That's how we used to do it, but tests showed that _filbuf really Dan> has to do the cr removal. Dan> On Jan 25, 2009 10:57 AM, "Uwe Bonnes" < Dan> bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: >>>>> "Dan" == Dan Kegel <dank(a)kegel.com> writes: Dan> I'll have a look... Dan> For me it looks like our whole black magic handling for the CR Dan> removal in read_i() is wrong. Probably _filbuf() should fill the Dan> buffer as is, only fget(w)c() should skip CR in text mode and Dan> fread() in binary mode should use unaltered chunks of _filbuf() in Dan> binary mode and iterate through _filbuf() in text mode, skipping Dan> CR. Could it be that _filbuf also skips CR as return value in text mode? B.t.w., for a file like "\\r\\r\\r\\nEOF", native _filbuf returns 0x0d... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

returned status 2
by gnuoytr＠rcn.com Jan. 25, 2009

Jan. 25, 2009

I was able to install some packages, but this and mdac27 can't find itself. The file is there.??? ubuntu 8.10 wine 1.1.13 I was able to install all packages needed on ubuntu 6.06 wine 1.0.1; different machine. thanks, Robert Location: http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer… [following] --2009-01-25 15:12:46-- http://ufpr.dl.sourceforge.net/sourceforge/bzflag/BZEditW32_1.6.5_Installer… Resolving ufpr.dl.sourceforge.net... 200.236.31.1, 200.17.202.1 Connecting to ufpr.dl.sourceforge.net|200.236.31.1|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 882263 (862K) [application/x-msdos-program] Saving to: `BZEditW32_1.6.5_Installer.exe' 100%[==========================================================================================>] 882,263 110K/s in 15s 2009-01-25 15:13:02 (57.7 KB/s) - `BZEditW32_1.6.5_Installer.exe' saved [882263/882263] Executing wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe wine: cannot find '/home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' Note: command 'wine /home/buggy/.winetrickscache/BZEditW32_1.6.5_Installer.exe' returned status 2. Aborting.

2 1

Talk at Google, "the Wine user experience"
by Owen Rudge Jan. 25, 2009

Jan. 25, 2009

Hey all, I've been a bit quiet as of late with uni work and so on, but figured I'd let you guys know that I was visiting Google in Mountain View on Thursday, and while there gave a tech talk on "Windows Meets Linux: the Wine user experience" - basically going over some of the issues with getting Wine out to users, ensuring a smooth experience for these users, and the challenges involves in this. It seemed to be well-received, and the talk is now up on YouTube: http://uk.youtube.com/watch?v=5E2HDQw4xmM Cheers! -- Owen Rudge http://www.owenrudge.net/

1 0

re: Test Case to show Wine-MSVCRT still misshandling ASCII Mode
by Dan Kegel Jan. 25, 2009

Jan. 25, 2009

I'll have a look...

1 0

Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64
by Dmitry Timoshkov Jan. 25, 2009

Jan. 25, 2009

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > +/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of the structure > + * is the same as of TBBUTTON */ > typedef struct > { > INT iBitmap; > @@ -96,6 +98,9 @@ typedef struct > BYTE fsStyle; > BYTE bHot; > BYTE bDropDownPressed; > +#ifdef _WIN64 > + BYTE bReserved64[4]; > +#endif > DWORD_PTR dwData; > INT_PTR iString; > INT nRow; Then probably it would make sense to make TBBUTTON the first member of the above structure. That would help in avoiding possible layout problems in future. -- Dmitry.

3 5

A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Guillaume SH Jan. 25, 2009

Jan. 25, 2009

Hi wine team, First let me thank you for providing wine software witch I see as a strong asset in the expansion of free software and as a useful tool for people (like me) already using free software wherever possible. At this point, Wine is at a very good level both in API coverage, quality (less and less hack, more and more nice and clean solutions) and efficiency. Reaching that level required a tremendous work in all kinds of domains (implementation, coordination, patch value judgment, test suite...). In this regard I want to thank you again and congratulate you all guys, what you have done so far is quite an achievement. This week however I was quite puzzled by one commit : "kernel32: Make GetOverlappedResult crash on NULL args as native does."(1) As I'm following wine only for a short time (count in months, not in years) I guess reproducing windows unfixed defects is a choice (although I am not sure this decision comes from consensus or from a boss statement) made by wine team. Thinking about it I see only one argument justifying it's the good direction : for the sake or portability from wine to windows platforms. For example, a firm using wine on a free-OS platform, for software development with a Windows target platform. Relying on this assertion (which someone may demonstrate me to be false, secondary or incomplete), I'm afraid that wine take a step in the wrong direction from what seems to me the third major reason to switch from non-free OS platform (typically Windows) from free-OS platform. Those 3 main reasons are for me : 1 - Freedom (possibility to browse sources, self-compile from sources and even modifying them) 2 - Free from charge 3 - Communicating openly about known defects in software, fixing defects without respects for commercial stakes (ex: hide bug until the xxth release, or not fixing a known bug until it is publicly discovered) To summarize, I'm stating that removing the clean and safe way to handle NULL parameters in this function to fall back to bad and dirty crash, exposing security issue for user (a software can be created specifically by a ill-intentioned one to exploit this defect), all for the sake of being as bad as Windows is, is a step in the wrong direction. I feel sad enough about it, and I think it can prevent advertised people to use it but above all to recommends Windows user to go for free-OS platform with usage of wine for their needs not covered by free-software (like proprietary format). Nevertheless, just as I said, I'm still very enthusiast about wine and still think it's great and very useful. I will continue to use it, promote its usage when suitable, and also warn about its known defects people around me. Guillaume (1) for reference : 32cc4011ee04046d41a41549d5a6a6233647f756 from 22/01/2009 PS : I am fully aware that free software have defects too, some of them being security issue. I am also aware, that in a software as huge as wine, reaching even a medium security level is a real strong challenge, increased by the defects in Windows API design. I am also fully aware that security is a process, not a product.

4 4

Re: A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Ben Klein Jan. 25, 2009

Jan. 25, 2009

2009/1/26 Guillaume SH <gsh.debianlists(a)gmail.com>: > I will be my last mail though because I understood that there is a > consensus that wine shouldn't be a safe and good tool enabling > transition from Windows to free-OS, but rather a tool with a > not-so-clear goal (again I'm not willing to start flaming, so please > don't). Wine's goal is perfectly clear: to provide, as best as possible, a complete and accurate implementation of win32 (and win64 long-term) and related APIs. If putting invalid data into a specific function causes a known crash on the only other implementation of win32 (Microsoft Windows), especially considering that win32 is standardised by the same company that produces Windows, it can be assumed that the crash is the correct behaviour and Wine should emulate it. >>> 1 - Freedom (possibility to browse sources, self-compile from sources >>> and even modifying them) >> >> This one commit does not making the source any less open. > I totally agree : this the first reason i evoked and it is 100% reached by wine > >>> 2 - Free from charge >> >> This one commit does not put a price tag on Wine. > I totally agree : this is the second reason I evoked and it is 100% > reached by wine > >>> 3 - Communicating openly about known defects in software, fixing >>> defects without respects for commercial stakes (ex: hide bug until the >>> xxth release, or not fixing a known bug until it is publicly >>> discovered) > I agree that wine doesn't try to hide defect, but Microsoft is, and > copycatting Microsoft behavior is like being accomplice of its silence > and lack of actions Microsoft's defect, if not already documented, has been revealed by this patch. It's not something they're likely to fix. If they fix it, then a matching fix has to go in Wine at some point (which could be interesting due to different behaviour on different Windows versions). Until they fix the bug and update win32 specifications to match, crashes directly caused by the commit in question are expected and can be assumed to be correct. > Regarding the security part, I am full aware of the facts you stated, > and this is a point that's dooming wine to have less success than It > could have. No, it's dooming Wine to have more success than it should have. Big difference. In implementing win32 API, Wine inherently opens up *nix to a whole new world of malware. Sure, it still needs to be explicitly run by the user, sure there is "wineserver -k" and "rm -rf ~/.wine", but that won't stop spyware, trojans, worms etc. completely. And it shouldn't, because if Wine attempts to stop malware, then legitimate applications will surely suffer too. Not to mention legitimate software that *acts* like malware, e.g. punkbuster :) > You are an intelligent man Ben, I happy to exchange with such a man. Lies, all lies! But thank you nonetheless.

2 2

A step in the wrong direction, in an ocean of steps in the right direction (try 3)
by Guillaume SH Jan. 25, 2009

Jan. 25, 2009

Hi Dimitry, Thank you very much for bringing this explanation to my knowledge. As you name came over and over through wine-devel list, I am aware that you are an experimented and influential member within wine community (which make a huge difference with me, as this is the first time I try to bring a contribution to wine(1) ), so I will consider this explanation as the way most involved wine people are considering things up. The most interesting part in your answer is indeed this word of "Behaviour" you used. Indeed, in my understanding (but maybe "I am hoping" is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones. Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence 2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...) Regarding the part of your mail where you wrote : "that's actually good that applications crash when they pass invalid data", I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. Don't misunderstand me here, I'm not insulting you neither I'm not saying that I am better than you nor I'm not trying to start a flaming thread. I respect the assertion you stated, but honestly and deeply fail to understand why is it correct. Guillaume (1) Talking openly and honestly about a subject that may be considered a problem is a way of contributing, less concrete than patches, but real too.

5 4

Re: [2/3]: winemenubuilder: generate fd.o MIME and file type associations
by Frank Richter Jan. 25, 2009

Jan. 25, 2009

On 24.01.2009 12:03, Damjan Jovanovic wrote: > +static char* wchars_to_unix_chars(LPCWSTR string) > +{ > + char *ret; > + INT size = WideCharToMultiByte(CP_UNIXCP, 0, string, -1, NULL, 0, NULL, NULL); Since that is used to write fd.o desktop and mime files: double-check the respective specs, I believe they mandate UTF-8 as the character encoding. UNIXCP isn't necessarily UTF-8. -f.r.

2 1

Updated testing DIB Engine
by Massimo Del Fedele Jan. 24, 2009

Jan. 24, 2009

I did some update on the engine, I tried to post it here as a zipped patch, but didn't got published.... So I've put it on bug 421 page with instructions on how to use it. I'd like to have some feedback if the implementation way is the right one. Ciao Max

1 0