Object manager case sensitivity issue
I want to make sure that this problem is well understood. Also to make it clear that Wine differs from windows in this really important aspect. For more details, you can refer to the following thread: http://www.winehq.org/hypermail/wine-devel/2005/04/0426.html It needs to be fixed at least on the server level (I have sent a patch for one of the possible solutions). Then we can get ntdll to follow the suite. For a test see attached program. You should be able to run it on windows with administrative privileges. As you can see, this is something very dangerous yet perfectly legal, at least on win2k sp4. -- Best regards, Vitaliy test_symlinks.c Description: Binary data
Re: Need ideas about ntoskrnl
Peter Beutner wrote: Yupp most of the code maybe already in ntdll. But imo it is quite as ugly, from a design point of view, to call ntdll functions from inside the ntoskrnl. It should be the other way around, shouldn't it? Sure, you just have to convince Alexandre that it's a good idea to move all the Nt* APIs to ntoskrnl, you're welcome to try but I think it's something you won't s do before wine 8.0 Ivan
Strange problem with writing files from wine
Hi! I have problems with writing files from wine (today's CVS). Typical example is word95, which always writes something like: Cannot access folder "F:\filename.doc ": unaccessible or protected by password (in my local language, so it may be inaccurate). There is a small problem with this strange indentation (that the second double quote is on a next line, but it is not fatal. More fatal is that this dialog even occurs and the file cannot be written. I've created a tracefile with +file and I think I've found the problem. At the moment of attempt to write (in this example, F:\brumbal.doc), there appears: trace:file:CreateFileW L".\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L".\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L".\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L".\\F:" (status c022) trace:file:CreateFileW returning 0x trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" trace:file:GetFileAttributesW L"F:\\brumbal.doc\r\n" trace:file:RtlDosPathNameToNtPathName_U (L"F:\\brumbal.doc\r\n",0x7fc8aae4,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\brumbal.doc\r\n" 520 0x7fc8a8b0 (nil)) trace:file:CreateFileW L".\\F:" GENERIC_READ FILE_SHARE_READ FILE_SHARE_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L".\\F:",0x7fc8975c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L".\\F:" 520 0x7fc89508 (nil)) trace:file:get_dos_device L"F:" -> "/dev/hdb1" warn:file:CreateFileW Unable to create file L".\\F:" (status c022) trace:file:CreateFileW returning 0x trace:file:RtlDosPathNameToNtPathName_U (L"F:\\",0x7fc89744,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"F:\\" 520 0x7fc89508 (nil)) trace:file:wine_nt_to_unix_file_name L"\\??\\F:\\" -> "/home/patrol/.wine/dosdevices/f:/" [EMAIL PROTECTED]:/opt/samba-dir/Program Files/Microsoft Office/Office$ Why the hell wine is trying to access /dev/hdb1 ? Yes, my home directory is on it, but I think that such a form of access is not good :-). In my .wine/dosdevices, there is clearly a line lrwxrwxrwx 1 patrol users 12 Sep 7 06:50 f: -> /home/patrol Or am I misinterpreting the log and the failure is caused by something else ? Otherwise wine is working near to perfect now. With regards, Pavel Troller
Re: Suggestions for improvement of the emulator
Juan Lang wrote: 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. So what? just set "Rejected, reason: tests needed" or "will review later" or whatever. Ivan.
Re: Need ideas about ntoskrnl
Alexandre Julliard schrieb: Peter Beutner <[EMAIL PROTECTED]> 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. Yupp most of the code maybe already in ntdll. But imo it is quite as ugly, from a design point of view, to call ntdll functions from inside the ntoskrnl. It should be the other way around, shouldn't it?
Re: Suggestions for improvement of the emulator
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. I've always thought that sort of thing should be done and would be cool, maybe the guys working on appdb could try and come up with something?
Re: Suggestions for improvement of the emulator
> 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/
Re: Suggestions for improvement of the emulator
> 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) . Cheers, Jeremy
Re: add proper support for native NT drivers and programs to the build system
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.
Re: Suggestions for improvement of the emulator
--- Dmitry Timoshkov <[EMAIL PROTECTED]> wrote: > "Hiji" <[EMAIL PROTECTED]> 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
Re: Suggestions for improvement of the emulator
"Hiji" <[EMAIL PROTECTED]> 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.
Re: Path for Testfiles (MSI: Test creating a package)
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
Re: Suggestions for improvement of the emulator
--- Steven Edwards <[EMAIL PROTECTED]> wrote: > Hello, > > On 9/6/05, Francois Gouget <[EMAIL PROTECTED]> 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
Re: Suggestions for improvement of the emulator
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.
Re: Suggestions for improvement of the emulator
Hello, On 9/6/05, Francois Gouget <[EMAIL PROTECTED]> 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
Re: Suggestions for improvement of the emulator
> [...] > > 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/
Re: DirectX status update....
--- James Liggett <[EMAIL PROTECTED]> 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
Re: DirectX status update....
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 > >
Re: Web Server Back Online
On 9/2/05, Stefan Leichter <[EMAIL PROTECTED]> 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
DirectX status update....
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
Re: Web Server Back Online
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 > >
Path for Testfiles (MSI: Test creating a package)
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
Re: URLMON: Added file protocol implementation
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'
Re: [Now ns7] Dragon ns8 problem
On Tue, 06 Sep 2005 18:19:08 +0200, Jean Magnan de Bornier <[EMAIL PROTECTED]> 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.
Re[2]: Need ideas about ntoskrnl
Tuesday, September 6, 2005, 7:34:44 AM, Francois Gouget wrote: > On Tue, 6 Sep 2005, Alexandre Julliard wrote: >> Peter Beutner <[EMAIL PROTECTED]> 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
Re: [Now ns7] Dragon ns8 problem
Le 05 septembre à 23:40:10 [EMAIL PROTECTED] écrit notamment: | On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier | <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] /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
Re: [Now ns7] Dragon ns8 problem
Le 06 septembre à 17:28:53 Francois Gouget <[EMAIL PROTECTED]> é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
Re: [Now ns7] Dragon ns8 problem
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 [EMAIL PROTECTED]http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean
Re: Need ideas about ntoskrnl
On Tuesday 06 September 2005 10:27, you wrote: > Kuba Ober wrote: > >On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote: > >>Peter Beutner <[EMAIL PROTECTED]> 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
Re: [Now ns7] Dragon ns8 problem
Le 06 septembre à 16:26:24 Francois Gouget <[EMAIL PROTECTED]> écrit notamment: | On Mon, 5 Sep 2005, [EMAIL PROTECTED] wrote: > | > On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier | > <[EMAIL PROTECTED]> 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
Re: Need ideas about ntoskrnl
Kuba Ober wrote: On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote: Peter Beutner <[EMAIL PROTECTED]> 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
Re: [Now ns7] Dragon ns8 problem
On Mon, 5 Sep 2005, [EMAIL PROTECTED] wrote: On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
Re: Installers freezing - ole, games
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
Re: Installers freezing - ole, games
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 tmarshaltest.tar.bz2 Description: application/bzip
Re: add proper support for native NT drivers and programs to the build system
Ivan Leo Puoti <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
Re: Need ideas about ntoskrnl
On Tue, 6 Sep 2005, Alexandre Julliard wrote: Peter Beutner <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
Re: [Now ns7] Dragon ns8 problem
On Mon, 05 Sep 2005 15:23:26 +0200, Jean Magnan de Bornier <[EMAIL PROTECTED]> 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 ;) Never mind, now the issue is to have sound; the volume check does not complete as for now. 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. 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 ! I am still running wine-20050524 that I used with NS7, and that worked well. It may be useful to post the version you are using for the record . Glad to hear you're getting somewhere. 8)
Re: Suggestions for improvement of the emulator
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 [EMAIL PROTECTED]http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Re: Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8
--- Karsten Elfenbein <[EMAIL PROTECTED]> wrote: That looks fine, thanks. > Added A2R10G10B10 and D3DFMT_D24FS8 modes to all other functions. > > Karsten > > > -Ursprüngliche Nachricht- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Im Auftrag von Oliver Stieber > > Gesendet: Samstag, 3. September 2005 22:15 > > An: wine-devel@winehq.org; [EMAIL PROTECTED] > > Betreff: ***SPAM*** Re: Wined3d: added A2R10G10B10 and D3DFMT_D24FS8 > > > > > > > > --- Karsten Elfenbein <[EMAIL PROTECTED]> 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
Re: Suggestions for improvement of the emulator
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.
Re: Need ideas about ntoskrnl
On Tuesday 06 September 2005 07:38, Alexandre Julliard wrote: > Peter Beutner <[EMAIL PROTECTED]> 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
Re: Suggestions for improvement of the emulator
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
Re: Need ideas about ntoskrnl
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
Re: Suggestions for improvement of the emulator
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. > 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
Re: Need ideas about ntoskrnl
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
Re: Need ideas about ntoskrnl
Peter Beutner <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: fonts: don't call LineTo with the gdi lock
Huw D M Davies <[EMAIL PROTECTED]> writes: > On Sun, Aug 28, 2005 at 12:04:41PM +0100, Huw D M Davies wrote: >> Huw Davies <[EMAIL PROTECTED]> >> 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 [EMAIL PROTECTED]
Re: Need ideas about ntoskrnl
Peter Beutner wrote: Any reasons given? Yes, he doesn't want driver in the wineserver. Ivan.
Re: Need ideas about ntoskrnl
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.
Re: Need ideas about ntoskrnl
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
Re: Need ideas about ntoskrnl
> "Ivan" == Ivan Leo Puoti <[EMAIL PROTECTED]> 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[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Need ideas about ntoskrnl
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
Re: Need ideas about ntoskrnl
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
Re: Suggestions for improvement of the emulator
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 re
Re: MSI: test creating a package
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
Re: MSI: test creating a package
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
Messages from 2030 (Laxdragon please read)
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.
ntoskrnl patch, reviews/comments/suggestions wanted
As Dmitry rightly pointed out, wine-devel is a good place to post stuff for help/comments/review, so here is an (almost) full diff of my tree against cvs. Without going as far as making wineserver a user mode ntoskrnl like mike_m suggested, this code allows kernel mode drivers to work decently in wine, naturally not many have been tested but it's a start. Alexadre's main complaint is that it's ugly to pass handles to ntoskrnl because it's a client process, currently we pass a pointer to a DEVICE_OBJECT, that obviously won't do but we're not sure what would do, suggestions are welcome. secdrv.sys from safedisc 1 works. Some code used to work around the anti debugger checks has been removed, so you can't run safedisc in winedbg with this patch. Running tools/make_requests and a full ./config.status && make depend && make is needed to build this patch. Ivan. ntoskrnl.diff.bz2 Description: Binary data
Re: MSI: test creating a package
Hi, On Tue, Sep 06, 2005 at 03:21:55PM +0900, Mike McCormack wrote: > ChangeLog: > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > * test creating a package +res = MsiCloseHandle( suminfo); +ok( res == ERROR_SUCCESS , "Failed to close suminfo" ); + + +res = MsiCloseHandle( hPackage); +ok( res == ERROR_SUCCESS , "Failed to close package" ); +} Hmm, something seems to be missing here... Andreas
Re: Some troubles with InstallShield
On Mon, Sep 05, 2005 at 10:21:17PM +0400, Vitaly Lipatov wrote: > Can anyone test PHP Expert Editor for install? It uses InstallShield > and install loop at message "File access denied." > > http://www.ankord.com/download/phpxedit_33.zip Installs fine here (except dialogbox at the end and that it requires ActiveX). Make sure no other InstallShield instances are running before starting the install. (killall wine-preloader) Ciao, Marcus
