official Watch_Dogs

[spaceelf]

The article you linked says you have approximately the same amount of handle limits for a process (i.e. per application) whether 32bit or 64bit Windows. Why would a game ever be allocating 16 million event handles anyway  :huh: (or many Windows Event handles at all for that matter)? The article itself even says that you would exhaust your physical resource limits before you reached the handle limit anyway (in the same way as GDI handle leaks do).

I know.  The question remains whether an OS/app can actually use all that with stability.  The article I can't find (perhaps it was removed, perhaps it isn't relevant anymore with Windows 7 and 8, who knows) IIRC implied that there was a point things would become unstable whether it was at the limit or not.

 

Since I can't find it...that's that.

[snaphat (Myles Landwehr) Member]

I know.  The question remains whether an OS/app can actually use all that with stability.  The article I can't find (perhaps it was removed, perhaps it isn't relevant anymore with Windows 7 and 8, who knows) IIRC implied that there was a point things would become unstable whether it was at the limit or not.

 

Since I can't find it...that's that.

 

I think the article you are referring to probably says the following: an application can't use the maximum amount of handles with stability under normal circumstances because it would cause the system to physically run out of memory; so you reach an out of memory state and can't recover gracefully. So, yes there is a point where things become unstable before reaching the handle limits -- the limit of physical resources.

[spaceelf]

I think the article you are referring to probably says the following: an application can't use the maximum amount of handles with stability under normal circumstances because it would cause the system to physically run out of memory; so you reach an out of memory state and can't recover gracefully.

No, it doesn't.

 

I am aware my information isn't defendable without the source text.

[Andre S. Veteran]

People still use GDI? :whistle:

People still use XP  :pinch:

[snaphat (Myles Landwehr) Member]

No, it doesn't.

 

You implied that you weren't sure what it said and now you are suddenly sure what it doesn't says  :laugh: I was giving you a logical basis for what it definitely could refer to based on what you said you thought it said. It wouldn't surprise me one bit if it actually did, given that the article you did link and articles I have found do say that

[spaceelf]

You implied that you weren't sure what it said and now you are suddenly sure what it doesn't says  :laugh:

I am not sure what it said with 100% certainty, as I don't have it in front of me.

 

I am sure what it didn't say.

 

Not quite the same thing.

[snaphat (Myles Landwehr) Member]

I am not sure what it said with 100% certainty, as I don't have it in front of me.

 

I am sure what it didn't say.

 

Not quite the same thing.

 

True that. This is off topic but that reminded me of this funny clip: http://www.youtube.com/watch?v=_w5JqQLqqTc. Love that show :-)

[The_Decryptor Veteran]

People still use XP  :pinch:

Heh, if only it was that easy. In a perfect world an application could use pure Direct2D/Direct3D for their UI, but there's no comparable common controls/themeing API for it, everything still relies on GDI (Wouldn't it be nice if uxtheme could draw directly to a D2D RT? Or having common controls that integrated into a UI scene graph, etc.)

Microsoft have been of the whole "2 minds" thing for a while, some of their teams love .NET/XAML/etc. (Server guys, Tablet guys), others love stuff like Direct2D (Office, IE), while the shell guys still seem to be stuck in GDI land, there's barely integration between all the different environments. So now we have a situation where we have Vista/7/8/8.1 all having hardware accelerated 2D/3D drawing libraries as the standard, and the desktop environment is stuck using APIs written for Windows 3 and anybody wanting to use the new APIs has to write everything themselves (Like Firefox drawing theme elements to GDI surfaces and uploading them to the GPU for rendering, instead of having them implemented as shaders on the GPU, etc.).

[MorganX]

Heh, if only it was that easy. In a perfect world an application could use pure Direct2D/Direct3D for their UI, but there's no comparable common controls/themeing API for it, everything still relies on GDI (Wouldn't it be nice if uxtheme could draw directly to a D2D RT? Or having common controls that integrated into a UI scene graph, etc.)

Microsoft have been of the whole "2 minds" thing for a while, some of their teams love .NET/XAML/etc. (Server guys, Tablet guys), others love stuff like Direct2D (Office, IE), while the shell guys still seem to be stuck in GDI land, there's barely integration between all the different environments. So now we have a situation where we have Vista/7/8/8.1 all having hardware accelerated 2D/3D drawing libraries as the standard, and the desktop environment is stuck using APIs written for Windows 3 and anybody wanting to use the new APIs has to write everything themselves (Like Firefox drawing theme elements to GDI surfaces and uploading them to the GPU for rendering, instead of having them implemented as shaders on the GPU, etc.).

 

Kinda OT, but if you know this, why doesn't any senior or executive management and Microsoft know it and see that it gets rectified?

[spaceelf]

Kinda OT, but if you know this, why doesn't any senior or executive management and Microsoft know it and see that it gets rectified?

WinRT actually does change things, just not sure what it does for the desktop environment (I'm told you can use it for desktop apps, but I don't know much about that.)

 

Course, it's still only for the new OSes so unlikely to be picked up by too many apps.

[Andre S. Veteran]

Heh, if only it was that easy. In a perfect world an application could use pure Direct2D/Direct3D for their UI, but there's no comparable common controls/themeing API for it, everything still relies on GDI (Wouldn't it be nice if uxtheme could draw directly to a D2D RT? Or having common controls that integrated into a UI scene graph, etc.)

Microsoft have been of the whole "2 minds" thing for a while, some of their teams love .NET/XAML/etc. (Server guys, Tablet guys), others love stuff like Direct2D (Office, IE), while the shell guys still seem to be stuck in GDI land, there's barely integration between all the different environments. So now we have a situation where we have Vista/7/8/8.1 all having hardware accelerated 2D/3D drawing libraries as the standard, and the desktop environment is stuck using APIs written for Windows 3 and anybody wanting to use the new APIs has to write everything themselves (Like Firefox drawing theme elements to GDI surfaces and uploading them to the GPU for rendering, instead of having them implemented as shaders on the GPU, etc.).

WPF was supposed to be the answer to that; it was this entirely Direct3D-based GUI toolkit that should have replaced WinForms/MFC/ATL, but Microsoft has failed to evolve it. WPF should currently use DirectComposition/Direct2D/D3D11, but it's stuck in the past with a terribly slow Direct3D9 implementation. WPF is the bastard child of the WinFX debacle and was too little, too late.

[The_Decryptor Veteran]

Problem with WPF was that it's based on managed code, which the shell team hates (Based on what I've heard). And Longhorn in it's original incarnation was a huge failure (I remember playing around with the early builds, they had better .NET integration than we do currently)

As an example, Direct2D and DirectWrite, they're based (Even if it's the design only) off the WPF counterparts (DirectWrite being an even better font render than WPF uses), but there's just no integration into the existing unmanaged APIs. The best you can do is make a "GDI Compatible" render target that lets you draw GDI resources to a Direct2D RT and then upload it to the GPU (Which is exactly what Firefox does, etc.), but there's no support for native rendering of theme elements to D2D (Ideally you'd want a vector version of the theme that can be drawn on the GPU, which is exactly what WPF did, but there's no counterpart for unmanaged apps), and there's no native D2D rendered controls. If you wanted a native interface drawn with D2D you'd either have to superclass the common controls to force them to render into a GDI/D2D RT, or recreate every single element, which is great for compatibility.

I would love to see more work put into WPF (Like basing it on D2D/D3D11 as you said), but it seems to have fallen by the roadside in favour of WinRT, but that's limited currently to Metro apps, which goes back into my argument of Microsoft not knowing what to focus on.

Also, how'd we get from a game to this subject?

Edit: Also, problem with Microsoft is that they often have internal "not invented here", teams work against each other, rather than with each other.

[MorganX]

Edit: Also, problem with Microsoft is that they often have internal "not invented here", teams work against each other, rather than with each other.

 

Excellent. That I understand. That is a management problem, not a programmer problem. The question is, does anyone in management know this problem exists? And do they have the backbone and authority to deal with it?

[neoadorable]

Hope you got your PS4 at least by now man, love this device, great machine and evolution!

 

I'll get them but just not right away.   At best I might get one for Christmas and the other later in February.  

[neoadorable]

in the end Hawk and others were right, the launch is great, love the PS4 so far, though no X1 for me for the time being. Very tempted by Wii U. And there are more than enough titles this season, that is for sure.

[PGHammer]

Can you back your claim of stability/robustness advantages up with some citations and specifics? As far as I know, there is nothing in the x64 portions of the ISA that would yield advantages in these areas. The only effective differences in the modes from a practical standpoint is that you have larger/more registers, can address more memory, and you have some additional x86_64 specific instructions.

 

Unless you are talking about security advantages in terms of ASLR, I don't see any inherent reason why 64-bit OSes would be at a stability advantage. I've honestly never heard of anyone suggesting that x64 OSes are inherently more stable before.

 

I refer to stability in terms of fewer crashes, not necessarily less vulnerable to outside forces - oddly enough, the primary reason FOR that increased stability is what you just stated - better memory management.  Browsers and productivity applications are even better examples than operating systems - the biggest driver behind moving who I support - and myself - to x64 was fewer crashes in web browsing and productivity applications (such as Office) -  not gaming.

However, there's an advantage in terms of security that is unique to x64 - and it's a CPU hardware feature that operating systems can leverage.  Had we forgotten about NX (No eXecute)? NX is old; it's also pretty much ubiquitous; while Intel played it up with their first x64 CPUs, AMD supports NX as well (Opteron and all of its progeny, including AMD's Fusion APUs of today).  While x32 operating systems can leverage PAE, that's not the case for NX - that is x64-only on the OS side. However, memory management is the biggest advantage - especially below 4 GB on the OS side.

 

Memory management in x32 has a ton of backward-compatibility built into it - for ease-of-transition reasons; remember, developing for even x32 was heavily resisted initially. However, all that ease-of-transition backward compatibility stuff baked into x32 has become a lead weight - a liability instead of an asset.  (Reminds me a lot of the Flash vs. HTML argument - for everything from Web pages to application and e-commerce front ends.)  Memory management in x64 is almost completely different from the bottom up - I would ask you to compare Firefox to the two most popular x64 iterations of the same code - Waterfox and Pale Moon.  (The very reason I included both Waterfox and Pale Moon is that the two browsers - while both are x64 - take different approaches from each other - let alone from what the Mozilla Foundation took on the x32 side.  When a true Win64 version of Mozilla Firefox arrives, add it to the comparison.)  There is STILL a lot of R&R when it comes to development; I'm not referring to "rest and relaxation", but "resistance and recalcitrance" - it's a "creature of humanity" that I doubt we will ever succeed in making endangered, let alone extinct.

[snaphat (Myles Landwehr) Member]

I refer to stability in terms of fewer crashes, not necessarily less vulnerable to outside forces - oddly enough, the primary reason FOR that increased stability is what you just stated - better memory management.  Browsers and productivity applications are even better examples than operating systems - the biggest driver behind moving who I support - and myself - to x64 was fewer crashes in web browsing and productivity applications (such as Office) -  not gaming.

 

I wasn't saying that x64 OSes have better memory management, I was simply saying that you have a larger address space available. Given the same amount of resources, you'd actually run out of resources quicker on a 64-bit OS because pointer sizes are larger so effectively by your definition of stability, an x64 OS would be less stable given the same amount of resources. In any case, OoM states aren't stability issues (Athernar pointed this out earlier in the thread). If the OS is completely depleted of resources it will simply have to cut programs until there is memory available for it to operate or for other programs that request memory. It's simply a resource mitigation issue.

 

However, there's an advantage in terms of security that is unique to x64 - and it's a CPU hardware feature that operating systems can leverage.  Had we forgotten about NX (No eXecute)? NX is old; it's also pretty much ubiquitous; while Intel played it up with their first x64 CPUs, AMD supports NX as well (Opteron and all of its progeny, including AMD's Fusion APUs of today).  While x32 operating systems can leverage PAE, that's not the case for NX - that is x64-only on the OS side. However, memory management is the biggest advantage - especially below 4 GB on the OS side.

 

Sure, a hardware NX bit has security advantages over software DEP, it had slipped my mind when I mentioned ASLR in my original post. The point there was that unless you were talking about security advantages, I don't see where you are getting 64-bit OSes are inherently more stable. The only advantages that you could construe as stability advantages are security related.

 

Memory management in x32 has a ton of backward-compatibility built into it - for ease-of-transition reasons; remember, developing for even x32 was heavily resisted initially. However, all that ease-of-transition backward compatibility stuff baked into x32 has become a lead weight - a liability instead of an asset.  (Reminds me a lot of the Flash vs. HTML argument - for everything from Web pages to application and e-commerce front ends.)  Memory management in x64 is almost completely different from the bottom up ...

 

I really haven't the foggiest what you are talking about in the text I bolded or why it would affect system stability. The only effective differences I know of at the OS level is what MS says at these links: http://support.microsoft.com/kb/294418; http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

 

...  I would ask you to compare Firefox to the two most popular x64 iterations of the same code - Waterfox and Pale Moon.  (The very reason I included both Waterfox and Pale Moon is that the two browsers - while both are x64 - take different approaches from each other - let alone from what the Mozilla Foundation took on the x32 side.  When a true Win64 version of Mozilla Firefox arrives, add it to the comparison.) 

 

How is this text related to the discussion of 64-bit vs 32-bit OS stability? The best I can surmise is that you are mentioning the software because:

• they use out of process plugin execution to prevent the entire browser from crashing (similar to chrome).
• they use x86_64 instructions for x64 builds like all x64 software.
• they use different optimization switches from normal firefox.

None of that stuff is related 64-bit vs 32-bit OS stability so you are going to have be more specific here as to why the browsers are relevant to the discussion...

 

There is STILL a lot of R&R when it comes to development; I'm not referring to "rest and relaxation", but "resistance and recalcitrance" - it's a "creature of humanity" that I doubt we will ever succeed in making endangered, let alone extinct.

 

What? :rolleyes:

[The_Decryptor Veteran]

...

However, there's an advantage in terms of security that is unique to x64 - and it's a CPU hardware feature that operating systems can leverage.  Had we forgotten about NX (No eXecute)? NX is old; it's also pretty much ubiquitous; while Intel played it up with their first x64 CPUs, AMD supports NX as well (Opteron and all of its progeny, including AMD's Fusion APUs of today).  While x32 operating systems can leverage PAE, that's not the case for NX - that is x64-only on the OS side. However, memory management is the biggest advantage - especially below 4 GB on the OS side.

 ...

What? That's not the case at all.

Edit: Oh, and 64bit Firefox for Windows is less stable than the 32bit release, along with other issues. That's why Mozilla don't have it as an official release, not because of any ideological reasons or whatever else people like to claim.

[snaphat (Myles Landwehr) Member]

What? That's not the case at all.

 

Correct me if I'm wrong, but I do think the hardware supported version of an NX bit is x64 only. OSes had similar similar concept for marking executable/non-executable pages prior to that bit being in hardware though and you are probably thinking of that. 

 

EDIT: Oh wait, you are probably referring to what he said about PAE not being able to use the NX bit. Yeah, he's entirely wrong about that. I wasn't paying attention to that when I replied to him.

[The_Decryptor Veteran]

AMD tied the NX bit to their 64bit CPUs, but Intel didn't (Although not in a way that really matters), they first introduced it in a series of Celeron processors that were 32bit only, then introduced support for it across the board with the introduction of their 64bit CPUs.

But meh

The actual way to access it is through extended bits on the page table, which you get under 64bit and PAE, and Windows runs in PAE mode by default.

[snaphat (Myles Landwehr) Member]

AMD tied the NX bit to their 64bit CPUs, but Intel didn't (Although not in a way that really matters), they first introduced it in a series of Celeron processors that were 32bit only, then introduced support for it across the board with the introduction of their 64bit CPUs.

But meh

The actual way to access it is through extended bits on the page table, which you get under 64bit and PAE, and Windows runs in PAE mode by default.

 

Yup, I just wasn't reading closely enough what PGHammer actually wrote :)

[PGHammer]

I wasn't saying that x64 OSes have better memory management, I was simply saying that you have a larger address space available. Given the same amount of resources, you'd actually run out of resources quicker on a 64-bit OS because pointer sizes are larger so effectively by your definition of stability, an x64 OS would be less stable given the same amount of resources. In any case, OoM states aren't stability issues (Athernar pointed this out earlier in the thread). If the OS is completely depleted of resources it will simply have to cut programs until there is memory available for it to operate or for other programs that request memory. It's simply a resource mitigation issue.

 

 

Sure, a hardware NX bit has security advantages over software DEP, it had slipped my mind when I mentioned ASLR in my original post. The point there was that unless you were talking about security advantages, I don't see where you are getting 64-bit OSes are inherently more stable. The only advantages that you could construe as stability advantages are security related.

 

 

I really haven't the foggiest what you are talking about in the text I bolded or why it would affect system stability. The only effective differences I know of at the OS level is what MS says at these links: http://support.microsoft.com/kb/294418; http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

 

 

How is this text related to the discussion of 64-bit vs 32-bit OS stability? The best I can surmise is that you are mentioning the software because:

• they use out of process plugin execution to prevent the entire browser from crashing (similar to chrome).
• they use x86_64 instructions for x64 builds like all x64 software.
• they use different optimization switches from normal firefox.

None of that stuff is related 64-bit vs 32-bit OS stability so you are going to have be more specific here as to why the browsers are relevant to the discussion...

 

 

What? :rolleyes:

I'm saying that all people are not exactly fans of changing how they do things - the difference is how changes are dealt with/accepted.  Rather amazingly, the further up the ladder you go, the more resistance and recalcitrance (not less) you run into - or has it not been pointed out that managers are more resistant/recalcitrant than those they manage?  As much as the issue here is IT (and gaming in particular), it's far from unique to gaming, or IT - hence my referring to it as a "creature of humanity", because such resistance and recalcitrance is about everything.

 

The only real difference is in degree.

[PGHammer]

What? That's not the case at all.

Edit: Oh, and 64bit Firefox for Windows is less stable than the 32bit release, along with other issues. That's why Mozilla don't have it as an official release, not because of any ideological reasons or whatever else people like to claim.

Actually, the issue for Firefox (and it's still a problem for Pale Moon and Waterfox) is a lack of fully x64 plug-ins (no non-beta x64 Flash plug-in, for example - for other common plug-in types, there's not even that for any browser - even IE).

And I never said that it was an ideological issue for Mozilla - the plug-in problem is quite valid.  (Remember, even though IE x64 is the most common of the x64 browsers, how many x64 plugins or AX controls are there for even it?)  I have referred to the plug-in problem as the equivalent of an "x32 jail", while others (in Neowin's Browser Forum) are far less charitable.

[The_Decryptor Veteran]

Well, Mozilla could do a 32bit plugin with a 64bit browser host, but it's hard (Unlike OS X, you can't have 2 different architectures in a single binary) and even then it's only a compatibility shim (The proper solution to 32bit plugins with a 64bit host is to replace them with 64bit plugins)

And yes, there are stability issues, for the longest time 64bit Firefox didn't have a crash reporter due to differences in the 64bit API, so people using the 64bit nightly just didn't report crashes, the printing code used 32bit pointers instead of the right length ones, etc.

Edit: IE runs in 32bit mode by default, that'd be a big reason why people don't make 64bit plugins for it. Same as WMP and codecs.

[snaphat (Myles Landwehr) Member]

I'm saying that all people are not exactly fans of changing how they do things - the difference is how changes are dealt with/accepted.  Rather amazingly, the further up the ladder you go, the more resistance and recalcitrance (not less) you run into - or has it not been pointed out that managers are more resistant/recalcitrant than those they manage?  As much as the issue here is IT (and gaming in particular), it's far from unique to gaming, or IT - hence my referring to it as a "creature of humanity", because such resistance and recalcitrance is about everything.

 

The only real difference is in degree.

 

Sure, but I still don't understand how this is related to 64-bit vs 32-bit stability at the architecture level. Just because Mozilla has a more stable build one way or the other; or has resistance in moving to a native 64-bit build, doesn't mean there are inherit stability differences at the architectural level.