http://bugs.winehq.org/show_bug.cgi?id=21220
Summary: 16-bit app barks at wprocs.dll and then crashes Product: Wine Version: unspecified Platform: x86 URL: http://193.219.43.130/~winetester/bin/win16/ledw2.tar. bz2 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs@winehq.org ReportedBy: saulius2@gmail.com
Created an attachment (id=25490) --> (http://bugs.winehq.org/attachment.cgi?id=25490) Crash log for Wine-1.1.35+
This happens with the first patch of recent 16-bit separation work [1] Alexandre did just before New Year of 2010:
commit 475b7d226cc062524495268825c3028c2797174d Author: Alexandre Julliard julliard@winehq.org Date: Tue Dec 29 16:24:00 2009 +0100
kernel32: Make krnl386.exe into a stand-alone 16-bit module.
Attaching output. With the next patch [2] the crash changes a bit:
commit e7715126eb8ab561c592af0c160ca199c6d7f61a Author: Alexandre Julliard julliard@winehq.org Date: Tue Dec 29 12:32:36 2009 +0100
winedos: Move 16-bit VxD support back into kernel.
Now line "err:module:__wine_dll_register_16 loading old style 16-bit dll wprocs.dll no longer supported" disappears from Wine output but the rest seems to remain the same. All the way until the series of separation patches ends with [3].
Well, it may be so binary cruft left in the dev tree which messes things up. I've did "rm -rf dlls/ libs/ programs/" now and started rebuild process.
[1] http://source.winehq.org/git/wine.git/?a=commit;h=475b7d226cc06252 [2] http://source.winehq.org/git/wine.git/?a=commit;h=e7715126eb8ab561 [3] http://source.winehq.org/git/wine.git/?a=commit;h=b3878802695ef47c
http://bugs.winehq.org/show_bug.cgi?id=21220
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression, win16
http://bugs.winehq.org/show_bug.cgi?id=21220
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|user32 |kernel32 Version|unspecified |1.1.35
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com 2010-01-01 18:02:33 --- (In reply to comment #0)
Now line "err:module:__wine_dll_register_16 loading old style 16-bit dll wprocs.dll no longer supported" disappears from Wine output but the rest seems to remain the same. All the way until the series of separation patches ends with [3].
Maybe your speaking about http://source.winehq.org/git/wine.git/?a=commit;h=f82ddf5e662da10e442d200f12...
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #2 from Saulius K. saulius2@gmail.com 2010-01-02 00:36:48 --- Cleaning those directories didn't help Wine compiled at point [3].
(In reply to comment #1)
Nikolay, I doubt that -- crash occurs at patch [1] already. Except perhaps the dev tree could be messed up with leftover and this is the only patch which fixes regression.
I could do "rm -rf dlls/ libs/ programs/; git checkout -f" if you persist, and rebuild Wine just before and with the patch you pointed to.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #3 from Saulius K. saulius2@gmail.com 2010-01-02 00:38:28 --- PS: This bug doesn't occur in Wine-1.1.35, Nikolay, so your version setting is a false statement.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #4 from Jeff Zaroyko jeffz@jeffz.name 2010-01-02 03:08:57 --- (In reply to comment #3)
PS: This bug doesn't occur in Wine-1.1.35, Nikolay, so your version setting is a false statement.
1.1.35 is what we set the version to for current git when it is before 1.1.36, if you check your --version, it will still partly be 1.1.35.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #5 from Saulius K. saulius2@gmail.com 2010-01-02 04:24:32 --- This is offtopic but that's inaccurate. Earlier we had CVS tag for that purpose. Can someone explain, please, why was it removed?
Now if someone forgets such temporarily decremented version setting in a bug report, the report states false fact. I consider this as a bug.
Is some bug report filled about this already?
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com 2010-01-02 04:32:56 --- (In reply to comment #5)
This is offtopic but that's inaccurate. Earlier we had CVS tag for that purpose. Can someone explain, please, why was it removed?
Cause it means nothing and requires commenting from time to time anyway.
Now if someone forgets such temporarily decremented version setting in a bug report, the report states false fact. I consider this as a bug.
It's not false. Version just indicates latest release before tested and simplifies version based querying.
Is some bug report filled about this already?
It's not a bug, it's just how it goes now.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #7 from Saulius K. saulius2@gmail.com 2010-01-02 04:50:34 --- (In reply to comment #6)
Cause it means nothing and requires commenting from time to time anyway.
It did mean suffix of the version string. And now it requires changing version field from time to time :(
Now if someone forgets such temporarily decremented version setting in a bug report, the report states false fact. I consider this as a bug.
It's not false. Version just indicates latest release before tested and simplifies version based querying.
In what way it does simplify? Lets assume another guy comes and sees version 1.1.35 in some regression report. Then he does regression hunt between v1.1.34 and v1.1.35. What does he find? Just that v1.1.35 is good AND bad.
It wouldn't call that simplification.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #8 from Austin English austinenglish@gmail.com 2010-01-02 11:41:44 --- (In reply to comment #7)
(In reply to comment #6)
Cause it means nothing and requires commenting from time to time anyway.
It did mean suffix of the version string. And now it requires changing version field from time to time :(
Now if someone forgets such temporarily decremented version setting in a bug report, the report states false fact. I consider this as a bug.
It's not false. Version just indicates latest release before tested and simplifies version based querying.
In what way it does simplify? Lets assume another guy comes and sees version 1.1.35 in some regression report. Then he does regression hunt between v1.1.34 and v1.1.35. What does he find? Just that v1.1.35 is good AND bad.
It wouldn't call that simplification.
Often, regressions in git are fixed before a release is made. The solution is to put the current git commit in the bug comments somewhere. Yes, it's not perfect, but it's better than the previous solution where CVS/GIT could describe current git, or a release that is 6 years old.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #9 from Dmitry Timoshkov dmitry@codeweavers.com 2010-01-03 04:31:31 --- See the bug 12728 for details about CVS/GIT version tag.
http://bugs.winehq.org/show_bug.cgi?id=21220
--- Comment #10 from Saulius K. saulius2@gmail.com 2010-01-17 03:26:19 --- OK, this bug was fixed this year already [6]:
commit 26a42f845284bdf642b863597dcb1a90d17b3e46 Author: Alexandre Julliard julliard@winehq.org Date: Tue Jan 5 14:26:05 2010 +0100
winedos: Merge all of winedos back into krnl386.
Thanks again go to Alexandre :)
[6] http://source.winehq.org/git/wine.git/?a=commit;h=26a42f845284bdf6
http://bugs.winehq.org/show_bug.cgi?id=21220
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #11 from Nikolay Sivov bunglehead@gmail.com 2010-01-17 07:00:18 --- Hi, Saulius. You could mark your own bugs fixed.
Reported fixed by commit 26a42f845284bdf642b863597dcb1a90d17b3e46.
http://bugs.winehq.org/show_bug.cgi?id=21220
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org 2010-01-22 11:02:28 --- Closing bugs fixed in 1.1.37.
-
wine-bugs＠winehq.org