September 2005 - Wine-Devel

Re: Suggestions for improvement of the emulator

by Juan Lang

> This of course points to another problem with the existing system - > if a patch has been rejected, it should be a necessary consequence > that the submitter is informed with reasons - they shouldn't have to > be chasing up Alexandre to find out if the patch was rejected or > merely missed (which happens often). (snip) > What is needed is a system that records all patches, together with > their current status (NEW, APPLIED, REJECTED (with reasons), and > whatever other status), informs the submitter of any change, and does > not allow for a patch merely to be forgotten. What this misses is the most common status that causes us all to argue: uncomitted, because Alexandre's not sure about it. Perhaps he has a gut feeling that the approach is not right, but hasn't taken the time to identify any particular flaw. Perhaps it merits additional thought. Perhaps it's too big to review quickly. Perhaps he hopes the submitter will realize it's not up to snuff, and resubmit a better patch. There are probably other reasons, but these all come to mind from my own experience. And no system can appropriately capture that, when the answer is not as clearly defined as one of the above states. This is frustrating, and some people do seem to be put off by it. I have no idea how many potential contributors we lose this way. On the other hand, this is Alexandre's style, and we've all had to get used to it. Any alternative that involves Alexandre doing more work will get summarily rejected--he does a great deal as it is, more I think than any one of us would be willing to do (or perhaps could do). The only credible alternative is a multi-maintainer system. This could allow faster development of some larger features, or more invasive ones, or more exploratory ones. The problem I see with this is one of quality: We have a large code churn rate, and, corresponding with that, a high bug churn rate. That makes regression testing and choosing an appropriate wine version both very difficult. Having multiple maintainers multiplies the number of possible configurations. Yes, I know we could have official releases and the like, but who of us would resist trying out some as-yet-unmerged DX9 patch from Oliver, or experimenting with safedisc? Continuing in that vein, we're all lazy about merging in large patch sets. I'm merging in a fairly large set of changes at the moment, and the slower pace has allowed me to catch issues that may not have surfaced otherwise. Having several competing trees with substantial differences would, in my opinion, reduce the overall quality of the project. So I see a tradeoff between development speed and quality. We may be perceived as having issues with speed, but I think we do pretty well with our small stable of developers. We do have issues with quality, IMHO, so I'd be reluctant to endorse any radical changes. What does seem to work is picking up for Alexandre by reviewing patches on wine-devel, and helping newcomers along. We seem to have picked up a few lately that don't mind the public thrashing :) There does seem to be some more collaborative development going on lately, too. Perhaps we should be more vocal about how we do business, what kind of feedback to expect, and how to get help? --Juan ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Jeremy White

> This of course points to another problem with the existing system - if a patch > has been rejected, it should be a necessary consequence that the submitter is > informed with reasons - they shouldn't have to be chasing up Alexandre to > find out if the patch was rejected or merely missed (which happens often). > This is not to criticise Alexandre, but to point out that systems need to be > put in place to help him manage these things. Just taking patches of the > mailing list is not a sufficient mechanism. What is needed is a system that > records all patches, together with their current status (NEW, APPLIED, > REJECTED (with reasons), and whatever other status), informs the submitter of > any change, and does not allow for a patch merely to be forgotten. > We actually have a todo on Jeremy Newman's list to build a patch management system for wine-devel, for Alexandre. Our hope was that we could adopt some of the CodeWeavers systems (we have a ticket system that's pretty slick, for example). However, it became clear that the requirements were fairly substantial (the tight emacs integration became our first clue :-/), and that project got back burnered. At the time we were discussing that, though, we didn't have many volunteer web programmers; maybe we should revisit that. Alexandre, would you be interested if folks other than Jer volunteered to help build such a system? With that said, I have to ask - what open source projects are you guys working on that don't suffer from these problems? I'm now a successful contributor to the Linux Kernel (tweaked isofs for Windows CDs) and it took me 3 years and countless dropped emails, despite the personal help of Alan Cox and Andrew Morton before my patch got in (and I have another patch, a minor bug fix, that I despair will ever see the light of day). I had a similar situation with MythTV (and the #mythtv channel is actively hostile to anyone mildly clueless), and the list goes on. Based on my experiences, I would say that Wine is a cut above, and Alexandre does a very fine job. On the other hand, I've often thought that the developer section should have a big FAQ to help explain how Alexandre works (notably the fact that he uses the absolute minimum amount of communication required at any time) <grin>. Cheers, Jeremy

Sept. 6, 2005

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

by Ivan Leo Puoti

Alexandre Julliard wrote: > >You should provide your own handling of stubs inside ntoskrnl, like >ntdll does. > > > ntosknrl? And who's talking about ntoskrnl? This is an attempt to add generic support for native nt applications, it's not a ntoskrnl specific thing, and not all native nt apps do their own exception handling. I certainly understand very few if any people will ever use winebuild on a native nt app, but that doesn't sound like a good enough reason to not have support for them. Ivan.

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Hiji

--- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > "Hiji" <hijinio(a)yahoo.com> wrote: > > > As a user, I've been particularly happy about how > Wine > > has progressed. However, what is of GRAVE concern > to > > me is when patches that fix serious bugs aren't > > applied; specifically, bug 3148. Even the patch > > submitter had to plead with this alias for someone > to > > listen because no one was paying attention to the > > patch. Yet, to date, the patch has either not > been > > applied nor the bug been fixed. > > Do you or the author of the patch know why the patch > has not been > accepted? Did you or he ask about the reason? If the > patch was > rejected because it's wrong or of a poor quality, > Wine CVS with > multiple committers would not solve this particular > problem. I don't want to speak for the author directly, but last I checked, no one would even acknowledge that the patch was submitted - so it didn't even reach the rejection or acceptance point. The sad part is that the patch that created the bug was accepted, but after realizing the error of the first patch, the author tried to submit a second patch to fix his first error. Thus, that leads us to where we are at now. This is my understanding of the situation. Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Dmitry Timoshkov

"Hiji" <hijinio(a)yahoo.com> wrote: > As a user, I've been particularly happy about how Wine > has progressed. However, what is of GRAVE concern to > me is when patches that fix serious bugs aren't > applied; specifically, bug 3148. Even the patch > submitter had to plead with this alias for someone to > listen because no one was paying attention to the > patch. Yet, to date, the patch has either not been > applied nor the bug been fixed. Do you or the author of the patch know why the patch has not been accepted? Did you or he ask about the reason? If the patch was rejected because it's wrong or of a poor quality, Wine CVS with multiple committers would not solve this particular problem. -- Dmitry.

Sept. 6, 2005

Re: Path for Testfiles (MSI: Test creating a package)

by Mike McCormack

Detlef Riekenberg wrote: >> dlls/msi/tests : package.c > ... i Suggest that: > - all directories and files for tests should be created in > "%TEMP%\winetest" > - we modify "wine/tests.h" to get this path and > check for path and name overflows (MAX_PATH and nesting level). > > "c:" could be readonly or absent/hidden > Any comments please. Sorry, that's my fault. I already changed all the other places we use "C:\winetest.msi" to simply "winetest.msi". I'll fix this one too. Mike

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Oliver Stieber

--- Steven Edwards <winehacker(a)gmail.com> wrote: > Hello, > > On 9/6/05, Francois Gouget <fgouget(a)free.fr> wrote: > > 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. > > I don't know if everyone follows wine-cvs everyday and examines every > patch that goes through but we could suggest in our documentation that > CC's of patches are sent to certain developers along with > wine-patches. Basically the model would stay the same as it is now > except we would be laying the ground work for the move to a maintainer > model. If someone wants to be a maintainer then they would add > themselves to the list and would agree to review patches people to > send them. > > If I was going to to do some DirectX hacking I would be more inclined > to send my patch to Oliver first rather than sending it to Julliard > because 1) I know Oliver is the defacto maintainer right now and 2) If > he has uncommitted patches in his tree then my changes could result in > conflict or duplication of work. > I know it has to be frustrating for new developers that join the > project don't know who works on what. They spend X amount of time > working on something only to see it be rejected or to be told "You did > this wrong". Sure they should have asked on wine-devel but maybe if we > had a list of people that were the point of contact for certain > modules (And clearly document the submission process) it would > encourage them to ask more questions directly. If you send the patches in to wine-patches then I will help you get the patches applied, that may mean that they don't get committed initially and I have to work with you to get the patches to a good level of completeness. I initially had a lot of patched declined, hell it was annoying, and my work would have made it into winecvs a lot faster if they had been committed earlier, but I think breaking patches down into small, defined manageable chunks is far more important in the long run, especially if it causes regression. Anyhow, I'm sure that all patches are very much appreciated by everyone, anyone who has any difficulty getting any patches committed should just ask for some help on wine-devel and I'm sure someone will be willing to help them out (If not just Email me and I'll give you a hand!). Roles seem to change a lot, so I'm not sure that appointing anyone is a good idea (appart from the default maintainer of for categories of bugs), you can always look at the code or http://www.winehq.org/site/status and find whoever has submited the recient changes, it may be initially daunting but I'm sure everyone's glad someone lends a hand. Oliver. > > > Thanks > Steven > > > ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Troy Rollo

The only reason I had not made some of these comments earlier was that I knew that they would not be well received, and that there would be at least some unconstructive responses. A prerequisite for having a productive discussion of this kind is being able to recognise the possible validity of alternative points of view, and to be aware of and have the maturity to accept the reality that nobody is infallible and in any particular instance it may be you who is wrong, and to react appropriately when it turns out you were wrong. There are some people here who can do that, and others who cannot. Unfortunately the ones who are not are usually the loudest and tend to destroy any value in the discussion. I always find it particularly amusing when people try to tell me what a commercial organisation in a particular situation would do when I'm a person who makes the particular type of decision concerned in a commercial organisation. I do not intend to fully respond to the replies. I did not expect the discussion to go anywhere productive (and still don't). I only made my detailed comments because I was asked directly based on a deliberately vague comment that I thought would not be controversial. I am at least not surprised by the complete lack of any attempt to be constructive on the part of one participant (who, for avoidance of doubt, is not one of the people quoted below). Nevertheless, two new points have been raised that merit some type of comment. On Tue, 6 Sep 2005 21:58, Robert Lunnon wrote: > 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 This is not necessary to comply with the LGPL, not is it even a possible element in ensuring compliance. On Tue, 6 Sep 2005 23:26, Francois Gouget wrote: > 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. This of course points to another problem with the existing system - if a patch has been rejected, it should be a necessary consequence that the submitter is informed with reasons - they shouldn't have to be chasing up Alexandre to find out if the patch was rejected or merely missed (which happens often). This is not to criticise Alexandre, but to point out that systems need to be put in place to help him manage these things. Just taking patches of the mailing list is not a sufficient mechanism. What is needed is a system that records all patches, together with their current status (NEW, APPLIED, REJECTED (with reasons), and whatever other status), informs the submitter of any change, and does not allow for a patch merely to be forgotten. The present system leads to inevitable delays since the submitter has to wait a while until it seems likely that the patch is not going to go in, then ask why - if submitters received immediate feedback once there is a decision, they could turn around a new version of the patch much more quickly (and an ideal system would link the new submission to the original to put it in more complete context). Then others who may be depending on the patch can get on with their work too. It ought to help Alexandre too since it would mean he wouldn't have to try to remember a week later why he rejected a particular patch, or re-examine the patch to figure out what he was thinking. It may be that Bugzilla could be coaxed into this role, although I suspect it's not particularly well adapted to this core task without some customisation.

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Steven Edwards

Hello, On 9/6/05, Francois Gouget <fgouget(a)free.fr> wrote: > 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. I don't know if everyone follows wine-cvs everyday and examines every patch that goes through but we could suggest in our documentation that CC's of patches are sent to certain developers along with wine-patches. Basically the model would stay the same as it is now except we would be laying the ground work for the move to a maintainer model. If someone wants to be a maintainer then they would add themselves to the list and would agree to review patches people to send them. If I was going to to do some DirectX hacking I would be more inclined to send my patch to Oliver first rather than sending it to Julliard because 1) I know Oliver is the defacto maintainer right now and 2) If he has uncommitted patches in his tree then my changes could result in conflict or duplication of work. I know it has to be frustrating for new developers that join the project don't know who works on what. They spend X amount of time working on something only to see it be rejected or to be told "You did this wrong". Sure they should have asked on wine-devel but maybe if we had a list of people that were the point of contact for certain modules (And clearly document the submission process) it would encourage them to ask more questions directly. Thanks Steven

Sept. 6, 2005

Re: Suggestions for improvement of the emulator

by Hiji

> [...] > > 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'. As a user, I've been particularly happy about how Wine has progressed. However, what is of GRAVE concern to me is when patches that fix serious bugs aren't applied; specifically, bug 3148. Even the patch submitter had to plead with this alias for someone to listen because no one was paying attention to the patch. Yet, to date, the patch has either not been applied nor the bug been fixed. Simple, yet silly, bugs like the beforementioned one can keep users from taking advantage of newer versions of Wine because they prefer to stay with older versions that don't have the bug(s). Food for thought... Hiji ______________________________________________________ Click here to donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/

Sept. 6, 2005

Re: DirectX status update....

by Hiji

--- James Liggett <jrliggett(a)cox.net> wrote: > This is some excellent news! Kudos and keep up the > great work :) > > James I agree. This is freakin' awesome! Hiji __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sept. 6, 2005

Re: DirectX status update....

by James Liggett

This is some excellent news! Kudos and keep up the great work :) James On Tue, 2005-09-06 at 21:21 +0100, Oliver Stieber wrote: > I though it was about time I gave a status update on DirectX9/wined3d, so here goes. > > Short of a couple of bug fixes (one to shaders, and another that causes some games to crash) > and a couple of patches that need resending (support for non-power2 textures in warhammer 40k) > wined3d and d3d9 is functionally as complete as the version on > http://directxwine.sourceforge.net/, that means that as soon as pixel shaders are coppied across > from d3d8 it's more or less the end of adding features to wined3d and the start of fixing the > remaining bugs and getting the performance up to spec. > > Anyhow, as soon as I've sent in those patches I'll provide another status update with a bit more > information about moving d3d8 over to wined3d and the improvements that have been made. > > Oliver. > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com > >

Sept. 6, 2005

Re: Web Server Back Online

by Brian Vincent

On 9/2/05, Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > Is it possible to get the timestamps back into the mailing list archive? It is > useful e.g. for regression testing to see when patches were committed to cvs. Yeah, it's actually a showstopper for me too and I asked the same thing. It's exactly why there was no WWN last and why there isn't likely to be one this week. I'm sure mailman has some great features, but for me the pipermail archives suck rocks. -Brian

Sept. 6, 2005

DirectX status update....

by Oliver Stieber

I though it was about time I gave a status update on DirectX9/wined3d, so here goes. Short of a couple of bug fixes (one to shaders, and another that causes some games to crash) and a couple of patches that need resending (support for non-power2 textures in warhammer 40k) wined3d and d3d9 is functionally as complete as the version on http://directxwine.sourceforge.net/, that means that as soon as pixel shaders are coppied across from d3d8 it's more or less the end of adding features to wined3d and the start of fixing the remaining bugs and getting the performance up to spec. Anyhow, as soon as I've sent in those patches I'll provide another status update with a bit more information about moving d3d8 over to wined3d and the improvements that have been made. Oliver. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Sept. 6, 2005

Re: Web Server Back Online

by Jeremy Newman

No, it is not possible. On Fri, 2005-09-02 at 23:22 +0200, Stefan Leichter wrote: > Am Mittwoch, 31. August 2005 01:30 schrieb Jeremy Newman: > > The webserver is back online. There are still plenty of quirks to fix. > > Feel free to bug me here on wine-devel about any issues that crop up. > > > Hi Jeremy, > > thank you for the new webserver. > > Is it possible to get the timestamps back into the mailing list archive? It is > useful e.g. for regression testing to see when patches were committed to cvs. > > Thanks Stefan > >

Sept. 6, 2005

Re: URLMON: Added file protocol implementation

by Stefan Leichter

Am Samstag, 3. September 2005 21:22 schrieb Jacek Caban: > Changelog: > Added file protocol implementation Hello, this patch breaks the cross compiling of the tests with mingw. Which is the correct location of the class id? Bye Stefan make[3]: Entering directory `/usr/src/wine/wine-mingw/dlls/urlmon/tests' i386-mingw32-gcc generated.cross.o misc.cross.o protocol.cross.o url.cross.o testlist.cross.o -o urlmon_crosstest.exe -lurlmon -luser32 -lkernel32 -lole32 -luuid /usr/local/lib/gcc/i386-mingw32/3.4.2/../../../../i386-mingw32/lib/ libuuid.a(uuid.o):/usr/src/packages/BUILD/mingw-3.7/w32api-3.2/lib/uuid.c: (.rdata+0x1340): multiple definition of `_CLSID_FileProtocol' protocol.cross.o:/usr/src/wine/wine-mingw/dlls/urlmon/tests/../../../../wine/ dlls/urlmon/tests/protocol.c:63: first defined here collect2: ld returned 1 exit status make[3]: *** [urlmon_crosstest.exe] Fehler 1 make[3]: Leaving directory `/usr/src/wine/wine-mingw/dlls/urlmon/tests'

Sept. 6, 2005

Path for Testfiles (MSI: Test creating a package)

by Detlef Riekenberg

Hi After reading reading this commit, .... > ChangeSet ID: 20009 > Added files: > dlls/msi/tests : package.c > Test creating a package. > Patch: http://cvs.winehq.org/patch.py?id=20009 ... i Suggest that: - all directories and files for tests should be created in "%TEMP%\winetest" - we modify "wine/tests.h" to get this path and check for path and name overflows (MAX_PATH and nesting level). "c:" could be readonly or absent/hidden Any comments please. -- By By ... ... Detlef

Sept. 6, 2005

Re: [Now ns7] Dragon ns8 problem

by wino＠piments.com

On Tue, 06 Sep 2005 18:19:08 +0200, Jean Magnan de Bornier <jean(a)bornier.net> wrote: > | Again I think this was covered in earlier posts but I seem to recall > wine > | not being able to control the recording level. I set it to a suitable > | level before starting NS IIRC and it got through to the dictation > training > | OK. > > This is not enough, it appears! > Sound level is not ok for dns. I'll have to search a little more; hope > ALSA is not a problem per se for natspeak or wine? > >> I just checked my entry in wine appDB and I was using 20050524 when I installed and tested Naturally Speaking and I still that version on my system. Another user posts it as working with "june" CVS. I checked my ~/.wine/config and see the following: "Drivers" = "wineoss.drv" ; default for most common configurations I am running Gentoo with 2.6.11 kernel, alsa-1.0.8 with alsa-oss . So ALSA works in as much as my wine is using alsa-oss emulation. HTH.

Sept. 6, 2005

Re[2]: Need ideas about ntoskrnl

by Vitaliy Margolen

Tuesday, September 6, 2005, 7:34:44 AM, Francois Gouget wrote: > 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? This obviously will not work. Drivers need their own space (i.e. kernel space). Besides, that will complicate things a lot. Also that means adding to ntdll something that does not belong there. On the other hand, this allows to implement buffer method METHOD_NEITHER the way it should be (running in the process's thread context). > Wouldn't that cause problems if a driver expects to be able to maintain > shared information across processes? Yes it will. Is I understand, drivers don't have a concept of a process. So all the information they maintain, is global to all processes. > Do we know if this is going to be a problem with the drivers we are > interested in? It looks like all protection systems have some kind of loader, and the game itself in some kind of wrapper or encrypted. A loader can set some information up in the driver. This information will be used by the game process and/or wrapper to do some magic/decrypt game before starting it. All this means that we need a separate process emulating kernel internals (to some extent) just enough for these drivers to work. Wineserver is not a suitable place for drivers, since it's not a "windows process". We can't load drivers as a dll to the calling process either. This leaves only one option - dedicated process for drivers. Vitaliy

Sept. 6, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 05 septembre à 23:40:10 wino(a)piments.com écrit notamment: | On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier | <jean(a)bornier.net> wrote: > [...] > | Again I think this was covered in earlier posts but I seem to recall wine | not being able to control the recording level. I set it to a suitable | level before starting NS IIRC and it got through to the dictation training | OK. > | Depending on your hardware and mixer software you should make sure you | over-driving the sound by putting sliders at 100% and take care not to | confuse mike input and the mike capture settings. > | 'mik' seems to be the ammount of the mike input that is fed back to the | output mixer and is independant of the mike capture level. > | It is mike capture you need for NS. jean(a)borlap /home/jean % amixer set Mic,0 100 cap unmute Simple mixer control 'Mic',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined cswitch cswitch-joined cswitch-exclusive Capture exclusive group: 0 Playback channels: Mono Capture channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Playback 31 [100%] [on] Front Left: Capture [on] Front Right: Capture [on] This is not enough, it appears! Sound level is not ok for dns. I'll have to search a little more; hope ALSA is not a problem per se for natspeak or wine? > | > Strangely, as I have the french version, the text I'm | supposed to read for volume check is in english?? > | What's strange about that? Most software works that way ! OK, today after a reboot, opening natsepeak.exe brings me to the expected french interface! | Glad to hear you're getting somewhere. Sure, thx! -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 6, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 06 septembre à 17:28:53 Francois Gouget <fgouget(a)free.fr> écrit notamment: | On Tue, 6 Sep 2005, Jean Magnan de Bornier wrote: | [...] | > Sure these are quicker, thanks wino and François; actually I was pointing | > at the fact that the need to kill all those wine-preloader in order to | > wineboot is very poorly documented, either in man wine or in the docs at | > wineqh, so I had to find out this by trial and error... > | Actually I'd say the fact thay you need to kill these processes is a | bug. Not sure what's causing it though. Don't know if you mean a dns or a wine bug? probably the latter, so: My machine: Linux-gentoo, wine 20050725 cheers -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 6, 2005

Re: [Now ns7] Dragon ns8 problem

by Francois Gouget

On Tue, 6 Sep 2005, Jean Magnan de Bornier wrote: [...] > Sure these are quicker, thanks wino and François; actually I was pointing > at the fact that the need to kill all those wine-preloader in order to > wineboot is very poorly documented, either in man wine or in the docs at > wineqh, so I had to find out this by trial and error... Actually I'd say the fact thay you need to kill these processes is a bug. Not sure what's causing it though. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Kuba Ober

On Tuesday 06 September 2005 10:27, you wrote: > Kuba Ober wrote: > >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... > > Except that Windows doesn't have missing functions or functions that > aren't quite completely implemented. I was looking at it entirely from the overall stability standpoint, assuming that wine will otherwise move forward. If we assume that wine will forever be stuck where it's now then of course this wouldn't make big sense. But then it's a strategic decision that will affect the long run, mostly, as right now there'd be like one or two drivers supported anyway (copy protection I'd assume)... Kuba

Sept. 6, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 06 septembre à 16:26:24 Francois Gouget <fgouget(a)free.fr> écrit notamment: | 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. Sure these are quicker, thanks wino and François; actually I was pointing at the fact that the need to kill all those wine-preloader in order to wineboot is very poorly documented, either in man wine or in the docs at wineqh, so I had to find out this by trial and error... cheers, -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 6, 2005

Re: Need ideas about ntoskrnl

by Robert Shearman

Kuba Ober wrote: >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... > Except that Windows doesn't have missing functions or functions that aren't quite completely implemented. As Alexandre says, there is a ton of stuff that would have to be duplicated in order to be able to load Windows drivers in the wineserver. For example, PE loader, virtual memory, exceptions / signal handling and threading. Also note that the wineserver is single threaded (and it would be a big task to make it thread-safe) and that whenever you are calling driver code then all Wine apps are blocked. -- Rob Shearman

Sept. 6, 2005