Proteus 8 does not longer works with Wine 1.7
Proteus 8 does not longer works with Wine 1.7
Hello such .. !!
With Wine1.7 to create a new project me this error message is displayed "Internal Exception: Access violation in module 'VGDVC.DLL' [00010C56]"
However, Wine1.6 not have that problem .... I guess that is a regress.
With Wine1.7 to create a new project me this error message is displayed "Internal Exception: Access violation in module 'VGDVC.DLL' [00010C56]"
However, Wine1.6 not have that problem .... I guess that is a regress.
Re: Proteus 8 does not longer works with Wine 1.7
First make sure your "Wine1.7" is actually the latest development release (1.7.26), and try reinstalling the app to a clean wineprefix. If that doesn't solve it, run a regression test and file a bug.
Re: Proteus 8 does not longer works with Wine 1.7
Okay I installed the v1.7.26 as told and still the problem persists.
Re: Proteus 8 does not longer works with Wine 1.7
remove your wineprefix (backup some of your apps) then reinstall your software , it might work
Re: Proteus 8 does not longer works with Wine 1.7
Still does not work... I'll have to send a report to see if they solve.jhay06 wrote:remove your wineprefix (backup some of your apps) then reinstall your software , it might work
Re: Proteus 8 does not longer works with Wine 1.7
I can not do regression testing...
Someone else could report this?
Someone else could report this?
Re: Proteus 8 does not longer works with Wine 1.7
Yona-TYT I have some bad ish news.
Appdb and bug report entries are the responsibilities of the users of the applications.
In fact asking some else to report for you who you are not paying is impolite. Asking for advice how to write the report we can give you that.
If you cannot do a regression test you should add Appdb Test Results that X versions of wine is failed so someone else using the same program who also cannot do a regression test with a different version can also add working and failed. Appdb Test Results exists so multi people can build up the section of the information of a regression test. So reducing the size of the regression test the developer has to perform attempting to fix a bug. Developer time is highly limited. So its a little early to ask us to do stuff you have not done everything you can yet.
Of course developers would prefer if you could do a regression test. Do at least have a look at the process of performing a regression test. http://wiki.winehq.org/RegressionTesting Yes the process is detailed here. We are willing to accept users saying Regression Tests are too hard and above their skill set. Do be aware not doing a regression test will extend the amount of time until a fix appears. Why regression tested bugs developers will deal with quicker because they take less time and resources. There is a price to pay by choosing not to do a regression test process.
If you are after issue fixed reasonably quickly you will find someone to pay to do regression test for you or work out how to do regression test yourself. Yes it is possible to pay codeweavers and the like to do the regression test for you and of course money talks. So a choice between paid and unpaid regression test you can bet what one the developers will be doing. Not doing it yourself or paying you are going to be at back of que. As long as you are willing to accept that we have no problems. Developers have to eat so paying people do come first on major-ally time consuming tasks. Regression testing is very heavy on the time consuming.
Yona-TYT you can now see why the advice was do regression test.
I guess you did not record exactly what version of wine 1.7 you first had. Because at this point you should have two appdb entries todo. Yes linking bugs to appdb entries also allows developers to see you are interested.
So far I have not see a wine log. http://wiki.winehq.org/FAQ#get_log Application error messages tell us almost nothing useful. With a log one of us here in support might see something that we can suggest that might get the application working. We will not see anything from Application error messages.
Yona-TYT you have just learnt why you should keep a record of what versions of wine the applications are working with.
By the way Wine 1.6 cannot be what you are running it had to be wine 1.6.2 because the program did not run with Wine 1.6. Please always use wine --version not package names. Yes this could be that a patch to 1.6 line has never been applied to the 1.7.x line.
One of the big problems that new people to FOSS have they complain about something in a forum and a mailing list then come back years latter and its not fixed. Why is it not fixed it was never put into reporting system because the person with the problem is the one todo that.
Yona-TYT please don't take me as mean. But over these things I believe in be blunt now it solves a lot of problems in the future once you understand how the process here works and how the process in most FOSS projects work.
Appdb and bug report entries are the responsibilities of the users of the applications.
So most likely no one else will report this. In fact people like me who have done IRC support and other support for wine know that doing a bug or appdb report for someone else when you don't use the application is forbid. Why is it forbid developer may need to ask a real user if the bug fix they have done fixed it or not. So unless you do it don't expect us to. We will provide advice and suggestions but key tasks like adding entries to Appdb to log what versions work and fail as well as bug reports we cannot do for you.Someone else could report this?
In fact asking some else to report for you who you are not paying is impolite. Asking for advice how to write the report we can give you that.
If you cannot do a regression test you should add Appdb Test Results that X versions of wine is failed so someone else using the same program who also cannot do a regression test with a different version can also add working and failed. Appdb Test Results exists so multi people can build up the section of the information of a regression test. So reducing the size of the regression test the developer has to perform attempting to fix a bug. Developer time is highly limited. So its a little early to ask us to do stuff you have not done everything you can yet.
Of course developers would prefer if you could do a regression test. Do at least have a look at the process of performing a regression test. http://wiki.winehq.org/RegressionTesting Yes the process is detailed here. We are willing to accept users saying Regression Tests are too hard and above their skill set. Do be aware not doing a regression test will extend the amount of time until a fix appears. Why regression tested bugs developers will deal with quicker because they take less time and resources. There is a price to pay by choosing not to do a regression test process.
If you are after issue fixed reasonably quickly you will find someone to pay to do regression test for you or work out how to do regression test yourself. Yes it is possible to pay codeweavers and the like to do the regression test for you and of course money talks. So a choice between paid and unpaid regression test you can bet what one the developers will be doing. Not doing it yourself or paying you are going to be at back of que. As long as you are willing to accept that we have no problems. Developers have to eat so paying people do come first on major-ally time consuming tasks. Regression testing is very heavy on the time consuming.
Yona-TYT you can now see why the advice was do regression test.
I guess you did not record exactly what version of wine 1.7 you first had. Because at this point you should have two appdb entries todo. Yes linking bugs to appdb entries also allows developers to see you are interested.
So far I have not see a wine log. http://wiki.winehq.org/FAQ#get_log Application error messages tell us almost nothing useful. With a log one of us here in support might see something that we can suggest that might get the application working. We will not see anything from Application error messages.
Yona-TYT you have just learnt why you should keep a record of what versions of wine the applications are working with.
By the way Wine 1.6 cannot be what you are running it had to be wine 1.6.2 because the program did not run with Wine 1.6. Please always use wine --version not package names. Yes this could be that a patch to 1.6 line has never been applied to the 1.7.x line.
One of the big problems that new people to FOSS have they complain about something in a forum and a mailing list then come back years latter and its not fixed. Why is it not fixed it was never put into reporting system because the person with the problem is the one todo that.
Yona-TYT please don't take me as mean. But over these things I believe in be blunt now it solves a lot of problems in the future once you understand how the process here works and how the process in most FOSS projects work.
Re: Proteus 8 does not longer works with Wine 1.7
Well, maybe I learned a little of how things work here.
I guess this is not going to be resolved in the near future ... that bad.
Anyway... Thank you all for your answers .. !!
I guess this is not going to be resolved in the near future ... that bad.
Anyway... Thank you all for your answers .. !!
Re: Proteus 8 does not longer works with Wine 1.7
That is not possible with plain Wine. All patches backported to the stable branch are in the development branch. If there's a patch in the user's 1.6.x that made this app work, it is unsupported, and this is not a regression.oiaohm wrote: Yes this could be that a patch to 1.6 line has never been applied to the 1.7.x line.
There is already a bug filed for Proteus Professional 8 not working, and that was filed for 1.6: https://bugs.winehq.org/show_bug.cgi?id=34457.
Re: Proteus 8 does not longer works with Wine 1.7
I did some tests and can confirm that the problem is presented starting from wine1.7.20 (1.7.19 - 1.7.20)
Re: Proteus 8 does not longer works with Wine 1.7
Yona-TYT I see you have got some progress.
https://appdb.winehq.org/objectManager. ... &iId=27887 I see the information has not been placed in appdb test results yet.
http://wiki.winehq.org/FAQ#get_log I still have not seen a log. Yona-TYT comparing the log output of wine of run with 1.7.19 and 1.7.20 might give a clue. That might allow us doing assistance to suggest a library override. Also for submitting a bug report you will need the log same reason developer will use this at times.
The fault is still fairly young. 7 versions back is 14 weeks. So it a really good time to open up a bug report.
Yona-TYT if you have questions about filling out the bug report and appdb test result entries we are here. You are point where you do stand a reasonable chance of getting fault fix if a bug is reported now with the information you have collected so far with logs.
So if you are a person who cannot to a regression test down to the exact patch or you don't have time todo this you are at the point now of being able to submit a decent bug report.
Yona-TYT so I think you are to the point of dotting the i's and crossing the t's. Yes filling in bug reports and appdb test results then pray.
Also do post on the forum a log. This forum has add file for a reason. Even that us doing support are mostly not developers we can at time suggest using winetricks script to install parts at times to avoid broken code lines in wine. Yes if having to use a winetricks script option to make a program work still requires you to submit a bug report as it very much a bandage over a open fault.
https://appdb.winehq.org/objectManager. ... &iId=27887 I see the information has not been placed in appdb test results yet.
http://wiki.winehq.org/FAQ#get_log I still have not seen a log. Yona-TYT comparing the log output of wine of run with 1.7.19 and 1.7.20 might give a clue. That might allow us doing assistance to suggest a library override. Also for submitting a bug report you will need the log same reason developer will use this at times.
The fault is still fairly young. 7 versions back is 14 weeks. So it a really good time to open up a bug report.
Yona-TYT if you have questions about filling out the bug report and appdb test result entries we are here. You are point where you do stand a reasonable chance of getting fault fix if a bug is reported now with the information you have collected so far with logs.
So if you are a person who cannot to a regression test down to the exact patch or you don't have time todo this you are at the point now of being able to submit a decent bug report.
Yona-TYT so I think you are to the point of dotting the i's and crossing the t's. Yes filling in bug reports and appdb test results then pray.
Also do post on the forum a log. This forum has add file for a reason. Even that us doing support are mostly not developers we can at time suggest using winetricks script to install parts at times to avoid broken code lines in wine. Yes if having to use a winetricks script option to make a program work still requires you to submit a bug report as it very much a bandage over a open fault.
Re: Proteus 8 does not longer works with Wine 1.7
It is necessary to Submit a new bug report ?
Re: Proteus 8 does not longer works with Wine 1.7
http://wiki.winehq.org/FAQ#get_log Still no log files from wine.
Yona-TYT without log files I cannot match attempt to match this bug up to existing bugs for you. If fault cannot be matched up against existing I have no option bar suggest submit a new bug report.
Submitting bug reports and updating appdb is necessary if you want the fault fixed.
Yona-TYT without logs for happening between 1.7.19-1.7.20 I cannot see anything like this reported. So I have to presume its a new bug. Only bug kinda like this is reported against wine 1.6. Since as you report it has been working after that that bug would be suspected as fixed and not closed. So from as far as I can see there is no valid bug to append to.
You have us support people. There is the triage team. Then there are the Developers. The triage team read the bug reports and logs and see if bugs two or more bugs can be merged and that bugs have enough information submitted. Of course you don't go out and intentionally submit duplicates but if you do by error processes are in place to handle it. As far as I can tell this fault is not a duplicate but everyone here information short to tell. Yes the triage team exists because project don't expect bug reports to be perfection.
You will notice every post of my I am asking for wine log. Two applications may display complete different error messages yet be exactly the same fault. Wine produces its own form of logging for a reason.
Yona-TYT everything is very structured. Following process is the only way to get results other than fix it yourself.
Yona-TYT without log files I cannot match attempt to match this bug up to existing bugs for you. If fault cannot be matched up against existing I have no option bar suggest submit a new bug report.
Submitting bug reports and updating appdb is necessary if you want the fault fixed.
Yona-TYT without logs for happening between 1.7.19-1.7.20 I cannot see anything like this reported. So I have to presume its a new bug. Only bug kinda like this is reported against wine 1.6. Since as you report it has been working after that that bug would be suspected as fixed and not closed. So from as far as I can see there is no valid bug to append to.
You have us support people. There is the triage team. Then there are the Developers. The triage team read the bug reports and logs and see if bugs two or more bugs can be merged and that bugs have enough information submitted. Of course you don't go out and intentionally submit duplicates but if you do by error processes are in place to handle it. As far as I can tell this fault is not a duplicate but everyone here information short to tell. Yes the triage team exists because project don't expect bug reports to be perfection.
You will notice every post of my I am asking for wine log. Two applications may display complete different error messages yet be exactly the same fault. Wine produces its own form of logging for a reason.
Yona-TYT everything is very structured. Following process is the only way to get results other than fix it yourself.
Re: Proteus 8 does not longer works with Wine 1.7
I have sent a new test result, place the debugging log in the comments... is this the correct way?
Re: Proteus 8 does not longer works with Wine 1.7
No. Debug logs don't belong in the AppDB at all, and even if they did, you shouldn't expect the people trying to help you here to go hunting for a log in the AppDB. Attach it here.Yona-TYT wrote:I have sent a new test result, place the debugging log in the comments... is this the correct way?
The AppDB is also not the place to file bugs; do that in bugzilla. As to whether you should file a new one when there already is one for Proteus 8 not working, the answer is yes, as that bug was filed for 1.6, and you claim this problem did not appear until 1.7.20, so it seems you are reporting a different issue.
Re: Proteus 8 does not longer works with Wine 1.7
I sent the report to Bugzilla, but they said him to do regression testing.
https://bugs.winehq.org/show_bug.cgi?id=37255
Well, I think that is where Yona gives up.
https://bugs.winehq.org/show_bug.cgi?id=37255
Well, I think that is where Yona gives up.
Re: Proteus 8 does not longer works with Wine 1.7
Yona-TYT you need to visit bug. "Austin English" one of the members of the triage team has seen it.
Yes you made a error in bug submission. The log files need to go into "Add an attachment" area of the bugzilla not independent service. And of course Austin English has asked you again if you will perform a Regression test.
From the logs
"fixme:dbghelp:elf_search_auxv can't find symbol in module" this is really strange and I cannot suggest an override to fix this. There was a single modification to dbghelp in 1.7.40 that was a suspected unsed variable. Maybe its not that unused.
So you are almost to end not quite yet. Yona-TYT.
Yes you made a error in bug submission. The log files need to go into "Add an attachment" area of the bugzilla not independent service. And of course Austin English has asked you again if you will perform a Regression test.
From the logs
"fixme:dbghelp:elf_search_auxv can't find symbol in module" this is really strange and I cannot suggest an override to fix this. There was a single modification to dbghelp in 1.7.40 that was a suspected unsed variable. Maybe its not that unused.
So you are almost to end not quite yet. Yona-TYT.
Re: Proteus 8 does not longer works with Wine 1.7
me too I have the same problm :/
Re: Proteus 8 does not longer works with Wine 1.7
Just do HKEY_CURRENT_USER\Software\Labcenter Electronics\Proteus 8 Professional\Default Graphics Mode=1
-
- Newbie
- Posts: 1
- Joined: Sat Jan 23, 2016 3:17 pm
Re: Proteus 8 does not longer works with Wine 1.7
@Demeo.
It worked!
I was suffering the same problem. I just changed the register key, and it worked inmediately.
Thank you so much!
It worked!
I was suffering the same problem. I just changed the register key, and it worked inmediately.
Thank you so much!