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

Crash in XOpenIM in wine 0.9.15

by Daniel Skorka

Hello, I want to bring an issue that has appeared on wine-users to your attention. The issue is basically this: Any time a process in wine tries to execute another process, wine will crash following a call to XOpenIM. For details please look here [1]. I'm sure Leigh is willing to provide any additional info required. regards, Daniel [1] http://www.winehq.org/pipermail/wine-users/2006-June/021973.html

June 13, 2006

Re: Broken FC5 packages - stay clear.

by Stephen Clark

Andreas Bierfert wrote: >On Mon, 12 Jun 2006 15:31:12 +0100 >Mike Hearn <mike(a)plan99.net> wrote: > > > >>On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: >> >> >>>Well from a wine perspective I see that this makes sense, but if you take a >>>look at all the dependencies it is another story... >>> >>> >>This is a problem with RPM and not with Wine. If RPM/yum had the concept >>of optional dependencies like some other systems do then this would really >>not be an issue. A better way to handle this would be to fix RPM, or >> >> > >It does know about this (don't quite remember the version it was introduced >with but it allows for that now). > > > >>simply to not mark them as dependencies at all yet still build the >>package with those features enabled. If the supporting libraries are >> >> > >This is just wrong packaging. Sorry if this sounds harsh but that cannot be the >solution and it never will be in Fedora Extras. > > > >>missing the features will be disabled at runtime usually with a message on >>stderr. >> >> > >Don't get me wrong... I am really happy that in the near future (1-2 years) >rpm and yum support for optional dependencies will be spread enough so it >solves a lot of issues like this one and I am really happy to make use >of it... but for now this is not an option, sadly... > > > >>The problem here is exactly the same as with Debian. This approach is >>just broken and should not be used. What if the user does not know about >> >> > >Hm maybe it is... but then I am no wine crack... splitting stuff up is >something you do in packaging and what really is encouraged by distributions. >Splitting stuff makes users happy and I can see why... ;) Looking over to >debian and thinking about the stuff that is installed by 'make install' got me >to the layout I have now... I don't say its perfect... it never was and it >probably never will be... that is why I like input from upstream... I am the >packager not the guy who did all the work on wine but I am the packager and I >know what is needed/wanted/regulated on the fedora side of the story. Together >with your input I am more than happy to change things around, just need people >upstream who are willing to listen and talk to packagers and I hope in this >case it will work. On thing I could offer which probably makes sense anyway is >to mention sub packages in the description or in a README-Fedora. > > > >>wine-tools and does not install it? They will be missing: >> >> * winecmd >> * notepad >> * winedbg >> * winepath >> * winhelp >> * _EXPLORER_ >> >>These may appear to to be optional but they are not. >> >>Explorer is needed for shell integration, HAL support and system tray >>support. It is not an end user tool, it's a part of the Wine >>infrastructure. >> >> > >Ok, will move explorer to the main wine package. > > > >>Winedbg is needed to produce useful crash data for developers. Notepad and >>winecmd are sometimes used by installers which will *fail silently* if >>they are missing. Winepath is used by various third party scripts. Winhelp >>is used by apps for online help, obviously. >> >> > >hm then maybe stuff should be merged to the main wine package for the stuff >mentioned above... will look into it and if you have further input and >suggestions rest assured that they are always welcome. > > > >>Gah. This is just frustrating. The same mistakes are made over and over >>and over again. And we are the ones who get to pick up the bugs. What was >>wrong with the way Vincent did it? >> >> > >Well for one thing: Direct them to me or https://bugzilla.redhat.com. I have >no problem with that and I stand for what I do. Maybe just maybe try to see the >packager/distro side of things and you will see that what Vincent did was great >work and is for certain things but for what is modern packaging and very >distribution specific to fedora or even fedora extras the way I did it is the >way to go... not by my opinion but the opinion and rules of the fedora >community... if you don't like it fine... ignore it, ignore me... but I'd >rather work together with you and the wine team on improving the wine >experience for users and not fighting here wasting time that could be better >spent improving the user situation. > >- Andreas > > > >------------------------------------------------------------------------ > > > > Well I found it frustrating the way it is packaged. I just deleted all the FC5 wine stuff and downloaded it from winehq. It is a shame you don't get the all the things you need without having to install 10 packages. My $.02, Steve Clark -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)

June 13, 2006

Re: What is needed to get more sites with a winetest executable

by Paul Vriens

On Tue, 2006-06-13 at 06:57 -0600, Andrew Ziem wrote: > Paul Vriens wrote: > >> Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: > >>> Hi, > >>> > >>> in the last months we've experienced several times that there was no > > winetest.exe available at the usual location > >>> (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several > > days/weeks. The reasons are sometimes known but in any case it's a > > Single Point Of Failure. > >>> What will it take to have multiple sites generating and hosting the > > winetest executable? Or do we already have this? > >>> Cheers, > >>> > >>> Paul. > >> Hi, > >> > >> not the answer to your question, but some thoughts about the topic. > >> > >> As long as the automatic build of Paul Millar works, there is not reason to > >> have a second winetest binary for nearly the same git/cvs source of the > > tests. One binary a day is enough. If you check > >> http://test.winehq.org/data/ > >> you will see that we miss often tests results for some windows platforms. > >> > >> If building the winetest binary fails. Someone needs to look into the > > reason > >> anyway. In almost all cases its a missing import in a library the test > > ist linked against. So first "our mingw environment" needs to be fixed. > > Just running another automatic build will fail with the same error as > > the build of > >> Paul. > >> > >> Its not hard for me to do the manual build. I just need some webspace to > > put > >> the stuff on. And i need to know what needs to be modified in the source > > before the build (somehow the build date need to be patched into the > > source). > >> Also the question is how the new build is announce to the public (hope that > >> it si not the case that it appears on astro.gla.ac.uk). > >> > > > > exactly my point. I know Paul Millar fixes stuff all the time by patches > > of you I think and Hans Leidekker (and others). But he is only one person, > > with of course a limited amount of time. > > > > Maybe we should have a few sites generating the winebuild and using a > > different path to publish stuff at test.winehq.org/data/[site]. We don't > > want to mix the output of different executables in one view (apples and > > pears). > > There are a limited number of winetest reports, but it's nice to be able > to see how a single test operates on a variety of systems. However, > having separate sites would fragment the reports. > > How about integrating all of winetest into winehq.org where there is a > primary maintainer and one or more backup maintainers? > > > Andrew > I wasn't talking about splitting the output. It was more like having a separate branch for every winetest-origin. Paul

June 13, 2006

Re: msvcrt[1/2]: add initial tests for dlls/msvcrt/data.c

by Andrew Ziem

Alexandre Julliard wrote: > Andrew Ziem <ahziem1(a)mailbolt.com> writes: > >> +typedef void (*_INITTERMFUN)(void); >> +unsigned int (WINAPI *p_initterm)(_INITTERMFUN *,_INITTERMFUN *); > > Msvcrt functions are not WINAPI. And why don't you simply call the > function directly instead of loading it dynamically? I found the second problem. To avoid warning implicit declaration of function ‘_initterm’ when compiling the test data.c, where should _initterm be declared? In a new dlls/msvcrt/data.h? Andrew

June 13, 2006

Re: What is needed to get more sites with a winetest executable

by Andrew Ziem

Paul Vriens wrote: >> Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: >>> Hi, >>> >>> in the last months we've experienced several times that there was no > winetest.exe available at the usual location >>> (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several > days/weeks. The reasons are sometimes known but in any case it's a > Single Point Of Failure. >>> What will it take to have multiple sites generating and hosting the > winetest executable? Or do we already have this? >>> Cheers, >>> >>> Paul. >> Hi, >> >> not the answer to your question, but some thoughts about the topic. >> >> As long as the automatic build of Paul Millar works, there is not reason to >> have a second winetest binary for nearly the same git/cvs source of the > tests. One binary a day is enough. If you check >> http://test.winehq.org/data/ >> you will see that we miss often tests results for some windows platforms. >> >> If building the winetest binary fails. Someone needs to look into the > reason >> anyway. In almost all cases its a missing import in a library the test > ist linked against. So first "our mingw environment" needs to be fixed. > Just running another automatic build will fail with the same error as > the build of >> Paul. >> >> Its not hard for me to do the manual build. I just need some webspace to > put >> the stuff on. And i need to know what needs to be modified in the source > before the build (somehow the build date need to be patched into the > source). >> Also the question is how the new build is announce to the public (hope that >> it si not the case that it appears on astro.gla.ac.uk). >> > > exactly my point. I know Paul Millar fixes stuff all the time by patches > of you I think and Hans Leidekker (and others). But he is only one person, > with of course a limited amount of time. > > Maybe we should have a few sites generating the winebuild and using a > different path to publish stuff at test.winehq.org/data/[site]. We don't > want to mix the output of different executables in one view (apples and > pears). There are a limited number of winetest reports, but it's nice to be able to see how a single test operates on a variety of systems. However, having separate sites would fragment the reports. How about integrating all of winetest into winehq.org where there is a primary maintainer and one or more backup maintainers? Andrew

June 13, 2006

Re: Broken FC5 packages - stay clear.

by Vitaliy Margolen

Tuesday, June 13, 2006, 1:14:00 AM, Andreas Bierfert wrote: > On Mon, 12 Jun 2006 15:31:12 +0100 > Mike Hearn <mike(a)plan99.net> wrote: >> On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: >> > Well from a wine perspective I see that this makes sense, but if you take a >> > look at all the dependencies it is another story... >> >> simply to not mark them as dependencies at all yet still build the >> package with those features enabled. If the supporting libraries are > This is just wrong packaging. Sorry if this sounds harsh but that cannot be the > solution and it never will be in Fedora Extras. And why isn't that a solution? That's what Wine already _does_. So what is the problem on your end? Just a principle? >> missing the features will be disabled at runtime usually with a message on >> stderr. > Don't get me wrong... I am really happy that in the near future (1-2 years) > rpm and yum support for optional dependencies will be spread enough so it > solves a lot of issues like this one and I am really happy to make use > of it... but for now this is not an option, sadly... Obviously you have never monitored this mailing list, looked at the source, bothered reading documentation. But that has nothing to do with rpm/deb/etc. That the the way Wine is made. It is built with few hard requirements. Most are soft requirements. >> wine-tools and does not install it? They will be missing: >> >> * winecmd >> * notepad >> * winedbg >> * winepath >> * winhelp >> * _EXPLORER_ >> >> These may appear to to be optional but they are not. >> >> Explorer is needed for shell integration, HAL support and system tray >> support. It is not an end user tool, it's a part of the Wine >> infrastructure. > Ok, will move explorer to the main wine package. You totally missed the point. You have to include _all_. Otherwise one part of Wine or another will brake. That's the main reason why I said that these packages are broken and that anyone reading this list should stay away from them. The only parts that you can possibly split are sound drivers, headers and debug package. Vitaliy

June 13, 2006

Martin Fuchs : shell32: SHELL32_GetItemAttributes()

by Rick Opper

hi, Like many wine users, I'm having trouble with programs calling the GetFolderAttributes... I've seen your patches and was wondering if it would be possible to download the pre-patched DLLs from somewhere. I'm running wine 0.9.15 and am surprised that the problem continues since the patch is so old... Thanks for your help, Rick Opper

June 13, 2006

Re: What is needed to get more sites with a winetest executable

by Paul Vriens

> Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: >> Hi, >> >> in the last months we've experienced several times that there was no winetest.exe available at the usual location >> (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several days/weeks. The reasons are sometimes known but in any case it's a Single Point Of Failure. >> >> What will it take to have multiple sites generating and hosting the winetest executable? Or do we already have this? >> >> Cheers, >> >> Paul. > Hi, > > not the answer to your question, but some thoughts about the topic. > > As long as the automatic build of Paul Millar works, there is not reason to > have a second winetest binary for nearly the same git/cvs source of the tests. One binary a day is enough. If you check > http://test.winehq.org/data/ > you will see that we miss often tests results for some windows platforms. > > If building the winetest binary fails. Someone needs to look into the reason > anyway. In almost all cases its a missing import in a library the test ist linked against. So first "our mingw environment" needs to be fixed. Just running another automatic build will fail with the same error as the build of > Paul. > > Its not hard for me to do the manual build. I just need some webspace to put > the stuff on. And i need to know what needs to be modified in the source before the build (somehow the build date need to be patched into the source). > Also the question is how the new build is announce to the public (hope that > it si not the case that it appears on astro.gla.ac.uk). > > Bye Stefan > Hi, exactly my point. I know Paul Millar fixes stuff all the time by patches of you I think and Hans Leidekker (and others). But he is only one person, with of course a limited amount of time. Maybe we should have a few sites generating the winebuild and using a different path to publish stuff at test.winehq.org/data/[site]. We don't want to mix the output of different executables in one view (apples and pears). Another thing what we could is just use a well-known-url for the winetest.exe like we did with the Mozilla ActiveX component. This url should of course point to the latest available on all site (don't know if that's feasible). Cheers, Paul.

June 13, 2006

Re: Vertex Buffer Objects for WineD3D

by Stefan Dösinger

> It will be better to move VBO creation and binding on vertexbuffer.c. (its > why GetMemory didn't provide VBO id before, no need for that) > Have you planned to use ti for index buffers too ? That was my first idea(just bind the vertex buffer in GetMemory and return the offset), but the problem is that dx apps may split vertices on multiple buffers. They may store the position in buffer 1 and the colors of vertices in buffer 2. GetMemory is called when the FVF or declaration is converted into strided data. The strided data contains pointers to the vertex data which may come from many different VBs. I have to bind the VBO the data is stored in when I pass the data pointer to gl in LoadVertexArrays. This is perfectly ok for GL(and not a performance issue), but I need the VBO number in the strided data to know where each data comes from. > > The vertex conversion is slow, and it turned out that if the app Locks > > the Buffer every frame then drawStridedSlow is faster Converting + > > drawStridedSlow. Because of that VBOs and the conversion aren't used for > > vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not > > loaded into a vbo. > > For that problem i had a prototype who remembered too many lock (in small > times) and active the no-VBO flag :) I considered the same thing, considering that the app may be bad-behaved and set bad flags. Remembering the application's behavior seemed to be better. However, I noticed that even well behaved apps(e.g. battlefield 1942) don't keep all the geometry they use in a map in vertex buffers at all time. Instead they load the area around the player, and load new stuff and throw away the old while the player moves through the map. As a result wined3d gets a bunch of IWineD3DVertexBuffer::Lock calls sporadically. Depending on the behavior of the player that is different. E.g. if a sniper stays at one place all the time there isn't much reload, but if he's flying a plane there is constantly new data. I couldn't think of any good heurisitics which could detect all that stuff, so I decided to rely on the flags set by the app. After all, the application developers know best what happens, and D3D8 and D3D9 apps are quite well-behaved compared to DDraw / D3D7 apps. (Even if we can find a good way to handle the bf1942 and hl2 cases perfectly, who can say if we won't find a game which does something perfectly valid and fools our algorithms) The same problem applies to textures and render targets, btw. For textures it can be solved quite well, render targes are more tricky. Stefan

June 13, 2006

Re: What is needed to get more sites with a winetest executable

by Stefan Leichter

Am Montag, 12. Juni 2006 20:22 schrieb Paul Vriens: > Hi, > > in the last months we've experienced several times that there was no > winetest.exe available at the usual location > (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several > days/weeks. The reasons are sometimes known but in any case it's a > Single Point Of Failure. > > What will it take to have multiple sites generating and hosting the > winetest executable? Or do we already have this? > > Cheers, > > Paul. Hi, not the answer to your question, but some thoughts about the topic. As long as the automatic build of Paul Millar works, there is not reason to have a second winetest binary for nearly the same git/cvs source of the tests. One binary a day is enough. If you check http://test.winehq.org/data/ you will see that we miss often tests results for some windows platforms. If building the winetest binary fails. Someone needs to look into the reason anyway. In almost all cases its a missing import in a library the test ist linked against. So first "our mingw environment" needs to be fixed. Just running another automatic build will fail with the same error as the build of Paul. Its not hard for me to do the manual build. I just need some webspace to put the stuff on. And i need to know what needs to be modified in the source before the build (somehow the build date need to be patched into the source). Also the question is how the new build is announce to the public (hope that it si not the case that it appears on astro.gla.ac.uk). Bye Stefan

June 13, 2006

WINED3D: Bug 5418

by H. Verbeet

http://bugs.winehq.org/show_bug.cgi?id=5418 The code in question does look a bit dodgy. Bad merge perhaps?

June 13, 2006

Re: wined3d: Another GLSL shader status update

by H. Verbeet

On 13/06/06, Raphael <fenix(a)club-internet.fr> wrote: > Well it will not be suficient to begin hacking on wined3d > (as only wined3d shaders architecture is explained) The rest is easy ;-)

June 13, 2006

Re: Broken FC5 packages - stay clear.

by Andreas Bierfert

On Mon, 12 Jun 2006 15:31:12 +0100 Mike Hearn <mike(a)plan99.net> wrote: > On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: > > Well from a wine perspective I see that this makes sense, but if you take a > > look at all the dependencies it is another story... > > This is a problem with RPM and not with Wine. If RPM/yum had the concept > of optional dependencies like some other systems do then this would really > not be an issue. A better way to handle this would be to fix RPM, or It does know about this (don't quite remember the version it was introduced with but it allows for that now). > simply to not mark them as dependencies at all yet still build the > package with those features enabled. If the supporting libraries are This is just wrong packaging. Sorry if this sounds harsh but that cannot be the solution and it never will be in Fedora Extras. > missing the features will be disabled at runtime usually with a message on > stderr. Don't get me wrong... I am really happy that in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues like this one and I am really happy to make use of it... but for now this is not an option, sadly... > The problem here is exactly the same as with Debian. This approach is > just broken and should not be used. What if the user does not know about Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;) Looking over to debian and thinking about the stuff that is installed by 'make install' got me to the layout I have now... I don't say its perfect... it never was and it probably never will be... that is why I like input from upstream... I am the packager not the guy who did all the work on wine but I am the packager and I know what is needed/wanted/regulated on the fedora side of the story. Together with your input I am more than happy to change things around, just need people upstream who are willing to listen and talk to packagers and I hope in this case it will work. On thing I could offer which probably makes sense anyway is to mention sub packages in the description or in a README-Fedora. > wine-tools and does not install it? They will be missing: > > * winecmd > * notepad > * winedbg > * winepath > * winhelp > * _EXPLORER_ > > These may appear to to be optional but they are not. > > Explorer is needed for shell integration, HAL support and system tray > support. It is not an end user tool, it's a part of the Wine > infrastructure. Ok, will move explorer to the main wine package. > Winedbg is needed to produce useful crash data for developers. Notepad and > winecmd are sometimes used by installers which will *fail silently* if > they are missing. Winepath is used by various third party scripts. Winhelp > is used by apps for online help, obviously. hm then maybe stuff should be merged to the main wine package for the stuff mentioned above... will look into it and if you have further input and suggestions rest assured that they are always welcome. > Gah. This is just frustrating. The same mistakes are made over and over > and over again. And we are the ones who get to pick up the bugs. What was > wrong with the way Vincent did it? Well for one thing: Direct them to me or https://bugzilla.redhat.com. I have no problem with that and I stand for what I do. Maybe just maybe try to see the packager/distro side of things and you will see that what Vincent did was great work and is for certain things but for what is modern packaging and very distribution specific to fedora or even fedora extras the way I did it is the way to go... not by my opinion but the opinion and rules of the fedora community... if you don't like it fine... ignore it, ignore me... but I'd rather work together with you and the wine team on improving the wine experience for users and not fighting here wasting time that could be better spent improving the user situation. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

June 13, 2006

Re: wined3d: GLSL Patch feedback requested

by H. Verbeet

On 13/06/06, Raphael <fenix(a)club-internet.fr> wrote: > I only have one question: > i see you have a cache to reuse prgid in set_glsl_shader_program but what > happens if user/app change the shaders content (for example using > SetFunction) ? your pre-compiled program will be correct ? > (because i don't see any list cleanup in shaders function reset) Good point :-) I wonder if respecifying the source and recompiling the program is worth it, or if we should just create a new shader object. > - It is correct to have GLSL binding code out of "if > (useVertexShaderFunction)" block ? It is, actually. If there's no shader in use, we need to tell GL to use fixed function again. The glUseProgramObjectARB call takes care of that. (programId is zero when no shaders are in use).

June 13, 2006

Re: Vertex Buffer Objects for WineD3D

by Raphael

On Monday 12 June 2006 13:40, Stefan Dösinger wrote: > Hi, > This is an updated version of the VBO patch. The main difference is the > integration with IWineD3DDevice::ProcessVertices which gives a nice > performance boost for Half-Life 1 and propably Anarchy Online(not tested > yet). It will be better to move VBO creation and binding on vertexbuffer.c. (its why GetMemory didn't provide VBO id before, no need for that) Have you planned to use ti for index buffers too ? > What is missing is work with vertex shaders(awaiting the download of the > dx8 sdk for the dolphin demo) and an implementation of > IDirect3DVertexbuffer7::ProcessVertices. > The vertex conversion is slow, and it turned out that if the app Locks the > Buffer every frame then drawStridedSlow is faster Converting + > drawStridedSlow. Because of that VBOs and the conversion aren't used for > vertex buffers in system memory and vbs with WINED3DUSAGE_DYNAMIC are not > loaded into a vbo. For that problem i had a prototype who remembered too many lock (in small times) and active the no-VBO flag :) > Cheers, > Stefan

June 12, 2006

Re: wined3d: GLSL Patch feedback requested

by Raphael

On Thursday 08 June 2006 17:35, Jason Green wrote: > The current cumulative patch is located here: > > http://cmhousing.net/wine/glsl_cumul.diff > I hate you, reviewing all this patch made me crazy. Anyway is an impressive work I only have one question: i see you have a cache to reuse prgid in set_glsl_shader_program but what happens if user/app change the shaders content (for example using SetFunction) ? your pre-compiled program will be correct ? (because i don't see any list cleanup in shaders function reset) And many comments: void inline drawPrimitiveDrawStrided(IWineD3DDevice *iface, BOOL useVertexShaderFunction, BOOL usePixelShaderFunction, int useHW, WineDirect3DVertexStridedData *dataLocations, UINT numberOfvertices, UINT numberOfIndicies, GLenum glPrimType, const void *idxData, short idxSize, int minIndex, long StartIdx) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; @@ -1791,91 +1920,59 @@ #endif TRACE("Loaded arrays\n"); + /* Bind the correct GLSL shader program based on the currently set vertex & pixel shaders. */ + if (wined3d_settings.shader_mode == SHADER_GLSL) { + GLhandleARB programId; + + set_glsl_shader_program(iface); + programId = This->stateBlock->shaderPrgId; + + if (programId != 0) { + /* Start using this program ID */ + TRACE_(d3d_shader)("Using GLSL program %u\n", programId); + GL_EXTCALL(glUseProgramObjectARB(programId)); + checkGLcall("glUseProgramObjectARB"); + } + } + if (useVertexShaderFunction) { - - It is correct to have GLSL binding code out of "if (useVertexShaderFunction)" block ? - i think moving binding code (GLSL and ARB) on a new base shader method (ex IWineD3DBaseShaderImpl_Bind) will be cleaner (and permit to not have GLS/ARB code in drawprim) - same for shaders constant loading Best Regards, Raphael

June 12, 2006

Re: wined3d: Another GLSL shader status update

by Raphael

On Sunday 11 June 2006 22:24, Mike Hearn wrote: > On Tue, 06 Jun 2006 13:55:15 -0400, Jason Green wrote: > > FYI - I just added a bunch to this page to get us started: > > > > http://wiki.winehq.org/DirectX-Shaders > > That's awesome, exactly the sort of thing I was looking for. This sort of > high level overview is very useful for new hackers! :) :) Well it will not be suficient to begin hacking on wined3d (as only wined3d shaders architecture is explained) Anyway Most of code is splitted in "logical" sources ... and documented when needed: for shaders/declaration: baseshader.c, glsl_shader.c, pixelshader.c, vertexshader.c, vertexdeclaration.c for textures: basetexture.c, cubetexture.c, texture.c, volumetexture.c for surfaces: surface.c, surface_gdi.c, others who have d3d compliant names: :) device.c, directx.c, drawprim.c, indexbuffer.c, palette.c, query.c, resource.c, stateblock.c, swapchain.c, utils.c, vertexbuffer.c, volume.c, wined3d_main.c Only one thing to new hackers: never begin with device.c :) Regards, Raphael

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Detlef Riekenberg

Dmitry Timoshkov wrote: > "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > What would you suggest me to do? > > Make yourself an expert in the area you are trying to improve. I try to do that for almost a year now for winspool / Printing. > Read MSDN, Done for many Functions. MSDN is not complete and not Error-Free. > books, Many of them. Do not forget the Oldies (Oldies are goldies!): They do not depend on MFC / DotNet / C# As an Example, my old win3.1 - Book has Descriptions for every Entry in "win.ini" / "system.ini" > find code samples on the net, Most samples still does not work. > write the tests on your own. I started with an app, that call the winspool.drv - API by the Commandline. Now, i do most extensions directly for the Testsuite. -- By By ... ... Detlef

June 12, 2006

What is needed to get more sites with a winetest executable

by Paul Vriens

Hi, in the last months we've experienced several times that there was no winetest.exe available at the usual location (http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/) for several days/weeks. The reasons are sometimes known but in any case it's a Single Point Of Failure. What will it take to have multiple sites generating and hosting the winetest executable? Or do we already have this? Cheers, Paul.

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Tue, 13 Jun 2006, Dmitry Timoshkov wrote: > * "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > > > > > Make yourself an expert in the area you are trying to improve. Read > > > MSDN, books, find code samples on the net, write the tests on your > > > own. > > Perhaps you would even become a high quality specialist in that area and > could star earning more money for your life. That's very lose dependency. It is required, yes, but not sufficient. Besides, priorities in my life is to avoid money as much as I can. Does this practically discourage me from helping Wine? ;-) > Oh year, speculating about the source of the book which you don't want > to read is much more productive than actually learning something. Are you sure I haven't read "Windows 95 Secrets" by Matt Pietrek? BTW, it was printed in your native language ;-) [switching to private communication mode] > > But, Dmitry, you haven't answered the question about the legitimity of > > the analysis from the mentioned bug [*] yet. I state it was collected > > by reverse engineering. Should I erase my memory or ask Tony to > > delete appropriate DB records from the bugzilla? ;-) > > Are you talking about http://bugs.winehq.org/show_bug.cgi?id=2081 ? Yes.

June 12, 2006

FIXED: Running siap and modules under wine, first steps

by Alex Villacís Lasso

Maximiliano Curia wrote: > On Monday 26 September 2005 15:00, Alex Villacís Lasso wrote: > >> --- wine-20050830-cvs/dlls/oleaut32/typelib.c 2005-09-21 >> 10:39:22.000000000 -0500 >> +++ wine-20050830-cvs-patch/dlls/oleaut32/typelib.c 2005-09-24 >> 20:34:32.000000000 -0500 >> > > >> This patch executes the "create interface" code when typekind == >> TKIND_DISPATCH >> and wTypeFlags has TYPEFLAG_FDISPATCHABLE, regardless of the value of >> hRefType, >> in addition to the previous condition. >> > > I backported this patch to the version 20050310. > If you are willing to let the test application available I could check the > successfullness. > > >> --- wine-20050830-cvs/dlls/ole32/defaulthandler.c 2005-09-23 >> 10:51:36.000000000 -0500 >> +++ wine-20050830-cvs-patch/dlls/ole32/defaulthandler.c 2005-09-25 >> 19:19:31.000000000 -0500 >> @@ -1422,7 +1422,7 @@ >> * This is necessary because it's the only time the non-delegating >> * IUnknown pointer can be returned to the outside. >> */ >> - if (pUnkOuter && IsEqualIID(&IID_IUnknown, riid)) >> + if (pUnkOuter && !IsEqualIID(&IID_IUnknown, riid)) >> return CLASS_E_NOAGGREGATION; >> >> /* >> > > IsEqualIID was introduced after the version 20050310 that I'm using, and it > seem that the: > if ( (pUnkOuter!=NULL) && > (memcmp(&IID_IUnknown, riid, sizeof(IID_IUnknown)) != 0) ) > was replaced wrongly replaced. > > The (pUnkOuter && !IsEqualIID(&IID_IUnknown, riid)), should have the same > efect as the previous code. > > >> Mr. Maximiliano Curia, could you please indicate where to get sample >> modules for SIAP? The default installer >> doesn't seem to come with any modules inside. Of course, this might be >> yet another Wine bug, so please confirm. >> > > Yes, of course, they are in: > http://www.afip.gov.ar/seccion_rg.asp#programas > > The most used are: > ftp://www.afip.gov.ar/iva40/iva_v4r1.exe (Taxes) > ftp://www.afip.gov.ar/sijyp25/sijyp.25r0.exe (Pensions) > > Although, there are different programs for different activities (and I use 12 > of these programs), these two are used by most of them. > > As of 2006-06-09, the CVS snapshot of Wine seems to run SIAP correctly. No crashes at all. Could you please be so kind as to test with the *most recent CVS snapshot* and confirm? Alex Villacís Lasso

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Tue, 13 Jun 2006, Dmitry Timoshkov wrote: > * "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > > > What would you suggest me to do? To annoy everyone on the list during > > 2 years by asking for a tutorial on how to debug dx game which draws > > black menu? ;-) > > Make yourself an expert in the area you are trying to improve. Read > MSDN, books, find code samples on the net, write the tests on your own. Sometimes comparing traces is easier than buying a book, for which I have no money or is more ethical than reading a book, which perhaps was written by a reverse engineer about his knowlegde, don't you think so? But, Dmitry, you haven't answered the question about the legitimity of the analysis from the mentioned bug [*] yet. I state it was collected by reverse engineering. Should I erase my memory or ask Tony to delete appropriate DB records from the bugzilla? ;-)

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: >> * "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: >> > >> > What would you suggest me to do? To annoy everyone on the list during >> > 2 years by asking for a tutorial on how to debug dx game which draws >> > black menu? ;-) >> >> Make yourself an expert in the area you are trying to improve. Read >> MSDN, books, find code samples on the net, write the tests on your own. > > Sometimes comparing traces is easier than buying a book, IMO you'd spend that 2 years much more productively by learning how the things work instead of trying to understand gibberish of the traces. Perhaps you would even become a high quality specialist in that area and could star earning more money for your life. > for which I have > no money Do the libraries exist in your area? > or is more ethical than reading a book, which perhaps was written > by a reverse engineer about his knowlegde, don't you think so? Oh year, speculating about the source of the book which you don't want to read is much more productive than actually learning something. > But, Dmitry, you haven't answered the question about the legitimity of the > analysis from the mentioned bug [*] yet. I state it was collected by > reverse engineering. Should I erase my memory or ask Tony to delete > appropriate DB records from the bugzilla? ;-) Are you talking about http://bugs.winehq.org/show_bug.cgi?id=2081 ? -- Dmitry.

June 12, 2006

Re: Gnome and KDE wine configuration tools

by Yuriy

> > > Guidance : > --------------- > Its not completely wine configuration utility, but a general > purpose system configuration utility for KDE. It now has got some > module for configuring WINE also. I got this news from > http://dot.kde.org/1150047999/. I havent tested it, but it can be got > from here http://www.simonzone.com/software/guidance/ > > Conclusion, its for you all to decide which is the best tool. And not > to forget give some valuable inputs to the developers to improve. > > Thanks, > Vijay > Hi, I'm the one making that. There's nothing much to test yet (need to get busier!), and it's not on the site, it's in SVN. Input is good of course. ~Yuriy

June 12, 2006

Re: Alexandre Julliard : riched20: Fix an uninitialized variable bug.

by Marcus Meissner

On Mon, Jun 12, 2006 at 10:02:35AM -0500, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: fe4c4780eb0a047f09a2e536eeaa1f51434b4b61 > URL: http://source.winehq.org/git/?p=wine.git;a=commit;h=fe4c4780eb0a047f09a2e53… > > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Mon Jun 12 16:09:50 2006 +0200 > > riched20: Fix an uninitialized variable bug. > > Mark todo a test that depended on the bug to succeed. And I wondered if only I was seeing this bug ;) Ciao, Marcus

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Andreas Bierfert

On Mon, 12 Jun 2006 15:41:16 +0100 Mike Hearn <mike(a)plan99.net> wrote: > There seems to be another issue here ... you removed the rpath code with a > link to two bugs that don't seem to indicate that was causing the problem. > > Now I appreciate that given RPMs are not relocatable it makes no > difference to your users but I am concerned that a problem apparently > unconnected to it caused this change. Vendor patches are bad, for Wine > they usually either mask upstream bugs or cause them. Well, for Fedora rpath are considered bad and as wine does not allow for --disable-rpath (which I would rather use) I applied this patch to get rid of them (and solve the problems that they where causing. Maybe fedora is broken in a way here or maybe it is not but rpath need to go out for the Fedora Extras rpm and if this fixes some bugs which are only there on fedora and the fedora rpms I am glad to close the according bugs (and leave a not the changelog so I remember what I did). - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Alexandre Julliard

Damjan Jovanovic <dj015(a)yahoo.com> writes: > So what's the story, are you accepting any > ReactOS-derived patches for dlls/setupapi/devinst.c, > or do I need to start writing my own? No ReactOS-derived code will be accepted in Wine at this point. -- Alexandre Julliard julliard(a)winehq.org

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > What would you suggest me to do? To annoy everyone on the list during 2 > years by asking for a tutorial on how to debug dx game which draws black > menu? ;-) Make yourself an expert in the area you are trying to improve. Read MSDN, books, find code samples on the net, write the tests on your own. -- Dmitry.

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: >* On Mon, 12 Jun 2006, Mike McCormack wrote: >> * Saulius Krasuckas wrote: >> > >> > And what if interface is blackboxed? >> >> I don't know what a "blackboxed interface" is. If you could name the >> interface you're talking about it would be easier to understand what you >> mean. > > I remember that last one was GetUName!getuname: > > [2] http://www.winehq.org/pipermail/wine-devel/2006-June/048500.html That one doesn't count (there were enough explanations why). Another one? -- Dmitry.

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Mike Hearn

There seems to be another issue here ... you removed the rpath code with a link to two bugs that don't seem to indicate that was causing the problem. Now I appreciate that given RPMs are not relocatable it makes no difference to your users but I am concerned that a problem apparently unconnected to it caused this change. Vendor patches are bad, for Wine they usually either mask upstream bugs or cause them. Specifically the libGL problem is a bug in that users setup (maybe in Fedora), and I don't think it's in Wine. I don't see where the /usr/lib/nvidia search path is coming from - if it's LD_LIBRARY_PATH then we should be using DT_RUNPATH in Wine and not DT_RPATH so we should fix it. If it's in the linker config then you are relying on a very particular combination of factors which may be true for some binaries shipped with Fedora but are not guaranteed by the ELF or Linux ABIs - you can't have a /usr/lib/libGL.so.1 and always expect it to lose to /usr/lib/nvidia/libGL.so.1! thanks -mike

June 12, 2006

re: WM_GETICON patch

by Dan Kegel

Mike Hearn wrote: > ... obviously WM_GETICON > requires inter-process bitmaps to be supported in some fashion, which is a > fair bit of work. Maybe for efficiency reasons even requiring the dreaded > remote thread creation/service thread :) Adding support for remote thread creation is on Tommy Kho's to-do list. (Probably just for linux and nptl initially.) - Dan

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Mike Hearn

On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote: > Well from a wine perspective I see that this makes sense, but if you take a look > at all the dependencies it is another story... This is a problem with RPM and not with Wine. If RPM/yum had the concept of optional dependencies like some other systems do then this would really not be an issue. A better way to handle this would be to fix RPM, or simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are missing the features will be disabled at runtime usually with a message on stderr. The problem here is exactly the same as with Debian. This approach is just broken and should not be used. What if the user does not know about wine-tools and does not install it? They will be missing: * winecmd * notepad * winedbg * winepath * winhelp * _EXPLORER_ These may appear to to be optional but they are not. Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure. Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously. Gah. This is just frustrating. The same mistakes are made over and over and over again. And we are the ones who get to pick up the bugs. What was wrong with the way Vincent did it? -m

June 12, 2006

Re: msvcrt[1/2]: add initial tests for dlls/msvcrt/data.c

by Andrew Ziem

Alexandre Julliard wrote: >> +typedef void (*_INITTERMFUN)(void); >> +unsigned int (WINAPI *p_initterm)(_INITTERMFUN *,_INITTERMFUN *); > > Msvcrt functions are not WINAPI. Thanks for catching that. > And why don't you simply call the > function directly instead of loading it dynamically? Dynamic loading was the easier solution to the problem "LINK : fatal error LNK1104: cannot open file 'MSVCRT.lib'" when compiling with MSVC7. Now, I found msvcrt.lib, so I'll test and resubmit. Andrew

June 12, 2006

Re: WM_GETICON patch

by Chris

On Monday 12 June 2006 06:42, Mike Hearn wrote: > Actually images are stored as pixmaps in the X server, so it'd be awfully > convenient if we could leverage that but I suspect the need to support > non-X display systems means we have to do it the hard way, by shovelling > image bits across the socket. Actaully you couldn't anyway, according to dlls/user/cursoricon.c: * This layout is very sub-optimal, as the bitmap bits are stored in * the X client instead of in the server like other bitmaps; however, * some programs (notably Paint Brush) expect to be able to manipulate * the bits directly :-( How would you allocate memory that could be shared between processes (either implicitly, or with a way to "transform" a pointer for one process to another)? Would that be an acceptable work around until something better is made?

June 12, 2006

Re: Gnome and KDE wine configuration tools

by Mike Hearn

Hmm, Wine Doors looks pretty cool. At least, it seems to have a nice UI. Though I question how much preset "profiles" can achieve these days ... we're getting closer to not needing them all the time. Maybe if the profiles can do things like install native MSI/DCOM/MDAC/InternetExplorer etc it might prove handy for end users.

June 12, 2006

Re: WM_GETICON patch

by Mike Hearn

On Sun, 11 Jun 2006 20:26:11 -0700, Chris wrote: > Aren't icons already created on the global heap? They're created with > GlobalAlloc16, and (optionally) added to a link list of shared icons. No, this is a confusing Win32ism. The "global heap" is not actually global, it's process-local. There *is* a shared heap in Windows 9x but not in NT. GDI objects are stored in the kernel in Windows, and so are "shared" via that mechanism. We do the same thing by moving things into the wineserver and transporting them via RPC. Actually images are stored as pixmaps in the X server, so it'd be awfully convenient if we could leverage that but I suspect the need to support non-X display systems means we have to do it the hard way, by shovelling image bits across the socket. thanks -mike

June 12, 2006

x11drv: set window manager icon hints correctly

by Juris Smotrovs

Currently, for many applications the generic Wine icon or a class default icon is used in window manager caption or taskbar instead of the application icon set with WM_SETICON. See, for instance, Bug 3370. What actually happens is this: the application icon is correctly set when processing WM_SETICON, but a bit later, when window is mapped, X11DRV_set_wm_hints resets it back to class default (or to none, leading to Wine icon). It seems that X11DRV_set_wm_hints has been designed to be called only when creating a window: it alocates WM hints -- XAllocWMHints() -- instead of checking for existing ones with XGetWMHints(...), and sets class default icon, instead of checking whether another icon has been set in the meantime. However, calls to X11DRV_set_wm_hints have been added at mapping a window and changing window style (see x11drv/winpos.c). Thus, Wine currently allocates WM hints anew and resets icon at every mapping and style change of a window. I attach a patch to X11DRV_set_wm_hints correcting this issue: 1) it checks for existing WM hints before allocating new ones, 2) it resets icon to class default only if no icon hint has been set earlier. Please, let me know if you see anything wrong with this patch. Cheers, Juris

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Damjan Jovanovic

--- Peter Beutner <p.beutner(a)gmx.net> wrote: > Mike McCormack wrote: > > Christian Gmeiner wrote: > >> Partially implement SetupDiGetClassDevsExA. This > patch bases on > >> reactos setupapi.dll. > > > > Don't be suprised if your patch isn't accepted. > ReactOS is considered a > > dirty reverse engineering project by many, and > Alexandre has rejected > > patches using their code before. > I thought they started auditing their code and > removing any "dirty" parts? > And according to their website this process is > nearly done. > > btw. using their code as documentation to implement > something on wine > should be safe nevertheless, shouldn't it? > > > The fact that some developers work both on > tinykrnl (a self-admitted > > 'dirty' reverse engineering effort) and ReactOS at > the same time should > > be enough to show you that they're walking close > to, or maybe over the > > fine line. > > > > Please don't post ReactOS code to wine-patches > again. > hm I thought direct code sharing wasn't even > possible before because of > the different licenses(GPL<->LGPL)? Only the ReactOS kernel is GPL, other parts have other licences. And they took SETUPAPI from us so it's still licenced under the LGPL. Am I to understand that if I want SetupDiGetClassDevsExW() and some other APIs I need for the still image system, I need to write them without even looking at the ReactOS code? I think that's unfair, the ReactOS SETUPAPI doesn't look reverse-engineered, everything in there conforms to the MSDN documentation and it's too incomplete to be reverse-engineered. Making such harsh judgements about one API (which they derived from wine and changed a little) just because of the bad reputation of some other parts of ReactOS is wrong, IMO. So what's the story, are you accepting any ReactOS-derived patches for dlls/setupapi/devinst.c, or do I need to start writing my own? > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

June 12, 2006

Re: winmm: Add support for "open new" commands.

by Eric Pouech

2006/6/11, Eric Pouech <eric.pouech(a)wanadoo.fr>: > > Peter Åstrand wrote: > > > On Sat, 10 Jun 2006, Eric Pouech wrote: > > > >>> ChangeLog: > >>> winmm: Add support for "open new" commands. > >> > >> > >> looks globally good, except that you don't enforce that you got a > >> correct device name ie I'm not sure that 'open new type waveaudio' > >> works (without the alias) > > > > > > I'm not sure I understand what you mean, how is the alias related to > > the verification of a correct device name? > > it's not. but I don't think a command like 'open new type waveaudio' > shall work (as the name of the MCI device would be new in that case, > which is a reserved keyword). In other words, I think that 'open new' > should fail if no alias is given. for the sake of completeness, I tested it on Windows: mciSendString("open new type wavedaudio", ...) fails with the error MCIERR_NEW_REQUIRES_ALIAS. This must be properly handled before submission into Wine. A+ -- > Eric Pouech

June 12, 2006

Re: Vertex Buffer Objects for WineD3D

by Stefan Dösinger

Hi, This is an updated version of the VBO patch. The main difference is the integration with IWineD3DDevice::ProcessVertices which gives a nice performance boost for Half-Life 1 and propably Anarchy Online(not tested yet). What is missing is work with vertex shaders(awaiting the download of the dx8 sdk for the dolphin demo) and an implementation of IDirect3DVertexbuffer7::ProcessVertices. Cheers, Stefan

June 12, 2006

Re: WineD3D: Fog fixes, try 3

by Stefan Dösinger

This is another update of the fog patch, it makes the BOOL warned static. ChangeLog: Stefan Dösinger(for CodeWeavers): Correct vertex fog for transformed vertices and correctly handle non-vertex, non-table fog

June 12, 2006

Re: WineD3D: Fog fixes, try 2

by Stefan Dösinger

Am Montag, 12. Juni 2006 10:51 schrieb H. Verbeet: > On 11/06/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > >+ BOOL warned = FALSE; > >+ if(!warned) { > >+ /* TODO: Use the fog table code from old ddraw */ > >+ FIXME("Implement fog for transformed > > vertices in software\n"); > > >+ warned = TRUE; > >+ } > > Shouldn't "warned" be static here? Or am I misunderstanding what this > is supposed to do? Right...

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Mon, 12 Jun 2006, Mike McCormack wrote: > * Saulius Krasuckas wrote: > > > > And what if interface is blackboxed? > > I don't know what a "blackboxed interface" is. If you could name the > interface you're talking about it would be easier to understand what you > mean. I remember that last one was GetUName!getuname: [2] http://www.winehq.org/pipermail/wine-devel/2006-June/048500.html

June 12, 2006

Re: msvcrt[1/2]: add initial tests for dlls/msvcrt/data.c

by Alexandre Julliard

Andrew Ziem <ahziem1(a)mailbolt.com> writes: > +typedef void (*_INITTERMFUN)(void); > +unsigned int (WINAPI *p_initterm)(_INITTERMFUN *,_INITTERMFUN *); Msvcrt functions are not WINAPI. And why don't you simply call the function directly instead of loading it dynamically? -- Alexandre Julliard julliard(a)winehq.org

June 12, 2006

Re: uxtheme efforts (wanted/needed ?)

by Alexandre Julliard

"Paul Vriens" <paul.vriens(a)xs4all.nl> writes: > I've sent 2 emails that are (for now) silently ignored: > > http://www.winehq.org/pipermail/wine-patches/2006-June/027253.html > http://www.winehq.org/pipermail/wine-patches/2006-June/027350.html > > They both have to do with uxtheme and were meant as a starter for > conformance tests and of course the fixes to it. I first wanted to start > with input/return paramater and value testing before I touch any > functional part (maybe not mutually exclusive). > > Was there anything wrong with the patches? How can I improve or what do I > have to change? I'm not a big fan of patches that add a lot of infrastructure without visible need. For instance the new draw.c test is basically empty. I understand you are planning to add more tests to it, but please only add test files once they contain enough code to make it clear that a new file is justified (the new system.c is fine in that respect). -- Alexandre Julliard julliard(a)winehq.org

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Mon, 12 Jun 2006, Dmitry Timoshkov wrote: > * "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > > > > > Yes, but how would you write a test for a badly implemented > > > > function, when you don't know its name or even name of a DLL it > > > > resides in? > > > > > > Then by what means do you know that the API is misbehaving? > > > > By the fact of my special app [*] not working in Wine ;-) > > I see nothing there which shows that a test case couldn't be written. Would you been seeing this similar way if Vincent P. hadn't made his discovered? And what if this discovery was made by reverse engineering the code? > Moreover, there is nothing there described in the 1st paragraph above. Lets say we have got only 22 numbers of responces in the report [*]. What would you suggest me to do? To annoy everyone on the list during 2 years by asking for a tutorial on how to debug dx game which draws black menu? ;-) > > [*] http://bugs.winehq.org/show_bug.cgi?id=2081

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Hans Leidekker

On Monday 12 June 2006 12:04, Andreas Bierfert wrote: > > Good, but shouldn't zlib-devel be pulled in like that too then? > > Oh... don't even mention discussions on what should be in the minimal build > root and what shouldn't ;) I'm not, this isn't about the minimal build system. zlib-devel should be pulled in through whatever package depends on it. > It is :) gphoto2 is pulled in by sane? I believe... anyway last time I > checked (0.9.14) it was pulled in :) Right, but gphoto2 is a direct Wine dependency, so it would be better IMO to support it as such. It's also more flexible, i.e this way a user could choose to install gphoto2 but not sane support. -Hans

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Mon, 12 Jun 2006, Mike McCormack wrote: > * Saulius Krasuckas wrote: > > > > Mike, and how would you describe API monitoring method of > > understanding how the stuff works? > > You mean using +relay? IMO, that's a legitimate way of understanding how > things work. Not exactly. What about strace.exe or stracent.exe under real windows? > If it's done using black box techniques, IMO, it's legitimate. > > Finding out how an public _interface_ behaves for various inputs and > outputs is legitimate, IMO. > > Examining piece of assembly to determine _implementation_ is not, IMO. Ok, let go further than my primary question. And what if interface is blackboxed? Would you consider analysis of a stack and CPU registers during a breakpoint at the very beginning of API call legitimate? In real windows, of course. That's about some data passing through an interface, not about some code assembly. > This is assuming that _interfaces_ are not copyright-able, whereas > _implementations_ are. Of course. But when interfaces gets hidden, we start walking on the low-level line where interface details border implementation details. No? > If there's a program that uses it, then we can get a sample input. Of course I spoke about real programs. Example was Diablo (v1), where I just hadn't enough skills to understand what here doesn't work. Later I opened a bug report (2 years ago). Now I think tracing the game in windows would help me. > I am *not* giving legal advice. This is my interpretation of how > interoperability with Windows programs should be legitimately achieved, > and what standards Wine contributors should live up to. That's fine, Mike. I understand that disc^H^H^H^Hpart pretty well, I hope :)

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Hans Leidekker

On Monday 12 June 2006 11:37, Andreas Bierfert wrote: > Why is there no BuildRequires for freetype? gphoto2? We also have > >These two are pulled in by other dependencies and thus don't need an explicit >listing (e.g. freetype by fontconfig-devel). Good, but shouldn't zlib-devel be pulled in like that too then? > zlib-devel on the other hand is not in the minimal buildroot :) Like Marcus said, freetype-devel is probably missing a dependency on zlib-devel. Wine doesn't directly depend on zlib-devel AFAICT. And it would be nice if you could add gphoto2 support. -Hans

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Marcus Meissner

On Mon, Jun 12, 2006 at 11:29:32AM +0200, Hans Leidekker wrote: > On Monday 12 June 2006 00:03, Andreas Bierfert wrote: > > > For more details take a look here: > > http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras > > Why is there no BuildRequires for freetype? gphoto2? We also have > a soft dependency on glibc-devel for dns resolver support. gcc depends > on glibc-devel so you maybe you don't need to list it explicitly. On > the other hand you do list zlib-devel. Does Wine directly depend on it? zlib is needed for freetype2. perhaps it is missing in freetype2-devel. Ciao, Marcus

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Mon, 12 Jun 2006, Dmitry Timoshkov wrote: > * "Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: > > > > Yes, but how would you write a test for a badly implemented function, > > when you don't know its name or even name of a DLL it resides in? > > Then by what means do you know that the API is misbehaving? By the fact of my special app [*] not working in Wine ;-) [*] http://bugs.winehq.org/show_bug.cgi?id=2081

June 12, 2006

Re: Broken FC5 packages - stay clear.

by Hans Leidekker

On Monday 12 June 2006 00:03, Andreas Bierfert wrote: > For more details take a look here: > http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras Why is there no BuildRequires for freetype? gphoto2? We also have a soft dependency on glibc-devel for dns resolver support. gcc depends on glibc-devel so you maybe you don't need to list it explicitly. On the other hand you do list zlib-devel. Does Wine directly depend on it? -Hans

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Mike McCormack

Saulius Krasuckas wrote: > And what if interface is blackboxed? I don't know what a "blackboxed interface" is. If you could name the interface you're talking about it would be easier to understand what you mean. Mike

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: >> > Yes, but how would you write a test for a badly implemented function, >> > when you don't know its name or even name of a DLL it resides in? >> >> Then by what means do you know that the API is misbehaving? > > By the fact of my special app [*] not working in Wine ;-) > > > [*] http://bugs.winehq.org/show_bug.cgi?id=2081 I see nothing there which shows that a test case couldn't be written. Moreover, there is nothing there described in the 1st paragraph above. -- Dmitry.

June 12, 2006

Re: WineD3D: Fog fixes, try 2

by H. Verbeet

On 11/06/06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >+ BOOL warned = FALSE; >+ if(!warned) { >+ /* TODO: Use the fog table code from old ddraw */ >+ FIXME("Implement fog for transformed vertices in software\n"); >+ warned = TRUE; >+ } Shouldn't "warned" be static here? Or am I misunderstanding what this is supposed to do?

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Saulius Krasuckas

* On Sat, 10 Jun 2006, Mike McCormack wrote: > * Peter Beutner wrote: > > > > I think the problem is that the way you describe is totally legal in > > most countries. > > In fact, afaik it is only in the USA where you have this explicit > > distinction between clean("chinese wall") and "dirty" reverse > > engineering. > > This is not simply a problem of what is legal and not in different > countries. > > We don't want to be associated project that is perceived to be pushing > the edge of what's legally (or even socially) acceptable. Doing so > would encourage FUD about Wine and that's a good way to lose developers > and users. Mike, and how would you describe API monitoring method of understanding how the stuff works? Does its use for finding misbehaved functions make Wine look like it pushes the edge? > Using test cases to determine the behaviour of Windows provides a way to > verify both the code that's written today, and code that will be written > a year later. It's not just legally better, it's easier to do, easier > for others to understand, and gives us a way to verify our code. Yes, but how would you write a test for a badly implemented function, when you don't know its name or even name of a DLL it resides in?

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Dmitry Timoshkov

"Saulius Krasuckas" <saulius2(a)ar.fi.lt> wrote: >> Using test cases to determine the behaviour of Windows provides a way to >> verify both the code that's written today, and code that will be written >> a year later. It's not just legally better, it's easier to do, easier >> for others to understand, and gives us a way to verify our code. > > Yes, but how would you write a test for a badly implemented function, when > you don't know its name or even name of a DLL it resides in? Then by what means do you know that the API is misbehaving? -- Dmitry.

June 12, 2006

Re: setupapi.dll: partially implement SetupDiGetClassDevsExA

by Mike McCormack

Saulius Krasuckas wrote: > Mike, and how would you describe API monitoring method of understanding > how the stuff works? You mean using +relay? IMO, that's a legitimate way of understanding how things work. > Does its use for finding misbehaved functions make > Wine look like it pushes the edge? If it's done using black box techniques, IMO, it's legitimate. Finding out how an public _interface_ behaves for various inputs and outputs is legitimate, IMO. Examining piece of assembly to determine _implementation_ is not, IMO. This is assuming that _interfaces_ are not copyright-able, whereas _implementations_ are. > Yes, but how would you write a test for a badly implemented function, when > you don't know its name or even name of a DLL it resides in? If there's no program that uses that function, then it's not necessary that for Wine to implement it, so it doesn't matter. If there's a program that uses it, then we can get a sample input. Wine is concerned with interoperability with programs written for the Win32 API. We don't care how other implementations of the Win32 API work, we only care what is required for programs to work. I am *not* giving legal advice. This is my interpretation of how interoperability with Windows programs should be legitimately achieved, and what standards Wine contributors should live up to. Mike

June 12, 2006

uxtheme efforts (wanted/needed ?)

by Paul Vriens

Hi, I've sent 2 emails that are (for now) silently ignored: http://www.winehq.org/pipermail/wine-patches/2006-June/027253.html http://www.winehq.org/pipermail/wine-patches/2006-June/027350.html They both have to do with uxtheme and were meant as a starter for conformance tests and of course the fixes to it. I first wanted to start with input/return paramater and value testing before I touch any functional part (maybe not mutually exclusive). Was there anything wrong with the patches? How can I improve or what do I have to change? Cheers, Paul

June 12, 2006

Re: iphlpapi: forward Icmp* functions to icmp.dll

by Molle Bestefich

Dmitry Timoshkov wrote: > In XP SP2 it's icmp.dll who forwards its entry points to iphlpapi.dll, > so we need to move some code around to accomplish the same thing. Curious; what happens when this is implemented and wine is running in eg. win98 mode? Won't there technically be a discrepancy of some sort?

June 12, 2006

Re: iphlpapi: forward Icmp* functions to icmp.dll

by Dmitry Timoshkov

"Steven Edwards" <winehacker(a)gmail.com> wrote: > On 6/11/06, Simon Kissane <skissane(a)gmail.com> wrote: >> In WinXP, these functions are implemented in iphlpapi.dll as well as >> icmp.dll (Win2000). >> They are already in Wine's icmp.dll, so forward the iphlpapi to icmp.dll > > Being its a small amount of code in icmp.dll I think we should just > duplicate it. Our dependancies should really match windows and the > last time I looked iphlpapi did not depend on icmp.dll in win2k. In XP SP2 it's icmp.dll who forwards its entry points to iphlpapi.dll, so we need to move some code around to accomplish the same thing. -- Dmitry.

June 12, 2006

Gnome and KDE wine configuration tools

by Vijay Kiran Kamuju

Hi, I was just looking at browsing net for some linux stuff. I just happend to see some news related to wine Wine-doors : ------------------ Its just a wine installation utility for GNOME with preliminary(very basic and primitive) wine configuration.It has support for multiple installations, from screenshots i think so. I got this news from here http://gnomedesktop.org/node/2689, and more information can be got from its web site http://www.wine-doors.org/ Guidance : --------------- Its not completely wine configuration utility, but a general purpose system configuration utility for KDE. It now has got some module for configuring WINE also. I got this news from http://dot.kde.org/1150047999/. I havent tested it, but it can be got from here http://www.simonzone.com/software/guidance/ Conclusion, its for you all to decide which is the best tool. And not to forget give some valuable inputs to the developers to improve. Thanks, Vijay

June 11, 2006

Re: iphlpapi: forward Icmp* functions to icmp.dll

by Steven Edwards

On 6/11/06, Simon Kissane <skissane(a)gmail.com> wrote: > In WinXP, these functions are implemented in iphlpapi.dll as well as > icmp.dll (Win2000). > They are already in Wine's icmp.dll, so forward the iphlpapi to icmp.dll Being its a small amount of code in icmp.dll I think we should just duplicate it. Our dependancies should really match windows and the last time I looked iphlpapi did not depend on icmp.dll in win2k. -- 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

June 11, 2006

Re: WM_GETICON patch

by Chris

On Sunday 11 June 2006 13:42, Mike Hearn wrote: > Well I guess this is a slight improvement but obviously WM_GETICON > requires inter-process bitmaps to be supported in some fashion, which is a > fair bit of work. Aren't icons already created on the global heap? They're created with GlobalAlloc16, and (optionally) added to a link list of shared icons. Since HICONs are really just void pointers, would something need to be done to transform the pointer for the receiving thread to see the same memory (assuming different processes need different pointers to see the same memory area)? I'm not too read up on how shared memory actually works.

June 11, 2006

Re: Broken FC5 packages - stay clear.

by Andreas Bierfert

On Sun, 11 Jun 2006 21:39:30 +0100 Mike Hearn <mike(a)plan99.net> wrote: > We had this problem with Debian, where people didn't install the "utils" > package and apps broke mysteriously. Unless you have a lot of experience > of Wine debugging you cannot detect this easily ... please, there's no > reason to split this stuff up as Wine will load everything in a failsafe > fashion so there is no need to mark the package as depending on a million > things. Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story... installing wine is one thing... ending up with zillion dependencies is a whole different story for lots of people where e.g. bandwidth is still a problem or which rather want to have a slim system. I as a packager sit between the chairs and in this case I see why splitting up wine made sense in debian and why it made sense for Fedora Extras as well. The question is what to split and what to leave in. The stuff that has been split from just having one 'wine' package is stuff that made sense and in ways interacts best with what Fedora Core ships with the distro. Sure there are improvements to be made and suggestions are always welcome :) but doing it the way it is done now made lots of people happy (and gave me positive feedback). > Out of interest what are the 11 packages? wine wine-arts wine-capi wine-cms wine-esd wine-jack wine-ldap wine-nas wine-tools wine-twain These are the 10 packages which are relevant for a 'normal' user where wine and wine-tools are the major ones. They are build from the wine sources (without winemp3). Then there is: wine-debuginfo wine-devel These two are more or less only interesting for packagers/developers etc. For more details take a look here: http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras And of course build from the wine-docs sources is the wine-docs rpm: wine-docs http://cvs.fedora.redhat.com/viewcvs/rpms/wine-docs/?root=extras > thanks -mike no problem. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

June 11, 2006

Re: DDraw: New ddraw lib

by Jesse Allen

On 6/11/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > > Oops, I didn't know about the option. It's running with GDI. But just > > replacing the DDraw library sped it up. Probably depth conversion? > > OpenGL don't work. > Hmm. No idea. SURFACE_GDI should be as fast as the old ddraw code, the > rendering is the same. > > There is a registry key, HKLU\software\wine\direct3d\DirectDrawRenderer. It > can be set to "gdi" to force gdi surfaces, or "opengl" to force opengl > surfaces. If "gdi" is set, Direct3D is mutually disabled. > > But still it is interesting that it is faster... > > > The slowness is observed in the multiplayer mode with another peer, not single player, and without your patch. With your patch, the slowness is gone. When you have another peer, the game fires off many udp packets to keep each other in sync. So each game packet basically tells the peers what actions the user it performing. Once you get packets from all the peers for each game "second" it updates the state of the game, and probably draws the screen accordingly. So the net code in the game while in this mode directly affects the drawing speed. Perhaps it is something with our net code causing the slowness, but your patch counteracts somehow, perhaps architechurely since you really made no code changes to the GDI part. (Note with DGA, I believe fixes the slowness too so...) Jesse

June 11, 2006

Re: WM_GETICON patch

by Mike Hearn

On Sat, 10 Jun 2006 16:35:45 -0700, Chris wrote: > Originally GeoShell would show no icon on the taskbar and print > a lot of fixme messages about it being unsupported. With this patch it now > (always) shows the Wine glass icon for programs, with no such fixme messages. Well I guess this is a slight improvement but obviously WM_GETICON requires inter-process bitmaps to be supported in some fashion, which is a fair bit of work. Maybe for efficiency reasons even requiring the dreaded remote thread creation/service thread :) thanks -mike

June 11, 2006

Re: Icmp* functions in iphlpapi.dll

by Mike Hearn

On Sat, 10 Jun 2006 21:37:01 -0500, Carl Fongheiser wrote: > Bad, bad idea. In Windows programming, you *never* call LoadLibrary from > DllMain. Inside of DllMain, you can't call anything which uses the loader > lock, because the loader lock is already taken out. As best as I read the > Wine code, it has the same limitation. Loader lock is a recursive critical section so it's OK to do that from the same thread and actually, the Wine loader code is written to allow that to work. That said it's quite dangerous to do much of anything inside a DllMain because so much stuff in Win32 relies on multiple threads or inter-thread messaging behind your back. thanks -mike

June 11, 2006

Re: Broken FC5 packages - stay clear.

by Mike Hearn

On Sun, 11 Jun 2006 11:09:10 +0200, Andreas Bierfert wrote: > Yes it is (ok more like 11 but ok). For me it works for the programs it should > work on... We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things. Out of interest what are the 11 packages? thanks -mike

June 11, 2006

Re: My new hero...

by Mike Hearn

On Tue, 06 Jun 2006 22:43:27 -0700, Dan Kegel wrote: > Mike, what was that you were saying about > there not being any wine hackers who fixed > problems all around the wine tree anymore? I consider myself joyfully corrected! :) Go Qingdao!

June 11, 2006

Re: wined3d: Another GLSL shader status update

by Mike Hearn

On Tue, 06 Jun 2006 13:55:15 -0400, Jason Green wrote: > FYI - I just added a bunch to this page to get us started: > > http://wiki.winehq.org/DirectX-Shaders That's awesome, exactly the sort of thing I was looking for. This sort of high level overview is very useful for new hackers! :) thanks -mike

June 11, 2006

Re: winmm: Add support for "open new" commands.

by Eric Pouech

Peter Åstrand wrote: > On Sat, 10 Jun 2006, Eric Pouech wrote: > >>> ChangeLog: >>> winmm: Add support for "open new" commands. >> >> >> looks globally good, except that you don't enforce that you got a >> correct device name ie I'm not sure that 'open new type waveaudio' >> works (without the alias) > > > I'm not sure I understand what you mean, how is the alias related to > the verification of a correct device name? it's not. but I don't think a command like 'open new type waveaudio' shall work (as the name of the MCI device would be new in that case, which is a reserved keyword). In other words, I think that 'open new' should fail if no alias is given. > > Perhaps the patch can be applied with a FIXME for the case you are > talking about, since we would then at least have partial support for > "open new"? that shouldn't be too hard to add. A+

June 11, 2006

Re: winmm: Add support for "open new" commands.

by Peter Åstrand

On Sat, 10 Jun 2006, Eric Pouech wrote: >> ChangeLog: >> winmm: Add support for "open new" commands. > > looks globally good, except that you don't enforce that you got a > correct device name ie I'm not sure that 'open new type waveaudio' works > (without the alias) I'm not sure I understand what you mean, how is the alias related to the verification of a correct device name? Perhaps the patch can be applied with a FIXME for the case you are talking about, since we would then at least have partial support for "open new"? Regards, -- Peter Åstrand ThinLinc Chief Developer Cendio http://www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

June 11, 2006

Re: WineD3D: Fog fixes, try 2

by Stefan Dösinger

Hi, Apply this patch instead, the old patch had some sloppiness error(setting FOGSTART as FOGEND when restoring z-based fog). The problem is corrected in this patch. It also doesn't add a senseless space at the begin of the file and sets the fog to GL_FASTEST for vertex fog and GL_NICEST for table / pixel fog. ChangeLog: Stefan Dösinger(for CodeWeavers): Correct vertex fog for transformed vertices and correctly handle non-vertex, non-table fog

June 11, 2006

Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER (FIXED)

by Andrew Ziem

Andrey Turkin wrote: > Andrew Ziem wrote: >> Please use this patch instead of previous "user3.patch". Thanks to >> Andrey Turkin for catching the uninitialized variable. >> >> changelog: >> user: handle special cases for SPI_SETDESKWALLPAPER >> >> The special cases remove the wallpaper or set it to default. >> Previously, these cases were ignored, so Wine would crash. >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> - if (filename == (LPSTR)-1) >> + if ((LPCSTR)SETWALLPAPER_DEFAULT == filename || (LPCSTR)NULL == >> filename || '\0' == filename[0]) >> { >> - GetProfileStringA( "desktop", "WallPaper", "(None)", buffer, 256 ); >> - filename = buffer; >> + /* set default wallpaper or remove wallpaper*/ >> + if (hbitmapWallPaper) >> + DeleteObject( hbitmapWallPaper ); >> + return TRUE; >> } >> hdc = GetDC( 0 ); > > According to MSDN, if > - pvParam==SETWALLPAPER_DEFAUL || pvParam==NULL, then wallpaper will be > set to default one > - pvParam[0]=='\0', then wallpaper will be removed. > I cannot see any signs of such distinction in your code :) When I ran the unit test on Windows 2000, that's what it did: in all three cases (SETWALLPAPER_DEFAULT, NULL, or '\0'), Windows 2000 removed the wallpaper. So, it seems the default wallpaper is no wallpaper, and a test could be added to show that. (I already have a test that checks the default wallpaper is the same on both SETWALLPAPER_DEFAULT and NULL). Beyond the cosmetics of changing the wallpaper, the purpose of the new code is to keep Wine from crashing on SETWALLPAPER_DEFAULT. Andrew

June 11, 2006

Re: DDraw: New ddraw lib

by Stefan Dösinger

Hi, > Oops, I didn't know about the option. It's running with GDI. But just > replacing the DDraw library sped it up. Probably depth conversion? > OpenGL don't work. Hmm. No idea. SURFACE_GDI should be as fast as the old ddraw code, the rendering is the same. There is a registry key, HKLU\software\wine\direct3d\DirectDrawRenderer. It can be set to "gdi" to force gdi surfaces, or "opengl" to force opengl surfaces. If "gdi" is set, Direct3D is mutually disabled. But still it is interesting that it is faster...

June 11, 2006

Re: Broken FC5 packages - stay clear.

by Andreas Bierfert

On Sat, 10 Jun 2006 17:31:22 -0600 Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > It seems that FC5 packager created a broken Wine distribution. I don't think I did... ;) > Instead of being 1-3 packages it's 15 (from what user told me on #winehq. > And it doesn't work at all: > "Application tried to create a window, but no driver could be loaded." Yes it is (ok more like 11 but ok). For me it works for the programs it should work on... > Which tells me it's compiled without X headers. I didn't even new Wine could > compile without X, since we don't have tty driver. Be sure it is compiled with everything that FC/FE{3,4,5,devel} can support. The only thing is that some stuff is split out into subpackages and if users want that support they need to install it. Take a look at debian for example. Fedora Extras wine layout is basically the same. For the X driver... that should work out of the box so I suspect that the user has a different problem. In any way direct FE wine users to http://bugzilla.redhat.com to file bug against wine. This way I can easily track such bugs and decide if they should be filed against wine or if it really is a packaging but. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

June 11, 2006

Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER (FIXED)

by Andrey Turkin

Andrew Ziem wrote: > Please use this patch instead of previous "user3.patch". Thanks to > Andrey Turkin for catching the uninitialized variable. > > changelog: > user: handle special cases for SPI_SETDESKWALLPAPER > > The special cases remove the wallpaper or set it to default. > Previously, these cases were ignored, so Wine would crash. > > > > ------------------------------------------------------------------------ > > > > - if (filename == (LPSTR)-1) > + if ((LPCSTR)SETWALLPAPER_DEFAULT == filename || (LPCSTR)NULL == filename || '\0' == filename[0]) > { > - GetProfileStringA( "desktop", "WallPaper", "(None)", buffer, 256 ); > - filename = buffer; > + /* set default wallpaper or remove wallpaper*/ > + if (hbitmapWallPaper) > + DeleteObject( hbitmapWallPaper ); > + return TRUE; > } > hdc = GetDC( 0 ); According to MSDN, if - pvParam==SETWALLPAPER_DEFAUL || pvParam==NULL, then wallpaper will be set to default one - pvParam[0]=='\0', then wallpaper will be removed. I cannot see any signs of such distinction in your code :)

June 11, 2006

Re: WM_GETICON patch

by Chris

I updated the patch a little more to handle WM_QUERYDRAGICON as well (something else that was complained about with GeoShell), since it's dealt with similarly to WM_GETICON (lparam is unused and an HICON is returned in the result). An odd effect now is that apps are showing one of GeoShell's arrows for program icons in the taskbar, whereas before it was the Wine glass. I didn't change anything directly relating to WM_GETICON, so I have no idea what could have caused it to change like that.

June 11, 2006

Re: getuname: add stub implementation [try 4]

by Dmitry Timoshkov

"Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > Just curious, what application besides charmap.exe uses getuname.dll? > > You are right, I guess it was charmap.exe > Is it unuseful dll? If nobody else besides charmap.exe uses that dll then yes, it's not useful for Wine at this point. Since interfaces of getuname are not documented it's clearly Windows internal dll, and chances are small that anybody else will use it. -- Dmitry.

June 10, 2006

Re: Icmp* functions in iphlpapi.dll

by Dmitry Timoshkov

"Simon Kissane" <skissane(a)gmail.com> wrote: > In Win2000, the ICMP functions exist in icmp.dll > In WinXP, they are still there, but they have also been duplicated > into iphlpapi.dll > > How would one go about adding them to iphlpapi? Does one just > duplicate all the code in the second DLL, or is there a way to have > some function implemented once & then exported by multiple DLLs? (I'm > a Wine newbie...) Actually that's not a Wine but a win32 concept about forwarding. For instance have a look how dlls/security forwards its entry points to secur32.dll. -- Dmitry.

June 10, 2006

Re: Icmp* functions in iphlpapi.dll

by Carl Fongheiser

On 6/10/06, Simon Kissane <skissane(a)gmail.com> wrote: > > Suppose one was to add code to iphlpapi's LibMain which did > LoadLibrary & GetProcAddress to get the addresses of the functions in > icmp.dll, and then the iphlpapi implementations just called the > icmp.dll implementations? (I'm assuming doing a static import would > result in some kind of name collission?) Bad, bad idea. In Windows programming, you *never* call LoadLibrary from DllMain. Inside of DllMain, you can't call anything which uses the loader lock, because the loader lock is already taken out. As best as I read the Wine code, it has the same limitation. Carl Fongheiser

June 10, 2006

WM_GETICON patch

by Chris

Here's a patch I'm trying to make to implement the WM_GETICON message, which programs like GeoShell (a Win32 taskbar replacement) would use to get a taskbar icon for the running processes. I'm not quite sure if it's proper or not, though. Originally GeoShell would show no icon on the taskbar and print a lot of fixme messages about it being unsupported. With this patch it now (always) shows the Wine glass icon for programs, with no such fixme messages. Since I'm unable to try it on a real Windows machine, I don't know if it's the right behavior for it to always show the generic icon like that. Feedback and help would be appreciated.

June 10, 2006

msi: sql parsing

by Joris Huizer

Hello, As somebody asked me whether I could try to use MSN Beta 8, I decided to give it a try; The installer quits at some point, caused by an unhandled SQL command "ALTER TABLE `Registry` HOLD" I decided to have a look at this, but I'm not familiar with msi, and my SQL knowledge isn't very big either; anyway, I added a few lines to the parser; now -- how could I find how to implement something for this? Regards, Joris diff --git a/dlls/msi/sql.y b/dlls/msi/sql.y index 86ebe30..f8c9f40 100644 --- a/dlls/msi/sql.y +++ b/dlls/msi/sql.y @@ -79,7 +79,7 @@ static struct expr * EXPR_wildcard( void int integer; } -%token TK_ABORT TK_AFTER TK_AGG_FUNCTION TK_ALL TK_AND TK_AS TK_ASC +%token TK_ABORT TK_AFTER TK_ALTER TK_AGG_FUNCTION TK_ALL TK_AND TK_AS TK_ASC %token TK_BEFORE TK_BEGIN TK_BETWEEN TK_BITAND TK_BITNOT TK_BITOR TK_BY %token TK_CASCADE TK_CASE TK_CHAR TK_CHECK TK_CLUSTER TK_COLLATE TK_COLUMN %token TK_COMMA TK_COMMENT TK_COMMIT TK_CONCAT TK_CONFLICT @@ -127,7 +127,7 @@ static struct expr * EXPR_wildcard( void %type <column_list> selcollist column column_and_type column_def table_def %type <column_list> column_assignment update_assign_list constlist %type <query> query from fromtable selectfrom unorderedsel -%type <query> oneupdate onedelete oneselect onequery onecreate oneinsert +%type <query> oneupdate onedelete oneselect onequery onecreate oneinsert onealter %type <expr> expr val column_val const_val %type <column_type> column_type data_type data_type_l data_count %type <integer> number @@ -156,6 +156,7 @@ onequery: | oneinsert | oneupdate | onedelete + | onealter ; oneinsert: @@ -235,6 +236,14 @@ onedelete: } ; +onealter: + TK_ALTER TK_TABLE table TK_HOLD + { + FIXME("Unimplemented: ALTER TABLE, HOLD\n"); + $$ = NULL; + } + ; + table_def: column_def TK_PRIMARY TK_KEY selcollist { @@ -807,7 +816,7 @@ UINT MSI_ParseSQL( MSIDATABASE *db, LPCW sql.len = 0; sql.view = phview; sql.mem = mem; - + r = SQL_parse(&sql); TRACE("Parse returned %d\n", r); diff --git a/dlls/msi/tokenize.c b/dlls/msi/tokenize.c index 05c3cda..9b628c0 100644 --- a/dlls/msi/tokenize.c +++ b/dlls/msi/tokenize.c @@ -45,6 +45,7 @@ struct Keyword { static const Keyword aKeywordTable[] = { { "ABORT", TK_ABORT }, { "AFTER", TK_AFTER }, + { "ALTER", TK_ALTER }, { "ALL", TK_ALL }, { "AND", TK_AND }, { "AS", TK_AS },

June 10, 2006

Broken FC5 packages - stay clear.

by Vitaliy Margolen

It seems that FC5 packager created a broken Wine distribution. Instead of being 1-3 packages it's 15 (from what user told me on #winehq. And it doesn't work at all: "Application tried to create a window, but no driver could be loaded." Which tells me it's compiled without X headers. I didn't even new Wine could compile without X, since we don't have tty driver. Vitaliy

June 10, 2006

Icmp* functions in iphlpapi.dll

by Simon Kissane

Hi In Win2000, the ICMP functions exist in icmp.dll In WinXP, they are still there, but they have also been duplicated into iphlpapi.dll How would one go about adding them to iphlpapi? Does one just duplicate all the code in the second DLL, or is there a way to have some function implemented once & then exported by multiple DLLs? (I'm a Wine newbie...) Suppose one was to add code to iphlpapi's LibMain which did LoadLibrary & GetProcAddress to get the addresses of the functions in icmp.dll, and then the iphlpapi implementations just called the icmp.dll implementations? (I'm assuming doing a static import would result in some kind of name collission?) Cheers Simon

June 10, 2006

Re: awwww

by Mike McCormack

Dan Kegel wrote: > I forgot to mention: I also consider any installer bug > a high priority bug. Installers Should Just Work. Agreed, as the installer blocks any other testing that can be done on an application. That's the reason Jeremy has had CodeWeavers employees working on OLE32 and MSI for the last year or so ;) Mike

June 10, 2006

Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER

by Andrew Ziem

Thank you for catching that. I missed the part = {'\0'}; Andrey Turkin wrote: > I cannot see where emptyW initialized. > > Andrew Ziem wrote: >> The special cases remove the wallpaper or set it to default. >> Previously, these cases were ignored, so Wine would crash. >> > <snip> >> + if (NULL == pvParam || SETWALLPAPER_DEFAULT == pvParam) >> + { >> + static const WCHAR emptyW[1]; >> + if (!SetDeskWallPaper( (LPSTR)pvParam )) >> + return FALSE; >> + SYSPARAMS_Save(SPI_SETDESKWALLPAPER_REGKEY, >> SPI_SETDESKWALLPAPER_VALNAME, emptyW, fWinIni);

June 10, 2006

Re: user[3/5]: handle special cases for SPI_SETDESKWALLPAPER

by Andrey Turkin

I cannot see where emptyW initialized. Andrew Ziem wrote: > The special cases remove the wallpaper or set it to default. > Previously, these cases were ignored, so Wine would crash. > <snip> > + if (NULL == pvParam || SETWALLPAPER_DEFAULT == pvParam) > + { > + static const WCHAR emptyW[1]; > + if (!SetDeskWallPaper( (LPSTR)pvParam )) > + return FALSE; > + SYSPARAMS_Save(SPI_SETDESKWALLPAPER_REGKEY, SPI_SETDESKWALLPAPER_VALNAME, emptyW, fWinIni); > + } > + else > + { > + if (!SetDeskWallPaper( (LPSTR) pvParam )) > + return FALSE; > + } > + break; >

June 10, 2006

Re: user[2/5]: implement A version of SPI_GETDESKWALLPAPER

by Andrey Turkin

Andrew Ziem wrote: > Previously, SPI_GETDESKWALLPAPER was handled by default: in the > switch, so the function (an A- function) would return a W string. > > ------------------------------------------------------------------------ > > > 5e4b86d689c899fc896d2870efaca9c335f01da0 > diff --git a/dlls/user/sysparams.c b/dlls/user/sysparams.c > index 5fed316..fb54b3b 100644 > --- a/dlls/user/sysparams.c > +++ b/dlls/user/sysparams.c > @@ -2496,6 +2496,16 @@ BOOL WINAPI SystemParametersInfoA( UINT > break; > } > > + case SPI_GETDESKWALLPAPER: /* 115 */ > + { > + WCHAR buffer[MAX_PATH]; > + ret = SystemParametersInfoW( SPI_GETDESKWALLPAPER, uiParam, buffer, fuWinIni ); > + if (!WideCharToMultiByte(CP_ACP, 0, buffer, -1, pvParam, uiParam, NULL, NULL)) > + ret = FALSE; > + else > + pvParam = buffer; > + } > + > default: > ret = SystemParametersInfoW( uiAction, uiParam, pvParam, fuWinIni ); > break; > > > ------------------------------------------------------------------------ > > > I think break is needed after case. Also, for what else pvParam = buffer; need for?

June 10, 2006

Re: Recording with "Lexia" (mci "open new")

by Eric Pouech

Peter Åstrand wrote: > >> 1) I believe the mciwave.c patch below makes sense in any case, right? >> >>> Without it freed memory is used. >> >> >> I don't see why ? > > > wmw->openParms.lpstrElementName and filename is a pointer to the same > memory, due to this statement in WAVE_mciOpen: > > memcpy(&wmw->openParms, lpOpenParms, sizeof(MCI_WAVE_OPEN_PARMSA)); > actually not exactly as mciOpenFile is called with lpOpenParms->lpstrElementName but you're right that the code is wrong, as we're freeing the lpstrElementName as passed by the calling program the right fix would be to set wmw->openParms.lpstrElementName to NULL after memcpy:ing lpOpenParams in mciOpen A+

June 10, 2006

Re: winmm: Add support for "open new" commands.

by Eric Pouech

Peter Åstrand wrote: > > ChangeLog: > winmm: Add support for "open new" commands. looks globally good, except that you don't enforce that you got a correct device name ie I'm not sure that 'open new type waveaudio' works (without the alias) A+

June 10, 2006

Re: awwww

by Jaap Stolk

On 6/10/06, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: > How about some newer copy protection systems that Wine could support I was wondering about that. I'm trying to run autocad 2004. (It's more an example to debug wine, I don't really need it) When run, it generates a temporary DLL, which in turn generates a temporary DLL, which in turn runs the program. (obviously each step involves new layer of encryption.) Would Wine be able to handle something like that ? Also. Some autocad extensions use printer port or USB hardware keys. Does Wine support low-level printer port access to the real printer port ? Also fun: acad can open multiple files, but some extensions don't support that, so you need to start a separate instance for each drawing, each with it's own copy protection DLL's, so with a couple of drawings open, more than 50 Mb of your system is wasted on the copy protections....

June 10, 2006

Re: DDraw: New ddraw lib

by Jesse Allen

On 6/10/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Samstag, 10. Juni 2006 01:40 schrieb Jesse Allen: > > On 6/9/06, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > > Hi, > > > > > > > I just want to state, the patch is very helpful when you can't use > > > > DGA. I just ran a test with Starcraft in multiplayer last night. Using > > > > OpenGL is noticibly faster than non-DGA. So I hope that it will get > > > > applied for 0.9.16. > > > > > > Did you run it with opengl and this patch, or with Rodericks ddraw patch? > > > > I ran it with your patch. I'm not familiar with Rodericks patch. > And it worked with SURFACE_OPENGL? Wow, I wasn't aware of that :-) All ddraw > games I tried (aow2, anno 1602, worms2) failed with opengl surfaces. > > > Oops, I didn't know about the option. It's running with GDI. But just replacing the DDraw library sped it up. Probably depth conversion? OpenGL don't work. Jesse

June 10, 2006

Re: appdb security

by EA Durbin

>Tobias Burnus wrote: >> >>Why don't you use mysql_escape_string(...)? >>http://de.php.net/manual/en/function.mysql-escape-string.php Why not just use PEAR::DB as recommended in the book "Essential PHP Security", as it handles multiple SQL interfaces and escapes the data automatically for you, appropriately for the type of database you're using. http://www.devshed.com/c/a/PHP/Accessing-Databases-with-DB/2/

June 10, 2006

riched20 bug 4452 fix still not merged?

by Dan Kegel

Hi Matt, can you add http://bugs.winehq.org/show_bug.cgi?id=4452 to your list of riched20 bugs to look at? This one even has a fix, but for some reason the fix hasn't been merged yet. Thanks, Dan

June 10, 2006

Re: notepad patches (search/replace, etc)

by Marcus Meissner

On Sat, Jun 10, 2006 at 09:52:50AM -0600, Vitaliy Margolen wrote: > Friday, June 9, 2006, 11:49:44 AM, Anoni Moose wrote: > > Let's try again... I apologize for the bad indentation. It's indented fine in > > emacs, which I use; however, when I use "diff -u file1 file2", it gives me the > > entire file as a patch. Therefore, I must use "diff -uwB". Emacs must be screwing it up... Your editor adds DOS linefeeds for some reason. Ciao, Marcus

June 10, 2006

Re: getuname: add stub implementation [try 4]

by Vitaly Lipatov

В сообщении от 10 июня 2006 19:25 Dmitry Timoshkov написал(a): > "Vitaly Lipatov" <lav(a)etersoft.ru> wrote: > > Add WINE_PREATTACH and correct numer of params for GetUName > > Try4: Export functions by name (@), fix warning in FIXME > > > > Changelog > > add minimal implementation for getuname dll and GetUName function > > Just curious, what application besides charmap.exe uses getuname.dll? You are right, I guess it was charmap.exe Is it unuseful dll? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

June 10, 2006

Re: netapi32: Improve NetUserGetInfo function

by Joris Huizer

Simon Kissane wrote: > netapi32: Improve NetUserGetInfo function > * Implemented support for all levels documented by MSDN > * Corrected error codes for nonexistent levels > * Now works with empty string as server name > > I have also attached a C program (which can be compiled with MINGW), > which tests the NetUserGetInfo functionality. > Perhaps you could write unit tests based on the test program, to show correctness of the current code - this helps avoiding regressions HTH, Joris

June 10, 2006

Re: notepad patches (search/replace, etc)

by Vitaliy Margolen

Friday, June 9, 2006, 11:49:44 AM, Anoni Moose wrote: > Let's try again... I apologize for the bad indentation. It's indented fine in > emacs, which I use; however, when I use "diff -u file1 file2", it gives me the > entire file as a patch. Therefore, I must use "diff -uwB". Emacs must be screwing it up... That will not work. Your patch look really bad with all types of indentation. You need to use something that doesn't autoindent. Also please do not mix spaces and tabs - you have that on each line and that's agreed NO-NO. You either use tabs (8 spaces) or you use all spaces. But not tab & spaces on the same line. Vitaliy.

June 10, 2006