Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Windows Operating Systems Software Upgrades Technology

Windows XP X64 Goes Gold 359

Kasracer writes "According to The Inquirer, 'Microsoft has released the final version of Windows XP 64 to manufacturing, meaning that those with machines that have 64-32 bit processors in from AMD and latterly Intel can now see what the extra addressing brings to the party.'"
This discussion has been archived. No new comments can be posted.

Windows XP X64 Goes Gold

Comments Filter:
  • Re:Longhorn (Score:4, Informative)

    by caston ( 711568 ) on Saturday April 02, 2005 @10:36AM (#12119611)
    Because 64 bit Linux has been around for a long time now and its making MS look very very outdated. This shows they are scrambleing to keep up now.

  • Re:Is this Longhorn? (Score:5, Informative)

    by MoonFog ( 586818 ) on Saturday April 02, 2005 @10:43AM (#12119634)
    What? This is just a new version of Windows XP, afaik it has nothing to do with Longhorn which is a totally new OS.
  • can now? (Score:5, Informative)

    by Anonymous Coward on Saturday April 02, 2005 @10:43AM (#12119641)
    that those with machines that have 64-32 bit processors in from AMD and latterly Intel

    (1) The opteron is a true 64-bit architecture. The em64t (intel thing) is a bit of a bodge (still basically a xeon core, with shades of 32-bit-ness in odd places like memory mapping for devices), but still appears 64 bit.

    (2) Linux people have been running x86-64 Linux for _ages_ now. It's a cheap and cheerful server platform without some of the worst cruddiness of x86, and a cheap, extremely cost effective, and generally excellent scientific workstation and compute cluster platform, and is selling like wild here (euro) anyway.

  • by pla ( 258480 ) on Saturday April 02, 2005 @10:43AM (#12119643) Journal
    meaning that those with machines that have 64-32 bit processors in from AMD and latterly Intel can now see what the extra addressing brings to the party.

    ...Unless you want to run hardware not built into a mainstream motherboard with support included in XP.

    ...Unless you want to run software using a legacy 16-bit installer (far more common than you might expect, even for programs that don't have a drop of 16-bit code themselves).

    XP for x64 has NO 32-bit hardware driver support. Very very few manufacturers have x64 drivers available yet. Thus, don't feel surprised when you literally can't use any of your fancy toys. On the bright side, NVidia does have beta 64-bit drivers available, so you might luck out. Of course, considering the stability of final-release NVidia drivers, do you really want to use a beta?

    XP x64 has also completely dropped 16bit support. No more old DOS programs. No more Win3.1 programs. More importantly (as I mentioned above), no more installers that used 16 bit code, even for purely 32-bit programs.

    I too look forward to running XP x64 on my Athlon64. But for the moment, the average Joe just doesn't have that as a realistic option. In another six months, perhaps. But not yet.
  • Re:Is this Longhorn? (Score:5, Informative)

    by MoonFog ( 586818 ) on Saturday April 02, 2005 @10:48AM (#12119659)
    No, Longhorn is the (code) name for the next version of Windows. XP-64 is just an upgrade, adding the 64 bit addressing possibilities to the Windows XP OS.

    Longhorn will not be out until next year at the earliest.
  • Re:Is this Longhorn? (Score:4, Informative)

    by wpmegee ( 325603 ) <wpmegee AT yahoo DOT com> on Saturday April 02, 2005 @10:49AM (#12119661)
    No. This is just Windows XP. Games and other apps will have to be recompiled to take advantage of it - UT2004 has a beta out, don't know of any others available.
  • Re:Heh (Score:2, Informative)

    by alman ( 86957 ) on Saturday April 02, 2005 @10:50AM (#12119666) Homepage
    NT For Alpha wasn't really 64 bit, it made high use of a 32-64bit emulator.
  • by Anonymous Coward on Saturday April 02, 2005 @10:52AM (#12119672)
    LightWave 3D, by NewTek.
  • Re:Heh (Score:3, Informative)

    by DaHat ( 247651 ) on Saturday April 02, 2005 @10:56AM (#12119683)
    I think you've got that backwards, NT4 for Alpha was pure 64-bit, and DEC shipped an (32-bit) x86 emulator to help existing applications be able to run.
  • "Can now see" (Score:4, Informative)

    by m50d ( 797211 ) on Saturday April 02, 2005 @10:59AM (#12119690) Homepage Journal
    Or they could have used SUSE and have seen what it does, what, 5 months ago?
  • Re:Longhorn (Score:5, Informative)

    by MoonFog ( 586818 ) on Saturday April 02, 2005 @10:59AM (#12119694)
    The XP version if available for free download and if you're talking about bundling XP-64 with pre-built computers, they would most likely come with Windows XP either way. I think it's more about the fear of losing customers rather than trying to trick people to buy two OS'. Besides, if MS where to go another full year without an OS with full 64 bit support, it could be bad for business.
    I agree to with you to a certain degree, I just think you're maybe a little too paranoid.
  • Re:Is this Longhorn? (Score:5, Informative)

    by Jugalator ( 259273 ) on Saturday April 02, 2005 @11:01AM (#12119701) Journal
    I thought longhorn was XP + 64-bit.

    I don't know where all misinformation about Longhorn being aimed for 64-bit processors come from. I keep seeing it everywhere on forums.

    Longhorn will be released just like Windows XP; in 32- and 64-bit editions.
  • by KidHash ( 766864 ) on Saturday April 02, 2005 @11:01AM (#12119703) Homepage
    It depends, what do you use your laptop for? Unless you're doing scientific work, or playing a game which is 64-bit optimized, then no.

    And even if you are doing those things, only if the drivers are available.

    Basically, hold off unless you have no choice
  • by BinLadenMyHero ( 688544 ) <binladen@9hel[ ]org ['ls.' in gap]> on Saturday April 02, 2005 @11:06AM (#12119721) Journal
    Whoever modded this down missed the reference to the excelent Civilization game. It periodicaly lists the top richest/welthiest/militarized/advanced/largest nations of the World.

    In fact, I've played only Freeciv [freeciv.org] (and not the original one) for a long time, but I'm pretty sure the Historian Publishes were on the original also.
  • by Anonymous Coward on Saturday April 02, 2005 @11:08AM (#12119730)
    The advantages of the AMD-64 archetecture go far beyond the additional address space. The number of general purpose registers is doubled (and, of course made 64 bits wide). This is far more important than the increased address space and, for most code more important than being 64 versus 32 bit.

    Translation: If you've never heard of a register, what this means is that there are twice as many internal storage locations in the processor. moving data between internal registers suffers from no delay, while accesses to memory (ram) is slow and processing cycles can be lost to wait states - basically the processor must pause and wait for the memory access to get done.

    This is why most code when recompiled for the new architecture will see an immediate performance improvement. Some code will see gains from the 64 bit width of these registers - but not as much. Virtually no one will see a benefit from being able to use more than 4gb of ram.
  • by Glonoinha ( 587375 ) on Saturday April 02, 2005 @11:10AM (#12119738) Journal
    You can throw 2-3G of memory at 32-bit applications right now using regular XP Professional or 32-bit Windows 2003 Server. With the new 64-bit version of Windows 2003 Server Enterprise you can throw a full TeraByte of physical memory at a single application. Good luck getting that much physical memory in a box right now, but you can get 32G or maybe 64G in a single machine right now if you try real hard (and have a LOT of cash.)

    Something tells me Duke Nukem Forever will take full advantage of the 64-bit platform.
  • by ergo98 ( 9391 ) on Saturday April 02, 2005 @11:15AM (#12119760) Homepage Journal
    With the .NET Framework as "64-bit native", all .NET apps will immediately benefit, and the JIT compiler can take advantage of all of the goodness of x64.

    In the binary world, an upcoming version of SQL Server 2005 x86 is promised.
  • by ergo98 ( 9391 ) on Saturday April 02, 2005 @11:20AM (#12119785) Homepage Journal
    I should note that the 64-bit .NET Framework isn't actually out yet: I don't believe it was delivered with the 64-bit XP. That was more of a "future focused" comment about an upcoming variant of the .NET Framework 2.0 that will be 64-bit.
  • by Anonymous Coward on Saturday April 02, 2005 @11:27AM (#12119819)
    Well, for one thing, XP-64 isn't really XP. It's essentially a user version of Windows Server 2003. So pretty much everything should get some benefits.

    Unfortunately, the Asus K8V SE SATA hard drive driver apparently identifies itself incorrectly or is in someway incompatible. It works fine under XP but XP-64 refuses to load it, saying that it's the wrong version, and XP-64 doesn't recognize the SATA ports out of the box. I have an IDE drive as my primary, so I can boot into XP-64 but I can't see either of my SATA drives when I do.

    And no, I won't talk about how I have a copy of a program that just went gold, and no, I haven't seen a crack for the registration requirement yet. Hopefully, one will come out before my 30 days are up.

  • Re:"Can now see" (Score:5, Informative)

    by rsax ( 603351 ) on Saturday April 02, 2005 @11:35AM (#12119855)
    Or they could have used NetBSD which was ported to the AMD 64 bit processor [netbsd.org] before it was even released..... in 2001.

    Booya!

  • Re:can now? (Score:1, Informative)

    by Anonymous Coward on Saturday April 02, 2005 @11:36AM (#12119858)
    >> (1) The opteron is a true 64-bit architecture. The em64t (intel thing) is a bit of a bodge
    >> (2) Linux people have been running x86-64 Linux for _ages_ now

    Parent is trolling fanboy. I pay the bills as a developer on a major x86-64 application.
    1) x86-64 is the same on both Intel and AMD. If they were really different, we would target Intel because Intel is shipping 10x the x86-64 volume AMD does.
    2) We have been DEVELOPING for what seems like ages. Wide spread deployment of x86-64 production envrionments is still a few quarters out. Fact is it is not quite ready for prime time.

  • Re:Heh (Score:5, Informative)

    by Waffle Iron ( 339739 ) on Saturday April 02, 2005 @11:36AM (#12119860)
    NT4 for Alpha was pure 64-bit

    It's highly debatable whether you could call it "pure 64-bit". A description of the implementation from here [macintouch.com]:

    Also, the Windows NT implementation on the Alpha was not really true 64 bit, but used a less ambitious system called VLM to allow access to more memory than 32 bit system. Here's a quote from Microsoft about it:
    "As you can see, the VLM APIs don't constitute true 64-bit computing. Sure, you can allocate and use this memory if it's physically present, meaning that virtual memory doesn't work with these addresses. But 99.44 percent of the Win32 API can't work with addresses above 4GB, so it's just you and your 64-bit pointers. Think of it as frontier territory with no newspapers, running water, or phone lines."
  • by Grey Ninja ( 739021 ) on Saturday April 02, 2005 @11:42AM (#12119879) Homepage Journal
    I know the article says it just went gold, but I know damn well that there's some people here who've tried it. I am just curious... how useable is it?

    I tried 64 bit Ubuntu briefly, but I went back to 32 bit after failing to acquire such things as my favorite XMMS plugins (which I never could get compiled and working properly, even in 32 bit, so was forced to get binaries), and 32codecs, and of course, browser plugins.

    I would imagine that the video codecs work a lot better in Windows XP, but I would imagine that it would be much similar to Linux in that I would have to run in 32 bit mode in order to actually use most stuff.

    I am aware that there's a way of running a 32 bit mode in Linux as well... but it seemed far too complex to actually go through with, and I am too much of a newbie to actually get it working properly.
  • The Horse's Mouth (Score:5, Informative)

    by PizzaFace ( 593587 ) on Saturday April 02, 2005 @11:52AM (#12119917)
    Microsoft has a website for Windows XP Professional x64 Edition [microsoft.com]. The site has a pseudo-technical overview [microsoft.com] of the product, and more detailed information [microsoft.com] for developers.
  • Re:can now? (Score:5, Informative)

    by Anonymous Coward on Saturday April 02, 2005 @12:09PM (#12119994)
    Look around for the implications of EM64T not having an IOMMU like AMD64 does. This is what the guy was talking about.

    With EM64T you can't do DMA from devices to addresses above 32bit. This means that the transfers have to be done into a buffer below 4Gb and then copied over to the application buffer (above 4Gb). This implies a serious performance penalty and puts EM64T out of the "true 64bit" bag.
  • by Darren Winsper ( 136155 ) on Saturday April 02, 2005 @12:16PM (#12120020)
    By default, 32-bit XP gives user-mode applications 2GB of addressable space, leaving 2GB for the kernel's address space.
  • by fimbulvetr ( 598306 ) on Saturday April 02, 2005 @12:44PM (#12120134)
    Quit using gnome, try xfce.

    here [xfce.org]
  • Re:Longhorn (Score:3, Informative)

    by dubbreak ( 623656 ) on Saturday April 02, 2005 @01:05PM (#12120238)
    Surely that would have brought down development times, and we could have it sooner?

    Obviously you haven't read The mythical Man Month [amazon.com].

    Of course if you aren't a software engineer or you are a "pointy haired boss" [wikipedia.org] then I'm not surprised you haven't read it and think throwing extra money and people at a project will make it faster.
  • by DarkEdgeX ( 212110 ) on Saturday April 02, 2005 @01:06PM (#12120244) Journal
    No, wrong. Current .NET apps will run in the context of the 32-bit .NET runtime, meaning they won't benefit from the larger address space or the eight additional general purpose registers. In order to run in the context of the 64-bit .NET runtime the header of the executable needs to contain specific flags.

    Also, .NET apps which thunk to external 32-bit DLL's for added functionality won't work with the 64-bit .NET runtime (e.g. - if you call out to kernel32.dll or any of the standard Win32 DLL's your code will, of course, not work with 64-bit DLL's).
  • by gr3kgr33n ( 824960 ) on Saturday April 02, 2005 @01:14PM (#12120279) Homepage Journal
    as a person currently running XP-64 Beta, Here are the gripes I have: Drivers must be 64-bit == Most Drivers 'cept nVidia and a select few others are 32 .Net Framework 64 is "out" With the lack of driver support, running XP-64 is a hit or miss operation currently. Luckly my board has most things onboard and gigabyte was kind enough to give me 32-bit versions of all my drivers. Thank you gigabyte for giving me 32 bit drivers with a 64 bit board, shure these guys don't work for microsoft?
  • by ergo98 ( 9391 ) on Saturday April 02, 2005 @01:23PM (#12120318) Homepage Journal
    No, wrong. Current .NET apps will run in the context of the 32-bit .NET runtime, meaning they won't benefit from the larger address space or the eight additional general purpose registers.

    You have a reference for that? Every source I've seen indicate that neutral .NET apps will automatically run as a 64-bit app when copied over. However, on the flip side you can mark the app to only run in 32-bit, or 64-bit, but the default mode is neutral, with no specific bitness.
  • by x0n ( 120596 ) on Saturday April 02, 2005 @02:19PM (#12120525) Homepage Journal
    Aye, but there is a /3GB switch you can use in boot.ini:

    "Increases the size of the user process address space from 2 GB to 3 GB (and therefore reduces the size of system space from 2 GB to 1 GB). Giving virtual-memory- intensive applications such as database servers a larger address space can improve their performance. For an application to take advantage of this feature, however, two additional conditions must be met: the system must be running Windows XP, Windows Server 2003, Windows NT 4 Enterprise Edition, Windows 2000 Advanced Server or Datacenter Server and the application .exe must be flagged as a 3-GB-aware application. Applies to 32-bit systems only."

    (take from sysinternals.com, a la Mark Russinovich)

    - Oisin
  • Re:can now? (Score:4, Informative)

    by l3v1 ( 787564 ) on Saturday April 02, 2005 @02:37PM (#12120600)
    1) x86-64 is the same on both Intel and AMD. If they were really different, we would target Intel because Intel is shipping 10x the x86-64 volume AMD does.

    As also one of the responses to this point out, you're not entirely right here. As I know it - and I'm not trolling here, just not having too much hands-on experience, so I could be somewhat wrong - they may "seem" equal, that is you can code almost exactly the same on them, but internally Opterons give you a 64bit architecture with all the benefits (and hypetransport being the chocolate on the cake) with 32bit compatibility, while 64bit-extended Xeons seem to be just as the name suggests.

  • by truesaer ( 135079 ) on Saturday April 02, 2005 @03:46PM (#12120987) Homepage
    Here are the gripes I have: Drivers must be 64-bit == Most Drivers 'cept nVidia and a select few others are 32 .Net Framework 64 is "out" With the lack of driver support, running XP-64 is a hit or miss operation currently.


    FYI, 64-bit drivers are required when running in 64-bit long mode on the processor. So it isn't an artificial limitation of Windows 64, but rather a requirement imposed by the processor.

    For those who aren't real familiar with AMD64 architecture, it works basically like this: The processor starts in real mode, and at some point the operating system sets up the necessary mechanisms to support protection, paging, interrupts, etc. At the point it switches the processor into protected mode which is where all modern operating system and code run. There is also a virtual 8086 mode to run native DOS type applications, which is where the run dialog in windows executes. These three modes are known collectively as legacy mode.

    From protected mode if you want to run 64-bit code you need to switch into long mode, which is a collective name for 64-bit mode and compatibility mode. 64-bit mode is a pure 64-bit environment. The operating system must run in this mode, and all drivers must be 64-bit. I believe this is because interrupts automatically switch the processor into 64-bit mode. On a code segment by code segment basis you can also run in compatibility mode, which allows 32-bit code to be run in long mode. That is how all the current 32-bit apps will be able to run even in long mode. so from protected mode the OS must switch into compatibility mode, then into 64-bit mode to run 64-bit code. Once in compatibility mode any interrupt will force a switch to 64-bit mode, which is why drivers need to be 64-bit.


    Its also worth noting that switching from 64-bit mode to compatibility mode and back has been designed to have no performance penalty.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin

Working...