What constitutes a good backtrace?
What constitutes a good backtrace?
Hi all,
I did my first bug report in a while. Unfortunately the good folks
at wineHQ.org didn't like it much because Gentoo by default stripped
out much of the backtrace info. I've recompiled Wine with more
backtrace capabilities in it and am wondering what's considered good
enough.
Below are two backtraces. They may or may not be exactly the same
failure but they both come from the same program doing similar things.
(Testing the system hardware for compatibility.) The first one is the
older one. The second is newer. My question is whether the second is
considered 'good enough' to be genuinely helpful?
Eventually, when I get a 'good' backtrace then I'll capture the 3
or 4 ways the program fails and submit all the data for the developers
but currently I'm just trying to get the basics working well enough to
be helpful.
Thanks,
Mark
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
12 0x1287:0x1318 (0x12c7:0x551c)
13 0x101f:0x0468 in kernel32 (+0x7e30c) (0x12c7:0x5556)
14 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dade858)
15 0x7ed0cdfe WINPROC_wrapper+0x50e() in user32 (0x7dadeb98)
16 0x7ed0f86c in user32 (+0xaf86c) (0x7dadf098)
17 0x7ed10dda in user32 (+0xb0dda) (0x7dadf0c8)
18 0x7ed10f61 in user32 (+0xb0f61) (0x7dadf768)
19 0x7ed1326f in user32 (+0xb326f) (0x7dadf7a8)
20 0x7ecd8232 in user32 (+0x78232) (0x7dadf818)
21 0x7ecdbfb9 in user32 (+0x7bfb9) (0x7dadf878)
Backtrace:
=>1 0x128f:0x462d (0x12c7:0x4f54)
2 0x128f:0x44f5 (0x12c7:0x5094)
3 0x128f:0x3a73 (0x12c7:0x5206)
4 0x1287:0x1e92 (0x12c7:0x5252)
5 0x1287:0x11c7 (0x12c7:0x52a6)
6 0x1287:0x1318 (0x12c7:0x52be)
7 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x52f8)
8 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dad83d8)
9 0x7ed00dfe call_window_proc16+0x16e() in user32 (0x7dad8718)
10 0x7ed0386c WINPROC_CallProc32ATo16+0x101c() in user32 (0x7dad8c18)
11 0x7ed04dda call_window_proc_Ato16+0x4a() in user32 (0x7dad8c48)
12 0x7ed04f61 WINPROC_CallProcWtoA+0x181() in user32 (0x7dad92e8)
13 0x7ed0726f WINPROC_call_window+0x1df() in user32 (0x7dad9328)
14 0x7ecccbaf DispatchMessageW+0x9f() in user32 (0x7dad9368)
15 0x7ec9987f IsDialogMessageW+0x10f() in user32 (0x7dad94c8)
16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)
I did my first bug report in a while. Unfortunately the good folks
at wineHQ.org didn't like it much because Gentoo by default stripped
out much of the backtrace info. I've recompiled Wine with more
backtrace capabilities in it and am wondering what's considered good
enough.
Below are two backtraces. They may or may not be exactly the same
failure but they both come from the same program doing similar things.
(Testing the system hardware for compatibility.) The first one is the
older one. The second is newer. My question is whether the second is
considered 'good enough' to be genuinely helpful?
Eventually, when I get a 'good' backtrace then I'll capture the 3
or 4 ways the program fails and submit all the data for the developers
but currently I'm just trying to get the basics working well enough to
be helpful.
Thanks,
Mark
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
12 0x1287:0x1318 (0x12c7:0x551c)
13 0x101f:0x0468 in kernel32 (+0x7e30c) (0x12c7:0x5556)
14 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dade858)
15 0x7ed0cdfe WINPROC_wrapper+0x50e() in user32 (0x7dadeb98)
16 0x7ed0f86c in user32 (+0xaf86c) (0x7dadf098)
17 0x7ed10dda in user32 (+0xb0dda) (0x7dadf0c8)
18 0x7ed10f61 in user32 (+0xb0f61) (0x7dadf768)
19 0x7ed1326f in user32 (+0xb326f) (0x7dadf7a8)
20 0x7ecd8232 in user32 (+0x78232) (0x7dadf818)
21 0x7ecdbfb9 in user32 (+0x7bfb9) (0x7dadf878)
Backtrace:
=>1 0x128f:0x462d (0x12c7:0x4f54)
2 0x128f:0x44f5 (0x12c7:0x5094)
3 0x128f:0x3a73 (0x12c7:0x5206)
4 0x1287:0x1e92 (0x12c7:0x5252)
5 0x1287:0x11c7 (0x12c7:0x52a6)
6 0x1287:0x1318 (0x12c7:0x52be)
7 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x52f8)
8 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dad83d8)
9 0x7ed00dfe call_window_proc16+0x16e() in user32 (0x7dad8718)
10 0x7ed0386c WINPROC_CallProc32ATo16+0x101c() in user32 (0x7dad8c18)
11 0x7ed04dda call_window_proc_Ato16+0x4a() in user32 (0x7dad8c48)
12 0x7ed04f61 WINPROC_CallProcWtoA+0x181() in user32 (0x7dad92e8)
13 0x7ed0726f WINPROC_call_window+0x1df() in user32 (0x7dad9328)
14 0x7ecccbaf DispatchMessageW+0x9f() in user32 (0x7dad9368)
15 0x7ec9987f IsDialogMessageW+0x10f() in user32 (0x7dad94c8)
16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)
What constitutes a good backtrace?
On Fri, Mar 7, 2008 at 3:16 PM, Mark Knecht <[email protected]> wrote:
line numbers. Perhaps that info was stripped out
during install; try running the wine that's in the build
directory (if you can).
Hi Mark, thanks for asking! Sadly, that trace doesn't have16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)
line numbers. Perhaps that info was stripped out
during install; try running the wine that's in the build
directory (if you can).
What constitutes a good backtrace?
On Fri, Mar 7, 2008 at 3:25 PM, Dan Kegel <[email protected]> wrote:
Currently I'm running Wine built from Gentoo portage. All the
default gcc flags either turn off or strip out all this backtrace
info. I tried turning it back on but I'm not a developer and really
don't understand this stuff so I'll need to learn.
I saw on the Wine site that it says the default version of Wine has
this stuff turned on. I suppose that means that if I download the
tarball and build from that then I'll get the info possibly because
the Wine build process doesn't turn it off or strip it out.
If building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.
cheers,
Mark
Dan,On Fri, Mar 7, 2008 at 3:16 PM, Mark Knecht <[email protected]> wrote:Hi Mark, thanks for asking! Sadly, that trace doesn't have16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)
line numbers. Perhaps that info was stripped out
during install; try running the wine that's in the build
directory (if you can).
Currently I'm running Wine built from Gentoo portage. All the
default gcc flags either turn off or strip out all this backtrace
info. I tried turning it back on but I'm not a developer and really
don't understand this stuff so I'll need to learn.
I saw on the Wine site that it says the default version of Wine has
this stuff turned on. I suppose that means that if I download the
tarball and build from that then I'll get the info possibly because
the Wine build process doesn't turn it off or strip it out.
If building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.
cheers,
Mark
What constitutes a good backtrace?
On Fri, Mar 7, 2008 at 3:47 PM, Mark Knecht <[email protected]> wrote:
might have better info for you.
You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad
Probably. If my resident gentoo guru were here, IIf building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.
might have better info for you.
You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad
What constitutes a good backtrace?
On 3/7/08, Dan Kegel <[email protected]> wrote:
Did you try this? http://www.gentoo.org/proj/en/qa/backtraces.xmlOn Fri, Mar 7, 2008 at 3:47 PM, Mark Knecht <[email protected]> wrote:Probably. If my resident gentoo guru were here, IIf building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.
might have better info for you.
You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad
What constitutes a good backtrace?
On Fri, Mar 7, 2008 at 4:40 PM, Charity Abbott <[email protected]> wrote:
For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries. Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?
Thanks,
Mark
Yes thanks. That's what I was working from to get this far.On 3/7/08, Dan Kegel <[email protected]> wrote:Did you try this? http://www.gentoo.org/proj/en/qa/backtraces.xmlOn Fri, Mar 7, 2008 at 3:47 PM, Mark Knecht <[email protected]> wrote:Probably. If my resident gentoo guru were here, IIf building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.
might have better info for you.
You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad
For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries. Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?
Thanks,
Mark
What constitutes a good backtrace?
On Fri, Mar 7, 2008 at 5:24 PM, Mark Knecht <[email protected]> wrote:
Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.
Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan
Not emulation libraries. They're plain old 32 bit libraries.For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries.
Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.
No problem. We don't need symbols there.Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?
Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan
What constitutes a good backtrace?
A bit offtopic, but it's mostly because of preference, and 64-bit seems more
lightweight when it comes to multitasking and other kind of operations. At
least that's been my experience, but I keep 32-bit just because it's more
compatible xD (I've had a few issues with wifi and webcam drivers before so
:p)
On Sat, Mar 8, 2008 at 10:47 PM, Dan Kegel <[email protected]> wrote:
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
lightweight when it comes to multitasking and other kind of operations. At
least that's been my experience, but I keep 32-bit just because it's more
compatible xD (I've had a few issues with wifi and webcam drivers before so
:p)
On Sat, Mar 8, 2008 at 10:47 PM, Dan Kegel <[email protected]> wrote:
-------------- next part --------------Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
Re: What constitutes a good backtrace?
If you install binaries and then "strip" then (or the installer strips them) then they are no good. You have to either:
1. Tell the installer not to strip Wine binaries when it installs them
2. Install debug package (dunno if it's available with gentoo)
3. Compile Wine yourself and do not install it - run it from the compile dir (as noted above)
1. Tell the installer not to strip Wine binaries when it installs them
2. Install debug package (dunno if it's available with gentoo)
3. Compile Wine yourself and do not install it - run it from the compile dir (as noted above)
What constitutes a good backtrace?
According to Gentoo...
Note: Some packages unfortunately handle stripping by themselves,
inside the upstream provided makefiles. This is an error and should be
reported. All packages should leave Portage the task of the stripping
or simply restrict stripping entirely. The main exception to this are
binary packages. They are usually stripped by upstream, outside of
Portage control.
Wine seems to be one of these packages. I tried it myself. However,
they provide winedbg and it is included in the Gentoo package. Did you
try running that?
Note: Some packages unfortunately handle stripping by themselves,
inside the upstream provided makefiles. This is an error and should be
reported. All packages should leave Portage the task of the stripping
or simply restrict stripping entirely. The main exception to this are
binary packages. They are usually stripped by upstream, outside of
Portage control.
Wine seems to be one of these packages. I tried it myself. However,
they provide winedbg and it is included in the Gentoo package. Did you
try running that?
Re: What constitutes a good backtrace?
Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verifyCharity Abbott wrote:Wine seems to be one of these packages. I tried it myself.
Code: Select all
./configure && make all install
What winedbg has anything to do with that?! Do you even have a clue what it is?Charity Abbott wrote:However, they provide winedbg and it is included in the Gentoo package. Did you
try running that?
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 8:36 AM, vitamin <[email protected]> wrote:
Gee, I wish I would have posted this last night. Maybe it would
have helped keep things more low key.
OK, there seems to have been a new release of Wine on the WinHQ.org
site so I built that last night and did not install it. This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?
I ran Wine this way:
mark@lightning ~/Desktop/Wine-0.9.57 $ ./wine-0.9.57/wine
"D:\setup.exe" &>~mark/Desktop/wine-LH_log.txt
Thanks,
MArk
fixmewodPlayer_Reset shouldn't have headers left
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
Unhandled exception: divide by zero in 16-bit code (127f:9de9).
In 16 bit mode.
Register dump:
CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b
IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C)
AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a
Stack dump:
0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f
0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000
0x12c7:0x5274: 0000 0000 01e8 014d 1668 a10d 1e24 1587
0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw-
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
12 0x1287:0x1318 (0x12c7:0x551c)
13 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x5556)
14 0x7ee8cb7e K32WOWCallback16Ex+0xce(vpfn16=0x0, dwFlags=<is not
available>, cbArgs=<register ESI not in topmost frame>,
pArgs=0x7e472b60, pdwRetCode=0x7e472894)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/kernel32/wowthunk.c:636]
in kernel32 (0x7e472858)
15 0x7ed1442e call_window_proc16+0x16e(hwnd=0x5c, msg=0x111,
wParam=0x45b, lParam=<register EDI not in topmost frame>,
result=0x7e47380c, arg=<is not available>)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:549]
in user32 (0x7e472b98)
16 0x7ed16eac WINPROC_CallProc32ATo16+0x101c(callback=0x7ed142c0,
hwnd=0x1005c, msg=<is not available>, wParam=<is not available>,
lParam=<register ESI not in topmost frame>, result=0x7e47380c,
arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:2165]
in user32 (0x7e473098)
17 0x7ed1841a call_window_proc_Ato16+0x4a(hwnd=0x1005c, msg=0x111,
wp=0x45b, lp=0x10082, result=0x7e47380c, arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:567]
in user32 (0x7e4730c8)
18 0x7ed185a1 WINPROC_CallProcWtoA+0x181(callback=0x7ed183d0,
hwnd=0x1005c, msg=0x111, wParam=0x45b, lParam=0x10082,
result=0x7e47380c, arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:1272]
in user32 (0x7e473768)
19 0x7ed1a8cf WINPROC_call_window+0x1df(hwnd=<register ESI not in
topmost frame>, msg=0x111, wParam=0x45b, lParam=0x10082,
result=0x7e47380c, unicode=0x1, mapping=0x45b)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:2202]
in user32 (0x7e4737a8)
20 0x7ecdd662 call_window_proc+0xc2(hwnd=<register ESI not in
topmost frame>, msg=0x111, wparam=0x45b, lparam=0x10082, unicode=0x1,
same_thread=0x1, mapping=0x45b)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/message.c:1615]
in user32 (0x7e473818)
Hi guys,Charity Abbott wrote:Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verifyWine seems to be one of these packages. I tried it myself.
Code:
./configure && make all install
Charity Abbott wrote:What winedbg has anything to do with that?! Do you even have a clue what it is?However, they provide winedbg and it is included in the Gentoo package. Did you
try running that?
Gee, I wish I would have posted this last night. Maybe it would
have helped keep things more low key.
OK, there seems to have been a new release of Wine on the WinHQ.org
site so I built that last night and did not install it. This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?
I ran Wine this way:
mark@lightning ~/Desktop/Wine-0.9.57 $ ./wine-0.9.57/wine
"D:\setup.exe" &>~mark/Desktop/wine-LH_log.txt
Thanks,
MArk
fixmewodPlayer_Reset shouldn't have headers left
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
Unhandled exception: divide by zero in 16-bit code (127f:9de9).
In 16 bit mode.
Register dump:
CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b
IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C)
AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a
Stack dump:
0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f
0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000
0x12c7:0x5274: 0000 0000 01e8 014d 1668 a10d 1e24 1587
0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw-
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
12 0x1287:0x1318 (0x12c7:0x551c)
13 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x5556)
14 0x7ee8cb7e K32WOWCallback16Ex+0xce(vpfn16=0x0, dwFlags=<is not
available>, cbArgs=<register ESI not in topmost frame>,
pArgs=0x7e472b60, pdwRetCode=0x7e472894)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/kernel32/wowthunk.c:636]
in kernel32 (0x7e472858)
15 0x7ed1442e call_window_proc16+0x16e(hwnd=0x5c, msg=0x111,
wParam=0x45b, lParam=<register EDI not in topmost frame>,
result=0x7e47380c, arg=<is not available>)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:549]
in user32 (0x7e472b98)
16 0x7ed16eac WINPROC_CallProc32ATo16+0x101c(callback=0x7ed142c0,
hwnd=0x1005c, msg=<is not available>, wParam=<is not available>,
lParam=<register ESI not in topmost frame>, result=0x7e47380c,
arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:2165]
in user32 (0x7e473098)
17 0x7ed1841a call_window_proc_Ato16+0x4a(hwnd=0x1005c, msg=0x111,
wp=0x45b, lp=0x10082, result=0x7e47380c, arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:567]
in user32 (0x7e4730c8)
18 0x7ed185a1 WINPROC_CallProcWtoA+0x181(callback=0x7ed183d0,
hwnd=0x1005c, msg=0x111, wParam=0x45b, lParam=0x10082,
result=0x7e47380c, arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:1272]
in user32 (0x7e473768)
19 0x7ed1a8cf WINPROC_call_window+0x1df(hwnd=<register ESI not in
topmost frame>, msg=0x111, wParam=0x45b, lParam=0x10082,
result=0x7e47380c, unicode=0x1, mapping=0x45b)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:2202]
in user32 (0x7e4737a8)
20 0x7ecdd662 call_window_proc+0xc2(hwnd=<register ESI not in
topmost frame>, msg=0x111, wparam=0x45b, lparam=0x10082, unicode=0x1,
same_thread=0x1, mapping=0x45b)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/message.c:1615]
in user32 (0x7e473818)
What constitutes a good backtrace?
On Fri, Mar 7, 2008 at 7:17 PM, Dan Kegel <[email protected]> wrote:
That said I'm not sure of it's usefulness just yet.
someone on the audio lists about should they build 32-bit or 64-bit
you will find that I'm 100% in the 32-bit camp.
So, how come this machine is 64-bit? Well, it goes like this. I bought
this machine 3 1/2 years ago. I had two Fedora 32-bit machines at the
time, one desktop and one laptop. I got an offer I couldn't refuse on
the laptop and sold it. My son then needed a machine for school so he
got my old slow desktop. I was left with the (then) fast 3GHz 64-bit
machine that started as an experiment really. It has a 32-bit chroot
(out of date now) which I wanted to make bootable but never got it
working. If I could then I wouldn't run 64-bit myself. Far too many
problems with web media in M$ formats.
Wonder why I forgot about this bug in the first place? For a couple of
years I didn't even think it was worth the effort to run Wine on the
64-bit machine. I figured it wouldn't work. (I'm still not.) I quit
and the last bugs I filed were back in 2005 I think, at least on this
machine.
Wonder why I'm back? Don't know really. Something came up on some
audio list about folks on 64-bit Linux running Wine to use some audio
programs so I figured (right or wrong) that it might be better now to
give Wine a try. However if you think this is pointless let me know
and I'll stop. As far as I can tell Wine works the same for me on this
machine as our other 32-bit Gentoo machines. I don't see any
difference in how well the programs I'd like to run, mostly games,
actually work.
Really the only issue here, for me, is can I help by giving some good
data. If it helps, then great. Mostly I don't want it to be a bother
to anyone, either on this list or the Wine developers. I'd just like
my time to be as useful as it can and if the games ever get fixed all
the better.
Hope that explains,
Mark
It wasn't any problem to build. make && make depend and it was done.On Fri, Mar 7, 2008 at 5:24 PM, Mark Knecht <[email protected]> wrote:Not emulation libraries. They're plain old 32 bit libraries.For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries.
Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.
That said I'm not sure of it's usefulness just yet.
Actually, if you were to search out all the times I gave an answer toNo problem. We don't need symbols there.Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?
Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan
someone on the audio lists about should they build 32-bit or 64-bit
you will find that I'm 100% in the 32-bit camp.
So, how come this machine is 64-bit? Well, it goes like this. I bought
this machine 3 1/2 years ago. I had two Fedora 32-bit machines at the
time, one desktop and one laptop. I got an offer I couldn't refuse on
the laptop and sold it. My son then needed a machine for school so he
got my old slow desktop. I was left with the (then) fast 3GHz 64-bit
machine that started as an experiment really. It has a 32-bit chroot
(out of date now) which I wanted to make bootable but never got it
working. If I could then I wouldn't run 64-bit myself. Far too many
problems with web media in M$ formats.
Wonder why I forgot about this bug in the first place? For a couple of
years I didn't even think it was worth the effort to run Wine on the
64-bit machine. I figured it wouldn't work. (I'm still not.) I quit
and the last bugs I filed were back in 2005 I think, at least on this
machine.
Wonder why I'm back? Don't know really. Something came up on some
audio list about folks on 64-bit Linux running Wine to use some audio
programs so I figured (right or wrong) that it might be better now to
give Wine a try. However if you think this is pointless let me know
and I'll stop. As far as I can tell Wine works the same for me on this
machine as our other 32-bit Gentoo machines. I don't see any
difference in how well the programs I'd like to run, mostly games,
actually work.
Really the only issue here, for me, is can I help by giving some good
data. If it helps, then great. Mostly I don't want it to be a bother
to anyone, either on this list or the Wine developers. I'd just like
my time to be as useful as it can and if the games ever get fixed all
the better.
Hope that explains,
Mark
Re: What constitutes a good backtrace?
Yes that looks much better.Mark Knecht wrote:This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 10:14 AM, vitamin <[email protected]> wrote:
Now, does it not matter that the first 10 lines or so don't have any
info? I guess the lines a bit lower give them enough info to get close
enough. That's the idea anyway?
With your input I'll go ahead and add the whole file to the bug report.
Thanks!
- Mark
Yeah, I thought so.Mark Knecht wrote:Yes that looks much better.This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?
Now, does it not matter that the first 10 lines or so don't have any
info? I guess the lines a bit lower give them enough info to get close
enough. That's the idea anyway?
With your input I'll go ahead and add the whole file to the bug report.
Thanks!
- Mark
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 10:14 AM, vitamin <[email protected]> wrote:
Be sure to attach the log as a file, not inline.
And you should probably also attach a +relay log.
- Dan
Yep, the 32 bit stuff has line numbers.Yes that looks much better.Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?
Be sure to attach the log as a file, not inline.
And you should probably also attach a +relay log.
- Dan
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 11:36 AM, vitamin <[email protected]> wrote:
merely verifying what he said earlier about adjusting the make.conf
file in Gentoo to not strip the binaries. It does not work correctly
with wine as documented on the Gentoo site. You get ?? symbols when
running gdb.
I ran winedbg "name_of_app", then typing the finish command. I was
just trying to be helpful. In fact, it looked a lot like the backtrace
data Mark just posted.
This note was specific to the Gentoo package. Do you run Gentoo? I wasCharity Abbott wrote:Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verifyWine seems to be one of these packages. I tried it myself.
Code:
./configure && make all install
merely verifying what he said earlier about adjusting the make.conf
file in Gentoo to not strip the binaries. It does not work correctly
with wine as documented on the Gentoo site. You get ?? symbols when
running gdb.
I found I got actual backtrace data, register dump and stack dump when
Charity Abbott wrote:What winedbg has anything to do with that?! Do you even have a clue what it is?However, they provide winedbg and it is included in the Gentoo package. Did you
try running that?
I ran winedbg "name_of_app", then typing the finish command. I was
just trying to be helpful. In fact, it looked a lot like the backtrace
data Mark just posted.
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 10:40 AM, Dan Kegel <[email protected]> wrote:
could you give the correct format? I just tried this I found in
Google:
WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt
but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?
When I get down around the failure this is what I see:
0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
0015:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7ef96573
Unhandled exception: divide by zero in 16-bit code (127f:9de9).
In 16 bit mode.
Register dump:
CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b
IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C)
AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a
Stack dump:
0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f
0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000
0x12c7:0x5274: 0000 0000 01e8 014d fec8 4ef8 1e24 1587
0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw-
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
Thanks,
Mark
Does this mean run it again but use +relay in the command line? If soAnd you should probably also attach a +relay log.
- Dan
could you give the correct format? I just tried this I found in
Google:
WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt
but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?
When I get down around the failure this is what I see:
0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
0015:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7ef96573
Unhandled exception: divide by zero in 16-bit code (127f:9de9).
In 16 bit mode.
Register dump:
CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b
IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C)
AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a
Stack dump:
0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f
0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000
0x12c7:0x5274: 0000 0000 01e8 014d fec8 4ef8 1e24 1587
0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw-
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
Thanks,
Mark
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 11:22 AM, Mark Knecht <[email protected]> wrote:
the exception. But this is kind of looking like it's going to be hard to
fix, the crash seems to be happening in 16 bit app code.
What app is this? Please give us the link to the bug report when you're done.
- Dan
Yes.Does this mean run it again but use +relay in the command line?
No, you got it right! To make it smaller, compress it, e.g. with gzip.If so could you give the correct format? I just tried this I found in
Google:
WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt
but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?
Getting there. You might want to add +seh to show more info aboutWhen I get down around the failure this is what I see:
0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
the exception. But this is kind of looking like it's going to be hard to
fix, the crash seems to be happening in 16 bit app code.
What app is this? Please give us the link to the bug report when you're done.
- Dan
Re: What constitutes a good backtrace?
64-bit processors? Refusal to live in the past? 100% of other Linux apps working fine in 64-bit? Ability to address all of memory in one segment? Find myself in the 1%? I can't exactly settle on one answer. :pDan Kegel wrote:Why is it that people run 64 bit operating systems on their desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan
Sure, I *know* you can come up with a lot of reasons running 32-bit is "better" (or at least, easier for developers and average users), and even show that performance improvements for straight-64-bit are minimal in 'normal' use.
But, the people running 64-bit desktops are helping the developers find problems, and make the apps "bit-agnostic". That in itself has to be worth something.
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 11:28 AM, Dan Kegel <[email protected]> wrote:
that fine point. Didn't change anything much.
you nixed at the time. No big deal. Either way it would be good to get
it looked at.
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.
The best link I have right now is in the bug report:
http://bugs.winehq.org/show_bug.cgi?id=2555
The link above has a download button but you have to be a file planet
member to get it.
There are other links on the web about the game:
http://en.wikipedia.org/wiki/Lighthouse_(computer_game)
It's generally in the Myst genre but harder puzzles to solve, or so I felt.
I'll look at adding +seh, zipping the file and submitting it in the
next hour or so.
Thanks much,
Mark
Good. I tried it again with quotes around the "+relay" since I missedOn Sat, Mar 8, 2008 at 11:22 AM, Mark Knecht <[email protected]> wrote:Yes.Does this mean run it again but use +relay in the command line?
No, you got it right! To make it smaller, compress it, e.g. with gzip.If so could you give the correct format? I just tried this I found in
Google:
WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt
but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?
that fine point. Didn't change anything much.
Yep, it does. That was one of vitamin's comments early on that I thinkGetting there. You might want to add +seh to show more info aboutWhen I get down around the failure this is what I see:
0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
the exception. But this is kind of looking like it's going to be hard to
fix, the crash seems to be happening in 16 bit app code.
you nixed at the time. No big deal. Either way it would be good to get
it looked at.
The app is an old, old game called Lighthouse:The Dark Being which IWhat app is this? Please give us the link to the bug report when you're done.
- Dan
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.
The best link I have right now is in the bug report:
http://bugs.winehq.org/show_bug.cgi?id=2555
The link above has a download button but you have to be a file planet
member to get it.
There are other links on the web about the game:
http://en.wikipedia.org/wiki/Lighthouse_(computer_game)
It's generally in the Myst genre but harder puzzles to solve, or so I felt.
I'll look at adding +seh, zipping the file and submitting it in the
next hour or so.
Thanks much,
Mark
Re: What constitutes a good backtrace?
Does it even work on win2k/winxp? Have you tried first? There are more and more things that Wine does the winNT way and not win9x way. So if you have an app that worked on win9x only - most likely it won't work on Wine.Mark Knecht wrote:The app is an old, old game called Lighthouse:The Dark Being which I
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.
What constitutes a good backtrace?
On Sat, Mar 8, 2008 at 1:39 PM, vitamin <[email protected]> wrote:
trade stocks and absolutely nothing else. If I cannot play it in wine
then I won't bother.
Please remember that I've said earlier that the game itself seems to
work fine, or at least well enough for me to install it and start
playing. I don't know if I'll get to the end successfully in Wine but
at least the game itself works well enough to get started. The only
part that I'm filing a report on is the part of the install process
that tests the system for hardware compatibility, and even in that
part only two parts seem to fail - the part that tests the CDROM and
the part that tests the CPU/OS. Even the OS part passes and it's only
the CPU part that the test says fails.
So, I completely understand that wine may never work completely for
all old Windows programs but if I don't report it then it never gets
fixed, right?
If there is a way for me to get even more in depth data I'm happy to
do that. It will take time but I figure why not? I have a lot of old
games that would be fun to revisit. I was thinking that I may start
repeating the process we're going through on Lighthouse on all my old
games jsut to see what works and what doesn't. Isn't that what we're
supposed ot do?
Thanks,
Mark
I don't load games on my Windows machine anymore. I use Windows toMark Knecht wrote:Does it even work on win2k/winxp? Have you tried first? There are more and more things that Wine does the winNT way and not win9x way. So if you have an app that worked on win9x only - most likely it won't work on Wine.The app is an old, old game called Lighthouse:The Dark Being which I
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.
trade stocks and absolutely nothing else. If I cannot play it in wine
then I won't bother.
Please remember that I've said earlier that the game itself seems to
work fine, or at least well enough for me to install it and start
playing. I don't know if I'll get to the end successfully in Wine but
at least the game itself works well enough to get started. The only
part that I'm filing a report on is the part of the install process
that tests the system for hardware compatibility, and even in that
part only two parts seem to fail - the part that tests the CDROM and
the part that tests the CPU/OS. Even the OS part passes and it's only
the CPU part that the test says fails.
So, I completely understand that wine may never work completely for
all old Windows programs but if I don't report it then it never gets
fixed, right?
If there is a way for me to get even more in depth data I'm happy to
do that. It will take time but I figure why not? I have a lot of old
games that would be fun to revisit. I was thinking that I may start
repeating the process we're going through on Lighthouse on all my old
games jsut to see what works and what doesn't. Isn't that what we're
supposed ot do?
Thanks,
Mark
What constitutes a good backtrace?
Dan Kegel wrote:
in about 1993. I have been wondering ever since why anybody would want
to cling to 32 bit. Recently I have been puzzled as to why anybody would
want to run a 32 bit opsys on 64 bit hardware. I think they just sense a
lack of commitment from Microsoft. Incidentally, I heard that Microsoft
had a 64 bit version of NT (an early one 3.1 or 3.5) for the Dec Alpha
but never released it. They released a 32 bit version for the Alpha - so
everybody ran Tru64 unix instead. The attraction of 64 bit is address
space more than large physical memory. If you are mapping large files
the address space issue is significant. A windows 32 bit application can
get about 1.5GB of usable address space in an application and it is not
enough. I had better declare my bias; I implement an APL interpreter. A
significant number of my users are bouncing off address space
restrictions and are being held back because their users are constrained
to use 32 bit windows as a platform.
Geoff Streeter
Geoff Streeter
Funny, my view is the exact opposite. I first used 64 bit on a Dec AlphaOn Fri, Mar 7, 2008 at 5:24 PM, Mark Knecht <[email protected]> wrote:
Not emulation libraries. They're plain old 32 bit libraries.For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries.
Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.
No problem. We don't need symbols there.Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?
Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan
in about 1993. I have been wondering ever since why anybody would want
to cling to 32 bit. Recently I have been puzzled as to why anybody would
want to run a 32 bit opsys on 64 bit hardware. I think they just sense a
lack of commitment from Microsoft. Incidentally, I heard that Microsoft
had a 64 bit version of NT (an early one 3.1 or 3.5) for the Dec Alpha
but never released it. They released a 32 bit version for the Alpha - so
everybody ran Tru64 unix instead. The attraction of 64 bit is address
space more than large physical memory. If you are mapping large files
the address space issue is significant. A windows 32 bit application can
get about 1.5GB of usable address space in an application and it is not
enough. I had better declare my bias; I implement an APL interpreter. A
significant number of my users are bouncing off address space
restrictions and are being held back because their users are constrained
to use 32 bit windows as a platform.
Geoff Streeter
Geoff Streeter
What constitutes a good backtrace?
Geoff Streeter <[email protected]> wrote:
payoff for desktop users in the switch to 64 bits that it seems
premature, at least for people who don't want to help ferret out
the remaining problems.
average desktop user doesn't.
- Dan
Abstractly, I agree. But there are so many gotchas and so littleFunny, my view is the exact opposite. I first used 64 bit on a Dec Alpha
in about 1993. I have been wondering ever since why anybody would want
to cling to 32 bit.
payoff for desktop users in the switch to 64 bits that it seems
premature, at least for people who don't want to help ferret out
the remaining problems.
Sure, your users have a real reason to go 64 bits. TheI had better declare my bias; I implement an APL interpreter. A
significant number of my users are bouncing off address space
restrictions and are being held back because their users are constrained
to use 32 bit windows as a platform.
average desktop user doesn't.
- Dan