Recommended Posts

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.

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.

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.

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

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.

  • Like 1

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 :-)

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.).

  • Like 1

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?

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.

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.

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.

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?

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.

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/294418http://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:

...

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.

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.

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.

  • Like 1

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 :)

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/294418http://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.

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.

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.

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.

This topic is now closed to further replies.
  • Posts

    • Google is opening the world's first AI museum in Los Angeles by Ivan Jenic Image via: Google Ever since AI image generators went mainstream, the debate over whether AI-generated art is real art hasn't let up. Those who don’t consider AI to be art say that if a machine does the creating and anyone can prompt it, there’s no skill involved, and therefore no art is produced. The counter-argument is equally persistent, as defenders of AI-generated artworks often claim that AI is just a tool, and that every major technological breakthrough, like the camera or the computer, was met with the same skepticism before eventually being accepted as a legitimate creative medium. Google’s position in this debate is clear. Which is no surprise, as the company is investing billions in AI infrastructure. And now, in efforts to encourage people to use its AI even more, Google is opening Dataland on June 20, which it's calling the world's first AI arts museum. Located inside The Grand LA, a Frank Gehry-designed building in Los Angeles, the museum spans 25,000 square feet. The museum is built around a collaboration with media artist Refik Anadol, who has worked with Google since 2016. The inaugural exhibition is called Machine Dreams: Rainforest, and is powered by an AI model trained on “an extensive dataset of the natural world.” It generates 1.2 billion pixels of visuals in real time and reacts to visitors dynamically. The space also generates soundscapes, real-time emotion sensing, and algorithmically produced scents. Image via: Refik Anadol Studio / Google Google says that the museum is powered by its Gemini models, which run on Google Cloud. So, everything is generated inside one of Google’s AI data centers and is streamed to the museum. Alongside the museum opening, Google Arts & Culture is funding an AI Artist Residency, giving four artists $25,000 grants each, along with mentorship from Refik Anadol Studio and access to Google's machine learning tools. Their work will be shown at Dataland and on the Google Arts & Culture website later this year. Google’s AI museum will undoubtedly initiate a fired-up debate on social media, and we can’t wait to see the first reactions. Via: Smithsonian Magazine
    • Calling GTA 6 overhyped crap doesn’t make you edgy, it just makes you sound like someone who hasn’t enjoyed anything since the PS2 era.
    • I’m not arguing whether Rockstar likes money. Obviously, they do, they’re a business. I’m saying this isn’t new. They’ve always launched console first. This is just how Rockstar operates.
    • I'm not sure how old the school is, but they've been doing this since GTA 3. Back in those days we'd be lucky for game companies to release on the PC at all. And with the current state of Sony (or Microsoft) their gaming wing won't be getting a penny from me.
    • We now know when and how the Universe may truly end by Sayan Sen Image by Marek Pavlík via Pexels| Not representative A study by physicist Henry Tye of Cornell University suggests that the universe may not expand forever. Instead, it could eventually stop expanding, begin contracting and end in a "Big Crunch" roughly 20 billion years from now. The research, published in the Journal of Cosmology and Astroparticle Physics, was conducted by Tye, Horace White Professor of Physics Emeritus at Cornell University. Using recent observations from major dark-energy surveys, Tye and his collaborators developed a cosmological model that predicts the universe could have a total lifespan of about 33 billion years. Since the universe is currently estimated to be 13.8 billion years old, the model places it near the midpoint of its existence. According to Cornell University's summary of the research, the study centers on the cosmological constant, a term introduced by Albert Einstein in his theory of general relativity. In modern cosmology, the cosmological constant is commonly used to describe the simplest form of dark energy, the unknown phenomenon believed to be driving the accelerating expansion of the universe. "For the last 20 years, people believed that the cosmological constant is positive, and the universe will expand forever," Tye said in a Cornell University news release. "The new data seem to indicate that the cosmological constant is negative, and that the universe will end in a big crunch." The study draws on data from the Dark Energy Survey (DES) and the Dark Energy Spectroscopic Instrument (DESI), two major projects designed to investigate the nature of dark energy. According to Tye, recent observations suggest that dark energy may not behave exactly like a simple cosmological constant. To account for those observations, Tye and his collaborators proposed a model involving an extremely light hypothetical particle that evolves over time. In their calculations, this produces a negative cosmological constant and leads to a future collapse of the universe. The model predicts that cosmic expansion would continue for approximately another 11 billion years before reaching a maximum size, after which the universe would begin contracting and eventually collapse. Scientists have long debated how the universe might end. As explained in an article published in The Conversation by Stephen DiKerby of Michigan State University, several possibilities have been proposed. If dark energy remains constant and positive, the universe could continue expanding indefinitely, gradually becoming colder, darker and more diffuse in a scenario often called the "heat death" of the universe. Other theoretical possibilities include a Big Rip, in which cosmic expansion accelerates so dramatically that galaxies, stars and even atoms are torn apart, or a Big Crunch, in which expansion reverses and the universe collapses back into an extremely dense state. DiKerby notes that the Big Crunch idea itself is not new. What distinguishes Tye's work is that it attempts to use current observational data to estimate when such a collapse might occur and how it could unfold. Much of the universe's long-term evolution remains uncertain. According to current astrophysical understanding, stars will continue to form and die for billions of years. The Sun, for example, is about halfway through its expected lifespan. Galaxies are also expected to continue merging; the Milky Way and Andromeda galaxies are projected to collide several billion years from now. At the same time, the nature of dark energy remains one of the biggest unanswered questions in cosmology. While observations indicate that the universe's expansion is accelerating, scientists still do not know what is causing that acceleration. Future observations may therefore alter current predictions about the cosmos's ultimate fate. Tye emphasized that additional evidence will be needed before firm conclusions can be drawn. DESI continues to collect data, while upcoming observations from missions and observatories including Euclid, SPHEREx and the Vera C. Rubin Observatory are expected to provide more precise measurements of dark energy. "People have said before that if the cosmological constant is negative, then the universe will collapse eventually. That's not new," Tye said. "However, here the model tells you when the universe collapses and how it collapses." For now, the study presents one possible future for the cosmos rather than a settled prediction. Whether the universe ultimately ends in a Big Crunch, expands forever, or follows another path entirely remains an open question that future observations will help answer. Source: Cornell University, The Conversation This article was generated with some help from AI and reviewed by an editor. Under Section 107 of the Copyright Act 1976, this material is used for the purpose of news reporting. Fair use is a use permitted by copyright statute that might otherwise be infringing.
  • Recent Achievements

    • First Post
      AndreaB earned a badge
      First Post
    • Week One Done
      Huge Trailer earned a badge
      Week One Done
    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
    • One Month Later
      eurospharma62 earned a badge
      One Month Later
    • Week One Done
      With What earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      570
    2. 2
      +Edouard
      175
    3. 3
      PsYcHoKiLLa
      73
    4. 4
      Michael Scrip
      68
    5. 5
      neufuse
      64
  • Tell a friend

    Love Neowin? Tell a friend!