August 2007 - Wine-Devel - list.winehq.org

Re: #winehq admin abuse

by Jeremy White

> aren't, things like this happen. I'm still banned from the channel, > people in this mailing list have said he shouldn't have banned me, and > yet, I'm still not unbanned. Ouch. I will say that I appreciate all that Vitaliy does; he truly does an amazing amount of helpful work. I also have great sympathy for his frustration with users. Further, I think the assessments of the conversation are essentially accurate; Vitaliy was quite reasonably frustrated with the conversation. But I want to state for the record that I think Jonathan is correct on one point: he should not have been banned, and he certainly should not be banned now. That was an overreaction and an abuse of op privileges, in my opinion. Vitaliy, I think you should take a break, or /ignore, or /kick, or use some other tool to ease your frustration; a ban is inappropriate except in the most extreme cases, in my opinion. Cheers, Jeremy

Aug. 17, 2007

Re: check_sharing disregards requested access

by Alexandre Julliard

"James Keane" <james.keane(a)gmail.com> writes: > check_access will now fail because the second caller is not honoring > FILE_SHARE_WRITE. but that shouldn't be neccesary as they are not > planning on writing anyways. The second caller won't, but the first one will, so you need FILE_SHARE_WRITE access. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2007

re: A script for automatic regression testing

by Dan Kegel

Martin wrote: > Regarding your script interface, I think it should accept these parameters: > * GIT_ID_1 - bisection start > * GIT_ID_2 - bisection end Sure, and/or dates and/or releases. * PNGs - list of PNG files which describe "bug hit" cases; No. The script should not invoke autohotkey, either. IMHO, it should instead factor out any knowledge about how to test for the bug into a user-supplied shell script. The script would be run once Wine is built, would check for the specific bug being searched for, and its exit status would be zero for success (no bug) and nonzero for failure (the bug was found). So using Mikolaj's script would require you to write a tiny shell script that invoked autohotkey on a script, or maybe just ran an installer and checked for the existance of a file, or something to do with PNG's, whatever you want. http://delta.tigris.org works this way; it calls the shell script "the oracle". - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Aug. 17, 2007

Re: Legal issues for contribution code into Wine

by Alexandre Julliard

"Dmitry Morovkov" <dmorovkov(a)gmail.com> writes: > After reading this, it looks like it's ok if someone have seen the windows > source code, and provided he is not going to directly copy unmodified source > code (what a stupid idea!), nor refer to it, he would be considered as a > good/trusted person? No, if you have seen parts of the Windows source code, you can't write code for Wine. We can't afford to take any risks in that area. -- Alexandre Julliard julliard(a)winehq.org

Aug. 17, 2007

Re: Issue(s) when running winetest on Windows

by Paul Vriens

Paul Vriens wrote: > Alexandre Julliard wrote: >> Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >> >>> Anyone? >>> >>> This is getting pretty serious now as several test reports that are >>> submitted will never be processed. I could of course try and fix this >>> in the parser but I do want to know what the issue is. The strange >>> thing is that it only happens in the msvcrt test (maybe because it's >>> file related). >> >> The only way is for the parent to wait for the child processes to >> terminate, by waiting on the process handles. >> > So what do you call the parent in this case? The winetest executable or > the test itself? The test itself is probably the only one who knows > about the processes it spawned/started. > > Do you know the reason why msvcrt/file.c uses _spawnvp, where the rest > of the test use CreateProcess (I've read some where that spawnvp is a > wrapper around CreateProcess anyway)? > > Cheers, > > Paul. > Something like this then: diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c index 46ccad6..98c8ada 100644 --- a/dlls/msvcrt/tests/file.c +++ b/dlls/msvcrt/tests/file.c @@ -34,6 +34,8 @@ #include <process.h> #include <errno.h> +static HANDLE prochandles[2]; + static void test_fdopen( void ) { static const char buffer[] = {0,1,2,3,4,5,6,7,8,9}; @@ -922,7 +924,7 @@ static void test_pipes(const char* selfname) arg_v[3] = str_fdr; sprintf(str_fdr, "%d", pipes[0]); arg_v[4] = str_fdw; sprintf(str_fdw, "%d", pipes[1]); arg_v[5] = NULL; - _spawnvp(_P_NOWAIT, selfname, arg_v); + prochandles[0] = (HANDLE)_spawnvp(_P_NOWAIT, selfname, arg_v); ok(close(pipes[1]) == 0, "unable to close %d: %d\n", pipes[1], errno); r=read(pipes[0], buf, sizeof(buf)-1); @@ -947,7 +949,7 @@ static void test_pipes(const char* selfname) arg_v[3] = str_fdr; sprintf(str_fdr, "%d", pipes[0]); arg_v[4] = str_fdw; sprintf(str_fdw, "%d", pipes[1]); arg_v[5] = NULL; - _spawnvp(_P_NOWAIT, selfname, arg_v); + prochandles[1] = (HANDLE)_spawnvp(_P_NOWAIT, selfname, arg_v); ok(close(pipes[1]) == 0, "unable to close %d: %d\n", pipes[1], errno); file=fdopen(pipes[0], "r"); @@ -1004,4 +1006,6 @@ START_TEST(file) test_get_osfhandle(); test_setmaxstdio(); test_pipes(arg_v[0]); + + WaitForMultipleObjects(2, prochandles, TRUE, 5000); } It's enough for the test on my box to have the lines in the correct order. Cheers, Paul.

Aug. 17, 2007

Re: Issue(s) when running winetest on Windows

by Paul Vriens

Jakob Eriksson wrote: > Alexandre Julliard wrote: >> Paul Vriens <paul.vriens.wine(a)gmail.com> writes: >> >> >>> Anyone? >>> >>> This is getting pretty serious now as several test reports that are >>> submitted will never be processed. I could of course try and fix this >>> in the parser but I do want to know what the issue is. The strange >>> thing is that it only happens in the msvcrt test (maybe because it's >>> file related). >>> >> The only way is for the parent to wait for the child processes to >> terminate, by waiting on the process handles. >> >> > > By the way. > I also noticed that Windows 95 actually bluescreens on rpcrt4 tests. > > regards, > Jakob > > But not every time? There a 2 reports of your win95 system(s) with the full report. Cheers, Paul.

Aug. 17, 2007

Re: Issue(s) when running winetest on Windows

by Paul Vriens

Alexandre Julliard wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> Anyone? >> >> This is getting pretty serious now as several test reports that are >> submitted will never be processed. I could of course try and fix this >> in the parser but I do want to know what the issue is. The strange >> thing is that it only happens in the msvcrt test (maybe because it's >> file related). > > The only way is for the parent to wait for the child processes to > terminate, by waiting on the process handles. > So what do you call the parent in this case? The winetest executable or the test itself? The test itself is probably the only one who knows about the processes it spawned/started. Do you know the reason why msvcrt/file.c uses _spawnvp, where the rest of the test use CreateProcess (I've read some where that spawnvp is a wrapper around CreateProcess anyway)? Cheers, Paul.

Aug. 17, 2007

Re: #winehq admin abuse

by Jonathan Challinger

I'm not going to continue this. This is my last message concerning this argument. I just have a few things to point out. Yes, there should be specific rules for IRC. Obviously, when there aren't, things like this happen. I'm still banned from the channel, people in this mailing list have said he shouldn't have banned me, and yet, I'm still not unbanned. Even if you don't have a lot of people to choose from, there should still be rules for those you do choose. This is a channel for END USERS. End users DO NOT ASK "SMART QUESTIONS." PERIOD. If you can't answer a "stupid question" in a civil way, by explaining how to ask or by linking to a guide to asking a smart question, don't answer it at all. Hell, I code decently myself, I've been using wine for over a year now (I think), and I STILL don't know that "err:ntdll:RtlpWaitForCriticalSection section 0x509da8c "?" wait timed out in thread 0047, blocked by 003e, retrying (60 sec)" is useless. Like I said, if it was a some random guy, it would've been rude. As a channel admin, he can at least exhibit some civility and say "that's a useless error message," instead of "oh well." Furthermore, if there was a known issue with certain hardware, that message would not be useless at all, as it is the only information available about the crash. As I would've explained if he'd been civil and MENTIONED that copying the files was a bad way to do it, I've been using a copied wow directory myself with the same version of wine with no problems. "I still fail to see how this is connected to being an op or not. This should be a general rule." It is connected to being an op because it is the op's JOB to keep the conversation civil. If he can't keep HIMSELF civil he has NO BUSINESS being an op, and frankly, no business being in the channel, period. "you stated that you hadn't read the FAQ" Where? Do you intend to ban every noob that asks a question without reading the FAQ? "starting the conversation in a "I'm a paying customer, and if people don't do what I want, I'll spend my money elsewhere" style message certainly doesn't help." I didn't. I merely stated that her switching to windows is out of my control and that I don't want to deal with fixing windows. In hindsight, yes, I would have phrased my question differently. Still, if you're going to offer a free help channel for free software you're essentially writing for charity, you should at least be prepared to be civil to those people who ask for help with a "tone" that you don't like. Its in the interest of the success of the project. If people stop using the app because the admin of the channel was a total fucking dick and publicly announced that he didn't care if the problem got fixed, the userbase of the project goes down, and eventually it dies. It will not have any developers, because no one wants to develop for a project with no users. I can so very easily circumvent the ban, and come back and ask the question when vitamin isn't around. I haven't, and I don't intend to. I'm done with wine, and now I'm done discussing its community's serious flaws. On 8/16/07, Kai Blin <kai.blin(a)gmail.com> wrote: > > On Thursday 16 August 2007 20:27:04 Jonathan Challinger wrote: > > Jonathan, > > without wanting to give the impression that you posted on this list and > now > everybody is ganging up on you, I do have a couple of comments here. > > > Jan Zerebecki, I'd be happy to help, but how? I could develop some > > guidelines and rules for admins to follow, but then what? How would they > be > > enforced? I have no authority to put such things in place. Its not the > > writing rules that's hard, its the enforcing them. Here: i'll write them > > now: > > Either participate politely or don't participate at all > > Break up flamewars, don't start them. > > I completely agree for mailing lists. But this doesn't really map well to > IRC. > Communication is much less precise and faster in chat. I don't have a good > solution. Does someone have a good set of explicit rules that work for > IRC? > > > There needs to be some kind of structure, though. Presumably, unless > he's > > the project leader, there's someone who can take away his admin > privileges. > > There should be guidelines for how admins behave, and admins who don't > > behave according to said guidelines should have their admin privileges > > suspended or removed. > > That's not the way it works, though. There need to be people willing to do > this job. If you have a large number to pick from, you can be picky. > Vitaliy > devotes a lot of time to helping people in #winehq, even though I agree he > is > a bit rude from time to time. Still, you will find that he's really > helpful > if you ask "smart questions", as esr defines them. > > > > > Tom Wickline, I am Pie-rate, not carretto. I still don't agree with how > he > > handled carretto. Maybe the community should try appointing admins based > on > > people skills, not coding skills? > > Agreed. Ideally the developers should do as little user support as > possible to > be able to spend more time developing. However, most wine users only come > into #winehq to bitch about some programs not working and to ask for help. > Again, if more people in there were actually active helping people, > someone > would have said something else than "oh well", and don't tell me you'd > just > have ignored the "oh well" in that case. > > Of course building a good community is important, and I think your email > scratches the surface of the problem Wine as a project has with it's > community. But that's material for a different thread. > > > The problem here is I asked a question in a help channel, not to him > > specifically, but he answered it just to state that he doesn't care. He > > then banned me for voicing concern over whether he should be doing such > > things. > > Ok, if you don't mind I'll dissect the question a little. > > [some formatting added for better readability] > > <Pie-rate>: my brother's girlfriend's WoW install is > crashing (locking up, stops responding) randomly. > > Here, you describe the problem you're seeing. So far, so good. > > <Pie-rate>: she will install windows tomorrow if it doesn't get fixed. i > don't > like windows and i don't want to deal with it. > > Here, you're trying to to stress how important your problem is. While this > might be important for you, it is not for me, and I doubt it is for lots > of > other Wine developers. I don't work on Wine because I want to make more > people switch to Linux. I stopped caring what operating system people use > about six years ago, as long as they don't mind what OS I use. > > Frankly, I started working on Wine because I was paid to work on it, and > while > I'm not paid anymore, I like the challenge of working on problems like > figuring out how Windows ticks and to make Wine tick the same way. > > But back to the analysis. > > <Pie-rate>: the message it crashes with is: > err:ntdll:RtlpWaitForCriticalSection section 0x509da8c "?" wait timed out > in > thread 0047, blocked by 003e, retrying (60 sec) > > This is not really helpful, but arguably that's a bit hard to tell without > knowing Wine. So I'd say this one is fine. > > <Pie-rate>: this is with an install copied over from my > computer, which i KNOW works flawlessly, and wine 0.9.41 > > If I'd do that on Windows, it'd break for a lot of apps. Why people think > Wine > is different is beyond me. As Juan said in his email. the FAQ clearly > states > not to do that. > > > Civility is important to a degree in the freenode channels, but swearing > > like a sailor while banning people who complain about it is just > > ridiculous. As an admin, you should be helping politely or not helping > at > > all, and breaking up flamewars, not starting them. > > I still fail to see how this is connected to being an op or not. This > should > be a general rule. > > Anyway, looking at my experience with Open Source help channels, you're > basically always expected to have read the FAQ before asking questions if > you > want someone to help you. You actually didn't ask a question and you > stated > that you hadn't read the FAQ. So I think an "oh well" response, while > certainly not ideal, was well justified. > > I agree with you that banning people who disagree is bad style. > Personally, > I'd probably just ignore the whole thing. But starting the conversation in > a "I'm a paying customer, and if people don't do what I want, I'll spend > my > money elsewhere" style message certainly doesn't help. We do get that a > lot, > and having done support in a volunteer organization myself, I know this > gets > on your nerves quite quickly. > > Anyway, I don't want to single you out for being the bad guy, I just > wanted to > explain a little why the echo you got here was the way it is. > > Oh, one other thing. It's a bit rude to take a personal email back to a > public > list without consent of the poster, especially if the poster stated that > he > didn't want the email to go to said list. Also, top-posting is against > common > mailing list etiquette. > > Cheers, > Kai > > -- > Kai Blin > WorldForge developer http://www.worldforge.org/ > Wine developer http://wiki.winehq.org/KaiBlin > Samba team member http://www.samba.org/samba/team/ > -- > Will code for cotton. > >

Aug. 17, 2007

Re: About WritePrivateProfileString and file operations

by James Keane

I think there is a problem with the check_sharing function in server/fd.c. At the end of the function when it is checking existing_access with the sharing variable it doesn't seem to care about what the caller is requesting. I think this is what is causing problems with the CreateFile call, because the check_sharing function doesn't care if you don't even want write access it will still check if you have the sharing bit. I have created a patch that will hopefully solve the real problem instead of the hack in WriteProfileString, I am not sure it is the 100% correct way to do it yet. On 8/16/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Zhongli Xu <zhongli.xu <at> gmail.com> writes: > > > > > Hi all,I run some tests about mixed using WritePrivateProfileString and stand > file operationsCodes look like this:GetPrivateProfileString(keyname, > value);fopen();fprintf("# comments"); > > fclose();WritePrivateProfileString(keyname, newvalue);What I found in the file > is that either WritePrivateProfileString operation succeeded(newvalue has been > written) or fprintf succeeded("#comments" shows up in the file). > > On windows hosts, there is no such problem.Any suggestion or idea is > welcomed.Thanks.Milo > > > > > > > > I don't know if it's the same issue but i know there is a bug in wine's > implementation of WritePrivateProfileString. > See http://bugs.winehq.org/show_bug.cgi?id=5024 > > I currently use this hack http://bugs.winehq.org/attachment.cgi?id=6750 to > install the game. Maybe it helps for your app too, and maybe someone could pick > up this bug. > > > > >

Aug. 16, 2007

Re: RFC: root cert tool

by Paul Millar

Hi Juan, On Wednesday 15 August 2007 20:02:17 Juan Lang wrote: [snip!] > Yes, that's true, but if trust truly is the issue, we have to ask what > exactly is being protected. [nothing's using Wine's CA root certs] Sure, if nothing is using Wine's root store just now it's probably overkill. I'm just a little concerned that one day something will, and assume the Root store is trustworthy. > In my personal opinion, certificates don't say as much as we'd like > them to. I guess, ultimately, it comes down to the individual CA's Signing Policy document; but yes, I guess certificates may not mean as much as people think. They do mean something. > If we'd never used certs with SSL, perhaps eavesdropping > attacks would be more prevalent, but that doesn't seem likely either - > one can use key negotiation protocols that don't assume you trust the > other end. Sorry, I'm not sure I follow you here. I may be missing something, but I don't see what you hope to get back from an untrusted remote server. For TLS, if both ends have established the session key (via asymmetric encryption, if you happen to have the public key or anonymously, via DH) then the only way to eavedrop is via a MitM attack or a variant. The certificate chain-of-trust is to prevent these MitM attacks. > Man-in-the-middle attacks might be more likely - but they > apply to downloading Firefox in the first place, so the fact that we > ignore them means that they're either not that much of a threat, or > that people don't care about them. I think also "too (computationally) expensive to do", but it looks like that's changing. > Attackers - and I'm thinking of > the web here - seem to be much more likely to engage in social > engineering attacks, perhaps because users can't tell the difference > between SSL-protected sites and ordinary ones, nor can they articulate > the difference between the two, even if they can discern it. (I can > dig up some paper references on this if you like.) I believe you! But, I think this will change (slowly) over time. Attackers (the "informed" ones, anyway: Shannon's maxim) will go after the weakest link. Good enough crypto is where "they" use others methods: Trojans or key-loggers (installed somehow), steal the remote server's hard disk or wait for someone to loose a laptop or the backup tapes. As people get better informed and software better, I imagine attacking the chain of trust becomes more attractive. > [...] The problem is that certs are opaque (asn.1 encoded,) so Alexandre > can't easily judge whether the certs are correct. I think it depends what you mean by "correct": do they function correctly or are they the correct certificates. It would be hard to make the former easy for a human (even for Alexandre) because of the maths involved, with some software its easy. The latter is verifying authenticity, which would require something else (e.g. out-of-band comms). [...] > What do you think of my most recent suggestion, that the Root store > should not read from the registry, but should read from certs > installed locally, where the path to them is set in the registry? But, yes, given that most distros have a collection of CA Root certs, using them would make sense. Saves us the bother. Do any Windows applications expect to be able to manage the root store? Cheers, Paul.

Aug. 16, 2007