Main Area and Open Discussion > Living Room

64 Bit OS - When to Switch ?

<< < (4/10) > >>

Stoic Joker:
The only compatibility issues I have come across are clients with ancient peripherals (usually printers and scanners).-Carol Haynes (July 08, 2011, 04:43 AM)
--- End quote ---

Add to the the kernel/user mode drive debacle and you drop even more devices on the x86 editions also. I don't know if it's laziness, greed, or both on the part of the manufacturers...But I'm getting tired of having to have that conversation with people because their 2yr old high dollar print device just flat don't work on their new machine. Mac ain't exempt either, their (probably the worse) compatible devices list isn't much more than a single page long these days.

Go to any manufacturer's site these days and try to find a 32-bit machine, it ain't easy. Or even possible for some unless by special (phone in and beg) request.

The only reason I didn't do a full-time switch to XP x64 back when was I couldn't bear to part with TClock ... But that got fixed shortly there after... ;) ...The instant I had a semi-stable alpha (carrot, stick...) I made the switch.

worstje:
Here is the catch: the amount of memory available for the stack is the same in 32-bit and 64-bit Windows, but the stack entries are twice as long on 64-bit Windows. Hence the usable window hierarchy depth is halved. And if you think that you can avoid the problem by using 32-bit edition of the affected application on 64-bit Windows, that is not the case. The problem is in the 64-bit kernel. The worst thing is that Microsoft refuses to consider this a bug and fix it (unless they changed their mind since the last time I checked).-vlastimil (July 08, 2011, 04:06 AM)
--- End quote ---

I never ran into this issue, and I do not believe it is any problem. If anything, window handles (which are the things you are referring to, I believe) have only gone up in the supported amounts, and the last time a scarcity of that resource was an issue was back in the W9x days. If you refer to the Z-order that defines what is drawn on top of what, I do not believe there is any sane limitation on that either.

I dare say, if you run into issues with the amounts of resources Windows makes available for a specific purpose, you are abusing that as a developer and without a doubt can find a more suitable solution. For example, there are tons of windowless controls that are considered lightweight because they do not use any Windows resources, and instead co-opt the help of their parent control that do have a handle.

So...if you do not want unexpected problems, switch to 64-bit Windows when you HAVE A REASON to, not when there seem not to be a reason not to.-vlastimil (July 08, 2011, 04:06 AM)
--- End quote ---

I remain with my advice to switch now, with now being defined as 'the point where you end up (re)installing Windows'. The last we all need are people holding on to phantom reasons not to switch (because they read something on the internet at some point)... and we all know how that worked out for Windows Vista (even though there were a few good reasons, a lot of it was hot air and bad press).

The only pre-requisite is that your hardware is from the last ~5 years, which is a decent enough expectation if you intend to run Windows 7.

vlastimil:
@vlastimil I disagree that this is a actual issue affecting many end users.
-justice (July 08, 2011, 04:29 AM)
--- End quote ---

maybe not many, but it affects some users/applications
http://stackoverflow.com/questions/386826/what-could-cause-redraw-issues-on-64-bit-vista-but-not-in-32-bit-in-net-winforms

I never ran into this issue, and I do not believe it is any problem. If anything, window handles (which are the things you are referring to, I believe) have only gone up in the supported amounts, and the last time a scarcity of that resource was an issue was back in the W9x days. If you refer to the Z-order that defines what is drawn on top of what, I do not believe there is any sane limitation on that either.

I dare say, if you run into issues with the amounts of resources Windows makes available for a specific purpose, you are abusing that as a developer and without a doubt can find a more suitable solution. For example, there are tons of windowless controls that are considered lightweight because they do not use any Windows resources, and instead co-opt the help of their parent control that do have a handle.
-worstje (July 08, 2011, 07:54 AM)
--- End quote ---

This is not about the number of window handles. It is about recursive window message processing - parent window receives WM_SIZE, sends WM_SIZE to its children, etc. (it is more complex in reality, there are more messages being sent)
Even native Windows controls use this kind of aggregation. List box has a Header control as its child, Combo box has an Edit box as a child. A toolbar can host a combo box (with an edit box inside) and be hosted in a Rebar. These are 4 levels of depth and we are still talking just about a toolbar. That toolbar is hosted within the application frame. Now add a tab or a splitter control and the depth grows. The depth limit on 64-bit windows is pretty shallow, like ~12. If you use .net winforms and make a tab/splitter hierarchy, you can experience this yourself.

Window-less controls can help, but it is a pain to use them. They are not the easy-to-use blackbox that a window is. But this is not the main issue here. The fact that the 64-bit system is worse than the 32-bit one in this aspect. And there may be more catches like this one.

The memory: first, determine if you need it. Do you want to work with really hi-res video or a large database? By all means get a lot of memory, 64-bit Windows AND a 64-bit edition of the software. Do you just browse the internet, use office and play games? You'll be better off with 4GB and 32-bit for the next few years.

Also...there are artificial limits on how much memory a 64-bit Windows allows you to use http://en.wikipedia.org/wiki/Windows_7#Physical_memory_limits

Renegade:
There is a 32-bit mode that you can toggle.



I can't see why anyone would want to go with a 32-bit OS now. Unless there are some very real and immediate reasons...

Eóin:
That release was in the same league as the Win32 subsystem on Windows 3.11: Total crap, with near to none support from applications or drivers.
It's sister-release Windows Server 2003 x64 edition was a little better (read: less worst) as there was actual hardware-driver support from the larger (server) vendors, but generic consumer-stuff was, as to be expected, a total disaster.
-Ath (July 08, 2011, 04:42 AM)
--- End quote ---

Well I had no difficulty getting drivers for all my hardware, but I accept I may have been lucky and that in general x64 drivers were few and far between back then. The OS itself though was for me absolutely rock solid, and as I understand it, it was Server 2003 x64 under the hood, but with the server applications stripped out and XP media-ish apps put in.

@vlastimil I'm not sure about that specific issue you mention, though the link you posted (and the linked msdn blog post) does sound reasonably scary. In general the move to 64bit has vastly improved the various resource limits available to applications (see these blog posts), so if anything going by that measurement, 64bit is more compatible than 32bit Windows.

I fully accept that things like 16bit applications or 32bit shell extensions might not work, but these days I firmly believe that the ordinary user should default to 64bit and only consider 32bit in exceptional circumstances. As anecdotal evidence, when purchasing laptops over the last year I noticed it's nearly, if not actually, impossible to buy a €400+ machine that doesn't come without 64bit pre-installed.

Navigation

[0] Message Index

[#] Next page

[*] Previous page