May 2005 - Wine-Devel - list.winehq.org

SEH and gcc again
by Daniel Kegel May 11, 2005

May 11, 2005

The old SEH / gcc question came up again on the gcc mailing list; see http://gcc.gnu.org/ml/gcc/2005-05/msg00511.html and followups. If anyone has anything constructive to add to that thread, this is a good chance to get the story right before it shows up on ZDNet.

1 0

Looking for win9x/ME testers
by Stefan Leichter May 11, 2005

May 11, 2005

Hello, the ole32 tests are working now for WinNT again: But they do not load on win9x/ME. Can someone with a Win9x/ME system run ole32_test.exe manualy and report the text displayed in the message box when it is started. ole32_test.exe is included in winetest-latest.exe. You can download winetest-latest.exe from http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ You will find ole32_test.exe in c:\temp\wct when the tests are performed. Thanks for your help Stefan

2 1

Flattening of ddraw directory and renaming of files
by Christian Costa May 11, 2005

May 11, 2005

Hi, I plan to flatten the ddraw directory and perform some files renaming in it. The changes I'm thinking about are in the attached file. If you have suggestions (or objections), let me know. If this is ok, I plan to submit the changes soon. Bye, Christian struct_convert.c \ convert.c -> ddraw_utils.c helper.c / d3dexecutebuffer.c -> executebuffer.c d3dmaterial.c -> material.c d3dvertexbuffer.c -> vertexbuffer.c main.c -> * regsvr.c -> * d3dcommon.c -> d3d_utils.c d3dlight.c -> light.c d3dtexture.c -> texture.c d3dviewport.c -> viewport.c mesa.c -> opengl.c d3d_private.h -> * ddcomimpl.h -> * ddraw_private.h -> * gl_api.h -> * gl_private.h -> * mesa_private.h -> opengl_private.h d3ddevice/main.c -> device_main.c d3ddevice/main.h -> device_main.h d3ddevice/mesa.c -> device_opengl.c dclipper/main.c -> clipper.c dclipper/main.h -> clipper.h ddraw/hal.c -> ddraw_hal.h ddraw/hal.h -> ddraw_hal.c ddraw/main.c -> ddraw_main.c ddraw/main.h -> ddraw_main.h ddraw/thunks.c -> ddraw_thunks.c ddraw/user.c -> ddraw_user.c ddraw/user.h -> ddraw_user.h direct3d/main.c -> direct3d_main.c direct3d/main.h -> direct3d_main.h direct3d/mesa.c -> direct3d_opengl.c dpalette/hal.c -> palette_hal.c dpalette/hal.h -> palette_hal.h dpalette/main.c -> palette_main.c dpalette/main.h -> palette_main.h dsurface/dib.c -> surface_dib.c dsurface/dib.h -> surface_dib.h dsurface/fakezbuffer.c -> surface_fakezbuffer.c dsurface/fakezbuffer.h -> surface_fakezbuffer.h dsurface/gamma.c -> surface_gamma.c dsurface/hal.c -> surface_hal.c dsurface/hal.h -> surface_hal.h dsurface/main.c -> surface_main.c dsurface/main.h -> surface_main.h dsurface/thunks.c -> surface_thunks.c dsurface/thunks.h -> surface_thunks.h dsurface/user.c -> surface_user.c dsurface/user.h -> surface_user.h dsurface/wndproc.c -> surface_wndproc.c dsurface/wndproc.h -> surface_wndproc.h Note: * = no change

5 9

Re: [QCAP] patch 3, Adding enumMediaType object
by Robert Shearman May 11, 2005

May 11, 2005

Rolf Kalbermatter wrote: >Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/qcap_main.h > dlls/qcap/enummedia.c > Add IEnumMediaType object for use by other class objects. This is >taken > from quartz with only minor adaptions. > > We should be putting these files into a static library that we can link to from quartz, qcap & other DirectShow dependent DLLs. Rob

2 1

Bug 2398
by Dustin Navea May 11, 2005

May 11, 2005

Lionel, it appears that bug 2398 is up your alley. sigh :) I was hoping it would be an easy fix.. Oh well. Its got something to do with the window/gl rewrite, if you could look at it and the regression causing patch when you get time, it would be appreciated. Thanks Dustin

3 2

(no subject)
by Jason Couture May 11, 2005

May 11, 2005

http://www.FreeMiniMacs.com/?r=18190345

1 0

Re: Commercial support
by Shachar Shemesh May 11, 2005

May 11, 2005

MediaHost (TM) wrote: > Hi All, > > I'm not sure, if winehq should be a platform for advertisements of > commercial services (except maybe codeweavers), otherwise there will > be a very long list there, very soon. That's good, in principle. The problem brought up during wineconf was that the lack of commercial support is viewed by potential deployers as a minus, making wine a dangerous technology. Saying "here is a list of companies willing to take your money and give you support" is actually a good thing for Wine. > And who to include and who not? Ah, there you have hit a more serious problem. For example, there is no doubt that CodeWeavers has been both a^Hthe major wine driving force, AND a financial sponsor. However, if we don't allow other companies room, we are unfair towards the other companies, towards CodeWeavers (why should they continue to be practically the only ones carrying the load), and towards Wine (and we don't want Wine to become a CodeWeavers subproject, do we?). I can suggest a simple rule to go by, as to whether to include a company or not. In order to be included, a company has to show that it has contributed (via it's employees or directly) a non-trivial patch to wine. We can even limit it to "in the past year". At the moment, I believe only three companies pass that criteria (CodeWeavers, Lingnu, and Dimi's company, whose name he has successfully kept secret, for some reason). Alternatively, we can have several lists. A "Gold" list, which includes companies that have the means to produce fixes to wine itself if necessary (as judged by the above criteria), and a normal list, which merely includes anyone who declares that they are willing to provide commercial support. I would have suggested a nominal fee (i.e. - a $50 contribution to the wine fund per year, or some such thing) from the last list. On the up side, it allows us to know the company is still active in this field. On the down side, I don't think we have the resources to start tracking who paid and who didn't. I could even suggest a platinum list, which would include any company that employs the equivalent of a full time Wine developer or up. Of course, this currently only includes CodeWeavers. The idea I'm trying to push here is that we can do such a list, so long as we keep clear objective criterias for who gets listed where. > Are there such plans to include such links on the website, except for > community based support? That's what we talked about over wineconf. It seems that such a list gives credibility to a project, and as such is a wanted thing. A company considering wine deployment is more likely to accept wine if they know they can get support for it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html

16 46

Re: Unknown stab type in crashes
by James Hawkins May 11, 2005

May 11, 2005

On 5/11/05, Andrew Neil Ramage <nrsc16850(a)blueyonder.co.uk> wrote: > Why not try grepping out the err:debug_help lines, so that you can read > the backtracve ? > I could do that, but the real question is do we have to display all of the debug_help error lines. The output occurrs every crash whether I'm using anything native or not. It seems to me that we could look into why we're running into unknown stab types or whether we can add handlers for these types so they wouldnt be unknown. -- James Hawkins

1 0

Re: listview: Send NM_CLICK notification when listview is clicked
by Alexandre Julliard May 11, 2005

May 11, 2005

James Hawkins <truiken(a)gmail.com> writes: > Hi, > > I verified this with native comctl32. > > Changelog > * Send NM_CLICK notification when listview is clicked. We already send NM_CLICK on button up, it doesn't look right to do it twice... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/msvcrt/files.c: Flush stdio buffers
by Alexandre Julliard May 11, 2005

May 11, 2005

wine.larry.engholm(a)xoxy.net writes: > One of the changes to file.c for revision 1.66 (2004/05/12) moved the > code to flush output buffers from _close() to MSVCRT_fclose(). The > latter function isn't called by msvcrt_free_io() which is called by > DllMain() for DLL_PROCESS_DETACH, so buffers are no longer flushed > when a program exits. Then it's msvcrt_free_io() that should be fixed, not _close(). -- Alexandre Julliard julliard(a)winehq.org

1 0