Bryce 5.5 once ran, before v0.9.56 [Free Full Version]

[dirkmitt]

In the application database, there is a revue according to which Bryce 5.5 does not run under WINE. But not having looked at the AppDB first, I went ahead and installed Bryce 5.5 some months ago, which ran fine under WINE 0.9.44 or some such version...

Here is an old screenshot of the app, which has been used to render a tree on the Linux Box. (Kanotix 2006-RC4)



But since I've upgraded to a newer version of WINE, the startup behaviour of Bryce has become, to paint the screen, but then to let most of the GUI turn black. Bryce is one application, which will use windows that have no visible borders on the desktop. And the GUI seems to appear for a split second, only to disappear after the document / render window has been painted. Here's the new screenshot:



I suspect that what has happened, is that since the application database was last added to by a tester, newer versions of WINE will run Bryce 5.5 . But in an even more recent version of WINE, I suspect that ambitious reprogramming of GUI-related code has resulted in some kind of layer miscount. Thus, I feel that this problem is GUI-related and not .NET related, which is what the tester wrote instead. Also, the rendered scene is still on my Linux Box / home WINE directory. But now that the GUI can't be clicked, Bryce 5.5 is temporarily unable to produce any more scenes or render them under WINE 0.9.58 .

Also, I find that the Bugzilla people just tend to ignore this sort of bug report. Will this ever get noticed or fixed?

Dirk

[Mark Knecht]

On Wed, Mar 26, 2008 at 6:33 PM, dirkmitt <[email protected]> wrote:

In the application database, there is a revue according to which Bryce 5.5 does not run under WINE. But not having looked at the AppDB first, I went ahead and installed Bryce 5.5 some months ago, which ran fine under WINE 0.9.44 or some such version...

Here is an old screenshot of the app, which has been used to render a tree on the Linux Box. (Kanotix 2006-RC4)

[Image: http://www.dirkmittler.com/Bryce_WINE.jpg ]

But since I've upgraded to a newer version of WINE, the startup behaviour of Bryce has become, to paint the screen, but then to let most of the GUI turn black. Bryce is one application, which will use windows that have no visible borders on the desktop. And the GUI seems to appear for a split second, only to disappear after the document / render window has been painted. Here's the new screenshot:

[Image: http://www.dirkmittler.com/Bryce5_5.jpg ]

I suspect that what has happened, is that since the application database was last added to by a tester, newer versions of WINE will run Bryce 5.5 . But in an even more recent version of WINE, I suspect that ambitious reprogramming of GUI-related code has resulted in some kind of layer miscount. Thus, I feel that this problem is GUI-related and not .NET related, which is what the tester wrote instead. Also, the rendered scene is still on my Linux Box / home WINE directory. But now that the GUI can't be clicked, Bryce 5.5 is temporarily unable to produce any more scenes or render them under WINE 0.9.58 .

Also, I find that the Bugzilla people just tend to ignore this sort of bug report. Will this ever get noticed or fixed?

Dirk

Dirk,
If it's a regression then it has a better chance of getting looked
at. Can you determine which version of Wine broke Bryce? If so then I
think you have a pretty good chance of getting someone to look at it.

- Mark

[dirkmitt]

I'm embarrassed to admit, that I don't recall which WINE version that was, which broke Bryce 5.5 .

I'm really sorry for that. {:-(}

Dirk

[Dan Kegel]

On Wed, Mar 26, 2008 at 8:46 PM, dirkmitt <[email protected]> wrote:

I'm embarrassed to admit, that I don't recall which WINE
version that was, which broke Bryce 5.5 .

I'm really sorry for that. {:-(}

No problem - you can find out now! Just grab an old version
from http://www.winehq.org/site/download and try it.

Or guess from the date of the screenshot. You can see
the release dates here:
http://www.winehq.org/pipermail/wine-announce/

[Zachary Goldberg]

On Wed, Mar 26, 2008 at 11:51 PM, Dan Kegel <[email protected]> wrote:

On Wed, Mar 26, 2008 at 8:46 PM, dirkmitt <[email protected]> wrote:

I'm embarrassed to admit, that I don't recall which WINE
version that was, which broke Bryce 5.5 .

I'm really sorry for that. {:-(}

No problem - you can find out now! Just grab an old version
from http://www.winehq.org/site/download and try it.

Or guess from the date of the screenshot. You can see
the release dates here:
http://www.winehq.org/pipermail/wine-announce/

In addition, if you can find an old version in which it works you can
do something called "regression testing". If you have (quiet a few)
minutes you can follow the guide here:

http://wiki.winehq.org/RegressionTesting

which will help Wine developers determine exactly whats broken and get
a quick fix.


--
Zachary Goldberg
Computer Science & Engineering
Electrical Captain of Penn Electric Race Team
School of Engineering at the University of Pennsylvania

[Mark Knecht]

On Wed, Mar 26, 2008 at 8:46 PM, dirkmitt <[email protected]> wrote:

I'm embarrassed to admit, that I don't recall which WINE version that was, which broke Bryce 5.5 .

I'm really sorry for that. {:-(}

Dirk

It's not that big a deal to do a binary search if you have the time.
Drop back 16 revisions, build the code. If it passes then jump forward
8 versions and try again. If that works then jump forward 4, or back 4
if it doesn't. Pretty soon you've found the version where it broke.
Not too big a deal if you don't mind building the code. I've found a
couple of regressions that way.

hope this helps,
Mark

[dirkmitt]

I have to admit, (1) that I don't do a dist-upgrade very often, which would keep my WINE version actual as well. But I did a d-u on January 1, 2008, that nearly broke my whole Linux Box. Rest assured, I was able to finish a broken-off d-u. And after that d-u, Bryce 5.5 ran under WINE. The most recent version was 0.9.52 at that time.

But later, my very next upgrade of specifically WINE was to version 0.9.57 . This version no longer allowed Bryce 5.5 to run properly.

Thus it could have been any one of 5 versions.

But, (2) I'm not really willing to reinstall WINE a number of times. I just hope that knowing within 5 versions might help the actual developers.

Dirk

[Zachary Goldberg]

On Thu, Mar 27, 2008 at 12:37 AM, dirkmitt <[email protected]> wrote:

I have to admit, (1) that I don't do a dist-upgrade very often, which would keep my WINE version actual as well. But I did a d-u on January 1, 2008, that nearly broke my whole Linux Box. Rest assured, I was able to finish a broken-off d-u. And after that d-u, Bryce 5.5 ran under WINE. The most recent version was 0.9.52 at that time.

But later, my very next upgrade of specifically WINE was to version 0.9.57 . This version no longer allowed Bryce 5.5 to run properly.

Thus it could have been any one of 5 versions.

But, (2) I'm not really willing to reinstall WINE a number of times. I just hope that knowing within 5 versions might help the actual developers.

Dirk

Is there a demo of the app one could download someplace to try and
replicate the behavior?

--Zach

[Mark Knecht]

On Wed, Mar 26, 2008 at 9:37 PM, dirkmitt <[email protected]> wrote:
<SNIP>

But, (2) I'm not really willing to reinstall WINE a number of times. I just hope that knowing within 5 versions might help the actual developers.

Dirk

No, that probably won't get you anywhere because it's here-say. for a
developer to fix anything they will need some data. the problem is
multi-fold:

1) A user like you or me sees a program break. (Independent of whether
it ever worked...)
2) We have to communicate enough information for someone to do some work.
3) The best answer in your case is two things:
a) A statement that it worked with this revision and failed with this
one, 1 revision apart
b) Some backtrace data that shows the failure happening. this
identifies the offending code

Since having the application is a requirement to get this whole
process started there are two options:
a) The user does the regression testing
b) The user find a demo and then convinces someone nice to do this
work for the user.

Option a) gets the best results and gets them the fastest. It's up to you.

- Mark

[austin987]

On Wed, Mar 26, 2008 at 9:37 PM, dirkmitt <[email protected]> wrote:

But, (2) I'm not really willing to reinstall WINE a number of times. I just hope that knowing within 5 versions might help the actual developers.

Knowing within 5 versions leaves roughly 900-1200 patches that could
be the problem. Knowing the exact patch makes it MUCH easier to find
the problem (along with a demo/backtrace/steps to reproduce/etc.)

[Mark Knecht]

On Thu, Mar 27, 2008 at 9:26 AM, Austin English <[email protected]> wrote:

On Wed, Mar 26, 2008 at 9:37 PM, dirkmitt <[email protected]> wrote:

But, (2) I'm not really willing to reinstall WINE a number of times. I just hope that knowing within 5 versions might help the actual developers.

Knowing within 5 versions leaves roughly 900-1200 patches that could
be the problem. Knowing the exact patch makes it MUCH easier to find
the problem (along with a demo/backtrace/steps to reproduce/etc.)

And while a newbie might not think it's that interesting to do a
regression test like this I know the first time I went through it I
learned a lot and ended up with a better appreciation of what goes
into making a program like Wine.

Anyway, it's up to him. doing this regression test down to the patch
will give him a better chance of getting a fix. He may not care enough
about using Bryce to warrant the work. That's up to him

Thanks!

- Mark

[dirkmitt]

Because you guys have made a convincing argument, I did the regression test.

After installing version 0.9.55 , I found that Bryce 5.5 still worked.

Next, I installed v0.9.56 , and found that Bryce 5.5 no longer worked (ie that the GUI error has cropped up.)

Now, as far as traces go, I always recalled, that Bryce 5.5 under WINE did not seem to produce any meaningful output. There were some messages, but they did not lead to a a fatal problem. But, to be sure I copied and pasted the output of Bryce 5.5 under WINE 0.9.56 , after which I downgraded back to WINE 0.9.55 so that I have a working version of Bryce, and copied and pasted the output again. Here is the output, from a text file as intermediate storage:

WINE 0.9.56 :

fixme:spoolsv:serv_main (0 (nil))
fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a
fixme:imm:ImmGetDefaultIMEWnd (0x10024 - (nil) 0x11a290 ): semi-stub


WINE 0.9.55 :

fixme:spoolsv:serv_main (0 (nil))
err:advapi:service_get_status service protocol error - failed to read pipe r = 0 count = 0!
fixme:imm:ImmGetDefaultIMEWnd (0x10024 - (nil) 0x11a290 ): semi-stub


I think that I did 'spoolsv:serv_main()...' to myself, by trying to install Poser a while ago. But in WINE 0.9.55 this finally does not prevent Bryce from running. It also appears when I give 'wineboot' .

Now I intend to stick with WINE 0.9.55 until I see a specific bug-fix for Bryce 5.5 GUI.

Dirk

[Mark Knecht]

On Thu, Mar 27, 2008 at 11:16 AM, dirkmitt <[email protected]> wrote:

Because you guys have made a convincing argument, I did the regression test.

After installing version 0.9.55 , I found that Bryce 5.5 still worked.

Next, I installed v0.9.56 , and found that Bryce 5.5 no longer worked (ie that the GUI error has cropped up.)

Hey, that was fast.

Now, as far as traces go, I always recalled, that Bryce 5.5 under WINE did not seem to produce any meaningful output. There were some messages, but they did not lead to a a fatal problem. But, to be sure I copied and pasted the output of Bryce 5.5 under WINE 0.9.56 , after which I downgraded back to WINE 0.9.55 so that I have a working version of Bryce, and copied and pasted the output again. Here is the output, from a text file as intermediate storage:

WINE 0.9.56 :

fixme:spoolsv:serv_main (0 (nil))
fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a
fixme:imm:ImmGetDefaultIMEWnd (0x10024 - (nil) 0x11a290 ): semi-stub

Meaningful output will only come if you build a special version of
Wine-0.9.56 which has the names still in it. then the hex numbers
start turning into function names, etc., and the developer can see
what part of the code is failing.

I'm trying to keep one testing version around on my machine at a given
time. I don't have to 'install' this version. I can just build it and
then run wine from that path instead of your main path. In your case
you *might* want to two versions to see the differences.

It's very easy to do this. Just download a tarball of Wine-0.9.56 from here:

http://sourceforge.net/project/showfile ... e_id=77449

then build it using (I think...) these two instructions:

./configure
make depend && make

Do NOT do an install or you will overwrite your main version.

Once done run wine from that location and look at the offending
output. you may have to run it with some extra command line stuff but
we'll talk about that if you need to and want to.

Hope this helps,
Mark

[David Gerard]

On 27/03/2008, Mark Knecht <[email protected]> wrote:

It's very easy to do this. Just download a tarball of Wine-0.9.56 from here:
http://sourceforge.net/project/showfile ... e_id=77449
then build it using (I think...) these two instructions:
./configure
make depend && make
Do NOT do an install or you will overwrite your main version.
Once done run wine from that location and look at the offending
output. you may have to run it with some extra command line stuff but
we'll talk about that if you need to and want to.

Note that this is indeed very easy indeed (I got the code by
installing using git, but it was just as easy) - but compilation will
take a little while!


- d.

[Mark Knecht]

On Thu, Mar 27, 2008 at 11:41 AM, David Gerard <[email protected]> wrote:

On 27/03/2008, Mark Knecht <[email protected]> wrote:

It's very easy to do this. Just download a tarball of Wine-0.9.56 from here:
http://sourceforge.net/project/showfile ... e_id=77449
then build it using (I think...) these two instructions:
./configure
make depend && make
Do NOT do an install or you will overwrite your main version.
Once done run wine from that location and look at the offending
output. you may have to run it with some extra command line stuff but
we'll talk about that if you need to and want to.

Note that this is indeed very easy indeed (I got the code by
installing using git, but it was just as easy) - but compilation will
take a little while!

And using git or CVS is great because eventually you can get all the
way down to the exact patch that broke things which will really help
the developers.

- Mark

[dirkmitt]

Instead of building a debug version of WINE for now, which would probably make me a part of your team, I just wanted to warn readers about a fact in Bryce under WINE. Maybe one day soon I will start debugging WINE with you, but right now this statement seems more important.

One should not think, that just because Bryce 5.5 works partially under WINE 0.9.55 , all of it works.

In the beginning, I found that starting up the part of Bryce 5.5 which is called the "DAZ Studio," would cause the whole virtual desktop to freeze. But more recently, I found that by overriding the library msvcirt.dll with its native, will stop that from happening, because this part of Bryce opens an interface to Poser, and Poser needs for msvcirt.dll to be overridden. And now I find that the DAZ Studio part will also load successfully.

Yet even now, the central panel of DAZ studio fails to redraw itself at times, leaving pieces of prior dialog boxes visible. This may be due to my LinuxBox not having its hardware-3D installed, which Poser tends to use.

Also, I can render stationary scenes with Bryce, but not animations, in spite of having installed a Codec pack. In fact, trying to create an animation with keyframes eventually causes the buggy GUI to display again, with parts of the virtual desktop blacked out. So my earlier theory may also be wrong, that this anomaly was just a GUI problem. Yet, it could actually be a GUI problem which prevents me from dragging the time-slider across the time-line. This is the main way to create those keyframes under Windows. Without keyframes, there can be no movement under Bryce. And quitting the motion lab, which has the same problem, leaves the main GUI partially black.

And it was in the hopes that this behaviour would improve, that I was upgrading WINE before. I'm still hopeful that the behaviour of these programs will improve.

Dirk

[austin987]

On Thu, Mar 27, 2008 at 2:22 PM, dirkmitt <[email protected]> wrote:

Instead of building a debug version of WINE for now, which would probably make me a part of your team, I just wanted to warn readers about a fact in Bryce under WINE. Maybe one day soon I will start debugging WINE with you, but right now this statement seems more important.

One should not think, that just because Bryce 5.5 works partially under WINE 0.9.55 , all of it works.

In the beginning, I found that starting up the part of Bryce 5.5 which is called the "DAZ Studio," would cause the whole virtual desktop to freeze. But more recently, I found that by overriding the library msvcirt.dll with its native, will stop that from happening, because this part of Bryce opens an interface to Poser, and Poser needs for msvcirt.dll to be overridden. And now I find that the DAZ Studio part will also load successfully.

Yet even now, the central panel of DAZ studio fails to redraw itself at times, leaving pieces of prior dialog boxes visible. This may be due to my LinuxBox not having its hardware-3D installed, which Poser tends to use.

Also, I can render stationary scenes with Bryce, but not animations, in spite of having installed a Codec pack. In fact, trying to create an animation with keyframes eventually causes the buggy GUI to display again, with parts of the virtual desktop blacked out. So my earlier theory may also be wrong, that this anomaly was just a GUI problem.

And it was in the hopes that this behaviour would improve, that I was upgrading WINE before. I'm still hopeful that the behaviour of these programs will improve.

Dirk

Knowing the version that broke doesn't help much. Please run a proper
regression test, which will identify the exact patch:

http://wiki.winehq.org/RegressionTesting

[dirkmitt]

I'm afraid that my Kanotix box is just not strong enough at this point. I installed git and ccache.

But after that, when I just ran the git clone ... command, the data was downloaded, after which git began resolving ~300 000 commits right away, which caused my KGet systray app to crash, after which my whole computer froze. Alt+SysReq+REISUB didn't even work.

And after that, thinking that git might be ready just to fix commits belonging to specific wine versions, I next tried

apt-get build-dep wine wine-dev

But when it told me that it needed to install 43 packages, forget it. Kanotix is Etch but isn't Etch 4.0! And one of the packages it wanted to install, was a whole new version of cpp.

Sorry, you guys are going to have to do this yourselves.

Dirk

[James Hawkins]

On Thu, Mar 27, 2008 at 3:51 PM, dirkmitt <[email protected]> wrote:

I'm afraid that my Kanotix box is just not strong enough at this point. I installed git and ccache.

But after that, when I just ran the git clone ... command, the data was downloaded, after which git began resolving ~300 000 commits right away, which caused my KGet systray app to crash, after which my whole computer froze. Alt+SysReq+REISUB didn't even work.

And after that, thinking that git might be ready just to fix commits belonging to specific wine versions, I next tried

apt-get build-dep wine wine-dev

But when it told me that it needed to install 43 packages, forget it. Kanotix is Etch but isn't Etch 4.0! And one of the packages it wanted to install, was a whole new version of cpp.

Sorry, you guys are going to have to do this yourselves.

We cant...we don't have the app.

--
James Hawkins

[dirkmitt]

Why didn't you just say so?

You can get Bryce 5.5 for free by now, right here:

http://www.download.com/3120-20_4.html? ... e&tag=srch

Dirk

[James Hawkins]

On Thu, Mar 27, 2008 at 4:20 PM, dirkmitt <[email protected]> wrote:

Why didn't you just say so?

You can get Bryce 5.5 for free by now, right here:

http://www.download.com/3120-20_4.html? ... e&tag=srch

Ok that's a step in the right direction. There's one thing left for
you to do to help us out. You need to test the demo to make sure it
fails in the exact same way. After that, one of us will get around to
running the regression test. Please open a bug report in our bugzilla
so we can track this.

--
James Hawkins

[Mark Knecht]

On Thu, Mar 27, 2008 at 2:20 PM, dirkmitt <[email protected]> wrote:

Why didn't you just say so?

You can get Bryce 5.5 for free by now, right here:

http://www.download.com/3120-20_4.html? ... e&tag=srch

Dirk

Hi Dirk,
As James says this is helpful. I might try it out for kicks.
However since you are coming in from the forums let me respond with
one comment, not really directed toward you specifically but rather to
the general audience. I've used wine for a long time. Some apps work
*fairly* well, but no app in my experience works perfectly. Every app
I've ever tried throws messages and does a few things wrong. It's just
a statement of fact for me using Wine.

Why do I write this? Because my experience having used wine for a
long time is that if an individual user wants an individual
application fixed then it sort of falls to that user to sheapard the
reports along over time and provide the inputs necessary for the
developers to do their work. As there are probably tens of thousands
of apps that do what Bryce is doing, in terms of working partially,
working and then being broken partially or completely, whatever, then
my experience is that the developers have a HUGE range of things they
can work on. They can choose what they want, what they think is most
important, what they have time for. It's up to them.

If I'm driven enough to really want to use a specific app in Wine
and it's not working well enough for my needs then it's up to me to do
whatever I can to provide the info. If I don't provide the info then I
expect nothing much will happen with the request. Believe me, I've got
some bug reports in there from 5 years ago I'm sure that probably have
never been looked at and possibly never will.

So, not specifically to you but rather to the forum users at large,
if you really want something fixed then providing more information and
not less is the path toward more timely results. It's really up to
you.

Just my 2 cents,
Mark

[dirkmitt]

I understand that 'git clone ...' is supposed to download far more data than my attempt did. But can somebody explain to me - Why did my KGet crash?

I have version "4:3.5.5-5 (stable)" .

Dirk

[Dan Kegel]

On Thu, Mar 27, 2008 at 5:02 PM, dirkmitt <[email protected]> wrote:

I understand that 'git clone ...' is supposed to download far more data
than my attempt did. But can somebody explain to me - Why did my KGet crash?

Perhaps your machine or distro is hosed...

[dirkmitt]

BTW You know, my hardware might be flaky.

This machine is an ancient Pentium-3 at 600MHz, custom-built non-professionally. Now by itself, this should not stop it from recompiling tons of code. And it wouldn't explain the Bryce bug recurring under the exact conditions either. But on the other hand, when I rebuilt certain other large source trees in past months and years, it has happened to me that the machine just froze like that. Maybe the old hardware does have a glitch. Outside of hardware problems, even a huge malfunctioning make job shouldn't halt the system.

Re.: Bryce 5.5 :

I was thinking of exactly how I should try to install the downloadable version of Bryce 5.5, to determine for sure whether under WINE 0.9.56 it fails in exactly the same way as my CD-ROM version. One way would be, if it was only a demo, to install it next to the full version, creating a WINE menu entry called '...Demo' . This would spare me the need to rename ~/.wine to ~/.wine.bak etc..

But what I did discover, is that the download I suggested in this thread, the file "Bryce5_5_Free_Setup.exe" , is a 122.2MB file, and is thus the full version already. And so the issue of whether it might not fail under WINE 0.9.56 becomes less likely.

But I do feel, that instead of now uninstalling WINE one more time and reinstalling it; I'll just keep this Windows installer as a spare copy. That way, I won't need to resort to the CD-ROM in the future myself.

And wouldn't this once-valuable app itself be a good incentive to WineHQ, to let them get more apps running that use such borderless panels? {:-)} Since having WINE would now mean, also having Bryce 5.5 if users were interested?

Dirk