September 2005 - Wine-Devel

Re: [Now ns7] Dragon ns8 problem

by Francois Gouget

On Mon, 5 Sep 2005, wino(a)piments.com wrote: > On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier <jean(a)bornier.net> > wrote: > >> As root, "ps ax | grep wine", and then looking at pid numbers, kill all of >> the /usr/bin/wine-preloader processes (there were four or five of them), >> one after the other. Then as user, wineboot worked. Wonder if this is >> usual? > > Yes I seem to remember having to kill off some wine-preloader processes after > failures but not sure if it was in this same context. > > BTW try pgrep ;) Even better, try 'killall wine-preloader' or 'killall -9 wine-preloader'. There's also pkill if you need to do a more sophisticated selection of the processes to kill. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U

Sept. 6, 2005

Re: Installers freezing - ole, games

by Robert Shearman

Ivan Gyurdiev wrote: > >> >> Thanks for reporting this. In order for the logs of these types of >> programs to make sense, you really need to give me one with >> +ole,+olerelay,+seh,+tid options. I suspect it is the following bug >> though: > > > > I've attached the necessary logs to: > http://bugs.winehq.org/show_bug.cgi?id=3108 Hi Ivan, I had a look through the logs, but I couldn't see anything too suspicious. I have Battlefield 2 here, but I don't have enough disk space to make it far enough into the installer to see the error. Hopefully it is just the known error I described. -- Rob Shearman

Sept. 6, 2005

Re: Installers freezing - ole, games

by Robert Shearman

Marcus Meissner wrote: >On Sun, Sep 04, 2005 at 02:17:06AM -0500, Robert Shearman wrote: > > >>In newer InstallShields, there is a marshaled object that contains a >>function with a VT_PTR -> VT_USERDEFINED( TKIND_ENUM ). This should be >>treated as "int *", but is actually treated as "int". This is due to >>some broken logic in the typelib marshaler that is designed to fix the >>problem with VT_PTR -> VT_USERDEFINED( TKIND_INTERFACE ) -> "IUnknown >>*", but where we should dereference the pointer any more. >>We probably need to use the logic in ITypeInfo::Invoke to appropriately >>transform the soup of pointers and userdefined types into something we >>can use. I should also need to check what things are accepted in the >>native version. i.e. is VT_PTR -> VT_PTR -> VT_USERDEFINED( TKIND_ENUM ) >>supported? If so, that isn't representable by the VARIANT vt's, so we >>would need to treat it differently than the ITypeInfo::Invoke case. >> >> > >Do you have a freely downloadable installer that exposes this? > > No, but I have a test program. -- Rob Shearman

Sept. 6, 2005

Re: add proper support for native NT drivers and programs to the build system

by Alexandre Julliard

Ivan Leo Puoti <ivanleo(a)gmail.com> writes: > @@ -469,8 +469,10 @@ > /* get the default entry point for a given spec file */ > static const char *get_default_entry_point( const DLLSPEC *spec ) > { > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE && spec->characteristics & IMAGE_FILE_DLL) > + return "__wine_spec_drv_entry"; > + if (spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) return "__wine_spec_exe_nentry"; Native drivers are not supposed to be dlls. > @@ -322,9 +322,15 @@ > ORDDEF *odp = &spec->entry_points[i]; > if (odp->type != TYPE_STUB) continue; > fprintf( outfile, "#ifdef __GNUC__\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > fprintf( outfile, "#else\n" ); > - fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); > + if(spec->subsystem == IMAGE_SUBSYSTEM_NATIVE) > + fprintf( outfile, "extern void __wine_spec_nunimplemented_stub( const char *module, const char *func ) __attribute__((noreturn));\n" ); > + else > + fprintf( outfile, "extern void __wine_spec_unimplemented_stub( const char *module, const char *func );\n" ); You should provide your own handling of stubs inside ntoskrnl, like ntdll does. -- Alexandre Julliard julliard(a)winehq.org

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Francois Gouget

On Tue, 6 Sep 2005, Alexandre Julliard wrote: > Peter Beutner <p.beutner(a)gmx.net> writes: > >> Any reasons given? > > Stability is the obvious reason. And also of course the fact that we > have most of the code we need in ntdll already and none of it in > wineserver. Just trying to move things forward and understand because I'm curious: So the way to do it would be to have ntdll load the drivers in the process using them? Wouldn't that cause problems if a driver expects to be able to maintain shared information across processes? Do we know if this is going to be a problem with the drivers we are interested in? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Francois Gouget

On Tue, 6 Sep 2005, Robert Lunnon wrote: > On Tuesday 06 September 2005 19:20, Francois Gouget wrote: >> On Tue, 6 Sep 2005, Troy Rollo wrote: >> [...] >> >>> Having to pipe all the changes through one person limits scalability. [...] > I must disagree, the LOTM (Lord Of The Manor) governance model may work for > an small outfit but wine has already outgrown it. I have two or three > withheld patches which are absolute show stoppers for running wine under > Solaris. They are withheld despite the fact they work because they were > refused, So you're saying that Alexandre is wrong to refuse your patches, not that he is overloaded and drops patches so often that it limits Wine's growth. Then adding more committers would not help. (unless you play one committer against the other to get your patches accepted) The way forward is to dig up the patches that were rejected, post them to wine-devel with the reason that was given for their rejection (because you asked why they were rejected, right?), and ask for suggestions on how to make them more acceptable. > yet every second week I am forced to work around some portability > problem introduced by someone else - not exactly ISO9001 quality assurance. I don't see a way around that. Only users of a given platform can detect compatibility or compilation problems with that platform. We cannot expect Alexandre, or every single committer in a multi-committer system, to test on every single platform out there before each commit. Even on Linux we sometimes get compilation problems with weird libxml libraries, opengl issues, old compilers, new compilers, etc. I'll grant you that we could possibly setup a TinderBox type of system but I feel that would be very overkill right now and even TinderBox can only detect problems after patches get committed. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Sept. 6, 2005

Re: Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8

by Oliver Stieber

--- Karsten Elfenbein <kelfe(a)gmx.de> wrote: That looks fine, thanks. > Added A2R10G10B10 and D3DFMT_D24FS8 modes to all other functions. > > Karsten > > > -----Ursprüngliche Nachricht----- > > Von: wine-patches-bounces(a)winehq.org > > [mailto:wine-patches-bounces(a)winehq.org] Im Auftrag von Oliver Stieber > > Gesendet: Samstag, 3. September 2005 22:15 > > An: wine-devel(a)winehq.org; wine-patches(a)winehq.org > > Betreff: ***SPAM*** Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8 > > > > > > > > --- Karsten Elfenbein <kelfe(a)gmx.de> wrote: > > Can you put together a patch to add A2R10G10B10 and > > D3DFMT_D24FS8 to utils.c as well please. > > > > D3DFmt2GLIntFmt needs to return GL_RGBA, D3DFmt2GLFmt needs > > to return GL_RGBA, D3DFmt2GLType needs to return > > GL_UNSIGNED_INT_2_10_10_10_REV, D3DFmtGetBpp needs to return 4, > > D3DFmtMakeGlCfg needs to > > PUSH2(GLX_ALPHA_SIZE, 2); > > PUSH2(GLX_RED_SIZE, 10); > > PUSH2(GLX_GREEN_SIZE, 10); > > PUSH2(GLX_BLUE_SIZE, 10); > > > > Also in surface.c IWineD3DSurfaceImpl_UnlockRect needs to use > > > > glDrawPixels(This->lockedRect.right - This->lockedRect.left, > > (This->lockedRect.bottom - > > This->lockedRect.top) - 1, GL_BGRA, GL_UNSIGNED_INT_2_10_10_10_REV, > > This->resource.allocatedMemory); > > when unlocking the back buffer > > > > > > Thanks, > > Oliver. > > > Changelog: > > > * added A2R10G10B10 and D3DFMT_D24FS8 modes > > > > > > > > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Ivan Leo Puoti

Marcus Meissner wrote: > Personally I consider the WINE project fair in its patch acceptance policies. IMHO it's also fair to call it Wine and not WINE, IIRC this was agreed on before. Ivan.

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Kuba Ober

On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote: > Peter Beutner <p.beutner(a)gmx.net> writes: > > Any reasons given? > > Stability is the obvious reason. Stability? It'd still be at most as unstable as a native windows session, so I don't see a big deal with that. If wineserver and/or user process crashes, so what? That'd very likely happen on the native platform as well, so I fail to see anything wrong with that approach from the stability perspective... Kuba

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Marcus Meissner

On Tue, Sep 06, 2005 at 09:58:03PM +1000, Robert Lunnon wrote: ... > I must disagree, the LOTM (Lord Of The Manor) governance model may work for > an small outfit but wine has already outgrown it. I have two or three > withheld patches which are absolute show stoppers for running wine under > Solaris. They are withheld despite the fact they work because they were > refused, yet every second week I am forced to work around some portability > problem introduced by someone else - not exactly ISO9001 quality assurance. > This causes problems for both me and the wine project because: > > 1. wine is NOT as portable as it should be. > 2. I am forced to become the LOTM for wine under Solaris since I am currently > the only source (I know of) for Solaris wine. > > There must have been half a dozen times where I have decided to abandon the > wine project due to its governance model, only to be encouraged back to it by > my customers. These days I submit my patches to comply with the LGPL, and if > they go in all well and good, if not I no longer care... Is this how > developers should be thinking about wine ? > > It's also important to remember that many developers that contribute > (Including myself) are volunteers, volunteers are hard to come by, but really > easy to get rid of. You need a governance model that is not only fair and > even handed with people, but is SEEN TO BE fair and even handed. This model > is not that. Do you mailinglist posting URLs for the refusals? You should push your patches more often and request feedback if they are rejected. Like we all do for our patches. Portability problems need to be pointed out by more people and fixed by the contributors. Changing the WINE development model would not help in your case. Personally I consider the WINE project fair in its patch acceptance policies. Ciao, Marcus

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Robert Lunnon

On Tuesday 06 September 2005 19:20, Francois Gouget wrote: > On Tue, 6 Sep 2005, Troy Rollo wrote: > [...] > > > Having to pipe all the changes through one person limits scalability. > > This is far from being an issue with the current number of patches. By > the time it becomes an issue I'm sure we'll have switched to a > distributed repository model with different maintainers for each part of > Wine. But you also have to realise that expecting to have multiple Wine > maintainers right now is unrealistic due to lack of volunteers with > enough time and who would be here for the long haul. > > The only issue is when he takes a vacation but that's not very often. > <lots of stuff deleted for brevity> I must disagree, the LOTM (Lord Of The Manor) governance model may work for an small outfit but wine has already outgrown it. I have two or three withheld patches which are absolute show stoppers for running wine under Solaris. They are withheld despite the fact they work because they were refused, yet every second week I am forced to work around some portability problem introduced by someone else - not exactly ISO9001 quality assurance. This causes problems for both me and the wine project because: 1. wine is NOT as portable as it should be. 2. I am forced to become the LOTM for wine under Solaris since I am currently the only source (I know of) for Solaris wine. There must have been half a dozen times where I have decided to abandon the wine project due to its governance model, only to be encouraged back to it by my customers. These days I submit my patches to comply with the LGPL, and if they go in all well and good, if not I no longer care... Is this how developers should be thinking about wine ? It's also important to remember that many developers that contribute (Including myself) are volunteers, volunteers are hard to come by, but really easy to get rid of. You need a governance model that is not only fair and even handed with people, but is SEEN TO BE fair and even handed. This model is not that. Bob

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Marcus Meissner

On Tue, Sep 06, 2005 at 01:46:21PM +0200, Andreas Mohr wrote: > Hi, > > On Tue, Sep 06, 2005 at 11:32:05AM +0100, Ivan Leo Puoti wrote: > > Peter Beutner wrote: > > > > >Any reasons given? > > > > Yes, he doesn't want driver in the wineserver. > > Well, that reasoning cannot remain without further discussion if there > truly is a need for such a feature. > > Either having a technically superiour isolated ntoskrnl framework > is sufficiently easy and feasible and compatible, or an alternative > could perhaps be to add this functionality to wineserver yet disable > critical parts of it by default in order to not compromise stability. This ntoskrnl is meant to load binary windows drivers. It will never live in the wineserver due to this reason ;) Ciao, Marcus

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Andreas Mohr

Hi, On Tue, Sep 06, 2005 at 11:32:05AM +0100, Ivan Leo Puoti wrote: > Peter Beutner wrote: > > >Any reasons given? > > Yes, he doesn't want driver in the wineserver. Well, that reasoning cannot remain without further discussion if there truly is a need for such a feature. Either having a technically superiour isolated ntoskrnl framework is sufficiently easy and feasible and compatible, or an alternative could perhaps be to add this functionality to wineserver yet disable critical parts of it by default in order to not compromise stability. Andreas Mohr

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Any reasons given? Stability is the obvious reason. And also of course the fact that we have most of the code we need in ntdll already and none of it in wineserver. -- Alexandre Julliard julliard(a)winehq.org

Sept. 6, 2005

Re: fonts: don't call LineTo with the gdi lock

by Alexandre Julliard

Huw D M Davies <h.davies1(a)physics.ox.ac.uk> writes: > On Sun, Aug 28, 2005 at 12:04:41PM +0100, Huw D M Davies wrote: >> Huw Davies <huw(a)codeweavers.com> >> Don't call LineTo while holding the gdi lock > > Is this one better? I think it would be better to release the DC earlier on and then just do normal GDI calls. -- Alexandre Julliard julliard(a)winehq.org

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Ivan Leo Puoti

Peter Beutner wrote: > Any reasons given? Yes, he doesn't want driver in the wineserver. Ivan.

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Ivan Leo Puoti

Uwe Bonnes wrote: > Was this discussed on wine-devel? No, but you're welcome to try and convince him, even if I don't really think it's possible. Ivan.

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Peter Beutner

Ivan Leo Puoti schrieb: > Peter Beutner wrote: > >> Why implement ntoskrnl as a seperate process plus inventing a new IPC >> protocol to talk to it? As you said: "ntoskrnl for windows _is_ what >> wineserver for wine.". So why not implement the needed ntoskrnl stuff >> into wineserver? > > > Great idea, but Alexadre doesn't want drivers running in wineserver. Any reasons given? > > Ivan > > > >

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Uwe Bonnes

>>>>> "Ivan" == Ivan Leo Puoti <ivanleo(a)gmail.com> writes: Ivan> Peter Beutner wrote: >> Why implement ntoskrnl as a seperate process plus inventing a new IPC >> protocol to talk to it? As you said: "ntoskrnl for windows _is_ what >> wineserver for wine.". So why not implement the needed ntoskrnl stuff >> into wineserver? Ivan> Great idea, but Alexadre doesn't want drivers running in Ivan> wineserver. Was this discussed on wine-devel? It's a pity if design decisions get explained on the winehackers IRC channel, so there are great chances to miss it... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Ivan Leo Puoti

Peter Beutner wrote: > Why implement ntoskrnl as a seperate process plus inventing a new IPC > protocol to talk to it? As you said: "ntoskrnl for windows _is_ what > wineserver for wine.". So why not implement the needed ntoskrnl stuff > into wineserver? Great idea, but Alexadre doesn't want drivers running in wineserver. Ivan

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Peter Beutner

Vitaliy Margolen schrieb: > We need ntoskrnl to run some subset of drivers on wine. Notably cd protection > drivers. They are not a hardware drivers, but a means to access something that > is not accessible from user space. So in a sense ntoskrnl is just a process to > run those drivers in, and send/receive requests to/from those drivers. > > You need to keep in mind that this is a kernel level, so some things will not > work, and some things have to work that normally do not in the user space. Also > ntoskrnl for windows _is_ what wineserver for wine. > Why implement ntoskrnl as a seperate process plus inventing a new IPC protocol to talk to it? As you said: "ntoskrnl for windows _is_ what wineserver for wine.". So why not implement the needed ntoskrnl stuff into wineserver? Peter

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Francois Gouget

On Tue, 6 Sep 2005, Troy Rollo wrote: [...] > Having to pipe all the changes through one person limits scalability. This is far from being an issue with the current number of patches. By the time it becomes an issue I'm sure we'll have switched to a distributed repository model with different maintainers for each part of Wine. But you also have to realise that expecting to have multiple Wine maintainers right now is unrealistic due to lack of volunteers with enough time and who would be here for the long haul. The only issue is when he takes a vacation but that's not very often. [...] > Even as things are now there is a disincentive to new developers. Some > developers don't bother submitting patches because they feel it's too much > work to get them accepted, and sometimes the patch doesn't get written at all > because there is not enough certainty that it will be accepted. Whatever the project or development model there is the risk that the patch will have to be reworked before it can be accepted. It's necessary to ensure the quality of the code and in order for the project to move forward rather than collapse repeatedly like a badly planned building. [...] > How many times have you seen people say that "Alexandre doesn't always know > what he wants, but he knows what he doesn't want"?. Hmmm, one? But it's unfair to expect him to solve everyone else's problems. One does not need commit access to suggest solutions to the current day's problem and when he is presented with a good solution Alexandre is quite able to say that he likes it. Otherwise you just have to accept that nobody knows what the right solution is. Then the only solution is to try one out to see if it is workable, then another one and so on until you find one that sticks. That's very much the development model of the Linux kernel btw. [...] > I suspect the current model is either at or near its limits. It would > certainly not cope with a significant number of commercial outfits putting in > a serious level of contribution, nor does it encourage them to make the > attempt. I can assure you that there are many more important factors that might dissuade a company from getting involved in Wine besides 'it's hard to get patches committed'. The saying 'Whatever you do, don't compete against Microsoft' would be one for instance. [...] > To scale better you would need to divide the project into different areas of > responsibility and have multiple committers. Well, we already have different committers for Wine, the website and the application database. But again it's the finding volunteers with the required knowledge, skill and free time that is going to be a problem. > Almost every subdirectory of "dlls" could in principle be a separate > area of responsibility with a separate group of committers, although > it might be more convenient to have more-or-less related > subdirectories under the umbrella of a single group. I mostly agree here. Actually I think we could easily have 2 or 3 developpers per dll or group of dlls which means we could have many more developpers without having them step on each other's toes too much. Once we get to that level of development we'll see if Alexandre becomes the bottleneck but we are very far off. > Each group responsible for an area would need to be prepared to give advice > to people working on some patch in that area that if followed would make it > virtually certain that the patch would be accepted. Having more people give advice and help new contributors would certainly help. But the people giving advice don't need commit access to do that. Some developpers like Mike McCormack and Dmitry Timoshkov have been quite active in this area and I think they had a positive effect. All that's needed is subscribing to wine-devel and wine-patches, some Wine experience and the time plus the will to review patches. > A supporting facility you would probably need would likely include either > separate mailing lists for each sub-project (things get lost in wine-devel > *now*) with consolidated read-only lists for people who want a convenient way > of watching all of the discussions or a shift to an NNTP heirarchy with > mailing gateways. I don't think there is too much traffic on wine-devel yet. At this point I feel that splitting up wine-devel runs a much greater risk to dilute discussions and extinguish them because of lack of participants. The number of emails without an answer would certainly rise. [...] > Even with the Linux kernel, which is the only project that I am aware of that > is comparable in size and follows a similar model to Wine, there appears to > me to be some greater division of responsibility. The Linux kernel is a much bigger project that Wine. I count almost 5 million lines of C code versus less than 2 million for Wine. They also have many more contributors. Just as a comparison, the lkml gets twice as much email in a week as wine-devel in a month! > This is all relevant, of course, only *if* significant expansion of the pool > of developers is a desirable goal. Yes, it definitely is. So the conclusion (mine anyway) is: * we need more volunteers to review patches and provide suggestions for improving them * we need more volunteers to help and maybe even informally 'mentor' new developpers * we need all Wine contributors to realise they should not wait for Alexandre to solve Wine's architectural problems or set directions * we could probably advertise more for Wine in universities and Linux user groups by making presentations/demos -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

Sept. 6, 2005

Re: MSI: test creating a package

by Andreas Mohr

Hi, On Tue, Sep 06, 2005 at 05:28:06PM +0900, Mike McCormack wrote: > > Andreas Mohr wrote: > > >Hmm, something seems to be missing here... > > The purpose of the test is only to prove that we can make a package. I > have other tests that I will submit later that build on > create_package_db and package_from_db, but this test does something > useful as it is. Sorry, I should have explicitly pointed out that it's the linefeeds that are missing. -- No programming skills!? Why not help translate many Linux applications! https://launchpad.ubuntu.com/rosetta

Sept. 6, 2005

Re: MSI: test creating a package

by Mike McCormack

Andreas Mohr wrote: > Hmm, something seems to be missing here... The purpose of the test is only to prove that we can make a package. I have other tests that I will submit later that build on create_package_db and package_from_db, but this test does something useful as it is. Mike

Sept. 6, 2005

Messages from 2030 (Laxdragon please read)

by Ivan Leo Puoti

http://www.winehq.com/pipermail/wine-devel/2030-March/000355.html Well, now we all know wineserver will still be around in 2030... Seriously, this should be fixed (not wineserver, the list archive) Ivan.

Sept. 6, 2005