http://bugs.winehq.org/show_bug.cgi?id=58161
Bug ID: 58161 Summary: Unimplemented function advapi32.dll.SystemFunction036 in LTSpice Product: Wine Version: 10.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: scallegari@arces.unibo.it Distribution: ---
LTSpice has traditionally been a wine-friendly application. Not long ago, its website used to explicitly suggest using wine to run the application in Linux. Recently, LTSpice has become impossible to install because it stops with the error in subject.
http://bugs.winehq.org/show_bug.cgi?id=58161
--- Comment #1 from Sergio Callegari scallegari@arces.unibo.it --- Followup: this seems to be a problem with the updating of the wine components when wine gets upgraded to a new version. Erasing the prefix and recreating it solves the issue.
http://bugs.winehq.org/show_bug.cgi?id=58161
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #2 from Austin English austinenglish@gmail.com --- I think in the past we've considered bugs like this INVALID for development releases. Alexandre, what do you think?
http://bugs.winehq.org/show_bug.cgi?id=58161
--- Comment #3 from Sergio Callegari scallegari@arces.unibo.it --- The most important point is clearly that the issue does not stay for the stable release, i.e. that when you update from one stable release to another it happens that some components remain in an inconsistent state in one of your wine prefixes.
Yet, I don't know if there is any statistical data, but in my circle I would say that the vast majority of the wine users are on the development releases, because (1) this is what many distros ship by default; (2) the situation is so dynamic that getting bug fixes and enhancements early makes a difference; (3) the development releases have historically been rather solid. So, addressing this early (if possible) could still be helpfull to many.
http://bugs.winehq.org/show_bug.cgi?id=58161
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- (In reply to Austin English from comment #2)
I think in the past we've considered bugs like this INVALID for development releases. Alexandre, what do you think?
Sometimes when there are changes to low-level dlls, it's possible that the prefix needs to be re-created, or else forcefully updated with WINEBOOTSTRAPMODE=1. That can even happen between stable releases. I understand that it's annoying, but I'm afraid it can't be completely avoided.
http://bugs.winehq.org/show_bug.cgi?id=58161
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED CC| |xerox.xerox2000x@gmail.com
--- Comment #5 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Alexandre Julliard from comment #4)
(In reply to Austin English from comment #2)
I think in the past we've considered bugs like this INVALID for development releases. Alexandre, what do you think?
Sometimes when there are changes to low-level dlls, it's possible that the prefix needs to be re-created, or else forcefully updated with WINEBOOTSTRAPMODE=1. That can even happen between stable releases. I understand that it's annoying, but I'm afraid it can't be completely avoided.
Let's resolve this as WONTFIX then.
http://bugs.winehq.org/show_bug.cgi?id=58161
--- Comment #6 from Sergio Callegari scallegari@arces.unibo.it --- Would it then be enough to run `WINEPREFIX=... WINEBOOTSTRAPMODE=1 wine ...` to fix things?