March 2007 - Wine-Devel - list.winehq.org

Re: Patch to fix bug 892
by Juan Lang March 26, 2007

March 26, 2007

Hi Patrick, thanks for the patch. Unfortunately it's rather large, and doesn't just do what it says, so it's unlikely to get accepted as-is. For example: + For use in GetSystemInfo(), these are the offsets into the register array. Original version + isn't very clear what is meant by regs[0]. That may be, but this change isn't strictly necessary to fix bug 892. You may send that change as a separate patch if you like. As another example: + #if defined(_SC_PAGESIZE) + cachedsi.dwPageSize = (DWORD)sysconf(_SC_PAGESIZE); Using sysconf is another change you may wish to make, but doesn't address bug 892. Please send this change separately as well. Another: - cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; - cachedsi.lpMaximumApplicationAddress = (void *)0x7FFEFFFF; - cachedsi.dwActiveProcessorMask = 1; - cachedsi.dwNumberOfProcessors = 1; + cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; /* Lower 64kb of memory... */ + cachedsi.lpMaximumApplicationAddress = (void *)0x7FFFFFFF; /* Lower 2GB */ cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; - cachedsi.dwAllocationGranularity = 0x10000; + cachedsi.dwAllocationGranularity = 0x10000; /* */ Besides some of these changes being unnecessary (what's the meaning of an empty comment?) one is incorrect. The value 0x7ffeffff is not the same as 0x7fffffff. The former value was chosen for some braindead app, and changing it back would break it. As a general rule, patches should be: 1) independent - they should be able to be applied in one go, without depending on others. 2) correct - they shouldn't cause compile- or run-time breakages or regression test failures. 3) minimal - they should contain the least change necessary to accomplish what they set out to do, and they should set out to do just one thing. So, please have a go at separating your patch into multiple smaller ones and see where they go. Good luck! --Juan ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

1 0

Re: WineD3D: Use GL_TEXTURE_2D for dummy textures
by H. Verbeet March 26, 2007

March 26, 2007

On 26/03/07, Felix Nawothnig <flexo(a)holycrap.org> wrote: > As discussed in IRC. Probably won't apply without the last patch but > doesn't depend on it. > I think I missed that discussion.

2 2

Re: WineD3D: Use GL_TEXTURE_2D for dummy textures
by Stefan Dösinger March 26, 2007

March 26, 2007

> Stefan, you mentioned something about "colliding with the normal 2d > handling" - from the code I don't see any problems and since you got no > test app... tell me if there's anything wrong with this. > static void activate_dimensions(DWORD stage, IWineD3DStateBlockImpl *stateblock) { > + glDisable(GL_TEXTURE_1D); > + checkGLcall("glDisable(GL_TEXTURE_1D)"); With the dummy texture beeing 2D we should not need to ever disable GL_TEXTURE_1D. According to the red book GL_TEXTURE_2D is preferred over _1D, _3D over _2D and _CUBE over _3D. Thus we would not even need the glDisable(GL_TEXTURE_2D) and can just leave it enabled, except if the stage(or any before) has a colorop of D3DTOP_DISABLE. Pixel shaders ignore GL_ENABLE(GL_TEXTURE_xD)

1 0

Wine's official Coverity contact(s)
by Paul Vriens March 26, 2007

March 26, 2007

Hi, a few days ago I've received an email from Mikołaj Zalewski requesting an account for Coverity !? I know that in the past some of us dealt with Coverity already. I had a look at the new website and apparently things changed with respect to creating (and approving) new accounts. (Before the new website came alive I think just sending an email got you an account). I must say it's not clear to me how the process currently work but sending an email to scan-admin(a)coverity.com should do the trick. The approval then has to be done by the main contact(s). The next step will be that the main contact(s) will have some kind of administration rights to add/change/delete(?) accounts (at least that's how I understood it). I'm currently in contact with one of the Coverity guys and volunteered to be one of the main contacts. I had a look through the list of current users and all of them look valid to me. I think it will be good to have one or two more main contacts. So anyone volunteering? There will hardly be any work involved (I hope). Mainly dealing with approving new accounts and communicating things back to the Wine community. Cheers, Paul.

2 2

Re: [2/3] WineD3D: Implement bem shader instruction
by H. Verbeet March 26, 2007

March 26, 2007

On 26/03/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Another patch, hopefully I got the glsl part right this time. > dst_mask is redundant, but otherwise it looks fine to me.

1 0

Re: Patch to fix bug 892
by Steven Edwards March 26, 2007

March 26, 2007

On 3/25/07, Patrick Baggett <baggett.patrick(a)gmail.com> wrote: > There also was a problem with getting the number of processors. The old code > assumed always 1 processor. The new code uses POSIX interfaces, if > available, at compile time and correctly builds a bitmask of the active > processors. It seems to me this should really be detected at runtime. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re: Safedisc support (was: Road to 1.0)
by Timo Jyrinki March 25, 2007

March 25, 2007

Alexandre Julliard wrote: > And if we delay it a bit more maybe we can slip in Safedisc > support too... Regarding which, does anyone have more up-to-date code and/or information regarding Safedisc support, than what is currently on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? Safedisc support seems to be a topic that is hacked upon by various people every now and then, but it does not seem very coordinated. It'd be great if the wiki page would help to report on who's working on what etc., and maybe even provide usable patches for users to try. -Timo

4 4

re: Winebot
by Dan Kegel March 25, 2007

March 25, 2007

Vit wrote: > I'll write the manifest (a),(c) and post it onto Winebot Wiki. Cool... where is that? > I gladly accept any input to create a regression test repository, > would you be so kind and point me to some list of programs / test > miniprograms to make a reference implementation? I'd be glad to. I, Lei, and Nigel are just getting that going, and will be in touch via email. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: kernel32: MultiByteToWideChar: MB_USEGLYPHCHARS fix
by Robert Shearman March 25, 2007

March 25, 2007

Andrew O. Shadoura wrote: > break; > } > > + if (flags & MB_USEGLYPHCHARS) { > + for (i=0; i!=dstlen; i++) > + if (dst[i]<0x20) dst[i]=glyph_xlat[dst[i]]; > + } > + > I think you need to take into account the codepage when doing this translation. -- Rob Shearman

4 6

Game road to 1.0
by Stefan Dösinger March 25, 2007

March 25, 2007

Hi, In another thread Alexandre has mentioned to wait for game stuff to stabilize before the 1.0 freeze. I think its time for another brainstorm of what features are still missing which we want in 1.0. The DirectX Todo has a long list but it tends to be useless to me. And I see that it can use some more cleanup( /me blames Tom-W for not nagging me enough :-) ) It also sounds like AJ takes games as an excuse to delay the freeze for the display driver cleanup, and I was tempted to take the display driver cleanup as an excuse to get more dx stuff in. So which of the following things do we want for 1.0? Direct3D: * Some SM 3.0 features are still missing. Instancing is now in, vertex textures and some other stuff still missing. Not widely used among games yet. * Multithreading. OpenGL part done(except of 3 patches which I'll NOT send for now (*) ), but needs synchronisation. Will take a lot of time. * OpenGL ddraw. Render target locking improvements, multithreading. * Many games to not run yet, problems on MacOS drivers and fglrx. For the D3D part I see that as bugfixes which can happen after the freeze as far as I understand things. * Direct3D10. Will see if someone applies for my SoC proposal. (*) The patches that do the context selection. I won't send them because with my testing patches people started hunting phantom bugs which were the result of missing synchronisation. DirectSound: Maarten plans to work on that for SoC I think. Freezing now would make that difficult. Would mean to delay the freeze until September / October most at least. I'd personally really apprechiate dsound and alsa working better in 1.0. OpenGL: I don't really know of the windowed opengl state, and the wined3d -> wgl move. Still planned? DirectPlay: Kai works on the protocol, but I think he doesn't plan to implement it anytime soon. It seems the current idea is to improve our networking libs to get native dplay working.

6 11