August 2006 - Wine-Devel - list.winehq.org

configure.ac: Show Messages about additional Packages with "--verbose"
by Detlef Riekenberg Aug. 20, 2006

Aug. 20, 2006

We should inform the User, when Wine is build without some Features. This Patch add Hints for additional Packages, which Wine can use. + X11-Extensions: Xext (Shm and shape), XRandr, XRender, Xxf86vmode added + libxslt1 added (libxslt1 depends on libxml2) + libhal added (libhal depends on libdbus-1) + libncurses / libcurses added + libsane added + libgphoto2 added + libicu added + liblcms added + libungif added - libdbus-1 not needed: libhal depends on libdbus-1 - libxml2 not needed: libxslt1 depends on libxml2 As requested by Alexandre, the Messages are displayed only, when requested by the User. I use the Option "--verbose" to enable the Messages. ("--verbose" is a standard Option for configure, but was unused) Changelog: - configure.ac: Show Messages about additional Packages with "--verbose" -- By by ... Detlef

1 0

compiling monolithic winetest executable with MSVC
by Saulius Krasuckas Aug. 20, 2006

Aug. 20, 2006

I've run "tools/api/msvcmaker --no-wine" and got winetest.dsp and wineruntests.dsp project files. If I exclude MSVC-non-compilable separate tests from the last project, some exe file is made. But is does nothing usefull. The first project produces winetest.lib, but its size is only 1272 bytes. I guess something is wrong with msvcmaker. Has anyone tried this? Did I miss something?

1 0

Re: [AppDB] Assorted language fixes for the front page
by Kai Blin Aug. 20, 2006

Aug. 20, 2006

On Sunday 20 August 2006 12:48, Alexander Nicolaysen Sørnes wrote: > Assorted language fixes for the AppDB front page. Shouldn't the first hunk be "howtos" instead of "howto's", anyway? Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: Allow older game to start up directx
by Stefan Dösinger Aug. 20, 2006

Aug. 20, 2006

Am Sonntag 20 August 2006 04:42 schrieb Tony Lambregts: > I have a game that uses Direct X[1] and complains that it is not > installed without this device. Credit for this patch goes to / > <mailto:lionel.ulmer(a)free.fr>/Lionel Ulmer <lionel.ulmer(a)free.fr> > > [1] See bug 2229 for more details. > http://bugs.winehq.org/show_bug.cgi?id=2229 > > Change log: Allow IID_IDirect3DRampDevice as valid Direct X interface. > > Files Changed: dlls/ddraw/direct3d_opengl.c This patch looks outdated, this file does not exist anymore since the ddraw write in 0.9.16. In the new code I couldn't find any check for the device ID(it always succeeds), so this patch shouldn't be needed.

1 0

Re: WineD3D: gpu detection
by Tom Wickline Aug. 19, 2006

Aug. 19, 2006

On 8/18/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > Hello, > > This patch tackles the problem in a different way. The idea is not to return the exact videocard but a close match (a card supporting more or less the same opengl features or with similar performance). Based on test using the closed source drivers from nvidia and ati and also using the opensource radeon dri drivers, I made a list of what extensions are available on the cards. Further I checked which of the extensions indicate correspond to certain directx versions. > You may already be aware of this "Graphics Card Comparison Guide" but in case you don't here is the links, it may help in the match making process....... ATI : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=0 NVIDIA : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=1 XGI : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=2 S3 : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=3 SiS : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=4 Matrox : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=5 PowerVR : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=6 3dfx : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=7 Trident : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=8 Intel : http://www.rojakpot.com/showarticle.aspx?artno=88&pgno=9 Tom

4 3

Re: WineD3D: gpu detection
by Frank Richter Aug. 18, 2006

Aug. 18, 2006

On 19.08.2006 00:09, Roderick Colenbrander wrote: > + } else if(WINE_D3D8_CAPABLE(gl_info)) { > + if (strstr(gl_info->gl_renderer, "GeForce4 Ti") || strstr(gl_info->gl_renderer, "Quadro4")) > + gl_info->gl_card = CARD_NVIDIA_GEFORCE4_TI4200; /* Geforce4 Ti4200/Ti4400/Ti4600/Ti4800, Quadro4 */ > + else if (strstr(gl_info->gl_renderer, "GeForce4 MX")) > + gl_info->gl_card = CARD_NVIDIA_GEFORCE4_MX; /* MX420/MX440/MX460/MX4000 */ Small note: GeForce4 MX is not a DX8 capable card. It's a souped-up GeForce2 MX and labelled "4" for marketing reasons. So perhaps move that check into the DX7 branch. -f.r.

1 0

Re: WineD3D: gpu detection
by Jesse Allen Aug. 18, 2006

Aug. 18, 2006

On 8/18/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > Hi, > > In case of Direct3D each device exports the pci device/vendor ids of the videocard. Lots of programs use these ids to get an idea about the capabilities of the card, enable/disable features based on the detected card or sometimes they are used for evil purposes aswell (working around bugs). .... > > Compared to the first method which I described which solely relied on the parsing of renderer strings this method is better because it takes into account the opengl capabilities of the videocard. So when a new card is out which isn't in our list, we won't fallback to a very basic card but can still return a 'close match' because of the opengl extension checks. > This patch is a nice idea. Some games query pci ids and do stupid things with it if it gets one it doesn't recognize. Using fake ids of a common card will help some. This potentially means that Wine will have better compatability with older games on newer hardware. For me this fixes a problem with battlefront under wine where battlefront sees CARD_WINE and turns everything to low and disables use of programmable shaders completely. It was very annoying because there was no way to force shaders back on in the game. I wrote a hack to fix it, but now I'm glad there is a patch that does this lots better! Thanks Roderick, Jesse

1 0

re-reading from registry
by Christoph Probst Aug. 18, 2006

Aug. 18, 2006

Hi, I'm still working on the clamav integration in wine. One question that came up recently is how to handle configuration changes. I'd like to allow to configure the virusscanner 'online' without restarting the wineserver or applications currently running. As the configuration is stored in the registry I could read all affected values every time I need them (that means several RegQueryValueExA() calls for every virusscan). But I found that this costs quite some time and even seems to cause IE5 to crash (does anyone know or want to know the reason?). When I save a local copy of my registry values and only update them every x seconds everything is fine. But is that a recommended way or is there a better solution to get notified if a registry key has been changed? If found RegNotifyChangeKeyValue() but I'm not sure if it is the right approach ... Cheers Chris -- Kontakt-Details: http://www.christoph-probst.com/kontakt/ PGP-FP: B171 7EA4 988C DD90 1601 D21C 5279 2FAF 9978 AF86

1 0

Re: tools[1/2]: wineprefixcreate: create a freedesktop-enabled menu directory
by Vitaliy Margolen Aug. 18, 2006

Aug. 18, 2006

Thursday, August 17, 2006, 2:08:25 PM, Mikolaj Zalewski wrote: > When creating the wineprefix, create a directory for the menu and a > configuration file that enables this menu in the freedesktop.org menu > structure. As suggested on wine-devel the menu directory is a > subdirectory of ~/.wine, so if the user deletes it, all menu items > created there will be automatically removed. > +<Name>Applications</Name> > + <Menu> > + <Name>Wine</Name> > + <LegacyDir>__HOME__/.wine/menu</LegacyDir> > + </Menu> > +</Menu> Why are you hard-coding this path to being .wine? You correctly used $WINEPREFIX before. Also that means that you should add files that are WINEPREFIX related. Or you will keep overwriting the other ones. Vitaliy Margolen

2 1

riched20: Send EN_LINK notifications. Properly underline / color links.
by renu.rajput＠tcs.com Aug. 17, 2006

Aug. 17, 2006

The patch at http://www.winehq.org/pipermail/wine-patches/2006-August/029855.html needs to be corrected a bit: In file editor.c, there is a change as follows > case WM_MOUSEMOVE: > if (GetCapture() == hWnd) > ME_MouseMove(editor, (short)LOWORD(lParam), (short)HIWORD(lParam)); > break; > + ME_LinkNotify(editor,msg,wParam,lParam); > Here, the function ME_LinkNotify is called after the break. So it would not get executed. Thanks! =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

1 0

Re: X11Drv/OpenGL pixelformat rewrite
by Tomas Carnecky Aug. 17, 2006

Aug. 17, 2006

Testing with World of Warcraft, the game runs fine, but I see this in the console: err:wgl:wglGetPixelFormatAttribivARB Unable to convert iPixelFormat 0 to a GLX one, expect problems! tom

2 1

[UPDATE 4] RFC: XEmbed System Tray Patch
by James Liggett Aug. 16, 2006

Aug. 16, 2006

Attached is the fourth update to my XEmbed system tray patches. For this version I made some fairly major changes: 1. Did away with the low-level checks for systrays, and instead had the systray icon windows created off-screen so they aren't mapped, as per Alexandre's suggestion. 2. systray_dock_window will put the icon windows back on the screen if there isn't an XEmbed tray to dock with. 3. Eliminated the WS_EX_TRAYWINDOW style hack, and moved the call to systray_dock_window to X11DRV_CreateWindow. I used the window class name to see if it was a tray window being created or not. 4. Consolidated all patches into one, as the individual patches weren't really individual changes. (Thanks to Mike McCormack for this advice.) As usual, comments/suggestions appreciated. Thanks again, James Liggett

2 1

[Fwd: Wine 0.9.19 upgrade problem]
by Scott Ritchie Aug. 16, 2006

Aug. 16, 2006

1 0

Last call for hotel and mailing list sign up
by Jeremy White Aug. 16, 2006

Aug. 16, 2006

Hi Folks, I got a brief repreive from the U of Reading, so I'm sending them the final counts tomorrow morning, so this is your last chance to request a room. Also, I'd like to start a thread on proposed meeting topics, so I'd like to ask everyone that's coming to make sure that they're subscribed to the wineconf mailing list so they can follow along. (And give those that don't want to be on it any longer to unsubscribe). Cheers, Jeremy

1 0

wined3d: direct3d.c variable-names request
by Andrew Talbot Aug. 16, 2006

Aug. 16, 2006

This request is aimed at the wined3d specialists. Hi, I'm looking to fix a couple of write-strings warnings in direct3d.c: lines 323 and 334, the second parameter to Callback(), but I don't know enough to give suitable names to the intended substitute variables. So I would be glad of suggestions, please. Thanks, -- Andy.

2 4

Re: widl [1/4]: Fix NdrConformantArrayUnmarshall calls in generated code
by Robert Shearman Aug. 16, 2006

Aug. 16, 2006

Dan Hipschman wrote: >This series of four patches allow gcc to compile the proxy file that widl >generates for oaidl.idl. This first patch fixes the number and types of >arguments widl generates for NdrConformantArrayUnmarshall calls. > >ChangeLog: >* Generate the correct args for NdrConformantArrayUnmarshall in proxy code > > Hi Dan, It might be better to reuse the code in typegen.c rather than maintaining two different pieces of code that essentially do the same job. -- Rob Shearman

2 2

Re: [RESEND] user: Select entire text if DLGC_HASSETSEL set
by Alexandre Julliard Aug. 16, 2006

Aug. 16, 2006

Stefan Siebert <stefan.siebert(a)web.de> writes: > +static void DIALOG_SelectTextIfHasSetSel( HWND hwndEdit ) > +{ > + MSG msg; > + LRESULT dlgCode; > + > + dlgCode = SendMessageW (hwndEdit, WM_GETDLGCODE, msg.wParam, (LPARAM)&msg); msg is not initialized, you are sending garbage to the app. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winecfg: appdefaults: use more strings from resources, unicode
by Paul Vriens Aug. 16, 2006

Aug. 16, 2006

On Wed, 2006-08-16 at 06:23 +0200, Frank Richter wrote: > +#define IDS_DEFAULT_SETTINGS 8017 > +#define IDS_EXECUTABLE_FILTER 8018 > +#define IDS_USE_GLOBAL_SETTINGS 8019 > +#define IDS_SELECT_EXECUTABLE 8020 Hi Frank, the patch is applied but the strings are not defined in the .rc files. Looks a bit strange now when starting winecfg. Cheers, Paul.

1 0

Benchmarking Wine
by Tom Wickline Aug. 16, 2006

Aug. 16, 2006

Hello, I'm planning to update the benchmarks on the wiki with version 9.20 when it's released and thought I would ask in advance if anyone here has any ideas about the benchmarks. The three new benchmarks that I plan to add are 3DMark03, 3DMark05?? and 3DMark06 Anyone here interested in ShaderMark or AquaMark? or any other bench for that matter. Also Ive made a small update to : http://wiki.winehq.org/BenchMark-0%2e9%2e6 The test were not run under optimal conditions, other apps open, not from a clean boot, run in a window, and with debugging on... So the scores should improve :) Cheers, Tom

5 11

Re: advapi32: add GetComputerObjectName tests (revised)
by Paul Vriens Aug. 16, 2006

Aug. 16, 2006

On Wed, 2006-08-16 at 07:28 -0400, Robert Reif wrote: > Revision based on feedback from Paul Vriens. Hi Robert, your patch was already applied. Could you diff it against current? Cheers, Paul.

1 0

Re: regedit: Write-strings warnings fix and remove superfluous casts (Resend)
by Alexandre Julliard Aug. 16, 2006

Aug. 16, 2006

Andrew Talbot <Andrew.Talbot(a)talbotville.com> writes: > Please tell me what is wrong with this patch. Thank you. It's causing warnings: gcc -c -I. -I. -I../../include -I../../include -I../../include/msvcrt -DNO_LIBWINE_PORT -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -fno-builtin -o childwnd.o childwnd.c childwnd.c: In function 'GetItemFullPath': childwnd.c:135: warning: passing argument 1 of 'CombinePaths' from incompatible pointer type childwnd.c: In function 'GetPathFullPath': childwnd.c:144: warning: passing argument 1 of 'CombinePaths' from incompatible pointer type -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winecfg: Use WCHARs for window title
by Alexandre Julliard Aug. 16, 2006

Aug. 16, 2006

Frank Richter <frank.richter(a)gmail.com> writes: > From 8aaa9ca3552c7e3662c58671c9bc789b1492aa32 Mon Sep 17 00:00:00 2001 > From: Frank Richter frank.richter(a)gmail.com <frank.richter(a)gmail.com> > Date: Wed, 16 Aug 2006 05:44:29 +0200 > Subject: [PATCH] winecfg: Use WCHARs for window title You should switch the app name to Unicode too, this way you wouldn't need to change all the format strings. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/5] kernel: add VirtualAllocEx remote thread conformance tests (updated)
by Alexandre Julliard Aug. 16, 2006

Aug. 16, 2006

tkho(a)ucla.edu (Thomas Kho) writes: > diff --git a/dlls/kernel/tests/Makefile.in b/dlls/kernel/tests/Makefile.in > index bfeae14..5f6c12e 100644 > --- a/dlls/kernel/tests/Makefile.in > +++ b/dlls/kernel/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = kernel32.dll > -IMPORTS = kernel32 > +IMPORTS = kernel32 user32 It would be cleaner to avoid importing user32 in the kernel tests. What you probably should do is have the test create more instances of itself the way the process test does. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32: add GetComputerObjectName tests (resend)
by Paul Vriens Aug. 16, 2006

Aug. 16, 2006

On Tue, 2006-08-15 at 19:01 -0400, Robert Reif wrote: > plain text document attachment (secur32.tests.diff.txt) > diff -puN wine.cvs/dlls/secur32/tests/Makefile.in wine/dlls/secur32/tests/Makefile.in > + rc = GetComputerObjectNameW(formats[i], nameW, &size); > + ok(rc || ((formats[i] == NameUnknown) && > + (GetLastError() == ERROR_INVALID_PARAMETER)) || > + (GetLastError() == ERROR_CANT_ACCESS_DOMAIN_INFO), > + "GetComputerObjectNameW(%d) failed: %ld\n", > + formats[i], GetLastError()); > + } > +} > + > +START_TEST(secur32) > +{ > + testGetComputerObjectName(); > +} Hi Robert, you must likely have to change the tests to check: a) if secur32 is available (NT4 seems to lack this one) b) W-calls are (sometimes) not present on non-unicode versions of windows. http://test.winehq.org/data/200608151000/ already shows errors with secur32 and NT4 (I get a pop-up that it can't find secur32.dll). Cheers, Paul.

1 0

RFC: XEmbed Systray Patches
by James Liggett Aug. 16, 2006

Aug. 16, 2006

Hello everyone, After a long hiatus, I'm trying again to get XEmbed systray support into Wine. I've been working on it for the past few days and I've got these patches. These are based on the system tray code from the Wine version used in the Linux port of Picasa [1] (which in turn was based on the work of Mike Hearn and Rob Shearman.) These patches are basically the same thing, with some fixes: 1. Use proper wine_tsx11 locking. 2. Clean up inappropriate C++ comments in that code. 3. Properly populated the XEvent structure to send docking messages. (According to the XEmbed systray spec [2], any unused fields in the message must be set to 0.) 4. Broken into five atomic patches against today's GIT. In my testing on Gnome 2.14, these patches dock much more reliabaly than the last ones, but they're still not quite perfect. In most cases, programs dock fine until about the seventh consecutive run (behavior observed with Steam and a small test program I wrote.) However, I noticed that it works perfectly if I enabled a +x11drv trace, so I suspect that this has something to do with stack problems, but I've been unable to find the source of the problem. I'd appreciate it if someone could give me some assistance on tracking down this issue. If you'd like to test these, please apply them in the order that they're numbered. Any comments/suggestions appreciated. Thnaks, James Liggett [1]: http://code.google.com/wine.html [2]: http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html#m…

2 13

Re: oleaut32: Added insufficient memory check to ITypelib2:GetDocumentation2
by Dan Kegel Aug. 15, 2006

Aug. 15, 2006

2006/8/15, Benjamin Arai <me(a)benjaminarai.com>: > ChangeLog: > - Added insufficient memory check to ITypelib2::GetDocumentation2 > - Returns MSDN specified value STG_E_INSUFFICIENTMEMORY Have you *ever* seen this run out of memory in real life? - Dan

1 0

Re: oleaut32: Added insufficient memory check to ITypelib2:GetDocumentation2
by Frank Richter Aug. 15, 2006

Aug. 15, 2006

On 16.08.2006 04:23, Benjamin Arai wrote: > if(pbstrHelpString) > + { > *pbstrHelpString=SysAllocString(This->DocString); > + if(!*pbstrHelpString) > + return STG_E_INSUFFICIENTMEMORY; > + } > if(pdwHelpStringContext) > *pdwHelpStringContext=This->dwHelpContext; > if(pbstrHelpStringDll) > + { > *pbstrHelpStringDll=SysAllocString(This->HelpStringDll); > + if(!pbstrHelpStringDll) > + return STG_E_INSUFFICIENTMEMORY; > + } Hm, shouldn't pbstrHelpString be freed in case the 2nd allocation fails? -f.r.

1 0

Re: kernel32: add GetNativeSystemInfo (Try 2)
by Dan Kegel Aug. 15, 2006

Aug. 15, 2006

This patch is good, and helps fix MS Photostory 2 LE's installer ( http://bugs.winehq.org/show_bug.cgi?id=5966 ). Robert, you might need to repost, though; there was a wrapped line.

1 0

[meta-bug] I can not contact Jeremy Newman
by Jérôme Bouat Aug. 15, 2006

Aug. 15, 2006

Hello, I can not reach Jeremy Newman. I hope he goes well. A very important bug still exist for years but its bugzilla issue gets no response at all : http://bugs.winehq.org/show_bug.cgi?id=5202 Please, say something (i.e. WONTFIX, INVALID, LATER, ...). I hope someone will respond. Thanks.

4 4

Re: user: Pass all required information with internal message when chaining hooks
by Alexandre Julliard Aug. 15, 2006

Aug. 15, 2006

Vitaliy Margolen <wine-patch(a)kievinfo.com> writes: > This patch deals with two sides of this problem. And actually saves > some time by not calling server one extra time. I don't think that's a good thing, now you risk calling a hook that has been deleted already. You really want to fetch the hook info from the destination thread. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: usp10: Resend - Remove unnecessary casts in test suite
by Alexandre Julliard Aug. 15, 2006

Aug. 15, 2006

Jeff L <lats(a)yless4u.com.au> writes: > Any problems? It doesn't apply. When resending a patch please regenerate it against the current tip. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Alexandre Julliard Aug. 15, 2006

Aug. 15, 2006

Jeff L <lats(a)yless4u.com.au> writes: > + cMaxItems = 255; /* Pick an abritary size for buffers */ > + if (!*pssa) /* Clean it out and start again */ > + ScriptStringFree(pssa); I still don't see why you want to free a NULL pointer. > + { > + prtssa(*pssa); > + analysis = * pssa; > + prtssa((SCRIPT_STRING_ANALYSIS *)analysis); Why do you print the same object twice? There seems to be a lot of confusion in your code between pointers and pointers to pointers, I think you need to define better data types to clarify this. -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: XEmbed Systray Patches
by James Liggett Aug. 15, 2006

Aug. 15, 2006

Hi Everyone, First, I'd like to apologize for sending those tarballs to wine-devel, as I've just been advised on IRC that such a practice discourages reviews. I've attached a text version of the patches in the hopes that it will get some more exposure. Again, sorry for the trouble. :) James

2 1

All right, let's solve these .desktop issues forever
by Scott Ritchie Aug. 14, 2006

Aug. 14, 2006

As of right now, I'd estimate that over half of our users are using Wine from a terminal window to launch their applications, largely because their window manager doesn't put Wine's Start Menu entries into their applications menu. Wine's been making .desktop files for some time, however it seems like they're being put in the wrong place. There's supposedly a proper, standard place to put them (or there should be), and perhaps a hack can be put in at the package-maintainer level, but in any case this is a pretty big usability issue at the moment. I'm pretty confident that someone here knows the answer to how things should be, and I'm also pretty sure it's a fairly simple change to make. Either way, we need to have a discussion about it - what's the next step here? Thanks, Scott Ritchie

7 8

Re: USER: SystemParametersInfo fixes
by Alexandre Julliard Aug. 14, 2006

Aug. 14, 2006

Frank Richter <frank.richter(a)gmail.com> writes: > Subject: [PATCH] USER: Fix SPI_SETICONTITLELOGFONT to check for LOGFONTW size > [...] > Subject: [PATCH] USER: initialize size of nonclients struct in load_nonclient_metrics Please don't attach multiple patches, each patch should be a separate mail. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WineD3D: add rgb24 colorkey conversion
by Alexandre Julliard Aug. 14, 2006

Aug. 14, 2006

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > + for (x = 0; x < len; x++) { > + /* Retrieve RGB24 color */ > + DWORD color = *((DWORD*)src); > + /* Store the RGB portion in dest and reserve a byte for alpha */ > + *Dest = color << 8; > + if ((color < surf->SrcBltCKey.dwColorSpaceLowValue) || > + (color > surf->SrcBltCKey.dwColorSpaceHighValue)) > + *Dest |= 0xff; > + src += 3; You should avoid unaligned DWORD accesses, this doesn't work on all platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

RFC: OpenGL x11drv rewrite (WoW fix)
by Roderick Colenbrander Aug. 14, 2006

Aug. 14, 2006

Hi, Since the WM rewrite we can only use the visual which was created by x11drv at x11drv initialization. In general this is a simple 32bit RGBA visual or when that's not available it is some 16bit visual. The problem is that the opengl code advertises more formats than this single format. The problem which this can cause is that a 'bad' format is set by SetPixelFormat. In the end when we create a context using wglCreateContext this 'bad' pixelformat is used. When some time later glXMakeCurrent is called we will get a BadMatch. (Note that in a few cases we catch the 'BadMatch' before it happens and create a new GLX Context; this is when context is NULL) The proposed patch which I attached to this email rewrites the pixel format code. First I'll give a short introduction and then I will explain my changes. The functions ChoosePixelFormat/GetPixelFormat/SetPixelFormat/DescribePixelFormat all work with a parameter 'iPixelFormat'. This variable is an index into the table of supported pixel formats. At the moment the index is a direct mapping to the FB config table exported by GLX. I have changed ChoosePixelFormat to only return the format of the main visual. Further this function needs to find a 'closest match' to the requested format, before it tried to find an exact match. I changed the function to look for a close match. Further because only 1 format is supported, the max index the function can return is 1. This kills the direct mapping of the index to the index in the GLX FB config table. All the opengl calls in x11drv got changed to only accept our single format. As I mentioned earlier the opengl calls used the specified iPixelFormat as an index in the GLX FB config table. Because the 1:1 mapping of iPixelFormat to this table got lost I have added a function to retrieve the index of the main visual. Further I had to change our wglMakeCurrent call to retrieve the pixel format to use from the main visual instead of getting it from a GetPixelFormat call. This was done because wglMakeCurrent needs an index into the GLX FB Config table and not in our 'win32 opengl format table' (which only contains 1 format). I have tested the patch in several programs. Before Halflife1 didn't work in 16bit because ChoosePixelFormat was too strict, the game works fine now. Further the patch also fixes the BadMatch error Nvidia users received in World Of Warcraft when using the OpenGL renderer. I think the patch is a correct fix for the BadMatch / ChoosePixelFormat issues. The patch isn't 100% complete yet as I haven't updated the WGL extensions for pbuffer and wglChoosePixelFormat to work with the new pixelformats yet (that's why you see a line WoW hack). I will fix that part when you guys think that the patch is correct. Regards, Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

2 1

Is anyone going to or presenting at Linuxworld?
by Scott Ritchie Aug. 14, 2006

Aug. 14, 2006

Linuxworldexpo is this week. Since no one's mentioned it yet, I'm assuming that we don't have a booth or speech planned :) http://www.linuxworldexpo.com/live/12/events/12SFO06A At any rate, perhaps we should be going to things like this. There's usually a convention like this (OSCON, etc) every couple of months, and it certainly couldn't hurt to have a Wine evangelist there talking about how powerful Wine is getting and why Wine should be considered as a bigger part of the Linux strategy. What do you think? Thanks, Scott Ritchie

2 1

Re: resend add missing glyph code to GetGlyphIndices
by Dmitry Timoshkov Aug. 14, 2006

Aug. 14, 2006

"Jeff L" <lats(a)yless4u.com.au> wrote: > -DWORD WineEngGetGlyphIndices(GdiFont font, LPCWSTR lpstr, INT count, > + * */ Strange indentation at the end of a comment. > +DWORD WineEngGetGlyphIndices(HDC hdc, GdiFont font, LPCWSTR lpstr, INT count, > LPWORD pgi, DWORD flags) > { > INT i; > - > + TEXTMETRICW textm; > for(i = 0; i < count; i++) > + { > pgi[i] = get_glyph_index(font, lpstr[i]); > - > + if (pgi[i] == 0) > + { > + if (flags & GGI_MARK_NONEXISTING_GLYPHS) > + pgi[i] = 0x001f; /* Indicate non existance */ > + else > + { > + GetTextMetricsW(hdc, &textm); > + pgi[i] = textm.tmDefaultChar; > + } > + } > + } > return count; > } I'd suggest to move GetTextMetricsW outside of the loop to not kill the performance. > + WCHAR testtext[] = {'T',0x0000,'s','t',0xffff,0}; > + WORD glyphs[(sizeof(testtext)/2)-1]; > + TEXTMETRIC textm; > + > + memset(&lf, 0, sizeof(lf)); > + strcpy(lf.lfFaceName, "Symbol"); > + lf.lfHeight = 20; > + > + hfont = CreateFontIndirectA(&lf); > + hdc = GetDC(0); > + > + ok(GetTextMetrics(hdc, &textm), "GetTextMetric failed\n"); Please set tab width to 8 instead of 4 and do not mix tabs and spaces. -- Dmitry.

3 3

Re: secur32: Fix heap error.
by Kai Blin Aug. 14, 2006

Aug. 14, 2006

On Monday 14 August 2006 11:57, Kai Blin wrote: > --- > dlls/secur32/dispatcher.c | 1 - > dlls/secur32/ntlm.c | 1 + > 2 files changed, 1 insertions(+), 1 deletions(-) Sorry, this one is obviously a typo. Sending a new one. Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: secur32: Make AcceptSecurityContext behaviour consistent withWindows.
by Dmitry Timoshkov Aug. 14, 2006

Aug. 14, 2006

"Kai Blin" <kai.blin(a)gmail.com> wrote: > phNewContext->dwUpper = ctxt_attr; > - phNewContext->dwLower = ret; > + phNewContext->dwLower = (DWORD)helper; You need to cast to ULONG_PTR to make the code 64-bit safe. Also please fix (DWORD)helper casts in other places. -- Dmitry.

2 1

Re: secur32: Clean up AcceptSecurityContext (reduce indent and duplication).
by Kai Blin Aug. 14, 2006

Aug. 14, 2006

On Sunday 13 August 2006 14:44, Kai Blin wrote: > --- > dlls/secur32/ntlm.c | 372 > ++++++++++++++++++++++----------------------------- > 1 files changed, 164 insertions(+), 208 deletions(-) After sending in the fixes for my "Make AcceptSecurityContext behaviour consistent with Windows, try2" patch, this one won't apply anymore. I'll resend it later today. Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: gdi: Implement GetFontUnicodeRanges.
by Huw Davies Aug. 14, 2006

Aug. 14, 2006

On Sun, Aug 13, 2006 at 08:26:24PM +0200, Hans Leidekker wrote: > > Any word on this patch? > > -Hans > > Changelog > Implement GetFontUnicodeRanges on top of fontconfig and freetype. I wonder whether FcFreeTypeCharSet is what you really want here. It uses a lot of heuristics which almost certainly won't match what Windows does, so we're probably better off writing our own. A test (on say Arial) would be useful here. Also note that even if you do use the Fc* functions you'll need to check that the pFc* ptrs are non-NULL before calling them. Huw.

2 1

[UPDATE 3] RFC: XEmbed System Tray Patches
by James Liggett Aug. 13, 2006

Aug. 13, 2006

Attached is the third update to the xembed systray patches. For this version I've simplified the if statements for checking if we should map tray icon windows or not (As per Scott Ritchie's advice--Thanks again Scott.) As always, further comments/suggestions appreciated. Thanks, James Liggett

1 0

[UPDATE 2] RFC: XEmbed System Tray Patches
by James Liggett Aug. 13, 2006

Aug. 13, 2006

Attached is the second update of the XEmbed systray patches. Changes in this version: 1. On the advice of Juan Lang, I only acquire the wine tsx11 lock when actually making X calls, and not while initializing data. 2. Added the ability to detect if we have an XEmbed systray so that we can selectively determine if we need to map tray windows or not. Under the last version, the icons would not be mapped under any circumstances whatsoever. While it would work if we had an XEmbed-compliant tray to dock with, the icon wouldn't show up at all if there wasn't one. Things work both ways now. But, if you look at the patches, you'll notice that the logic in the if statements is a little ugly. Is there a cleaner way to do this? Thanks, James Liggett

2 3

Re: secur32: make GetComputerObjectNameA use GetComputerObjectNameW (revised)
by Chris Robinson Aug. 13, 2006

Aug. 13, 2006

On Sunday 13 August 2006 06:45, Robert Reif wrote: > This patch also adds a partial implementation of GetComputerObjectNameW. The GetComputerObjectNameA function appears to be broken. When GetComputerObjectNameW fails due to too little memory in the name buffer, it sets the buffer size as specified by MSDN. However, when GetComputerObjectNameA calls GetComputerObjectNameW and receives an error code, this isn't copied into its nSize parameter.

2 1

Re: reasons for not accepting the patch
by Dan Kegel Aug. 12, 2006

Aug. 12, 2006

2006/8/12, Vijay Kiran Kamuju <infyquest(a)gmail.com>: > [Why wasn't the patch > http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html > accepted?] I looked at this a couple days ago, and sent this to the patches' author to encourage him to repost it: -- snip --- 1. The patch is missing the filename header, and cannot be applied to the sources by running 'patch'. 2. the patch was posted with the following legal notice: "Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited." That tells us "You may not use this patch." You have to post patches without that. 3. the message did not contain any license information (e.g. Author: Renu Rajput (Tata Inc.) Copyright 2006 Tata Inc License: LGPL. Adding that would help. 4. The message essentially repeated much of the bug report in bugzilla. That's not needed. Just refer to the bug report. Any one of the above four might have been enough to cause the patch to be ignored. Fix them all and you've got a good shot. Two more tips: 5. The bug report in bugzilla does not link to your proposed fix. Often after I post a proposed fix, I add a comment to bugzilla saying something like "Patch sent: http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html" Not only does this give another way for people to stumble across and review your patch, it also helps avoid duplication of effort. I had no idea you had sent in a patch for this bug already! 6. Patches that do not get applied need to be resent after a few days. Every time you resend it, you should try to improve it or the test case a bit, and make sure it still applies against current cvs or git. Use the same subject line as before, but append "(resend)" to the end. Patches are like TCP/IP. There is no ACK when a packet is corrupt, you have to resend after correcting a bit error! --- snip --- Hope that helps. - Dan

2 1

Re: winmm: prevent NULL dereference in MCI_Close
by Eric Pouech Aug. 12, 2006

Aug. 12, 2006

Jan Zerebecki wrote: >If this patch is rejected from inclusion, please tell me why, as >I would have to ask anyway. > >From: Jan Zerebecki <jan.wine(a)zerebecki.de> > > > Jan, do you have a specific program that depends on this case ?

2 1

Missing subtitle in WWN 307
by Francois Gouget Aug. 12, 2006

Aug. 12, 2006

Hi, It's not a big issue but I have noticed that in WWN 311 the article about 'Microsoft WGA & Wine' does not have a subject: http://www.winehq.org/?issue=311#Microsoft%20WGA%20&%20Wine Currently it reads: +----------------------------------------+---------+ |Microsoft WGA & Wine | Archive | +----------------------------------------+---------+ That is it is missing the 'subtitle' underneath the gray bar. So it should look something like this: +----------------------------------------+---------+ |Microsoft WGA & Wine | Archive | +----------------------------------------+---------+ WINE & Microsoft WGA Is this an XML parsing bug? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

1 0

Wide-string Functions: Double Casting
by Andrew Talbot Aug. 12, 2006

Aug. 12, 2006

Although I accept that my opinion may not be universally shared :-), I believe that it is better to turn -Wcast-qual on permanently and double-cast the appropriate return values of the relevant wide-string functions (strchrW(), strrchrW(), strpbrkW(), memchrW() and memrchrW()) than to leave it normally turned off: that way, the developers can avoid violations as they go, and give the janitors a break ;-). These functions are ubiquitous and widely understood, and they account for the vast majority of cast-qual warnings. Because, as I understand it, we are aiming for C89 compatibility, and to try to maximise portability, I am proposing to use size_t, rather than uintptr_t (which is a C99 type): it seems like the next-best thing. So I would like to submit a patch that, for example, changes strchrW() to: extern inline WCHAR *strrchrW( const WCHAR *str, WCHAR ch ) { WCHAR *ret = NULL; do { if (*str == ch) ret = (WCHAR *)(size_t)str; } while (*str++); return ret; } What do people think? Should I just send in the patch and see what criticism it engenders? Does anyone have a system on which this would fail or generate other warnings in place of the cast-qual one? Needless to say, I hope to be tackling the cast-qual janitorial task, soon; hence, my sudden interest in this. Thanks, -- Andy.

4 9

Re: ddraw fix for incorrect return value from wined3d take 3.
by Roderick Colenbrander Aug. 12, 2006

Aug. 12, 2006

Hi, One small comment regarding your patch make sure that you use the same indentation as the rest of the ddraw code. The ddraw code seems to use 4 spaces for a tab and I think your editor is configured to use tabs. Regards, Roderick Colenbrander > The new test cases crashes under wine but not under > windows. The fix for test cases crash is to initialize > the vertexbuffer to NULL when unsuccessful. > > This patch should be used rather then previous one. > > thx > Index: dlls/ddraw/direct3d.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/direct3d.c,v retrieving revision 1.9 diff -u -r1.9 direct3d.c --- dlls/ddraw/direct3d.c 9 Aug 2006 11:04:37 -0000 1.9 +++ dlls/ddraw/direct3d.c 11 Aug 2006 22:47:16 -0000 @@ -992,8 +992,11 @@ { ERR("(%p) IWineD3DDevice::CreateVertexBuffer failed with hr=%08lx\n", This, hr); HeapFree(GetProcessHeap(), 0, object); + *VertexBuffer = NULL; if (hr == WINED3DERR_INVALIDCALL) return DDERR_INVALIDPARAMS; + if (hr == WINED3DERR_OUTOFVIDEOMEMORY) + return D3DERR_TOOMANYVERTICES; else return hr; } -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: wininet: Support http_proxy environment variable
by Augusto Arcoverde da Rocha Aug. 11, 2006

Aug. 11, 2006

Exists a opened bug report about the problem which this patch is suposed to fix: http://bugs.winehq.org/show_bug.cgi?id=5625 Can someone give some comments for what this pach wasn't applied? Thanks, Augusto Arcoverde da Rocha

5 10

Re: [UPDATE] RFC: XEmbed System Tray Patches
by Juan Lang Aug. 11, 2006

Aug. 11, 2006

Hi James, thanks for taking this up. I'd like to have nice docked system tray icons, too. Some small nits on your patches: + wine_tsx11_lock(); + /* set XEMBED protocol data on the window */ + info[0] = 0; /* protocol version */ + info[1] = 1; /* mapped = true */ + XChangeProperty( display, data->whole_window, + x11drv_atom(_XEMBED_INFO), + x11drv_atom(_XEMBED_INFO), 32, PropModeReplace, + (unsigned char*)info, 2); + + /* send the docking request message */ + ZeroMemory( &ev, sizeof(ev) ); + ev.xclient.type = ClientMessage; + ev.xclient.window = systray_window; + ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); + ev.xclient.format = 32; + ev.xclient.data.l[0] = CurrentTime; + ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; + ev.xclient.data.l[2] = data->whole_window; + ev.xclient.data.l[3] = 0; + ev.xclient.data.l[4] = 0; + XSendEvent( display, systray_window, False, NoEventMask, &ev ); + wine_tsx11_unlock(); You do more with the lock held than you need to. Initializing info and ev could both be down without holding the lock. diff --git a/include/wine/server_protocol.h b/include/wine/server_protocol.h index b8c8a7c..3b4bd08 100644 --- a/include/wine/server_protocol.h +++ b/include/wine/server_protocol.h @@ -2741,6 +2741,7 @@ struct set_window_pos_reply { struct reply_header __header; unsigned int new_style; + unsigned int ex_style; }; This diff should be against server/protocol.def, not against server_protocol.h. diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c index b26e14f..69c32ef 100644 --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -400,6 +400,13 @@ static void systray_dock_window( Display ev.xclient.data.l[3] = 0; ev.xclient.data.l[4] = 0; XSendEvent( display, systray_window, False, NoEventMask, &ev ); + + /* This XSync call is needed to properly send the message to the + * systray window and is required to have icon docking work properly. + * Furthermore, an XSync is shown in an example of how to send proper + * docking messages, see the XEmbed system tray spec for more + * information. */ + XSync(display, False); Why not include this in the original patch (0005 in the series?) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Wine and Photoshop in news
by Vijay Kiran Kamuju Aug. 11, 2006

Aug. 11, 2006

Check this link out Its about Wine and Photoshop compatibility. http://www.manilastandardtoday.com/?page=business05_aug01_2006 Can we also try to improve the photoshop compatibility with wine. Today will download the demo and try it on wine current git.

4 5

Re: [wintrust.h] Added some missing struct variables
by Paul Vriens Aug. 11, 2006

Aug. 11, 2006

On Fri, 2006-08-11 at 16:40 +0200, Paul Vriens wrote: > Hi, > > our struct was missing some variables. > > Changelog > Added some missing struct variables > > Cheers, > > Paul > --- > include/wintrust.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/wintrust.h b/include/wintrust.h > index d490ac9..0230dee 100644 > --- a/include/wintrust.h > +++ b/include/wintrust.h > @@ -254,6 +254,8 @@ typedef struct _CRYPT_PROVIDER_DATA { > HCRYPTMSG hMsg; > DWORD csSigners; > CRYPT_PROVIDER_SGNR *pasSigners; > + DWORD csProvPrivData; > + CRYPT_PROVIDER_PRIVDATA *pasProvPrivData; > DWORD dwSubjectChoice; > union { > struct _PROVDATA_SIP *pPDSip; Hi, please wait with this one. There appears to be some differences in the structure for w2k/winxp (and others?). Cheers, Paul.

1 0

Re: kernel32: redirect GetNativeSystemInfo to GetSystemInfo
by Alexandre Julliard Aug. 11, 2006

Aug. 11, 2006

Robert Reif <reif(a)earthlink.net> writes: > --- dlls/kernel/kernel32.spec 21 Jun 2006 13:03:23 -0000 1.175 > +++ dlls/kernel/kernel32.spec 11 Aug 2006 01:51:02 -0000 > @@ -546,7 +546,7 @@ > @ stdcall GetNamedPipeHandleStateA(long ptr ptr ptr ptr str long) > @ stdcall GetNamedPipeHandleStateW(long ptr ptr ptr ptr wstr long) > @ stdcall GetNamedPipeInfo(long ptr ptr ptr ptr) > -# @ stub GetNativeSystemInfo > +@ stdcall GetNativeSystemInfo(ptr) GetSystemInfo There's a bit more to it than that, so we probably want to print a FIXME for this one. -- Alexandre Julliard julliard(a)winehq.org

1 0

[wintrust.h] Added some missing struct variables
by Paul Vriens Aug. 11, 2006

Aug. 11, 2006

Hi, our struct was missing some variables. Changelog Added some missing struct variables Cheers, Paul --- include/wintrust.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/wintrust.h b/include/wintrust.h index d490ac9..0230dee 100644 --- a/include/wintrust.h +++ b/include/wintrust.h @@ -254,6 +254,8 @@ typedef struct _CRYPT_PROVIDER_DATA { HCRYPTMSG hMsg; DWORD csSigners; CRYPT_PROVIDER_SGNR *pasSigners; + DWORD csProvPrivData; + CRYPT_PROVIDER_PRIVDATA *pasProvPrivData; DWORD dwSubjectChoice; union { struct _PROVDATA_SIP *pPDSip; -- 1.4.1.1

1 0

Re: winhelp: fix LZ77 decompressor patch: what's wrong?
by HolyLich Aug. 11, 2006

Aug. 11, 2006

В сообщении от Friday 11 August 2006 17:17 вы написали: > 2006/8/11, HolyLich <lich(a)math.spbu.ru>: > > I've sent patch several times, but it has not been applied. > > Why not use memmove() instead? > Heh, this problem was discussed before http://www.winehq.org/pipermail/wine-devel/2006-August/050133.html, http://www.winehq.org/pipermail/wine-devel/2006-August/050139.html http://www.winehq.org/pipermail/wine-devel/2006-August/050141.html. memmove cannot be used because it provides other functionality - it doesn't suit LZ77 memcpy cannot be used because it's too clever (copies INTs instead of BYTEs), so doesn't suit LZ77 Solution: while (len--) *dst++=*src++; // The simplies way of memcpy Any more suggestion of bad patch? --HolyLich

2 1

winhelp: fix LZ77 decompressor patch: what's wrong?
by HolyLich Aug. 11, 2006

Aug. 11, 2006

Hi, I've sent patch several times, but it has not been applied. Patch is reasonable, MIME type is OK. patch -p0 < mbox works ;-) (as recommended at http://winehq.org/site/docs/winedev-guide/style-notes) Please, tell what I must do to this patch to be applied? Thanks a lot -- HolyLich Subject: [RESENDv2] winhelp: fix LZ77 decompressor Date: Thursday 10 August 2006 14:21 From: HolyLich <lich(a)math.spbu.ru> To: wine-patches(a)winehq.org Hi, This patch fixes a bug in LZ77 decompressor which affected only large (>0x1000) compressed embedded files, e.g. images (metafiles). I've never noticed it corrupting small images, but it may. I sent this patch before but messed with MIME. Now it's OK. ChangeLog: winhelp: Fix LZ77 decompressor -------------------------------------------------------

3 2

Rooms for Wineconf - Please act now
by Jeremy White Aug. 11, 2006

Aug. 11, 2006

Hi Folks, I know that Wineconf is still over a month away, but you'll really regret it if you don't make your accomodation selections now. If you paypal (or even arrange to mail a check) to me *now*, you'll get to hang out with all the cool people, on campus, and learn what the "Drink-making facilities on each corridor" really means, all for the low low price of about 40 pounds (okay, so the exchange rate sucks, and that's $75 US, but still...) If you *don't* get me an room request in the next few days, then I'll have to close down our room reservation, and you'll be stuck in some sleazy motel on the edge of town paying outrageous sums of of money. (Okay, they actually all look like nice places to stay, but they will be a ways away, and they all cost more :-/). Again, see this page for more details: http://www.winehq.org/site/wineconf/travel If you can't do Paypal, I can take a check in US currency as well. Cheers, Jeremy

6 9

Re: wldap32: Write-strings warning fix
by Hans Leidekker Aug. 11, 2006

Aug. 11, 2006

On Friday 11 August 2006 00:58, Andrew Talbot wrote: > -INT CDECL ber_printf(BerElement*,PCHAR,...); > +INT CDECL ber_printf(BerElement*,LPCSTR,...); This is an API defined by Microsoft, we can't change its prototype. -Hans

2 1

patch feedback?
by Damjan Jovanovic Aug. 11, 2006

Aug. 11, 2006

Hi I've tried submitting a patch to wine-patches 3 times now in the past 3 weeks, and not only has it not been applied, but I never even got any feedback. Please tell me what I am doing wrong. The latest patch is below. Thank you Damjan --- Damjan Jovanovic <dj015(a)yahoo.com> wrote: > Date: Thu, 3 Aug 2006 23:49:11 -0700 (PDT) > From: Damjan Jovanovic <dj015(a)yahoo.com> > To: wine-patches(a)winehq.org > Subject: setupapi: test+patch for > SetupDiOpenClassRegKeyExW (try 3) > > wine's SetupDiOpenClassRegKeyExW returns FALSE > instead > of INVALID_HANDLE_VALUE in several places, and > doesn't > brace the GUID string like it should. The test > reveals > these problems, and the patch fixes them. > > ChangeLog: > * Fixed returns values, braced GUID string, and > added > a test, for SetupDiOpenClassRegKeyExW. > > Damjan Jovanovic (dj015(a)yahoo.com) > > > a/dlls/setupapi/tests/Makefile.in 2006-07-10 > 18:01:08.000000000 +0200 > +++ b/dlls/setupapi/tests/Makefile.in 2006-08-04 > 16:15:05.000000000 +0200 > @@ -3,7 +3,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = setupapi.dll > -IMPORTS = setupapi kernel32 > +IMPORTS = setupapi kernel32 advapi32 rpcrt4 > > CTESTS = \ > devinst.c \ > --- a/dlls/setupapi/tests/devinst.c 2006-08-03 > 10:07:11.000000000 +0200 > +++ b/dlls/setupapi/tests/devinst.c 2006-08-04 > 17:57:57.000000000 +0200 > @@ -27,6 +27,7 @@ > #include "winuser.h" > #include "winreg.h" > #include "setupapi.h" > +#include "rpc.h" > > #include "wine/test.h" > > @@ -63,7 +64,85 @@ > ok(ret, "SetupDiDestroyDeviceInfoList failed : > %ld\n", error); > } > > +static void test_SetupDiOpenClassRegKeyExW() > +{ > + GUID guid; > + RPC_STATUS rpcStatus; > + HKEY hkey; > + WCHAR *unbracedGuid; > + WCHAR *bracedGuid; > + > + rpcStatus = UuidCreate(&guid); > + if (rpcStatus != RPC_S_OK) > + { > + ok(FALSE, "failed to generate test guid, > error %ld", rpcStatus); > + return; > + } > + > + /* Check return value for non-existant key */ > + hkey = SetupDiOpenClassRegKeyExW(&guid, > KEY_ALL_ACCESS, > + DIOCR_INSTALLER, NULL, NULL); > + ok(hkey == INVALID_HANDLE_VALUE, > + "invalid return value %p from > SetupDiOpenClassRegKeyExW " > + "for non-existant key, expected %p\n", > hkey, INVALID_HANDLE_VALUE); > + > + rpcStatus = UuidToStringW(&guid, > &unbracedGuid); > + if (rpcStatus != RPC_S_OK) > + { > + ok(FALSE, "failed to get string form of > guid, error %ld", rpcStatus); > + return; > + } > + > + bracedGuid = HeapAlloc(GetProcessHeap(), 0, > + (lstrlenW(unbracedGuid) + 3) * > sizeof(WCHAR)); > + if (bracedGuid != NULL) > + { > + HKEY classesKey; > + > + bracedGuid[0] = (WCHAR) '{'; > + memcpy(&bracedGuid[1], unbracedGuid, > + lstrlenW(unbracedGuid) * > sizeof(WCHAR)); > + bracedGuid[1 + lstrlenW(unbracedGuid)] = > (WCHAR) '}'; > + bracedGuid[1 + lstrlenW(unbracedGuid) + 1] > = (WCHAR) 0; > + > + SetLastError(0xdeadbeef); > + classesKey = > SetupDiOpenClassRegKeyExW(NULL, KEY_ALL_ACCESS, > + DIOCR_INSTALLER, NULL, NULL); > + ok(classesKey != INVALID_HANDLE_VALUE, > + "failed to open the device classes > registry key: error %ld\n", > + GetLastError()); > + if (classesKey != INVALID_HANDLE_VALUE) > + { > + DWORD ret; > + HKEY classKey; > + ret = RegCreateKeyW(classesKey, > bracedGuid, &classKey); > + if (ret == ERROR_SUCCESS) > + { > + RegCloseKey(classKey); > + SetLastError(0xdeadbeef); > + classKey = > SetupDiOpenClassRegKeyExW(&guid, KEY_ALL_ACCESS, > + DIOCR_INSTALLER, NULL, NULL); > + /* wine does incorrectly return > FALSE, so ... */ > + ok(classKey != FALSE && classKey != > INVALID_HANDLE_VALUE, > + "failed opening class key, > error %ld\n", GetLastError()); > + RegCloseKey(classKey); > + RegDeleteKeyW(classesKey, > bracedGuid); > + } > + else > + ok(FALSE, "failed creating device > key: error %ld\n", ret); > + RegCloseKey(classesKey); > + } > + > + HeapFree(GetProcessHeap(), 0, bracedGuid); > + } > + else > + ok(FALSE, "failed to allocate memory for > braced guid\n"); > + > + RpcStringFreeW(&unbracedGuid); > +} > + > START_TEST(devinst) > { > test_SetupDiCreateDeviceInfoListEx(); > + test_SetupDiOpenClassRegKeyExW(); > } > --- a/dlls/setupapi/devinst.c 2006-08-03 > 10:07:11.000000000 +0200 > +++ b/dlls/setupapi/devinst.c 2006-08-04 > 18:10:06.000000000 +0200 > @@ -1393,6 +1393,7 @@ > PVOID Reserved) > { > LPWSTR lpGuidString; > + LPWSTR lpBracedGuidString; > HKEY hClassesKey; > HKEY hClassKey; > LPCWSTR lpKeyName; > @@ -1433,21 +1434,37 @@ > if (UuidToStringW((UUID*)ClassGuid, > &lpGuidString) != RPC_S_OK) > { > RegCloseKey(hClassesKey); > - return FALSE; > + return INVALID_HANDLE_VALUE; > + } > + > + lpBracedGuidString = > HeapAlloc(GetProcessHeap(), 0, > + (strlenW(lpGuidString) + 3) * > sizeof(WCHAR)); > + if (lpBracedGuidString == NULL) > + { > + RpcStringFreeW(&lpGuidString); > + RegCloseKey(hClassesKey); > + return INVALID_HANDLE_VALUE; > } > + lpBracedGuidString[0] = (WCHAR) '{'; > + memcpy(&lpBracedGuidString[1], lpGuidString, > + strlenW(lpGuidString) * sizeof(WCHAR)); > + lpBracedGuidString[1 + strlenW(lpGuidString)] = > (WCHAR) '}'; > + lpBracedGuidString[1 + strlenW(lpGuidString) + > 1] = (WCHAR) 0; > + > + RpcStringFreeW(&lpGuidString); > > if (RegOpenKeyExW(hClassesKey, > - lpGuidString, > + lpBracedGuidString, > 0, > KEY_ALL_ACCESS, > &hClassKey)) > { > - RpcStringFreeW(&lpGuidString); > + HeapFree(GetProcessHeap(), 0, lpBracedGuidString); > RegCloseKey(hClassesKey); > - return FALSE; > + return INVALID_HANDLE_VALUE; > } > > - RpcStringFreeW(&lpGuidString); > + HeapFree(GetProcessHeap(), 0, > lpBracedGuidString); > RegCloseKey(hClassesKey); > > return hClassKey; > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- a/dlls/setupapi/tests/Makefile.in 2006-07-10 18:01:08.000000000 +0200 +++ b/dlls/setupapi/tests/Makefile.in 2006-08-04 16:15:05.000000000 +0200 @@ -3,7 +3,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = setupapi.dll -IMPORTS = setupapi kernel32 +IMPORTS = setupapi kernel32 advapi32 rpcrt4 CTESTS = \ devinst.c \ --- a/dlls/setupapi/tests/devinst.c 2006-08-03 10:07:11.000000000 +0200 +++ b/dlls/setupapi/tests/devinst.c 2006-08-04 17:57:57.000000000 +0200 @@ -27,6 +27,7 @@ #include "winuser.h" #include "winreg.h" #include "setupapi.h" +#include "rpc.h" #include "wine/test.h" @@ -63,7 +64,85 @@ ok(ret, "SetupDiDestroyDeviceInfoList failed : %ld\n", error); } +static void test_SetupDiOpenClassRegKeyExW() +{ + GUID guid; + RPC_STATUS rpcStatus; + HKEY hkey; + WCHAR *unbracedGuid; + WCHAR *bracedGuid; + + rpcStatus = UuidCreate(&guid); + if (rpcStatus != RPC_S_OK) + { + ok(FALSE, "failed to generate test guid, error %ld", rpcStatus); + return; + } + + /* Check return value for non-existant key */ + hkey = SetupDiOpenClassRegKeyExW(&guid, KEY_ALL_ACCESS, + DIOCR_INSTALLER, NULL, NULL); + ok(hkey == INVALID_HANDLE_VALUE, + "invalid return value %p from SetupDiOpenClassRegKeyExW " + "for non-existant key, expected %p\n", hkey, INVALID_HANDLE_VALUE); + + rpcStatus = UuidToStringW(&guid, &unbracedGuid); + if (rpcStatus != RPC_S_OK) + { + ok(FALSE, "failed to get string form of guid, error %ld", rpcStatus); + return; + } + + bracedGuid = HeapAlloc(GetProcessHeap(), 0, + (lstrlenW(unbracedGuid) + 3) * sizeof(WCHAR)); + if (bracedGuid != NULL) + { + HKEY classesKey; + + bracedGuid[0] = (WCHAR) '{'; + memcpy(&bracedGuid[1], unbracedGuid, + lstrlenW(unbracedGuid) * sizeof(WCHAR)); + bracedGuid[1 + lstrlenW(unbracedGuid)] = (WCHAR) '}'; + bracedGuid[1 + lstrlenW(unbracedGuid) + 1] = (WCHAR) 0; + + SetLastError(0xdeadbeef); + classesKey = SetupDiOpenClassRegKeyExW(NULL, KEY_ALL_ACCESS, + DIOCR_INSTALLER, NULL, NULL); + ok(classesKey != INVALID_HANDLE_VALUE, + "failed to open the device classes registry key: error %ld\n", + GetLastError()); + if (classesKey != INVALID_HANDLE_VALUE) + { + DWORD ret; + HKEY classKey; + ret = RegCreateKeyW(classesKey, bracedGuid, &classKey); + if (ret == ERROR_SUCCESS) + { + RegCloseKey(classKey); + SetLastError(0xdeadbeef); + classKey = SetupDiOpenClassRegKeyExW(&guid, KEY_ALL_ACCESS, + DIOCR_INSTALLER, NULL, NULL); + /* wine does incorrectly return FALSE, so ... */ + ok(classKey != FALSE && classKey != INVALID_HANDLE_VALUE, + "failed opening class key, error %ld\n", GetLastError()); + RegCloseKey(classKey); + RegDeleteKeyW(classesKey, bracedGuid); + } + else + ok(FALSE, "failed creating device key: error %ld\n", ret); + RegCloseKey(classesKey); + } + + HeapFree(GetProcessHeap(), 0, bracedGuid); + } + else + ok(FALSE, "failed to allocate memory for braced guid\n"); + + RpcStringFreeW(&unbracedGuid); +} + START_TEST(devinst) { test_SetupDiCreateDeviceInfoListEx(); + test_SetupDiOpenClassRegKeyExW(); } --- a/dlls/setupapi/devinst.c 2006-08-03 10:07:11.000000000 +0200 +++ b/dlls/setupapi/devinst.c 2006-08-04 18:10:06.000000000 +0200 @@ -1393,6 +1393,7 @@ PVOID Reserved) { LPWSTR lpGuidString; + LPWSTR lpBracedGuidString; HKEY hClassesKey; HKEY hClassKey; LPCWSTR lpKeyName; @@ -1433,21 +1434,37 @@ if (UuidToStringW((UUID*)ClassGuid, &lpGuidString) != RPC_S_OK) { RegCloseKey(hClassesKey); - return FALSE; + return INVALID_HANDLE_VALUE; + } + + lpBracedGuidString = HeapAlloc(GetProcessHeap(), 0, + (strlenW(lpGuidString) + 3) * sizeof(WCHAR)); + if (lpBracedGuidString == NULL) + { + RpcStringFreeW(&lpGuidString); + RegCloseKey(hClassesKey); + return INVALID_HANDLE_VALUE; } + lpBracedGuidString[0] = (WCHAR) '{'; + memcpy(&lpBracedGuidString[1], lpGuidString, + strlenW(lpGuidString) * sizeof(WCHAR)); + lpBracedGuidString[1 + strlenW(lpGuidString)] = (WCHAR) '}'; + lpBracedGuidString[1 + strlenW(lpGuidString) + 1] = (WCHAR) 0; + + RpcStringFreeW(&lpGuidString); if (RegOpenKeyExW(hClassesKey, - lpGuidString, + lpBracedGuidString, 0, KEY_ALL_ACCESS, &hClassKey)) { - RpcStringFreeW(&lpGuidString); + HeapFree(GetProcessHeap(), 0, lpBracedGuidString); RegCloseKey(hClassesKey); - return FALSE; + return INVALID_HANDLE_VALUE; } - RpcStringFreeW(&lpGuidString); + HeapFree(GetProcessHeap(), 0, lpBracedGuidString); RegCloseKey(hClassesKey); return hClassKey;

2 1

Re: segfaults with last selection repaint patch in riched20
by Phil Krylov Aug. 11, 2006

Aug. 11, 2006

Hi Krzysztof, On 11/08/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > What are the circumstances? Is it after some delete/insert operation, or > just after document load? Well I have not traced the whole sequence of calls to richedit, but from the display I can suppose the following. I am doing a search operation on some files. When the app finds a match, it fills the richedit with some text including the match, and changes the match's color (supposedly selects the match and calls setcharformat). It works OK. After that I push "Find next" button. After finding another match the app updates richedit text with the new context of the match and (not changed the match's color yet) segfaults. > I'd do an assert(pLastSelStartPara->member.para.nCharOfs <= > pLastSelEndPara->member.para.nCharOfs) or something. That could possibly > shed some light on the issue. When it crashes and falls out to GDB, nCharOfs of the first para is 10, and nCharOfs of the last para is 3. > This git thing is a piece of unreliable unintuitive crap. For sure CVS was simpler, but GIT also has some advantages... I haven't had any problems requiring to git-clone yet, but I still have to hold the GitWine wiki page open in my browser ;) -- Ph.

1 0

segfaults with last selection repaint patch in riched20
by Phil Krylov Aug. 11, 2006

Aug. 11, 2006

Hi Krzysztof, I was getting a segfault in ME_MarkForPainting() after that patch (BTW great work), and started looking through the code. One thing I found was obviously a typo which can be easily fixed (BTW I don't know for sure but I'd also update pLastSelStartPara and pLastSelEndPara here): --- a/dlls/riched20/paint.c +++ b/dlls/riched20/paint.c @@ -529,7 +529,7 @@ ME_InvalidateSelection(ME_TextEditor *ed /* last selection markers aren't always updated, which means they can point past the end of the document */ if (editor->nLastSelStart > len) - editor->nLastSelEnd = len; + editor->nLastSelStart = len; if (editor->nLastSelEnd > len) editor->nLastSelEnd = len; But it did not resolve my problem. I did not have time to find the real reason for the segfault, but here is a quick hack which made the segfault go away and can probably help you in finding the real reason. Sorry, but I can't officially provide you with the failing application (IBM Translation Manager 6.0.9) which is proprietary and only for IBM internal usage. --- a/dlls/riched20/para.c +++ b/dlls/riched20/para.c @@ -94,7 +94,7 @@ void ME_MarkForWrapping(ME_TextEditor *e void ME_MarkForPainting(ME_TextEditor *editor, ME_DisplayItem *first, ME_DisplayItem *last) { - while(first != last) + while(first && first != last) { first->member.para.nFlags |= MEPF_REPAINT; first = first->member.para.next_para; The backtrace of the segfault was: 1 0x7d948cc0 ME_MarkForPainting+0x10(editor=0x11700f8, first=0x11741d8, last=0x1173ac8) [/home/phil/build/wine-git/dlls/riched20/para.c:99] in riched20 (0x7d948cc0) 2 0x7d948816 ME_InvalidateSelection+0x186(editor=0x11700f8) [/home/phil/build/wine-git/dlls/riched20/paint.c:542] in riched20 (0x7d948816) 3 0x7d9442e9 RichEditANSIWndProc+0x22d9(hWnd=0x100b4, msg=0xb1, wParam=0xe, lParam=0x117) [/home/phil/build/wine-git/dlls/riched20/editor.c:1579] in riched20 (0x7d9442e9) 4 0x7d9466aa RichEdit10ANSIWndProc+0x3a(hWnd=0x100b4, msg=0xb1, wParam=0xe, lParam=0x117) [/home/phil/build/wine-git/dlls/riched20/editor.c:2598] in riched20 (0x7d9466aa) ... -- Ph.

2 1

[UPDATE] RFC: XEmbed System Tray Patches
by James Liggett Aug. 10, 2006

Aug. 10, 2006

Attached is a major update to the XEmbed systray patches that I sent earlier this week. After a few days of tweaking and testing the code, I think I have found the solution to the race conditions that have plagued previous versions of this work. While this is a major step forward, I still need some assistance with some issues with these patches: 1. I need people to test this on any window manager they can to see if the results that I get can be reproduced, especially on older GNOME versions (I tested on GNOME 2.14) I was able to run a small test app that I made over 120 times, and each time it docked perfectly, no zombie systray adapter windows like before. 2. In order to accomplish this reliability, I've had to ensure that systray windows are *never* mapped. According to the XEmbed specs and my testing, we can't map systray windows ourselves--the tray has to do it, or we get the race conditions. However, my current solution isn't entirely correct. The problem is that systray windows aren't mapped under *any* circumstances. While this allows the docking to work properly, the icons don't show up at all if there's no tray to dock with. I've been contemplating some solutions to the problem but I'm not sure what the correct way to go about this is. My current idea is to add a function to winex11.drv that checks to see if we have a systray window. If the function finds one, then we don't map tray windows. If it doesn't return one, then we map them. Would adding a function like that to x11drv be a good idea? Any comments/suggestions/test results highly appreciated. If you'd like to test these, apply them in the order that they're numbered (should go from 0001 to 0010.) Thanks again, James Liggett

1 0

A advapi32 patch to Implement GetCurrentHwProfileA() fully I found
by Scott Ritchie Aug. 10, 2006

Aug. 10, 2006

It looks like this patch didn't get into 0.9.19, so I think someone else needs to take ownership of it and figure out what Alexandre wants until it can get in. I'm looking forward to full tilt poker working :) Any volunteers? Thanks, Scott Ritchie ----- Thanks to the AppDB and a little digging, I was able to discover this patch from a long while ago that never got properly forwarded to wine-patches. See here: http://www.winehq.org/pipermail/wine-devel/2006-February/045115.html Apparently, it makes the Full Tilt Poker client work, which is currently broken (see http://appdb.winehq.org/appview.php?iVersionId=2839) Since this patch apparently got lost by the wayside after it showed up on wine-devel, I'm doing the last step for him and sending it on to wine-patches. If this patch does get rejected, I won't be able to fix it, so please post a message on wine-devel so someone else can do it. It would be a shame for this implementation to stay dead for another year. If implemented, this should also close bug 4468: http://bugs.winehq.org/show_bug.cgi?id=4468 Thanks, Scott Ritchie

1 0

Re: wine-ShowCursor-D3D-over-GDI.patch
by Stefan Dösinger Aug. 10, 2006

Aug. 10, 2006

Am Samstag 29 Juli 2006 11:17 schrieb Andrew Riedi: > Well, here is my first patch, feel free to tell me what all is wrong with > it. I noticed a problem in WoW d3d, so I tracked it down and checked out > msdn. It seems that implementing ShowCursor() over GDI is acceptable, at > least according to msdn, and it seems to work great. Anyhow, this patch > fixes the two mouse cursor problem in WoW, and makes wined3d more > compatible with windows, at least msdn. Here goes nothing. I wrote a little testing app, and unfortunately this is not correct. IDirect3DDevice9::ShowCursor has no effect on the gdi cursor. Part one of that tests are in the minor cursor fix I sent yesterday. The cursor visiblity reported by GetCursorInfo does not change with d3d9device::ShowCursor. The real visibility on the screen does not change either, after ShowCursor(FALSE) the gdi cursor is still visible on windows. The other parts are in my not-yet sent visual test case suite, I didn't send it yet because it needs more work on GetFrontBufferData. What I noticed is that the gdi cursor immediately disappears when SetCursorProperties is called - but GetCursorInfo still returns that it is showed, and the cursor handle is the same :-/ There are some other things which hide the cursor which I didn't find yet. A number of old ddraw games have cursor issues too

1 0

Something wrong with this patch ?
by Stefan Siebert Aug. 10, 2006

Aug. 10, 2006

I assume there's something wrong with my patch ? I've did some research lately on how 32 Bit programs interact with 16Bit windows. This patch doesn't help if a SendMessage was sent from a 32Bit application because it gets dispatched from the 16Bit thread. So NtCurrentTeb doesn't work. At least it fixes uncaught WM_USER messages in the current process. >user - EditWndProc_common - Ignore WM_USER messages which are not sent >from a vdm >Hello, >this patch fixes a Notes Client crash when building the server console >tab (administration client). After creating a text control for console >commands it sends uncaught WM_USER messages which get interpreted by >Wine as 16Bit messages and crashes badly due to NULL pointers. >Changelog: user/edit.c - EditWndProc_common - Ignore WM_USER messages >which are not sent from a vdm --- Stefan Siebert diff --git a/dlls/user/edit.c b/dlls/user/edit.c old mode 100644 new mode 100755 index c4f95e4..fd74183 --- a/dlls/user/edit.c +++ b/dlls/user/edit.c @@ -439,6 +439,10 @@ static LRESULT WINAPI EditWndProc_common LRESULT result = 0; TRACE("hwnd=%p msg=%x (%s) wparam=%x lparam=%lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wParam, lParam); + + /* Ignore WM_USER messages which are not sent from a vdm */ + if ((msg >= WM_USER) && (!NtCurrentTeb()->Tib.SubSystemTib)) + return 0; if (!es && msg != WM_NCCREATE) return DefWindowProcT(hwnd, msg, wParam, lParam, unicode);

1 0

static inline wine_get_fs etc
by Tijl Coosemans Aug. 10, 2006

Aug. 10, 2006

I'm looking at include/wine/library.h and was wondering why the wine_get_fs/gs/... are declared extern and not static like many other functions in that file. Is there any particular reason I'm not seeing? Their __asm__ block is also missing __volatile__ I believe.

3 2

Wine is stripping comments from system register
by Augusto Arcoverde da Rocha Aug. 9, 2006

Aug. 9, 2006

Hi all, I'm tring store some marks as comments inside of system register, but when I start some wine process and it finish the comments have disappeared from the register file. Is this the expected behaviour? Many thanks, Augusto Arcoverde da Rocha

2 1

localspl.dll: Implementation-Question
by Detlef Riekenberg Aug. 9, 2006

Aug. 9, 2006

Am Sonntag, den 30.07.2006, 21:41 +0200 schrieb Detlef Riekenberg: > Printmonitors need spoolss.dll,EnumPortsW > > On windows, all work is done in spoolss.dll and winspool.drv is just the > Forwarder (RPC). > We avoid the need for loading spoolss.dll in every App by > doing the work in winspool.drv and use spoolss.dll as relay. > > > Changelog: > - spoolss: add EnumPortsW (by calling winspool.drv) > The Codebase in "dlls/winspool.drv/info.c" get really large and the actual Code-Path is: "winspool.drv -> CUPS/LPR" (with help from GDI). A possible place to split the Code is at the Printmonitor-Level. The Printmonitor for the Standard "Local Ports" in Windows (COM*:, LPT*:, FILE:, Windows-File) was in "localmon.dll" and merged into "localspl.dll" with w2k. On IRC, Alexandre already accepted to handle Wine-Specific Ports ( CUPS:*, LPR:*, Pipe to a unix_app, /unix-File ) together with the Standard Window-Ports in a single Printmonitor: "localspl.dll" The Requirement, that updating the System-Printers in wine must work automatic, need some Attention, when the related code (LoadSystemPrinters) move from "winspool.drv" to "localspl.dll": 1) Changing the Code-Path to "winspool.drv -> localspl.dll -> CUPS/LPR" and using the same Memory-Functions for "localspl.dll" as done in Windows (the Memory-Related Exports from "spoolss.dll"), give us a circular dependency, when we load and call "winspool.drv" from "spoolss.dll". For this reason, using HeapAlloc(GetProcessHeap(), ...) and Friends from "kernel32.dll" is a Possible way to go for "localspl.dll". 2) To let Printing in Wine work as similar as possible as Printing is done in Windows, (but without RPC and without the Spooler-Service) we can change the Code-Path to "winspool.drv -> spoolss.dll -> localspl.dll -> CUPS/LPR" and use the Exports from "spoolss.dll". Since we need the Memory-Exports from "spoolss.dll" also for other Printmonitors and many Names/Prototypes of the other "spoolss.dll" - Exports are Equal to the Functions in "winspool.drv", I prefer Solution "2". (Wine as an EMF-Printing-Backend for samba is only Possible with 2) As a Reference, what windows does, is: winspool.drv --(RPC)--> spoolsv.exe(Spooler Service) --(WINAPI)--> spoolss.dll -> localspl.dll -> Driver for LPT*: / COM*: Any comments please. Thanks -- By By ... ... Detlef

1 0

Re: This patch should fix bug 4863 - Icons in Notes Workspace
by Augusto Arcoverde da Rocha Aug. 9, 2006

Aug. 9, 2006

Hi all, A little time ago I have sent this patch and now I'm asking to the Wine devel community about the correctness of that code. May be a fix for "Icons in Notes" bug would be incorporated in the next Wine release with some peer-review efforts. Regards, Augusto Arcoverde da Rocha On 7/21/06, Augusto Arcoverde da Rocha <agarobr.listas(a)gmail.com> wrote: > Description: > This patch should fix bug 4863 - Icons in Notes Workspace. > > ChangeLog: > Making SetDIBits function compliant with MSDN documentation by > ignoring the device context parameter if DIB parameter is informed as > having a palette (DIB_PAL_COLORS). > > References: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmap… > > Author: > Augusto Arcoverde da Rocha <agarobr\at\yahoo.com.br> > > Notes: > Since I wasn't successful learning more about internal representation > of DIB structure, I couldn't make the apropriated test units for this > fix, sorry. > > >

4 4

Re: version/tests: Write-strings warnings fix
by James Hawkins Aug. 9, 2006

Aug. 9, 2006

On 8/9/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Please note: in install.c, I have preserved a distinction between "regedit" > and "regedit.exe" that was in the original code. If this distinction is > accidental, please inform me, via wine-devel, and I shall send a revised > version of this patch. > ... > > @@ -34,6 +34,9 @@ > char filename[MAX_PATH]; > char outBuf[MAX_PATH]; > char windir[MAX_PATH]; > + static CHAR empty[] = "", > + regedit_a[] = "regedit", > + regedit_b[] = "regedit.exe"; > > memset(appdir, 0, MAX_PATH); > memset(windir, 0, MAX_PATH); > Seems like regedit and regedit_exe might be better names than regedit_a/b. -- James Hawkins

2 1

Re: WineD3D: draw buffers support (patch 2)
by Roderick Colenbrander Aug. 9, 2006

Aug. 9, 2006

This is a slighly updated version of the patch. The code is the same but I changed the comment a little as suggested by Henri as the part about SM3 was wrong. Roderick > Hi, > > This is a second draw buffers / gl_FragColor patch and it depends on the > other patch which was sent earlier today. The previous patch added draw > buffers support and fixed a gl_FragData bug. This patch fixes another case > where we incorrectly use gl_FragData. > > Regards, > Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

wine
by XIAOJING XIN Aug. 9, 2006

Aug. 9, 2006

hi how are you? i am one of wine users , it is a very amazing software i like it very much , and i have a problem here , does wine support other language? i use it to run one of foreign software which is Chinese, but , the wine software can not display the language, so what can i do now , does it only support English software? regard thank you very much

5 6

[FreeBSD] locating wine at 0x20000000
by Tijl Coosemans Aug. 9, 2006

Aug. 9, 2006

Hello all, For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf00000. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x80000000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x20000000. That would be the easiest solution by far, but, are there any potential problems with that?

2 7

Re: [2/2] WINED3D: Fix D3DCOLOR swizzling in shaders.
by Christoph Frick Aug. 9, 2006

Aug. 9, 2006

On Sat, Aug 05, 2006 at 06:15:42PM +0200, H. Verbeet wrote: > This patch fixes those issues by looking at the data types in the > vertex declaration the shader will be used with. To be able to do > that, we have to wait with compiling the shader until the shader is > first used and we have a vertex declaration. I am not sure, if exactly *this* patch fixes the problem - but i assume so: the colors of the cars and lights in Live For Speed are not fixed also. thanks for that! -- cu

1 0

Re: wineconsole: command line option output / default user backend
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This small patch provides command line option output, a "--help" option > and a default user backend ("--backend=user" is default) to "wineconsole". Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code. -- Alexandre Julliard julliard(a)winehq.org

6 14

widl: Error on simple idl file
by Elrond Aug. 9, 2006

Aug. 9, 2006

Hi, The attached idl file gives an error when used with widl -DUSE_TYPEDEF simple.idl I doubt, that it is a syntax error, since adding "-h" creates the header, using "-c" gives the error. The error is: error: Unsupported member type 0x0 Elrond

1 0

Re: ntdll: make shared user data access work
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Robert Reif <reif(a)earthlink.net> writes: > diff -p -u -r1.66 thread.c > --- dlls/ntdll/thread.c 26 Jul 2006 14:01:20 -0000 1.66 > +++ dlls/ntdll/thread.c 6 Aug 2006 01:15:43 -0000 > @@ -215,7 +215,7 @@ HANDLE thread_init(void) > > addr = (void *)0x7ffe0000; > size = 0x10000; > - NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE, PAGE_READONLY ); > + NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); This code is only intended to reserve the space at startup. We need to initialize it properly later on before making it accessible. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: wineconsole: command line option output / configurable default backend
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This patch is akin to the previously posted; however, instead of making > the user backend > the default, I read an environment variable WINECONBACKEND to determine > the default. I don't think that's an improvement, please let's not add more obscure environment variables. You should try to use the user backend when the X display is available and fall back to curses otherwise. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: oleaut32: Add tmarshal conformance test
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This adds a conformance test written by Rob Shearman. Pretty much all the > code in the four files beginning with "tmarshal" is his. All I did was make > some changes to the Makefiles to be able to test things with IDL components, > and I tweaked his stuff in one or two places where needed. For example, I > wrapped the tests that failed in todo_wine blocks, and I commented out a test > that crashes Wine. All the tests pass on Windows (including the one that > crashes Wine). They don't work on Wine here: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok fixme:ole:ITypeInfo_fnRelease destroy child objects err:ole:marshal_object couldn't get IPSFactory buffer for interface {a028db05-30f0-4b93-b17a-41c72f831d84} err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80040155 err:ole:CoMarshalInterface Failed to marshal the interface {a028db05-30f0-4b93-b17a-41c72f831d84}, 80040155 tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x8003001e tmarshal.c:760: Test failed: CoUnmarshalInterface failed with error 0x8003001e wine: Unhandled page fault on write access to 0x00000000 at address 0x15a159 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x0015a159). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:0015a159 ESP:0033fc88 EBP:0033fd58 EFLAGS:00010246( - 00 -RIZP1) EAX:00159310 EBX:7b8abaa8 ECX:00000000 EDX:00000001 ESI:8003001e EDI:60412be7 Stack dump: 0x0033fc88: 00159310 7b88c87f 00159310 00000001 0x0033fc98: 0015a500 0015a158 00159310 0033ff2c 0x0033fca8: 7b82be98 7b8415c0 7b8abaa8 8003001e 0x0033fcb8: 60412be7 0033fd58 0033fc90 7b88c805 0x0033fcc8: 00000001 00000000 00000000 00000020 0x0033fcd8: 0033fd58 7bc2764f 00110000 7bc77848 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000119 Backtrace: =>1 0x0015a159 (0x0015a159) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for oleaut32_test<elf> 2 0x603092f7 func_tmarshal+0x2f7 [/home/julliard/wine/wine/dlls/oleaut32/tests/tmarshal.c:763] in oleaut32_test (0x603092f7) 3 0x6040ee81 run_test+0x121(name=0x1103a9) [/home/julliard/wine/wine/dlls/oleaut32/tests/../../../include/wine/test.h:365] in oleaut32_test (0x6040ee81) 4 0x6040f1a9 __wine_spec_exe_entry+0x99(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in oleaut32_test (0x6040f1a9) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> 5 0x7b87015b start_process+0xeb(arg=0x0) [/home/julliard/wine/wine/dlls/kernel/process.c:822] in kernel32 (0x7b87015b) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 6 0x6001f887 wine_switch_to_stack+0x17 in libwine.so.1 (0x6001f887) 0x0015a159: addb %dl,0x0(%ecx) Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wineconsole: command line option output / configurable default backend
by Vitaliy Margolen Aug. 9, 2006

Aug. 9, 2006

Wednesday, August 9, 2006, 2:33:17 AM, Ekkehard Morgenstern wrote: > This patch is akin to the previously posted; however, instead of making > the user backend > the default, I read an environment variable WINECONBACKEND to determine > the default. > If the value isn't set, "curses" will be the default as in the original > code. You patch wrapped again. Please attach it to the e-mail instead. Vitaliy.

2 1

Re: riched20: new selection invalidation logic
by Vitaliy Margolen Aug. 9, 2006

Aug. 9, 2006

Monday, August 7, 2006, 9:27:16 AM, Krzysztof Foltman wrote: > ChangeLog: > * New, clean, simple selection repaint logic - should fix all > outstanding refresh issues (and bug#5882) > Krzysztof I think this patch takes number of asserts per line to the highest level I've ever seen. Could you explain why you adding asserts everywhere (only 11 in this patch alone!!!)? Instead of using proper error handling? For the past year or more that was the main source of user problems. And if you could how many installers have been broken with this technique, you will probably account for 90% of all the installers that otherwise would work on Wine. Have you even tried your code on purposely broken rtf? How does it handle it? Vitaliy Margolen

3 6

Re: msvcrt: In text mode a ctrl-z signals EOF
by Duane Clark Aug. 8, 2006

Aug. 8, 2006

Duane Clark wrote: > Changelog: In text mode a ctrl-z signals EOF > Spotted by David Hagood with test suggested by Dan Kegel > Howdy David. Any chance you could try out this patch? I added a conformance test, as suggested by Dan, and it looks like any data after a ctrl-z is stripped. Of course, it may be that in the real world there will never be anything other than additional ctrl-z characters, in which case your version would be fine (and more efficient). http://www.winehq.org/pipermail/wine-patches/2006-August/029544.html

1 0

Re: libs/wine/config.c: use execve on FreeBSD
by Alexandre Julliard Aug. 8, 2006

Aug. 8, 2006

Tijl Coosemans <tijl(a)ulyssis.org> writes: > * use execve on FreeBSD Renaming the msvcrt function would really be better. Particularly since "extern char **environ" doesn't work right on all platforms. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Alexandre Julliard Aug. 8, 2006

Aug. 8, 2006

Jeff L <lats(a)yless4u.com.au> writes: > + cMaxItems = 255; /* Pick an abritary size for buffers */ > + analysis = (string_analysis*) pssa; > + if (!*pssa) { /* Clean it out and start again */ > + prtssa(*pssa); > + ScriptStringFree((SCRIPT_STRING_ANALYSIS*)analysis); > + } > + analysis = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(string_analysis)); > + *pssa = (string_analysis*)analysis; I don't follow what you are trying to do here. Why do you print and free a NULL structure? And why do you assign it to analysis and then overwrite it right away with a new allocation? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winhelp: bug fix in LZ77 decompressor - prehistory to make things clear
by HolyLich Aug. 8, 2006

Aug. 8, 2006

>> >> Why? >> >> Er, if the memcpy worked (or almost worked) and failed due to overlap >> problems, then memmove will do the trick. Did it ever work at all before? >> Either this code never worked, or you're either seeing a problem that doesn't >> exist/misunderstanding things. >> >> Cheers, Kuba Um, sorry, I didn't understand question. I try to explain why memcpy worked before. It did not worked. As far as I noticed, this bug does not affect small files (<=0x1000) but if file was large enough (>0x1000 byte) - it will appear. In my case it was multi-colour metafile (jwpce.hlp, http://www.physics.ucla.edu/~grosenth/jwpce.html - lots of metafiles). Small pictures are OK, but large are jammed. What is interesting, the bug affected bitmap part of metafile, so no errors while PlayMetaFile, but the result bitmap was jammed a little. --HolyLich

2 1

Re: riched20: modify ME_CharFromPoint to work properly with password controls
by Phil Krylov Aug. 8, 2006

Aug. 8, 2006

Hi Matt, On 07/08/06, Matt Finnicum <mattfinn(a)gmail.com> wrote: > This patch modifies ME_CharFromPoint to work properly with password > controls (the patch i sent in / got committed a couple days ago). Should not the temp string be freed afterwards? -- Ph.

2 2

Re: winhelp: bug fix in LZ77 decompressor
by HolyLich Aug. 8, 2006

Aug. 8, 2006

On Tue, 8 Aug 2006 09:37:09 -0400, Kuba Ober <kuba(a)mareimbrium.org> wrote: >> > > Fix rather unusual bug in LZ77 decompressor. We cannot use >> > > memcpy >> > > with overlapped areas because of unpredictable result. We must >> > > copy byte-by-byte. > >> > Why don't you use memmove instead? The man page for memcpy says: >> > Use memmove(3) if the memory areas do overlap. > >> We cannot use memmove. It provides different functionality. It moves >> blocks, but LZ77 decompress algorithm copies bytes. >> >> Let's suppose: >> 012 >> XYZ >> >> When we say 'memmove(1, 0, 2)' we will get: >> 012 >> XXY >> >> But we (LZ77 algorithm) expect: >> 012 >> XXX (three 'X'). >> >> memcpy is rather clever (it optmizes process by coping INT instead of >> BYTES). This optimization is fatal for LZ77. > > Why? > > Er, if the memcpy worked (or almost worked) and failed due to overlap > problems, then memmove will do the trick. Did it ever work at all before? > Either this code never worked, or you're either seeing a problem that doesn't > exist/misunderstanding things. > > Cheers, Kuba memmove provides OTHER functionality - it GUARANTEES, that if blocks overlaps, then destination area will the same as source area before. LZ77 decompress algorithms needs copiing byte-by-byte - of course, if areas overlap, then dest area WILL NOT match the src area before. It IS correct for LZ77! The simpliest version of memcpy routine, like this: void my_memcpy(char *dst, char *src, int len) { while (len-->0) *dst++=*src++; ) WILL work correctly for LZ77. memcpy provided by gcc is optimized - it NOT copies byte-by-byte from beginning till end. If you mediate over lz77 decompress algo (dlls/kernel/lzexpand.c) the things will be clean.

1 0

Re: winhelp: bug fix in LZ77 decompressor
by HolyLich Aug. 8, 2006

Aug. 8, 2006

> HolyLich wrote: > > ChangeLog: > > Fix rather unusual bug in LZ77 decompressor. We cannot use memcpy > > with overlapped areas because of unpredictable result. We must copy > > byte-by-byte. > Why don't you use memmove instead? The man page for memcpy says: > Use memmove(3) if the memory areas do overlap. We cannot use memmove. It provides different functionality. It moves blocks, but LZ77 decompress algorithm copies bytes. Let's suppose: 012 XYZ When we say 'memmove(1, 0, 2)' we will get: 012 XXY But we (LZ77 algorithm) expect: 012 XXX (three 'X'). memcpy is rather clever (it optmizes process by coping INT instead of BYTES). This optimization is fatal for LZ77. For more information, please, refer to patch. It contains some useful comment. --HolyLich

2 1

Font metrics
by Jeff L Aug. 8, 2006

Aug. 8, 2006

People, I am working on ScriptStringXtoCP etc in usp10. In setting up the tests for this I notice that ABC widths returned ScriptPlace (*/GetCharABCWidthsI) /*is not the same as Windows does. Have tried an couple of fonts and the results are the subtly different. Before I get too carried away with this, are the ABC widths supposed to be the same in Wine and Windows? Jeff Latimer

1 0

dinput & [Get|Set]CursorPos conandrum
by Vitaliy Margolen Aug. 8, 2006

Aug. 8, 2006

Some one few weeks ago mentioned that they needed SetCursorPos to work globally (between processes). Well it seems after all we do need that to fix few lots of things, including most mouse related bugs in dinput. Actually the problem I have is not as much with SetCursorPos as with the fact that with multiple processes only one gets MotionNotify (and other notify) events. This gets cursor position out of sync between two processes and causes interesting side-effects. It's not something major but an annoyance. There are could be more serious problems however. The possible solutions might be: 1. Store cursor_pos in wineserver and call wineserver whenever we need it or need to modify it. Seems straight forward but how expensive it would be? 2. Use shared memory. That means we have to allocate it first (will SharedUserData work for this?). And use mutex for sync. 3. Query X for it's cursor position. Pretty much what we do, except that needs to be fixed: Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X. Any ideas appreciated. Vitaliy

2 4

Re: winhelp: bug fix in LZ77 decompressor
by Michael Stefaniuc Aug. 8, 2006

Aug. 8, 2006

HolyLich wrote: > ChangeLog: > Fix rather unusual bug in LZ77 decompressor. We cannot use memcpy > with overlapped areas because of unpredictable result. We must copy > byte-by-byte. Why don't you use memmove instead? The man page for memcpy says: Use memmove(3) if the memory areas do overlap. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: WineD3D: shader cap fixes
by Roderick Colenbrander Aug. 8, 2006

Aug. 8, 2006

Use this updated patch. I forgot to initialize some constants to zero and made the diff against a wrong file because of which some crucial changes were missed. Roderick > Hi, > > This patch adds most missing shader capabilities. Some capabilitise are > read from OpenGL but not everything is mappable to Direct3D in some cases an > extension from lets say Nvidia can be used but it is not really worth it. > If there's no OpenGL cap the minimum required values as required by the > shader specs are used. > > Regards, > Roderick Colenbrander -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

Constifying Undocumented Code?
by Andrew Talbot Aug. 8, 2006

Aug. 8, 2006

Where we emulate undocumented code, is it acceptable to constify the formal arguments, where appropriate? Thanks, -- Andy.

3 3

HAL and Copy Protection
by Jesse Allen Aug. 8, 2006

Aug. 8, 2006

Does anyone have HAL and SecuRom copy protection working? I'm starting to get support questions with people using HAL and I'm not sure how to help them. I need information now that HAL support is in Wine on whether SecuRom works with it and how to get it to work as I don't have HAL. Jesse

2 6

Re: wined3d: stub out remaining renderstates
by Stefan Dösinger Aug. 7, 2006

Aug. 7, 2006

Am Dienstag 08 August 2006 00:06 schrieb Jan Zerebecki: > If this patch is rejected from inclusion, please tell me why, as i would > have to ask anyway. It looks like you forgot d3d7 render states like TEXTUREMAPBLEND. This state isn't really important for this patch, I will send an implementation for it tomorrow, but other d3d7 render states are perhaps needed.

1 0

Re: wintrust: Always return ERROR_SUCCESS in WinVerifyTrust [RESEND]
by Paul Vriens Aug. 7, 2006

Aug. 7, 2006

On Mon, 2006-08-07 at 11:11 -0700, James Hawkins wrote: > Hi, > > Accoring to recent comments by Paul Vriens, Process Explorer now > accepts ERROR_SUCCESS from WinVerifyTrust, and several installers > require ERROR_SUCCESS in order to continue, so everyone is happy. > Fixes bugs 5573 and 3619. > > http://bugs.winehq.org/show_bug.cgi?id=5573 > http://bugs.winehq.org/show_bug.cgi?id=3619 > > Changelog: > * Always return ERROR_SUCCESS in WinVerifyTrust. > > dlls/wintrust/wintrust_main.c | 18 +++++------------- > 1 files changed, 5 insertions(+), 13 deletions(-) > When I run process explorer without tracing/debugging everything is fine. As soon as I add +wintrust,+heap it fails again. There is most likely some heap corruption somewhere (couldn't be more vague). Alexandre's patch to add more free list entries only masked the problem, as far as I can see from the results. Cheers and sorry for the misleading remarks, Paul.

2 2

Re: user[2/2]: Preserve LastError.
by Vitaliy Margolen Aug. 7, 2006

Aug. 7, 2006

Saturday, July 29, 2006, 7:28:10 PM, Vitaliy Margolen wrote: > ChangeLog: > user: Preserve LastError. > dlls/user/tests/input.c | 4 ++++ > dlls/winex11.drv/x11drv.h | 3 +++ > 2 files changed, 7 insertions(+), 0 deletions(-) Anything wrong with this patch? Test case clearly shows that we should preserve the LastError. Vitaliy Margolen

2 3