Re: #winehq admin troubles
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
Re: #winehq admin troubles
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, 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.
Re: #winehq admin troubles
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 <[EMAIL PROTECTED]> 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 > > >
Problem with client manually starting services
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 ", 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 ", 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
Wine LivePC
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.
Re: %fs, %gs on AROS hosted
On Wed, 07 Nov 2007 08:37:34 +0100, Marcus Meissner <[EMAIL PROTECTED]> 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.
valgrind results for Oct 7
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
Re: [10/14] WineD3D: Implement the varying map
Am Mittwoch, 7. November 2007 08:10:35 schrieb Stefan Dösinger:
> Am Dienstag, 6. November 2007 23:41:40 schrieb Allan Tong:
> > On 11/6/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
> > > +/* Don't do any register mapping magic if it is not needed, or
> > > if we can't + * achive anything anyway
> > > + */
> > > +if(highest_reg_used < (GL_LIMITS(glsl_varyings) / 4) ||
> > > + num_regs_used >= (GL_LIMITS(glsl_varyings) / 4) ) {
> > > +if(num_regs_used >= (GL_LIMITS(glsl_varyings) / 4)) {
> >
> > Should it not be "num_regs_used > (GL_LIMITS(glsl_varyings) / 4)"?
>
> yes, I think you are right. Thanks for spotting this
Here is a fixed patch
From f53befe0cdc63ea8175091d7a3e985b81fdcefe2 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger <[EMAIL PROTECTED]>
Date: Wed, 7 Nov 2007 10:30:15 +0100
Subject: [PATCH] WineD3D: Implement the varying map
This patch actually implements the map made possible with the last
patch.
---
dlls/wined3d/baseshader.c | 20 ++--
dlls/wined3d/glsl_shader.c |3 +++
dlls/wined3d/pixelshader.c | 35 +--
dlls/wined3d/wined3d_private.h |1 +
4 files changed, 55 insertions(+), 4 deletions(-)
diff --git a/dlls/wined3d/baseshader.c b/dlls/wined3d/baseshader.c
index 2d1c5d9..df0ac0c 100644
--- a/dlls/wined3d/baseshader.c
+++ b/dlls/wined3d/baseshader.c
@@ -422,8 +422,24 @@ HRESULT shader_get_registers_used(
else if (WINED3DSPR_TEMP == regtype)
reg_maps->temporary[reg] = 1;
-else if (WINED3DSPR_INPUT == regtype && !pshader)
-reg_maps->attributes[reg] = 1;
+else if (WINED3DSPR_INPUT == regtype) {
+if( !pshader)
+reg_maps->attributes[reg] = 1;
+else {
+if(param & WINED3DSHADER_ADDRMODE_RELATIVE) {
+/* If relative addressing is used, we must assume that all registers
+ * are used. Even if it is a construct like v3[aL], we can't assume
+ * that v0, v1 and v2 aren't read because aL can be negative
+ */
+unsigned int i;
+for(i = 0; i < MAX_REG_INPUT; i++) {
+((IWineD3DPixelShaderImpl *) This)->input_reg_used[i] = TRUE;
+}
+} else {
+((IWineD3DPixelShaderImpl *) This)->input_reg_used[reg] = TRUE;
+}
+}
+}
else if (WINED3DSPR_RASTOUT == regtype && reg == 1)
reg_maps->fog = 1;
diff --git a/dlls/wined3d/glsl_shader.c b/dlls/wined3d/glsl_shader.c
index 3dfca51..4083d56 100644
--- a/dlls/wined3d/glsl_shader.c
+++ b/dlls/wined3d/glsl_shader.c
@@ -2670,6 +2670,9 @@ static void handle_ps3_input(SHADER_BUFFER *buffer, semantic *semantics_in, sema
if(map[i] >= (GL_LIMITS(glsl_varyings) / 4)) {
FIXME("More input varyings declared than supported, expect issues\n");
continue;
+} else if(map[i] == -1) {
+/* Declared, but not read register */
+continue;
}
register_token = semantics_in[i].reg;
diff --git a/dlls/wined3d/pixelshader.c b/dlls/wined3d/pixelshader.c
index daeae42..483c0ad 100644
--- a/dlls/wined3d/pixelshader.c
+++ b/dlls/wined3d/pixelshader.c
@@ -543,7 +543,7 @@ static HRESULT WINAPI IWineD3DPixelShaderImpl_SetFunction(IWineD3DPixelShader *i
if (WINED3DSHADER_VERSION_MAJOR(This->baseShader.hex_version) > 1) {
shader_reg_maps *reg_maps = &This->baseShader.reg_maps;
HRESULT hr;
-unsigned int i;
+unsigned int i, j, highest_reg_used = 0, num_regs_used = 0;
/* Second pass: figure out which registers are used, what the semantics are, etc.. */
memset(reg_maps, 0, sizeof(shader_reg_maps));
@@ -553,7 +553,38 @@ static HRESULT WINAPI IWineD3DPixelShaderImpl_SetFunction(IWineD3DPixelShader *i
/* FIXME: validate reg_maps against OpenGL */
for(i = 0; i < MAX_REG_INPUT; i++) {
-This->input_reg_map[i] = i;
+if(This->input_reg_used[i]) {
+num_regs_used++;
+highest_reg_used = i;
+}
+}
+
+/* Don't do any register mapping magic if it is not needed, or if we can't
+ * achive anything anyway
+ */
+if(highest_reg_used < (GL_LIMITS(glsl_varyings) / 4) ||
+ num_regs_used > (GL_LIMITS(glsl_varyings) / 4) ) {
+if(num_regs_used > (GL_LIMITS(glsl_varyings) / 4)) {
+/* This happens with relative addressing. The input mapper function
+ * warns about this if the higher registers are declared too, so
+ * don't write a FIX
Re: Develop .h for Wine by looking Microsoft Platform SDK
On 11/7/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 7. November 2007 01:00:54 schrieb King InuYasha: > > It is not legal at all. Using Microsoft Platform SDK header code is not > > under the GNU General Public License version 2.0 or its listed compatible > > licenses, so you have to do it manually WITHOUT looking at the PSDK. I > > recommend removing the PSDK from your system as a way to remove temptation. > Headers contain facts, and facts cannot be copyrighted. Also the sdk headers > are the only source of information. Collecting them from the msdn is not > going to work. > > The typing of the header itself is copyrighted though, so you must not > copypaste from the MS Header. The wine header should be implemented as > differently as possible, but still be 100% compatible. Especially watch out > that the wine header includes the same files the other header does. > > > Hrmm smells like another good FAQ item. =)
Re: advapi32: fix buffer overrun in tests/registry.c:wine_debugstr_wn(), try 3
On 11/7/07, Alexandre Julliard <[EMAIL PROTECTED]> 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...
Re: advapi32: fix buffer overrun in tests/registry.c:wine_debugstr_wn(), try 3
"Dan Kegel" <[EMAIL PROTECTED]> writes: > Fixes an off-by-one buffer overflow in wine_debugstr_wn() > in which the wchar after the end of the buffer was read. > > This is same as try 2, but is slightly clearer and more correct. > > Found via Valgrind warning: > Conditional jump or move depends on uninitialised value(s) > at 0x45F3219: wine_debugstr_wn (registry.c:151) > by 0x45F34F5: test_hkey_main_Value_W (registry.c:284) > by 0x45F7644: func_registry (registry.c:327) > by 0x460A127: run_test (test.h:387) > > Alexandre, if you don't like this 'un, please tell me why. That function is really supposed to print n chars, not n-1. The terminating null probably needs to be included in the length. -- Alexandre Julliard [EMAIL PROTECTED]
Re: ntdll: Architecture may be '*' in lookup_manifest_file so don't rely on the first '*' of the format indiacting where the version number is.
Robert Shearman <[EMAIL PROTECTED]> writes: > Instead use the underscores that separate the string fields. Of course the assembly name can contain underscores too... I think that the whole idea of checking the version number from the file name is flawed. -- Alexandre Julliard [EMAIL PROTECTED]
[keyboard] GetAsyncKeyState: request for fixing #5623
Hello, I have two favourite games (Diablo II & Ultima Online) and both of them works great under Wine. Unfortunately this is quite hard to play UO without additional tool called "EasyUO" which doesn't work under Wine. EasyUO generally works fine but it can not detect pressing any key-combination in focued UO window. Possibility of detecting is the main functionality for EUO. This problem is cuased by little bug in support for GetAsyncKeyState function. I am waiting about 8 months now for fixing this bug and I wonder if I can ask sb to look info this bug. Just to make fixing this little faster. Bug is quite well decribed in: http://bugs.winehq.org/show_bug.cgi?id=5623 but if you don't understand this, I can try to explain more detailed. So my request is someone try to fix this bug. Anyone have a free moment for this, please? -- Rafał Miłecki
Mistakes in my yesterday evening patches
I have send 4 patches yesterday. The 2 first of them are tagged resend. Please do not take those two first patches into account, they have already been merged in the git tree. My proxy played me a trick, i haven't see that before I sent them again. Only the 2 last ones (3/4 and 4/4) are to be merged by now. Sorry for my mistake, Laurent
