[Bug 30259] New: StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

Bug #: 30259
           Summary: StarCraft II doesn't start
           Product: Wine
           Version: 1.5.0
          Platform: x86-64
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

This is with Arch Linux and ATI radeon driver. Installation seemed to go fine,
and also the update, but it doesn't launch:

err:winediag:wined3d_dll_init The GLSL shader backend has been disabled. You
get to keep all the pieces if it breaks.
fixme:process:GetLogicalProcessorInformation ((nil),0x32dca0): stub
2012/03/25 02:52:06  ../Shared/Shared/SRegCompat/SRegCompat_Win32.cpp(498) :
Assertion failed: *keyname  ""
err:ntdll:RtlpWaitForCriticalSection section 0x7dff61e0
"../../../wine/dlls/winex11.drv/x11drv_main.c: X11DRV_CritSection" wait timed
out in thread 0009, blocked by 0025, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7edc88a0
"../../../wine/dlls/user32/user_main.c: user_section" wait timed out in thread
0025, blocked by 0009, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7bcbe900
"../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread
0026, blocked by 0025, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7bcbe900
"../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread
0009, blocked by 0025, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7edc88a0
"../../../wine/dlls/user32/user_main.c: user_section" wait timed out in thread
0025, blocked by 0009, retrying (60 sec)
err:ntdll:RtlpWaitForCriticalSection section 0x7bcbe900
"../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread
0026, blocked by 0025, retrying (60 sec)
err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr
0x7bc36f1c
err:ntdll:RtlpWaitForCriticalSection section 0x7bcbe900
"../../../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread
0009, blocked by 0025, retrying (60 sec)
err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr
0x7bc36f1c

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Vitaliy Margolen  2012-03-24 22:33:45 CDT ---
> err:winediag:wined3d_dll_init The GLSL shader backend has been disabled. You

get to keep all the pieces if it breaks.

Exactly what it says.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

Vitaliy Margolen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
         Resolution|INVALID                     |DUPLICATE
           Severity|major                       |normal

--- Comment #2 from Vitaliy Margolen  2012-03-24 22:38:35 CDT ---
Actually duplicate.

*** This bug has been marked as a duplicate of bug 29982 ***

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #3 from Felipe Contreras  2012-03-24 23:11:10 CDT ---
(In reply to comment #1)
> > err:winediag:wined3d_dll_init The GLSL shader backend has been disabled. You
>
> get to keep all the pieces if it breaks.
>
> Exactly what it says.

Go here:
http://appdb.winehq.org/objectManager.php?sClass=version&iId=20882

Do you see this?
UseGLSL    disabled

Yeah, pretty much every guide for Stracraft II says the same.

Not that it makes any difference. As you can see in bug #29982; the output is
*exactly* the same.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #4 from Austin English  2012-03-26 02:33:03 CDT ---
(In reply to comment #3)
> (In reply to comment #1)
> > > err:winediag:wined3d_dll_init The GLSL shader backend has been disabled. You
> >
> > get to keep all the pieces if it breaks.
> >
> > Exactly what it says.
>
> Go here:
> http://appdb.winehq.org/objectManager.php?sClass=version&iId=20882
>
> Do you see this?
> UseGLSL    disabled
>
> Yeah, pretty much every guide for Stracraft II says the same.

The AppDB is controlled by users, we can't police every entry there. People
have a habit of fiddling with every option, even when it makes things worse. As
the message says, it's there to try, but if it's broken, please don't report
bugs for it.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #5 from Felipe Contreras  2012-03-26 17:35:38 CDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > > err:winediag:wined3d_dll_init The GLSL shader backend has been disabled. You
> > >
> > > get to keep all the pieces if it breaks.
> > >
> > > Exactly what it says.
> >
> > Go here:
> > http://appdb.winehq.org/objectManager.php?sClass=version&iId=20882
> >
> > Do you see this?
> > UseGLSL    disabled
> >
> > Yeah, pretty much every guide for Stracraft II says the same.
>
> The AppDB is controlled by users, we can't police every entry there. People
> have a habit of fiddling with every option, even when it makes things worse. As
> the message says, it's there to try, but if it's broken, please don't report
> bugs for it.

You are a user, you can go to it right now and remove that, right? The fact of
the matter is that disabling UseGLSL sometimes makes sense, and in this case,
_this_ bug has _nothing_ to do with it.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #6 from Austin English  2012-03-26 20:05:02 CDT ---
(In reply to comment #5)
> You are a user, you can go to it right now and remove that, right? The fact of
> the matter is that disabling UseGLSL sometimes makes sense, and in this case,
> _this_ bug has _nothing_ to do with it.

This is the job of AppDB maintainers. I help administer it, but with the volume
of stuff going on there, it's not easy.

I understand that disabling UseGLSL may make sense, but as we said, it makes
bugs invalid. If it's not related, as you said, then retest with GLSL _enabled_
before filing the bug, to be sure.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #7 from Henri Verbeet  2012-03-27 02:26:13 CDT ---
I should mention that recommending to disable GLSL in generic appdb
instructions is just about always wrong. There are two fairly specific cases
where disabling GLSL may make sense. The first case is on drivers that have the
nvidia shader program extensions, and where those extensions give better
performance than GLSL. This is pretty much only the case for the proprietary
nvidia drivers on Linux, for some specific applications. In some cases the
reason it's faster is actually because the GLSL code received bug fixes that
the ARB shader program code never got. The other case where disabling GLSL may
make sense is on OS X where the GLSL compiler is generally just so terrible
that not using it is the only way to make things work at all.

In the case of an AMD card with the r600g driver, all that disabling GLSL is
going to do is to limit you to shader model 1 shaders.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #8 from Felipe Contreras  2012-03-27 08:01:01 CDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > You are a user, you can go to it right now and remove that, right? The fact of
> > the matter is that disabling UseGLSL sometimes makes sense, and in this case,
> > _this_ bug has _nothing_ to do with it.
>
> This is the job of AppDB maintainers. I help administer it, but with the volume
> of stuff going on there, it's not easy.

You are now aware of it, right? I still see UseGLSL disabled.
> I understand that disabling UseGLSL may make sense, but as we said, it makes
> bugs invalid. If it's not related, as you said, then retest with GLSL _enabled_
> before filing the bug, to be sure.

It does not invalidate the bug, as I said, it makes *absolutely no difference*
in this case.

Seems like you are using it just as an excuse to close bugs.

If you really cared about *solving* them, you would first ask to enable it and
re-test, not immediately closing it as invalid.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #9 from Vitaliy Margolen  2012-03-27 08:59:25 CDT ---
(In reply to comment #8)
This bug is closed as duplicate not invalid. What are you complaining about?
That you did something Wine _explicitly told you_ not to do? And now you
getting a ear full of developers telling you why you shouldn't do it?

Yes, your program has an issue running under Wine. Yes there is a bug about it
(bug 29982). Either wait for it to be resolved or fix it yourself for everyone
else to enjoy. Wine is an open source project. No one owes anything to anyone. 
All people here are volunteers and contribute their own free time, experience
and knowledge to the project.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #10 from Felipe Contreras  2012-03-27 10:14:05 CDT ---
(In reply to comment #9)
> (In reply to comment #8)
> This bug is closed as duplicate not invalid.

_Now_, but that's not the first thing you did. The first thing you did was to
mark it as INVALID without really knowing if was invalid or not; IOW without
knowing if UseGLSL was the issue or not.

[e-mail]
2012-03-24 22:33:45 CDT    
Status    UNCONFIRMED    RESOLVED
Resolution    ---    INVALID
> What are you complaining about?

^- You are marking bugs as INVALID without knowing if they are really invalid.
> That you did something Wine _explicitly told you_ not to do?

Where?

This is what Wine says: 'The GLSL shader backend has been disabled. You get to
keep all the pieces if it breaks.'

This didn't cause any issue. It's *totally* and *completely* irrelevant. I know
because I tried disabling it, as I said in further comments. I should have lied
and removed that line from the output.
> And now you
> getting a ear full of developers telling you why you shouldn't do it?
>
> Yes, your program has an issue running under Wine. Yes there is a bug about it
> (bug 29982). Either wait for it to be resolved or fix it yourself for everyone
> else to enjoy. Wine is an open source project. No one owes anything to anyone. 
> All people here are volunteers and contribute their own free time, experience
> and knowledge to the project.

Yes, that doesn't make your actions any more appropriate.

Closing bugs for the wrong reasons is still wrong.

If it makes you happier to close as INVALID all bugs that have UseGLSL
disabled, go ahead, that doesn't help anybody, specially not the Wine project.
What you should be doing is *first* make sure UseGLSL is the issue, and *then*
mark as INVALID.

But I'm sure you will never accept that there's room for improvement for your
actions. No, you are perfect.

[Bug 30259] StarCraft II doesn't start

http://bugs.winehq.org/show_bug.cgi?id=30259

--- Comment #11 from Austin English  2012-03-27 12:22:16 CDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > This bug is closed as duplicate not invalid.
>
> _Now_, but that's not the first thing you did. The first thing you did was to
> mark it as INVALID without really knowing if was invalid or not; IOW without
> knowing if UseGLSL was the issue or not.
>
> [e-mail]
> 2012-03-24 22:33:45 CDT    
> Status    UNCONFIRMED    RESOLVED
> Resolution    ---    INVALID
> > What are you complaining about?
>
> ^- You are marking bugs as INVALID without knowing if they are really invalid.
> > That you did something Wine _explicitly told you_ not to do?
>
> Where?
>
> This is what Wine says: 'The GLSL shader backend has been disabled. You get to
> keep all the pieces if it breaks.'
>
> This didn't cause any issue. It's *totally* and *completely* irrelevant. I know
> because I tried disabling it, as I said in further comments. I should have lied
> and removed that line from the output.

The point, however, is we don't know that immediately. The configuration is
unsupported, it's a waste of time to attempt to find a valid bug in an
unsupported configuration. The burden is on you to attempt the application, in
a _supported_ way, not expect _volunteers_ to spend valuable time trying to
find if there is a valid bug. That time is better spent on well defined bugs.
> > And now you
> > getting a ear full of developers telling you why you shouldn't do it?
> >
> > Yes, your program has an issue running under Wine. Yes there is a bug about it
> > (bug 29982). Either wait for it to be resolved or fix it yourself for everyone
> > else to enjoy. Wine is an open source project. No one owes anything to anyone. 
> > All people here are volunteers and contribute their own free time, experience
> > and knowledge to the project.
>
> Yes, that doesn't make your actions any more appropriate.
>
> Closing bugs for the wrong reasons is still wrong.
>
> If it makes you happier to close as INVALID all bugs that have UseGLSL
> disabled, go ahead, that doesn't help anybody, specially not the Wine project.
> What you should be doing is *first* make sure UseGLSL is the issue, and *then*
> mark as INVALID.

No, for reasons pointed out beforehand. For similar reasons, if someone reports
a bug and wine complains that their 3d setup is invalid (no direct rendering
support), we ask them to fix their setup first, to rule out that problem.
> But I'm sure you will never accept that there's room for improvement for your
> actions. No, you are perfect.

Everyone has room for improvement, but asking volunteer developers to change
their practices whenever you clearly didn't follow instructions is a bit
selfish.

Regardless, I'm done with this discussion, I have better uses for my time.

Regards,
Austin