September 2007 - Wine-Devel

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 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: hhctrl.ocx: Parse HTML entities in the table of contents.
by Alexandre Julliard April 15, 2008

April 15, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > + p++; > + if ((*p == 'X') || (*p == 'x')) > + { > + /* hexadecimal entity */ > + while ((*p >= '0' && *p <= '9') || (*p >= 'a' && *p <= 'f') || > + (*p >= 'A' && *p <= 'F')) > + p++; > + ch = strtolW(start + 2, NULL, 16); > + } This is still broken. > + if (p - start - 1 <= sizeof(char_refs[0].name)) > + { > + for (i = 0; i < sizeof(char_refs)/sizeof(char_refs[0]); i++) > + if (!strncmpW(char_refs[i].name, start + 1, p - start - 1)) > + break; > + } This is still broken too. -- Alexandre Julliard julliard(a)winehq.org

2 1

The status of the wintab dll
by Robert North Dec. 24, 2007

Dec. 24, 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches. P.S. I won't be available from the 15th for about a week or so. So, if you have any questions, I'm afraid you might have to be patient. Hope this is of interest to someone -Rob. ******Applications: Current status*********** ***In Painter 5 *Cursor pressure works. (Therefore is usable by most) *Cursor orientation is a little odd: The orientation maths needs to be re-done. *No eraser. Haven't yet cracked what enables the eraser. *Doesn't work in desktop mode: Need to map to desktop coordinates. *Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-) *Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions. ***In Photoshop 6. *Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode. * Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs. *******To Do************* 1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this) 2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done. 3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen) 4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows. 5. Tests ~ --My current philosophy on tests is... ~ Use Photoshop & Painter, any formal tests ~ can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict. **********Long term to do (Anyone interested?):********* There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;) 1. Improve configuration of wintab. Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file. 2. Handle Z-Order of context properly. This entails *sharing Z-Order between apps. *Working out exactly what role windows have in determining tablet context z-orders. *Allow tablet contexts that don't cover the whole screen/tablet. *Handle inter-application clipping of tablet contexts *Allow all application's windows to receive tablet events when tablet context is on top 3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse) 4. Unicodify 5. Implement various wintab extensions. 6. Implement wintab manager functions. 7. Tests. *********Unknowns********* 1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop? 2. How Painter detects the eraser. Have 3 possibilities i. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!) ii. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only). iii. I've missed something 3. Requirements of other applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s /ZKMUGwQOuw/SIIbOkIUbd0= =R4M7 -----END PGP SIGNATURE-----

2 1

Direct3D Game test framework
by Stefan Dösinger Dec. 21, 2007

Dec. 21, 2007

Hi, Now that we're facing Direct3D 9 feature completion soon - VTF support coming in from Henri, High order patches and thread safety from me - the d3d work will change a bit soon. Instead of adding new features we'll debug games and improve performance. It would be good if we had some automated testing framework to support the process :-) Unfortunately this isn't easy. Games do not render exactly, so verifying that a game doesn't show any visual regressions automatically may be more effort than reward. Here I think we'll have to rely on users testing the games regularly and testing regressions. I am more concerned about the performance thing. It is very easy to make some performance improvement that does more harm than good. Also benchmarks take quite some time and are affected by many external parameters. So I'd like some automated and controlled performance testing environment. Instead of building one from scratch it would be cool if we could reuse existing software. cxtest comes to my mind(www.cxtest.org). It is a test suit built by codeweavers for running regression tests on Windows apps. It can remote control applications using keyboard input and compares screenshots to reference ones. It could be used to start benchmarks automatically. A plus here is that some machines run nightly tests. However, those are VMs, so no 3D acceleration. A problem is also reading back the results. Does anyone know some applications for doing that? Windows or Linux apps, commercial or open source ones(prefered, though). Then we need benchmarking apps. Here regular Windows benchmarks come to my mind(3DMarkXYZW), games with benchmark facilities(hl2, ut, ...). We can record tests, get a reference performance counter from windows and run nightly tests(or manually started tests). A problem we're facing is reading back the results. Taking screenshots and running OCR on them is error prone, we need a way to get the numbers from the benchmarks, not an image of the numbers. Now we need a concrete collection of benchmarks. A mixture of popular Benchmarks like 3DMark would be good, and some more cientific benchmarks. So far I have: 3DMark: Popular benchmark for testing the overall performance, doesn't give very detailed results though. Controlling: Standard windows controls, keyboard events should do the job Result readback: Can write results to a file, but must take care about the licensing. Not everything is free, most likely a license is needed. Half-Life 2: Nice facility of recordable timedemos. Can record average game demos, but also demos which stress specific features. Controlling: Command line parameters Result readback: Can be asked to copy the console into the clipboard UT2004: Popular engine. Has a Linux port, but many mods only ship the d3d renderer. Controlling: Unknown Result readback: unknown. DirectX sdk demos, nvidia / ati demos: Stress specific rendering features. Good for testing performance(with vsync removed), or a bad idea? Controlling, Readback: Source code is available and can be modified. License, especially possible benchmark clauses? Other suggestions? Another nice-to-have thing would be a game independent profiling method, simmilar to the +fps debug channel, just more detailed. Some games do not have built-in benchmarking, it would still be nice to use them. That means facing some new problems? How to tell loading from in-game rendering? How to remove control those games in a repeatable way, especially if there are some random elements in the game? More detailed data from wined3d could also be used to draw nice graphs for other benchmarks :-) We'll need some hardware diversity too. It would be nice if the tests worked on Linux and MacOS, and a variety of hardware was used. I want at least nvidia, ati and intel gpu's, older and newer ones. I could also revive my ATI mach64 :-) Any other comments or suggestions? I think once I'm done with the current exam season and my patch backlog is in I will retire from direct wined3d development for a few days / weeks to set up a testing environment, then start fixing games.

10 40

Work legalities
by Nathan Williams Dec. 11, 2007

Dec. 11, 2007

Hey everyone, I have been planning to do some work on wine for a while now, but after I started working I got myself a new programming job. I'm worried about the copyright of any external work I do, so I need a little advice. What do I need from my employer to clear me to work on wine? Is something verbal ok, or should I get it in writing? -- Nathan

10 12

Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread
by Stefan Dösinger Nov. 15, 2007

Nov. 15, 2007

Am Donnerstag, 20. September 2007 03:49:40 schrieb Carroll Vance: > I have tested this with a driver I made and it seemed to > work fine. I don't know much about ntoskrnl.exe, but if you have a test driver, you may want to include it in the patch. Other libraries have a set of regression tests in dlls/<lib>/tests . ntoskrnl.exe doesn't have any yet, but I don't know if that is a policy or just because no one started it yet.

2 1

CryptAcquireContext Failure, default/Type 024 requested
by Rob Seger Nov. 9, 2007

Nov. 9, 2007

Wine currently supports types 001 and 012, but I have a new game attempting to use type 024 (Software\\Microsoft\\Cryptography\\Defaults \\Provider Types\\Type 024). I've googled, as well as searched MSDN, for a reference as to what the crypt provider type 024 even is with no success. Does anyone know? Looking through the advapi32.dll code, this looks like it might be a serious undertaking to implement. Is that estimation accurate? Does anyone have any tips or pointers about implementing an entire CSP in wine? I appreciate any help, keep up the good work all! Rob

3 7

Window decorations missing on Compiz/Debian Etch
by Michael Jung Oct. 11, 2007

Oct. 11, 2007

Hi all, since a couple of weeks all wine GUI applications are missing the window manager decorations on my Debian Etch box with the Compiz window manager. I did'nt get to doing a bisect until today. The problematic patch seems to be: --- commit ac98e0c07535af4a373c0af343498903e2ff42a6 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Aug 20 22:06:33 2007 +0200 winex11: Switch windows to managed mode in SetWindowPos instead of at creation time. --- Anybody else seeing this problem? I'll attach a +x11drv log from starting up notepad with a current version of wine as of today (wine-0.9.44-g282696b). Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de libGL warning: 3D driver claims to not support visual 0x4b trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1024,768) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1024,768) primary size: 1024x768 trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c1a3f38 trace:x11drv:X11DRV_SetupXIM Using en_US.UTF-8 locale of Input Method trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2 trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT trace:x11drv:X11DRV_SetupXIM No callback style avalable trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x38065c, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x3806dc, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x380784, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x380804, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1c0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1c4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c4, buffer=0x3808ac, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c0, buffer=0x3808cc, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1c8) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1cc) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1cc, buffer=0x380bf4, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c8, buffer=0x380c14, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1d0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1d4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x380f3c, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d0, buffer=0x380f5c, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x210) 64x16 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x248) 128x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x264) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x268) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x268, buffer=0x381284, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x264, buffer=0x3812a4, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x26c) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x270) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x270, buffer=0x3815cc, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x26c, buffer=0x38164c, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x274) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x278) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x278, buffer=0x382274, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x274, buffer=0x382294, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x27c) 16x16 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x27c, bits=0x121308, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x280) 16x16 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x280, bits=0x120ff0, count=0x20) trace:x11drv:X11DRV_CreateBitmap (0x290) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x294) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x294, buffer=0x382274, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x290, buffer=0x3822f4, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x298) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x298, bits=0x121308, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x29c) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x29c, bits=0x121f10, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x2ac) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x2b0) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2b0, buffer=0x382274, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2ac, buffer=0x382294, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x2cc) 64x144 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x2b4) 16x16 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2b4, bits=0x121308, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x2b8) 16x16 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2b8, bits=0x121660, count=0x20) trace:x11drv:X11DRV_CreateBitmap (0x2dc) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x2e0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2e0, buffer=0x382274, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2dc, buffer=0x3822f4, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x2fc) 128x288 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x2e4) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2e4, bits=0x121ad0, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x2e8) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2e8, bits=0x120378, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x30c) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x310) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x310, buffer=0x382274, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x30c, buffer=0x3822f4, count=0xc00) libGL warning: 3D driver claims to not support visual 0x4b trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1024,768) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1024,768) primary size: 1024x768 trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c06e720 trace:x11drv:X11DRV_SetupXIM Using en_US.UTF-8 locale of Input Method trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2 trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT trace:x11drv:X11DRV_SetupXIM No callback style avalable trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x39065c, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x3906dc, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x390784, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x390804, count=0x80) trace:x11drv:X11DRV_SetWindowPos win 0x10020 window (0,0)-(1024,768) client (0,0)-(1024,768) style 86000000 trace:x11drv:X11DRV_CreateWindow hwnd 0x10020 cs 0,0 1024x768 trace:x11drv:X11DRV_CreateWindow win 0x10020 window 0,0,1024,768 client 0,0,1024,768 whole 0,0,1024,768 X client 0,0,1024,768 xwin 4d trace:x11drv:X11DRV_ShowWindow hwnd=0x10020, cmd=5, wasVisible 0 trace:x11drv:X11DRV_CreateBitmap (0x1d4) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1d8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d8, buffer=0x3908ac, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x39092c, count=0xc00) trace:x11drv:X11DRV_SetWindowPos win 0x10022 window (0,0)-(0,0) client (0,0)-(0,0) style 04c00000 trace:x11drv:X11DRV_SetWindowPos making win 0x10022/4000001 managed trace:x11drv:X11DRV_SetWindowPos win 0x10022 window (0,0)-(0,0) client (0,0)-(0,0) style 04c00000 trace:x11drv:X11DRV_CreateWindow hwnd 0x10022 cs 0,0 0x0 trace:x11drv:X11DRV_SetWindowPos win 0x10022 window (0,0)-(0,0) client (3,22)-(3,22) style 04c00000 trace:x11drv:X11DRV_sync_window_position setting win 4000001 pos 0,0,0x0 after 7ecb8ec0 changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10022 window 0,0,0,0 client 3,22,3,22 whole 0,0,0,0 X client 3,22,3,22 xwin 4000001 trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (153,75)-(861,599) style 04cf0000 trace:x11drv:X11DRV_SetWindowPos making win 0x10024/3c00001 managed trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (153,75)-(861,599) style 04cf0000 trace:x11drv:X11DRV_sync_window_position setting win 3c00001 pos 157,98,700x497 after 4 changes=f trace:x11drv:X11DRV_CreateWindow hwnd 0x10024 cs 153,75 708x524 trace:x11drv:X11DRV_CreateBitmap (0x33c) 7x11 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x34c) 7x11 1 bpp trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (157,117)-(857,595) style 04cf0000 trace:x11drv:X11DRV_sync_window_position setting win 3c00001 pos 157,98,700x497 after 4 changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10024 window 153,75,861,599 client 157,117,857,595 whole 157,98,857,595 X client 0,19,700,497 xwin 3c00001 trace:x11drv:X11DRV_SetWindowPos win 0x10026 window (0,0)-(700,478) client (0,0)-(700,478) style 40a00144 trace:x11drv:X11DRV_CreateWindow hwnd 0x10026 cs 0,0 700x478 trace:x11drv:X11DRV_SetWindowPos win 0x10026 window (0,0)-(700,478) client (3,3)-(681,475) style 40a00144 trace:x11drv:X11DRV_CreateWindow win 0x10026 window 0,0,700,478 client 3,3,681,475 whole 0,0,700,478 X client 3,3,681,475 xwin 0 trace:x11drv:X11DRV_ShowWindow hwnd=0x10026, cmd=5, wasVisible 0 trace:x11drv:X11DRV_CreateBitmap (0x404) 2x13 1 bpp trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=1, wasVisible 0 trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (157,117)-(857,595) style 14cf0000 trace:x11drv:X11DRV_sync_window_position setting win 3c00001 pos 157,98,700x497 after 359 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 0x10024 trace:x11drv:X11DRV_CreateBitmap (0x420) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x420, bits=0x1266f0, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x41c) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x41c, bits=0x1269e8, count=0xc00) trace:x11drv:update_fullscreen_state setting fullscreen state for window 3c00001 to false trace:x11drv:X11DRV_SetWindowPos win 0x10026 window (0,0)-(700,478) client (3,3)-(681,475) style 50a00144 trace:x11drv:X11DRV_Expose win 0x10024 (3c00001) 0,0 700x497 trace:x11drv:X11DRV_CreateBitmap (0x194) 8x8 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x194, bits=0x1189a0, count=0x10) trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (157,117)-(857,595) style 04cf0000 trace:x11drv:X11DRV_SetWindowPos unmapping win 0x10024 trace:x11drv:destroy_whole_window win 0x10024 xwin 3c00001

5 7

Weekly Newsletter
by EA Durbin Oct. 1, 2007

Oct. 1, 2007

Who maintains the weekly newsletter? I noticed it hasn't been updated since May. _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx…

2 1

Wine application compatibility
by Roderick Colenbrander Sept. 30, 2007

Sept. 30, 2007

Hi, Every Wine release more and more programs start to work on Wine. A serious problem is that not all programs can work out of the box. Some games for instance need the windows version to be set to Windows 95 or it will crash. Other games like Medal of Honour need their OpenGL extension string trimmed to get it to work on cards which support a lot of OpenGL extensions. There are dozens of more examples like that. Microsoft is having similar troubles and since Windows 2000 they provide appcompat stuff for windows (in WinXP/Vista it is a default feature). It basically works on a database which is used somehow at program startup and which then applies 'fixes' like 'setting the windows version', patching function calls and more. See for instance http://technet.microsoft.com/en-us/library/bb457032.aspx for more info and pay attention to http://technet.microsoft.com/en-us/library/bb457032.apcpxp06_big(en-us,tech… which shows a part of the list and the scope of it. I think we have reached a point in Wine where we might need something similar :( Our compatibility seems to be bigger than XP/Vista so we might not need much. Perhaps we need to maintain some file which applies really needed fixups. It should be merged into the registry using wineprefixcreate and the database can be checked using winecfg. It would use normal AppDefaults. What do you guys think about such a thing? I don't like it at all but I fear it is really needed. If we would add such I'm not sure if we are allowed to dump microsoft their database, looking at it might be something differently. It might be a good topic for WineConf. Regards, Roderick Colenbrander -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

4 6

[PATCH] Fix Ugly borders around undecorated windows in Gnome
by Matthew D'Asaro Sept. 30, 2007

Sept. 30, 2007

This is my first attempt at submitting a patch to WINE, so please excuse me if I have broken any conventions or am going through the wrong channel. As it currently stands, wine is setting the 'MWM_DECOR_BORDER' hint on managed but undecorated windows, such as iTunes, or Winamp. This does not cause problems in KDE, but in Gnome it puts a gray border around such windows. Not setting this hint does not seem to cause problems in KDE and fixes the problem in Gnome. A patch to do just that is attached. Comments? -Matthew D'Asaro

1 0

New winetricks: 'volnum' command to work around bug 5351, new gecko
by Dan Kegel Sept. 30, 2007

Sept. 30, 2007

Another month, another winetricks. This updates the gecko installed by winetricks to 0.1.0, and adds a 'volnum' verb to let you run installers that complain "Unable to find a volume for file extraction." And it has a few other cleanups. As usual, it's at http://kegel.com/wine/winetricks - Dan revision 1.33 date: 2007/09/30 02:47:13; author: dank; state: Exp; lines: +18 -0 Added volnum verb to work around bug 5351 ---------------------------- revision 1.32 date: 2007/09/30 02:30:33; author: dank; state: Exp; lines: +15 -12 Minor janitorial cleanup ---------------------------- revision 1.31 date: 2007/09/30 02:26:40; author: dank; state: Exp; lines: +11 -9 Detlef Riekenberg reported that gecko was using old version. This fixes it. ---------------------------- revision 1.30 date: 2007/09/30 00:03:03; author: dank; state: Exp; lines: +14 -0 Sanity checking by Lei ---------------------------- revision 1.29 date: 2007/09/30 00:00:55; author: dank; state: Exp; lines: +1 -1 Fix typo introduced by last change ---------------------------- revision 1.28 date: 2007/09/29 23:21:33; author: dank; state: Exp; lines: +19 -38 Localized paths cleanup from Detlef Riekenberg -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 4

Re: winex11.drv: possible fix for thick border around utility window in DatePicker
by Dmitry Timoshkov Sept. 30, 2007

Sept. 30, 2007

<a_villacis(a)palosanto.com> wrote: > It seems that, when presented with a combination of WS_POPUP and WS_BORDER > without any extended style, the window is supposed to be shown with a thin > border (a 1px border in Windows). I still have not found a window style that > makes a X window show a thin border, and the nearest thing in looks is no > border at all. Please comment on this patch, as I don't think it is exactly > sane. > > Changelog: > * Deactivate WS_BORDER when present with WS_POPUP > - else if (style & WS_BORDER) mwm_hints.decorations |= MWM_DECOR_BORDER; > + else if ((style & WS_BORDER) && !(style & WS_POPUP)) mwm_hints.decorations |= MWM_DECOR_BORDER; This looks like a bug in Metacity, I don't see why it adds "(disabled) decorations" when only asked for MWM_DECOR_BORDER. On the other hand we already check for WS_CHILD|WS_POPUP and don't add MWM_DECOR_BORDER if any of that styles present, so perhaps your change is in that direction, and should be made to also check for both WS_CHILD|WS_POPUP. Probably it's also worth to file a bug to metacity bugzilla. -- Dmitry.

1 0

The Spouse Test
by Dan Kegel Sept. 30, 2007

Sept. 30, 2007

When will Wine be good enough for the average person to use? One test is, "Is it good enough to let your spouse migrate to Linux from Windows?". My wife's must-have app list is roughly Microsoft Office '97 Adobe Photoshop Elements 1 Ulead PhotoImpact Macromedia Dreamweaver 8 Musicmatch Jukebox 8 FamilyTreeMaker 2006 And you know what? All of those basically work except for Photoshop Elements. They need some cosmetic work, and a native DLL or two, and probably a few obscure bugfixes, but I think that's it. (I didn't test Office '97, since I expect she'll be using Crossover for that, as Codeweavers tests that app pretty well.) It's possible that by this time next year Wine will pass this test for me. - Dan

4 3

Broken patches since 0.9.45 (problem with missing binary files)
by Victor Sept. 30, 2007

Sept. 30, 2007

Hello! It looks like last two patches - wine-0.9.45.diff.bz2 and wine-0.9.46-diff.bz2 are broken. It is not possible to compile wine-0.9.45 (if sources were created by patching 0.9.44 with wine-0.9.45.diff.bz2) due to missing notepad.ico :) : --- make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.45/programs/net' make[2]: Entering directory `/home/erv/distr/wine/wine-0.9.45/programs/notepad' ../../tools/makedep -C. -S../.. -T../.. -I../../include/msvcrt dialog.c main.c rsrc.rc notepad.ico: No such file or directory notepad.ico was first included from rsrc.rc:47 make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. -I../../include/msvcrt dialog.c main.c rsrc.rc notepad.ico: No such file or directory notepad.ico was first included from rsrc.rc:47 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.45/programs/notepad' make[1]: *** [notepad/__depend__] Error 2 make[1]: Leaving directory `/home/erv/distr/wine/wine-0.9.45/programs' make: *** [programs/__depend__] Error 2 Compilation failed, aborting install. --- and it isn't possible to compile wine-0.9.46 (created by patching complete 0.9.45 sources with wine-0.9.46.diff.bz2) due to missing c1.bmp in cards.dll: --- make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.46/dlls/capi2032' make[2]: Entering directory `/home/erv/distr/wine/wine-0.9.46/dlls/cards' ../../tools/makedep -C. -S../.. -T../.. cards.c cards.rc c1.bmp: No such file or directory c1.bmp was first included from cards.rc:23 make[2]: [Makefile] Error 1 (ignored) ../../tools/makedep -C. -S../.. -T../.. cards.c cards.rc c1.bmp: No such file or directory c1.bmp was first included from cards.rc:23 make[2]: *** [depend] Error 1 make[2]: Leaving directory `/home/erv/distr/wine/wine-0.9.46/dlls/cards' make[1]: *** [cards/__depend__] Error 2 make[1]: Leaving directory `/home/erv/distr/wine/wine-0.9.46/dlls' make: *** [dlls/__depend__] Error 2 Compilation failed, aborting install. --- And here is a script I've been using to unpack patches (it should be placed in dir containing wine-0.9.30.tar.bz2 and patches (0.9.31, 0.9.32, etc) in *.diff.bz2 format : --- #!/bin/sh echo unpacking wine BUILD=30 BASE=$BUILD WINE='wine-0.9' tar -xvvjf $WINE.$BUILD.tar.bz2 && cd $WINE BUILD=$(($BUILD+1)) cd "$WINE.$BASE" while [ -f ../$WINE.$BUILD.diff.bz2 ]; do echo $WINE.$BUILD bzcat ../$WINE.$BUILD.diff.bz2|patch -p1 && BUILD=$(($BUILD+1)) done cd .. mv $WINE.$BASE $WINE.$(($BUILD-1)) --- Can someone fix this problem? (It looks like problem is related to binary files) It would be great if both patches were fixed and re-uploaded. Thanks. -- Victor Eremin (ErV2005(a)rambler.ru)

2 2

Re: version resource for ole2nls.dll
by Dmitry Timoshkov Sept. 29, 2007

Sept. 29, 2007

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > Ok, looks like i picked a bad example from the wine tree. > +#define WINE_FILEVERSION 2,1,3050,1 > #define WINE_FILEVERSION_STR "2.10.3050.1" Shouldn't it be 2,10,3050,1 ? Also, could you please also fix the place(s) which you took as an example? -- Dmitry.

1 0

Solidworks Update
by Stephan Rose Sept. 29, 2007

Sept. 29, 2007

I tested Solidworks with 0.9.46 today and fonts seem to be ok now. No more screwed up texts like in the previous versions. So that's a definite improvement. =) Everything else seems to have remained unchanged though. Stephan

1 0

Re: Revert "mshtml: Return wine: URI for protocols handled by MSHTML."
by Jacek Caban Sept. 29, 2007

Sept. 29, 2007

Vitaliy Margolen wrote: > I do not know what author wanted to archive here. But what he did > archive is broken Wine and all other programs that use their own > "protocol:". > > This reverts commit 718b771f2a57d0c762d24c6ef62f070eb3647e8a. > > mshtml: Revert commit that broke steam and most other apps. This patch fixed some apps that use pluggable protocols and reverting it is a step backward. I've sent a correct fix. Thanks, Jacek

2 1

DInput mouse - where to go from here?
by Vitaliy Margolen Sept. 28, 2007

Sept. 28, 2007

As many of you know, Wine have number of serious problems when it comes down to games when using mouse. In fact big number of games suffer one or more of the following problems: 1. Mouse pointer escapes game window (for windowed programs) or confined to arbitrary rectangle (for full-screen) - bug 6971. 2. Mouse is being constantly re-centered (number of bugs). 3. Mouse lags, moves wrong direction or doesn't move at all (number of bugs). 4. Mouse is not smooth with high graphics/system load. There are lots of reasons for these bugs: a) Wine does not grab pointer (doesn't lock it to one particular window). b) Wine's dinput still doing mouse warping while it should not c) Wine relies on an application to process messages so new input events could be received. d) Wine's x11drv is not fine grained - it has only one lock that everything uses, d3d and wgl included. e) The path from x11drv to dinput for input events is long with big overhead. f) X events come from Wine windows for the current process only not whole screen. g) Motion events Wine receives are absolute not relative. Here is what me and others tried but failed: i) XEvIE - buggy, disabled by default, requires server round trip. ii) XInput - does not allow opening of keyboard or mouse devices. iii) Event Device (EvDev) - works perfectly, solves (a,b,c,d,e,f,g) but it's a client only solution (will not work on remote X, because it will try to open remote mouse, not local). iv) Virtualizing mouse pointer in x11drv - depends on (a) moves (b) from dinput into x11drv while same issues remain. v) Writing new X extension - last I've heard about this, it didn't get anywhere past initial proposals. Anything else I missed? Are there are any better ways to solve these problems? Any other ways at all? As you see there are not much options available to solve mouse problems. However I personally do not want to turn this into another "child opengl saga". We ether solving it now, or putting a big red X on any game that's using dinput mouse, that's not already working. The point I'm trying to make is: can we once put our "right ways of doing things" aside and fix something that never worked before? And fix it _for good_! Yes it's a limited fix it will work only for 99% of users who play games on their PC, and not remotely. Vitaliy Margolen.

8 10

AntiAliasing for Source Based games
by christine.youngson＠clear.net.nz Sept. 28, 2007

Sept. 28, 2007

Hi everyone, I'm exceptionally new to posting messages on mailing lists (ie its my first time) so please forgive me in advance if I've done something wrong! My question for the wine developers is, why is Anti Aliasing not supported for Source based games? I play Day of Defeat Source everyday, and many wine gamers play steam based source engine games such as DoDs and Counterstrike Source, and its nearly at windows xp level fps wise, but the main nuisance for us is that there is no AA! AA greatly improves the look of games, and it seems that there is an emphasis on making the games look nice by adding functionality such as shaders and glsl, so in this respect, a basic feature of games such as AA should be considered to be made. Also Team Fortress Two is coming out fairly shortly and AA would be a nice feature to implement for when it comes out :) I would consider learning C etc myself to try and get this functionality (I learned Java as part of my degree) up and running, but sadly I probably don't have the skills to contribute. Anyways, keep up the excellent work wine developers, you guys do a tremendous job, but please consider adding this one feature, as it would mean a lot to myself and many many others who play steam based source games etc using wine on Linux! Take care!

4 3

Re: iTunes 7.4.2 doesn't even install for me
by Juan Lang Sept. 28, 2007

Sept. 28, 2007

Hi Paul, > I saw your bug 9765 but I don't even get that far. The install crashes for me > with something that appears to be connected to a driver: Actually, I see that crash too. I meant to log a bug for it, but never did. Would you mind? (snip) > L"C:\\windows\\System32\\Drivers\\GEARAspiWDM.sys" (native) at 0x460000 > trace:module:process_attach (L"GEARAspiWDM.sys",(nil)) - START > trace:module:MODULE_InitDLL (0x460000 L"GEARAspiWDM.sys",PROCESS_ATTACH,(nil)) - > CALL > trace:seh:raise_exception code=c0000005 flags=0 addr=0x464010 > trace:seh:raise_exception info[0]=00000001 > trace:seh:raise_exception info[1]=00460038 > trace:seh:raise_exception eax=0046137e ebx=7bc90dc8 ecx=0000001c edx=00460000 > esi=7bc87f5b edi=00460038 That address (0x00460038) is suspect. It looks like part of a Unicode string. Something about how this driver is loaded is buggy, I'm guessing ntoskrnl.exe is a bit too stubby for it yet. Nevertheless, iTunes starts for me after this crash, it just warns about the registry entries needed for CD/DVD drives being missing, and I suspect that's due to this driver not being registered correctly. I just ignore that warning. > As your so busy with iTunes these days, I thought I contact you directly. I don't mind, but I'm actually off it now. I've tried to stay up to date this week, but no guarantees now that I'm back in school. --Juan

2 1

re: I need help, please
by Dan Kegel Sept. 28, 2007

Sept. 28, 2007

David, sorry, Wine's not likely to be able to run Corel Draw X3 without several months worth of work, and nobody's focusing on it at the moment. - Dan

5 4

address space layout
by Tijl Coosemans Sept. 28, 2007

Sept. 28, 2007

Hi all! I had a user running FreeBSD 6.2, Xorg 7.3, ATI r200 DRI driver report a problem where running Warcraft3 crashed because it ran out of malloc heap space. The error was: Assertion failed: (texObj->DriverData != NULL), function r200BindTexture, file r200_tex.c, line 1098. fixme:ntdll:FILE_GetNtStatus Converting errno 12 to STATUS_UNSUCCESSFUL This error happens inside the r200 driver, errno 12 means ENOMEM. There was a bug report with a patch over at http://bugs.freedesktop.org/show_bug.cgi?id=12184 The patch gets rid of the assertion failure by doing proper error checking, but it doesn't solve the underlying problem of course, causing a NULL pointer dereference in Wine somewhat later: wine: Unhandled page fault on read access to 0x00000058 at address 0x7e99cc84 (thread 0009), starting debugger... This isn't the first time such a problem appears, especially with games, so ultimately a solution has to be found. The problem is that the way Wine wants to setup the address space is really somewhat incompatible with the way FreeBSD mmap and malloc work. FreeBSD mmap allocates from the end of a process data segment upwards towards the stack. Linux mmap allocates from the stack downwards. FreeBSD (<7.x) malloc doesn't fall back to mmap when it runs out of space in the data segment. Linux malloc does (I've been told). Because the wine process loads itself at 0x7bf00000, this means on FreeBSD with mmap going up, both the data segment and all shared objects (like builtin dlls) sit squeezed between that address and 0x80000000 since addresses above 0x80000000 can't be used for builtin dlls. It's about 64Mb which is currently split 50/50 between heap space and shared objects. This works in a lot of cases, but sometimes a 32Mb heap isn't enough like in the example above, where I assume it's been taken up by textures and other graphics data. Linux doesn't have this problem because mmap allocates shared objects from 0x80000000 downwards and can go beyond the address where wine is loaded if necessary. It can allocate extra heap space this way too when needed. Alexandre and I discussed this a couple weeks ago, but didn't really come up with anything. The problem back then (WoW) has since gone away (turned out to be a memory leak somewhere) so everything was left the way it was. Now it has turned up again however with a different program on a different setup, so it's something that really needs to be looked at. It could again be a memory leak in some other project's code, but then that just means the current situation isn't robust enough to deal with that, since it all does work on Linux. It appears that the only solution is to locate wine somewhere after 0x80000000 instead of at 0x7bf00000 and to allow mmap to allocate memory there. Then the data segment size limit can be set to 256Mb or something instead of 32Mb. The problem is then that builtin dlls are mmapped (by the runtime linker) well beyond 0x80000000. Now I'm thinking, would it be possible to load dummy dlls somewhere in the first 2Gb of address space? Through which API calls can a program determine a dll is above 0x80000000 by the way?

2 1

Re: msvcrt: move error condition before memory allocation (found by Smatch) [1/3, resend]
by Alexandre Julliard Sept. 28, 2007

Sept. 28, 2007

Lionel_Debroux <lionel_debroux(a)yahoo.fr> writes: > _wfullpath leaks some heap memory in an error paths. Found in Michael > Stefaniuc's list of Wine potential bugs detected by Smatch. > Fixed by moving the error treatment before the allocation, since the > error treatment doesn't fire up if there was a memory allocation (due to > size = MAX_PATH; assignment). > > Is there anything wrong with this patch ? Yes, you are using the size before checking if the buffer is NULL (in which case the size is meaningless), and as you said yourself the error treatment isn't used if there was an allocation, so there's no leak to fix here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine gets exposed in Norway :)
by Tomas Zijdemans Sept. 28, 2007

Sept. 28, 2007

The most visited and respected technology related site in Norway (210 000 unique norwegian hits a week), is now launching a series of articles where they will test 3 games thoroughly in wine each month! Today the first article tested Fahrenheit, Guild Wars: Nightfall and Civilization IV: Warlords. The results where good and focused on what users should do to make them work smoothly. Hope this is an encouragement for Stefan and all the others of you working to get games working :)

2 2

Re: version resource for ole2nls.dll
by Dmitry Timoshkov Sept. 28, 2007

Sept. 28, 2007

"Stefan Leichter" <Stefan.Leichter(a)camline.com> wrote: > This patch fixes Bug 9747 > > ChangeLog > --------- > added version resource for ole2nls.dll > +#define WINE_FILEVERSION_STR "2.10.3050.1" > +#define WINE_FILEDESCRIPTION_STR "Wine OLE dll" > +#define WINE_FILENAME_STR "OLE2NLS.DLL" > + > +#include "wine/wine_common_ver.rc" Why do you define WINE_FILEVERSION_STR but not WINE_FILEVERSION? That not creates a confusion but could lead to hard debuggable problems with application which test only one of them. -- Dmitry.

1 1

Re: bits[1/3]: Minimal Background Intelligent Transfer Service (bits) implementation
by Alexandre Julliard Sept. 27, 2007

Sept. 27, 2007

Roy Shea <roy(a)cs.hmc.edu> writes: > Resubmission of a bare bones bits implementation. There is no bits.dll on any Windows version I've checked. Where does this dll come from? -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: mpr: Changes comparison of dwScope in WNetOpenEnum function
by Juan Lang Sept. 27, 2007

Sept. 27, 2007

Hi Konstantin, - providerTable->table[index].dwEnumScopes & dwScope) + providerTable->table[index].dwEnumScopes & WNNC_ENUM_GLOBAL) This change looks correct, but it should be changed in the next block as well: ret = providerTable->table[index].openEnum( dwScope, dwType, dwUsage, lpNet, &handle); It also looks incorrect in _enumerateGlobalPassthroughW: ret = providerTable->table[enumerator->providerIndex]. openEnum(enumerator->dwScope, enumerator->dwType, enumerator->dwUsage, enumerator->lpNet, &enumerator->handle); In fact, all of these usages of dwScope look to confuse the two meanings. (D'oh.) --Juan

2 4

WineD3D surface management cleanup
by Stefan Dösinger Sept. 27, 2007

Sept. 27, 2007

Hi, This mail is mainly addressed at Henri and Roderick, but I'll send it here to allow others to read it too. These patches contain some cleanups of the d3d surface loading code. It's main aim is to put the code that copies the surface between system memory, texture and drawable into a centralized place, make LockRect simpler and pbo creation and surface memory allocation in one place(surface allocation is not completely there yet). It also makes other parts of the code simpler, avoids playing with the surface flags in other places, and it will allow us to centralize the logic that in the case of fbo offscreen rendering the drawable is the same as the texture(This is also not implemented yet). The patches don't aim at fixing any bugs themselves, and I hardly tested them, so there may be a truckload of regressions. I'm mainly showing them to show the general direction I'm heading into.

4 6

Re: Alexandre Julliard : gdi32: Don' t pass a DC handle to WineEngGetFontUnicodeRanges.
by Robert Shearman Sept. 27, 2007

Sept. 27, 2007

Alexandre Julliard wrote: > -DWORD WineEngGetFontUnicodeRanges(HDC hdc, LPGLYPHSET glyphset) > +DWORD WineEngGetFontUnicodeRanges(GdiFont *font, LPGLYPHSET glyphset) > { > FIXME("(%p, %p): stub\n", hdc, glyphset); > You forgot to change hdc to font in the FIXME call. -- Rob Shearman

1 0

Re: [PATCH 1/2] [try2] Allow completion object to be attached to an fd object
by Alexandre Julliard Sept. 27, 2007

Sept. 27, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > +DECL_HANDLER(set_completion_info) > +{ > + struct fd *fd = get_handle_fd_obj( current->process, req->handle, 0 ); > + > + if (fd) > + { > + if (fd->completion) > + release_object( fd->completion ); > + fd->completion = get_completion_obj( current->process, req->chandle, IO_COMPLETION_MODIFY_STATE ); > + fd->comp_key = req->ckey; > + release_object( fd ); You need to check that the completion object is valid before you start modifying the fd. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi: Fix meaning and use of bidirectionality flags
by Shachar Shemesh Sept. 27, 2007

Sept. 27, 2007

Maarten Lankhorst wrote: > According to shachar shamesh they have a slightly different meaning. > This should fix it. > First of all, things seem much much better with this patch. I would direct your attention to the fact that, when I run it, I get: > $ programs/notepad/notepad > fixme:bidi:mirror stub: mirroring of characters not yet implemented > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveWeak assert failed: pcls[ich] <= BN > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveNeutrals assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 > fixme:bidi:resolveImplicit assert failed: pcls[ich] < 5 As far as I can tell, an assert should not be a "fixme", but that's something else. Shachar

1 0

Re: [5/5] WineD3D: Add sincos support to arb shaders
by Ivan Gyurdiev Sept. 27, 2007

Sept. 27, 2007

Aren't most of these 2.0 and 3.0 instructions ? What's the goal of adding them to ARB - you won't be able to implement full 2.0/3.0 support in ARB. I think most of these were left unimplemented on purpose. Ivan

2 3

Total bidi regression
by Shachar Shemesh Sept. 27, 2007

Sept. 27, 2007

Hi Maarten, It seems that since your last changes to the Bidi implementation, BiDi suffered total regression. At least on my system, no BiDi related text (neither Hebrew nor Arabic) gets reordered, at all. Placing breakpoints suggest that BIDI_Reorder is still getting called, so I can only assume that the problem is somewhere inside it (or in the classification) I haven't traced inside to see where things went wrong, nor do I know whether your work on that matter is done. I just wanted to point out that Wine, at the moment, performs no BiDi at all as far as the user is concerned. Shachar

2 6

I need help, please
by David Outteridge Sept. 26, 2007

Sept. 26, 2007

Hello All, I am new to Wine. I need to use corelDRAW for non-central reasons that I will explain if asked. I prefer to host on *nix (currently Mandriva 2007.0), but I can host on MS XP as a backup. I bought the latest and greatest corelDRAW X3 (version 13) and now have spent about a week learning Wine and trying to get corelDRAW working. There are some problems with installation, not completely solved yet; but I am hopeful that execution will be successful since earlier versions are reported in the Wine application database as running well. I have reached a point where I am beginning to understand what is going on with the hosting, and, also, I am getting a glimmer of *how* Wine works. But, as everyone knows, Wine needs a lot of study to get any siginificant grasp of *what* is happening, and I am very aware of how little I know. I need help and guidance to go further, otherwise I shall have to revert to MS XP. I should like very much to use Wine, but I am concerned that to get it going, without help, I shall have to resort to hacks that will be of no use to anyone in the long term, or become engulfed in a never-ending sea of detail. So, here I describe what has happened, and I invite anyone to point me in the right direction, etc., for further work. I am a programmer of many years, but I have not used C for a long time, my preference is for another language. I have no knowledge of Windows internals, and not much about using it except at a fairly remote C++ application programming level when I used Visual Dev Studio (name?) in the past. I have downloaded the Wine source, and have learnt how to manipulate trace messages to see what is happening. The first problem, with corelDRAW out of the box, with Wine 0.9.45 from rpm, or with my downloaded/compiled code, is summarized like this: fixme:msi:ACTION_PerformAction unhandled msi action L"InstallIEFullUI" err:msi:ITERATE_Actions Execution halted, action L"_InstallIE" returned 1602 Notice that there is a leading "_" on one of these actions, and that part of the other is FullUI, which seems to relate very well with one of the MS User Interface Levels. Can anyone tell me the significance of the leading "_", in particular, where does it come from? Also any help on how InstallIEFullUI is split up (my assumption) into _InstallIE and FullUI would be helpful. After much stirring around, hacking at everything in sight, what I have done to deal with this error is cut-and-paste ACTION_InstallInitialize code in msi/actions.c, and modify it suitably, to satisfy InstallIEFullUI and _InstallIE. And this gets me past the err:msg above; which may or may not enable me, ultimately, to install corelDRAW. This do-nothing-really is something of a cop-out, of course. I would make the effort to do something useful, rather than simply returning a deceptive value, but there are two reasons for not doing so. One is that I do not know enough about Wine code/structure/policy, etc., and I could see simply producing garbage, albeit working, code through ignorance. The second reason is that, I read on the Wine website, one should not try to install IE. What is more, Wine (from the rpm) puts a copy of iexplore.exe in my .wine directory anyway. So the question here is: what should I do wrt IE and InstallIEFullUI to follow Wine policy? The second problem seems to me to be rather far-reaching; I think I have run into the problem in three different ways, the last occurrence turns out to be the next fatal step for corelDRAW installation. The first run-in: I have run the distribution iexplore, also I have installed three other IEs, using ies4linux. All of these behave in the same way: they come up properly, and the right-click/wineicon menu that closes the application, moves it to different desktops, etc., also works, so exiting the application is done properly, too. My guess is that this is all done by the window manager, however. The problem is that IE displays no toolbar, so it is quite useless as a browser; it is, indeed, a software boat-anchor. The second run-in: When I ran winecfg, irfanview, regedit, etc.. under the rpm distribution they worked well enough, although the font used was, well, horrible, and almost unreadable. When I moved to the source version of Wine, the apps worked somewhat like iexplore above, except that the menus were available, but contained MangleFont - totally unreadable, with lots of Xs in the text. I posted to comp.emulators.ms-windows.wine and some kind sole suggested loading the MS core fonts, which I had never heard of; but, bingo!, not only did this - utterly magically - solve the problem, but the font(s) used is nice and readable. The third run-in: The corelDRAW installation popups (dialogs?) do not display well, in particular they appear not to refresh when appropriate. The fatal part comes with the license agreement box, where, in addition to most of the popup content not displaying (mouse intervention brings up *some* things), the "Next" button used to continue the installation does not show, nor is it present in the popup. Curiously, the "Cancel" button, right next to it, does show - after its, blank, location is clicked on. I know where the Next button is because I cheated and ran the corelDRAW CD on the XP box, where it works, of course. Not being able to transmit Next to the popup is a stalemate position. But here is some trace output from the same time, you will need to imagine the trace positions in the code. Necessarily, as above, I clicked the "Cancel" button toward the end of this trace fragment. trace:dajo:ITERATE_Actions POS 61 L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 21 0 0 trace:dajo:ACTION_HandleStandardAction POS 31 0 1 trace:dajo:ACTION_HandleStandardAction UNHANDLED STD ACTION L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 22 0 trace:dajo:ACTION_HandleCustomAction UNHANDLED CTM ACTION L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 23 0 trace:dajo:ACTION_DialogBox POS 81 L"LicenseAgreement" trace:dajo:event_do_dialog POS 91 L"LicenseAgreement" trace:dajo:event_do_dialog POS 92 L"LicenseAgreement" trace:dajo:WineEngCreateFontInstance POS 51 L"System" trace:dajo:WineEngCreateFontInstance POS 52 L"System" trace:dajo:WineEngCreateFontInstance POS 51 L"Tahoma" trace:dajo:WineEngCreateFontInstance POS 52 L"Tahoma" trace:dajo:WineEngCreateFontInstance POS 51 L"ArialMT" fixme:font:WineEngCreateFontInstance Untranslated charset 77 trace:dajo:WineEngCreateFontInstance POS 53 L"ArialMT" trace:dajo:WineEngCreateFontInstance POS 52 L"ArialMT" trace:dajo:WineEngCreateFontInstance POS 51 L"Tahoma" trace:dajo:WineEngCreateFontInstance POS 52 L"Tahoma" trace:dajo:event_do_dialog POS 91 L"CancelSetup" trace:dajo:event_do_dialog POS 92 L"CancelSetup" trace:dajo:ACTION_DialogBox POS 82 L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 24 1 trace:dajo:ACTION_PerformUIAction HANDLED MSI ACTION L"LicenseAgreement" trace:dajo:ACTION_PerformUIAction POS 25 1 err:msi:ITERATE_Actions Execution halted, action L"LicenseAgreement" returned 1602 So, it appears that the untranslated character set 77 (ArialMT) is preventing the corelDRAW popup from displaying properly - that, of course, is a wild guess at the moment. But, in a curious way, it ties in with the other problems with fonts that I have experienced. OK, so I should fix the FIXME. But now I am back to the code/structure/policy problem. Is the solution as simple as hacking up ArialMT to work, or does this need some proper action to solve a more general problem? So this marks the point where I decided to write what you are reading. I need guidance on policy mainly, I think. I should like help on how this error, and its solution, fits in to the larger Wine picture. I hope that I have presented, what is becoming, my dilemma. I *really* want to handled these problems, and, now that I started to find my way around in Wine, maybe do some other things, all with one objective of helping the Wine project. But I have other pressures on me, and I have this uncomfortable feeling of opening ever-widening boxes of worms. I cannot continue to spend days of time without some feeling that the scope of the task is going to contract rather than expand further. In conclusion, I can report that corelDRAW X3 does not install (also see the appDB for confirmation), which is regressive wrt version 11, which is rated as Gold. Some of the reasons are given above. The required OS is either XP or 2000, an attempt to use soemthing else brings up a message stating that. Thanks for reading this. David

1 0

Re: [PATCH] [2/2] winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUse
by Peter Oberndorfer Sept. 26, 2007

Sept. 26, 2007

On Wednesday 26 September 2007, Peter Oberndorfer wrote: > --- > dlls/winhttp/main.c | 25 +++++++++++++++++++++++++ > dlls/winhttp/winhttp.spec | 2 +- > 2 files changed, 26 insertions(+), 1 deletions(-) > There is a 'r' missing in the patch title. it should be: winhttp: stub impl of WinHttpGetIEProxyConfigForCurrentUser Greetings Peter

1 0

Re: [PATCH 2/2] configure: Build wine-kthread on FreeBSD.
by Tijl Coosemans Sept. 26, 2007

Sept. 26, 2007

On Wednesday 26 September 2007 19:24:24 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.

1 0

Re: [PATCH 1/2] loader: Reduce data segment size in wine-pthread/kthread on FreeBSD.
by Tijl Coosemans Sept. 26, 2007

Sept. 26, 2007

On Wednesday 26 September 2007 19:17:44 Charlie wrote: This is me. I guess I called git-format-patch from a terminal where I was root.

1 0

Re: [5/5] WineD3D: Add sincos support to arb shaders
by H. Verbeet Sept. 26, 2007

Sept. 26, 2007

On 26/09/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + /* dst.w = src[0].w * 1 / (src.x^2 + src.y^2 + src.z^2)^(1/2) according to msdn*/ That comment looks a bit out of place for sincos. Copy-paste from nrm?

1 0

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size (try 2)
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

a_villacis(a)palosanto.com writes: > I considered doing this at first, but ME_ToCF2W is used in three other > places beside handling EM_SETCHARFORMAT (all in style.c), and those places > might get a null-pointer exception instead of an assert if something went > wrong. A null-pointer exception serves the same purpose as an assert, and they both result in a debugger backtrace, so there's no reason to add more asserts here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Cannot compile wine due to recent changes
by Kirill K. Smirnov Sept. 26, 2007

Sept. 26, 2007

Hi, I got the following error message during compile fresh git-current wine: gcc -c -I../../../dlls/winex11.drv -I. -I../../../include -I../../include -I/usr/X11R6/include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o x11drv_main.o ../../../dlls/winex11.drv/x11drv_main.c In file included from ../../../dlls/winex11.drv/x11drv_main.c:52: ../../../dlls/winex11.drv/xcomposite.h:40: error: `XCompositeGetOverlayWindow' undeclared here (not in a function) ../../../dlls/winex11.drv/xcomposite.h:40: warning: type defaults to `int' in declaration of `pXCompositeGetOverlayWindow' ../../../dlls/winex11.drv/xcomposite.h:41: error: `XCompositeReleaseOverlayWindow' undeclared here (not in a function) ../../../dlls/winex11.drv/xcomposite.h:41: warning: type defaults to `int' in declaration of `pXCompositeReleaseOverlayWindow' ../../../dlls/winex11.drv/x11drv_main.c:389: warning: type defaults to `int' in declaration of `pXCompositeGetOverlayWindow' ../../../dlls/winex11.drv/x11drv_main.c:390: warning: type defaults to `int' in declaration of `pXCompositeReleaseOverlayWindow' make[2]: *** [x11drv_main.o] Ошибка 1 make[2]: Leaving directory `/home/lich/wine/wine/build/dlls/winex11.drv' make[1]: *** [winex11.drv] Ошибка 2 make[1]: Leaving directory `/home/lich/wine/wine/build/dlls' make: *** [dlls] Ошибка 2 X is Xorg 6.9.0 -- Kirill

2 1

Re: services.exe[2/8]: load services list from registry
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > + buf = HeapAlloc(GetProcessHeap(), 0, size + 4); > + if ((err = RegQueryValueExW(hKey, szValue, 0, &type, (LPBYTE)buf, &size)) != 0) > + goto failed; > + buf[size/2] = 0; > + buf[size/2 + 1] = 0; Please use sizeof(WCHAR) instead of hardcoding values like 2 and 4. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/6] Make ntdll I/O function to generate completion events
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > This has to be done in client because server does not > know about actual operation details (e.g. io.Information), > and moreover some operations does not use server at all. The needed information can be sent to the server along with the normal async status. We shouldn't add yet another server call for this, async I/O already requires too many server roundtrips. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/6] Allow completion object to be attached to a fd object
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

Andrey Turkin <andrey.turkin(a)gmail.com> writes: > +struct compl_map *create_completion_map( obj_handle_t handle, unsigned long completion_key ) > +{ > + struct completion *completion; > + struct compl_map *map; > + > + if ((completion = get_completion_obj( current->process, handle, IO_COMPLETION_MODIFY_STATE )) == NULL) > + return NULL; > + if ((map = mem_alloc( sizeof(*map) )) == NULL) > + { > + release_object( completion ); > + return NULL; > + } > + map->completion = completion; > + map->completion_key = completion_key; > + return map; > +} There doesn't seem to be a need for a separate compl_map type here, you could just as well store the completion object in the fd structure directly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: services.exe/advapi32[5/8]: move QueryServiceConfig to services.exe
by Robert Shearman Sept. 26, 2007

Sept. 26, 2007

Mikolaj Zalewski wrote: > My QueryServiceConfig is not compatible with Windows one - I haven't > tried hard but I couldn't tune the parameters to connect with Windows > services.exe. So I'm not trying to store the structure in the on the > server side buffer but pass it all through the RPC and put in into the > buffer in advapi32. As I understand in near future Wine will not be a > member of Windows domains so on-the-wire compatibility is not very > important. > You don't need to be a member of a domain to use remote interfaces like the one for services or the one for the registry. On-the-wire compatibility will be important once we get remote named pipe support, but getting the right architecture is the goal at the moment, and your patches are a step towards that. I believe that the QUERY_SERVICE_CONFIGW parameter should be a byte_count one, but this is not implemented yet, both in the RPC runtime and in widl. -- Rob Shearman

1 0

Re: RICHED20: EM_SETCHARFORMAT must return 0, not assert, on invalid struct size
by Alexandre Julliard Sept. 26, 2007

Sept. 26, 2007

a_villacis(a)palosanto.com writes: > Changelog: > * EM_SETCHARFORMAT must not assert on invalid structure size. Instead, it > should just fail and return 0. It would be better to do that in ME_ToCF2W since it already has to check the size, simply make it return NULL on error or something like that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: pdh: add tests for XP variant of api call
by Hans Leidekker Sept. 26, 2007

Sept. 26, 2007

On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c All tests succeed here on 2003 without your patch. Even if APIs return different values on different versions of Windows we should not add version checks. Instead we should accept all possible return values or remove the test altogether when it's clear that you cannot depend on specific return values. -Hans

2 5

Recent BiDi changes
by Shachar Shemesh Sept. 26, 2007

Sept. 26, 2007

Hi Maarten, Can you, please, explain the advantage of creating our own implementation of the BiDi algorithm over using existing implementations? I know ICU sucks (especially as far as linkage is concerned), but there are other implementations, major among which is fribidi, which are free, are C based, and have a compatible license. Is there any need to Wine to be aware of the inside working of the algorithm? Also, so long as you are picking up the BiDi glove I dropped oh so many years ago, it seems to me that the proper place to implement BiDi would be in unscribe, where it is for Windows. The GDI implementation Wine has is a hack that reached it's useful end the moment you realize that DrawText needs its own implementation, independent of ExtTextOut (mostly due to line breaking code). Thanks, Shachar

3 6

Re: shell32[1/2]: shlview: make the shell view control Unicode (fixesbuf #9767)
by Dmitry Timoshkov Sept. 26, 2007

Sept. 26, 2007

"Mikolaj Zalewski" <mikolaj(a)zalewski.pl> wrote: > When the control class is Unicode the listview will be sending > LVN_GETDISPINFOW instead of LVN_GETDISPINFOA and filenames with > charactes outside of the ACP will display properly. > I'm changing the type of a define from the include/ directory but > that's a define not present in the Windows SDK. If that define doesn't present in SDK it shouldn't be in Wine either. > --- a/include/shlobj.h > +++ b/include/shlobj.h > @@ -149,7 +149,7 @@ typedef struct > */ > > typedef GUID SHELLVIEWID; > -#define SV_CLASS_NAME ("SHELLDLL_DefView") > +#define SV_CLASS_NAME ((const WCHAR[]){'S','H','E','L','L','D','L','L','_','D','e','f','V','i','e','w',0}) This construct is not portable. Please move this to appropriate source file, and use 'static const WCHAR ...' syntax. -- Dmitry.

1 0

Re: comctl32: remove unneeded todo_wine, because test pass
by James Hawkins Sept. 26, 2007

Sept. 26, 2007

On 9/25/07, Christian Gmeiner <christian.gmeiner(a)gmail.com> wrote: > I am running make test an a fresh git fetch; git rebase origin and am > getting this: > > ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p > comctl32_test.exe.so monthcal.c && touch monthcal.ok > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2006 wp=00000000 lp=00000000 > err:monthcal:MONTHCAL_WindowProc unknown msg 2005 wp=00000001 lp=00000000 > monthcal.c:818: Test succeeded inside todo block: Expected 131073, got 131073 > make[2]: *** [monthcal.ok] Fehler 1 > > This patch removes the todo_wine.. as it seems to work now. If this > patch gets not accepted, please tell me why. > Becuase it doesn't pass for other people, particularly Julliard; otherwise, it would have been fixed by now. -- James Hawkins

5 4

Wine GSoC 2007 project membership
by Alexander Nicolaysen Sørnes Sept. 25, 2007

Sept. 25, 2007

Hello all, I received a passing evaluation in this year's GSoC, but I was not added to the Wine project hosting for 2007, does anyone here have the power to add me? Alexander N. Sørnes

2 3

Re: user32: Make message test pass cleanly under XP SP2
by Alexandre Julliard Sept. 25, 2007

Sept. 25, 2007

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > /* posted message */ > PostMessageA( hwnd, WM_CHAR, dbch[0], 0 ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); > ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); > ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); > ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > > /* posted thread message */ > PostThreadMessageA( GetCurrentThreadId(), WM_CHAR, dbch[0], 0 ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); > PostMessageA( hwnd, WM_CHAR, dbch[1], 0 ); > ok( PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "no message\n" ); > ok( msg.message == WM_CHAR, "unexpected message %x\n", msg.message ); > ok( msg.wParam == wch, "bad wparam %lx/%x\n", msg.wParam, wch ); > + msg.message = 0xdeadbeef; > ok( !PeekMessageW( &msg, hwnd, 0, 0, PM_REMOVE ), "got message %x\n", msg.message ); I'm not sure I see the point of that change, since the message is not tested when PeekMessage fails. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering
by Alexandre Julliard Sept. 25, 2007

Sept. 25, 2007

Chris Robinson <chris.kcat(a)gmail.com> writes: > + if(w > 0 && h > 0) { > + XFlush(gdi_display); > + XCopyArea(gdi_display, physDev->gl_drawable, physDev->drawable, > + physDev->gc, 0, 0, w, h, physDev->dc_rect.left, > + physDev->dc_rect.top); Why do you need an XFlush here? > + if(data->whole_window && vis->visualid == XVisualIDFromVisual(visual)) > + { > + TRACE("Whole window available and visual match, rendering onscreen\n"); > + goto done; > + } > + > + if(!composite_gl) > + goto done; There's no sense in having a config option for this since the alternative doesn't work anyway, particularly since you removed the scissor support. > + data->gl_drawable = XCreateWindow(gdi_display, root_window, -w, 0, w, h, > + 0, vis->depth, InputOutput, > + vis->visual, > + CWColormap | CWOverrideRedirect, > + &attrib); The window needs to be created on the thread display, and as a child of the main window. > +static void update_gl_drawable(struct x11drv_win_data *data) > +{ > + unsigned int border, depth; > + int x, y, w, h; > + Window root_win; > + > + if(!data->gl_drawable) > + return; > + > + wine_tsx11_lock(); > + XGetGeometry(gdi_display, data->gl_drawable, &root_win, &x, &y, > + (unsigned int*)&w, (unsigned int*)&h, &border, &depth); You must not use XGetGeometry, this incurs a server round-trip. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: user32: Make message test pass cleanly under XP SP2
by Anatoly Lyutin Sept. 25, 2007

Sept. 25, 2007

Dmitry Timoshkov wrote: > Hello, > > Changelog: > user32: Make message test pass cleanly under XP SP2. > > --- > dlls/user32/tests/msg.c | 142 +++++++++++++++++++++++++++++++++------------- > 1 files changed, 102 insertions(+), 40 deletions(-) > > > > @@ -224,51 +226,53 @@ static const struct message WmSwitchChild[] = { > /* Switch MDI child */ > { WM_MDIACTIVATE, sent },/* in the MDI client */ > { WM_WINDOWPOSCHANGING, sent|wparam,SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */ > + { EVENT_OBJECT_REORDER, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > { WM_CHILDACTIVATE, sent },/* in the 1st MDI child */ > /* Deactivate 2nd MDI child */ > - { WM_NCACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_CREATE, hook }, > + { WM_NCACTIVATE, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */ > + { WM_MDIACTIVATE, sent|defwinproc }, /* in the 2nd MDI child */ > + { HCBT_MINMAX, hook|lparam, 0, SW_MAXIMIZE }, > /* Preparing for maximize and maximaze the 1st MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_FRAMECHANGED|SWP_STATECHANGED },/* in the 1st MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI child */ > - { WM_CHILDACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_MOVE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_SIZE, sent|defwinproc|optional },/* in the 1st MDI child */ > + { WM_GETMINMAXINFO, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_FRAMECHANGED|SWP_STATECHANGED }, /* in the 1st MDI child */ > + { WM_NCCALCSIZE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { WM_CHILDACTIVATE, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000 }, /* in the 1st MDI child */ > + { WM_SIZE, sent|defwinproc|wparam, SIZE_MAXIMIZED }, /* in the 1st MDI child */ > /* Lock redraw 2nd MDI child */ > - { WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_FRAMECHANGED|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 2nd MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_CREATE, hook }, > + { WM_SETREDRAW, sent|wparam|defwinproc, 0 }, /* in the 2nd MDI child */ > + { HCBT_MINMAX, hook|lparam, 0, SW_NORMALNA }, > /* Restore 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_SHOWWINDOW|SWP_STATECHANGED },/* in the 2nd MDI child */ > - { WM_GETMINMAXINFO, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_NCCALCSIZE, sent|wparam|defwinproc|optional, 1 },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGED, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_MOVE, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_SIZE, sent|defwinproc|optional },/* in the 2nd MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|0x8000 },/* in the 2nd MDI child */ > + { WM_NCCALCSIZE, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */ > + { EVENT_OBJECT_SHOW, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam|defwinproc, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE|0x8000 }, /* in the 2nd MDI child */ > + { WM_SIZE, sent|defwinproc|wparam, SIZE_RESTORED }, /* in the 2nd MDI child */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in the 2nd MDI child */ > /* Redraw 2nd MDI child */ > - { WM_SETREDRAW, sent|defwinproc|optional },/* in the 2nd MDI child */ > - { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOACTIVATE|SWP_NOSIZE|SWP_FRAMECHANGED|SWP_NOMOVE },/* in the MDI frame */ > - { WM_NCCALCSIZE, sent|wparam, 1 },/* in the MDI frame */ > - { WM_WINDOWPOSCHANGED, sent},/* in the MDI frame */ > - { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc|optional, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE },/* in the 1st MDI child */ > - { WM_NCACTIVATE, sent|wparam|defwinproc|optional, 1 },/* in the 1st MDI child */ > - { WM_SETVISIBLE, hook }, > - { WM_KILLFOCUS, sent|defwinproc|optional }, /* in the 2nd MDI child */ > - { WM_IME_SETCONTEXT, sent|wparam|optional, 0 }, /* in MDI client */ > - { WM_IME_SETCONTEXT, sent|wparam|optional, 1 }, > + { WM_SETREDRAW, sent|wparam|defwinproc, 1 },/* in the 2nd MDI child */ > + /* Redraw MDI frame */ > + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE },/* in MDI frame */ > + { WM_NCCALCSIZE, sent|wparam, 1 },/* in MDI frame */ > + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_NOACTIVATE|SWP_FRAMECHANGED|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE}, /* in MDI frame */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in MDI frame */ > + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam, 0, 0 }, /* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGING, sent|wparam|defwinproc, SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, /* in the 1st MDI child */ > + { WM_NCACTIVATE, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { HCBT_SETFOCUS, hook }, > + { WM_KILLFOCUS, sent|defwinproc }, /* in the 2nd MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam|defwinproc, 0 },/* in the 1st MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam, 1 }, /* in MDI client */ > { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > { WM_SETFOCUS, sent },/* in the MDI client */ > - { WM_SETVISIBLE, hook }, > + { HCBT_SETFOCUS, hook }, > { WM_KILLFOCUS, sent },/* in the MDI client */ > - { WM_SETFOCUS, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_MDIACTIVATE, sent|defwinproc|optional },/* in the 1st MDI child */ > - { WM_WINDOWPOSCHANGED, sent },/* in the 1st MDI child */ > + { WM_IME_SETCONTEXT, sent|wparam, 0 }, /* in MDI client */ > + { WM_IME_SETCONTEXT, sent|wparam|defwinproc, 1 }, /* in the 1st MDI child */ > + { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, > + { WM_SETFOCUS, sent|defwinproc }, /* in the 1st MDI child */ > + { WM_MDIACTIVATE, sent|defwinproc },/* in the 1st MDI child */ > + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, /* in the 1st MDI child */ > { 0 } > }; > Sorry! It falls in my Windows XP SP2 with: msg.c:3267:expected 0009 - actual 0009 msg.c:3267:expected 0008 - actual 0008 msg.c:3267:expected 0281 - actual 0007 msg.c:3267: Test failed: Child did not switch correctly: the msg 0x0281 was expected, but got msg 0x0007 instead msg.c:3268:end of test for switch maximized MDI children -- Best regards Anatoly Lyutin.

2 2

Re: widl [2/6]: Fix conformant array test failures
by Alexandre Julliard Sept. 25, 2007

Sept. 25, 2007

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This patch gets conformant arrays working in the tests. Currently, only > the address of some conformant arrays are being marshalled, and this wasn't > showing up in the tests because some storage was static. This patch fixes > the problem by writing pointers to conformant array types in the format > string. This also requires handling field pointer conformances, and > expression evaluation routines that expect the containing structure of a > conformant array at the top of the stack, rather than the conformant array > itself. With this patch, the tests still pass, but correctly this time. It breaks the ole32 tests: ../../../tools/runtest -q -P wine -M ole32.dll -T ../../.. -p ole32_test.exe.so moniker.c && touch moniker.ok moniker.c:897: Test failed: IRunningObjectTable_EnumRunning hr=800703e6 wine: Unhandled page fault on read access to 0x00000000 at address 0x60527ff6 (thread 0010), starting debugger... WineDbg starting on pid 000f Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x60527ff6). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60527ff6 ESP:0033fa90 EBP:0033fe58 EFLAGS:00010206( - 00 - RIP1) EAX:0033fe30 EBX:6054601c ECX:00000000 EDX:00000000 ESI:800703e6 EDI:6053e4ec Stack dump: 0x0033fa90: 00000000 6053e498 800703e6 60542308 0x0033faa0: 0033fe34 00000100 00000000 00000000 0x0033fab0: 60547478 60547474 6053cdc8 0033fe48 0x0033fac0: 0033fe44 0033fe40 0033fe38 0033fe20 0x0033fad0: 6053d190 60542308 0033fe14 6053e720 0x0033fae0: 6053e2dc 60539d74 6053e154 60539de8 Backtrace: =>1 0x60527ff6 func_moniker+0x15f6() [/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test (0x0033fe58) 2 0x60538df8 run_test+0x128(name=0x1103ce) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:389] in ole32_test (0x0033fea8) 3 0x6053948d main+0x14d(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/ole32/tests/../../../include/wine/test.h:437] in ole32_test (0x0033fed8) 4 0x6053955b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in ole32_test (0x0033ff08) 5 0x7b87446e start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8) 6 0x600289a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x60527ff6 func_moniker+0x15f6 [/home/julliard/wine/wine/dlls/ole32/tests/moniker.c:898] in ole32_test: movl 0x0(%edx),%ecx 898 hr = IEnumMoniker_QueryInterface(spEM1, &IID_IUnknown, (void*) &lpEM1); Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wtsapi32: add stub for WTSRegisterSessionNotification
by Louis. Lenders Sept. 24, 2007

Sept. 24, 2007

Anything wrong with these simple stubs? http://www.winehq.org/pipermail/wine-patches/2007-September/043944.html and http://www.winehq.org/pipermail/wine-patches/2007-September/043945.html ? --------------------------------- Yahoo! Answers - Get better answers from someone who knows. Tryit now.

1 0

Re: mlang: fix memory leaks in error path (found by Smatch).
by Tijl Coosemans Sept. 24, 2007

Sept. 24, 2007

On Monday 24 September 2007 14:20:51 Lionel_Debroux wrote: > ConvertINetString leaks some heap memory in an error path. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > 2007-09-24 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/mlang/mlang.c: > mlang: fix memory leaks in error path (found by Smatch). > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index eb14ad0..c6274c5 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -635,9 +635,10 @@ HRESULT WINAPI ConvertINetString( > pDstStrW = HeapAlloc(GetProcessHeap(), 0, cDstSizeW * sizeof(WCHAR)); > hr = ConvertINetMultiByteToUnicode(pdwMode, dwSrcEncoding, pSrcStr, pcSrcSize, pDstStrW, &cDstSizeW); > if (hr != S_OK) > - return hr; > + goto cleanup; > > hr = ConvertINetUnicodeToMultiByte(pdwMode, dwDstEncoding, pDstStrW, &cDstSizeW, pDstStr, pcDstSize); > +cleanup: > HeapFree(GetProcessHeap(), 0, pDstStrW); > return hr; > } This is a bikeshed issue really, but I wonder what Wine's policy on gotos like this is. Imo, it's better to add the HeapFree call to the if block and let the compiler work it out.

3 2

Would like to contribute to wine
by Maciej Kowalczyk Sept. 24, 2007

Sept. 24, 2007

Hi all, I'm looking for subject for my Master's thesis. It might be interesting to do something useful for Wine. On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress. I think it is doable because Windows 2000 and later printer drivers are work in user-space. In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS. Or maybe you have other ideas? Best regards, Maciej Kowalczyk

6 8

Re: Does MWM_DECOR_BORDER really cause window to have caption?
by Kirill K. Smirnov Sept. 24, 2007

Sept. 24, 2007

> > Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless > > window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK > > without it. > > If you mean the following line in > dlls/winex11.drv/window.c,X11DRV_set_wm_hints() > > else if (!(style & (WS_CHILD|WS_POPUP))) mwm_hints.decorations |= > MWM_DECOR_BORDER; > > then you can always send a patch with an explanation why it's needed. Of course, I can send a patch, which just removes this line with some explanations (referring to winamp), but I'm afraid it may break something. Since original patch introduced this code, there is an application which depends on this. But that original patch does not contain any hint, so I ask the list in hope somebody might know the reason. -- Kirill

1 0

Re: mlang: fix memory leaks in error paths (found by Smatch).
by Lionel_Debroux Sept. 24, 2007

Sept. 24, 2007

Lionel_Debroux wrote: > EnumRfc1766_create leaks some heap memory in two error paths. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > 2007-09-24 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/mlang/mlang.c: > mlang: fix memory leaks in error paths (found by Smatch). > > > > ------------------------------------------------------------------------ > >>From 394f63633148d76fa322b726218e8a824e5a3930 Mon Sep 17 00:00:00 2001 > From: Lionel Debroux <lionel_debroux(a)yahoo.fr> > Date: Mon, 24 Sep 2007 14:12:10 +0200 > Subject: mlang: fix memory leaks in error paths (found by Smatch). > > --- > dlls/mlang/mlang.c | 13 +++++++++++-- > 1 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/dlls/mlang/mlang.c b/dlls/mlang/mlang.c > index b5b8e0d..eb14ad0 100644 > --- a/dlls/mlang/mlang.c > +++ b/dlls/mlang/mlang.c > @@ -1885,7 +1885,11 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang, LANGID LangId, > data.total = 0; > data.allocated = 32; > data.info = HeapAlloc(GetProcessHeap(), 0, data.allocated * sizeof(RFC1766INFO)); > - if (!data.info) return S_FALSE; > + if (!data.info) > + { > + HeapFree(rfc); > + return S_FALSE; > + } > > TlsSetValue(MLANG_tls_index, &data); > EnumSystemLocalesW(enum_locales_proc, 0/*LOCALE_SUPPORTED*/); > @@ -1893,7 +1897,12 @@ static HRESULT EnumRfc1766_create(MLang_impl* mlang, LANGID LangId, > > TRACE("enumerated %d rfc1766 structures\n", data.total); > > - if (!data.total) return FALSE; > + if (!data.total) > + { > + HeapFree(data.info); > + HeapFree(rfc); > + return FALSE; > + } > > rfc->info = data.info; > rfc->total = data.total; Err, screw that. The two first parameters "GetProcessHeap(), 0, " of the three HeapFree calls are missing... I did not forget to launch a make process to check my modifications were correct, though. What happened was that everything was recompiled, and by the time the compiler complained, I had already sent the mails by mistake... Sorry. Lionel Debroux.

1 0

Re: Does MWM_DECOR_BORDER really cause window to have caption?
by Kirill K. Smirnov Sept. 24, 2007

Sept. 24, 2007

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > > I'm trying to get winamp playlist window to be painted correctly (bug > > #8300). The problem is: > > 0) wine version is git-current. > > 1) winamp playlist window style is WS_CLIPSIBLINGS > > 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) > > 3) This hint behaviour is WM-dependent: > > a) KDE - caption is painted; > > b) XFCE - ditto; > > c) fluxbox - correct (no caption). > > > > This situation confuses a little. I believe DECOR_BORDER does not add a > > caption to window, but it does under great WM such as KDE. Is this > > behaviour correct? If KDE/XFCE is a culprit, should we add a workaround > > into wine? > > There is a distinct MWM hint to add a caption to a window: MWM_DECOR_TITLE. > If this is proved to be a KDE/XFCE bug it should be reported to an > appropriate bug tracking system. It's better to write pure X11 app to demonstate it, but I am not familiar with it :-( Anyway, what is the purpose of setting MWM_DECOR_BORDER to borderless window (style is WS_CLIPSIBLINGS only)? KDE, XFCE, fluxbox work OK without it. -- Kirill

2 1

Re: pdh: add tests for XP variant of api call
by Hans Leidekker Sept. 24, 2007

Sept. 24, 2007

On Monday 24 September 2007 12:13:50 Jeff Latimer wrote: > This patch adds the variations to the api that XP implements. My > assumption is that these changes will, mostly, be reflected in 2003 and > Vista. I can't check them so if someone could give them a run and let > know, that would be fine. I will get on with adding the variations to pdh.c To prevent you doing any duplicate work, I have implementations of PdhCalculateCounterFromRawValue, PdhCollectQueryDataEx and PdhValidatePath{,Ex} in my tree, along with a range of tests. -Hans

2 1

Does MWM_DECOR_BORDER really cause window to have caption?
by Kirill K. Smirnov Sept. 24, 2007

Sept. 24, 2007

Hi, I'm trying to get winamp playlist window to be painted correctly (bug #8300). The problem is: 0) wine version is git-current. 1) winamp playlist window style is WS_CLIPSIBLINGS 2) winex11 driver converts it to MWM_DECOR_BORDER hint. (window.c:599) 3) This hint behaviour is WM-dependent: a) KDE - caption is painted; b) XFCE - ditto; c) fluxbox - correct (no caption). This situation confuses a little. I believe DECOR_BORDER does not add a caption to window, but it does under great WM such as KDE. Is this behaviour correct? If KDE/XFCE is a culprit, should we add a workaround into wine? Thanks for attention -- Kirill

2 1

Is ICU no longer a dependency of Wine?
by Scott Ritchie Sept. 24, 2007

Sept. 24, 2007

I stumbled across this patch while browsing recent commits: http://www.winehq.org/pipermail/wine-cvs/2007-September/036309.html Am I correct to say that we no longer need libicu when compiling Wine? By the way, it would be nice if someone shot off an email to wine-devel whenever the build dependencies change (either removing or adding a lib) -- it makes it a lot easier on we package maintainers. Thanks, Scott Ritchie

2 1

Re: [2/5] WineD3D: Recompile glsl pixelshaders if the sampler format changes
by Vitaliy Margolen Sept. 24, 2007

Sept. 24, 2007

Stefan Dösinger wrote: > > ------------------------------------------------------------------------ > > This patch causes noticeable slowdown in Counter Strike Source stress test in the first part of it (rotating panels). Testing in dxlevel 80, 1024x768 fbo, cl_monitors 0. I'm getting ~33 fps in that area before patch and around 7 fps with this patch. Vitaliy.

2 1

strange pixel format
by Jose Osvaldo Sept. 24, 2007

Sept. 24, 2007

The No-CD crack for "The Sims" calls to "IDirectDrawImpl_CreateSurface" (ddls/ddraw.c) which calls to "IDirectDrawImpl_CreateNewSurface". One of these calls passes a abnormal value for DDPixelFormat causing "PixelFormat_DD2WineD3D" (dlls/utils.c) to return "WINED3DFMT_UNKNOWN" (0). "IDirectDrawImpl_CreateNewSurface" returns immediately causing the program to fail by raising an exception. In this case, forcing the "IDirectDrawImpl_CreateNewSurface" function to continue with other pixel format, even a not defined one, avoids the exception and "The Sims" starts. The abnormal value is this: dwFlags = 0x00000000 dwSize = 32 dwFourCC = 0x00000000 u1 = 0x00000000 u2 = 0x00000000 u3 = 0x00000000 u4 = 0x00000000 u5 = 0x00000000 I do not know what is the expected behaviour in real Windows. The original executable file crashes with other error, but I think that is caused by the anticopy protection.

2 1

Re: [4/5] WGL: Remove GL scissors/viewport override
by Vitaliy Margolen Sept. 23, 2007

Sept. 23, 2007

Chris Robinson wrote: > > ------------------------------------------------------------------------ > This patch causes crash with virtual desktop. Crash attached. Vitaliy.

2 2

Re: [5/5] winex11: Use an offscreen redirected window for child OpenGL rendering
by Vitaliy Margolen Sept. 23, 2007

Sept. 23, 2007

Chris Robinson wrote: > This uses XComposite, when available, to render GL to an offscreen window, and > updates the win32 window when glFlush/glFinish/SwapBuffers is called. When > rendering to a top-level window with a matching visual, it renders > directly "onscreen", and setting the registry key > HKCU\Software\Wine\X11 Driver\CompositeGL > to false will disable GL compositing behavior even when XComposite is > available (default is enabled). > > Same here, default should be disabled. Do not introduce more regressions in something already broken by default. And don't punish something that works perfectly without anything extra. Vitaliy.

2 1

Re: [1/5] winex11: Load the XComposite extension when available
by Vitaliy Margolen Sept. 23, 2007

Sept. 23, 2007

Chris Robinson wrote: > A set of patches to replace the scissors hack with offscreen rendering and > compositing. Step one, look for and load the XComposite extension libs. > > ------------------------------------------------------------------------ > > +int usexcomposite = 1; It should be off by default until users will have enough time to test if it's working properly. Vitaliy.

2 1

Re: shdocvw: Added WebBrowser::FullScreen property implementation.
by Reece Dunn Sept. 23, 2007

Sept. 23, 2007

On 23/09/2007, Jacek Caban <jacek(a)codeweavers.com> wrote: > --- > dlls/shdocvw/shdocvw.h | 1 + > dlls/shdocvw/tests/webbrowser.c | 23 +++++++++++++++++++++++ > dlls/shdocvw/webbrowser.c | 15 +++++++++++---- > 3 files changed, 35 insertions(+), 4 deletions(-) > + hres = IWebBrowser2_get_FullScreen(wb, &b); > + ok(hres == S_OK, "get_FullScreen failed: %08x\n", hres); > + ok(b == VARIANT_TRUE, "b=%x\n", b); > + > + hres = IWebBrowser2_put_FullScreen(wb, VARIANT_FALSE); > + ok(hres == S_OK, "put_FullScreen failed: %08x\n", hres); > + > IWebBrowser2_Release(wb); This last call to put_FullScreen is missing a get_FullScreen check. Everything else looks ok. - Reece

1 0

Re: [OT] Freemail Terms Of Use [was: Wine autorunner]
by Reece Dunn Sept. 23, 2007

Sept. 23, 2007

On 23/09/2007, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > _________________________________________________________________ > > Connect to the next generation of MSN Messenger > > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= > >wlmailtagline > This is OT regarding this patch, but most people use freemailers, including > hotmail / msn. Some service providers tried to establish some > all-your-copyright-belong-to-us terms of service. Should we take care about > that in any way? Either by making sure that patches aren't sent from such > services, or to make sure that such conditions do not hold up in court? > > I am using gmx myself, and I haven't checked the TOS for changes since years, > and I only gave them a 5 secound look when signing up, so I should start with > checking that myself(I send most patches from my CW address though) Reading the current GoogleMail terms of usage, there is this: "Your Intellectual Property Rights. Google does not claim any ownership in any of the content, including any text, data, information, images, photographs, music, sound, video, or other material, that you upload, transmit or store in your Google Mail account. We will not use any of your content for any purpose except to provide you with the Service." so there is no problem there. Also, the hotmail legal statement has this: "8. Your Materials. You may be able to submit materials for use in connection with the service. Except for material that we license to you, we do not claim ownership of the materials you post or otherwise provide to us related to the service (called a "submission"). However, by posting or otherwise providing your submission, you are granting to the public free permission to: * use, copy, distribute, display, publish and modify your submission, each in connection with the service; * publish your name in connection with your submission; and * grant these permissions to other persons. This section only applies to legally permissible content and only to the extent that use and publishing of the legally permissible content does not breach the law. We will not pay you for your submission. We may refuse to publish, and may remove your submission from the service at any time. For every submission you make, you must have all rights necessary for you to grant the permissions in this section." So you should also be fine there as well, although I do find it interesting that according to this (if I have read it correctly), anything that you send via hotmail is freely usable by the public! - Reece

1 0

Re: Wine autorunner
by Stefan Dösinger Sept. 23, 2007

Sept. 23, 2007

Am Sonntag, 23. September 2007 01:42:46 schrieb Computer Dude: > Attached is the git patch for a utility to perform simple parsing of > Windows autorun.inf files, and to run the associated programs under WINE. > It will auto-detect the CD drive if not specified on the command line, > auto-detect the mount point, and attempt to mount it if it i not already > mounted. Shouldn't this be implemented in the gnome / kde autorun support? Perhaps in the form of registering a new autorun "mimetype" which tells gnome/kde about autorun.inf files, and how to use them? _________________________________________________________________ > Connect to the next generation of MSN Messenger > http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source= >wlmailtagline This is OT regarding this patch, but most people use freemailers, including hotmail / msn. Some service providers tried to establish some all-your-copyright-belong-to-us terms of service. Should we take care about that in any way? Either by making sure that patches aren't sent from such services, or to make sure that such conditions do not hold up in court? I am using gmx myself, and I haven't checked the TOS for changes since years, and I only gave them a 5 secound look when signing up, so I should start with checking that myself(I send most patches from my CW address though)

2 1

Re: Wine autorunner
by Kai Blin Sept. 23, 2007

Sept. 23, 2007

On Sunday 23 September 2007 01:42:46 Computer Dude wrote: > Attached is the git patch for a utility to perform simple parsing of > Windows autorun.inf files, and to run the associated programs under WINE. You need to provide your real name for your patch to be considered at all. Wine will not accept anonymous patches. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

WM_CHAR of Ctrl-C, Ctrl-V appear to have no effect in WinXP-SP2 riched20 control
by a_villacis＠palosanto.com Sept. 23, 2007

Sept. 23, 2007

I am trying to fix a few tests for riched20 that attempt to recover the text from the control with WM_GETTEXT and assume the text will be recovered unchanged. As demostrated in a patch I sent a few minutes ago, this assumption is not true when the text to recover contains unbalanced \r, which are converted to \r\n. However I have a strange problem. On my setup (WinXP-SP2 with cygwin), sending Ctrl-C and Ctrl-V with WM_CHAR appears to have no effect on the riched20 control used for the tests. Therefore the text buffer is not modified and the end text remains unchanged. I want to check whether this tests fails in the same way for anybody else, and if not, to receive suggestions on what might be wrong with my setup.

1 0

Re: wine.inf: add some four keys in Active Setup\Installed Components [resend]
by Robert Shearman Sept. 23, 2007

Sept. 23, 2007

Mikolaj Zalewski wrote: > +; Some apps wants at least four keys in Installed Components to run correctly > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{a2f95861-06e5-4e58-ab61-94cbdde2ff55},Version,2,"1,0,0,0" > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{c30a0529-fcef-4b19-8e68-9527b54474ac},Version,2,"1,0,0,0" > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{d0b883e4-af5a-45c9-bd44-deb9867c1d94},Version,2,"1,0,0,0" > +HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{e84bb5b4-7fe1-469c-9f24-5a2af3402108},Version,2,"1,0,0,0" You might want to find four real components always present on Windows to add to this key. -- Rob Shearman

2 1

WineD3D patch submission
by Mitchell Wheeler Sept. 22, 2007

Sept. 22, 2007

Hi all, A week or so ago I tried to get a game working in WINE (Titan Quest), however it seems it really needs a proper DIB engine before it'll be playable. Anyways, in my attempt to get it working I fixed up some issues w/ "IWineD3DDeviceImpl_UpdateSurface.c" in dlls/wined3d, not entirely sure how you guys do things around here so I thought i'd just post my changes to the function in this mailing list and you can do with it what you want. (Note: it actually has a few different methods of doing one thing, enclosed in macro blocks to toggle between them. Technically the first one should work (i think :\) once you guys properly implement surface locking/unlocking, and it's 'simplest', but the last one is the only one that actually works properly (using standard OpenGL calls). You'll probably have to clean up the code to meet your coding standards / etc, maybe remove the custom byte size calculation of compressed images, and some other things - but the functionality is there... i also fixed the existing code that didn't actually do what it was supposed to, heh. Regards, Mitchell Wheeler static HRESULT WINAPI IWineD3DDeviceImpl_UpdateSurface(IWineD3DDevice *iface, IWineD3DSurface *pSourceSurface, CONST RECT* pSourceRect, IWineD3DSurface *pDestinationSurface, CONST POINT* pDestPoint) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *) iface; /** TODO: remove casts to IWineD3DSurfaceImpl * NOTE: move code to surface to accomplish this ****************************************/ IWineD3DSurfaceImpl *pSrcSurface = (IWineD3DSurfaceImpl *)pSourceSurface; IWineD3DSurfaceImpl *pDestSurface = (IWineD3DSurfaceImpl*)pDestinationSurface; int srcWidth, srcHeight; unsigned int srcSurfaceWidth, srcSurfaceHeight, destSurfaceWidth, destSurfaceHeight; WINED3DFORMAT destFormat, srcFormat; int srcLeft, srcTop, destLeft, destTop; WINED3DPOOL srcPool, destPool; int offset = 0; int rowoffset = 0; /* how many bytes to add onto the end of a row to wraparound to the beginning of the next */ glDescriptor *glDescription = NULL, *glSrcDescription = NULL; GLenum dummy; int bpp; UINT destByteSize = 0, srcByteSize = 0; int destPixelByteSize = 0, srcPixelByteSize = 0; CONVERT_TYPES convert = NO_CONVERSION; WINED3DSURFACE_DESC winedesc; TRACE("(%p) : Source (%p) Rect (%p) Destination (%p) Point(%p)\n", This, pSourceSurface, pSourceRect, pDestinationSurface, pDestPoint); memset(&winedesc, 0, sizeof(winedesc)); winedesc.Width = &srcSurfaceWidth; winedesc.Height = &srcSurfaceHeight; winedesc.Pool = &srcPool; winedesc.Format = &srcFormat; winedesc.Size = &srcByteSize; IWineD3DSurface_GetDesc(pSourceSurface, &winedesc); winedesc.Width = &destSurfaceWidth; winedesc.Height = &destSurfaceHeight; winedesc.Pool = &destPool; winedesc.Format = &destFormat; winedesc.Size = &destByteSize; IWineD3DSurface_GetDesc(pDestinationSurface, &winedesc); if(srcPool != WINED3DPOOL_SYSTEMMEM || destPool != WINED3DPOOL_DEFAULT){ WARN("source %p must be SYSTEMMEM and dest %p must be DEFAULT, returning WINED3DERR_INVALIDCALL\n", pSourceSurface, pDestinationSurface); return WINED3DERR_INVALIDCALL; } /* This call loads the opengl surface directly, instead of copying the surface to the * destination's sysmem copy. If surface conversion is needed, use BltFast instead to * copy in sysmem and use regular surface loading. */ d3dfmt_get_conv((IWineD3DSurfaceImpl *) pDestinationSurface, FALSE, TRUE, &dummy, &dummy, &dummy, &convert, &bpp, FALSE); if(convert != NO_CONVERSION) { return IWineD3DSurface_BltFast(pDestinationSurface, pDestPoint ? pDestPoint->x : 0, pDestPoint ? pDestPoint->y : 0, pSourceSurface, (RECT *) pSourceRect, 0); } if (destFormat == WINED3DFMT_UNKNOWN) { TRACE("(%p) : Converting destination surface from WINED3DFMT_UNKNOWN to the source format\n", This); IWineD3DSurface_SetFormat(pDestinationSurface, srcFormat); /* Get the update surface description */ IWineD3DSurface_GetDesc(pDestinationSurface, &winedesc); } ActivateContext(This, This->lastActiveRenderTarget, CTXUSAGE_RESOURCELOAD); ENTER_GL(); if (GL_SUPPORT(ARB_MULTITEXTURE)) { GL_EXTCALL(glActiveTextureARB(GL_TEXTURE0_ARB)); checkGLcall("glActiveTextureARB"); } /* Make sure the surface is loaded and up to date */ IWineD3DSurface_PreLoad(pDestinationSurface); IWineD3DSurface_GetGlDesc(pDestinationSurface, &glDescription); IWineD3DSurface_GetGlDesc(pDestinationSurface, &glSrcDescription); /* this needs to be done in lines if the sourceRect != the sourceWidth */ srcWidth = pSourceRect ? pSourceRect->right - pSourceRect->left : srcSurfaceWidth; srcHeight = pSourceRect ? pSourceRect->bottom - pSourceRect->top : srcSurfaceHeight; srcLeft = pSourceRect ? pSourceRect->left : 0; srcTop = pSourceRect ? pSourceRect->top : 0; destLeft = pDestPoint ? pDestPoint->x : 0; destTop = pDestPoint ? pDestPoint->y : 0; // Calculate the rowOffset / offset values, for copying #define ISDXTFORMAT(format) \ (format == WINED3DFMT_DXT1 || format == WINED3DFMT_DXT2 || format == WINED3DFMT_DXT3 || format == WINED3DFMT_DXT4 || format == WINED3DFMT_DXT5) // Calculating this for our selves because I don't have faith in how surface->bytesPerPixel is calculated... destPixelByteSize = destByteSize / (int)(destSurfaceWidth * destSurfaceHeight); srcPixelByteSize = srcByteSize / (int)(srcSurfaceWidth * srcSurfaceHeight); if(pSourceRect != NULL) { // Irregular surface formats if (destFormat != srcFormat) { FIXME("Can not convert between surface pixel formats..."); // Would require some relatively big code restructuring for rare occurances (that shouldn't even be supported?) return WINED3DERR_INVALIDCALL; } // Uniform surface formats else { if(srcWidth != srcSurfaceWidth || srcLeft > 0) { rowoffset = srcSurfaceWidth * srcPixelByteSize; offset += (srcLeft * srcPixelByteSize); } if(srcTop > 0) offset += srcTop * srcSurfaceWidth * srcPixelByteSize; } } /* Sanity check */ if (IWineD3DSurface_GetData(pSourceSurface) == NULL) { /* need to lock the surface to get the data */ FIXME("Surfaces has no allocated memory, but should be an in memory only surface\n"); } /* TODO: Cube and volume support */ if(rowoffset != 0) { // Compressed texture if (ISDXTFORMAT(destFormat)) { if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) { #if 0 RECT rect; rect.left = destLeft; rect.top = destTop; rect.right = destLeft + srcWidth; rect.bottom = destTop + srcHeight; // Lock source/destination regions WINED3DLOCKED_RECT destRect, srcRect; printf("Locking surfaces...\n"); if( FAILED(IWineD3DSurface_LockRect(pDestinationSurface, &destRect, &rect, 0)) || FAILED(IWineD3DSurface_LockRect(pSourceSurface, &srcRect, pSourceRect, WINED3DLOCK_READONLY))) { // How should we handle this case? Just returning an invalid call for now... return WINED3DERR_INVALIDCALL; } printf("Surfaces locked, copying contents now... "); if(destFormat == WINED3DFMT_DXT1) { printf("DXT1\n"); //memcpy(destRect.pBits, srcRect.pBits, srcRect.Pitch * (srcHeight / 2)); //memcpy(destRect.pBits, srcRect.pBits, srcRect.Pitch * (srcHeight / 2)); memcpy(destRect.pBits, srcRect.pBits, ceil(srcWidth/4) * ceil(srcHeight/4) * 8); } else { printf("DXT2-5\n"); //memcpy(destRect.pBits, srcRect.pBits, srcRect.Pitch * (srcHeight / 4)); memcpy(destRect.pBits, srcRect.pBits, ceil(srcWidth/4) * ceil(srcHeight/4) * 16); } // Unlock source/destination regions IWineD3DSurface_UnlockRect(pSourceSurface); IWineD3DSurface_UnlockRect(pDestinationSurface); printf("Unlocking surfaces...\n"); #elif 0 // Get pointers to the source/destination buffers unsigned char *dest_data = (unsigned char*)IWineD3DSurface_GetData(pDestinationSurface); const unsigned char *src_data = (unsigned char*)IWineD3DSurface_GetData(pSourceSurface); // Copy subsection of source buffer, in to destination buffer. unsigned char *dest_ptr = dest_data + offset; const unsigned char *src_ptr = src_data + offset; size_t i; for(i = 0; i < srcHeight; ++i) { memcpy(dest_ptr, src_ptr, srcWidth * srcPixelByteSize); dest_ptr += rowoffset; src_ptr += rowoffset; } // Upload destination buffer to server GL_EXTCALL(glCompressedTexImage2DARB(glDescription->target, glDescription->level, glDescription->glFormatInternal, srcWidth, srcHeight, 0, destByteSize, dest_data)); checkGLcall("glCompressedTexImage2DARB"); #elif 1 int blocksize = 16; if(destFormat == WINED3DFMT_DXT1) blocksize = 8; #define max(a, b) (a > b? a : b) srcHeight = max(srcHeight, 4); srcWidth = max(srcWidth, 4); #undef max int data_size = (srcWidth / 4) * (srcHeight / 4) * blocksize; int row_size = data_size / srcHeight; int pixel_size = row_size / srcWidth; int stride = srcSurfaceWidth * pixel_size; unsigned char *temp_buffer = HeapAlloc(GetProcessHeap(), 0, data_size); unsigned char *temp_ptr = temp_buffer; // Debug info //printf(" > BytesTotal: %i | BytesPerPixel: %i | RowSize: %i\n", data_size, pixel_size, row_size); //printf(" > Source: %i -> %i, %i -> %i | Dest: %i, %i\n", srcLeft, srcWidth, srcTop, srcHeight, destLeft, destTop); //printf(" > Offset: %i\n", (int)((row_size * srcTop) + srcLeft * pixel_size)); // Get pointers to the source buffer const unsigned char *src_data = (unsigned char*)IWineD3DSurface_GetData(pSourceSurface); src_data += (stride * srcTop) + srcLeft * pixel_size; size_t i; for(i = 0; i < srcHeight; ++i) { memcpy(temp_ptr, src_data, row_size); temp_ptr += row_size; src_data += stride; } GL_EXTCALL(glCompressedTexSubImage2DARB( glDescription->target, glDescription->level, destLeft, destTop, srcWidth, srcHeight, glDescription->glFormatInternal, data_size, temp_buffer )); //checkGLcall("glCompressedTexSubImage2DARB"); HeapFree(GetProcessHeap(), 0, temp_buffer); #endif } else { FIXME("TODO: Need to update a DXT compressed texture without hardware support\n"); } } // Uncompressed texture else { /* not a whole row so we have to do it a line at a time */ int j; /* hopefully using pointer addtion will be quicker than using a point + j * rowoffset */ const unsigned char* data =((const unsigned char *)IWineD3DSurface_GetData(pSourceSurface)) + offset; for(j = destTop; j < (srcHeight + destTop); ++j) { glTexSubImage2D(glDescription->target ,glDescription->level ,destLeft ,j ,srcWidth ,1 ,glDescription->glFormat ,glDescription->glType ,data /* could be quicker using */ ); data += rowoffset; } } } else { // Compressed texture if (ISDXTFORMAT(destFormat)) { if (GL_SUPPORT(EXT_TEXTURE_COMPRESSION_S3TC)) { int blocksize = 16; if(destFormat == WINED3DFMT_DXT1) blocksize = 8; #define max(a, b) (a > b? a : b) int data_size = (max(srcWidth, 4) / 4) * (max(srcHeight, 4) / 4) * blocksize; #undef max //printf(" -> S = %i | CompressedTexImage2D(?, %i, %i, %i, %i, 0, %i, ?)\n", destByteSize, glDescription->level, glDescription->glFormatInternal, srcWidth, srcHeight, data_size); GL_EXTCALL(glCompressedTexSubImage2DARB(glDescription->target, glDescription->level, destLeft, destTop, srcWidth, srcHeight, glDescription->glFormatInternal, data_size, IWineD3DSurface_GetData(pSourceSurface))); checkGLcall("glCompressedTexImage2DARB"); } else { FIXME("TODO: Need to update a DXT compressed texture without hardware support\n"); } } // Uncompressed Texture else { glTexSubImage2D( glDescription->target, glDescription->level, destLeft, destTop, srcWidth, srcHeight, glDescription->glFormat, glDescription->glType, IWineD3DSurface_GetData(pSourceSurface) ); checkGLcall("glTexSubImage2D"); } } LEAVE_GL(); ((IWineD3DSurfaceImpl *)pDestinationSurface)->Flags &= ~SFLAG_INSYSMEM; ((IWineD3DSurfaceImpl *)pDestinationSurface)->Flags |= SFLAG_INTEXTURE; IWineD3DDeviceImpl_MarkStateDirty(This, STATE_SAMPLER(0)); return WINED3D_OK; }

5 7

Re: Minimal Background Intelligent Transfer Service (bits) implementation
by Michael Stefaniuc Sept. 22, 2007

Sept. 22, 2007

Hello Roy, Roy wrote: > This patch provides a first skeleton version of bits.dll. thanks for the patch but could you please add also a DLL_WINE_PREATTACH case in DllMain()? That way Wine can prefer to load a native bits DLL (if one is available) until the Wine one gets usable. See for example the mscoree DLL for an example (dlls/mscoree/mscoree_main.c). thanks bye michael > From 95f4728e706861f201fb2b399e7ca5db128e71b3 Mon Sep 17 00:00:00 2001 > From: Roy Shea <roy(a)cs.ucla.edu> > Date: Tue, 18 Sep 2007 14:29:14 -0700 > Subject: Minimal Background Intelligent Transfer Service (bits) implementation > > --- > dlls/bits/Makefile.in | 16 ++++++++++++++++ > dlls/bits/bits.spec | 4 ++++ > dlls/bits/bits_main.c | 43 +++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 63 insertions(+), 0 deletions(-) > create mode 100644 dlls/bits/Makefile.in > create mode 100644 dlls/bits/bits.spec > create mode 100644 dlls/bits/bits_main.c > > diff --git a/dlls/bits/Makefile.in b/dlls/bits/Makefile.in > new file mode 100644 > index 0000000..2c9e293 > --- /dev/null > +++ b/dlls/bits/Makefile.in > @@ -0,0 +1,16 @@ > +TOPSRCDIR = @top_srcdir@ > +TOPOBJDIR = ../.. > +SRCDIR = @srcdir@ > +VPATH = @srcdir@ > +MODULE = bits.dll > +IMPORTS = kernel32 > +EXTRALIBS = > + > +C_SRCS = \ > + bits_main.c > + > +#RC_SRCS = version.rc > + > +(a)MAKE_DLL_RULES@ > + > +(a)DEPENDENCIES@ # everything below this line is overwritten by make depend > diff --git a/dlls/bits/bits.spec b/dlls/bits/bits.spec > new file mode 100644 > index 0000000..c5fc87a > --- /dev/null > +++ b/dlls/bits/bits.spec > @@ -0,0 +1,4 @@ > +@ stub DllCanUnloadNow > +@ stub DllGetClassObject > +@ stub DllRegisterServer > +@ stub DllUnregisterServer > diff --git a/dlls/bits/bits_main.c b/dlls/bits/bits_main.c > new file mode 100644 > index 0000000..37be887 > --- /dev/null > +++ b/dlls/bits/bits_main.c > @@ -0,0 +1,43 @@ > +/* > + * Implementation of bits.dll > + * Background Intelligent Transfer Service (bits) interface > + * > + * Copyright 2007 Google (Roy Shea) > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include <stdarg.h> > + > +#include "windef.h" > +#include "wine/debug.h" > + > +WINE_DEFAULT_DEBUG_CHANNEL( bits ); > + > +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) > +{ > + TRACE("(%p, %d, %p)\n", hinstDLL, fdwReason, lpvReserved); > + > + switch (fdwReason) > + { > + case DLL_PROCESS_ATTACH: > + DisableThreadLibraryCalls(hinstDLL); > + break; > + case DLL_PROCESS_DETACH: > + break; > + } > + > + return TRUE; > +} > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

3 2

Re: services.exe[3/3]: start a local RPC server [fixed]
by Robert Shearman Sept. 22, 2007

Sept. 22, 2007

Mikolaj Zalewski wrote: > diff --git a/dlls/advapi32/Makefile.in b/dlls/advapi32/Makefile.in > index 8f6fe33..85e9680 100644 > --- a/dlls/advapi32/Makefile.in > +++ b/dlls/advapi32/Makefile.in > @@ -5,7 +5,7 @@ SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = advapi32.dll > IMPORTLIB = libadvapi32.$(IMPLIBEXT) > -IMPORTS = kernel32 ntdll > +IMPORTS = rpcrt4 kernel32 ntdll I think you should make rpcrt4 a DELAYIMPORT since it should only be needed for program that use services. Also, you have added one or two header files that don't have a copyright and LGPL statement at the top, which should probably be fixed before the final version (the exception is the one-line files to make the generated files appear in the right place). -- Rob Shearman

1 0

Re: advapi32: add some more rights constants for ConvertStringSecurityDescriptorToSecurityDescriptor
by Hans Leidekker Sept. 22, 2007

Sept. 22, 2007

On Saturday 22 September 2007 04:19:09 Mikolaj Zalewski wrote: > + > + ADS_RIGHT_DELTE = 0x00010000, You're missing an E there. -Hans

1 0

re: Will ROS and WINE still be steady be synchronized ?
by Dan Kegel Sept. 21, 2007

Sept. 21, 2007

Shachar Shemesh wrote: > As far as I understand this, if I disassemble Microsoft binaries (it is > legal in Israel), then the resulting knowledge is legal to use - > anywhere (in other words - the only one who can be sued is me, and the > jurisdiction is Israel, where the action is legal). I am not a lawyer, but I bet you're wrong there. The disassembled code is probably considered a copy, using it could be a copyright violation, and if any such code snuck into Wine, we'd have to go rip it out at great cost. - Dan

5 11

Re: services.exe[3/3]: start a local RPC server and make advapi32 connect/disconnect to it on service manager handle creation/destruction
by Robert Shearman Sept. 21, 2007

Sept. 21, 2007

Mikolaj Zalewski wrote: > + /* Compatible with Windows function 0x0f */ > + DWORD svcctl_OpenSCManagerW( > + SvcCtlRpcHandle rpc_handle, > + [in,unique,string] LPCWSTR MachineName, > + [in,unique,string] LPCWSTR DatabaseName, > The string attribute should be redundant as LPCWSTR should already be declared as a string type. I also noticed this redundancy in your fourth services patch. > + if ((err = RpcServerInqBindings(&pbindingVector)) != ERROR_SUCCESS) > + { > + WINE_ERR("RpcServerInqBindings failed with error %u\n", err); > + return err; > + } What's the purpose of this? You don't actually use the binding vector anywhere. -- Rob Shearman

1 0

Re: Patch: ntoskrnl.exe - Added PsCreateSystemThread
by Dmitry Timoshkov Sept. 21, 2007

Sept. 21, 2007

"Carroll Vance" <ovencleaner(a)gmail.com> wrote: > I have implemented PsCreateSystemThread in ntoskrnl.exe. This API i have > found used by programs like nProtect gameguard, and is a pretty commonly > used kernel api. This either ends up calling CreateThread or > CreateRemoteThread depending on if a process handle was provided. You can call CreateRemoteThread without any checks for the process handle. > This is my > first patch, I read over the dev docs and patch format, I hope I did not > miss anything. I have tested this with a driver I made and it seemed to work > fine. Your patch mixes tabs and spaces on the same line, that makes formatting messy. Also if you could add spaces around '!=' and '==' in if statements that would make the code slightly more readable. -- Dmitry.

1 0

Re: Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons
by John Klehm Sept. 21, 2007

Sept. 21, 2007

On 9/20/07, Antonio Cuni <anto.cuni(a)gmail.com> wrote: > At least one game (Pro Evolution Soccer 6) rely on the pguid field of > the DIOBJECTDATAFORMAT struct to respond to joystick button's events. > Setting pguid to GUID_Button solves the problem. > > 2007-09-20 Antonio Cuni <anto.cuni(a)gmail.com> > > * dlls/dinput/joystick_linux.c, > dlls/dinput/joystick_linuxinput.c > Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for > joystick buttons > > > + df->rgodf[idx].pguid = &GUID_Button; // some games require the GUID to be > + > df->rgodf[idx].pguid = &GUID_Button; // some games require the GUID to be GUID_Button > You need to use C style comments /* */ Regards =), --John Klehm

1 0

Re: Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for joystick buttons
by Vitaliy Margolen Sept. 21, 2007

Sept. 21, 2007

Antonio Cuni wrote: > At least one game (Pro Evolution Soccer 6) rely on the pguid field of > the DIOBJECTDATAFORMAT struct to respond to joystick button's events. > Setting pguid to GUID_Button solves the problem. > > 2007-09-20 Antonio Cuni <anto.cuni(a)gmail.com> > > * dlls/dinput/joystick_linux.c, > dlls/dinput/joystick_linuxinput.c > Always set DIOBJECTDATAFORMAT.pguid to GUID_Button for > joystick buttons > Thank you for the patch. I have few comments about it: > -- /tmp/wine-0.9.45/dlls/dinput/joystick_linux.c 2007-09-14 19:30:55.000000000 +0200 > +++ ./joystick_linux.c 2007-09-20 17:02:15.000000000 +0200 You should diff from the top of the tree (above line should say dlls/dinput/joystick_linux.c). > + df->rgodf[idx].pguid = &GUID_Button; // some games require the GUID to be GUID_Button C++ comments are not allowed in Wine. Please put comments above the code. > newDevice->buttons[i] = 0x80 | newDevice->numButtons; > + df->rgodf[idx].pguid = &GUID_Button; // some games require the GUID to be GUID_Button > df->rgodf[idx++].dwType = DIDFT_MAKEINSTANCE(newDevice->numButtons++) | DIDFT_PSHBUTTON; Please don't use tabs. Use spaces to keep formating. Vitaliy.

1 0

Re: Implemented PsCreateSystemThread in ntoskrnl.exe
by Juan Lang Sept. 20, 2007

Sept. 20, 2007

Hi Carroll, + if (ProcessHandle!=0) + localThreadHandle = CreateRemoteThread(ProcessHandle,0,0,StartRoutine,StartContext,0,&ThreadId); + else localThreadHandle = CreateThread(0,0,StartRoutine,StartContext,0,&ThreadId); + + if (localThreadHandle==0) return STATUS_SEVERITY_ERROR; You should use NtCreateThread rather than CreateThread. It also returns a proper status, so you don't have to guess like you do here. --Juan

2 2

[PATCH] fix small spelling mistakes
by Juan Lang Sept. 20, 2007

Sept. 20, 2007

Hi Peter, > correct spelling of iff -> if Just so you know, iff is a common abbreviation meaning "if and only if." I don't think that's any clearer in the cases you modified, so I think your patch is fine, I just thought you (and others) might be interested. --Juan

2 1

Will ROS and WINE still be steady be synchronized ?
by theUser BL Sept. 20, 2007

Sept. 20, 2007

Hi! I have also ask the question in a mail in the ROS-Mailinglist -- until now there comes now answer. http://www.reactos.org/archives/public/ros-dev/2007-August/009718.html Will ReactOS and WINE still be steady synchronized? ROS have for example an other Notepad.exe and an other Wordpad.exe The WineMINE have on ROS the colors of the original Windows WinMine. And the cards.dll have other cards. AT first it used the cards of http://nifty.stanford.edu/2004/EstellCardGame/ But after the comment of http://www.reactos.org/archives/public/ros-dev/2007-July/009625.html it used the cards at http://sourceforge.net/projects/macsolitairex WINE on the other side used since the beginning of its cards.dll the Microsoft copyrighted cards, which are also part of MS-Windows. So, for me it seems, that ROS and WINE goes two different ways since some time without syncronizing the source-codes, which can be used for both projects. Is that true? And if yes: Why? Greatings theuserbl _________________________________________________________________ Sie suchen E-Mails, Dokumente oder Fotos? Die neue MSN Suche Toolbar mit Windows-Desktopsuche liefert in sekundenschnelle Ergebnisse. Jetzt neu! http://desktop.msn.de/ Jetzt gratis downloaden!

4 4

Re: WineD3D: better video memory reporting
by Juan Lang Sept. 20, 2007

Sept. 20, 2007

Your patch appears empty: > Type: text/x-diff > Size: 0 bytes --Juan

2 1

Re: setupapi(8/22): Implement SetupDiCreateDeviceInfoW
by Alexandre Julliard Sept. 20, 2007

Sept. 20, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > +static DWORD SETUPDI_DevNameToDevID(LPCWSTR devName) > +{ > + LPCWSTR ptr; > + DWORD devNameLen = lstrlenW(devName), devInst = 0; > + BOOL valid = TRUE; > + > + TRACE("%s\n", debugstr_w(devName)); > + for (ptr = devName; valid && *ptr && ptr - devName < devNameLen; ) > + { > + if (isdigitW(*ptr)) > + { > + devInst <<= 8; This won't do what you want. You'd need *= 10 if the id is really stored in decimal, though 0000 looks more like it should be in hex. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: winex11.drv/wintab32[3/5]: make wintab strings in winex11.drv Unicode, implement WTInfoW
by Alexandre Julliard Sept. 20, 2007

Sept. 20, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > @@ -305,8 +312,8 @@ void X11DRV_LoadTabletInfo(HWND hwnddefault) > hwndTabletDefault = hwnddefault; > > /* Do base initializaion */ > - strcpy(gSysContext.lcName, "Wine Tablet Context"); > - strcpy(gSysDevice.NAME,"Wine Tablet Device"); > + MultiByteToWideChar(CP_UTF8, 0, "Wine Tablet Context", -1, gSysContext.lcName, WT_MAX_NAME_LEN); > + MultiByteToWideChar(CP_UTF8, 0, "Wine Tablet Device", -1, gSysDevice.NAME, WT_MAX_NAME_LEN); You should define Unicode constants directly, there's no need to convert at run-time. > @@ -695,10 +716,12 @@ int X11DRV_AttachEventQueueToTablet(HWND hOwner) > X11DRV_expect_error(data->display,Tablet_ErrorHandler,NULL); > for (cur_loop=0; cur_loop < gNumCursors; cur_loop++) > { > + char cursorNameA[WT_MAX_NAME_LEN]; > int event_number=0; > > + WideCharToMultiByte(CP_UNIXCP, 0, gSysCursor[cur_loop].NAME, -1, cursorNameA, WT_MAX_NAME_LEN, NULL, NULL); > for (loop=0; loop < num_devices; loop ++) > - if (strcmp(devices[loop].name,gSysCursor[cur_loop].NAME)==0) > + if (strncmp(devices[loop].name, cursorNameA, WT_MAX_NAME_LEN)==0) This doesn't look right; if the name overflows the buffer we shouldn't simply match against a truncated string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Alexandre Julliard : wordpad.exe: We can now store binary files in the repository.
by Markus Amsler Sept. 20, 2007

Sept. 20, 2007

So we can also add ttf fonts and get rid of the fontforge dependency? Markus

2 1

Re: kernel32: Don't crash accessing an invalid handle in GlobalSize [try3]
by Dmitry Timoshkov Sept. 20, 2007

Sept. 20, 2007

"James Hawkins" <truiken(a)gmail.com> wrote: > This version compares the pointer value to 64000 instead of using a > try/catch block, as suggested by Alexandre. > - if(pintern->Magic==MAGIC_GLOBAL_USED) > + if(pintern > (PGLOBAL32_INTERN)64000 && pintern->Magic==MAGIC_GLOBAL_USED) > { > if (!pintern->Pointer) /* handle case of GlobalAlloc( ??,0) */ It should be either 65535 (0xffff), or a test for HIWORD(pintern) being 0. Also the cast should be to (char *) on both sides rather than (PGLOBAL32_INTERN). -- Dmitry.

2 1

Handling New IDLs with widl
by Roy Sept. 19, 2007

Sept. 19, 2007

Howdy, I'm looking for advice on how to integrate a new idl into wine. I'm implementing bits and using the widl compiler on the IDL I wrote. My current setup places the IDL in include/ with the build system generating a header file that it posits there. So far, so good. I now need to generate bits_i.c and link that into my dll located in dlls/bits. Adding: ---- IDL_I_SRCS = $(TOPSRCDIR)/include/bits.idl ---- to dlls/bits/Makefile.in solves this problem but drops the bits_i.c into include/. This is rather messy. Any advice on if I should (1) moving my IDL into dlls/bits/ and do everything locally or (2) dig into Make.rules.in and update the rule for *_i.c generation to allow the generated file to exist locally with the .idl sitting in include. The second idea is a little tricky since the current rule is careful to rename the generated .i file with the -U option: ---- .idl_i.c: $(WIDL) $(IDLFLAGS) -u -U $@ $< ---- which is a great idea, but uses the full path to the original idl when renaming the file. Probably good for the general case, but not for me. Thanks for the advice! -Roy

2 1

Re: wineboot: Pass non-zero timeouts to SendMessageTimeout, otherwise the call won't timeout.
by Alexandre Julliard Sept. 19, 2007

Sept. 19, 2007

Robert Shearman <rob(a)codeweavers.com> writes: > Set the default for WM_QUERYENDSESSION to be 5s which should be enough > time for users to respond to any message boxes and WM_ENDSESSION to a > lower 1s. If you are going to timeout on the user interaction you need to popup a confirmation dialog of some kind to allow users to force killing the app; you can't kill it just because the user didn't click on a "do you want to save your file?" message box fast enough. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: widl [2/2]: Implement pointer descriptions for complex structures
by Robert Shearman Sept. 19, 2007

Sept. 19, 2007

Dan Hipschman wrote: > var_t *field, > } > else if (is_ptr(type)) > { > - print_file(file, 2, "0x8,\t/* FC_LONG */\n"); > + unsigned char fc = (cont->type == RPC_FC_BOGUS_STRUCT > + ? RPC_FC_POINTER > + : RPC_FC_LONG); > + print_file(file, 2, "0x%x,\t/* %s */\n", fc, string_of_type(fc)); > *tfsoff += 1; > } > else if (!write_base_type(file, type, tfsoff)) > I sent a patch yesterday which does a similar thing to this chunk. I think we need to agree on which approach we're going to take so we can let Alexandre know which patch to commit. -- Rob Shearman

2 4

Re: winsock: Increase amount of iovec's to 32
by Alexandre Julliard Sept. 19, 2007

Sept. 19, 2007

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > I don't know why WS_MSG_MAXIOVLEN is used here, that seems to be a > message identifier rather then the actual size of MAXIOVLEN, so I added > a define for MAXIOVLEN and made it 32. MSG_MAXIOVLEN is not a message identifier, it's really supposed to be an iovec size. Do you have a test case showing that Windows uses 32 instead? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: include: add a macro to declare critical sections as we declare them in Wine - initialized and with a debug
by Alexandre Julliard Sept. 19, 2007

Sept. 19, 2007

"Mikolaj Zalewski" <mikolajz(a)google.com> writes: > Would such a patch be accepted? No, debug.h is about the libwine debugging API, critical sections have nothing to do with that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv: When minimizing a top level window move it outside of the visible desktop area
by Alexandre Julliard Sept. 19, 2007

Sept. 19, 2007

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > Changelog: > winex11.drv: When minimizing a top level window move it outside of > the visible desktop area. This will break apps that expect to paint their icon window, and probably also break the positioning of the icon title. It also doesn't work even for standard icons in desktop mode. -- Alexandre Julliard julliard(a)winehq.org

1 0