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

Re: wininet: initialize a buffer

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > Valgrind is complaining we are doing strcmp() on the buffer without > initializing it. You should fix the code to not do the strcmp when we don't have a valid buffer, instead of hiding the bug by clearing memory. -- Alexandre Julliard julliard(a)winehq.org

Nov. 8, 2007

Re: %fs, %gs on AROS hosted

by Marcus Meissner

On Wed, Nov 07, 2007 at 09:25:51PM +0100, Staf Verhaegen wrote: > On Wed, 07 Nov 2007 08:37:34 +0100, Marcus Meissner > <marcus(a)jet.franken.de> wrote: > > > On Tue, Nov 06, 2007 at 10:17:12PM +0100, Staf Verhaegen wrote: > >> Hello wine developers, > >> > > > Win32 (and so Wine) uses %fs as the thread selector. > > > > It needs to stay constant over process switches (as in "saved") and the > > base > > virtual address must be settable. > > > > But the use of %fs by wine does not seem to conflict in any way with a > possible usage of that segment register by the OS where wine is running > on. Or is there some OS specific code that is handling it ? No, it does not conflict. Your syscall / scheduler entry/exit points however need to take care to save/restore it correctly, otherwise you get interesting crashes ;) Ciao, Marcus

Nov. 8, 2007

Re: #winehq admin troubles

by Tom Wickline

This thread has made me nothing but sick...... Chris suggest we ban Vitamin, Jeremy suggested he not use his OP privileges for a time. others bitch and cry that there being treated mean... But as the song goes, one should never spit into the wind. So with that said until Vitamin is asked to be a OP and is allowed to use those privileges as he sees fit I will no longer be in #winehq Tom Wickline

Nov. 8, 2007

Re: #winehq admin troubles

by feba thatl

Actually, Dan, I disagree. I don't think he needs to be taken off the 'frontlines' at all. I don't even think his ops permissions need to be taken away, at least not yet. I think it's #winehq which needs to be taken care of. We could ban Vitamin off the face of the internet, but that's not going to fix anything. However, adding rules and conditions to the channel might. First of all, if there are rules in place for how admins should act, it is fairer for everyone. Admins don't get banned or de@'d for things they didn't think were a problem, and users don't get banned or kicked for things they didn't think were problems. In addition, a set of rules would increase efficiency, as it could get better answers from users, and quicker, more accurate replies from others; which apart from being nicer on users, would also be less stressful for people supporting them. Lastly, and I think the best benefit to rules, is that they somewhat 'dehumanize' the banning process, if they're made correctly. Admins would know precisely when they can or cannot ban someone, so they do not have to worry about getting in trouble over it, and users have no one to be angry at but themselves when they are removed by force. Even simple rules could help. For example, add the following to the IRC page of appdb, and link to that instead of the FAQ in the channel topic: Rules for #winehq: 1. Before you do anything, read the FAQ. 2. After that, check the appdb and google to see if anyone has already had your problem. 3. If you find nothing after an honest effort of searching, try #winehq, and ask your question as follows: a. Phrase your question in the best English you can (no chtspk, please), and describe the problem as thoroughly as possible. b. Include any information that may be of help, such as OS/distro, wine --version, things you've already tried, <other thelpful info here> 4. After you have asked, be patient. #winehq is made up entirely of volunteers, and even if someone who wants to help might not know what to do in your case. On the other hand, someone who does might get annoyed by your antics, and ignore you anyway. 5. Again, remember #winehq is made up of volunteers. Please do not mistreat them, or you may be kicked at an admin's discretion. 6. If an admin asks you to stop doing something, please stop doing it. If you do not, you may be kicked. That would be simple and quick enough for any user who is going to get a reply anyway. The admin rules would need to be a bit more complex (how to try to treat people, what they can't ask people to stop doing, when they can break out the banhammer), but not very much so. This also has the benefit of any action taken against @s being purely a 'you broke the rules' decision, instead of a 'convicted in the court of public opinion' covering-of-#winehq's-ass.

Nov. 8, 2007

Re: #winehq admin troubles

by Edward Savage

This thread has become rather long and I don't have time to catch up completely on it though I'd like to add weight to those commenting on how Vitamin deals with the channel. Being one of the many users to suffer his wrath when I first joined the wine community I can comment on just how off putting he can be. Having helped extensively in debian and several other channels I however understand how painful it can be. I wander in and help in winehq as often as I can these days and I notice the users we tend to get are worse than those of other channels, they rarely google, they do their best not to understand, and they expect far to much. Though at the end of the day these are the people we need to be changing and adding to the community. Furthermore, I'd like to add the comment that the majority of the time Vitamin is perfectly calm and collected in his moderating, I'd like to stress this. Though some times he acts far outside what is required of him, no user in need should be banned, _ever_, and kicking should be reserved for real pains. Patience is really what is needed here and it is some thing Vitamin lacks at least some of the time. While I don't mind the snide attitudes of those helping in the channel, as they are result of users being dealt with (and I am guilty of it myself), I would like to see a reduction in the ability to moderate those users so that they are not abused beyond reason. At the end of the day you can use words far more effectively to deal with a nuisance than a ban and this is some thing any one with OP power needs to understand. Edward On Nov 6, 2007 7:27 AM, Dan Kegel <dank(a)kegel.com> wrote: > Luke Bratch wrote: > > After seeing Vitamin deal with people for a long time > > now, I can say I totally agree with how he does > > things. > > Technically, he's spot on. > It's his bedside manner that is broken. > We really don't want him on the front line of support, > somebody else should do that. > But once the newbies are filtered out, he's great. > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > > >

Nov. 8, 2007

Problem with client manually starting services

by Roy Shea

Howdy All, I'm developing missing services in Wine and am running into problems with how Wine starts services. In Windows a service can be started using "net start <service name>", assuming that the service is properly added to the registry. In Wine it appears that the user must manually start the service before calling "net start <service name>", or the service fails to start. This is blocking me from developing an svchost wrapped DLL. I guess its not surprising that the work around of first manually starting a service fails for a DLL with no main function :-) Dan Kegel mentioned a recollection of a known bug in Wine along these lines where, as a work around, clients are manually starting servers. Anyone know more details on this problem? Any pointers to old emails or knowledge of this problem would be a big help I start digging through WINEDEBUG logs. Thanks! -Roy

Nov. 8, 2007

Wine LivePC

by T.J. Purtell

Hey, I've build a Wine LivePC so that people can take a linux operating system capable of running Windows programs on a USB drive. Its great for carrying a portable work environment with you, providing a container for safely running executables you download from the internet, or making an isolated environment for a family member that they can carry with them. http://www.moka5.com/node/1620 Obviously the LivePC is free, but registration on the site is required to download the free engine for using LivePC (Its based off VMware player). It has the latest version of Wine, so using this is an easy way to check if a particular application is well supported in Wine. Cheers, -T.J.

Nov. 7, 2007

Re: %fs, %gs on AROS hosted

by Staf Verhaegen

On Wed, 07 Nov 2007 08:37:34 +0100, Marcus Meissner <marcus(a)jet.franken.de> wrote: > On Tue, Nov 06, 2007 at 10:17:12PM +0100, Staf Verhaegen wrote: >> Hello wine developers, >> > Win32 (and so Wine) uses %fs as the thread selector. > > It needs to stay constant over process switches (as in "saved") and the > base > virtual address must be settable. > But the use of %fs by wine does not seem to conflict in any way with a possible usage of that segment register by the OS where wine is running on. Or is there some OS specific code that is handling it ? greets, Staf.

Nov. 7, 2007

valgrind results for Oct 7

by Dan Kegel

This time I filtered out files whose only error was trying to close(-1). http://kegel.com/wine/valgrind/20071107/ Quite a few tests no longer show problems (partly because of the new filtering): comctl32/imagelist crypt32/oid crypt32/store d3d9/visual kernel32/console msi/package oleaut32/vartest rpcrt4/server shell32/shlfileop That leaves 75 tests with problems. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Nov. 7, 2007

Re: advapi32: fix buffer overrun in tests/registry.c:wine_debugstr_wn(), try 3

by Dan Kegel

On 11/7/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > That function is really supposed to print n chars, not n-1. The > terminating null probably needs to be included in the length. Hmm. The function is only called on registry keys and values, none of which are really nul terminated (and some vendors use embedded nuls on purpose). I think the unconditional nul termination check is a bug introduced when the author forked the function from the copy in libs/wine/debug.c. Patch coming...

Nov. 7, 2007