Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Pretending this was a political decision (vs just being what the Windows hackers decided to use their time on)...

Let's tally the arguments so far for prioritizing 64-bit Windows development.

Pro: The Ars article lists some Win64-specific security-bug mitigation features, unclear how significant these are.

Con: The Windows PC is a declining platform, and the current 32-bit product covers all of the platform currently. There's probably a shortage open source developers working on Windows-specifics. 32-bit is much more memory-efficient. 64-bit breaks compatibility with plugins. Address space shortage will likely be covered by the tab unloading feature mentioned in the article, before it becomes an issue in practice.

Overall sounds to me like You Ain't Gonna Need It.



The Windows PC is a declining platform

It's difficult to be rising when you start at 95%.

Nevertheless a great majority of users access the Internet via a computer running Windows and it will remain the case for a long while.


I would have assumed it's declining in terms of market share (driven down by tablets/Mac/Linux) but there's a surprisingly large absolute drop coming as well:

"Researchers IDC and Gartner Inc. said PC shipments in the third quarter fell more than 8% from a year earlier, the steepest drop since at least 2001." ( http://online.wsj.com/article/SB1000087239639044465780457804... )


A drop in sales doesn't imply a drop in usage, though. Perhaps PCs are merely lasting longer before needing to be replaced?


> It's difficult to be rising when you start at 95%.

When just about every PC is sold with Windows, one would expect its market share to, at least, remain constant.


It is my understanding that the Mac gained significant market shares and that on mobile devices Windows isn't predominant.


Not if other platforms grow faster than it i.e. Smartphones or Tablets.


> The Windows PC is a declining platform...

That must be the reason I get am getting more .NET contracts than Java ones I suppose.


Yes, its triumph over the Java Desktop has been impressive.


Yup. It's the declining platform of today, while Java is the declining platform of five years ago.


> That must be the reason I get am getting more .NET contracts than Java ones I suppose.

The kind of contracts you have is entirely dependent on your skill set and your network. The last time I was paid to write C# code was 8 years ago.

You need cooler friends ;-)


Lets put this way then.

Our consulting company does mostly Fortune 500 and DAX 30 customers.

After 5 years of almost only Java projects, most of the new contracts are coming from .NET land.

Better explained?


I work for several very large telcos and I have been, so far, able to avoid both .NET and Java. Last time I wrote C# code was because Microsoft (then a client) demanded we run our application on a Windows server. I wrote a proxy that sat in front of the application (which ran on a Linux machine).

Again, you need cooler friends.


> Again, you need cooler friends.

The ones I have keep my account manager very happy.


>Address space shortage will likely be covered by the tab unloading feature mentioned in the article, before it becomes an issue in practice.

before? I've seen Firefox run up against the 2gb limit[1] for years.

This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.

[1]: http://www.brianmadden.com/blogs/brianmadden/archive/2004/02...


Firefox runs in 3GB, so it leaves 1GB for the kernel and uses 3GB for itself.


Only if you enable the 3GB switch for Windows. Or on 64-bit Windows where FF gets 4 GiB, then.


32-bit Windows (with the 2GB limit) couldn't run the 64-bit Firefox in any case, so in the context of this discussion the 32-bit build is always getting 4GB of address space.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: