April 2006 - Wine-devel - list.winehq.org

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