Hello,

Issues in a single application are severity 'normal'.
Read more about severity levels descriptions there:
https://wiki.winehq.org/Bugs#severity

Please attach a normal (=without WINEDEBUG) terminal output.
Instructions to get a log can be found there:
https://wiki.winehq.org/FAQ#get_log

There is a demo [1].
Can you reproduce the issue with that demo?

Also,
What is the latest version that you know used to work?

[1] https://www.gamepressure.com/download.asp?ID=14733

Regards.

> What is the latest version that you know used to work?
6.0.1 

Your other questions -- while reasonable -- won't get an answer.

Version 7.8 also doesn't work. 

Version 6.01 requires a working configuration of OpenGL, which appears to depend on some specific versions of system components, which a Linux distribution probably needs to manage. 

This dependency on particular system component versions (possibly versions of Xorg/drivers) and a failure to report on these flaws is also a problem in wine. A generic message saying that OpenGL failed to initialize is just a worthless way of informing a user. If glxgears works, then wine should also be able to initialize OpenGL.

(In reply to Anonymous from comment #2)
> > What is the latest version that you know used to work?
> 6.0.1 
> 
> Your other questions -- while reasonable -- won't get an answer.

If you won't provide answers, it's reasonable that the bug won't be fixed.

(In reply to Anonymous from comment #3)
> Version 7.8 also doesn't work. 
> 
> Version 6.01 requires a working configuration of OpenGL, which appears to
> depend on some specific versions of system components, which a Linux
> distribution probably needs to manage. 

Please run a regression test:
https://wiki.winehq.org/Regression_Testing

> This dependency on particular system component versions (possibly versions
> of Xorg/drivers) and a failure to report on these flaws is also a problem in
> wine. A generic message saying that OpenGL failed to initialize is just a
> worthless way of informing a user. If glxgears works, then wine should also
> be able to initialize OpenGL.

You're likely missing 32-bit opengl support. Running a 32-bit glxgears would likely show the same problem.

> Please run a regression test:
> https://wiki.winehq.org/Regression_Testing

https://wiki.winehq.org/Regression_Testing doesn´t provide cross-platform regression testing code. (For example, it doesn't work unmodified on Guix.)

So, if I want to run a regression test, I'd first have to port this collection of commands into infrastructure suitable for running regression tests. The right way to do this is to have a single program that works across all supported operating systems in order not to exclude some users. Picking favorites w.r.t. distributions discourages innovation. 

If you guys wants to export regression testing to users, you should even hide the fact it uses git. All that should be required is some primitive that exports checking for the color of a particular pixel after a particular amount of time and all a user would have to say is for example "a pixel at coordinates (100,100) changes color five times in a row in a repeating pattern" for an OK-test. Literally, every single issue I have had with wine w.r.t. games could have been tested by that. In fact, it should be possible to have the build system ask users with a particular interest in some applications with a particular system configuration to check such a basic property automatically during idle CPU time. 

Even Bugzilla could be used for users to automatically send such outputs. If you want people to contribute, you should make it easy to do so. The amount of feedback you would get in that way would dwarf the information obtained from the select few developers that might happen to still play some old game.    

> You're likely missing 32-bit opengl support. Running a 32-bit glxgears would likely show the same problem.

I do have 32-bit OpenGL support, but just not for the right set of system components against which 6.01 is compiled (the same binary works fine with an older system configuration). I am not currently using something like https://github.com/guibou/nixGL, which might be the quick fix solution in my case.  

Newer versions of wine don't complain about OpenGL(because it's compiled against compatible system components), but they just never show a splash screen. 

It would be of interest if *anyone* running this game can run it with any wine version >= 7. I do not believe such people exist. The probability that the demo doesn't work is also extremely high, if it uses the same initialization procedure for that splash screen.

Hello,

(In reply to Anonymous from comment #5)
> https://wiki.winehq.org/Regression_Testing doesn´t provide cross-platform
> regression testing code. (For example, it doesn't work unmodified on Guix.)
> 
> So, if I want to run a regression test, I'd first have to port this
> collection of commands into infrastructure suitable for running regression
> tests. The right way to do this is to have a single program that works
> across all supported operating systems in order not to exclude some users.
> Picking favorites w.r.t. distributions discourages innovation. 
> 
> If you guys wants to export regression testing to users, you should even
> hide the fact it uses git. All that should be required is some primitive
> that exports checking for the color of a particular pixel after a particular
> amount of time and all a user would have to say is for example "a pixel at
> coordinates (100,100) changes color five times in a row in a repeating
> pattern" for an OK-test. Literally, every single issue I have had with wine
> w.r.t. games could have been tested by that. In fact, it should be possible
> to have the build system ask users with a particular interest in some
> applications with a particular system configuration to check such a basic
> property automatically during idle CPU time. 
> 
> Even Bugzilla could be used for users to automatically send such outputs. If
> you want people to contribute, you should make it easy to do so. The amount
> of feedback you would get in that way would dwarf the information obtained
> from the select few developers that might happen to still play some old
> game.    

I don't understand what you are talking about.

Regression testing is not an application, it's a method for finding the cause of an issue when it results from a change in the code. It's not meant to be done by average users and it can't be made universal as the regressions are unpredictable.

It consists of iterating through the commits (individual changes in the code) between a known working version and a non-working version until the first commit that causes the issue is found. You have to compile Wine at each step and then test the application with the intermediate build.

The instructions given are an example. They use git because that's what the project uses for its own builds and it has an easy to use bisect function that facilitate the regression test by using a dichotomic algorithm.

You have to adapt the instructions to your own building environment and requirements.

> I do have 32-bit OpenGL support, but just not for the right set of system
> components against which 6.01 is compiled (the same binary works fine with
> an older system configuration). I am not currently using something like
> https://github.com/guibou/nixGL, which might be the quick fix solution in my
> case.  
> 
> Newer versions of wine don't complain about OpenGL(because it's compiled
> against compatible system components), but they just never show a splash
> screen. 

If you use a pre-build Wine package then it's normal. Wine 6.0.1 packages are now old and were built against old dependencies so when you use it, it tries to load old libraries that are just not there.

That's why the regression test requires building Wine on the current system, so Wine loads libraries that are current installed.

> It would be of interest if *anyone* running this game can run it with any
> wine version >= 7. I do not believe such people exist. The probability that
> the demo doesn't work is also extremely high, if it uses the same
> initialization procedure for that splash screen.

I just tested the demo on Wine 7.13 and it works out-of-the-box, so we need more info on what is happening on your system and the first thing you can do is provide the log that I asked earlier.

Regards.

Created attachment 72841 [details]
log

This is output from wine-7.13.

https://bugs.winehq.org/show_bug.cgi?id=51165#c2 claims that with a fresh .wine prefix folder another application works. I'd expect that if Bug 51165 is resolved that this issue (at least for wine-7.13) is also resolved. 

The wine prefix I am using is compatible with wine-6.01. As a user I expect that one doesn't have to reinstall applications with any upgrade.

(In reply to Anonymous from comment #8)
> https://bugs.winehq.org/show_bug.cgi?id=51165#c2 claims that with a fresh
> .wine prefix folder another application works. I'd expect that if Bug 51165
> is resolved that this issue (at least for wine-7.13) is also resolved. 
> 
> The wine prefix I am using is compatible with wine-6.01. As a user I expect
> that one doesn't have to reinstall applications with any upgrade.

Hello,

You may still reinstall in a fresh wineprefix (rename the old one first) to test if it really fixes the issue, and then make a diff of both wineprefixes, in case there are obvious differences that you can report to us.

Regards.

WINEPREFIX=~/.wineprefixbug winecfg

The diff is way too big. Unless there is a shell script of some kind, which can be used to automatically minimize the WINEPREFIX configuration directory, there is no way in which I can track this down (without writing such a tool myself, which would involve me probably knowing about the file formats of every single file managed by wine and knowing which files are relevant to begin with (in other words, I'd first have to become a wine expert (something I don't want to be))). 

Do you have such minimization tools? If not, why do you people even pretend to offer any kind of compatibility between versions? In a project with many outside contributors potentially messing up something critical and many, many users, surely _someone_ must have thought this can't ever scale, right?

The bug apparently has existed for over a year. Not good. 

I think the lesson here is that a single wine configuration shouldn't contain the installation of multiple independent applications, because it becomes a debugging nightmare (because the tools don't exist). 

When I run with some empty WINEPREFIX directory, winecfg shows a window with some tabs as it is supposed to do (and asks about the installation of mono). So, it's an absolute certainty that some incompatibility related _only_ to the library resolution of winecfg between 6.01 and 7.13 was introduced.

I don't understand how someone writing a program can make such basic mistakes in the first place and if such a thing happens (because apparently the programmer wasn't as smart as they thought they were) once doesn't immediately provide such bug minimization tools (such tools have been written about for _decades_ and have been part of the "art" for much longer than that).

Hello,

Try 'diff -r -q' between the windows/system32 of the two wineprefixes.
That's where the Wine DLLs are stored/symlinked.

Regards.

(In reply to Anonymous from comment #10)
> I think the lesson here is that a single wine configuration shouldn't
> contain the installation of multiple independent applications, because it
> becomes a debugging nightmare (because the tools don't exist). 
> 
> When I run with some empty WINEPREFIX directory, winecfg shows a window with
> some tabs as it is supposed to do (and asks about the installation of mono).
> So, it's an absolute certainty that some incompatibility related _only_ to
> the library resolution of winecfg between 6.01 and 7.13 was introduced.
> 
> I don't understand how someone writing a program can make such basic
> mistakes in the first place and if such a thing happens (because apparently
> the programmer wasn't as smart as they thought they were) once doesn't
> immediately provide such bug minimization tools (such tools have been
> written about for _decades_ and have been part of the "art" for much longer
> than that).

Because Wine is hard enough, broadly. Also, it's not a class of bug that comes up that often.

Anyway, in cases like this IME the problem tends to be not reuse of prefixes for multiple applications *per se*, but rather:

(a) programs installing native DLLs in a prefix,
(b) people doing the same thing manually, and forgetting about it or not mentioning it in bug reports,
(c) similarly, configuring the wine version, registry keys, native overrides, etc.,
(d) applications which didn't install correctly in the first place, or don't work on the first run, or only work on the first run...

with (c) being the most common. It's often easiest to check that by opening winecfg and looking for differences in the windows version or native overrides.

Created attachment 72894 [details]
file directory diff as requested

(In reply to Olivier F. R. Dierick from comment #11)
> Hello,
> 
> Try 'diff -r -q' between the windows/system32 of the two wineprefixes.
> That's where the Wine DLLs are stored/symlinked.
> 
> Regards.

Did you see my diff?

I tried the Steam version of CNC3 and the game ran fine in Wine 7.22. The only problem was that my original screen resolution was not restored when I exited. Are you running the game with Steam too?

Can you try again in Wine 9.6 or later?

I tested CNC3 on wine-10.0rc1 and it seems to launch or more importantly its showing the splash screen using a fresh prefix.

The other bug 56663 still exists.

Good enough given lack of information from OP.

Reported fixed. Reopen if the basic requirements for a bug report are provided.

Closing bugs fixed in 10.0-rc2.