- wine-devel - winehq.org

how to open a linux application in the windows program
by yaoyansi 13 Apr '06

13 Apr '06

I appreciate your help as I begin to understand Wine. I installed kernel-win32 on Linux,and tried running a program which is developed with vc++6.0. The program runs well except opening a linux application. I can use system(),WinExec(),and ShellExecute() to open a windows application in vc++6.0. The question is,how to open a linux application in my program?and how to fill the correct parameters in these 3 functions. --yaoyansi --------------------------------- 雅虎1G免费邮箱百分百防垃圾信雅虎助手-搜索、杀毒、防骚扰

2 1

bad archive link in WWN Issue #311
by Tony Lambregts 13 Apr '06

13 Apr '06

The archive link for "Audio Latency Issues" in issue 311 of Wine Weekly News gives a 404 error: http://www.winehq.com/pipermail/wine-devel/2006-April/046088.html It should probably be replaced by the following link. http://www.winehq.com/pipermail/wine-devel/2006-April/046139.html I would fix it myself but I am at work right now and I will be out of town (and away from my linux box) for the Easter long weekend so it will be a while before I am able to do so. So If someone else could provide a proper patch I would appreciate it in the mean time here is a the best patch I could come up with using the tools I have Thanks

2 1

Re: Wine fonts too big for their input fields.
by Duane Clark 13 Apr '06

13 Apr '06

Brian Vincent wrote: > On 4/12/06, *Duane Clark* <dclark(a)akamail.com > <mailto:dclark@akamail.com>> wrote: > > I made the attached changes to the edit test. The results when run on > Win2k are a bit strange (note that I only looked for the min in the > first 1024 glyphs): > > edit.c:807:Font Microsoft Sans Serif first char=32, last=65532 > edit.c:817:MinA=0, minC=0 > edit.c:824:Left=0, right=0 > > > Question: is there ever a situation where Left=0 and Right=0 is ok? If > not, just bump it by 1. > > That's probably not the right solution, but this just seems like a > corner case. Actually, those are the results on real Windows 2000. So they are (presumably) the correct values. Wine puts in margins, which it shouldn't in this case.

1 0

Re: Hungarian translation of wordpad and regedit
by James Hawkins 13 Apr '06

13 Apr '06

On 4/13/06, Kovács András <andras(a)csevego.net> wrote: > Hi I translated these two programs to hungarian There are two attached > documents: 1. The diffs between the original and the modified files 2. The > two Hu.rc files Best regards, Andras Kovacs > Can you send the diff of each program separately? -- James Hawkins

1 0

Re: README: Updated to not point users at wineinstall and to mention fontforge
by Phil Krylov 13 Apr '06

13 Apr '06

On Mon, 10 Apr 2006 08:18:51 +0200 Kai Blin <kai.blin(a)gmail.com> wrote: > Also added fontforge to the build requirements list, with a note to Gentoo > users to update their version of fontforge, as the version currently used in > Gentoo doesn't work. Too late: today's Gentoo Portage has fontforge-20060406 (although as a ~x86 unstable package). -- Ph.

7 8

Re: wined3d: move traces into D3DFmtMakeGlCfg and fix FIXME for depth/stencil buffer "not found"
by Jason Green 13 Apr '06

13 Apr '06

On 4/13/06, Christoph Frick <frick(a)sc-networks.de> wrote: > License: LGPL > ChangeLog: > 2006-04-12 Christoph Frick <rid(a)zefix.tv> > * dlls/wined3d/device.c > move traces into D3DFmtMakeGlCfg and fix FIXME for depth/stencil > buffer "not found" Part of this is already in my patch from yesterday that has been applied to the latest git/cvs (the FIXME update). But, the TRACE's could still be useful.

1 0

Re: [WINED3D] Improve pshader code structure
by Vitaliy Margolen 13 Apr '06

13 Apr '06

Wednesday, April 12, 2006, 4:02:58 PM, Ivan Gyurdiev wrote: > The point of this patch is to pull out things like modifier processing > (write masks, saturate, swizzle) from different case statements, and put > them in a more common path, which simplifies code, and makes sure we > don't miss cases. Also, reorder things as appropriate to get rid of the > crazy continue/switch flow control that's confusing me. Dead code paths > were also if0'ed. > Patch introduces undesired effect that now input and output modifiers > are allowed on all instructions, which is definitely not valid according > to MSDN. However, I don't think we should care at this point, since > processing of valid shaders, and simplifying the code path should take > precedence. We can add validation later in a more appropriate place [ > the current "validation" is to completely disable or enable modifiers on > certain instructions, which is not correct either - and it should fail, > not just print a fixme on error ]. > Patch will enable processing _bx2 modifier on certain texture > instructions, which is valid in shaders 1.2/1.3. Also, is negation and > swizzling valid on texture instructions in 3.0? If it is, this will > process it. Also will enable write mask processing in some texture > instructions where it previously wasn't, generating more correct shader. I'm afraid this page changes too much at one go. You should split it into separate pieces. For example: > TRACE("Found opcode D3D:%s GL:%s, PARAMS:%d, \n", > - curOpcode->name, curOpcode->glname, curOpcode->num_params); > + curOpcode->name, curOpcode->glname, curOpcode->num_params - 1); should be one patch. Btw why are you adding -1 here? This could be turned into one big patch that is no-op: > /* Cubemap textures will be more used than 3D ones. */ > - sprintf(tmpLine, "TEX T%lu, TMP, texture[%lu], CUBE;\n", reg, reg); > + sprintf(tmpLine, "TEX T%lu, TMP, texture[%lu], CUBE;\n", output, output); Vitaliy Margolen

2 1

Wine fonts too big for their input fields.
by Tony Lambregts 13 Apr '06

13 Apr '06

We now have at least three bugs[1] where the program will not accept the all the characters that are required if we do not use native fonts. The latest bug report was reported just today and the reporter resolved the bug as FIXED when he used Native fonts. So I have a couple of questions. Should we consider using native fonts a "FIX" or is it just a workaround? Or in other words can we fix our built in fonts to fix this. Should These bugs marked a duplicates? [1] http://bugs.winehq.org/show_bug.cgi?id=2389 http://bugs.winehq.org/show_bug.cgi?id=4162 http://bugs.winehq.org/show_bug.cgi?id=5052 -- Tony Lambregts

6 17

Re: Comctl32: fix listview column resize [2/2] (resend)
by Detlef Riekenberg 12 Apr '06

12 Apr '06

Mikołaj Zalewski wrote: > When resizing the columns of a listview by dragging the header columns > divider, the list columns resizes after every mouse move while the > header only draws a tracking line and resizes when the mouse button goes > up. These patches tries to fix it. The Drivers-Listview in winecfg works now (thanks for that fix), but the Listview-Issues in winefile are still present. Any Ideas? -- By By ... ... Detlef

2 1

undefined reference to `FT_Load_Sfnt_Table'
by Saulius Krasuckas 12 Apr '06

12 Apr '06

WRT suite build fails for quite long time already: [1] So that probably was caused by the patch from Huw: [2] It may happen because of missing FreeType 2 stuff: [3] If that's the case for us (Paul Millar), can it be worked around by adding another configure check, guys? Or it isn't worth an effort? [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php?max=5&start=869 [2] http://source.winehq.org/git/?p=wine.git;a=commit;h=130a0e4f41e8f3c38194273… [3] http://lists.freedesktop.org/archives/fontconfig/2005-June/001377.html

3 2

Re: DNSAPI: implement DnsQuery_UTF8 (review only)
by Juan Lang 12 Apr '06

12 Apr '06

+ if (options & DNS_QUERY_NO_NETBT) + FIXME( "option DNS_QUERY_NO_NETBT not implemented\n" ); In fact, you do support this. You don't support the lack of it. That is, you don't call NetBIOS() to do a name lookup if it isn't specified. I'm not sure you really want to though. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 6

RE: IDE with Winemaker
by Ng, Billy H CIV NAVSEA 12 Apr '06

12 Apr '06

In KDevelop, did you set up a new project your ddraw test app? If so, which type did you pick? Thanks. -----Original Message----- From: Stefan Dِsinger [mailto:stefandoesinger@gmx.at] Sent: Thursday, March 23, 2006 9:27 To: wine-devel(a)winehq.org; Ng, Billy H CIV NAVSEA Subject: Re: IDE with Winemaker Hi, > Hi, I am a Windows Developer who is new to the Linux world. Is there any > IDE (like Visio Studio) I can use with Winemaker? I am trying to port a > Windows App to Linux Fedora. I managed to use wineg++ with kdevelop by overriding the compiler. It worked quite well for my needs(code a ddraw test app), but I don't know if it works for bigger apps. Just set a CC="winegcc", CXX="wineg++" and LINK="winegcc" (??) environment variable in the projekt options. There isn't any IDE which offers an editor for the resource files, so you have to edit them by hand.

2 1

Re: Protect some DIB functions from bad inputs.
by Rein Klazes 12 Apr '06

12 Apr '06

On Tue, 11 Apr 2006 10:24:14 +0200, you wrote: >> Hi, >> >> There are a couple of entries in the bug database (at least #4334 and >> #4664) where the application calculates a wrong pointer for bitmap data. >> The application survives on Windows but crashes on wine. >> >> >> Changelog: >> dlls/x11drv : dib.c >> dlls/gdi/tests : bitmap.c >> Protect the Set/Stretch DIBitfunctions from accessing bad bitmap data. >> Add some tests that would crash without that. >> > >Hello, > >I'm sorry if writing to you directly is not right thing to do, I was >advised so on #wine-hq. > >I would just like to ask you why this patch didn't get merged to git >(and subsequently to 0.9.11) and if there is anything I can do to get it >in in time for 0.9.12? I have no idea why it was not merged, never got any comments. Cc' ed to the developers list for suggestions. A re-diffed patch is attached. Rein

6 6

re: Wine fonts too big for their input fields.
by Dan Kegel 12 Apr '06

12 Apr '06

Duane Clark wrote: >I also have an installer (for Xilinx) that exhibits this problem. I >created a small application that creates a single line edit control >(which is what the Xilinx installer uses). I notice that on Win2k the >EM_GETMARGINS message returns zero for left and right messages, but on >Wine it returns 2 for both margins. Would that be suitable for use as a conformance test? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Wine won't show any characters after the first run
by David D. Hagood 12 Apr '06

12 Apr '06

I'm having a strange problem with Wine - it will not show any characters in any windows, UNLESS I delete Wine's registry files - then it will show characters for the first program run, but no other programs thereafter (including repeat runs of the first program). So, for example, I can run "winecfg" and it will show the config window, with 2 rows of tabs, but no text anywhere. If I then delete ~/.wine/*.reg and re-run winecfg, it will show the characters, and interestingly enough it will place the tabs in one long row rather than 2 rows. If I then run, say, regedit, it will NOT show any characters at all. If I exit winecfg and re-run it, it will now show no characters, and it will place the tabs into 2 rows. I've run it with WINEDEBUG=+font and don't see anything screamingly obvious in terms of errors. This is with a fresh full checkout from CVS as of yesterday (11 Apr 2006), built, and installed (after removing /usr/include/wine, /usr/lib/wine, and /usr/bin/wine*), under SuSE 9.3. Soooo - any suggestions for things to look for?

1 0

Problem with explorer desktop and PAINT messages
by Jesse Allen 12 Apr '06

12 Apr '06

Hi, There is a problem with explorer managing the desktop and the sending of PAINT messages. I've narrowed it down to the following area. In dlls/user/message.c wait_message_reply(), if QS_PAINT are the bits we get, and we call MsgWaitForMultipleObjectsEx, it seems to block the process indefinitely. Should another process be replying here? I decided to make the function return if we get QS_PAINT. Now my app doesn't hang and paints properly. Any ideas what I should be looking for or know? Note the call MsgWaitForMultipleObjectsEx waits for sent messages. Changing it makes no difference. Thanks, Jesse --- wine-current/dlls/user/message.c 2006-03-30 19:37:06.000000000 -0700 +++ wine/dlls/user/message.c 2006-04-09 18:47:14.000000000 -0700 @@ -2136,7 +2136,7 @@ static void wait_message_reply( UINT fla } SERVER_END_REQ; - if (wake_bits & QS_SMRESULT) return; /* got a result */ + if (wake_bits & (QS_SMRESULT | QS_PAINT)) return; /* got a result */ if (wake_bits & QS_SENDMESSAGE) { /* Process the sent message immediately */

2 7

Re: Problem with explorer desktop and PAINT messages
by Fabian Cenedese 12 Apr '06

12 Apr '06

>Ok, I'm not sure about it waiting for that event. The call is >0009:Call kernel32.WaitForSingleObject(00000048,ffffffff) ret=00401c00 > >Anyway I wrote a test app, showwindow.c. It is available on >ftp://resnet.dnip.net . The relay log is there too. The test app tries >to mimic the calls I see. I tested under wine and it does hang. I >will see about windows. I don't know if I did it right. I created an empty Win32 application with VC6, added your file, added an #include <stdio.h> for printf and compiled it successfully. Upon running a window shortly flashes up and the program ends, but no messages are printed to the command window. Most important thing I guess is that it didn't hang. bye Fabi

2 2

DDraw/DX7 over WineD3D: Regression
by "Alexander N. Sørnes" 12 Apr '06

12 Apr '06

Hello, I have found that the DDraw/DirectX 7 over WineD3D patch introduces a regression. Heroes of Might and Magic IV now displays a menu in the upper area of the screen, something it is only supposed to do in windowed mode. The game is then moved a little down, so the bottom of the screen disappears. If the game's resolution is changed, it displays correctly, but if it then is changed back to the resolution it had when it started, the menu appears again. How it works with current CVS http://appdb.winehq.org/screenshots.php?appId=1229&versionId=1638 How it works with the patch http://www.thehandofagony.com/alex/winepics/heroes4_regression.png Regards, Alexander N. Sørnes

1 0

re: RFC/PATCH: Twain + Gphoto
by Dan Kegel 12 Apr '06

12 Apr '06

Marcus wrote: > I have started adding gphoto2 support to twain.dll. Sounds good. I'm mildly surprised twain doesn't support libgphoto2 as a backend already, but whatever... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 5

ARBfp2.0
by Ivan Gyurdiev 12 Apr '06

12 Apr '06

Why does wine write ARBfp2.0 into opengl shaders that originated from DirectX2.0? The shaders I'm seeing all use commands currently available to us [ no branches or anything like that ], but are marked v2.0. As a result the ARB extension fails on them every single time (invalid header - ARBfp2.0), while it could work.

3 2

getwinegit.sh 0.33 released! (final version)
by Christian Lachner 12 Apr '06

12 Apr '06

In this Release I changed all the stuff i was annoyed of. Here the changes: 0.33 We are now also able to load a config-file... - Optional Config-File Support! The Internal Config-Area still exists. I created an example-config and a colorless one for all who don't want a colorful output - Better handling of multiple process protection for the script - Better Checks for set variables I don't plan to develop for getwinegit.sh any longer. It is now feature-complete and ate enough of time. It was nice to learn, what scripting is able to do. I hope that getwinegit.sh is useful to the community - yes, i use it quite often. If there are serious problems, I will fix them. So why isn't this release called 1.0? I don't have the time to test. The Users should report bugs and someone should fix them. I also saw, that my script is not used by much people so maybe there wont be a single bug found in the future. Whatsoever, thanks for taking the time reading this and have much fun with the script. (wow, 22K. it was never meant to grow that much) chris

1 1

bug when compiling wine on cygwin
by Alexander 12 Apr '06

12 Apr '06

Hello! Yesterday I downloaded wine-0.9.11 sources and tried to compile it on cygwin with gcc-4.1.0. './configure' and 'make depend' completed successfully, but I make wine failed - GCC C compiler rejected kthread.c: ---------------- kthread.c:93: error: field 'res_state' has incomplete type kthread.c: In function '__res_state': kthread.c:144: warning: control reaches end of non-void function make[1]: *** [kthread.o] Error 1 make[1]: Leaving directory `/cygdrive/d/GnuProjects/wine-0.9.11/loader' make: *** [loader] Error 2 ---------------- I attached full log to this message. Please, help me fix it and build wine on cygwin. -- Best regards, Alexander mailto:a.shabanov@geovid.com

1 0

setupapi.dll updated by reactos
by Detlef Riekenberg 11 Apr '06

11 Apr '06

Hi. Hervé Poussineau (hpoussin) anounced today on #winehackers, that he did some updates (LGPL) on our "setupapi.dll" - codebase for reactos. So when you have an Installer / Application, that needs more from "setupapi.dll", this hint my help. -- By By ... ... Detlef

2 1

Re: crypt32: fix a typo
by Juan Lang 11 Apr '06

11 Apr '06

> Why ruin perfectly good formatting? This eliminates a line-wrap in my 80-col editor, and makes it consistent with the rest of the file, and indeed with the rest of the DLL. Plus, it's my file. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

Re: WineD3D: Add a resource dumper
by Stefan Dösinger 11 Apr '06

11 Apr '06

Hi, Just a question: Why are the signatures of some of the mails I send to wine-patches broken? It doesn't happen with all mails, approx. every fifth signature is incorrect. The signatures of the same mails in the sent mail folder are correct. Is there something that modifies some mails, but not all? I can't find any modifications in the contents of the mails, so I don't think it's an attack. Stefan

1 0

Re: winspool: [3/4] Implement AddMonitor
by Alexandre Julliard 11 Apr '06

11 Apr '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > + if (RegOpenKeyExW(hroot, mi2w->pName, 0, KEY_READ, &hentry) == ERROR_SUCCESS) { > + TRACE("monitor %s already exists\n", debugstr_w(mi2w->pName)); > + /* NT: ERROR_PRINT_MONITOR_ALREADY_INSTALLED (3006) > + 9x: ERROR_ALREADY_EXISTS (183) */ > + SetLastError(ERROR_PRINT_MONITOR_ALREADY_INSTALLED); > + goto addmW_cleanup; > + } > + else > + { > + if(RegCreateKeyW(hroot, mi2w->pName, &hentry) == ERROR_SUCCESS) { > + INT len; > + len = (lstrlenW(mi2w->pDLLName) +1) * sizeof(WCHAR); > + res = (RegSetValueExW(hentry, DriverW, 0, > + REG_SZ, (LPBYTE) mi2w->pDLLName, len) == ERROR_SUCCESS); > + } > + } There's a race here, you should use RegCreateKeyExW and check the returned disposition. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: WLDAP32: improve error handling in create_page_control()
by Alexandre Julliard 11 Apr '06

11 Apr '06

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog > Improve error handling in create_page_control(). This doesn't build for me (LDAP_MAXINT is not defined). -- Alexandre Julliard julliard(a)winehq.org

1 0

CJK Font aren´t shown properly
by vikas goswami 11 Apr '06

11 Apr '06

I am facing problems when i used chinese system with wine the text on dialog boxes or menus... are not shown properly.. --- Vikas Goswami __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com

1 0

Re: crypt32: fix a typo
by Dimi Paun 11 Apr '06

11 Apr '06

On Mon, 2006-04-10 at 21:05 -0700, Juan Lang wrote: > - ret = CryptGetProvParam(hProv, PP_CONTAINER, (BYTE *)szContainer, > - &size, 0); > + ret = CryptGetProvParam(hProv, PP_CONTAINER, > + (BYTE *)szContainer, &size, 0); > if (ret) > { > len = MultiByteToWideChar(CP_ACP, 0, szContainer, -1, > @@ -761,7 +761,8 @@ > > if (szProvider) > { > - ret = CryptGetProvParam(hProv, PP_NAME, (BYTE *)szProvider, &size, 0); > + ret = CryptGetProvParam(hProv, PP_NAME, (BYTE *)szProvider, > + &size, 0); > if (ret) Why ruin perfectly good formatting? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: coverity: fix some pseudoleaks
by Dimi Paun 11 Apr '06

11 Apr '06

On Mon, 2006-04-10 at 21:21 -0700, Juan Lang wrote: > Oops, should have looked at the other error reports too. This fixes > the others it reports in winegcc, and supercedes my last email. I'm afraid this is a waste of time. winegcc 'leaks' memory by design, it's a short lived program, there's no point in worrying to much about it. For example, strmake() allocates memory every time, and we almost never free it. And no, we shouldn't fix that -- it would clutter the code quite a bit for zero-benefit. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Re: exdisp.idl: Added missing attributes.
by Robert Shearman 10 Apr '06

10 Apr '06

Jacek Caban wrote: >+ >+ [id(0x60020004), hidden, helpstring("Register a pending open with the list")] >+ HRESULT RegisterPending( >+ [in] long lThreadId, >+ [in] VARIANT *pvarloc, >+ [in] VARIANT *pvarlocRoot, >+ [in] int swClass, >+ [out] long *plCookie); >+ >+ [id(0x60020005), hidden, helpstring("Remove a window from the list")] >+ HRESULT Revoke([in] long lCookie); >+ >+ [id(0x60020006), hidden, helpstring("Notifies the new location")] >+ HRESULT OnNavigate([in] long lCookie, [in] VARIANT *pvarLoc); >+ >+ [id(0x60020007), hidden, helpstring("Notifies the activation")] >+ HRESULT OnActivated([in] long lCookie, [in] VARIANT_BOOL fActive); >+ >+ [id(0x60020008), hidden, helpstring("Find the window based on the location")] >+ HRESULT FindWindowSW( >+ [in] VARIANT *pvarLoc, >+ [in] VARIANT *pvarLocRoot, >+ [in] int swClass, >+ [out] long *phwnd, >+ [in] int swfwOptions, >+ [out, retval] IDispatch **ppdispOut); >+ >+ [id(0x60020009), hidden, helpstring("Notifies on creation and frame name set")] >+ HRESULT OnCreated([in] long lCookie, [in] IUnknown *punk); >+ >+ [id(0x6002000a), hidden, helpstring("Used by IExplore to register different processes")] >+ HRESULT ProcessAttachDetach([in] VARIANT_BOOL fAttach); > } > Are these helpstrings an exact copy of what is in native? If so, I don't think we want them in Wine (and they are only useful to VB programmers anyway). Also, IDs with the 0x60000000 flag are ones generated by the IDL compiler, hence they don't need to be added in the IDL. -- Rob Shearman

2 1

Re: [WINED3D] Map D3DFMT_L16, D3DFMT_A16B16G16R16 to OpenGL formats
by Jason Green 10 Apr '06

10 Apr '06

On 4/10/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > Map: > > D3DFMT_L16 -> GL_LUMINANCE16_EXT > D3DFMT_A16B16G16R16 -> GL_RGBA16_EXT > as Raphael suggested. Assuming this mapping is correct, you should also add these formats here: http://source.winehq.org/git/?p=wine.git;a=blob;h=056c6fb76dd770c03655b7973… (though, that whole part of the file could use some work) And, possibly here: http://source.winehq.org/git/?p=wine.git;a=blob;h=f1868cdb3de16e9bb49f11706…

2 1

Re: Alexandre Julliard : twain_32: Renamed the dlls/twain directory to dlls/ twain_32.
by Dimi Paun 10 Apr '06

10 Apr '06

On Mon, 2006-04-10 at 13:47 -0500, Alexandre Julliard wrote: > twain_32: Renamed the dlls/twain directory to dlls/twain_32. Cool! I guess we're only left with the big 3: gdi/kernel/user. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 3

DirectDraw status
by Stefan Dösinger 10 Apr '06

10 Apr '06

Hello, I thought I'd give an overview of the status of the ddraw merge. Well, basically it's progressing nicely, and the first huge part of the merge has been done. The necessary type changes were made to include/wine/wined3d_types.h and include/wine/wined3d_interface.h, so ddraw can now use the wined3d interface header. I have uploaded an updated patch against Wine from yesterday, 23:30 to my website( http://stud4.tuwien.ac.at/~e0526822/ ). It contains a few fixes, like yet another refcounting cleanup( Ihope that this works fine now :) ), and the performance issue on my radeon card, as well as the mipmap issues(all cards) are fixed :) What is next? I will send patches which create the new WineD3D methods needed for ddraw. These patches won't contain the implementation, but just the entry in the vtable and a stub function. So if someone disagrees with a method, then we don't have to discuss about the bare existance of a method and it's implementation at the same time :) Additionally, I will now start writing a lot of test cases for all DirectX versions, with an eye for reference counting, in hope that we can fix the refcounting crashes finally. I have a test for some unimplemented functions in my local tree too, like ProcessVertices. Once the function stabs are in, and the tests show where we have to go to, I'll send the implementation of the functions. After that, all that is left is to merge the ddraw.dll code, but first some regression testing has to be done. I'll ask then for some testing help here and at wine-users, so we can catch regressions before they can occur :) Thanks for all the help with testing and coding so far :) Stefan

4 4

Re: [PATCH] [WineDump]: fake dlls
by Alexandre Julliard 10 Apr '06

10 Apr '06

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > - now that setupapi generates fake DLLs, add the recognition of > those in winedump I think this should go in pe_dump, it's really PE-specific, the generic code doesn't need to know about it. -- Alexandre Julliard julliard(a)winehq.org

1 0

Missing fonts
by "Alexander N. Sørnes" 10 Apr '06

10 Apr '06

Hello, I have found some font problems recently with Wine. First of all, the text of most richedit objects started displaying as rectangles since around Wine 0.9.9, and now, with current CVS, no text is displayed in applications witht the standard Windows interface (like winecfg, wordpad, message boxes etc.) on some systems. While the first issue occurs on all systems I have tested, the second one does not. On a system with only the free corefonts installed, the text is missing; while on a system with all Windows/MS Office fonts, it is displayed fine. What are the new default fonts? Is the first system misconfigured, or does Wine only use non-downloadable Windows fonts now? Regards, Alexander N. Sørnes

12 25

Wine tarball patched with DDraw/DX7 over WineD3D patches
by Alexander N. Sørnes 10 Apr '06

10 Apr '06

I have made a tarball with Wine CVS patched with the DirectDraw/DirectX 7 over WineD3D patches so it is easier to test/use. Feel free to link to the page. http://www.thehandofagony.com/alex/wine-wd3dp/ The patches fixes the redrawing problems for Warlords Battlecry, and the animations in Stronghold: Crusader are now smooth instead of jerky. Screenshot from Warlords Battlecry http://appdb.winehq.org/screenshots.php?appId=2686&versionId=3913 Regards, Alexander N. Sørnes

3 2

Re: [PATCH 1/3] winedos: better MSCDEX emulation
by Petr Tesarik 10 Apr '06

10 Apr '06

Hi everyone, has this patch been rejected? If so, could anyone tell me why? Yes, I know that neither the API, nor the include files are ideal yet, but fixing it would produce a really huge patch, which is AFAIK something you don't like at all. Anyway, with this patch and my other patches applied (including one to the Linux kernel, which was accepted in 2.6.15), I can now run Kindler Literaturlexikon with Wine. And I'd enjoy adding that application to the appdb. Petr Dne 03/31/06 v 14:29:38 (+0200), Petr Tesarik napsal(a): > Hi, > > while I was trying to make Kindler Literaturlexikon work in Wine, I > found out that this program uses a DOS program to access the CDROM, > and that it requires a real working MSCDEX device driver (and not only > that, the driver has to reside in a different segment than the DOS > core). > > To make the patches as small as possible, I've split the patch into > several parts. > > This part just moves some declarations from devices.c to dosexe.h, so > that the code in devices.c can be used from other source files. > > ChangeLog: > > * dlls/winedos/devices.c, dlls/winedos/dosexe.h: > winedos: move some declarations to the header file

2 3

Patch submission
by n1iic Jason Greene 10 Apr '06

10 Apr '06

Greetings. I am a new Linux user, and I would like to request a patch addition to add functionality for a game. The information can be found at http://wiki.minegoboom.com/index.php/Running_Continuum_under_Wine I think for the people that want to learn Linux, applying the patch is a great exercise, like I found. Unfortunately, it is long and involved and might scare off those that have less confidence or don't have a guru handy, but still want to try. I originally sent this to the wine-patches list and the owner recommended that I send it here. Thanks Jason

3 2

Wine tarball patched with DDraw/DX7 over WineD3D patches
by Alexander Nicolaysen Sørnes 10 Apr '06

10 Apr '06

I have made a tarball with Wine CVS patched with the DirectDraw/DirectX 7 over WineD3D patches so it is easier to test/use. Feel free to link to the page. http://www.thehandofagony.com/alex/wine-wd3dp/ The patches fixes the redrawing problems for Warlords Battlecry, and the animations in Stronghold: Crusader are now smooth instead of jerky. Screenshot from Warlords Battlecry http://appdb.winehq.org/screenshots.php?appId=2686&versionId=3913 Regards, Alexander N. Sørnes

1 0

Re: Missing fonts
by Alexander N. Sørnes 10 Apr '06

10 Apr '06

Vitaliy Margolen skrev: >Sunday, April 9, 2006, 4:15:22 PM, Alexander N. Sørnes wrote: > > > >I'm sorry, but are you reading this mailing list at all? To sum it up: >1. You need fontforge. >2. You need _working_ fontforge. >3. You need Wine's fonts made with working fontforge. > >Same thing for freetype. > >Vitaliy > > First of all, I am very sorry if I sent a message in ignorance. But wasn't the FontForge stuff introduced before 0.9.11? Compiling and running 0.9.11 works fine, but doing the same for CVS does not. > > > > >

1 0

Wine tarball patched with DDraw/DX7 over WineD3D patches
by "Alexander N. Sørnes" 10 Apr '06

10 Apr '06

I have made a tarball with Wine CVS patched with the DirectDraw/DirectX 7 over WineD3D patches so it is easier to test/use. Feel free to link to the page. http://www.thehandofagony.com/alex/wine-wd3dp/ The patches fixes the redrawing problems for Warlords Battlecry, and the animations in Stronghold: Crusader are now smooth instead of jerky. Screenshot from Warlords Battlecry http://appdb.winehq.org/screenshots.php?appId=2686&versionId=3913 Regards, Alexander N. Sørnes

1 0

Wine tarball patched with DDraw/DX7 over WineD3D patches
by "Alexander N. Sørnes" 10 Apr '06

10 Apr '06

I have made a tarball with Wine CVS patched with the DirectDraw/DirectX 7 over WineD3D patches so it is easier to test/use. Feel free to link to the page. http://www.thehandofagony.com/alex/wine-wd3dp/ The patches fixes the redrawing problems for Warlords Battlecry, and the animations in Stronghold: Crusader are now smooth instead of jerky. Screenshot from Warlords Battlecry http://appdb.winehq.org/screenshots.php?appId=2686&versionId=3913 Regards, Alexander N. Sørnes

1 0

DDraw over WineD3D - Indexed colour visuals
by Adam Luchjenbroers 10 Apr '06

10 Apr '06

I've been using and tracking Stefan Dossinger's work re: DDraw over WineD3D and decided try and find out if IWineD3DSurface was far enough along to be able to be used in place of IWineX11Surface for 2d applications (Hopefully to eliminate depth conversion issues). Short answer, no. Long answer, Screen displays blank, trace log shows that glReadPixels at line 615 in wined3d\surface.c (LockRect) is failing with error GL_INVALID_OPERATION. Further investigation reveals that this is because glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably because an indexed colour visual was not available, and this buffer is connected directly to the screen). I figured I'd look to the people already familiar with the WineD3D\DDraw codebase before I tried to figure out my own solution. -- "Most people would rather die than think; in fact, they do so." - Bertrand Russell (1872 - 1970)

3 5

DirectX 7
by Dimi Paun 10 Apr '06

10 Apr '06

Hi folks, I am not up-to-date with the latest DirectX news, can someone please tell me if we have any support for DirectX 7? I have a screensaver (Marine Aquarium) that I would like to run, but it requires DirectX 7. Is there any trick to get it to run? Thanks! -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

4 4

Wine tarball patched with DDraw/DX7 over WineD3D patches
by "Alexander N. Sørnes" 09 Apr '06

09 Apr '06

I have made a tarball with Wine CVS patched with the DirectDraw/DirectX 7 over WineD3D patches so it is easier to test/use. Feel free to link to the page. http://www.thehandofagony.com/alex/wine-wd3dp/ The patches fixes the redrawing problems for Warlords Battlecry, and the animations in Stronghold: Crusader are now smooth instead of jerky. Screenshot from Warlords Battlecry http://appdb.winehq.org/screenshots.php?appId=2686&versionId=3913 Regards, Alexander N. Sørnes

1 0

[x11drv] Fix two clipboard bugs. Fixes BadAtom crash (bug 4601)
by Dan Kegel 09 Apr '06

09 Apr '06

[Is it safe to call intern_atoms() inside the event handler like this?] Changelog: Fix two clipboard problems that caused BadAtom crashes (bug 4601) and caused some clipboard formats to not be exported properly Patch also at http://kegel.com/wine/badatom3.patch if this gets mangled by gmail. dlls/x11drv/clipboard.c | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) Index: dlls/x11drv/clipboard.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/clipboard.c,v retrieving revision 1.51 diff -d -u -r1.51 clipboard.c --- dlls/x11drv/clipboard.c 22 Feb 2006 21:31:52 -0000 1.51 +++ dlls/x11drv/clipboard.c 9 Apr 2006 21:25:15 -0000 @@ -1784,6 +1784,10 @@ if (names) { wine_tsx11_lock(); + /* FIXME: we're at the mercy of the app sending the event here. + * Currently if they send a bogus atom, we will crash. + * We should handle BadAtom errors gracefully in this call. + */ XGetAtomNames( display, atoms, nb_atoms, names ); wine_tsx11_unlock(); for (i = 0; i < nb_atoms; i++) @@ -2790,6 +2794,13 @@ LPWINE_CLIPFORMAT lpFormats; LPWINE_CLIPDATA lpData; + /* Create X atoms for any clipboard types which don't have atoms yet. + * This avoids sending bogus zero atoms. + * Without this, copying might not have access to all clipboard types. + * FIXME: is it safe to call this here? + */ + intern_atoms(); + /* * Count the number of items we wish to expose as selection targets. */ @@ -2804,7 +2815,7 @@ while (lpFormats) { if ((lpFormats->wFormatID == lpData->wFormatID) && - lpFormats->lpDrvExportFunc) + lpFormats->lpDrvExportFunc && lpFormats->drvData) cTargets++; lpFormats = lpFormats->NextFormat; @@ -2832,8 +2843,15 @@ while (lpFormats) { if ((lpFormats->wFormatID == lpData->wFormatID) && - lpFormats->lpDrvExportFunc) - targets[i++] = lpFormats->drvData; + lpFormats->lpDrvExportFunc) { + /* Don't send zeroes, lest receiver choke on XGetAtomName() */ + if (lpFormats->drvData) { + assert(i < cTargets); + targets[i++] = lpFormats->drvData; + } else { + WARN("bug: ignoring zero atom...\n"); + } + } lpFormats = lpFormats->NextFormat; } @@ -2841,6 +2859,7 @@ lpData = lpData->NextData; } while (lpData != ClipData); + assert(i == cTargets); wine_tsx11_lock(); @@ -2849,7 +2868,10 @@ unsigned int i; for ( i = 0; i < cTargets; i++) { - if (targets[i]) + /* intern_atoms() should make these nonzero. + * We checked before adding them to the array, just to be safe. + */ + assert(targets[i]); { char *itemFmtName = XGetAtomName(display, targets[i]); TRACE("\tAtom# %d: Property %ld Type %s\n", i, targets[i], itemFmtName); -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Coverity doing scans of Wine codebase!
by Dan Kegel 09 Apr '06

09 Apr '06

See http://scan.coverity.com/ They say they've found 830 potential bugs - that's quite a few. I haven't seen 'em yet, still waiting for my registration to come through. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

15 27

Wine as Windows Terminal Server?
by Samuel Hunt 09 Apr '06

09 Apr '06

Thought for you all..... Would it be possible to use Wine with a few extra bits to make a kind of Windows Terminal Server? So you login via VNC, and the Wine system prompts you for a username and password, which it authenticates. It then loads up a "desktop", with a fake "Start" menu, that you have things similar to a normal start menu, but more appropriate to a terminal server environment. You then run your programs, but all the I/O is to/from the remote client, and each session is independent of each other, so there can be lots of different clients with different permissions (so admin may have full access to all of the drive, but users have various bits of their "hard drive" read-only and things like that). Would seem to make Wine very useful if that could be done. Then VNC clients simply see a "Windows" desktop, and can do what they want, but all the back-end is Wine and Linux. Sam

3 2

Re: DirectDraw status
by Stefan Dösinger 09 Apr '06

09 Apr '06

Hi, > Too many games are unplayable because of slowness, "Omikron : The Nomad > Soul" is one of them and your patch give me hope to see it working better ( > actually it works with some graphic artifacs, but the in-game menu is > painfully slow ). However i tried your patch and now i get this error box > running demo : "DirectX error : impossible to get the surface attached to > the primary surface". Demo is available here : > http://www.3dgamers.com/dlselect/games/omikron/omikrondemo_full.exe.html Hm. I will download the file when I'm back at the university, but I have holidays now for 2 weeks :) Note that the ddraw merge doen't target a speed improvement for now, and wined3d is a little bit slower than the currect ddraw Direct3D code. So unless you hit a bug in the ddraw code, the performance won't improve. > I've also tested Fallout, it works great, but the fade-in/out problem isn't > completely "gone" : no more slowness but no more fade effect too :). > > Later i'll test more games, should i forward you results on this ML ? Yeah, report them to wine-devel. But I'm afraid that most d3d games, except the ones I tried will fail for now. Thanks for the report, Stefan

1 0

Re: winedbg: resend: analyse far calls in be_i386_is_func_call
by Eric Pouech 09 Apr '06

09 Apr '06

Jeff L wrote: > Fixes some things Eric pointed out. Have not tested the far calls as I > don't have anything that generates them. > > This patch came about when I was looking at why single stepping seemed > to stuff up after a call. It breaks down the calls for 32 bit mode > calls but not necessarily 16 and not 64 bit calls. It is a fairly messy > area of knowledge and I could do with assistance as to how the 16/32/64 > bit modes work. > > Change log: Add code to analyse far calls in be_i386_is_func_call > instead of only near calls. > > Jeff Latimer a lot of things still look wrong to me... - first of all, a lot of code should be factorized - the callee should really be filled with the way the address of the call is stored in the insn (for example, you return a modeflat for a relative call from a 16 bit segment...) - lots of computation for negative displacements are wrong - segment is always expressed as an unsigned short (even in ADDRESS structure), so you shouldn't convert it to an int... - ... A+ > > Index: programs/winedbg/be_i386.c > =================================================================== > RCS file: /home/wine/wine/programs/winedbg/be_i386.c,v > retrieving revision 1.6 > diff -u -r1.6 be_i386.c > --- programs/winedbg/be_i386.c 21 Mar 2006 19:22:51 -0000 1.6 > +++ programs/winedbg/be_i386.c 8 Apr 2006 14:30:45 -0000 > @@ -380,28 +380,243 @@ > > static unsigned be_i386_is_func_call(const void* insn, ADDRESS* callee) > { > +#define f_mod(byte) ((byte)>>6) > +#define f_reg(byte) (((byte)>>3)&0x7) > +#define f_rm(byte) ((byte)&0x7) > BYTE ch; > - int delta; > + BYTE mod, reg, rm; > + BYTE delta8; > + short delta16; > + int delta = 0; > + int segment = 0; > + unsigned short segment16; > > if (!dbg_read_memory(insn, &ch, sizeof(ch))) return FALSE; > switch (ch) > { > - case 0xe8: > - dbg_read_memory((const char*)insn + 1, &delta, sizeof(delta)); > - > + case 0xe8: /* Call near, relative to next instruction */ > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, dbg_context.SegCs); > + if (callee->Mode == AddrMode1616) { > + if (!dbg_read_memory((const char*)insn + 1, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; in this case, the callee should be kept as AddrMode1616, not in flat mode. you shouldn't either crop delta to a 16 bit value, especially it's wrong when delta is negative > + } else { > + if (!dbg_read_memory((const char*)insn + 1, &delta, sizeof(delta))) > + return FALSE; > + } > callee->Mode = AddrModeFlat; > callee->Offset = (DWORD)insn; > - be_i386_disasm_one_insn(callee, FALSE); > + be_i386_disasm_one_insn(callee, FALSE); > callee->Offset += delta; > > return TRUE; > - case 0xff: > + > + case 0xff: /* Call far, absolute address */ > if (!dbg_read_memory((const char*)insn + 1, &ch, sizeof(ch))) > return FALSE; > - ch &= 0x38; > - if (ch != 0x10 && ch != 0x18) return FALSE; > - /* fall through */ > - case 0x9a: > + rm = f_rm(ch); /* Extract ModR/M byte */ > + reg = f_reg(ch); > + mod = f_mod(ch); > + if (reg != 0x02 && reg != 0x03) return FALSE; > + if (reg == 0x02) { /* Same segment */ > + switch(mod) > + { > + case 0x00: /* Register operand */ > + callee->Mode = AddrModeFlat; > + switch (rm) > + { > + case 0x00: > + delta = dbg_context.Ebx + dbg_context.Esi; > + break; > + case 0x01: > + delta = dbg_context.Ebx + dbg_context.Edi; > + break; > + case 0x02: > + delta = dbg_context.Ebp + dbg_context.Esi; > + break; > + case 0x03: > + delta = dbg_context.Ebp + dbg_context.Edi; > + break; > + case 0x04: > + delta = dbg_context.Esi; > + break; > + case 0x05: > + delta = dbg_context.Edi; > + break; > + case 0x06: > + if (!dbg_read_memory((const char*)insn + 2, &delta, sizeof(2))) /* disp16 */ > + return FALSE; this is ugly. it'll work but, it would be cleaner to make it with reading delta16 (as a short), then cast the short to an int > + break; > + case 0x07: > + delta = dbg_context.Ebx; > + break; > + } > + break; > + case 0x01: /* Disp8 operand */ > + callee->Mode = AddrModeFlat; > + if (!dbg_read_memory((const char*)insn + 2, &delta8, sizeof(delta8))) > + return FALSE; > + delta = delta8; > + switch (rm) > + { > + case 0x00: > + delta += dbg_context.Ebx + dbg_context.Esi; > + break; > + case 0x01: > + delta += dbg_context.Ebx + dbg_context.Edi; > + break; > + case 0x02: > + delta += dbg_context.Ebp + dbg_context.Esi; > + break; > + case 0x03: > + delta += dbg_context.Ebp + dbg_context.Edi; > + break; > + case 0x04: > + delta += dbg_context.Esi; > + break; > + case 0x05: > + delta += dbg_context.Edi; > + break; > + case 0x06: > + delta += dbg_context.Ebp; > + break; > + case 0x07: > + delta += dbg_context.Ebx; > + break; > + } > + break; > + case 0x02: /* Disp16 or Disp32 bit operand */ > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, dbg_context.SegCs); > + if (callee->Mode == AddrMode1616) { > + if (!dbg_read_memory((const char*)insn + 2, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; > + } else { > + if (!dbg_read_memory((const char*)insn + 2, &delta, sizeof(delta))) > + return FALSE; > + } > + callee->Mode = AddrModeFlat; > + switch (rm) > + { > + case 0x00: > + delta += dbg_context.Ebx + dbg_context.Esi; > + break; > + case 0x01: > + delta += dbg_context.Ebx + dbg_context.Edi; > + break; > + case 0x02: > + delta += dbg_context.Ebp + dbg_context.Esi; > + break; > + case 0x03: > + delta += dbg_context.Ebp + dbg_context.Edi; > + break; > + case 0x04: > + delta += dbg_context.Esi; > + break; > + case 0x05: > + delta += dbg_context.Edi; > + break; > + case 0x06: > + delta += dbg_context.Ebp; > + break; > + case 0x07: > + delta += dbg_context.Ebx; > + break; > + } > + break; > + case 0x03: /* Register operand */ > + callee->Mode = AddrModeFlat; > + switch (rm) > + { > + case 0x00: > + delta = dbg_context.Eax; > + break; > + case 0x01: > + delta = dbg_context.Ecx; > + break; > + case 0x02: > + delta = dbg_context.Edx; > + break; > + case 0x03: > + delta = dbg_context.Ebx; > + break; > + case 0x04: > + delta = dbg_context.Esp; > + break; > + case 0x05: > + delta = dbg_context.Ebp; > + break; > + case 0x06: > + delta = dbg_context.Esi; > + break; > + case 0x07: > + delta = dbg_context.Edi; > + break; > + } > + break; > + default: /* Disp32 bit operand */ > + if (!dbg_read_memory((const char*)insn + 2, &delta, sizeof(delta))) > + return FALSE; > + break; > + } > + > + callee->Offset = delta; > + > + return TRUE; > + } > + else if (reg == 0x03) /* Indirect Far call into other segment */ > + { > + far char * faraddr; you shouldn't need the far here (it brings nothing) > + /* Extract the far address of the indirect address */ > + if (dbg_read_memory((const char*)insn + 2, &faraddr, sizeof(faraddr))) > + return FALSE; > + /* Extract the far address of the callee */ > + if (dbg_read_memory((const char*)faraddr + sizeof(delta), &segment16, sizeof(segment16))) > + return FALSE; > + segment = segment16; > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, (int) &segment); > + if (callee->Mode == AddrMode1616) { > + if (dbg_read_memory((const char*)faraddr, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; > + } else { > + if (dbg_read_memory((const char*)faraddr, &delta, sizeof(delta))) > + return FALSE; > + } > + callee->Mode = AddrMode1632; /* We have made a 32 address so say so */ > + callee->Segment = segment; > + callee->Offset = delta; /* absolute address not an offset */ > + > + return TRUE; > + } > + > + WINE_FIXME("Unsupported yet call insn (0x%02x) at %p\n", ch, insn); > + return FALSE; > + > + case 0x9a: /* Call far, absolute address in operand */ > + if (dbg_read_memory((const char*)insn + 1 + sizeof(delta), &segment16, sizeof(segment16))) > + return FALSE; > + segment = segment16; > + callee->Mode = get_selector_type(dbg_curr_thread->handle, &dbg_context, dbg_context.SegCs); > + if (callee->Mode == AddrMode1616) { > + if (!dbg_read_memory((const char*)insn + 1, &delta16, sizeof(delta16))) > + return FALSE; > + delta = delta16; /* Align to 32 bits */ > + delta &= 0xffff; > + } else { > + if (!dbg_read_memory((const char*)insn + 1, &delta, sizeof(delta))) > + return FALSE; > + } > + > + callee->Mode = AddrMode1632; /* We have made a 32 address so say so */ > + callee->Segment = segment; > + callee->Offset = delta; /* absolute address not an offset */ > + > + return TRUE; > + > case 0xCD: > WINE_FIXME("Unsupported yet call insn (0x%02x) at %p\n", ch, insn); > /* fall through */ > > > ------------------------------------------------------------------------ > > -- Eric Pouech

2 2

winevdm.exe: double free or corruption (fasttop)
by Saulius Krasuckas 09 Apr '06

09 Apr '06

After renewing my wine and running 16-bit app I sometimes get such output in the console (when the app exits): $ ./wine /home/s2/cc/Program\ Files/winled/led2w.exe fixme:toolhelp:InterruptRegister16 (0000, 0x11d700ba), stub. fixme:toolhelp:InterruptUnRegister16 (0000), stub. *** glibc detected *** winevdm.exe: double free or corruption (fasttop): 0x7e014e98 *** ======= Backtrace: ========= /lib/libc.so.6[0x72ad7124] /lib/libc.so.6(__libc_free+0x77)[0x72ad765f] /usr/lib/libGL.so.1[0x67fd5d5e] ======= Memory map: ======== 00000000-00010000 --xp 00000000 00:00 0 00010000-00110000 rwxp 00010000 00:00 0 00110000-20000000 --xp 00110000 00:00 0 20000000-2001a000 r-xp 00000000 03:09 64133 /lib/ld-2.3.5.so (Full logs go attached) Now I wonder whether this is a bug in wine (winevdm possibly), in my glibc (v2.53.5-10.3 from FC4) or in libGL (brought by nVidia driver v1.0-8178-pkg2) ? Last time I got this is now, with last GIT commit date: Sat, 8 Apr 2006 18:03:59 +0000 (20:03 +0200). Any ideas how to determine the nature of bug?

1 0

Pixel Shader questions
by Ivan Gyurdiev 09 Apr '06

09 Apr '06

1) The following pixel shader opcodes appear to be implemented with fragment_ARB, yet they are marked REQUIRE_GLSL. This generates errors, and they are skipped. Is this intentional? D3DSIO_TEX (texld), D3DSIO_CND, D3DSIO_CMP. 2) D3DSIO_CMP appears incorrect according to info online - the Opengl CMP should check >0, while the DirectX checks >= 0. 3) Is there a point at storing the OpenGL code in this large table? I don't like how for half the codes wined3d attempts to map them 1:1 to an opengl code via this table, and for the other half it doesn't use this field at all [ because it can't, combinations are necessary ]. Why not get rid of the field completely? 4) Wined3d likes to print out comment tokens as a FIXME - can this be downgraded to a TRACE? 5) The d3d9 pixel shader relay says (Disabled) - this is misleading, the shaders are enabled. ========== I want to figure out why HL2 doesn't work - enabling the codes above does not seem to help (but looking at the generated shader output, it makes make more sense). HL2 has severe texturing, lighting, and sound problems with hardware shaders (and it's slow and unusable with the software ones).

2 3

more Recommended Packages for Debian
by Corey McClymonds 09 Apr '06

09 Apr '06

Hi, For the recommended packages wiki page, there are a couple of packages that aren't included in that: libicu34-dev libssl-dev giflib3g-dev libxxf86vm-dev libxxf86dga-dev. Relatedly, I can't compile, because I get an error about openGL: checking for glXCreateContext in -lGL... no configure: error: /usr/X11R6/lib/libGL.a is present on your system. This prevents linking to OpenGL. Delete the file and restart configure. Apparently it only shows this if glXCreateContext isn't found, yet xlibmesa-gl-dev has this function. How can I get configure to see it? Corey

1 0

Repeatable BadAtom, valgrind errors; find in notepad broken
by Dan Kegel 09 Apr '06

09 Apr '06

Well, I switched to Dapper Drake Flight 6, but the X errors persist. I can reproduce them trivially tonight on my laptop by hitting Find in wine's Notepad (I was trying to reproduce http://bugs.winehq.org/show_bug.cgi?id=1614). The errors look like X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 and now that winedbg is working again (yay), setting WINEDEBUG=+synchronous generates a good backtrace: 3 0x7f231cea _XError+0xf4 in libx11.so.6 (0x7f231cea) 4 0x7f23229e _XReply+0x185 in libx11.so.6 (0x7f23229e) 5 0x7f212c7d XGetAtomNames+0x131 in libx11.so.6 (0x7f212c7d) 6 0x7f315cfd X11DRV_CLIPBOARD_InsertSelectionProperties+0x17b(properties=<register not in topmost frame>) [/home/dank/wine/dlls/x11drv/clipboard.c:1788] in winex11 (0x7f315cfd) 7 0x7f3182ae X11DRV_CLIPBOARD_UpdateCache+0x3e6(lpcbinfo=<register not in topmost frame>) [/home/dank/wine/dlls/x11drv/clipboard.c:1911] in winex11 (0x7f3182ae) 8 0x7f3187a8 X11DRV_IsClipboardFormatAvailable+0x28(wFormat=0x1) [/home/dank/wine/dlls/x11drv/clipboard.c:2498] in winex11 (0x7f3187a8) 9 0x7f6c30f9 IsClipboardFormatAvailable+0x25(wFormat=0x1) [/home/dank/wine/dlls/user/clipboard.c:583] in user32 (0x7f6c30f9) 10 0x7fb84488 NOTEPAD_WndProc+0x2e8(hWnd=0x70124, msg=0x117, wParam=0x1e0, lParam=0x2) [/home/dank/wine/programs/notepad/main.c:160] in notepad (0x7fb84488) Turning on +clipboard makes the error go away, so I guess it's a Heisenbug. (Doesn't make find work, though; that's http://bugs.winehq.org/show_bug.cgi?id=1614 ) Running notepad.exe.so under valgrind reveals a few suspicious lines: ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x205EE469: SELECTOR_SetEntries (../../include/wine/library.h:130) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x20604A9C: WOWTHUNK_Init (../../include/wine/library.h:130) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x219EFD36: XcursorImageHash (in /usr/lib/libXcursor.so.1.0.2) ==22697== ==22697== Syscall param write(buf) points to uninitialised byte(s) ==22697== at 0x20000772: (within /lib/ld-2.3.6.so) ==22697== Address 0x213A4EF2 is on thread 1's stack ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x200235AD: wine_ldt_get_entry (../../include/wine/library.h:130) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x2180CC68: X11DRV_KeymapNotify (keyboard.c:1275) ==22697== ==22697== Conditional jump or move depends on uninitialised value(s) ==22697== at 0x2180CC9E: X11DRV_KeymapNotify (keyboard.c:1278) None of the above happen after the ^F, though, so while they look bad, they might not have anything to do with notepad's problems. Time to sleep. I'm posting these notes for my own use later, and in case anyone feels like checking up on any of the BadAtom, valgrind, or 'find in notepad' errors. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 2

Re: Winecfg - ESPERANTO Language Support
by Alexandre Julliard 08 Apr '06

08 Apr '06

f_sophia <f_sophia(a)libero.it> writes: > Hi WINE-Folks... > > Change Log. > autor: Antonio Codazzi > e-mail: f_sophia(a)libero.it > Content: > /programs/winecfg/Eo.rc (Esperanto Language) > New language support Several of your patches don't compile. Please make sure to test against the current tree before submitting. -- Alexandre Julliard julliard(a)winehq.org

1 0

dlls/d3d9/volume.c regression
by Gerald Pfeifer 08 Apr '06

08 Apr '06

The following patch revision 1.20 date: 2006-04-07 15:06:58 +0200; author: julliard; state: Exp; lines: +1 -1 Stefan Dösinger <stefandoesinger(a)gmx.at> wined3d: Add WINED3DBOX to wined3d_types.h. has one, and only one, effect as far as I can tell: it adds a new compiler warning volume.c: In function 'IDirect3DVolume9Impl_LockBox': volume.c:175: warning: passing argument 2 of 'This->wineD3DVolume->lpVtbl->LockBox' from incompatible pointer type both on SUSE Linux 10.0 using GCC 4.0 as well as FreeBSD 5.4 using GCC 3.4. (dlls/d3d9/volumetexture.c has exactly the same problem: 'IDirect3DVolumeTexture9Impl_LockBox': volumetexture.c:191: warning: passing argument 3 of 'This->wineD3DVolumeTexture->lpVtbl->LockBox' from incompatible pointer type.) Would you mind fixing these? Thanks, Gerald

2 1

Coverity first-day results
by Mike Hearn 08 Apr '06

08 Apr '06

Last nights run eliminated 31 defects as flagged by the scanner and added a new REVERSE_INULL in dlls/secur32/tests/main.c. We're now down from 833 to 803. That file hasn't changed since February so it appears the scanner is either still working its way through the code or Coverity are adapting it as it goes so it can cover more of the codebase. If you look at the number of functions scanned in each report it constantly goes up, so it does seem that right now its coverage of the codebase is incomplete. Nonetheless, wiping out 30 in the space of 2 days is not bad going at all! Congrats everybody! Of course a few of these bugs are quite trivial or would be hardly ever encountered, but it's still nice to fix them so they don't clutter up the reports with noise and it's easier to spot the more important ones. thanks -mike

1 0

Re: [coverity] fix dereferencing a potential NULL pointer.
by Dimi Paun 08 Apr '06

08 Apr '06

On Sat, 2006-04-08 at 12:48 +0200, Rein Klazes wrote: > dlls/user : menu.c > Fix dereferencing a potential NULL pointer. This patch seems to be doing more than avoiding a NULL dereference. Also, can you also mention which pointer can be NULL? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

wine-patches archive attachments have strange mime type?
by Dan Kegel 08 Apr '06

08 Apr '06

When I'm looking at the wine-patches archives, e.g. at http://winehq.org/pipermail/wine-patches/2006-April/025521.html and the patch is an attachment, the archive's link to the attachment, e.g. http://www.winehq.org/pipermail/wine-patches/attachments/20060408/64e34006/… can't be displayed by my copy of Firefox; it doesn't recognize the DIFF or PATCH mime types. I tried adding them in /etc/mime.types, and I tried looking for a way to set them in Firefox, but no joy. Should the server be serving these up as mime type text/plain? - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Dogfood gone runny: fonts awful in firefox
by Dan Kegel 08 Apr '06

08 Apr '06

Seems like the recent font patches have caused trouble in both Firefox. In Firefox, I have to install corefonts for text to be legible at all lately. Is this expected? -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 2

Re: Makefile.in: Fix broken ctags/etags-targets
by Alexandre Julliard 08 Apr '06

08 Apr '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > "make etags" and "make ctags" are broken. What's broken about them? -- Alexandre Julliard julliard(a)winehq.org

2 5

Re: PATCH: makedep warning
by Alexandre Julliard 08 Apr '06

08 Apr '06

Marcus Meissner <marcus(a)jet.franken.de> writes: > glibc 2.4 + FS=2 makes it warn on ftruncate result > handling. The result cannot be -1 actually, but > check for it anyway. > > Ciao, Marcus > > Changelog: > Check result of ftruncate(). Please don't do that, it's useless. -- Alexandre Julliard julliard(a)winehq.org

1 0

msvcrt: handle inheritance problem
by qingdoa daoo 08 Apr '06

08 Apr '06

HI all, Recently I have been trying to improve support for some MinGW based IDEs without native msvcrt. Now I am dealing with a problem with standard io handle redirection which prevents output from gcc tools from being piped to IDE message windows. I have been able to find that the problem is related to this patch on dlls/msvcrt/file.c http://cvs.winehq.org/cvsweb/wine/dlls/msvcrt/file.c.diff?r1=1.59&r2=1.60&f… It has a one line changlog saying: Duplicate stdin/stdout handles to avoid closing them when library is unloaded. If I revert file.c to pre-patch state, redirection works fine. But am not sure if there will be unexpected consequences. So I searched the wine-patch and wine-devel archives but didn't find the patch or any discussion about it. Could someone explain what exactly that changelog line means? A simple test program ------------------------------------------------------------------------ #include "stdio.h" #include "process.h" int main(int argc, char* argv[]) { if( argc == 1 ) { char *argv2[] = { argv[0], "foo", NULL }; _spawnv(_P_NOWAIT, argv[0], argv2); } else { puts("This won't print with builtin msvcrt"); } return 0; } --------------------------------- Love cheap thrills? Enjoy PC-to-Phone calls to 30+ countries for just 2¢/min with Yahoo! Messenger with Voice.

1 0

FFXI Winsock Question
by Andres Mejia 08 Apr '06

08 Apr '06

I'm having a problem with staying connected while logged in to the PlayOnline service of FFXI. The only debug message I keep finding is a warning that goes "warn:winsock: WSAErrno errno 4 (Interrupted system call)." I already submitted a bug for this but I'm wondering if there was anymore I could do. What I'm asking is, have I done enough or is there something more that I can do to help with fixing this bug?

1 0

NtProtectVirtualMemory
by Segin 07 Apr '06

07 Apr '06

Could someone clue me in to just what this means and why it is: err:virtual:NtProtectVirtualMemory Unsupported on other process A quick Google comes up that function is undocumented, so I don't have much info on it. From the wine source: if (!is_current_process( process )) { ERR("Unsupported on other process\n"); return STATUS_ACCESS_DENIED; } And that's self explanitory, but why is it "Unsupported on other process"?

5 8

Re: WineD3D: Allow the inclusion of the wined3d headers when the ddraw headers are included
by Alexandre Julliard 07 Apr '06

07 Apr '06

Stefan Dösinger <stefandoesinger(a)gmx.at> writes: >> Alexandre, if you think >> that it should be in the wined3d headers, you can add >> #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24)) >> in line 169 in wined3d_interface.h, or ask me to send a patch for that. > Forget about that, I forgot that wined3d_types is included before that line. > Attached is a patch which creates WINEMAKEFOURCC and uses this. Windows has a MAKEFOURCC in ddraw.h too, probably you should use that instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

server: Fix for possible desktop variable being NULL when set_process_default_desktop is called
by Dan Kegel 07 Apr '06

07 Apr '06

Mike Hearn wrote: >I'm not really convinced a static >analysis can catch things that we "know" cannot happen (eg it'd be a >violation of the X protocol or something) and so rely on them without >explicit checks. To be secure, I think we have to handle X protocol violations, too. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Compiling wine 0.9.11 under solaris 10
by Chiaki 07 Apr '06

07 Apr '06

I am trying to build wine-0.9.11 on a solaris express system (nevada b29). But at the end of compilation, I got link errors in a couple places. (messages are given below.) I followed the guidance at http://www.blastwave.org/wine/winemaking.html I had not known the tips mentioned at http://wiki.jswindle.com/index.php/Installing_Wine#Solaris before I tried compilation, Because I didn't know, instead of disabling some macros as suggested in the above URL, I hacked the source files so that the previously ignored files were compiled under Solaris 10 (or Solaris 11 beta). (I listed some of these into a mail list mentioned at blastware web page [solaris package repository] http://lists.blastwave.org/pipermail/users/2006-April/thread.html when I was tinkering with 0.9.10. The changes are basically the same for the case of 0.9.11 with a few additions now that I have configured 0.9.11 in a slightly different manner from the way 0.9.10 was configured. And the link errors I saw have not changed between 0.9.10 and 0.9.11) Anyway, at the end of compilation, I got link errors in a couple places. ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status These seem to be due to versioning(?) of read/write system call symbols or something. (SUNW seems to be symbol used by SUN to mark symbols coming from their libraries, etc.. It is market symbol for Sun Microsystems. Most of Sun-supplied `packages' for solaris is named like SUNWxyz to denote that they are coming from Sun instead of 3rd parties.) Have anybody seen these link problems before? Are there any workarounds? Or am I using incorrect ld/gas, etc? Tool chain information. $ uname -a SunOS solaris-nv-28-home 5.11 snv_28 i86pc i386 i86pc $ which gcc /usr/sfw/bin/gcc bash-3.00$ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (I have replaced /usr/ccs/bin/ld invoked with the above to be gnu ld instead of the original sun ld.) bash-3.00$ /usr/ccs/bin/ld --version GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. bash-3.00$ The eerors at this stage are only seen for two programs namely wine-kthread and wine-server at this moment. The entire log for the last remaining errors follows here. (Line folding is done by the mailer here, sorry about this.) cd /home/ishikawa/local-src/wine-sources/wine-0.9.11/ bash-3.00$ make -k gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wine-kthread -Wl,--export -dynamic -Wl,--section-start,.interp=0x7bf00400 -Wl,--rpath,\$ORIGIN/`../tools /relpath /usr/local/bin /usr/local/lib` kthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/lo ader *** Error code 1 The following command caused the error: cd loader && make `libdinput.def.a' is up to date. ../../tools/winegcc/winegcc -B../../tools/winebuild -mwindows curses.o dialog .o registry.o user.o wineconsole.o wineconsole_res.res -o wineconsole.exe. so -Wl,--rpath,\$ORIGIN/`../../tools/relpath /usr/local/lib/wine /usr/local/li b` -L../../dlls -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L.. /../libs -lwine -L../../libs/port -lwine_port -lrt -lthread -lsocket -lnsl - lcurses -Wb,-dcomctl32 -Wb,-duser32 -Wb,-dgdi32 gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wineserver -Wl,--rpath,\$ ORIGIN/`../tools/relpath /usr/local/bin /usr/local/lib` atom.o change.o clas s.o clipboard.o console.o context_alpha.o context_i386.o context_powerpc. o context_sparc.o context_x86_64.o debugger.o directory.o event.o fd.o file.o handle.o hook.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o ptrace.o queue.o region.o registry.o request.o sem aphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o sunptrace.o -L. ./libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port -lrt -lthread -lsocket -lnsl ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/se rver *** Error code 1 The following command caused the error: cd server && make make: Warning: Target `all' not remade because of errors bash-3.00$ TIA -- int main(void){int j=2006;/*(c)2006 cishikawa. */ char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\""; char *i ="d>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz"; while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1), (putchar(t[j])));return 0;}/* under GPL */

1 0

Re: [dsound] set default primary buffer sample rate and bits per sample
by Alexandre Julliard 07 Apr '06

07 Apr '06

Robert Reif <reif(a)earthlink.net> writes: > Programs that are written specifically for 2000 and xp don't > bother to set the primary buffer format because it's a noop. However > wine is patterned after win9x and DirectX 7 or > earlier which has a real primary buffer and expects the > program to change the primary buffer format if necessary. > > This patch provides a way to change the primary buffer format > from 22050x8 to an application specific value or a system wide > value for programs that don't. Shouldn't we make it work the win2k way then, instead of requiring users to configure things manually? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: server: Fix for possible desktop variable being NULL when set_process_default_desktop is called
by Alexandre Julliard 07 Apr '06

07 Apr '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > The desktop variable could be NULL when set_process_default_desktop is > called, so check for this. (Found by Coverity). I don't see how this could happen. Did I miss something? -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: buffer check in comdlg
by Robert Shearman 07 Apr '06

07 Apr '06

Aric Stewart wrote: > if(fodInfos->unicode) > { > LPOPENFILENAMEW ofn = fodInfos->ofnInfos; >- strcpyW( ofn->lpstrFile, lpstrPathSpec); >- memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); >+ if (nSizePath+sizeUsed > ofn->nMaxFile) >+ { >+ *((WORD*)ofn->lpstrFile)=nSizePath+sizeUsed; >+ FILEDLG95_Clean(hwnd); >+ EndDialog(hwnd,FALSE); >+ COMDLG32_SetCommDlgExtendedError(FNERR_BUFFERTOOSMALL); >+ return FALSE; >+ } >+ else >+ { >+ strcpyW( ofn->lpstrFile, lpstrPathSpec); >+ memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR) ); >+ } > } > > This formatting doesn't look at all consistent, either with itself or the other code there. -- Rob Shearman

2 1

WineD3D: Add a WINEMAKEFOURCC macro
by Stefan Dösinger 07 Apr '06

07 Apr '06

Hello, Alexandre, if you think > that it should be in the wined3d headers, you can add > #define MAKEFOURCC(a,b,c,d) ((a << 0) | (b << 8) | (c << 16) | (d << 24)) > in line 169 in wined3d_interface.h, or ask me to send a patch for that. Forget about that, I forgot that wined3d_types is included before that line. Attached is a patch which creates WINEMAKEFOURCC and uses this. Changelog: Stefan Dösinger: Add a WINEMAKEFOURCC macro to wined3d_types.h

1 0

Re: advpack: Rewrite get_parameter to be able to handle an empty parameter
by James Hawkins 07 Apr '06

07 Apr '06

On 4/7/06, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Changelog: > * Rewrite get_parameter to be able to handle an empty parameter. > blah Ignore this, because I sent too much in one patch. -- James Hawkins

1 0

new to wine, Guild Wars don't display correctly
by BONNEL Christophe 07 Apr '06

07 Apr '06

3 6

Re: msi: Use a debug channel to turn on transform debugging. (Coverity)
by Alexandre Julliard 07 Apr '06

07 Apr '06

Mike McCormack <mike(a)codeweavers.com> writes: > --- a/dlls/msi/table.c > +++ b/dlls/msi/table.c > @@ -1604,13 +1604,12 @@ static MSIRECORD *msi_get_transform_reco > USHORT mask = *rawdata++; > MSICOLUMNINFO *columns = tv->columns; > MSIRECORD *rec; > - const int debug_transform = 0; > > rec = MSI_CreateRecord( tv->num_cols ); > if( !rec ) > return rec; > > - if( debug_transform ) MESSAGE("row -> "); > + if( TRACE_ON(msidb) ) MESSAGE("row -> "); You should use TRACE instead of MESSAGE then, it will be a lot more readable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: x11drv: (bug 4685) properly handle VK_LMENU input (resend)
by Dmitry Timoshkov 07 Apr '06

07 Apr '06

<tkho(a)ucla.edu> wrote: A couple of suggestions about coding style: > +struct transition_s { > + BYTE wVk; It would be more logical to use WORD for VK codes as everywhere else. > + BYTE before_state; > + BYTE _todo_wine; > +}; Same for _todo_wine, it should be BOOL. > + > +struct sendinput_test_s { > + WORD wVk; > + DWORD dwFlags; > + struct transition_s expected_transitions[MAXKEYEVENTS+1]; > + UINT expected_messages[MAXKEYMESSAGES+1]; > +} sendinput_test[] = { > + /* test ALT+F */ > + {VK_LMENU, 0, {{0x12, 0x00, 0}, {0xa4, 0x00, 0}, {0}}, {0x104, 0}}, > + {'F', 0, {{0x46, 0x00, 0}, {0}}, {0x104, 0x106, 0x112, 0}}, > + {'F', KEYEVENTF_KEYUP, {{0x46, 0x80, 0}, {0}}, {0x105, 0}}, > + {VK_LMENU, KEYEVENTF_KEYUP, {{0x12, 0x80, 0}, {0xa4, 0x80, 0}, {0}}, > + {0x101, 0}}, Please use VK names and symbolic message names in the above arrays to make them more readable. > /*********************************************************************** > * X11DRV_send_keyboard_input > @@ -1128,14 +1141,16 @@ > { > message = WM_KEYUP; > if ((key_state_table[VK_MENU] & 0x80) && > - ((wVk == VK_MENU) || (wVk == VK_CONTROL) || !(key_state_table[VK_CONTROL] & 0x80))) > + ((VkStripLR(wVk) == VK_MENU) || (VkStripLR(wVk) == VK_CONTROL) > + || !(key_state_table[VK_CONTROL] & 0x80))) > { > if( TrackSysKey == VK_MENU || /* <ALT>-down/<ALT>-up sequence */ > - (wVk != VK_MENU)) /* <ALT>-down...<something else>-up */ > + (VkStripLR(wVk) != VK_MENU)) /* <ALT>-down...<something else>-up */ > message = WM_SYSKEYUP; > TrackSysKey = 0; > } > key_state_table[wVk] &= ~0x80; > + key_state_table[VkStripLR(wVk)] &= ~0x80; > keylp.lp1.previous = 1; > keylp.lp1.transition = 1; > } > @@ -1145,12 +1160,13 @@ > keylp.lp1.transition = 0; > if (!(key_state_table[wVk] & 0x80)) key_state_table[wVk] ^= 0x01; > key_state_table[wVk] |= 0xc0; > + key_state_table[VkStripLR(wVk)] |= 0xc0; > > message = WM_KEYDOWN; > if ((key_state_table[VK_MENU] & 0x80) && !(key_state_table[VK_CONTROL] & 0x80)) > { > message = WM_SYSKEYDOWN; > - TrackSysKey = wVk; > + TrackSysKey = VkStripLR(wVk); It would be much simpler to call VkStripLR() only once and use the result for further processing. -- Dmitry.

1 0

Compiling wine 0.9.11 under solaris 10
by Chiaki 07 Apr '06

07 Apr '06

I am trying to build wine-0.9.11 on a solaris express system (nevada b29). But the end of compilation, I got link errors in a couple places. (messages are given below.) I followed the guidance at http://www.blastwave.org/wine/winemaking.html I had not known the tips mentioned at http://wiki.jswindle.com/index.php/Installing_Wine#Solaris before I tried compilation, Because I didn't know, instead of disabling some macros as suggested in the above URL, I hacked the source files so that the previously ignored files were compiled under Solaris 10 (or Solaris 11 beta). (I listed some of these into a mail list mentioned at blastware web page [solaris package repository] http://lists.blastwave.org/pipermail/users/2006-April/thread.html when I was tinkering with 0.9.10. The changes are basically the same for the case of 0.9.11 with a few additions now that I have configured 0.9.11 in a slightly different manner as was done for 0.9.10 mentioned in the above link. And the link errors I saw have not changed between 0.9.10 and 0.9.11) Anyway, at the end of compilation, I got link errors in a couple places. ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status These seem to be due to versioning(?) of read/write system call symbols or something. (SUNW seems to be symbol used by SUN to mark symbols coming from their libraries, etc.. It is market symbol for Sun Microsystems. Most of Sun-supplied `packages' for solaris is named like SUNWxyz to denote that they are coming from Sun instead of 3rd parties.) Have anybody seen these link problems before? Are there any workarounds? Or am I using incorrect ld/gas, etc? Tool chain information. $ uname -a SunOS solaris-nv-28-home 5.11 snv_28 i86pc i386 i86pc $ which gcc /usr/sfw/bin/gcc bash-3.00$ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-20050802) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (I have replaced /usr/ccs/bin/ld invoked with the above to be gnu ld instead of the original sun ld.) bash-3.00$ /usr/ccs/bin/ld --version GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. bash-3.00$ There are only seen for two programs namely wine-kthread and wine-server at this moment. The entire log for the last remaining erros follows here. (Line folding is done by the mailer here, sorry about this.) cd /home/ishikawa/local-src/wine-sources/wine-0.9.11/ bash-3.00$ make -k gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wine-kthread -Wl,--export -dynamic -Wl,--section-start,.interp=0x7bf00400 -Wl,--rpath,\$ORIGIN/`../tools /relpath /usr/local/bin /usr/local/lib` kthread.o main.o -L../libs/wine -lwine -L../libs/port -lwine_port ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/lo ader *** Error code 1 The following command caused the error: cd loader && make `libdinput.def.a' is up to date. ../../tools/winegcc/winegcc -B../../tools/winebuild -mwindows curses.o dialog .o registry.o user.o wineconsole.o wineconsole_res.res -o wineconsole.exe. so -Wl,--rpath,\$ORIGIN/`../../tools/relpath /usr/local/lib/wine /usr/local/li b` -L../../dlls -lcomctl32 -luser32 -lgdi32 -ladvapi32 -lkernel32 -lntdll -L.. /../libs -lwine -L../../libs/port -lwine_port -lrt -lthread -lsocket -lnsl - lcurses -Wb,-dcomctl32 -Wb,-duser32 -Wb,-dgdi32 gcc -I/opt/csw/include/freetype2 -L/opt/csw/lib/ -o wineserver -Wl,--rpath,\$ ORIGIN/`../tools/relpath /usr/local/bin /usr/local/lib` atom.o change.o clas s.o clipboard.o console.o context_alpha.o context_i386.o context_powerpc. o context_sparc.o context_x86_64.o debugger.o directory.o event.o fd.o file.o handle.o hook.o mailslot.o main.o mapping.o mutex.o named_pipe.o object.o process.o ptrace.o queue.o region.o registry.o request.o sem aphore.o serial.o signal.o snapshot.o sock.o symlink.o thread.o timer.o token.o trace.o unicode.o user.o window.o winstation.o sunptrace.o -L. ./libs/wine -lwine -L../libs/unicode -lwine_unicode -L../libs/port -lwine_port -lrt -lthread -lsocket -lnsl ../libs/wine/libwine.so: undefined reference to `write(a)SUNW_0.9' ../libs/wine/libwine.so: undefined reference to `read(a)SUNW_0.9' collect2: ld returned 1 exit status *** Error code 1 make: Warning: Target `all' not remade because of errors Current working directory /home/ishikawa/local-src/wine-sources/wine-0.9.11/se rver *** Error code 1 The following command caused the error: cd server && make make: Warning: Target `all' not remade because of errors bash-3.00$ TIA -- int main(void){int j=2006;/*(c)2006 cishikawa. */ char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\""; char *i ="d>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz"; while(*i)((j+=(int)strchr(t,*i++)-(int)t),(j%=sizeof t-1), (putchar(t[j])));return 0;}/* under GPL */

1 0

Coverity Open Source Defect Scan of Wine
by Ben Chelf 07 Apr '06

07 Apr '06

Hello Wine Developers, As some of you may have heard, last month Coverity set up http://scan.coverity.com as a site dedicated to scanning open source projects for defects. In just 1 month, over 4500 defects have been examined by various open source developers, and from what we can tell, it seems that there have been over 2500 patches to the scanned code bases! Due to popular request, I’m happy to announce that we’ve added Wine to the list of projects scanned on the site. For those of you not familiar with "scan" yet and by way of introduction ... I'm the CTO of Coverity, Inc., a company that has technology that performs static source code analysis to look for defects in code. You may have heard of us or of our technology from its days at Stanford (the "Stanford Checker"). The reason I'm writing is because we have set up a framework internally to continually scan open source projects and provide the results of our analysis back to the developers of those projects. To see the results of the project, check out: http://scan.coverity.com My belief is that we (Coverity) must reach out to the developers of these packages (you) in order to make progress in actually fixing the defects that we happen to find, so this is my first step in that mission. Of course, I think Coverity technology is great, but I want to hear what you think and that's why I worked with folks at Coverity to put this infrastructure in place. The process is simple -- it checks out your code each night from your repository and scans it so you can always see the latest results. Right now, we're guarding access to the actual defects that we report for a couple of reasons: (1) We think that you, as developers of Wine, should have the chance to look at the defects we find to patch them before random other folks get to see what we found and (2) From a support perspective, we want to make sure that we have the appropriate time to engage with those who want to use the results to fix the code. Because of this second point, I'd ask that if you are interested in really digging into the results a bit further for your project, please have a couple of core maintainers and/or developers reach out to us to request access. As this is a new process for us and still involves a small number of packages, I want to make sure that I personally can be involved with the activity that is generated from this effort. So I'm basically asking for people who want to play around with some cool new technology to help make source code better. If this interests you, please feel free to register on our site or email me directly. And of course, if there are other packages you care about that aren't currently on the list, I want to know about those too. If this is the wrong list, my sincerest apologies and please let me know where would be a more appropriate forum for this type of message. Many thanks for reading this far... -ben Ben Chelf Chief Technology Officer Coverity, Inc.

2 1

Building in Unicode mode
by Sergio 06 Apr '06

06 Apr '06

Hi, I am trying to compile something that needs to be compiled defining UNICODE and _UNICODE but I am getting this error: In file included from plugins/yapp/../../include/m_database.h:67, from plugins/yapp/stdafx.h:39, from plugins/yapp/options.cpp:1: /usr/include/wine/windows/tchar.h:27:2: error: #error You must use msvcrt when building in Unicode/MBCS mode I tried defining __WINE_USE_MSVCRT but it did not help. Does anyone have any idea of how to solve this problem? Thank you in advance. Sergio.

1 0

Re: [coverity] Don't close uninitialized handle on VXD error path
by Andrey Turkin 06 Apr '06

06 Apr '06

I thought INVALID_HANDLE_VALUE==-1 and not 0. Moreover, I can't see any code path leading to ERR where handle is allocated (or assigned to) at all so I think there is no need to close it. Mike Hearn wrote: > Mike Hearn <mike(a)plan99.net> > Don't close uninitialized handle on VXD error path > > diff --git a/dlls/kernel/vxd.c b/dlls/kernel/vxd.c > index 5d16684..2a004a0 100644 > --- a/dlls/kernel/vxd.c > +++ b/dlls/kernel/vxd.c > @@ -179,7 +179,7 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR > { > static const WCHAR dotVxDW[] = {'.','v','x','d',0}; > int i; > - HANDLE handle; > + HANDLE handle = INVALID_HANDLE_VALUE; > HMODULE module; > WCHAR *p, name[16]; > > @@ -254,10 +254,14 @@ HANDLE VXD_Open( LPCWSTR filenameW, DWOR > } > > ERR("too many open VxD modules, please report\n" ); > - CloseHandle( handle ); > + > + if (handle) > + { > + CloseHandle( handle ); > + handle = 0; > + } > FreeLibrary( module ); > - handle = 0; > - > + > done: > RtlLeaveCriticalSection( &vxd_section ); > if (!DuplicateHandle( GetCurrentProcess(), handle, GetCurrentProcess(), &handle, 0, > > >

1 0

strange win in 2006 SourceForge.net Community Choice Awards
by Marcus Meissner 06 Apr '06

06 Apr '06

Hi, The 2006 SourceForge.net Community Choice Awards have been announced ... and it seems the Desktop Winner is: "WINE ..... for Darwin and Mac OS X" Strangely enough, our project directly does not appear to be listed at all in the "Desktop" category. Still considering whether to be sad or happy. I have now added us to the "Desktop environment" category. Ciao, Marcus

1 0

Re: fonts: Add the Won sign in place of the backslash for Korean fonts
by Huw D M Davies 06 Apr '06

06 Apr '06

On Thu, Apr 06, 2006 at 12:45:01PM +0100, Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > fonts: Add the Won Sign in place of the backslash for Korean fonts Actually could you ignore this for the moment? Dmitry's got a patch that's about to arrive that'll clash with this, and this one is much easier to regenerate. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Invisible fonts regression
by Ivan Gyurdiev 06 Apr '06

06 Apr '06

I am no longer able to see fonts in: - the GTA installer - for example on the intial screen ("What language to use?") - Steam (*with* Tahoma previously installed and working). When selecting menus fonts will flash quickly making the menu visible, and then disappear. In addition, when re-creating a new clean wine root, I also lose the ability to see fonts in winecfg. This is Wine 0.9.11 on Fedora Rawhide x86_64. There is no error output. The Steam problem was in the last release as well. What should I do to track down the problem?

5 8

SimCity 4 and hardware rendering -- Not working.
by Segin 06 Apr '06

06 Apr '06

As usual, I went out and found something else to test. SimCity 4 Deluxe works, impeckably well, but it only does software rendering (which can literally bring your system to it's knees). I use a patched .exe cause the default one didn't work for me (and this one has a no-cd deal, plus is smaller). Anyways, when starting in Direct3D mode, it goes to a back window, but quickly flashes back to your desktop, with this debug: err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (0000000a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (0000000b) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (0000000c) value : 0000000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK (0000000d) value : ffffffff ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL (00000010) value : 00000001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0000001e) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS (00000028) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (00000030) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (0000008a) value : 00000000 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (00000097) value : 00000000 ! It then resumes loading in software rendering.

3 2

WINE & Microsoft WGA
by Marcus Meissner 06 Apr '06

06 Apr '06

Hi, Just found by random websearch... http://www.microsoft.com/genuine/downloads/FAQ.aspx?displaylang=en ... Q: Will systems running WINE pass WGA validation? A: Wine is an implementation of the Windows 3.x and Win32 APIs on top of X and Unix. When WGA validation detects WINE running on the system, it will notify users that they are running non-genuine Windows, and it will not allow genuine Windows downloads for that system. Users of WINE should consult the WINE community for WINE updates. It is important to note that WINE users, and other users of non-genuine Windows, can continue to download updates for most Microsoft applications from Microsoft application-specific sites, such as Office Update. Ciao, Marcus

3 2

EU CVS server is not up to date
by Berend Reitsma 05 Apr '06

05 Apr '06

Hello, The EU CVS server is not up to date. The head of the Changelog is 1.110 while on cvs.winehq it is 1.111. $ cvs -n -d:pserver:cvs@rhlx01.fht-esslingen.de:/home/wine -q log ChangeLog | head RCS file: /home/wine/wine/ChangeLog,v Working file: ChangeLog head: 1.110 branch: locks: strict access list: symbolic names: Wine-0_9_10: 1.110 Wine-0_9_9: 1.109 Regards, Berend.

1 0

[opengl] Another possible fix for the BadMatch error
by Leon Freitag 05 Apr '06

05 Apr '06

> The BadMatch in X_GLXCreateGLXPixmap is another problem.. here you > should get a BadMatch in X_GLXMakeCurrent. That's true, this patch should only fix the BadMatches in glXMakeCurrent. > BadMatch in X_GLXCreateGLXPixmap is a known problem, I've submitted a > patch but it was rejected. Well, try to resubmit it :) Or post it here, so that others could test it. Perhaps you could merge this one-liner into it and then resubmit it. Leon

2 5

Problem cloning wine repository with git...
by Scott Bambrough 05 Apr '06

05 Apr '06

I'm having trouble cloning the wine repository. I attempt to clone it and never get any files. All I ever see is: $ git clone http://source.winehq.org/git/wine.git wine-git defaulting to local storage area I've followed the instructions found here: http://wiki.winehq.org/GitWine I've tried the following commands in an attempt to clone the wine repository: git clone git://source.winehq.org/git/wine.git wine-git git clone http://source.winehq.org/git/wine.git wine-git I'm using git version 1.0.4. I've also tried the latest version of the getwinegit.sh shell script with the same results. I've managed to use git to clone the kernel and git source trees, so git is working on my system. I started the clone of the wine source and let it run over lunch for an hour with no files. If anyone has an idea of what I'm doing wrong, or how to debug the problem I'd appreciate the help. I'm a git newbie. Cheers, Scott

2 2

Re: Alexandre Julliard : configure: Filter out garbage from arts-config --libs too.
by Marcus Meissner 05 Apr '06

05 Apr '06

On Tue, Apr 04, 2006 at 05:37:44AM -0500, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 197a7d0422b2dd60009e405bc254ca616327fbf0 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=197a7d0422b2dd60009e405… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Tue Apr 4 12:08:30 2006 +0200 > > configure: Filter out garbage from arts-config --libs too. > > --- > > configure | 9 ++++++++- > configure.ac | 9 ++++++++- > 2 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/configure b/configure > index 9bffafd..c825171 100755 > --- a/configure > +++ b/configure > @@ -10855,7 +10855,14 @@ then > -I*) ARTSC_CFLAGS="$ARTSC_CFLAGS $i";; > esac > done > - ARTSC_LIBS=`$ARTSCCONFIG --libs` > + ARTSC_LIBS="" > + for i in `$ARTSCCONFIG --libs` > + do > + case "$i" in > + -L/usr/lib|-L/usr/lib64) ;; > + -L*|-l*) ARTSC_LIBS="$ARTSC_LIBS $i";; > + esac > + done It also adds -L/opt/kde/lib64 for me, so this will likely not fully work. I would say we just do not configure arts and esd on 64->32 compiles. :/ Ciao, Marcus

2 4

Re: [PATCH] - rewrote toolhelp implementation only on top of ntdll functions
by Alexandre Julliard 05 Apr '06

05 Apr '06

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > + l = min(ldr_mod[i].BaseDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szModule, ldr_mod[i].BaseDllName.Buffer, l); > + mod->szModule[l / sizeof(WCHAR)] = '\0'; > + l = min(ldr_mod[i].FullDllName.Length, sizeof(mod->szModule) - sizeof(WCHAR)); > + memcpy(mod->szExePath, ldr_mod[i].FullDllName.Buffer, l); This can't work, the dll name and path are in the address space of the target process. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wined3d/OpenGL question
by Jason Green 05 Apr '06

05 Apr '06

I may be barking up the wrong tree here, but I'm trying to debug the cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in drawprim.c (line 1251). This is for Civilization 4 using both hardware vertex & pixel shaders. I've only noticed this error when it is passed GL_TRIANGLES with a large number of vertices. Here's a sample output with a little extra debugging info, and cleaned up a little: trace:d3d_draw:primitiveToGl TRIANGLES trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, number of vertices1156 trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, number of vertices1156 ... trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader trace:d3d_draw:drawPrimitiveDrawStrided glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok drawprim.c / 1846 trace:d3d_draw:drawPrimitiveDrawStrided glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from glDrawRangeElements @ drawprim.c / 1251 Often, a series of these errors will result in an unhandled exception in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 kernel). I read up on the glDrawElements() function and it refered to the GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call that function, it returns 4096, and the number of vertices that it's trying to pass is larger than that. I've tried doing a min() of the max and the actual # of vertices, but the results are the same. So, the question is: Could this be one of the causes of the graphical glitches I'm seeing? I can toy around with these functions all day, but I don't really understand them all that well. Does that routine need to be reworked to split up a D3DPT_TRIANGLELIST into multiple calls if the calculated number of vertices/indices is too high for the user's graphics card? Or, am I way off base thinking this has any bearing on my real issues? Thanks, Jason

3 4

d3d: unhandled texture formats
by Ivan Gyurdiev 05 Apr '06

05 Apr '06

The F.E.A.R and BF2 demos crash immediately after complaining about: fixme:d3d:D3DFmtGetBpp Unhandled fmt(36,WINED3DFMT_A16B16G16R16) fixme:d3d:debug_d3dformat Unrecognized 81 D3DFORMAT! I have some native dlls installed, d3dx9_*.dll, mscoree.dll... that have no wine implementation. According to msdn: D3DFMT_A16B16G16R16 36 64-bit pixel format using 16 bits for each component. D3DFMT_L16 81 16-bit luminance only. The second one is missing from wined3d_private.h Both are missing from D3DFmtGetBpp. Also note that there's default handling in D3DFmtGetBpp that says: /* Guess at the highest value of the above */ and selects 4 bytes per pixel, but the highest value of the above is 8 - and it's used by D3DFMT_A16B16G16R16 - maybe that's why it crashes.

3 4

XVidMode is required for Gamma Control
by Jesse Allen 05 Apr '06

05 Apr '06

I've found that XVidMode is required for gamma control, and that it defaults to off. There are two bug reports about gamma. One is Diablo 2 as it fails to run at all in D3D mode because of it (and with a cryptic error too). The other is the gamma slider fails to produce the effect. There are three ways to fix the problem: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this. 2) Make UseXVidMode default to "Y". 3) Tell people to set UseXVidMode manually. Let me know what any of you think is best. I'd prefer the first one so that I won't have people scratching their heads over what is going on. Though #2 might be more correct than #1. Something should be changed because it's silly that Diablo 2 cannot run by default. Jesse

7 16

Re: wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi 05 Apr '06

05 Apr '06

[ Charset UTF-8 unsupported, converting... ] > hurtta+wine(a)leija.mh.fmi.fi wrote: > > >http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > > > > > > > >>It's OK that most people don't have fontforge installed, that just > >>means that people who can't cope with compiling from source and can't > >>satisfy all the required dependencies to create a working binary > >>shouldn't do it. They need to use a prepackaged one from a > >>confidential source who knows what is needed and how to resolve the > >>dependencies. > >> > >> > > > > > >Perhaps because there is NO binary available on > >list of http://www.winehq.org/site/download > Then they can check their distributions source package tree (pkgsrc, > ports, etc.) or binary tree (which compliments pkgsrc, ports, etc. and > is compatable.) > > I mean, come on, can it be that hard to look in ports? If distribution is 4 years old, wine is also. Distributions works good enough, but 4 year old is little different. Or have you different opinion?

1 0

Re: richedit20: Implement EM_FORMATRANGE
by Phil Krylov 04 Apr '06

04 Apr '06

On Tue, 4 Apr 2006 11:46:18 +1000 Troy Rollo <wine(a)troy.rollo.name> wrote: > + * *** Notes on tables *** > + * > + * The CHARRANGE structure passed in the FORMATRANGE structure is not > + * sufficient to deal with tables, where we would need information on the > + * start position for text in each column of the table. > + * > + * Testing on Windows NT shows that the Microsoft Rich Edit control gives > + * pathological results when there are tables in the document - both in edit > + * mode and for EM_FORMATRANGE. The Microsoft Rich Edit control uses the > + * table solely as a hint to where the paragraph should start. The table > + * does not expand to fit its text. Long paragraphs wrap when you hit the > + * right page margin and continue at the left page margin. This is only true for RichEdit 2.0 - later versions have better table support, while our current implementation is approximately at 2.0 level. -- Ph.

2 1

wine / fontforge regression
by hurtta+wine＠leija.mh.fmi.fi 04 Apr '06

04 Apr '06

http://www.winehq.org/pipermail/wine-devel/2006-April/046196.html > It's OK that most people don't have fontforge installed, that just > means that people who can't cope with compiling from source and can't >satisfy all the required dependencies to create a working binary > shouldn't do it. They need to use a prepackaged one from a > confidential source who knows what is needed and how to resolve the > dependencies. Perhaps because there is NO binary available on list of http://www.winehq.org/site/download / Kari Hurtta

1 0

cvs help for bug #4541, Wine > 20050725 with FreeBSD 6.0
by Lee Parsons 04 Apr '06

04 Apr '06

Hello I submitted the bug #4541 regarding running the application WinMDI on wine in FreeBSD 6.0: http://bugs.winehq.org/show_bug.cgi?id=4541 I have begun regression testing on this bug. I have determined that it seems to break on 20050921, as 0921 works and 0922 does not. However, I have been unable to cvs checkout any particular versions of wine for that day. For example, if I look at the wine-cvs archives for that day, and want to checkout for the patch submitted 05:20:20, I run the command: lparsons@r32_1600$ cvs -d $CVSROOT checkout wine "2005-09-21 05:20 CDT" which ends up returning: cvs checkout: cannot find module `2005-09-21 05:20:20 CDT' - ignored I would like to be able to determine which patch specifically is responsible. Any help with CVS would be useful here. thank you Lee Parsons

2 1

Re: wined3d: Also print the format like a fourcc if unknown in debug_d3dformat.
by Alexandre Julliard 04 Apr '06

04 Apr '06

Jan Zerebecki <jan.wine(a)zerebecki.de> writes: > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -94,7 +94,7 @@ const char* debug_d3dformat(WINED3DFORMA > FMT_TO_STR(WINED3DFMT_CxV8U8); > #undef FMT_TO_STR > default: > - FIXME("Unrecognized %u D3DFORMAT!\n", fmt); > + FIXME("Unrecognized %u (as fourcc: %s) D3DFORMAT!\n", fmt, debugstr_an((CHAR*)&fmt,4)); Using %c%c%c%c as format would be better than a debugstr hack. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: Wined3d/OpenGL question
by James Trotter 04 Apr '06

04 Apr '06

---------- Forwarded message ---------- From: James Trotter <james.trotter(a)gmail.com> Date: Apr 4, 2006 8:16 PM Subject: Re: Wined3d/OpenGL question To: Jason Green <jave27(a)gmail.com> On 4/4/06, Jason Green <jave27(a)gmail.com> wrote: > > I may be barking up the wrong tree here, but I'm trying to debug the > cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in > drawprim.c (line 1251). This is for Civilization 4 using both > hardware vertex & pixel shaders. I've only noticed this error when it > is passed GL_TRIANGLES with a large number of vertices. > > Here's a sample output with a little extra debugging info, and cleaned > up a little: > > trace:d3d_draw:primitiveToGl TRIANGLES > trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144, > number of vertices1156 > trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144, > number of vertices1156 > ... > trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader > trace:d3d_draw:drawPrimitiveDrawStrided > glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok > drawprim.c / 1846 > trace:d3d_draw:drawPrimitiveDrawStrided > glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850 > trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...) > fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from > glDrawRangeElements @ drawprim.c / 1251 > > Often, a series of these errors will result in an unhandled exception > in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1 > kernel). > > I read up on the glDrawElements() function and it refered to the > GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES. When I call > that function, it returns 4096, and the number of vertices that it's > trying to pass is larger than that. I've tried doing a min() of the > max and the actual # of vertices, but the results are the same. > > So, the question is: Could this be one of the causes of the graphical > glitches I'm seeing? I can toy around with these functions all day, > but I don't really understand them all that well. Does that routine > need to be reworked to split up a D3DPT_TRIANGLELIST into multiple > calls if the calculated number of vertices/indices is too high for the > user's graphics card? Or, am I way off base thinking this has any > bearing on my real issues? > > Thanks, > Jason > > > GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES are just performance hints, and not actual limits to how many vertices or indices that the driver can handle. From http://pyopengl.sourceforge.net/documentation/manual/glDrawRangeElements.3G… : "Implementations denote recommended maximum amounts of vertex and index data, which may be queried by calling glGet with argument GL_MAX_ELEMENTS_VERTICES and GL_MAX_ELEMENTS_INDICES. If end - start + 1 is greater than the value of GL_MAX_ELEMENTS_VERTICES, or if count is greater than the value of GL_MAX_ELEMENTS_INDICES, then the call may operate at reduced performance. There is no requirement that all vertices in the range [start,end] be referenced. However, the implementation may partially process unused vertices, reducing performance from what could be achieved with an optimal index set." Also, "GL_INVALID_OPERATION is generated if glDrawRangeElements is executed between the execution of glBegin and the corresponding glEnd."

1 0

wine / fontforge regression
by Molle Bestefich 04 Apr '06

04 Apr '06

Hello, This patch from Mar 9: http://www.winehq.org/pipermail/wine-cvs/2006-March/021502.html causes all applications run with Wine to continually emit: err:font:ReadFontDir Can't open directory "/usr/local/bin/../lib/../share/wine/fonts/" when fontforge isn't installed. Also, take a look at the path above. It's relative to '/usr/local/bin', ok - but why the double descend into the parent directory? The "../lib" seems completely redundant with the "../share" coming right after it. Regards

8 13

Re: compile error
by Tom Spear 04 Apr '06

04 Apr '06

On 4/4/06, MF <mforcada(a)freesurf.ch> wrote: > > Hi Tom, > > After make depend, last lines give this message: > quote > ld: Relocatable linking with relocations from format elf64-x86-64 > (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.UrlAln.o) > is not supported > winebuild: ld -m elf_i386 -r failed with status 256 > winegcc: ../../tools/winebuild/winebuild failed. > unquote Aha! Ok, so make dep and make are failing before they are able to build any of the tools like winecfg and wineprefixcreate... That is due to your 64-bit libraries being installed in the default location, and your 32-bit ones being installed elsewhere.. Do you happen to have a /usr/lib32 directory? If so, try doing the build like this: make distclean LDFLAGS=/usr/lib32 ./configure make dep make sudo make install and then do the wineprefixcreate and run winecfg.. Let us know if you have any problems after that.. Of course if you do have a lib32 dir, but it is not /usr/lib32, substitute the path to your lib32 dir where I put /usr/lib32 (it shouldn't be just /lib32).. Of course someone on the list could tell you the exact path to the directory if you would be so kind as to tell us what distro you are using. :-) Tom

1 0

re: richedit20: Implement EM_FORMATRANGE
by Dan Kegel 04 Apr '06

04 Apr '06

Hi Troy, any chance you can also provide a conformance test, however trivial? (Also, from reading http://discuss.fogcreek.com/joelonsoftware3/default.asp?cmd=show&ixPost=973… http://support.microsoft.com/default.aspx?scid=kb%3Ben%3B129860 http://www.codeproject.com/printing/richeditprint.asp I gather that some but not all apps will also require EM_DISPLAYBAND to make use of this, right? Just curious.) Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

compile error
by MF 04 Apr '06

04 Apr '06

Hi, System: Dell Power Edge 830, Intel Dual Core, Linux Ubuntu 5.10, 64 bits version Tried to compile Wine with the ./tools/wineinstall as per recommended procedure in readme file, from sources package downloaded with apt-get build-dep wine and apt-get --build source wine wich did not go 100% well...: quote Reading package lists... Done Building dependency tree... Done Need to get 13.5MB of source archives. Get:1 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (dsc) [1209B] Get:2 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (tar) [13.5MB] Get:3 http://wine.sourceforge.net source/ wine 0.9.10~winehq1-2 (diff) [47.0kB] Fetched 9537kB in 35s (268kB/s) dpkg-source: extracting wine in wine-0.9.10~winehq1 dpkg-source: unpacking wine_0.9.10~winehq1.orig.tar.gz dpkg-source: applying ./wine_0.9.10~winehq1-2.diff.gz dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.10~winehq1-2 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot dh_testroot: You must run this as root (or use fakeroot). make: *** [clean] Error 1 Build command 'cd wine-0.9.10~winehq1 && dpkg-buildpackage -b -uc' failed. E: Child process failed end quote The directory "wine-0.9.10~winehq1" was created OK and the package source seemed to be there. So I tried "./tools/wineinstall" and got the following message: quote configure: creating cache config.cache checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking whether make sets $(MAKE)... yes checking for gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. Configure failed, aborting install. end quote re-did the whole thing after clean up and tried the dpkg command in sudo and got quote ~/wine-0.9.10~winehq1$ sudo dpkg-buildpackage -b -uc dpkg-buildpackage: source package is wine dpkg-buildpackage: source version is 0.9.10~winehq1-2 dpkg-buildpackage: source changed by Scott Ritchie <scott(a)open-vote.org> dpkg-buildpackage: host architecture amd64 debian/rules clean dh_testdir dh_testroot rm -f build-stamp # Add here commands to clean up after the build process. /usr/bin/make distclean make[1]: Entering directory `/home/formig/wine-0.9.10~winehq1' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/formig/wine-0.9.10~winehq1' make: [clean] Error 2 (ignored) #-/usr/bin/make -C documentation clean dh_clean debian/rules build dh_testdir # Add here commands to configure the package. CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make sets $(MAKE)... yes checking for x86_64-linux-gnu-gcc... gcc -m32 checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make: *** [config.status] Error 77 unquote Seems to be an error with my C compiler ? GCC IS 4:4.0.1-3 I attach config.log for more details. Any idea ? With kindest regards, Miguel

4 5

Re: advpack: Rewrite get_parameter so that it can handle empty parameters [RESEND]
by Alexandre Julliard 04 Apr '06

04 Apr '06

"James Hawkins" <truiken(a)gmail.com> writes: > Changelog: > * Rewrite get_parameter so that it can handle empty parameters. You are still parsing the whole string for every parameter, this is O(n^2) which isn't very nice. What you want is a strtok-style function to retrieve parameters sequentially. -- Alexandre Julliard julliard(a)winehq.org

1 0

Pegasus Mail via Wine
by James E. Lang 04 Apr '06

04 Apr '06

I have been using Pegasus Mail via Wine for nearly two years. Before that I used Pegasus Mail on a Win98 system for several years. Since Wine officially entered Beta category in late 2005, I have tried most of the releases (starting with 0.9.3). Pegasus functioned quite well with Wine Versions 0.9.3, 0.9.5, 0.9.6, 0.9.7, & 0.9.8. Wine Version 0.9.4 was unusable. Wine Versions 0.9.9 and 0.9.10 both sent Pegasus a signal to shut itself down when the message composition window got closed. As Rein Klazes wrote on 11 Mar 06 @ 06:20 re: user32: Handle WM_ENDSESSION in DefWinProc(): > On Fri, 24 Feb 2006 14:29:45 -0600, you wrote: > > Author: Francois Gouget <fgouget(a)codeweavers.com> > > Date: Fri Feb 24 15:34:09 2006 +0100 > > > > user32: Handle WM_ENDSESSION in DefWinProc(). > > DefWinProc() should call PostQuitMessage() on WM_ENDSESSION if the > > shutdown is proceeding. > > Hi Francois, > > This patch is causing a problem in Pegasus Mail. Closing some dialogs > cause termination of the complete program. > Here is a part of SPY++ log when run under win2000, when I close the > edit new mail dialog ... I don't know whether this is fixed in Wine Version 0.9.11 since I cannot get Pegasus Mail to perform any useful function with that version of Wine. With Wine Version 0.9.8 Pegasus Mail would load on my computer and display my list of e-mail folders within 30 seconds. With Wine Version 0.9.11 Pegasus Mail still does not display the folder list after 15 minutes. Pegasus Mail's startup window *does* display for the proper time interval. "Technical" Observations: When I use Wine Version 0.9.8 and use KDE System Guard to view the running processes I see that the process that is running the bash shell that runs Pegasus Mail has one Wine related offspring process ("Wine-preloader") and that offspring uses about 598,000 bytes of RAM. When I use Wine Version 0.9.11 there is that same process but it in turn has an offspring process of its own (also "Wine-preloader") which uses about 41,500 bytes of RAM. During the time that Wine was failing to display the normal things for Pegasus Mail I noticed that the value of VmRss (resident virtual memory?) increased in very small increments (usually 8 bytes at a time) two or three times a minute. The total VmSize (Virtual Memory Size?) value did not change. It is remotely possible that given enough time (measured in hours maybe) that Pegasus Mail would have finally displayed something useful. What I'm trying to say is that I have not been able to use any version of Wine after 0.9.8 to support Pegasus Mail and I'm trying to pass along a description of what I see. I have no debug code activated and do not know what debug options would be appropriate. -- Jim

1 0

[opengl] Another possible fix for the BadMatch error
by Leon Freitag 03 Apr '06

03 Apr '06

Someone mentioned earlier that the code in wgl.c in DescribeDrawable() violates the GLX specification and therefore causes bogus return values for the visualid. However this code has been already present before the regression, but worked somehow. So the regression can't be caused by this violation. I tried to correct this violation by calling glXChooseFBConfig and then glXGetChooseConfigAttrib, as suggested in the spec, and glXChooseFBConfig returns NULL for the appropriate FBCONFIG_ID. However the problem seems to be in getting Drawable which is then passed to DescribeDrawable. The VisualID of the Drawable isn't needed at all, since before calling the glXMakeCurrent, we just want to know if the context visualid differs from visualid of Wine desktop. This one-liner should fix the BadMatch errors. Tested on Warcraft 3. http://winehq.org/pipermail/wine-devel/2006-March/thread.html ------ diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c index c7d3147..e9046ca 100644 --- a/dlls/opengl32/wgl.c +++ b/dlls/opengl32/wgl.c @@ -551,7 +551,7 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, draw_vis_id = describeDrawable(ctx, drawable); ctx_vis_id = describeContext(ctx); - if (-1 == draw_vis_id || (draw_vis_id == visualid && draw_vis_id != ctx_vis_id)) { + if (visualid != ctx_vis_id) { /** * Inherits from root window so reuse desktop visual */ Please test this patch and report if it works. If it works fine (and doesn't introduce any regressions) then I'll submit it to wine-patches. Leon

3 2

Re: winebuild: Add an "x86_64" flag
by Alexandre Julliard 03 Apr '06

03 Apr '06

Robert Shearman <rob(a)codeweavers.com> writes: > ChangeLog: > Add an "x86_64" flag in winebuild so we can export 64-bit-only > functions in a 64-bit build. Are there really enough functions that would need this to justify adding a new flag? -- Alexandre Julliard julliard(a)winehq.org

2 2

AppDB email address obfuscation
by n0dalus 03 Apr '06

03 Apr '06

Hi, I am concerned that the email addresses on the appdb are too easily harvestable. Is there a reason no effort seems to be made to hide the email addresses of users on there? Also, when getting a notification of a post, you can see everyone's email addresses in the To: field. Should these be Bcc? Just curious, n0dalus.

3 2

Re: Implement THREAD_PRIORITY_TIME_CRITICAL
by Andreas Mohr 03 Apr '06

03 Apr '06

Hi, On Fri, Mar 31, 2006 at 02:06:23PM +0100, Mike Hearn wrote: > This patch gives me rock solid audio in Imperium Galactica 2, so now the > game works perfectly. > > There has been discussion around this issue with respect to security in > the past, however, regardless of what approach is adopted this code will > have to be written anyway. Ah, thanks, nice to see that it actually helps. > + scheduler = SCHED_FIFO; IMHO we should really add some smart detection of SCHED_ISO kernel capability and *much* prefer to use that one then. One really wouldn't want to hang the box... Not to mention that SCHED_FIFO requires root, which is an absolute PITA. Nice To Have would be support for stuff such as SCHED_IDLEPRIO and SCHED_BATCH... > + if (result == -EPERM) > + { > + static int need_warning = 1; > + > + if (need_warning) > + { > + fprintf( stderr, "\nwineserver: Failed to promote the priority of a time critical thread.\n" ); > + fprintf( stderr, "Audio may destabilise. To fix this re-run the application as root.\n\n" ); > + need_warning = 0; > + } > + > + return; > + } Make that static int already_warned; /* static: = 0! */ Since static uses 0 as default and you don't want to waste space in the .bss(?) segment for an explicit 1 init. Andreas Mohr -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta (or alternatively buy nicely packaged Linux distros/OSS software to help support Linux developers creating shiny new things for you?)

8 18

Re: [Bug 4979] New: wine .9.11 make fails on AMD64
by Tom Spear (Dustin Booker, Dustin Navea) 03 Apr '06

03 Apr '06

Wine Bugs wrote: > http://bugs.winehq.org/show_bug.cgi?id=4979 > > Summary: wine .9.11 make fails on AMD64 > Product: Wine > Version: 0.9.11. > Platform: PC-x86-64 > OS/Version: Linux > Status: UNCONFIRMED > Severity: normal > Priority: P2 > Component: wine-patches > AssignedTo: wine-bugs(a)winehq.org > ReportedBy: nospam(a)thenerdshow.com > > > Seems like this old bug is back, identical to this one, possibly? > http://www.winehq.com/hypermail/wine-devel/2004/01/0598.html > > Trouble building wine .9.11 & CVS on AMD64. It's linking 64 bit libraries again > :( Passing LDFLAGS="-L/usr/lib" --libdir=/usr/lib to configure doesn't help, > either. > > make[2]: Entering directory `/home/fozner/install/wine/dlls/winmm/winearts' > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -shared > ./winearts.drv.spec arts.o audio.o > -Wl,--rpath,\$ORIGIN/`../../../tools/relpath /usr/local/lib/wine /usr/local/lib` > -o winearts.drv.so -L../../../dlls -lwinmm -luser32 -lkernel32 -lntdll > -L../../../libs -lwine -L/usr/lib64 -ldl -lartsc -lpthread -lgmodule-2.0 -ldl > -lgthread-2.0 -lglib-2.0 -L../../../libs/port -lwine_port > /usr/lib64/libdl.so: could not read symbols: File in wrong format > > Rudimentary regression test: > wine .9.10 works fine with just ./configure && make depend && make. > wine .9.11 fails with above error > Today's CVS also fails. > > I can get it to build with some editing of the makefiles, but that's not the > point of this exercise. > > I figured this was important enough to forward to the list. Alexandre, could (should) there be a --dont-link-64bit-libs flag added to configure please, or maybe a --without-64bit-libs? Tom

3 4

You don't have administrator privileges on this computer ... (whats changed in 0.9.11?)
by Roland Kaser 03 Apr '06

03 Apr '06

Hello I just tried to make my usual test installations on the new 0.9.11 release. But at this time the setup responses (in german) Sie haben keine Verwaltungsprivilegien auf diesem Computer. Setup kann nicht fortgesetzt werden. (You don't have administrator privileges on this computer. Setup cannot be continued..). Can somebody tell me whats happend to the username mapping in 0.9.11 what can I do to avoid those messages? Thanks Roland Kaeser

3 2

What's uuid 33ad4ed2-6699-11cf-b70c-00aa0060d393?
by Dan Kegel 03 Apr '06

03 Apr '06

http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=33ad4… turns up seven apps which fail with errors like fixme:ole:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393} http://www.google.com/search?q=33ad4ed2-6699-11cf-b70c-00aa0060d393 turns up quite a few hits for 33ad4ed2-6699-11cf-b70c-00aa0060d393, but they're all wine errors, no definitions. I presume this UUID is associated with riched20's COM interface, but I don't know how to check. Anyone know? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

linux 2.6.16 and 2G/2G-split
by Sven Köhler 03 Apr '06

03 Apr '06

Hi, i didn't get any response on the user-mailinglist, so i try the devel-list. here's my problem: since i upgraded my kernel to 2.6.16, wine segfaults immediatly after i start it. When i upgraded to 2.6.16, i also chose to use the 2G/2G vmsplit. Is wine supposed to work with that config? Thanks Sven

2 2

Re: winhelp esperanto language update
by Alexandre Julliard 03 Apr '06

03 Apr '06

f_sophia <f_sophia(a)libero.it> writes: > Hi, Folks > > Change Log. > autor: Antonio Codazzi > e-mail: f_sophia(a)libero.it > Content: > /programs/winhelp/Eo.rc (Esperanto language) update n. 2. > - Added "short-cuts" support > > --- Eo.old 2006-03-26 01:56:27.000000000 +0100 > +++ Eo.rc 2006-03-29 00:19:11.000000000 +0200 Please generate patches from the top-level dir, especially for file names that exist in several directories. -- Alexandre Julliard julliard(a)winehq.org

1 0

PATCH: msvcrt: test: Allow environment strings longer than 512 characters
by qingdoa daoo 03 Apr '06

03 Apr '06

Test case added --------------------------------- New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.

1 0

COM programming in assembly, geez...
by Dan Kegel 03 Apr '06

03 Apr '06

While looking for COM documentation for C programmers (i.e. for when you want to do COM without helpers like MFC or ATL), I stumbled across quite a bit for assembly programmers! For the record, here are some of the interesting links on both subjects I ran across tonight: http://ript.net/~spec/ - implementation of COM servers and clients in raw C++. http://thunder.prohosting.com/~asm1/articles/com_1.txt - calling COM in asm http://thunder.prohosting.com/~asm1/articles/com_2.txt - COM objects in asm http://illmob.org/files/text/Accessing%20COM%20Objects%20from%20Assembly.ht… http://www.masmforum.com/ appears to be a bulletin board where quite a few assembers have support forums. http://www.japheth.de/h2incX.html says it's a tool to convert .h files to .inc files. http://www.masmforum.com/simple/index.php?topic=171.0 mentions that MS lets you download masm.exe for free under certain conditions. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Update on Software Freedom Law Center work
by Alexandre Julliard 03 Apr '06

03 Apr '06

Folks, As announced at the last Wineconf, Jeremy and myself have been working for a few months now with the Software Freedom Law Center on a number of legal issues concerning Wine. We've been mostly quiet about it, so I thought I'd post a status update. There are two major tasks going on at the moment: 1. Code audit We are doing an audit of the code base, to make sure we have proper records of all contributions, and spot any potentially troublesome code. The goal is to be able to show to people who don't want to dig through the source that we have done our development properly, and that they can use Wine without fear of legal trouble. Currently, a survey is being sent out to people we have identified as major contributors, so that we can collect some information from them, like employers, license agreements, that sort of thing. This will enable us to build a complete track record for all contributions. We are still processing the results, at this point the responses we received cover approximately half of the code base (many thanks to everybody who took the time to answer!). We'll be sending the survey to more contributors in the near future to try to get as close to 100% coverage as we can. 2. Non-profit organization There are many advantages to having a non-profit organization for a project, for instance to allow tax-exempt donations, or hold assets like trademarks. However it's a lot of paperwork to do, so we never went to the trouble of setting one up. Now the SFLC is starting an organization called the Software Freedom Conservancy, that will be officially launched on Monday. It's basically an umbrella non-profit that provides services to free software projects. By joining that organization, we will get all the advantages of having our own non-profit, without having to do any of the work, so that seems like a good deal... There will also be the possibility of assigning our copyrights to that organization, which would make it easier to enforce the license, and provide some liability protection for developers. However this will only be done if most developers are comfortable with it, so I'd be interested to hear your feedback on this issue. -- Alexandre Julliard julliard(a)winehq.org

7 8

re: wine / fontforge regression
by Dan Kegel 03 Apr '06

03 Apr '06

Molle Bestefich wrote: > This patch from Mar 9: > http://www.winehq.org/pipermail/wine-cvs/2006-March/021502.html > causes all applications run with Wine to continually emit: > err:font:ReadFontDir Can't open directory "/usr/local/bin/../lib/../share/wine/fonts/" > when fontforge isn't installed. I saw one other message complaining about this, so I filed http://bugs.winehq.org/show_bug.cgi?id=4974 so Molle's report doesn't fall through the cracks (doesn't seem likely, but hey). Perhaps the author of that patch can respond there. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

whats wrong with the wine devel list
by Karl Lattimer 02 Apr '06

02 Apr '06

Hi, I am having real issue with this list, I can't distinguish betweeen list mail, other email and spam. Why is there no prefix [wine-devel] in the subject line? Also I don't particularly like the reply-to setup here, can't it just be munged back to the list, rather than replying to an individual? And finally, why does it take half a day for a post I've made to ping back to my email inbox? This list seems to be in some kind of 1990's time warp of usability. Can it be changed? Kind regards, K,

12 16

Re: d3dx: VertexBuffer should keep reference to the parent device object.
by H. Verbeet 02 Apr '06

02 Apr '06

> ChangeLog: > d3dx: VertexBuffer should keep reference to the parent device object. That's probably the best solution for the moment. >+ /* Parent reference */ >+ LPDIRECT3DDEVICE9 parentDevice; However, the name parentDevice is somewhat misleading, in particular considering the meaning of "parent" in wined3d. From the point of view of the d3d8/d3d9 object it's simply the device.

1 0

getwinegit.sh 0.32 released!
by Christian Lachner 02 Apr '06

02 Apr '06

One more Version! It's time to test this script until it is one of the last versions. I don't want to spend more time into this so I desided to soonly quit this project. Here the Changes since 0.31: 0.32 No Changes to Functitonality, but cool stuff :) - Better Trap-handling - Nicer Sleeper-function (I love it) - No output to the shell but only the ones by getwinegit.sh blackbox? no, everything's in the logfile - Some Fixes we all don't want to miss but I don't remeber ;)... again This release should be stable, but I want it to be tested. Tell me, if it is useful to you guys or made problems. Mail to the mailinglist if you have questions or found bugs or want something to be added. chris

1 1

Software Freedom Conservancy
by Jeremy White 02 Apr '06

02 Apr '06

I'd like to start a separate thread on this subject, so we don't lose the chance to discuss this. I think it's a really good idea for us to join. Right now, I manage the finances for 'The Wine Project'. The money literally flows into my personal bank account; I registered a 'Doing Business As' (DBA) in Minnesota so I could take checks and stuff as 'The Wine Project'. It's not tons of money, but the account is now up to about $2400 (which is nice, as our Wineconf fees will be about that much). (Of course, without the embezzling, it'd be much more, but that's the way it goes <grin>). Further, we had a challenge when we needed to manage the money from Google for the Summer of Code. Again, I handled it via CodeWeavers, but it wasn't quite 'right'. So I think it would be better for us to have a professional organization to hold these funds, and to serve as an umbrella organization for us. Candidly, I'm not sure I see any down side. They do all the nasty work, and we get someone to help us out with annoying admin chores. What's not to like? I guess if they prove to be incompetent or unresponsive it could be an issue (like if we send them the $2400 but can never get a check cut). But right now I don't see much risk of that; the SFLC at least has been very responsive (which, considering what we're paying them [$0] is nothing short of miraculous). Anyone else have any objections or other thoughts on it? Cheers, Jeremy

5 4

Re: winedbg: analyse far calls in be_i386_is_func_call
by Eric Pouech 02 Apr '06

02 Apr '06

Jeff L wrote: > This patch came about when I was looking at why single stepping seemed > to stuff up after a call. It breaks down the calls for 32 bit mode > calls but not necessarily 16 and not 64 bit calls. It is a fairly messy > area of knowledge and I could do with assistance as to how the 16/32/64 > bit modes work. > > Change log: Add code to analyse far calls in be_i386_is_func_call > instead of only near calls. > > Jeff Latimer > + switch (rm) > + { > + case 0x00: > + segment = dbg_context.Eax; > + break; > + case 0x01: > + segment = dbg_context.Ecx; > + break; > + case 0x02: > + segment = dbg_context.Edx; > + break; > + case 0x03: > + segment = dbg_context.Ebx; > + break; > + case 0x04: > + break; > + case 0x05: > + segment = dbg_context.Ebp; > + break; > + case 0x06: > + segment = dbg_context.Esi; > + break; > + case 0x07: > + segment = dbg_context.Edi; > + break; > + } this is wrong... this is part of the offset computation, not the segment (as it's an intra-segment call) > + callee->Mode = AddrModeFlat; > + callee->Segment = segment; > + callee->Offset = delta; /* absolute address not an offset */ here you should use a callee->Mode of AddrMode1632 or AddrMode1616, not a flat one basically, you can tell if it's a 16 or 32 bit call depending whether the current cs refers to a 16 or 32 bit selector A+ -- Eric Pouech

1 0

AppDB problem
by Segin 02 Apr '06

02 Apr '06

While changing user prefences, I got this error: Database Error! Query: REPLACE session_list VALUES ('0b7b7e6e2b25056088b212db53619c9c', '', '', 'current|O:4:\"user\":7:{s:7:\"iUserId\";s:5:\"72211\";s:6:\"sEmail\";s:17:\"segin11(a)yahoo.com\";s:9:\"sRealname\";s:0:\"\";s:6:\"sStamp\";s:14:\"20051229230938\";s:12:\"sDateCreated\";s:19:\"2005-07-09 01:45:14\";s:12:\"sWineRelease\";s:8:\"20050524\";s:17:\"bInactivityWarned\";N;}', '', NOW()) Deadlock found when trying to get lock; Try restarting transaction Just thought this was worth reporting.

1 0

Re: Keyboard Rewrite
by Tom Spear 02 Apr '06

02 Apr '06

On 4/1/06, Derek Fawcus <dfawcus(a)cisco.com> wrote: > > On Fri, Mar 31, 2006 at 01:33:18PM -0600, Tom Spear wrote: > > Hi all, this is a call for volunteers. I am hoping that certain > developers > > participating in another thread are willing to rewrite the keyboard > code, > > but we need people to test. If you are interested, please reply here > saying > > that you are interested, and what kind of keyboard you use, as well as > the > > layout you use under X. I will be creating a wiki page for this project > > once the people who will be taking on this rewrite confirm that they > will do > > so, and will post the link to this thread as soon as it is created. > > > > The purpose of this rewrite is to (hopefully) fix all of the problems > people > > have with key mappings, characters not showing up as expected, race > > conditions, characters not showing up at all, etc, and hopefully allow > us to > > close out many of the bugs in bugzilla having to do with the keyboard. > > Well I'd be willing to try, as I have a peculier keyboard layout, and > failed > on my first attempt to hack the wine source to match, it seemed to ignore > what I specified wrt to symbol changes. But then I did not try debugging > it. > > I'm using a UK layout 105 key keyboard, with a few changes that make if > more > like a teminal keyboard, so it is a bit of a weird mix between a USA and > a > UK mapping. Some of the choices derive from the fact that this is plugged > in to a UK layout IBM T40, and so the extra windows are missing when > using > the native keyboard. > > The descriptions below apply to the layout of the external keyboard, not > they > laptop layout. > > The key Marked 'Esc' (to left of F1) generates Backslash (or Bar when > shifted) > > Some of the number row is remapped to be more like the USA/Terminal form: > > Key to left of '1!' (keycode 49) generates Escape (like a proper > terminal) > Shift of '2' gives At (normally Quotedbl) > Shift of '3' gives NumberSign (normally Sterling) > AltGR of '3' gives Sterling > AltGR of '4' gives EuroSign > > I had to change the results generated by keys to the right of 'L' such > that > they made sense. So I also have a bunch of quotes there: > > The key to the right of ';:', marked as "'@', keycode 48 gives the > following: > Unshifted Apostrophe (normal, as marked) > Shifted QuoteDbl (normally At) > AltGR LeftSingleQuoteMark > AltGR+Shift LeftDoubleQuoteMark > The key to the right of that one, marked as "#~', keycode 51 gives the > following: > Unshifted Grave (normally NumberSign) > Shifted AsciiTilde (normal, as marked) > AltGR RightSingleQuoteMark > AltGR+Shift RightDoubleQuoteMark > > Caps Lock (to left of 'A') gives is a duplicate Control_L, and no key > generates Caps Lock > > The key marked '\|' to the right of the left shift key, is a duplicate > Shift_L > The left windows key (between left shift and left alt) generates Super_L > The right windows key (between AltGR and Menu key) generates Super_R > The Menu key (between right windows key and right control key) generates > Alt_R > > The AltGR key is ISO_Level3_Shift, and when shifted is Multi_key. But > I've never > found a use for Multi_key yet. > > DF > Ok. Are these outputs that you are giving us what the keyboard shows under a native app, or what they currently show under wine? What layout do you pick under X? en_US, en_GB, pc105 no dead keys? Thanks Tom

3 2

Re: WineD3D: Do not set the mipmap level count for old textures
by Stefan Dösinger 01 Apr '06

01 Apr '06

Am Samstag, 1. April 2006 19:34 schrieb Stefan Dösinger: > The attached patch stops WineD3D from re-setting the GL_TEXTURE_MAX_LEVEL > texture parameter every time a texture is used. It is not necessary, as the > max level is a property of the texture and not the active unit(according to > Lionel Ulmer). Setting the maximum level causes the 3d driver to dirtify > the texture in the video memory, which has to be reloaded then every time > it is used. > > This patch should greatly increase the performance of most games. (I > noticed an fps improvement of a factor of 5) A small addition here: This case seems to be handled by the nvidia driver already, so the performance improvement applies only to ati cards. I tested this with my mobility radeon 9000 with the open source driver from Xorg7.0 and fglrx 8.23.7

1 0

Direct3D, the kernel and ReactOS
by Stefan Dösinger 01 Apr '06

01 Apr '06

Hello List, I had a talk to the DirectX developers of reactos on their irc channel to discuss how Reactos and Wine can share efforts on DirectX. (Please leave the legal issues asside for now, let us concentrate on the technical part for now). I didn't expect much possibility for a cooperation in such a hw-related thing as DirextX, but Greatlord told me about the gdi / win32k problem Wine is heading to with the current DirectX code. According to Greatlord, Microsoft's DirectX implementation basically consists of a kernel-side part in gdi.dll and win32k.sys, and a user-mode part in ddraw.dll, d3d8.dll and d3d9.dll. The user dlls contain the Hardware emulation layer code, and calls to the kernel for the Hardware abstraction layer. Now that wouldn't be a problem for Wine, as applications are expected to use the user mode dlls, and using the kernel interface is highly discouraged by Microsoft. However, there are a few apps out there which access the kernel interface directly, and Greatlord told me that he knew about a few companies which plan to use it to gain speed improvement. Expectedly, such apps won't work on Wine. My long term suggestion is to move the Direct3D->OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). I know that this is not easy to achieve. The kernel interface is poorly documented, and Greatlord has spent a lot of effort to verify the docs and to write a better documentation of the interface. Apps using the kernel interface should be considered broken, and I don't give them a long lifetime as the interface changes from Windows version to Windows version(According to Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this way and implement the kernel Direct3D interface? If so, I consider this something post-1.0, and we should definitely see what changes Vista brings. Another thing we discussed was DirectInput. ReactOS uses wines dinput.dll, with improvements which gets the sdk demos and some nasty games working. I can see if I can merge the changes to Wine.

8 11

Firefox much faster with 0.9.11?!
by Dan Kegel 01 Apr '06

01 Apr '06

I dunno what y'all did, but Firefox now downloads long mailing list indices much faster than it used to. This dogfood is getting yummier every month. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 1

request for Orkut wine forum manager
by Shachar Shemesh 01 Apr '06

01 Apr '06

Hi all, If you don't know who I am, please do skip the rest of this paragraph. As you well know, I have not been as active on the Wine project as I wish. Unfortunately, this is not going to change much in the near future :-( I am currently the manager of the "Wine" forum on Orkut. I just got an email asking to do some operation (enabling email to members), which clarified to me that, perhaps, my lack of activity is to the disadvantage of the community members. And so, I would like to ask the esteemed members of this list. Is there anyone here who would like to take this responsibility from me? Please be sure to CC me on replies. Thanks, Shachar

1 0

Budget Dedicated has provided us with a server and a ton of free bandwidth
by Scott Ritchie 01 Apr '06

01 Apr '06

Hello folks, Just wanted to let everyone know that I finished setting up the server Budget Dedicated has given us. (http://www.budgetdedicated.com) Currently it's hosting the APT repository: deb http://wine.lowvoice.nl/apt breezy main deb-src http://wine.lowvoice.nl/apt breezy main Now, here's the cool thing: we're not confined by disk space anymore here, so we can host .deb packages in the APT repository for different distributions. This includes backports to Debian Sarge, as well as forward ports to new versions of Ubuntu like Dapper, or even whatever other crazy deb distro we want to package. Budget Dedicated has also given permission for other things to be moved there, such as the Wine website (or parts thereof). The server is super fast and on a very fat pipe in the Netherlands, so for anyone in Europe it'll almost certainly be better to download things from there. For now, however, it's just an APT repository, and the APT repository just has Ubuntu Breezy packages, however it would be very easy to add packages for other distributions or architectures - just send me an email and I can take care of it. Thanks, Scott Ritchie

1 0

Photoshop plugins in Gimp on Linux using Wine!
by Dan Kegel 01 Apr '06

01 Apr '06

I've been hearing rumblings about people using Wine to run windows photoshop plugins on Linux Gimp, but hadn't seen anything concrete. Well, here it is: http://www.gimp.org/~tml/gimp/win32/pspi.html Have a look. Congratulations, Wine! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 12

Re: Software Freedom Conservancy
by Tom Spear (Dustin Booker, Dustin Navea) 01 Apr '06

01 Apr '06

Jeremy White wrote: >> No objection from me.. Although, I should mention that I haven't seen >> much in the way of a link to donate to the project. Theres no link on >> the main page anywhere that I can see. Perhaps the fund would be a >> little bigger if it was easier to find a donate link? >> > > Hmm. On the lower right hand side of the main page is a donate > link, and there is also a donations request on Sourceforge. > > But you raise a good point; feel free to make a suggestion > for how it should change (a patch?) - I'm certainly not opposed. > > (Although the honest truth is that we raise more money than > we need right now, at least for Wine. For CodeWeavers, we can > always use more money :-/) > > Cheers, > > Jeremy > > hmm.. I didn't see that at all lol. I did however notice the contributing link shortly after I sent the last email. I think if we put the donate link (as well as the codeweavers link) on the left just under the search link they might get noticed a little more.. Of course you do raise a good point about raising more money than wine really needs, so on to the next idea... The short answer is that I dont have an idea right now, but I have done some thinking about it.. If you want the long answer, keep reading, else, just click close lol... Obviously codeweavers requires advertising and marketing in order to get new customers. The majority of that advertising so far has been done by the community and word of mouth. The biggest step towards taking codeweavers mainstream is obviously to get more people to switch to linux.. the press has done a decent job of helping us out in that respect, but a lot of people dont read the magazines. I mean I see it all the time on various forums, my favorite being the forum entitled the worst tech support call you have ever made... Someone will get DSL service, and not have a router, and think that it will work out of the box with whatever os they use... So when it doesnt and they cant figure it out, they call dsl tech support, and ask "Do you support Linux?"... Guess what the tech support rep asks 99% of the time... "What is Linux? Is that a new version of Windows?"..... Back to the point though, people dont read magazines or stuff on the internet so they dont know theres an alternative to windows. That means they dont know about cW or crossover. How do we get more users over to Linux? Good question, unfortunately one I don't have an answer for right now. Once we get users to Linux, or maybe even as the hook to get them to switch would be to show them crossover while showing them linux and how not prone to viruses it is, show them internet explorer running under it, or better yet show them stuff like word, excel, and adobe, and then show them firefox and say ok ie is the only app we are going to take away from you.. then the security issues are small (no ie to infect) but they can still use their regular stuff, and their machine will seem more responsive compared to how it ran on windows. I'm sure those are all ideas your people have already had and discussed, but shoot, it would be nice to see some linux based booths at e3 or ces or the revamped comdex once it comes out.. of course the best way to get mainstream is the force your way mainstream, more and better placement on store shelves.. get the stores to start pitching linux and the benefits of using it over windows. then have the rep help them decide on a distro and put them in touch with someone familiar with linux. of course that is all beyond codeweavers and wine's scope, but that is the idea.. get other linux companies to start pushing it more. M$ wants to play hardball? We gotta start predicting their pitches. Tom

1 0

Re: [Bug 1181] Keyboard translation broken: uses raw keycodes
by Peter Åstrand 31 Mar '06

31 Mar '06

On Thu, 30 Mar 2006, Wine Bugs wrote: > http://bugs.winehq.org/show_bug.cgi?id=1181 > > ------- Additional Comments From Speeddymon(a)gmail.com 2006-30-03 10:26 ------- > Peter, I'm not sure if you ever did subscribe to wine-devel, but you did mention > that wine could possibly reuse parts of your keysym implementation. Could you > email the list (even if you dont scubscribe) and let them know about this bug, > and see if anyone is willing to take a look at it. Just make sure you let them > know you aren't subscribed, if you aren't, and to CC you on replies. Hi, now you know about this bug. As the comment says, it might be possible to reuse some parts from the rdesktop implementation. I'm not saying that it will be easy, though. To be honest, I think bug 4923, and many others, are more important. Instead of fixing Wine, it might be possible to enhance Xvnc so that it can "emulate" a physical Xserver with a certain physical keyboard. Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

4 5

Keyboard Rewrite
by Tom Spear 31 Mar '06

31 Mar '06

Hi all, this is a call for volunteers. I am hoping that certain developers participating in another thread are willing to rewrite the keyboard code, but we need people to test. If you are interested, please reply here saying that you are interested, and what kind of keyboard you use, as well as the layout you use under X. I will be creating a wiki page for this project once the people who will be taking on this rewrite confirm that they will do so, and will post the link to this thread as soon as it is created. The purpose of this rewrite is to (hopefully) fix all of the problems people have with key mappings, characters not showing up as expected, race conditions, characters not showing up at all, etc, and hopefully allow us to close out many of the bugs in bugzilla having to do with the keyboard. Thanks all in advance Tom

4 4

getwinegit.sh 0.31 released!
by Christian Lachner 31 Mar '06

31 Mar '06

OK, I'm tired now but this is a new release an it owns ;). It should be quite stable but I didn't test it. So what has changed: 0.31 One more Release, I'm glad about this one - Some smaller an greater Fixes - After Compiling, the Script creates a helperfile to help mode 4 - Sections in Logfile - Trap included to handle ctrl+c - Implemented a small sleeper to give you a chance to stop the script before it starts to clean the source This is one of the last versions. The last version will be called 1.0. (maybe the next one?) If you miss a feature... write to the mailinglist.

1 1

Improper message recursion revealed by recent desktop window changes
by Troy Rollo 31 Mar '06

31 Mar '06

The recent changes to the desktop have revealed a problem with recursive processing of X messages. The problem started to manifest with commit 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack that looks like this: <application Window procedure> WINPROC_wrapper ... CallWindowProcW ... SendMessageW X11DRV_SetWindowPos SetWindowPos X11DRV_ConfigureNotify process_events X11DRV_MsgWaitForMultipleObjectsEx wait_message_reply send_inter_thread_message SendMessageTimeoutW SendMessageW send_parent_notify DestroyWindow In other words, a destroy notification is being sent to the parent window with SendMessageW, and before that message returns an unrelated X message is processed. Under Windows the equivalent could never happen - if a thread is in SendMessage(), the only messages that can be delivered to it are ones sent by SendMessage() from another thread. The consequences of this can be unpleasant if the code that processes (in this case a window movement notification) the message interferes with state that is being dealt with in earlier stack frames. wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, INFINITE, QS_ALLINPUT, 0 ); The brute-force approach of changing this to the following makes the application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to change I thought it best left to people with more familiarity with it. -- Troy Rollo - wine(a)troy.rollo.name

3 4

Re: [RESEND][x11drv] cleanup: Move x11drv escape codes to one common header file.
by Alexandre Julliard 31 Mar '06

31 Mar '06

Tomas Carnecky <tom(a)dbservice.com> writes: > This patch doesn't change any logic or C sourcecode, it only moves the > X11DRV escape code definition to one common header file. Currently the > definitions are spread over several C source files, and even there the > definitions differ from file to file. I don't see anything wrong with > this patch unless you *want* to have it difficult to maintain the code. Actually, that's more or less what we want. That sort of inter-dll dependencies should be strongly discouraged, and we don't want to add more of it than strictly necessary; as far as possible we also don't want dlls to depend on private headers, so copying a few things across is the preferred approach. If it becomes a problem it means something is wrong with our implementation. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: "Unhandled exception: floating point stack check" early in program?
by Petr Tesarik 31 Mar '06

31 Mar '06

Hi, I'm not online too often. :( So, I thought the patch for Linux must already be in CVS. It is not. The patch can be found here: http://www.winehq.org/pipermail/wine-patches/2006-March/025228.html However, the patch only works for Linux. Please, let me know if you're using a different platform, as it is very likely that it can be made to work too, but I won't send patches which I can't test. To the wine-devel list: Why was the patch rejected, anyway? Petr Tesarik On 03/29/06 at 09:35:04 (-0800), Dan Kegel wrote: > On 3/29/06, Petr Tesarik <hat(a)tesarici.cz> wrote: > > No, this is not normal. This problem was introduced on the i386 > > architecture, when floating point registers were added to winedbg. > > Currently, there are two pending patches by me, one which fixes the > > problem on Linux, and another which fixes it on all platforms but is > > most likely wrong. > >... > > Anyway, see also my next email. > > Looking forward to it. > Can you give me the URL of the i386 patche in the wine-patches archive? > Thanks, > Dan >

1 0

[PATCH] Don't enforce process handle access rights in Win98 mode (fixes dcom98 ncalrpc)
by Mike Hearn 31 Mar '06

31 Mar '06

Sending here until wine-patches stops eating my email. IMHO this would best be done in get_obj_from_handle in the server, but this approach is what the registry APIs do and what Rob suggested, so here it is. diff --git a/dlls/kernel/process.c b/dlls/kernel/process.c index 4263a22..d5017c4 100644 --- a/dlls/kernel/process.c +++ b/dlls/kernel/process.c @@ -2265,6 +2265,8 @@ HANDLE WINAPI OpenProcess( DWORD access, attr.SecurityQualityOfService = NULL; attr.ObjectName = NULL; + if (GetVersion() & 0x80000000) access = PROCESS_ALL_ACCESS; + status = NtOpenProcess(&handle, access, &attr, &cid); if (status != STATUS_SUCCESS) {

1 0

winspool: [1/2] implement EnumMonitorsW
by Detlef Riekenberg 31 Mar '06

31 Mar '06

Our Tests will work, when both Patches are in the Tree Changelog: - winspool: implement EnumMonitorsW -- By By ... ... Detlef

1 0

Re: [WIDL] Implement support for unique strings
by Robert Shearman 31 Mar '06

31 Mar '06

Eric Kohl wrote: > Robert Shearman wrote: > >>> case PASS_OUT: >>> + if (in_attr && has_size && pointer_type == RPC_FC_UP && >>> phase == PHASE_FREE) >>> + break; >>> if (!out_attr) >>> continue; >>> break; >>> >>> >> >> I don't think this is correct. Firstly, it should continue, not >> break. Secondly, I think it only doesn't need to free the string if >> it has a size. I'm pretty sure it shouldn't depend on being a unique >> string. >> > > Robert, > this is exactly what I want! WIDL must generate a call to > NdrPointerFree for 'in', 'unique', sized pointers to strings. Other > 'in' pointers don't need to be freed. > > Why? Because three different versions of MIDL do it this way. > Counter-example with the following IDL: void ConformantString2Out([in] long size, [in, out, string, size_is(size)] char **pszString); void Test([in] long size, [in, out, size_is(size)] char **pszArray); Both generate NdrPointerFree calls and I believe both are satisfied by the test you introduced: void __RPC_STUB Tests_ConformantString2Out( PRPC_MESSAGE _pRpcMessage ) { MIDL_STUB_MESSAGE _StubMsg; unsigned char **pszString; long size; RPC_STATUS _Status; ((void)(_Status)); NdrServerInitializeNew( _pRpcMessage, &_StubMsg, &Tests_StubDesc); size = 0; ( unsigned char ** )pszString = 0; RpcTryFinally { RpcTryExcept { if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[44] ); _StubMsg.Buffer = (unsigned char *)(((long)_StubMsg.Buffer + 3) & ~ 0x3); if(_StubMsg.Buffer + 4 > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } size = *(( long * )_StubMsg.Buffer)++; NdrConformantArrayUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char * *)&pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44], (unsigned char)0 ); if(_StubMsg.Buffer > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } } RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } RpcEndExcept ConformantString2Out(size,pszString); _StubMsg.BufferLength = 0; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char *)pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44] ); _pRpcMessage->BufferLength = _StubMsg.BufferLength; _Status = I_RpcGetBuffer( _pRpcMessage ); if ( _Status ) RpcRaiseException( _Status ); _StubMsg.Buffer = (unsigned char *) _pRpcMessage->Buffer; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, (unsigned char *)pszString, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[44] ); } RpcFinally { _StubMsg.MaxCount = ( unsigned long )size; NdrPointerFree( &_StubMsg, (unsigned char *)pszString, &__MIDL_TypeFormatString.Format[40] ); } RpcEndFinally _pRpcMessage->BufferLength = (unsigned int)(_StubMsg.Buffer - (unsigned char *)_pRpcMessage->Buffer); } void __RPC_STUB Tests_Test( PRPC_MESSAGE _pRpcMessage ) { MIDL_STUB_MESSAGE _StubMsg; unsigned char **pszArray; long size; RPC_STATUS _Status; ((void)(_Status)); NdrServerInitializeNew( _pRpcMessage, &_StubMsg, &Tests_StubDesc); size = 0; ( unsigned char ** )pszArray = 0; RpcTryFinally { RpcTryExcept { if ( (_pRpcMessage->DataRepresentation & 0X0000FFFFUL) != NDR_LOCAL_DATA_REPRESENTATION ) NdrConvert( (PMIDL_STUB_MESSAGE) &_StubMsg, (PFORMAT_STRING) &__MIDL_ProcFormatString.Format[52] ); _StubMsg.Buffer = (unsigned char *)(((long)_StubMsg.Buffer + 3) & ~ 0x3); if(_StubMsg.Buffer + 4 > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } size = *(( long * )_StubMsg.Buffer)++; NdrConformantArrayUnmarshall( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char * *)&pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78], (unsigned char)0 ); if(_StubMsg.Buffer > _StubMsg.BufferEnd) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } } RpcExcept( RPC_BAD_STUB_DATA_EXCEPTION_FILTER ) { RpcRaiseException(RPC_X_BAD_STUB_DATA); } RpcEndExcept Test(size,pszArray); _StubMsg.BufferLength = 0; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayBufferSize( (PMIDL_STUB_MESSAGE) &_StubMsg, (unsigned char *)pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78] ); _pRpcMessage->BufferLength = _StubMsg.BufferLength; _Status = I_RpcGetBuffer( _pRpcMessage ); if ( _Status ) RpcRaiseException( _Status ); _StubMsg.Buffer = (unsigned char *) _pRpcMessage->Buffer; _StubMsg.MaxCount = ( unsigned long )size; NdrConformantArrayMarshall( (PMIDL_STUB_MESSAGE)& _StubMsg, (unsigned char *)pszArray, (PFORMAT_STRING) &__MIDL_TypeFormatString.Format[78] ); } RpcFinally { _StubMsg.MaxCount = ( unsigned long )size; NdrPointerFree( &_StubMsg, (unsigned char *)pszArray, &__MIDL_TypeFormatString.Format[74] ); } RpcEndFinally _pRpcMessage->BufferLength = (unsigned int)(_StubMsg.Buffer - (unsigned char *)_pRpcMessage->Buffer); } -- Rob Shearman

2 1

Re: advpack: Implement LaunchINFSectionEx [resend]
by Alexandre Julliard 31 Mar '06

31 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > +static LPWSTR get_parameter(LPWSTR parameters, WCHAR separator, DWORD index) > +{ > + LPWSTR param = NULL, ptr = parameters; > + DWORD i = 0; > + > + while (*parameters && i < index) > + { > + if (*parameters == separator) > + { > + ptr = parameters; > + i++; > + } > + > + parameters++; > + } > + > + if (!*parameters || *parameters == separator) > + return NULL; > + > + param = HeapAlloc(GetProcessHeap(), 0, (parameters - ptr) * sizeof(WCHAR)); > + lstrcpynW(param, parameters, parameters - ptr); > + > + return param; > +} That's a very inefficient way of splitting a string. It's much better to allocate a copy of the whole string and go through it just once, inserting nulls to separate the tokens. -- Alexandre Julliard julliard(a)winehq.org

1 0

advpack: The Plan
by James Hawkins 31 Mar '06

31 Mar '06

Hey, As you've probably noticed, I've been working on implementing advpack for a couple months now; a lot of progress has been made, and I'm glad to say that the end is in sight. The rest of this email details the game plan for finishing advpack. advpack has five main install functions: DoInfInstall, ExecuteCab, LaunchINFSection, LaunchINFSectionEx, and RunSetupCommand. They all basically do the same thing with minor differences in functionality. ExecuteCab extracts the files to install from a cab archive, LaunchINFSectionEx provides backup and rollback capability, and RunSetupCommand can also launch executables. When installing an INF section, advpack calls setupapi to install the base INF commands, such as CopyFiles and AddReg. After this, advpack parses the Advanced INF for advanced commands that are only installable when using advpack. These commands include: Values: RequiredEngine - Use either setupapi or setupx, we will ignore it. CustomDestination - assigns ldids to extra directories. SmartReboot - same reboot options as LaunchINFSection. Cleanup - deletes the INF when the install/uninstall is finished if this is 1. CheckAdminRights - check if the user is admin if this is 1. Actions: RegisterOCXs UnregisterOCXs BeginPrompt EndPrompt RunPreSetupCommands RunPostSetupCommands DelDirs PerUserInstall Backup/Rollback: ComponentName ComponentVersion BackupReg PreRollBack BackupPath Internally, there will be three main install functions: install_init, which will open the INF, make sure it's legit, and other initializations, spapi_install, which will call setupapi to install the base INF commands, and adv_install, which will parse the install section and run the provided commands. Each advanced command will be implemented by a function of similar name, e.g., RegisterOCXs would be implemented by the function register_ocxs, etc. All the command functions will be in a hash map, the key being the command name, the value being a pointer to the function that implements the command. adv_install will use setupapi to parse the entries of the install section, calling the function returned by a query to the hash map. According to INF Web [1], some commands are run before others, so there will probably be three or four maps, the functions in the maps grouped according to the order in which the commands should be run. For example, RunPreSetupCommands is to be executed after the BeginPrompt command, so begin_prompt would be in the phase 1 map, and run_pre_setup_commands would be in the phase 2 map. We would call the parser like so: run_adv_commands("InstallSection", phase1_map); run_adv_commands("InstallSection", phase2_map); run_adv_commands("InstallSection", phase3_map); If a command in the install section is not in the map, we just ignore it. This is The Plan so far, so if anyone has any ideas or suggestions, I'd love to hear from you. Thanks, James Hawkins [1] http://www.winpack.org/petr/INF_web/

4 4

Very old Windows programs and Wine
by Segin 31 Mar '06

31 Mar '06

I have come forth with a Windows program -- complete with source and binary -- designed for Windows 2.03 (as from the binary headers, i learned a bit about NE headers trying to hack Win9x 16-bit apps onto windows 3.1, i did manage to get Defrag to work that way) Case and point, would anyone like to take a look at what all Wine can do with the source (winelib) and the binary (admittedly designed for a 8086.)

1 0

Re: COMCTL32: Add comctl32 to the list of always builtin dlls.
by Vitaly Lipatov 31 Mar '06

31 Mar '06

I do not agree with this patch. There is broken code in WINE's comctl32 realization (in treeview/listview code) and we need overrides builtin dll by native for get differences... В сообщении от 30 марта 2006 07:56 Mike McCormack написал(a): > --- > > dlls/ntdll/loadorder.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Why winetools is utterly useless, once and for all.
by Segin 31 Mar '06

31 Mar '06

There is one reason, inarguable (if you reply to this you have a IQ of 0) as to why WineTools is useless: Most of the WineTools 'magic' is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, thefore, WineTools is utterly useless and has no point in existing AT ALL, PERIOD.

14 25

Re: [WIDL] Implement support for unique strings
by Robert Shearman 30 Mar '06

30 Mar '06

Eric Kohl wrote: > case PASS_OUT: >+ if (in_attr && has_size && pointer_type == RPC_FC_UP && phase == PHASE_FREE) >+ break; > if (!out_attr) > continue; > break; > > I don't think this is correct. Firstly, it should continue, not break. Secondly, I think it only doesn't need to free the string if it has a size. I'm pretty sure it shouldn't depend on being a unique string. -- Rob Shearman

1 0

Need Help for IniFileMapping
by Detlef Riekenberg 30 Mar '06

30 Mar '06

Hi all. I need your Help to see, how IniFileMapping works on different NT-Versions. An updated kernel32_crosstest.exe, that prints a lot of informations and a detailed description is here: http://bugs.winehq.org/show_bug.cgi?id=4096 Thanks for your Help (IniFile is the redirection from "*.ini" - Files to the Registry, by GetPrivateProfileString() and Friends.) -- By By ... ... Detlef

1 0

OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
by Dr J A Gow 30 Mar '06

30 Mar '06

I was interested to read several comments on this list in respect of such comments as 'IQ of zero'. Such comments were the final straw in leading me to take this action. A few days ago I sent a comment to the list. Nothing really sinister, just an observation and an experience. Before long I had a particularly vicious and vile diatribe sent in reply to my comment - to my private email address. I have appended the lower headers and the bulk of the message I received at the end of this message (trimming the html from the bottom). I thought long and hard before taking this action. It is not something I would normally do, but in this instance I was so incensed at this individual's behaviour that I felt that 'naming and shaming' was the only way forward. Not even so much as to the fact that he directed his comments to me, but more the fact that had I been a new prospective developer, the effect such diatribe would have would not in any way be positive. It certainly would taint their perception of the open-source community. Furthermore I sincerely doubt that I am the only one to experience this behaviour. Others may just suffer in silence. I have worked with many smaller community projects, on OS/2 and latterly on Linux, and never been subjected to this kind of abuse from members of the community. I joined this list because I felt that there was something I could contribute to Wine, and in the instance it turned out that there was. I did not join it to receive unsolicited email of an abusive nature from members of the community. Had he done this by telephone I could have had him prosecuted, at least in the UK. But he hides behind a gmail.com address and makes comments I seriously suspect he would not have the balls to say to my face. No, I do not believe that we need a 'net police force'. Common decency between individuals, however, is essential. Diversity, discussion, criticism, expression, even annoyance are all valuable when driving a project forward. Blatant personal abuse is not tolerable. It is not tolerable in society, it should not be tolerated in the developer community. The community needs to police itself, rather than be policed, and individuals who bring the community into disrepute need to be dealt with by the community. That is why I bring this into the open. How to prevent such actions? I do not think it that this is possible in its entirety. I can (and have) simply add this individual's address to my blocked list. However, I may have been a newcomer to open-source development who would not have been so tolerant, and whose opinions of the community may have been changed by this action. May I suggest that whoever is responsible for the hosting of the mailing list change the configuration so that email addresses are not placed in the header? (I am no expert on mailing-list software but it does not immediately seem to be impractical.) That way all replies have to go to the list and this would prevent such unsolicited email being sent. This is my last word on this matter. Make of it what you will. I refuse to be prevented from contributing to vital projects such as Wine when I can by the antics of some depraved individual. It has left a sour taste in my mouth though, and like it or not, it does not portray Wine developers in a good light. ------------------------------------------------------------------------------- Disposition-Notification-To: Segin <segin2005(a)gmail.com> Date: Fri, 24 Mar 2006 15:01:11 -0500 From: Segin <segin2005(a)gmail.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051202) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dr J A Gow <J.A.Gow(a)furrybubble.co.uk> Subject: Re: Winetools -> wine doors References: <1143192770.25116.22.camel(a)despair.kent-music.com> <442441D7.7020107(a)furrybubble.co.uk> In-Reply-To: <442441D7.7020107(a)furrybubble.co.uk> Content-Type: multipart/alternative; boundary="------------010900050103010506060607" X-BV-Spam-Score: 0.4 (/) X-Envelope-From: segin2005(a)gmail.com X-Virus-Scanned: by amavisd-new This is a multi-part message in MIME format. --------------010900050103010506060607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dr J A Gow wrote: > >> I've looked through the winetools code and it is a clusterf*ck of >> nonsense. It appears to be in the final stages of code rot, however > > > This "clusterf*ck of nonsense" helped me to get a microcontroller > development suite running under Wine, which otherwise would not install You're a fucking retard, RTFM! You'd learn you need to use DLLOverrides in Winecfg. > natively. After over ten years designing and developing embedded systems, > there is one thing that stands out. That you're a dumbfuck? > Code that is 'nonsense' does not work > at all. That's 100% definitive of Winetools. > Code that works may not be elegant, it may not be pretty and > you may hate the style, but it _works_ Nope, wine doesn't do ~/.wine/config, which makes winetools COMPLETELY useless. **WINETOOLS DOES NOT DO A DAMN REDEEMING THING FOR WINE USERS THAT ARE UP TO DATE!!!!** > and therefore it is not nonsense. Yes, it is. > This code works, is useful and serves a purpose. Just because you don't > like the way it is written does not make it nonsense. Language, please! > No IT DOES NOT! > John. > > So you're saying that you don't know how to use dlloverrides on winecfg, right? that's basically the same thing winetools does except that wine now ignores the config file (makine winetools utterly useless, 100%, no questions asked). please just install all the native DLLs that winetools installs, and set a dlloverride in winecfg of * (native, builtin) for your exe file. Please stop spouting your mis-infomation.

4 6

Re: advpack: Forward ExecuteCabA to its unicode counterpart
by Robert Shearman 30 Mar '06

30 Mar '06

James Hawkins wrote: >@@ -86,6 +87,43 @@ HRESULT WINAPI DoInfInstall(const SETUPC > > /*********************************************************************** > * ExecuteCabA (ADVPACK.@) >+ * >+ * See ExecuteCabW. >+ */ >+HRESULT WINAPI ExecuteCabA(HWND hwnd, CABINFOA* pCab, LPVOID pReserved) >+{ >+ UNICODE_STRING cab, inf, section; >+ CABINFOW cabinfo; >+ HRESULT hr; >+ >+ TRACE("(%p, %p, %p)\n", hwnd, pCab, pReserved); >+ >+ if (!pCab) >+ return E_INVALIDARG; >+ >+ RtlCreateUnicodeStringFromAsciiz(&cab, pCab->pszCab); > > pCab->pszCab can be NULL, right? I don't think RtlCreateUnicodeStringFromAsciiz handles that case in the way you expect. -- Rob Shearman

1 0

Re: Improper message recursion revealed by recent desktop window changes
by Jesse Allen 30 Mar '06

30 Mar '06

On 3/29/06, Troy Rollo <wine(a)troy.rollo.name> wrote: > The recent changes to the desktop have revealed a problem with recursive > processing of X messages. The problem started to manifest with commit > 1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack > that looks like this: > > <application Window procedure> > WINPROC_wrapper > ... > CallWindowProcW > ... > SendMessageW > X11DRV_SetWindowPos > SetWindowPos > X11DRV_ConfigureNotify > process_events > X11DRV_MsgWaitForMultipleObjectsEx > wait_message_reply > send_inter_thread_message > SendMessageTimeoutW > SendMessageW > send_parent_notify > DestroyWindow > > In other words, a destroy notification is being sent to the parent window with > SendMessageW, and before that message returns an unrelated X message is > processed. Under Windows the equivalent could never happen - if a thread is > in SendMessage(), the only messages that can be delivered to it are ones sent > by SendMessage() from another thread. > > The consequences of this can be unpleasant if the code that processes (in this > case a window movement notification) the message interferes with state that > is being dealt with in earlier stack frames. Yep, that's why the launching of War3 seems to only paint explorer or the launch window depending on how I hacked wine. This is the problem exhibited in bugs 4948, 4897, and 4847. > > wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with: > > res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue, > INFINITE, QS_ALLINPUT, 0 ); > > The brute-force approach of changing this to the following makes the > application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT > and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to > change I thought it best left to people with more familiarity with it. > > -- > Troy Rollo - wine(a)troy.rollo.name > > > Last thing I did today was looking at the message passing and signal handling. The signal handling doesn't look any different than before. I figured something could be up with the message handling as it seemed one thread was stomping on another but I don't know anything about wineserver. I'll take a better look tomorrow! Jesse

1 0

Re: OT: General behaviour of the community (from 'Why winetools is utterly useless, once and for all')
by Hiji 30 Mar '06

30 Mar '06

> How do you propose we prevent people from emailing people that post to > wine-devel? How do we choose who gets to email people directly and > who doesn't? How do we filter the contents of their email? I want to chime in and say that I'm with Tom and the ole Doc here. I don't think there's any way to filter somebody's contents, but I think it's important for the community to speak up when somebody is out of line. I know I was the first to respond to Sergin's email by asking that he be more constructive in his feedback, but past that, none of the regulars on this thread said much. Now, his thread has spawned into something that is soooo far out there that it almost has no relevancy to this list. I want to note that I don't see how Sergin's comments and behavior could have been interpreted as anything but inappropriate; however, with the majority of people not saying anything, I can only imagine that Sergin felt that what he did was perfectly okay and acceptable on this list. I'm trying to say two things here: 1) If somebody says/ does something that is not okay, say something to that person. Of course, be constructive about it. For example, when I first joined this list, people got upset that I was top-posting - I learned that it was not ok in this community because people said someting. So, I try to bottom post (when I remember.) 2) I've always said Wine is an awesome thing - probably the best thing to come out of the Linux community since ... well, Linux and its desktops. Now, more than ever, Wine need as many developers as possible to keep it improve b/c as Linux adoption continues people will look to Wine and CrossOver for application cross-compatibility. And, I'm not talking about the developer who pops in with a patch every 6 months (I see that person as a patch submitter), but instead, I'm talking about a developer who dedicated him/herself to the Wine project. And with that, the team can't afford to lose that good talent b/c the "newbie talent" was mistreated in this community. Those are my 2 cents that I think will go a long way. Thanks, Hiji

3 3

Interesting D3D testapp
by Willie Sippel 30 Mar '06

30 Mar '06

Hi there. I think I just found a very nice D3D testapp: fr-025 by Farbrausch. A nice, small (8.2MB) graphics demo, already works somewhat with Wine (starts, plays, music and everything works, good performance), but lots and lots of effects are simply missing or wrong. It does quite a bit interesting stuff wined3d doesn't seem to handle: strange viewport handling, glow, blending, reflections, blur(?). So many unimplemented features I won't even dare to file bugreports for every single one... :) It's the all-time most popular demo on pouet.net (obviously, given it's called "fr-025 - the.popular.demo" ;) ) You can get it at: http://www.pouet.net/prod.php?which=9450 -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

1 0

Here is an RSS feed for front page of www.winehq.com
by Daniel Schwarz 29 Mar '06

29 Mar '06

I've long wondered why winehq.com does not provide an RSS feed. I've created one using the feed43.com sitescraping tool. Works well and it should be very low impact to your webserver (it only hits the URL at most once every 6 hours and caches the result for subsequent queries) Feel free to post this RSS link on the winehq homepage. http://feed43.com/winehq.xml Best Regards, Dan Schwarz

1 0

"Unhandled exception: floating point stack check" early in program?
by Dan Kegel 29 Mar '06

29 Mar '06

See the winedbg session below. Is it normal for winedbg to complain about floating point stuff when the program, run normally, doesn't? Using either 'cont' or 'pass' at this point just repeats the same message. Hints welcome. Thanks, Dan dank@lappy:~$ ~/wine/programs/winedbg/winedbg ~/.wine/drive_c/putty/putty.exe WineDbg starting on pid 0x42 start_process () at /home/dank/wine/dlls/kernel/process.c:845 0x7fcbd259 start_process+0xb9 [/home/dank/wine/dlls/kernel/process.c:845] in ker nel32: subl $12,%esp 845 ExitProcess( entry( peb ) ); Wine-dbg>c First chance exception: floating point stack check in 32-bit code (0x7f7a0d90). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:7f7a0d90 ESP:7fafea58 EBP:7fafea90 EFLAGS:00010246( - 00 -RIZP1) EAX:7fdc2400 EBX:7f7c00b0 ECX:00000000 EDX:7fdc2400 ESI:7fafeaac EDI:00000002 Stack dump: 0x7fafea58: 7fafeb40 0000ffff 7fafea90 7f7c00b0 0x7fafea68: 0000005c 0000007c 7fafea90 7f79e0c6 0x7fafea78: 7f7c8f40 7fd868e8 0000005c 7f34e09c 0x7fafea88: 63656a62 0000007c 7fafeac0 7f31a40f 0x7fafea98: 000002e4 7fafeaac 00000002 7fafeb40 0x7fafeaa8: 7fafeb78 00000000 00000000 00000007 0200: sel=1007 base=7fec2000 limit=00001fff 32-bit rw- Backtrace: =>1 0x7f7a0d90 LPtoDP+0x50(hdc=0x2e4, points=0x7fafeaac, count=0x2) [/home/dank/wine/dlls/gdi/mapping.c:132] in gdi32 (0x7f7a0d90) 2 0x7f31a40f X11DRV_XWStoDS+0x3f(physDev=0x7fdc2558, width=0x7) [/home/dank/wine/dlls/x11drv/graphics.c:307] in winex11 (0x7f31a40f) 3 0x7f33e89d X11DRV_XRender_SelectFont+0x5d(physDev=0x7fdc2558, hfont=0x7c) [/home/dank/wine/dlls/x11drv/xrender.c:554] in winex11 (0x7f33e89d) 4 0x7f3390e0 X11DRV_SelectFont+0xce0(physDev=0x7fdc2558, hfont=0x7c, gdiFont=0x7fdb7110) [/home/dank/wine/dlls/x11drv/xfont.c:3234] in winex11 (0x7f3390e0) 5 0x7f78c52f FONT_SelectObject+0x6f(handle=0x7c, obj=0x7fd868d8, hdc=0x2e4) [/home/dank/wine/dlls/gdi/font.c:587] in gdi32 (0x7f78c52f) 6 0x7f79fb20 SelectObject+0x70(hdc=0x2e4, hObj=0x7c) [/home/dank/wine/dlls/gdi/gdiobj.c:1168] in gdi32 (0x7f79fb20) 7 0x7f77e9f7 DC_InitDC+0x77(dc=0x7fdc2400) [/home/dank/wine/dlls/gdi/dc.c:204] in gdi32 (0x7f77e9f7) 8 0x7f7801e9 CreateDCW+0x129(driver=0x7f34146c, device=0x0, output=0x0, initData=0x0) [/home/dank/wine/dlls/gdi/dc.c:655] in gdi32 (0x7f7801e9) 9 0x7f304f27 X11DRV_GetDCEx+0x387(hwnd=0x10020, hrgnClip=0x0, flags=0x3) [/home/dank/wine/dlls/x11drv/dce.c:214] in winex11 (0x7f304f27) 10 0x7f86acaa GetDCEx+0x3a(hwnd=0x0, hrgnClip=0x0, flags=0x3) [/home/dank/wine/dlls/user/painting.c:476] in user32 (0x7f86acaa) 11 0x7f86ad6c GetDC+0x3c(hwnd=0x0) [/home/dank/wine/dlls/user/painting.c:490] in user32 (0x7f86ad6c) 12 0x7f82ed0a GetDialogBaseUnits+0x3a [/home/dank/wine/dlls/user/dialog.c:1411] in user32 (0x7f82ed0a) 13 0x7f830c8b DIALOG_CreateIndirect+0x2b(dlgTemplate=<register not in topmost frame>, dlgProc=0x4340e2, param=0x0, unicode=0x0, modal=0x0) [/home/dank/wine/dlls/user/dialog.c:474] in user32 (0x7f830c8b) 14 0x7f83254e CreateDialogIndirectParamAorW+0x2e(hInst=0x400000, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0, flags=0x2) [/home/dank/wine/dlls/user/dialog.c:697] in user32 (0x7f83254e) 15 0x7f83264e CreateDialogIndirectParamA+0x2e(hInst=0x400000, dlgTemplate=0x46bcc0, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:706] in user32 (0x7f83264e) 16 0x7f8326c6 CreateDialogParamA+0x66(hInst=0x400000, name=0x6f, owner=0x0, dlgProc=0x4340e2, param=0x0) [/home/dank/wine/dlls/user/dialog.c:670] in user32 (0x7f8326c6) 17 0x00434801 in putty (+0x34801) (0x00434801) 18 0x442922a7 (0x442922a7) 19 0x00000000 (0x00000000) 20 0x00000000 (0x00000000) Wine-dbg> ? -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: server: Fix FPU registers in get_thread_context()
by Vitaliy Margolen 29 Mar '06

29 Mar '06

Monday, March 27, 2006, 12:51:03 AM, Petr Tesarik wrote: > Hi, > this patch fixes a bug in get_thread_context(). Currently, this > routine assumes that all registers except debug registers are saved in thread->>context if it exists. However, it does not include FPU > registers. > IMO, we should not blindly assume which registers are present in thread->>context but look at ContextFlags. > BTW I found this bug when winedbg stopped working with programs using > the FPU. > ChangeLog: > * Look at ContextFlags to see which registers are saved in > thread->context. Sorry this is not correct. Exception handler should get full context including FPU context. If we not saving it that's the problem on the other end. Vitaliy Margolen

2 2

Re: Alexandre Julliard : x11drv: Moved desktop mode handling to the explorer process.
by Tony Lambregts 29 Mar '06

29 Mar '06

Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: db6608ac9f9bbc2ddd7f8bf201d1387d079dfd5f > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=db6608ac9f9bbc2ddd7f8bf… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Mar 27 22:43:03 2006 +0200 > > x11drv: Moved desktop mode handling to the explorer process. > > Per-application desktop mode settings are no longer supported. Apps > can be launched in a specific desktop window by using: > > explorer /desktop=name[,widthxheight] app.exe [args] > > If the named desktop already exists the app is launched inside it. The > default desktop is cleverly named "default". > So if I understand this correctly all programs will share the same desktop. Is it also true that I cannot specify in winecfg that one program can run full screen and another in a desktop window. If this is the case we will have a fair amount of crying over this one. At the very least we need to put a note in winecfg. (preferabley befor next release). -- Tony Lambregts

12 23

Page fault xmlspy 2006 wine .9.10
by Grant Lewis 29 Mar '06

29 Mar '06

It's repeatable. I can launch the progam fine but when I click in certain parts of the gui I generate the page fault and the program dies. wine: Unhandled page fault on write access to 0x0000001f at address 0x7d62d6 (th read 0009), starting debugger... WineDbg starting on pid 0x8 First chance exception: page fault on read access to 0x00000000 in 32-bit code ( 0x7ffa7292). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7ffa7292 ESP:7fbfec74 EBP:7fbfed3c EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:7ffd5280 ECX:00000000 EDX:00000000 ESI:0000001f EDI:00000002 Stack dump: 0x7fbfec74: 7fbfec90 00000001 00000000 00000c28 0x7fbfec84: 7fbff174 7ffa09d0 00000001 7ffd5280 0x7fbfec94: 0000001f 00000002 7fbfed3c 7fbfec74 0x7fbfeca4: 7ffa7283 00000001 80000000 00000000 0x7fbfecb4: 7ffa4dc9 7ffa406d 00000000 7ff9afea 0x7fbfecc4: 7ffd5280 7e1699a8 00000048 7ff9b0af Backtrace: =>1 0x7ffa7292 RtlImageNtHeader+0x72 in ntdll (0x7ffa7292) 2 0x7ffa757a RtlImageDirectoryEntryToData+0x3a in ntdll (0x7ffa757a) 3 0x7fc43dbf UnhandledExceptionFilter+0x4df in kernel32 (0x7fc43dbf) 4 0x7ffa0a65 __wine_exception_handler+0x95 in ntdll (0x7ffa0a65) 5 0x7ffbbb99 call_exception_handler+0x29 in ntdll (0x7ffbbb99) 6 0x7ffbbb6d EXC_CallHandler+0x1d in ntdll (0x7ffbbb6d) 7 0x7ffa040f in ntdll (+0x1040f) (0x7ffa040f) 8 0x7ffa059b __regs_RtlRaiseException+0x2b in ntdll (0x7ffa059b) 9 0x7ffbc2ac in ntdll (+0x2c2ac) (0x7ffbc2ac) 10 0xdeadbabe (0xdeadbabe) 11 0x00000000 (0x00000000) 0x7ffa7292 RtlImageNtHeader+0x72 in ntdll: cmpw $0x5a4d,0x0(%eax) Modules: Module Address Debug info Name (98 modules) PE 0x00400000-014eb000 Deferred xmlspy PE 0x10000000-1002e000 Deferred ssce5332 ELF 0x7bf00000-7bf03000 Deferred <wine-loader> ELF 0x7ed0b000-7ed20000 Deferred midimap<elf> \-PE 0x7ed10000-7ed20000 \ midimap ELF 0x7ee3e000-7ee5f000 Deferred msacm32<elf> \-PE 0x7ee50000-7ee5f000 \ msacm32 ELF 0x7ee5f000-7ee76000 Deferred msacm<elf> \-PE 0x7ee70000-7ee76000 \ msacm ELF 0x7ee76000-7ef4a000 Deferred libcrypto.so.0.9.7 ELF 0x7ef4a000-7ef72000 Deferred libssl.so.0.9.7 ELF 0x7ef72000-7ef8a000 Deferred libcups.so.2 ELF 0x7ef8c000-7efa0000 Deferred msimg32<elf> \-PE 0x7ef90000-7efa0000 \ msimg32 ELF 0x7f08e000-7f0bd000 Deferred uxtheme<elf> \-PE 0x7f0a0000-7f0bd000 \ uxtheme ELF 0x7f0bd000-7f0d5000 Deferred ximcp.so.2 ELF 0x7f0d5000-7f0d8000 Deferred xlcdef.so.2 ELF 0x7f0d8000-7f136000 Deferred libgl.so.1 ELF 0x7f14c000-7f1fb000 Deferred libx11.so.6 ELF 0x7f1fb000-7f26c000 Deferred winex11<elf> \-PE 0x7f210000-7f26c000 \ winex11 ELF 0x7f26c000-7f287000 Deferred libexpat.so.0 ELF 0x7f287000-7f2a9000 Deferred libfontconfig.so.1 ELF 0x7f2ab000-7f2bf000 Deferred libice.so.6 ELF 0x7f2bf000-7f321000 Deferred libfreetype.so.6 ELF 0x7f328000-7f330000 Deferred libxcursor.so.1.0.2 ELF 0x7f330000-7f337000 Deferred libxrender.so.1 ELF 0x7f337000-7f390000 Deferred msvcrt<elf> \-PE 0x7f350000-7f390000 \ msvcrt PE 0x7f390000-7f3cb000 Deferred oraclm32 ELF 0x7f3cf000-7f3da000 Deferred libxext.so.6 ELF 0x7f3da000-7f3f4000 Deferred imm32<elf> \-PE 0x7f3e0000-7f3f4000 \ imm32 ELF 0x7f3f4000-7f46d000 Deferred winmm<elf> \-PE 0x7f400000-7f46d000 \ winmm ELF 0x7f46d000-7f48d000 Deferred odbc32<elf> \-PE 0x7f480000-7f48d000 \ odbc32 ELF 0x7f48d000-7f4b2000 Deferred ws2_32<elf> \-PE 0x7f4a0000-7f4b2000 \ ws2_32 ELF 0x7f4b2000-7f4cb000 Deferred wsock32<elf> \-PE 0x7f4c0000-7f4cb000 \ wsock32 ELF 0x7f4cb000-7f4e7000 Deferred mpr<elf> \-PE 0x7f4d0000-7f4e7000 \ mpr ELF 0x7f4e7000-7f522000 Deferred wininet<elf> \-PE 0x7f4f0000-7f522000 \ wininet ELF 0x7f522000-7f541000 Deferred cabinet<elf> \-PE 0x7f530000-7f541000 \ cabinet ELF 0x7f541000-7f56d000 Deferred urlmon<elf> \-PE 0x7f550000-7f56d000 \ urlmon ELF 0x7f56d000-7f5e6000 Deferred oleaut32<elf> \-PE 0x7f580000-7f5e6000 \ oleaut32 ELF 0x7f5e6000-7f5fa000 Deferred olepro32<elf> \-PE 0x7f5f0000-7f5fa000 \ olepro32 ELF 0x7f5fa000-7f613000 Deferred oledlg<elf> \-PE 0x7f600000-7f613000 \ oledlg ELF 0x7f613000-7f639000 Deferred winspool<elf> \-PE 0x7f620000-7f639000 \ winspool ELF 0x7f639000-7f6d2000 Deferred comctl32<elf> \-PE 0x7f640000-7f6d2000 \ comctl32 ELF 0x7f6d2000-7f6ee000 Deferred iphlpapi<elf> \-PE 0x7f6e0000-7f6ee000 \ iphlpapi ELF 0x7f6ee000-7f729000 Deferred rpcrt4<elf> \-PE 0x7f700000-7f729000 \ rpcrt4 ELF 0x7f729000-7f79b000 Deferred ole32<elf> \-PE 0x7f740000-7f79b000 \ ole32 ELF 0x7f79b000-7f7e7000 Deferred shlwapi<elf> \-PE 0x7f7b0000-7f7e7000 \ shlwapi ELF 0x7f7e7000-7f896000 Deferred shell32<elf> \-PE 0x7f800000-7f896000 \ shell32 ELF 0x7f896000-7f92c000 Deferred comdlg32<elf> \-PE 0x7f8a0000-7f92c000 \ comdlg32 ELF 0x7f92c000-7f963000 Deferred advapi32<elf> \-PE 0x7f940000-7f963000 \ advapi32 ELF 0x7f963000-7f9e3000 Deferred gdi32<elf> \-PE 0x7f970000-7f9e3000 \ gdi32 ELF 0x7f9e3000-7faf0000 Deferred user32<elf> \-PE 0x7fa00000-7faf0000 \ user32 ELF 0x7fc01000-7fc05000 Deferred libxxf86vm.so.1 ELF 0x7fc05000-7fcf0000 Export kernel32<elf> \-PE 0x7fc20000-7fcf0000 \ kernel32 ELF 0x7fe01000-7fe06000 Deferred libxxf86dga.so.1 ELF 0x7fe06000-7fe10000 Deferred libnss_files.so.2 ELF 0x7fe10000-7fe1a000 Deferred libnss_nis.so.2 ELF 0x7fe1a000-7fe2f000 Deferred libnsl.so.1 ELF 0x7fe31000-7fe40000 Deferred libz.so.1 ELF 0x7fe42000-7fe45000 Deferred libxrandr.so.2 ELF 0x7fe45000-7fe68000 Deferred libm.so.6 ELF 0x7fe68000-7ff5e000 Deferred libwine_unicode.so.1 ELF 0x7ff5f000-7ff67000 Deferred libsm.so.6 ELF 0x7ff67000-7ff70000 Deferred libnss_compat.so.2 ELF 0x7ff74000-7ffe0000 Export ntdll<elf> \-PE 0x7ff90000-7ffe0000 \ ntdll ELF 0xb7dd9000-b7ddd000 Deferred libdl.so.2 ELF 0xb7ddd000-b7ef8000 Deferred libc.so.6 ELF 0xb7ef8000-b7f4a000 Deferred libpthread.so.0 ELF 0xb7f60000-b7f7a000 Deferred libwine.so.1 ELF 0xb7f7b000-b7f92000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 0000000f -1 0000000e 0 0000000d 0 0000000c 0 0000000a 0000000b 0 00000008 (D) Z:\opt\Altova\XMLSpy2006\XMLSpy.exe 00000009 0 <==

3 5

Re: advpack: Open the INF file if the RSC_FLAG_INF flag is specified
by Alexandre Julliard 29 Mar '06

29 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > @@ -72,10 +72,7 @@ static void test_RunSetupCommand() > /* try to run an exe with the RSC_FLAG_INF flag */ > hexe = (HANDLE)0xdeadbeef; > hr = pRunSetupCommand(NULL, "winver.exe", "Install", "c:\\windows\\system32", "Title", &hexe, RSC_FLAG_INF, NULL); > - todo_wine > - { > - ok(hr == SPAPI_E_WRONG_INF_STYLE, "Expected SPAPI_E_WRONG_INF_STYLE, got %ld\n", hr); > - } > + ok(hr & SPAPI_E_EXPECTED_SECTION_NAME, "Expected a setupapi error, got %ld\n", hr); This test doesn't make sense. If you want to test certain bits you have to write that explicitly, not pick some random constant that happens to have the right value. And in any case a simple AND won't do what you want. -- Alexandre Julliard julliard(a)winehq.org

1 0

Debugging X errors?
by Dan Kegel 28 Mar '06

28 Mar '06

OK, I've had it. The X errors I'm running into are keeping me from getting work done. They might be due to bugs in my X server (ubuntu 05.10), but while I wait for the next release of ubuntu, maybe I could try to track them down anyway. It looks like the procedure for diagnosing X errors such as X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 17 (X_GetAtomName) Atom id in failed request: 0x0 Serial number of failed request: 468 Current serial number in output stream: 470 in Wine is to do WINEDEBUG=+synchronous export WINEDEBUG and then use winedbg to run the apps, and get a backtrace when the error occurs. I'll try that. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Russian translation for uninstall application
by Dmitry Timoshkov 28 Mar '06

28 Mar '06

"Anatoly A. Kazantsev" <jim-crow(a)rambler.ru> wrote: > + * Uninstaller (Russain Resources) Please fix the above typo and the translation of the word "registry" to match the commonly used russian word and resend the patch. -- Dmitry.

1 0

I have a complaint about the website
by Philip V. Neves 28 Mar '06

28 Mar '06

On the website there is an article that talks about homogenious populations being a threat to society and to the computer industry. Although I accept the fact that this is mostly true I believe that is a good argument for creating the Linux OS and other OS's not for creating wine. With the wine project you are bringing the homogenious population to the Linux community. So theoretically a virus could spread just as easily through a wine system as well as a Windows system. That virus could spread even if the security in Linux is in place. The wine installation could be affected and we have to reinstall the wine directory. I'd appreciate it if you guys would take that out of the website. I feel it hurts the credibility of your project by having it there. The fact is if a company has a wine installation they could have a large number of appications that could be affected by a virus. Wine running on a different system won't fix that. Although the security system in Linux could provide some security against accessing more vital parts of the system, the wine installation is still vulnerable due to the fact its implementing windows system calls. I have infact found viruses with Clam after installing wine. So I don't feel that this statement is true.

7 8

Re: setupapi: Test loading an exe from the system directory with SetupOpenInfFile
by Alexandre Julliard 28 Mar '06

28 Mar '06

"James Hawkins" <truiken(a)gmail.com> writes: > All the handling is in place for this to (mostly) work in > SetupOpenInfFileW. We call > CreateFile("c:\\windows\\system32\\winver.exe", ..., > OPEN_EXISTING...), but that fails, returning INVALID_HANDLE_VALUE. > winver.exe is in drive_c/windows/system32 as a symlink to the > installed winver.exe.so. Should a call to CreateFile on a symlink > fail? If the symlink is broken, yes. Note that it's no longer supposed to be a symlink, you should probably remove it and re-run wineprefixcreate. That said, I'm not quite sure why you'd want to open an exe with SetupOpenInfFile... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 28 Mar '06

28 Mar '06

2 3

What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
by Tomas Carnecky 28 Mar '06

28 Mar '06

GL_FRONT and GL_FRONT_LEFT mean the same unless the drawable is stereo. And I don't think PBuffers or Pixmaps can be stereo, so is there any special reason to use GL_FRONT_LEFT ? Or is it because the spec sais so? tom

4 7

Winetools -> wine doors
by penna＠bb.com.br 28 Mar '06

28 Mar '06

Hi Karl, > I would love it if people would get involved, a few good coders can have > SVN/trac access I'll work on opening up to the public soon. > > pygtk/pyxml/wine hackers/shell scripters very welcome. Maybe I can help with bash scripting (very good skill) .... I know nothing about python ... 8( ... but can learn quickly. BTW, I would like to point out two suggestions: 1) you (we) should set up a winedoors-devel list. This discussion should be out of the wine-devel list (we should not mix things up and wine devel folks are already too busy) 2) the winedoors should return some information to the AppDB in order to keep that information for the wine devel folks get some feedback what is going on with, for example, DLL overrides. For example, if the AppDB keeps track of the most overriden DLLs (information "feeded" by winedoors - or winetools 8)) I think wine developers could query the database in order to see which DLL needs some improvement because its is the most one overriden. One more thing, I like Winetools. It helped me a lot. Does it need improvement? Yes, it needs, but it is not the reason we may "burn" it. Regards (I am not subscribed at wine-devel list, so please cc me) --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 ---------------------------------------------------------

2 1

Re: What is the reason to use GL_FRONT_LEFT in wglMakeCurrent()
by Tom Spear (Dustin Booker, Dustin Navea) 27 Mar '06

27 Mar '06

Tomas Carnecky wrote: > I don't know if it even runs.. I mean, if it works correctly. > > http://dbservice.com/tom/LinuxTest.exe > > It creates LinuxTest.log in the same directory as the executable, and > prints out whether pbuffers are supported and which drawbuffers are > activated.. > > tom > > Well, I ran the file, and it did create the log, but in my case it said that pbuffers weren't supported in either spec. Tom

1 0

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 27 Mar '06

27 Mar '06

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. Oh, I forgot to mention another thing. I didn't start all this for nothing. I made my changes to raise_trap_exception() to make an existing application (Kindler Lexikon) work. Now, the copy protection mechanism in Kindler Lexikon uses a DOS application (no kidding!), so if you accept the VM86-related stuff that I posted earlier, so that raise_trap_exception() is not used for VM86-generated debug traps, it would probably be enough. However, as a side effect I noticed that the code does not work well, so I fixed it. If my fix is not good enough, well, then the UNIX ABI is not good enough, because: 1. A SIGTRAP can be delivered as a result of: a. INT 1 (single step or hardware breakpoint) b. INT 3 (INT3 or INT 03) c. kill() or tgkill() on the process 2. sc_trapno in sigcontext is set correctly by Linux only for 1a and 1b. The value of sc_trapno for 1c is undefined (and it may be even 1 or 3; I can provide a test case if needed). 3. Since you want to raise a BREAKPOINT exception for 1c, a BREAKPOINT exception with ExceptionAddress decremented by 1 for 1b and a SINGLE_STEP exception for 1a, you have to distinguish between those three cases. 4. You can tell the 1c case from 1b or 1c from the si_code in siginfo. However, this field might not be available. Things are even worse, because even TRAP_sig might be unavailable on some platforms! 5. Since the kernel does not provide enough information to distinguish between 1a, 1b and 1c, you have to investigate the reason yourself. There is no other way to detect a hardware breakpoint than to look at DR6. Additionally, since the bits would get stuck for all subsequent SIGTRAPs, we need to clear them. There is no other way to detect an INT3 breakpoint than to look at the code that immediately precedes the exception address. However, there is no guarantee that this address is mapped at all (a hardware breakpoint may occur anywhere, even at the first opcode of a page). Since native Windows won't crash in such cases, neither should we. That's why the whole thing is in a TRY block. Pretty long, huh? Petr Tesarik

3 3

Re: ntdll: Fix SIGTRAP handling
by Petr Tesarik 27 Mar '06

27 Mar '06

Dne 03/27/06 v 16:05:15 (+0200), Alexandre Julliard napsal(a): > Petr Tesarik <hat(a)tesarici.cz> writes: > > > No, Windows need not do things like that, because the Windows kernel > > knows very well, whether it got INT1 or INT3... Some UNIX kernels do > > not give us that information reliably. > > I'm afraid it's not acceptable to do things differently, especially > not things like the checking of the previous instruction that may > cause extra exceptions. Also stuff like the clearing of DR6 needs a > test case, that's something that's visible from the application. I don't want to cause unnecessary conflicts, so I _have_ written a test case, where Wine does a lot of application-visible things differently. Anyway, I've provided an improvement which only needs to do such things as a fallback on platforms, where the cause of the SIGTRAP cannot be determined easily. In my opinion, the solution is reasonable because if any application is really interested in the DR6 register (i.e. it is a debugger), it will clear the status register (DR6) anyway, since the processor never clears the bits and unless you clear them manually, the register gets pretty useless. I wonder why you haven't been bothered by the fact that the current implementation silently drops the TF bit, which is even worse! :O Petr Tesarik

2 2

Re: ntdll: Fix SIGTRAP handling
by Alexandre Julliard 27 Mar '06

27 Mar '06

Petr Tesarik <hat(a)tesarici.cz> writes: > 2. The x86 spec states that a single-step interrupt (INT 1) is > generated if the TF bit was set when the execution of the > instruction BEGAN. This means that if the instruction changes the > TF bit (e.g. popf), there is an INT 1, but the TF bit is not set > any more. The only way to check whether the interrupt was > generated because of the TF bit, is to check bit 15 in DR6. I don't see why you can't still check the TF bit, it will be set 99% of the time, and fetching the DR6 register is quite expensive. > The following patch fixes all of these issues. I'd really like to see test cases showing that Windows does things this way. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack: Add initial tests for RunSetupCommand
by Detlef Riekenberg 27 Mar '06

27 Mar '06

Am Donnerstag, den 23.03.2006, 23:12 -0600 schrieb James Hawkins: > * Add initial tests for RunSetupCommand. > dlls/advpack/tests/install.c | 106 ++++++++++++++++++++++++++++++++++++++++ Hi. Your tests used a fixed Path, resulting to failure on: - win95, win98 and winme (c:\windows\system) - NT3.51 (c:\winnt35\system32) - NT4 and w2k (c:\winnt\system32) - Every Installation, that use a non-default Installation-Directory - Every update of an NT < winxp (I don't know about the default Path in Versions > winxp) Your Patch is already in the tree, so expect many tests to fail. -- By By ... ... Detlef

1 0

FPU context in signal handlers
by Petr Tesarik 27 Mar '06

27 Mar '06

Hi, I've just submitted a patch that handles the FPU state in signal handlers. However, the FPU_sig() macro is only defined for Linux, so other architectures won't benefit from that patch. I doubt that i387 FPU state is left untouched by the kernel on other architectures, but I have no access to any such box (*BSD, BSDI, SCO, Apple), I cannot investigate into that, and the FPU handling is most likely broken on those architectures. This has become more serious now that winedbg tries to fetch (and restore!) the FPU state on the i386 architecture. I guess that architectures with (context)->uc_mcontext also define (context)->uc_mcontext.fpregs (SCO), but since I can't test it, I won't send such a patch to wine-patches. Is there anything I might do about it? Anybody wants to help? Petr

1 0

Regression in wine made 2006/03/23
by Pavel Troller 27 Mar '06

27 Mar '06

Hi! I would like to report a regression made by commits issued 2006/03/23 at the evening. Just now I don't have bisecting environment available, I've just made a simple CVS regression testing and found the above commit (it modifies multiple areas) guilty. The problem is that DC++ gui is totally screwed up now. It tries to render, but mostly unsuccessfully, it's full of garbage and doesn't display, what it should. It doesn't update when necessary. DC++ is simply unusable now. I should leave my testing machine now. I can try to pinpoint a particular patch responsible for this regression later in the evening today, or tomorrow. If anybody has an idea, what change could cause this, please let me know, it will be more easy for me. With regards, Pavel Troller

2 1

Wine/Interix -- The pros and cons.
by Segin 27 Mar '06

27 Mar '06

I was thinking about running Wine on Interix (the POSIX layer of Microsoft's Services for Unix). There are a few apparent unknows: Would Wine load the .dll.so's? Since Interix uses PE for it's native format (running on Windows, duh), Would Wine load the .dll.so's? Would it reject them being in PE format and having the 'POSIX Layer' attribute set, or could we hack on a patch to detect if Wine itself is running in said layer, and load them if it is? Would that even *work*? And how about detecting Winelib applications? It might get detected as a regular Windows app, and ... uh-oh... (let's just say it isn't pretty) There are several obvious pros: You can test Wine almost fully under Windows without mingling with Windows's native componets. This would allow for better and faster compatability tests. We could also see what "unknowns" exist in Interix -- Althought not nessessrarly useful to Wine developers itself, it could mean a whole new generation of applications which are half-Unix, half-Windows, if the right holes are found. I am sure this will spark a LOT of debate.

4 3

Re: WINECFG: use directory harddiskvolume1 for mapping drive C instead of drive_c
by Hans Leidekker 26 Mar '06

26 Mar '06

Any word on why this patch wasn't applied? There's a test marked todo_wine by Stefan Leichter that demonstrates this behaviour. And here's the relevant part of a relay log: 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "a:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "b:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=00000000 ret=0100503a 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "c:",7fb0f8c8,00000400) ret=0100503a 0009:Ret kernel32.QueryDosDeviceA() retval=0000000c ret=0100503a 0009:Call ntdll._strlwr(7fb0f8c8 "..\\drive_c") ret=01005053 0009:Ret ntdll._strlwr() retval=7fb0f8c8 ret=01005053 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002638 "harddisk") ret=01005069 0009:Ret ntdll.strstr() retval=00000000 ret=01005069 0009:Call ntdll.strstr(7fb0f8c8 "..\\drive_c",01002630 "ramdisk") ret=0100507d 0009:Ret ntdll.strstr() retval=00000000 ret=0100507d 0009:Call kernel32.QueryDosDeviceA(7fb0fe68 "d:",7fb0f8c8,00000400) ret=0100503a ... I know this affects the IE7 and MSI 3.1 installer, but probably more. ------------------ I've seen installers from Microsoft call QueryDosDevice on the whole alphabet and search any returned object name for the substrings "harddisk" and "ramdisk". On Wine they normally won't find any and quit with the following error: "Unable to find a volume for file extraction" QueryDosDevice on Wine returns the filename pointed to by the drive link beneath the dosdevices directory. In a default Wine installation this is ../drive_c. So a simple fix for this problem is to use the a different name for that directory, for example the name used for the first harddisk in the NT object namespace: harddiskvolume1. -Hans Changelog Use directory harddiskvolume1 for mapping drive C instead of drive_c.

2 1

Re: Alexandre Julliard : server: Class and global atoms should not be local to a window station.
by Alasdair Sinclair 26 Mar '06

26 Mar '06

Hi This patch breaks firefox-1.5 on fedora core 4 (x86-64). err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 wine: Unhandled page fault on write access to 0x0000001a at address 0x6033e436 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x0000001a in 32-bit code (0x6033e436). fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\xpcom\build\xpcom_core.pdb' Register dump: CS:0023 SS:002b DS:002b ES:002b FS:1007 GS:0063 EIP:6033e436 ESP:7fa0f790 EBP:7fa0f7c0 EFLAGS:00010246( - 00 -RIZP1) EAX:00000001 EBX:7f5e866c ECX:00000000 EDX:7fa0f704 ESI:00000000 EDI:7fa0fd18 Stack dump: 0x7fa0f790: 0001002a 7f5c580a 0001002a 00000113 0x7fa0f7a0: 00000000 0000139c 7fca1cf9 7f5e866c 0x7fa0f7b0: 7fa0f7c0 7f5e866c 0001002a 7fa0fd18 0x7fa0f7c0: 7fa0f800 7f5c6490 6033e417 0001002a 0x7fa0f7d0: 00000113 00000000 0000139c 7e270598 0x7fa0f7e0: 7fa0f9ac 7fa0f824 7f595f80 00000113 0200: sel=1007 base=7fe6a000 limit=00001fff 32-bit rw- Backtrace: =>1 0x6033e436 in xpcom_core (+0x2e436) (0x6033e436) 2 0x7f5c6490 WINPROC_CallWndProc+0x70(hwnd=<register not in topmost frame>, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dlls /user/winproc.c:418] in user32 (0x7f5c6490) 3 0x7f5cd2de CallWindowProcW+0x12e(func=0x7f624c34, hwnd=0x1002a, msg=0x113, wParam=0x0, lParam=0x139c) [/ppp/wine/wine-git/dll s/user/winproc.c:3095] in user32 (0x7f5cd2de) 4 0x7f5926ff DispatchMessageW+0xaf(msg=0x7fa0fd18) [/ppp/wine/wine-git/dlls/user/message.c:3001] in user32 (0x7f5926ff) fixme:dbghelp:sffip_cb NIY on 'c:\builds\tinderbox\Fx-Mozilla1.8\WINNT_5.2_Depend\mozilla\browser\app\firefox.pdb' 5 0x0051866b in firefox (+0x11866b) (0x0051866b) 6 0x007fd417 in firefox (+0x3fd417) (0x007fd417) 7 0x00401012 in firefox (+0x1012) (0x00401012) 8 0x7fc8a00c start_process+0xec(arg=0x0) [/ppp/wine/wine-git/dlls/kernel/process.c:845] in kernel32 (0x7fc8a00c) 9 0xf7fcc4f7 wine_switch_to_stack+0x17 in libwine.so.1 (0xf7fcc4f7) Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 9873494ced8405113381266b4d99c2a9f3002cb1 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=9873494ced8405113381266… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Wed Mar 22 22:13:40 2006 +0100 > > server: Class and global atoms should not be local to a window station. > > --- > > dlls/user/tests/winstation.c | 43 +++++++++++++++++++++++++++++++++++++++++- > server/atom.c | 27 ++++++++++++++++---------- > server/class.c | 24 ++++------------------- > 3 files changed, 62 insertions(+), 32 deletions(-) > > diff --git a/dlls/user/tests/winstation.c b/dlls/user/tests/winstation.c > index 4bc1941..a595718 100644 > --- a/dlls/user/tests/winstation.c > +++ b/dlls/user/tests/winstation.c

1 0

stir stir stir
by Mike Hearn 26 Mar '06

26 Mar '06

Deprived of patch-writing time lately I can do little more than cheer the team on. And of course, take pot-shots at our partners over the wall, the Windows team themselves ;) Hello there if you're reading this! In the comments of this anonymous MS employees blogs post (great reporting here huh) we can find this post by somebody who claims to be on an appcompat testing team: http://minimsft.blogspot.com/2006/03/vista-2007-fire-leadership-now.html#c1… in which the following totally astonishing claim is made: "Results: Client appcompat % hovering at <40% (GASP - INTERNAL INFO... better moderate this one out!!!!)" which is explained due to reduction of testing staff, loss of team morale and outsourcing of testing. Can it really be true that the Vista builds have such appallingly low application compatibility? Anybody who has access to Vista builds want to comment on this? Given they (now) have half a year to clean it up, does anybody want to take bets on what the score will be by the time it releases? I wonder what this number means (presumably that 40% of apps work perfectly out of the box), and I also wonder what our own appcompat score is. Wouldn't it be scary if Linux ends up more Windows compatible than Windows is! :) thanks -mike

1 0

Speed demon: Mozilla 1.7.12 and Wine.
by Segin 25 Mar '06

25 Mar '06

This is possibly the best news the Wine development team has recieved since getting Solitare to run on Wine in 1994: Wine and Mozilla are *faster* than IE on native Windows, on the same harware. I am not joking you. I used to have a Windows partition until it was corrupted recently, and my "personalized" Google homepage comes up in 2.31 seconds in IE. Note that Windows is running native (not a VM). Mozilla 1.7.12 in Wine pulls up the same page in under a second. I will continue to test. The only thing that is missing is Java support, and most of us can live without that. It's nice to know that we are mopping the floor with the World's Worst Webbrowser.

1 0

WGL_PBUFFER_LOST_ARB implementation
by Tomas Carnecky 25 Mar '06

25 Mar '06

This patch implements 'WGL_PBUFFER_LOST_ARB'. It creates a new field in 'X11DRV_PDEVICE' which is used to store flags (currently only one: X11DRV_FLAG_DAMAGED). This flag indicates that the drawable (PBuffer) is damaged and no longer valid. As soon as the x11 driver receives the GLX_DAMAGED event it calls X11DRV_GLX_Event() which then set the flag. wglQueryPbufferARB() uses ExtEscape() to retrieve this flag and can decide whether the PBuffer is lost or not. This patch depends on one I've sent earlier to the wine-patches mailing list: '[x11drv] Move x11drv ExtEscape() codes to one common header file.'. Please look through this patch and tell me if I've done something horribly wrong or missed an important aspect. I'm very new to wine and I don't know what I am allowed to touch and what not. tom

1 0

Winetools -> wine doors
by Karl Lattimer 25 Mar '06

25 Mar '06

I read your story about winetools a couple weeks ago around the same time that I tried using winetools on FC5 test 3, it didn't go well with winetools and I was looking for another solution and couldn't find one that fitted well with my criteria. I started thinking of packages like RPMs and started breaking down a wine application installation into what we would need to run it directly from the application menu. What I came up with this is, its pretty raw right now, its simply a small self contained package for managing the install process of a wine application, soon I'm going to start work on creating a package repository and the package browser but would really like to use the appdb for supplementary information, i.e. screenshots version compatibility etc... http://www.qdh.org.uk/wordpress/?cat=6 I have also considered having a way of making apps install gobally on a machine so any and every user has access to them, and considered using inotify to watch events and provide a way of handling this. This is still in the beginning stages and I would be grateful for any input you may have. I was very interested in what was published here, http://www.winehq.org/?issue=308#Winetools..%20part%20II I've looked through the winetools code and it is a clusterf*ck of nonsense. It appears to be in the final stages of code rot, however there are some useful little bits in there which I have been cannibalising when necessary into my own application. The beauty of this is that it is only an application shell, in theory the appdb could be the central configuration repository containing all the information to make an app work. Available apps can be browsed, downloaded if possible or installed from a cd drive with minimal fuss. I have one other who has joined in the project, his name is Alex Doukas and I believe he has also recently joined wine-devel. Right now we're at the stage of building up some script archives and starting to put together application packs for the most important stuff, I will be working on the downloaders/xml parsers within the next couple of weeks and hopefully we should soon have a working application where the community keeps it up to date. To prevent duplication of work I would suggest that suggestions to my project will be accepted, I hope to provide some public space for bug tracking etc... in the next couple of weeks and even public SVN. I currently have this configured and running but unfortunately do not have a great deal of bandwidth. The more people who join in the better, python programmers especially welcome, any scripts should eventually be posted to the bugzilla. Once the application db and my application fit together nicely we could have users publishing scripts in the appdb.

4 7

Re: Wine/Interix -- The pros and cons.
by Kuba Ober 25 Mar '06

25 Mar '06

On Saturday 25 March 2006 14:04, you wrote: > I have hands-on experience with it. I know that if you get the > abandonware X11 server, XDeep/32, and symlink the xdeep40.exe file (i > think that's it) to /usr/X11R6/bin/X (/dev/fs/C/xdeep32/bin/xdeep40.exe > -> /usr/X11R6/bin/X) you can use startx... > > And by the way, I use NetBSD pkgsrc on Interix (which is a supported > platform per the NetBSD pkgsrc site.) Interesting! One only hopes it's not bait-and-switch on MS's side. Cheers, Kuba

1 0

Bug 4806 - CpuDetect.dll missing (need help)
by Tom Spear 25 Mar '06

25 Mar '06

When trying to load up various apps, users are having problems with wine causing the program to say that certain files are missing, even when run from within the program directory (where the file that is supposedly missing is).. The problem has been narrowed down to this patch: http://www.winehq.org/pipermail/wine-cvs/2006-January/020072.html ..It seems to be that wine thinks the header is bigger than the file to be read. Louis Lenders and Tony Lambregts have narrowed it down to one line, which commenting out causes the programs to work.. After they added some traces to the code, it appears that the st.st_size variable is correct but the header_size variable is incorrect.. My question is where is wine pulling the header size from to fill into that variable to have given it the value that it is getting? And is there a simple (as well as proper) solution for this? Tom

1 0

Could not run Digital Mars C/C++ Compiler under Wine
by Igor Sysoev 25 Mar '06

25 Mar '06

When I try to run any program from Digital Mars C/C++ Compiler http://www.digitalmars.com/download/freecompiler.html under Wine 0.9.10 on FreeBSD 6.1, I always see the error: C:\dmc\bin>dmc wine: Unhandled stack overflow at address 0x405620 (thread 0017), starting debugger... WineDbg starting on pid 0x16 Couldn't initiate DbgHelp Unhandled exception: stack overflow in 32-bit code (0x00405620). file_set_error: Bad address file_set_error: Bad address Register dump: CS:0033 SS:003b DS:003b ES:003b FS:1007 GS:001b EIP:00405620 ESP:0035ff6c EBP:0035ffe8 EFLAGS:00010216( - 00 -RIAP1) EAX:00000000 EBX:9c297064 ECX:0035ff1c EDX:00000000 ESI:9c099460 EDI:00405620 Stack dump: 0x0035ff6c: 9c20b210 9c099460 00000000 00000000 0x0035ff7c: 00000000 ffffffff 9c1d1ff8 9c1e47ec 0x0035ff8c: 9c20b1a8 9c297064 0035ff6c 0035ffe8 0x0035ff9c: 00110000 00001000 0000127f 00000000 0x0035ffac: 00000000 00000000 00000000 00000001 0x0035ffbc: 00000000 00000000 00000000 00000000 0200: sel=1007 base=00110000 limit=00001fff 32-bit rw- Backtrace: =>1 0x00405620 (0x00405620) file_set_error: Bad address 0x00405620: -- no code accessible -- Modules: Module Address Debug info Name (0 modules) Threads: process tid prio (all id:s are in hex) 00000016 (D) C:\dmc\bin\dmc.exe 00000017 0 <== 00000008 00000009 0 Igor Sysoev http://sysoev.ru/en/

2 4

ilink32 hungs under Wine 0.9.10
by Igor Sysoev 25 Mar '06

25 Mar '06

When I try to link with ilink32.exe from C++ Builder Compiler and Command Line Tools ( http://appdb.winehq.org/appview.php?versionId=1423 ) ilink32 hangs. I saw comment on http://appdb.winehq.org/appview.php?versionId=1423 about changing ADDRESS_SPACE_LIMIT. Could be applied to 0.9.10 ? Igor Sysoev http://sysoev.ru/en/

1 1

monitoring OS API calls
by Saulius Krasuckas 25 Mar '06

25 Mar '06

Hi, I mean Windows there - my primary aim is to monitor WinAPI calls. There exists quite a few of monitor apps to achieve this. But their nature is soft-intrusive - they patch system DLLs on disk or PE images in memory. I'd like to monitor calling of a functions from a lower-level side. One possibility is to rewrite system DLLs, which is hard in a case of Windows. Maybe another possibility can be to run OS in machine emulator and to break on reading/executing some virtual memory addresses? I imagine physical memory maps into linear addresses which maps into virtual addresses (perhaps into unshared space of each win32 process). Then it would be nice to implement a Debug Logging similar to one from the Wine project. [*] What effort is needed to implement breaking of emulation on execution of given/defined virtual addresses (plus reading a CPU state and virtual memory) of different Windows OS versions inside machine emulator? Can such code be put as some plugin to BOCHS or so? Maybe I need to look at the different machine virtualization projects like Qemu? [*] http://winehq.org/site/developer-cheatsheet

3 2

Re: [opengl] Catch BadMatch errors before they can occur.
by Lionel Ulmer 25 Mar '06

25 Mar '06

> Oh, and this patch creates a new debug-channel 'swapbuffers' and puts > both opengl swapbuffers functions into it. What is the reason for this change ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 8

firefox dogfooding on 0.9.10 - png bux FIXED.
by Segin 25 Mar '06

25 Mar '06

As of 0.9.10, the bug which caused all PNGs in Firefox to appear inverse is fixed. Also, for developers with slower machines, try using Mozilla 1.7.x, it's much much faster than Firefox. It may not have *as many* bugs, but it still brings up the same exact OLE problems which Firefox does, so using it is just as useful here.

1 0

GetExitCodeProcess always returns 1
by Igor Sysoev 25 Mar '06

25 Mar '06

3 years ago I reported that on FreeBSD Wine-20030508's GetExitCodeProcess() always returns 1: http://www.winehq.org/hypermail/wine-devel/2003/06/0100.html This report included a small test case. It was fixed by patch: http://www.winehq.org/hypermail/wine-devel/2003/06/0381.html and I used the patched Wine-20030508 to run MSVC, OpenWatcom C, and Borland C in a command line. Recenty I build Wine-0.9.10 from ports on FreeBSD 6.1, but GetExitCodeProcess() still always returns 1. Igor Sysoev http://sysoev.ru/en/

7 23

Re: [winedoc] Resend Update to documentation
by Dimi Paun 24 Mar '06

24 Mar '06

On Wed, 2006-03-22 at 00:11 +1100, Jeff L wrote: > I assume that documentation patches still come here. Yes, they do. A few points however: -- please make patches from the root of the docs/, not from docs/en/ -- you need to refine a bit what your trying to say, I can not apply it in the current form. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

2 1

wine in "online news"
by Stefan Leichter 24 Mar '06

24 Mar '06

The german publishing company Heise Verlag reported in his online new http://www.heise.de/newsticker/meldung/71270 the availability of a plugin running Photoshop filters in GIMP on Linux using wine. For details look the authors blog at http://tml-blog.blogspot.com/2006/02/photoshop-filters-in-gimp-on-linux.html There might be a similar article in english language somewere in the WEB. Bye Stefan

1 0

CreateScalableFontResourceA: what does it mean?
by Hiji 24 Mar '06

24 Mar '06

There is this program, Cakewalk Sonar XL 2 (http://appdb.winehq.org/appview.php?versionId=2615) that I always try to run on Wine. The good news is, I can get it running, not smoothly, but it does run. However, it tries to utilize one of its own fonts, and always stubs on CreateScalableFontResourceA. It hits this: fixme:font:CreateScalableFontResourceA (0,"C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.FOR","C:\\PROG~FBU\\Cakewalk\\SONA~3TJ\\TTSNOTE.TTR",(null)): stub Then the app tells me the following in a popup: "Cannot create the Staff view musical symbol font." Anybody know what this means or have any workaround for making CreateScalableFontResourceA work? I've seen this problem since Dec. 2004, but since it hasn't gone away, I thought I'd pipe up and ask about it. Thanks in advance! Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 2

Problem with resolution
by Frederico Bertucci 24 Mar '06

24 Mar '06

Hello guys, I got a different problem I believe I'm trying run a application to develop interactive class, called VisualClass, if I start it with my kde resolution in 1280x1024, doesnt works, if i start it with my kde resolution in 800x600, doesnt works too, BUT if I start it with 800x600 and after change to 1280x1024 as soon its load, simply works, with 800x600, but works... I ckecked all configurations and components from wine, fonts, everything that I remember... There are anything to do ??... I am in a migration program, and this is one of the main of project... Tks. -- Frederico Bertucci e-mail / msn: fred(a)netbil.com.br www.netbil.com.br NetBil - Redes e Internet 18-3659-2444 XxX Linux for work Linux for fun XxX ________________________________________________ :: NetBil :: :: A escolha certa em Internet ::

1 0

Wine on FC5
by Kevin DeKorte 24 Mar '06

24 Mar '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been able to get Wine working on FC5, both from source and from RPM and neither seems to have the smooth font support. Is there some new option that is needed for FC5 support. I had Notes 6.51 working very nice under FC4, but it has some weird drawing issues in FC5. I'm guessing it has something to do with the new xorg packages, but any ideas would be helpful. Thanks, Kevin - -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEJCj2aR60qN0tF+8RApaaAKCo8pj6FAgoK7vHzBnGJ0jRZsV+5ACeL+kt jPJPYh8VeA8m2YIB2jreCsA= =1vFw -----END PGP SIGNATURE-----

1 0

Race condition in keyboard code?
by Peter Åstrand 24 Mar '06

24 Mar '06

Hi, I've been debugging a very strange keyboard problem this afternoon: In some cases the key combination AltGr+2 produces "2" (wrong) rather than "@" (correct), when using a Swedish layout. The problem seems to be a race condition: If a KeyEvent occurs almost directly after the "2" key is pressed, the AltGr state is incorrect. The problem has been verified with this simple test program: /* gcc -Wall xfake.c -o xfake -L/usr/X11R6/lib -lX11 -lXtst */ #include <X11/Xlib.h> #include <X11/extensions/XTest.h> int main( int argc, char* argv[] ) { Display* dpy; dpy = XOpenDisplay( NULL ); XTestFakeKeyEvent(dpy, 0x71, True, CurrentTime); XTestFakeKeyEvent(dpy, 0xb, True, CurrentTime); XSync(dpy, False); //sleep(1); XTestFakeKeyEvent(dpy, 0x71, False, CurrentTime); XTestFakeKeyEvent(dpy, 0xb, False, CurrentTime); XCloseDisplay( dpy ); return 0; } (0x71 is Mode_Switch, 0xb is the "2" key). I'm executing the program while having Wines Notepad active. If the sleep() is commented out, a "2" is inserted into Notepad. If the sleep() is active, "@" is inserted. More evidence: When debugging with WINEDEBUG=keyboard,key, the traces for X11DRV_ToUnicodeEx is printed after the Mode_Switch KeyRelease trace. Now I wonder, is this a problem with: 1) Wine or 2) The Windows API or 3) The way I'm using X11/the keyboard (generating events that quickly). ? I do understand why this happens: X11DRV_ToUnicodeEx uses the global, static variable AltGrMask. Is this a bug? Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

2 3

Re: SERVER: Only reset the notify event flag if there's no events pending.
by Alexandre Julliard 24 Mar '06

24 Mar '06

Mike McCormack <mike(a)codeweavers.com> writes: > diff --git a/server/change.c b/server/change.c > index 4349d7e..67a47af 100644 > --- a/server/change.c > +++ b/server/change.c > @@ -1130,7 +1130,7 @@ DECL_HANDLER(read_directory_changes) > dir->signaled--; > > /* clear the event */ > - if (event) > + if (event && !dir->signaled) > reset_event( event ); This breaks the tests: change.c:518: Test failed: action wrong change.c:522: Test failed: ov.Internal wrong change.c:523: Test failed: ov.InternalHigh wrong change.c:582: Test failed: should timeout change.c:590: Test failed: ov.Internal wrong change.c:603: Test failed: should timeout change.c:669: Test failed: should timeout make[1]: *** [change.ok] Error 7 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re:wine.inf: Add a shdocvw.dll stub dll to the system directory
by Louis. Lenders 24 Mar '06

24 Mar '06

What about adding a few more, like opengl32 (http://bugs.winehq.org/show_bug.cgi?id=3877) and some more (there are more of these bugs in bugzilla that can be solved that way, i could make a quick list of them if necessary) Regards Louis Module: wine Branch: refs/heads/master Commit: c3c112de231fae2f28d3f685c341a204ddef26a9 URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=c3c112de231fae2f28d3f68… Author: Mike McCormack <mike <at> codeweavers.com> Date: Wed Mar 22 23:46:31 2006 +0900 wine.inf: Add a shdocvw.dll stub dll to the system directory. --- tools/wine.inf | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf b/tools/wine.inf index 747eb83..17d9144 100644 --- a/tools/wine.inf +++ b/tools/wine.inf <at> <at> -2114,6 +2114,7 <at> <at> HKLM,%CurrentVersion%\Telephony\Country 11,,help.exe,winhelp.exe 11,,msiexec.exe 11,,notepad.exe +11,,shdocvw.dll 11,,progman.exe 11,,regsvr32.exe 11,,wcmd.exe ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

4 3

Re: [opengl] check drawable and context Visual IDs in wglMakeCurrent()
by Tomas Carnecky 24 Mar '06

24 Mar '06

Tomas Carnecky wrote: > Changelog: > - fail if the drawable and context Visual IDs don't match. > > why? because this will produce a BadMatch and crash the application so > instead of the crash rather return GL_FALSE and let the application > handle it. Please don't apply this patch yet. It fixes one case but there is more to be aware of. This BadMatch bug is triggered if an application creates a window (with a default Visual ID) and a custom (non-default) pixel format, the IDs were 0x21 and 0x23 in my case (glxinfo/xdpyinfo report Visual ID in the range from 0x21 to 0x70). But! I've seen that World of Warcraft calls wglMakeCurrent() with a darawable that has Visual ID 0x71 and a context with Visual ID 0x21. Now 0x71 is not defined (according to the glxino output) but it works fine, eg. glXMakeCurrent() doesn't produce the X Error in that case. So I went up the backtrace, into create_glxpixmap(). I let this function fail if it would produce a X Error, eg. if "depth of pixmap does not match the GLX_BUFFER_SIZE value of vis". Then I had to modify wglMakeCurrent() to respect the create_glxpixmap() failure and return FALSE. Works good so far, framerate in WoW went up from ~20 to up to 70 fps, average is somewhere between 40-50 !!! This is incredible. So.. in this attachment you'll find a patch that does what I've just described. I can't test it on anything else than WoW, so if someone would please review it and test with outher opengl/d3d applications it would be great. Also, it would be great if we could put the *Swap*Buffers() into their own log domain, something like 'swapbuffers', because the trace is usually useless, only when you explicitly look whether these functions are called or not, otherwise they only fill the log with garbage. thanks tom

4 6

Known issues area on main wiki page
by Tom Spear (Dustin Booker, Dustin Navea) 24 Mar '06

24 Mar '06

I'm not trying to be a whiner here, but I think enough is enough when it comes to having to close bugs as a duplicate. There has to be some simple solution to cut down on the number of new bugs filed that report that winecfg crashes when clicking on the audio tab. I know that the subject above isn't it, but it is at least a start. I was about to create it myself, but my better judgement said I should ask here first. Can someone please(!) put something on some page that almost everyone sees saying that if you are having a problem with winecfg crashing when clicking on the audio tab to check out bug 4051 first? Please! Thanks Tom

13 24

[PATCH] server/mailslot.c doesn't compile on certain systems. [Added ChangeLog]
by Segin 24 Mar '06

24 Mar '06

I have noticed that including stdint.h to server/mailslot.c fixes it for me. Those on wine-patches and not wine-devel, please CC any replies. ChangeLog: Includes stdint.h in server/mailslot.c, added comment explaining why. --- server/mailslot.c.orig 2006-03-23 22:37:32.000000000 -0500 +++ server/mailslot.c 2006-03-23 22:40:32.000000000 -0500 @@ -34,6 +34,8 @@ #include <stdlib.h> #include <sys/time.h> #include <sys/types.h> +/* include stdint.h cause of some systems breaking */ +#include <stdint.h> #ifdef HAVE_SYS_IOCTL_H #include <sys/ioctl.h>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel