[Wine] What constitutes a good backtrace?

[Geoff Streeter]

Alan McKinnon wrote:
> On Monday 10 March 2008, Dan Kegel wrote:
>   
>> Geoff Streeter <geoff at dyalog.com> wrote:
>>     
>>>  Funny, 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.
>>>       
>> Abstractly, I agree.  But there are so many gotchas and so little
>> 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.
>>
>>     
>>> 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.
>>>       
>> Sure, your users have a real reason to go 64 bits.  The
>> average desktop user doesn't.
>>     
>
> I have to say that I am with Dan on this one. Off the top of my head, I 
> can't think of any *desktop* app that requires the full addressing 
> capabilities of 64 bit. Come to think of it, I can't think of any 
> desktop or notebook *machines* that have more than 4G of RAM installed. 
> Plus, there are a whole slew of desktop apps that just don't work right 
> on 64bit systems - starting with flash.
>
> In the general case on x86 cpus, 64bit desktops tend to supply the user 
> with a whole large set of brand new shiny problems while solving no 
> existing ones. There are always exceptions of course - sometimes I 
> would like to demo two certain column-based database and an abstraction 
> layer along with reporting tools, ETL stuff and have the whole lot 
> delivered to the user from JBoss. Sadly, this lot will never run on a 
> notebook, so the demo consists of dragging several machines in boxes 
> off to the client's premises. But that's an obscure case...
>
> Servers - different story. I'm very close to the point where I simply 
> will not support new apps deployed on new 32 bit systems. Current needs 
> in *this* area for the majority of customers I have to deal with 
> already go beyond what 32 bit can deliver.
>
> This isn't to say that there is something wrong with 32 bit code - there 
> isn't. It's just that the code lying around for desktop use is written 
> for 32 bit and also satisfies current and foreseeable future needs.
>
>
>
>   
I don't think history supports this view. If my memory serves, and I am 
old enough for it to be unreliable, Bill Gates in the mid '80s said 
"640K is enough for anyone", then a combination of the 80386, Pharlap 
and Metaware High C made the statement seem stupid. There is a sort of 
corollary to Moore's Law that means that the memory requirements of 
applications grow at about a factor of 2 every 18 months. So that 640K 
can now be multiplied by 2^16 ish. This is approximately 4GiB. Most 32 
bit opsys deliver about 2GiB of address space to the program. By 
fiddling a bit you can get some more (on AIX up to more than 3GiB). So I 
would argue that we are already at or about the limit of 32 bit address 
space for applications.

I have not noticed the problems with 64 bit that are described. I use 
XP64 at work and the only real problem has been that some apps come with 
16bit installers which won't run. I have to be a bit selective with 
hardware to ensure that I get 64 bit drivers. I  have to be a bit 
selective with hardware for Linux for similar reasons, this is much less 
true than it used to be. I use AIX, Solaris(SPARC) and a few Linux 
distributions, none of them have given me any issues about running 32 
bit apps on 64 bit opsys. These things were sorted out by the AIX and 
Solaris guys in the 1990s. Applications written for Microsoft Windows 
are more suspect. I got an MSDN library that refused to use the 64 bit 
version of IE, I had to force it to use the 32 bit version. We have put 
Vista64 on laptops that then did horrible things on hibernation. 64 bit 
Linux has been fine.

Dig around the net for the growth rates of share trading quotes. There 
is an APL like language called K that targets this area. They will scare 
you. I accept that the share trading markets are lunatic and these sorts 
of growth rates only demonstrate that lunacy. However, there are real 
systems that target these environments and have to handle those data 
volumes.

I repeat my comment that 64 bit is about address space rather than real 
memory so the present boundary of 4GiB imposed by motherboards aimed at 
desktops and laptops is not an argument for sticking with 32 bit. This 
is not to say that real memory is not important. We have customers with 
96GiB of real. Those motherboards will be hosting 16GiB in two years 
time and our customers will be using machines with 256GiB by then.

Keeping this on topic for this list; I am really looking forward to a 64 
bit winelib.

Geoff Streeter