Slashdot Mirror
64-Bit Windows Releases Now Available
SimplyJeff writes "Athlon 64 users rejoice! Today at WinHEC 2005 in Seattle, Microsoft announced availability of the 64-bit editions of Windows XP and Windows Server 2003. Strangely (and possibly a sign the drivers aren't yet up to snuff), Microsoft will not sell the 64-bit releases in retail outlets. For now, only new PC buys can get Windows x64 Edition as an option. However, those who purchased Windows XP after March 31, 2003, can trade in their copy for the 64-bit version at a cost of $12 and a voided warranty. Although, x64 users will get one free support call to Microsoft." Reader bonch adds a link to CNET's review of the OS.
Why the hell don't they just label it public beta, since it seems they want no one but a very select few to use it. This is more like a beta test then a product release ...
This signature was left intentionally blank.
How long before they hits the Warez, Is it me or does it seem like M$ is just shooting themselves in the foot by not selling it retail since many will seek "other" ways of obtaining the product?
From the summary:
Although, x64 users will get one free support call to Microsoft.
What on earth does that mean? Does a call to MS support cost so much that one free call is worth mentioning in the summary?
Or do they know that anyone using W64 will need to call MS support, or what?
If you have a 64-bit processor, here is your OS. I know people are going to get on here and talk about Linux supporting 64-bit a while ago and such, but this is Windows. They have moved to 64-bit. That means, us designers who like to use Photoshop or just play games (that don't run on linux that is) can finally put our 64-bit processor to some good use.
There is still going to be the lack of 64-bit programs for a while, but it's a start.
And in my opinion, the $12 trade sounds like a nice deal.
Cheers
P.S. No, I am not a Linux hater or w/e. I like linux, I like windows. I just use them for what each does best.
I think this is a good step forward. The actual performance improvements will likely be quite marginal until there are native 64-bit applications. Currently Windows XP and 2003 64-bit editions run 32-bit applications perfectly, but under an emulation layer called WoW (no not World of Warcraft, but Windows on Windows).
I'm not sure how many people remember this, but back when Digital Equipment Corporation's famed Alpha processor was "supported" by Windows NT, the 64-bit environment was infact not much more than a cheap hack. Microsoft designed Windows NT to not actually execute 64-bit instructions, but 32-bit instructions in parallel. I'm glad to see Microsoft is doing a better job supporting the AMD and Intel 64-bit processor lines.shop.envescent.com - Computer hardware and more.
But since all 64 bit programs must be reengineered anyway (ranging from a simple recompile to a partial rewrite depending on the code), is NX on by default for 64 bit programs (an off for Windows On Windows 32 (the layer that runs Win32 programs on Win64))? Seems like the opportune time to make that switch.
If companies can get drivers out soon for it, should be a relativly nice OS. Of course since this is just a different architecture in many ways this is less than a service pack (since nothing has changed featurewise except under the hood). Comparing it to Tiger wouldn't really be fair for that reason.
But going forward, it should be interesting to see performance differences as drivers mature. I'd love to see a performance comparaison in 6 months or so when things should be relativly good. And now that Windows is out, we should see more 64-bit programs which means better benchmarks for the difference between 32 and 64 bits in everyday tasks. The last big excuse for avoid 64 bits is gone (first it was processors, but AMD and Intel both sell 'em now, then it was Windows, but MS sells THAT now, what's left?).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
I should note, that AMD made that decision. When running a 64 bit OS, the x86-64 architecture can run 64-bit programs, or 32-bit programs. There is no mode (AFAIK) that will let you execute 16 or 8-bit programs. In 32-bit mode on i386 you can still drop down and run 16-bit and 8-bit tasks, but not x86-64. So MS would have to build Virtual PC into Windows to allow that.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
You won't find this on Slashdot, but seeing how people love to pick on Windows security, I thought to let you know about this;
http://www.tuaw.com/2005/04/25/mac-trojan/
Yesterday (even before OS X Tiger was released) the first Trojan for Tiger appeared.
Sophos is listing a new Mac Trojan, dubbed Mac/Cowhand-A, which lets other people gain control of your Mac: "Mac/Cowhand-A is a proxy Trojan for the Mac OSX platform. The Trojan may copy itself to the user's Preferences folder. In order to run itself on startup, the Trojan may add itself to the user's Startup Items."
I started a new job about a couple years ago. Didn't take me long to notice the following line all over:
struct devive_info = (struct device_info *)a_ulDeviceHandle.
I told the chief programer we need to fix this fast as 64 bits are coming, and was told not to worry about it.
For those who can't read hungarian, this function was passed in a parameter as a int, and it was promptly cast (old style C cast too) to a pointer. This works on 32 bit platforms (normally), but will never work on 64 bit platforms.
This is the guy who decided that since GCC is a terrible C++ compiler (it is, but we were still using compilers from 1995 for the windows stuff, and working around bugs in it), he would standardize on Gcc 2.95 even though gcc 3 is much better. I never did figure out that logic. (this was a decision made late last year) Sometimes I'm glad he doesn't work there anymore.
Not that it matters much to me, I'm a UNIX guy. The last version of Windows I ever had on my machines was 3.1, and I installed OS/2 as soon as it arrived.
There was far more to it than that. When you're writing C or C++ code you often make implicit assumptions about the size of many objects. Also MS changed the layout of values passed to Windows messages in many cases, and that required extensive code changes.
I don't see many apps being ported to 64 bit though - only apps that have very heavy memory requirements. MS made a mindbogglingly stupid choice when they made sizeof(long) = 32bits in their 64 bit data model. Every other 64 bit operating system made sizeof(long) == 64 bits. That means that even if you've ported to 64 bits before (because you're a server app that works on thing other than Windows), you're up for porting work.
Frankly, I doubt this is useful to more than a tiny fraction of /.'ers. My impression is that most of us run Linux or OS X for our desktop/server systems, and only use Windows for games. Okay, a reasonable number of /.'ers will have to use Windows desktops at work, but how many of those actually run memory intensive applications that are too slow currently?
When they games start coming as standard as dual format AMD64/x86, I'll think about switching. In the meantime, don't care (and if more games start getting released on the Mac, I'll just ditch the PC anyway, frankly).
I remember Far Cry was supposed to have 64-bit version. Are those currently out and working for Windows XP 64-bit?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Mac OS 10.3 and Tiger (10.4) both have 64-bit components. Tiger obviously has more.
The idea here is that the bulk of the OS is still 32-bits. Applications run in 32-bit space, but unix tools (Apple lingo for CLI apps) can reside in 64-bit space, as does the bulk of the underlying OS that requires it (memory, kernel, some drivers, one-button mouse etc) and that only if the hardware is 64-bits (so the OS is a FAT build for some components).
If you user-space (UI) application requires 64-bits (PhotoShop to name the proverbial example), then it's image processing threads can be 64-bits and loaded from the 32-bit UI application.
As time move on and Tiger gets more update and eventually reach MegaPussy (not the actual name but whatever 10.5 will be), more components will be 64-bits.
There is some criticism for this adoption strategy but it has a goal. This way, Tiger apps can run on either 32 or 64-bits machines. if you app requires (or uses) 64-bits components, then it will be a more concious design decision and there are less chance some dweeb ends up trying to launch a 64-bit application on it's Rev B iMac.
Such transitions to new hardware is not new to Apple (wich I consider the kings in that field, considering what the hardware platform went through). It only means less broken apps for now.
(And I was kidding about the 64-bit one-button mouse drivers.)
You can pimp Linux all you like, most people care about Windows and what it runs on. For a long time, the only 64-bit Windows was IA-64. GRanted no one used it, but still. However now MS has discontinued all IA-64 support for workstation, and gone with x86-64, and it's going mainstream. That effectively means the format war is decided. Intel may continue to make IA-64 chips, but they'll never be mainstream since Windows doesn't use them.
I saw these being sold all over Akihabara this past weekend... This guy confirms, and they seem legit. Anybody know what's up with this?
Isnt this "no retail"-strategy exactly what will make people warez Windows XP64 even more?
Lets face it, many people already have bought Athlon 64-systems, or want to build them themselves. Those people CANT get Windows XP64 on their machines legally, if I understand this correctly.
Of course people could get an MSDN-subscription...
Why force people into warez?
Why justifying warez?
Why not sell it when people want it?
Most people wont buy a Dell just to get XP64 for their home-built system.
To put it this way, changing int's would be troublesome, be a performance hit and not give any advantages (since anyone needing a 64 bit word knows where to look already). Changing the size of the regular long int would maybe be more sensible since it is a bit useless to have it be defined as the same size as int as it typically is today, but really, it is not useful in any way other than to make the type hierarchy slightly nicer, and that is hardly worth the trouble.
Interestingly the issues seen in new Windows are the same as the ones in x86_64 Linux. Except drivers aren't nearly as problematic since there are only a few "3rd party" proprietary drivers (like graphics card manufacturers), and those have had 64-bit drivers for quite some time. The drivers in the kernel tree have been cleaned up during the last 10 years (starting with the alpha port), so in many cases just a recompile is enough.
;), that way buggy browser plugins don't crash your browser completely).
(Browser) plugins are the other issue, if you need flash or proprietary format video playing using windows dll's you'll still want to use a 32-bit browser or video player. Konqueror, I believe, runs plugins as a separate process, so it's unaffected by this (it's not a bad design choice either, Firefox/mozilla/IE should do this too
So, do you need a 64-bit OS? Like mentioned in other comments, you probably don't need 64-bitness that much (unless running code processing lots of big numbers), but those extra registers you get in 64-bit mode give you a nice speed boost. And people already have enough memory in their boxes to see a benefit today (> 1GB is enough since you avoid all those TLB flushes and all that, this applies to Windows and Linux, >= 4GB for a big boost since you don't need that PAE crap)
You know, for all the bullshit about how Linux is ahead of MS in the 64 bit department, that's _not_ my experience with it.
Sometime during th last half of last year, i.e., after more than a year of "Linux is 64 bit already" bullshit, I actually gave it a try. Gentoo, to be precise. Let me tell you how it worked:
There were almost no drivers for anything. Not for the hard drive, not for AGP, not for anything. And that was on a Via K8T800 chipset, i.e., the chipset the A64 was launched with.
Which is just as well, because ATI also had no 64 bit drivers for my 9800 XT. I ended up staring into a 60 Hz VESA Framebuffer display for about a week before I uninstalled it.
And you know how slow that framebuffer was? Let's just say it's the first time I saw DSL downloads being braked by the speed of updating the progress bar.
But maybe it had 64 bit applications? Nope, guess again. No 64 bit OpenOffice, no 64 bit Eclipse, not one goddamn app I needed to use was ported yet. Just for a lark I tried emerging Pingus. (God knows the framebuffer speed didn't promise to be good for a game.) Guess what? That one wasn't 64 bit ready, either.
So you folks are telling me... what? That a freakin' useless system with no apps and no drivers counts as being ahead of MS? Yeah, right. That MS sucks for not loading 32 bit drivers... just like Linux didn't load ATI's 32 bit drivers? That MS's marketting is more guilty than the bleating zealots promoting a Linux system without drivers or apps as a finished and production-ready solution?
Sometimes this kind of zealotry strikes me like doing more harm than good. I can tell you that _I_ am not looking forward to trying 64 bit Linux again. (And I'm writing this in Konqueror in 32 bit mode Gentoo linux right now, so you can spare the "Redmond fanboy" wisecracks.) I think other people who got tricked by that zealotry would be even less inclined to give it another try, ever.
It may not be obvious, but _some_ truth in advertising can go a long way. Yes, we're all nerds, we're all outraged as the "creative puffering" that marketting does. But one-upping them via outright lies and outright promoting an unfinished product where only the kernel and GCC is anywhere near 64 bit ready, well, is just a way to shoot the whole Linux community in the foot.
It may not be obvious, but the _only_ use and reason to live of a computer or an OS is to run an apps, and of those is to solve a problem the user has. Same as a tool. You don't buy a microwave oven as an ideological statement against gas ovens, you buy them to actually heat some stuff in them. Same with computers.
And there a tool which sorta is imperfect beats a tool which is completely useless any day.
That's the problem with the mindless zealotry: you sold someone a solution based on _your_ ideology, rather than his needs, you've lost him as a customer for good. That tool from MS is very very imperfect, yes, but it does run Paintshop, some games, etc. It does what Joe Average wants. If your big ideology win is selling Joe a tool which doesn't do that, you haven't converted him, you've just gained someone who'll tell all his friends to stay off that Linux crap.
Just food for thought.
A polar bear is a cartesian bear after a coordinate transform.
Holy shit... lol you are very right... my brain is frazzled from all my finals... havent slept enough... I should have at least realized why the statement I made seemed way too complicated for the action I wanted. Especially since I'm casting a unsigned long to struct which is obviously not correct... Plus there is that assign by value on structs that gets itchy FINALLY there is the lack of precision... wouldn't the problem have been the fact that it was an unsigned long being used Anyways? the fact that this assignment would propagate the error by 1 more bit of resolution loss is irrelevant since the unsigned long could never address 64bits anyways unless there was a special compiler...
I still don't get the reason for dynamic cast though... assuming I had done the pointer casting "correctly"
Gravity Sucks
I will quote in its entirety a post I put on a http://forums.hexus.net/showthread.php?t=23425 Hexus forum a few months ago:
... these applications gain from 64-bit processing either because the problem lends itself to a very large data set, eg a large memory requirement or else because of a requirement to process numbers which are wider than the CPU's register width.)
:-)
Our world is such that we commonly work with numbers between positive and negative 2 billion. Everything from monetary amounts to the number of records in a database, from distance between places to weights and quantities - we generally work with numbers well within the 32-bit range.
When 32-bit processing came around we had a general and common need to process numbers bigger than what could be handled by 16-bit CPU registers, e.g. numbers bigger than 65,000. But this need for large number processing have stayed the same over time, and so it will not assist to drive the development of 64-bit CPUs!
There is also the ability of the CPU to do more accurate floating point mathematics. This, as well as the need to work with very big numbers, play a role only in engineering and science applications, and to a smaller degree in games.
Therefore the need for 64-bit processing is driven more by the need for addressing more memory than by the need for faster processing of very big or very small numbers.
We need 64-bit processing where the data width inherent in the problem exceeds the (32-bit) processor's registers' width. (Actually this is true for database memory requirements and for games' number crunching and engineering and scientific applications too
It is not generally possible to recompile or even rewrite an existing problem to "require" bigger registers or memory space. However if a problem already requires big numbers to be processed and had been "optimised" to fit into 32-bit world, then the program can be (un/re)"optimised" to utilise the full 64-bit processing capability by removing these initial optimisations, such as where 64-bit operations have been broken into multiple 32-bit operations.
In fact, someone (Adrian Cockroft) very aptly said http://www.sun.com/sun-on-net/itworld/UIR951101per f.html 64-bit CPUs increase application performance despite the 64-bit nature of these CPUs . 64-bit instructions and, in particular, 64-bit memory address pointers imposes a big additional load on memory, caching and the CPU, so if you're not using those extra bits, compiling to 64-bit actually makes the application execute slower!
To test this, take your favourite compiler and compile your favourite utility program to both 32 and 64-bit executables and run both and compare the timings on your trusted Althlon64 or Sun ULTRA 5 workstation.
Unless the program either processes lots of large numbers or utilise more than 4GB ram, the 32-bit version will run faster.
A program which does not process huge numbers and which does not process numbers bigger than 32-bits will run faster when compiled to a 32-bit executable, even on a 64-bit CPU. There is also the bigger 64-bit executable to load and instructions to move between memory and CPU.
Let me add something to this - as a pojnt in case, all the general purpose utils on Solaris 7, 8, 9 and 10 come as 32-bit executables by default (Some 64-bit utils are available, but not in your path by default). This is probably because the memory bandwidth overhead (read: Wasted memory bandwidth) due to 64-bit executables needing to transfer double the amount of bits from memory to find out where pointers point, even if it is just to point to next next memory address! (Eg pointers are bigger because they can address more memory, even if you don't need it)
A very simple comparisson will prove this, eg
timex
--- Abnormally normal.
Hum strange. I've played a cracked version in the past.
Shoot me
Actually, you'll have to buy a new system in order to get it: x64 Windows releases will not be sold on retail shelves - only as an option from manufacturers selling PCs...
Hmmm, I've had a completely different experience with 64 bit Gentoo... I'm currently running 64 bit Gentoo Linux on an FX-55 chip. I dual booted into WinXP 64 bit for a little while, but found the lack of native 64 bit applications (and especially drivers) to be irritating (I'm not a big fan of Windows to begin with either). I've found the biggest speed increases have nothing to do with 64 bit code though. In fact memory access seems to be way, way, way faster. There is also no more "bigmem" option, which was required to address more than 768MB of RAM in 32 bit Linux (at the expense of performance). Ok, so some apps seem to have benefited, and there is a lot of 64 bit optimized code for Linux, but man, applications (32 bit or 64 bit) launch faster, the OS boots faster... I'm really happy with the 64 bit switch. My experience with 64 bit WinXP was much more similar to what you describe with 64 bit Gentoo actually... No drivers, no 64 bit binaries, nothing ran correctly. The few 64 bit drivers that were out there (nVidia mostly) were stripped down versions of the 32 bit software; no supporting apps/control panels. Sound was all FUBAR too (not to imply that 64 bit ALSA was easy to get working). This all seemed to be related to the inability to install non "64 bit Windows Certified" drivers.
The browser thing (32 bit plugins don't work) was annoying at first... Then I just installed adblock and told it to strip out all flash content. I don't even miss it :) You can use Konqueror with 32 bit plugins, but c'mon, who wants to have to run two web browsers just to see flash ads?
For me, the real frustrating parts of running a 64 bit OS right now are two fold. One, all the closed-source CODECs are still 32 bit only which means a side-by-side install of 32 bit media players is required to say, play WM files in Linux. That side-by-side install is the other pain. Though Gentoo has done a good job of it, I have two of every library installed; one 32 bit and one 64 bit. Some apps have to be compiled 32 bit, which GCC does a good job of, but if it gets linked to a 64 bit library or gets pissy about a 64 bit dependancy, you're sunk.
All-in-all I've seen no reason whatsoever (for ME) to run 64 bit Windows when the open source community has been working so hard to churn out a butt-load of 64 bit apps (the 64 bit Gentoo Portage tree is almost as large as the 32 bit tree now). The big irony is that I've been chomping at the bit for a 64 bit Windows release to spur the authoring of 64 bit drivers, CODECs, and games. So bigs thumbs up here for 64 bit Windows even though I have no plans to run it.
I'm going to go ahead and say it though; 64 bit Windows XP PRO RC2 (the latest 64bit Win I ran) can't hold a candel to 64 bit Gentoo Linux. That said, I did spend a lot of time reading up on 64 bit Linux and waited until nVidia released 64 bit drivers, then bought an nVidia mobo/GPU. I would have been really mad if I had to load 2D-only drivers on my 6800 Ultra, but then I wouldn't drop $500 on a graphics card until I made sure that it supported by the OS I intended to run. I'm also not going to let my horrible experience with 64 bit Windows sour me on the OS forever; I'll simply try again down the road when it is more "main stream". If MS makes a better 64 bit OS than Linux - I'll switch.
Actually, I wrote my thesis on life experience.