What is the effect of setting the /3GB switch on my 64-bit Windows machine?


Nothing.

Comments (41)
  1. 640k says:

    The flag takes disk space, and thus, fragment the file system, and makes the computer slower. Also takes more ram in the code that loads boot.ini

  2. John says:

    Well, that clears that up.

  3. Steven says:

    Succinct.

  4. someone else says:

    Cool, Raymond, so you’re twittering (tweeting?) your blog entries now? I like that.

    "The flag takes disk space, and thus, fragment the file system, and makes the computer slower. Also takes more ram in the code that loads boot.ini"

    Unlikely. If you boot.ini takes up more than one cluster (normally 4 kb on NTFS), you have a lot more problems that just fragmentation.

    Then again, there aren’t that many 64-bit machines with a 64-bit version of Windows 5.x.

  5. 640k says:

    Boot time is slower because the code has to parse a larger file.

    [I find this all very amusing because 64-bit Windows doesn’t use boot.ini. -Raymond]
  6. Falcon says:

    @someone else:

    Yes – presumably the space is taken up by your, shall we say, LARGE menu timeout value, which won’t have the intended effect because the boot manager can only handle up to ~10 million seconds!

    If only that suggestion about using bignums had come a little earlier…

  7. Matt Newman says:

    It would be more fun if it restricted available ram to 3GB… kind of an evil easter egg.

  8. pae says:

    How about /PAE?

  9. Gabest says:

    Well, there are many pci tuners that fail to work if the system has 4+ gb of ram, if I could choose between one 2gb module or two that are limited to 3gb I would gladly have that plus one gig.

  10. 579 says:

    > Unlikely. If you boot.ini takes up more than one cluster (normally 4 kb on NTFS), you have a lot more problems that just fragmentation.

    Plus, it should be of exactly K+1, K+2, K+3, K+4 or K+5 bytes long where K is any multiple of 4096.

    Otherwise the weight of /3GB switch would be null because you don’t gain a cluster by removing it.

  11. Alexandre Grigoriev says:

    @Gabest,

    You confuse process usermode VM size (which /3GB controls in x86), and physical memory size. Anyway, if a system has "only" 4GB of RAM, in x64 some of it will already be over 4GB logical, and those PCI tuners won’t work already.

  12. Pierre B. says:

    Well, Windows XP 64-bits edition still uses boot.ini. :P

    (Of course, I must be in the very tiny group of martyrs who is still on XP64… at least it a lot less painful than it was when it first came out.)

  13. Billy O'Neal says:

    @Pierre B.:

    No, it does not. Windows XP Professional x64 Edition does. Windows XP 64 Bit Edition runs only on Itanium systems… I seriously doubt you’ve got one of those lying around.

  14. Pierre B. says:

    Billy: sorry, I forgot I was writing in the land of nit-pickers! Woe to me to talk of 64-bits edition when I meant x64! We won’t accept such a loose usage of language! Not on this ship^H^H^H blog!

  15. Matt Fisher says:

    I saw the headline in my RSS reader, clicked, saw the text, and laughed heartily.

    Thanks, Raymond.  :)

  16. Billy O'Neal says:

    I’m not being a language stickler. Just saying that when Raymond says 64-bit Windows doesn’t use boot.ini, he is not mistaken.

    64-bit refers to the IA-64 architecture.

    x64 or x86-64 refers to the amd64 architecture.

    They’re very different and the operating systems designed to run on them are nothing alike.

    Don’t blame me, I didn’t name the products that way ;)

  17. Random832 says:

    This post is far too verbose – I got about halfway through it and gave up.

  18. Random832 says:

    On a more serious note [just realized this after I posted] – if "64-bit" only refers to IA-64, does that mean that this post does not apply to x64? What does the /3GB switch do on x64, then?

  19. Jonathan says:

    NT 5.1 (Windows XP) 32-bit uses boot.ini.

    NT 5.2 (Windows XP and Windows Server 2003) 32-bit and 64-bit (AMD64) use boot.ini.

    NT 6.x (Windows Vista and later), both 32 and 64-bit, use BCD.

    I don’t know what IA-64 systems use. EFI?

  20. how long until someone creates

    WhatistheeffectofsettingtheSlash3GBswitchonmy 64-bitWindowsmachine.com

  21. Joe says:

    Again, why do you want o use the/3GB switch on a 64-bit system?

    Joe

  22. 945 says:

    My app (which I haven’t written yet) will read boot.ini and crash if the switch is not set to a proper value. So please consider making this setting relevant for forward-compatibility reasons.

  23. Nick says:

    Very succinct Raymond, but it doesn’t even address the primary problem!

    The real question is, has Microsoft finally given its customers what they want with 64-bit Windows?  Have you FINALLY allowed for more than 11 million seconds boot delay?

    Stop ignoring your customers!

  24. Brett Allen says:

    So…what does it do on a x32 or x64 machine?

  25. Cooney says:

    So…what does it do on a x32 or x64 machine?

    really?

    http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx

  26. scorpion007 says:

    TL;DR.

  27. Endurion says:

    I wish more technical documentation was that clear and to the point.

  28. Fire Snake says:

    That’s called 4GB RAM Tuning now!

  29. Fire Snake says:

    One clarification for some dummies out here, but I would expect it to have an effect on Processes running in 32bit WoW mode on a x64 machine … or not? I mean if I port a 32 bit app from a x86 to a x64 machine, and the x86 machine had the /3gb (or 4 gig ram tuning) enabled, I could not port it, or how would I tell the x64 machine to use 3gb user mode address space for a process which uses 32 bit pointers?

    Might be a dumb question, but at least I am an honest idiot.

  30. 640k says:

    Many programs become buggy when you enable the 3gb switch in 32-bit windows. Is it the same in 64-bit windows?

  31. Mike Dimmick says:

    640k: Just flipping the /3GB switch doesn’t actually do anything for most programs. Programs have to opt in to get a 3GB virtual address space using the /LARGEADDRESSAWARE linker flag (which sets a bit in the image header). If they don’t, they still get a 2GB address space.

    In 64-bit Windows, 32-bit programs that specify /LARGEADDRESSAWARE get a near-4GB address space, while 32-bit programs that don’t still get a 2GB address space as before. After all, they didn’t say they could handle addresses with bit 31 set to 1.

    Mostly it’s server programs that specify /LARGEADDRESSAWARE, though, and there are normally 64-bit versions that get access to the full 64-bit address space available.

  32. someone else says:

    "Mostly it’s server programs that specify /LARGEADDRESSAWARE, though, and there are normally 64-bit versions that get access to the full 64-bit address space available."

    That, and multimedia programs. Photoshop is one of them. And for good reason.

  33. JamesW says:

    @Mike Dimmick: Just flipping the /3GB switch doesn’t actually do anything for most programs. Programs have to opt in.

    Yes. And any that do opt in should pay heed to Raymond’s mention of the "Top down" flag in the memory manager allocation preferences mask, as mentioned in this post from years ago: http://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx

    If you say you’re LARGEADDRESSAWARE, then make sure your code runs well with the top down allocator. It helped us catch some ancient code smuggling data in bit 31.

  34. David Heffernan says:

    Ironically WOW64 has some bugs with addresses >2GB, for example GetCursorPos fails for all such addresses.  This is fixed in Windows 7 but won’t be down-ported to Vista.

  35. Yuhong Bao says:

    “Ironically WOW64 has some bugs with addresses >2GB, for example GetCursorPos fails for all such addresses. ”

    Which can be nasty, since it do not show unless an address above 2GB is actually passed to GetCursorPos.

  36. Paul says:

    Gah. Didn’t realise someone made the exact same joke that I did.

    That’s what I get for skimreading.

  37. odys says:

    same as in the x86

  38. Yuhong Bao says:

    IMO the biggest mistake made with EFI during it’s history was AMD not considering EFI during x86_64 development. Instead, EFI had to be ported to x86_64 after the fact, which delayed its adoption for years. If AMD had mandated it from the beginning that all x86_64 OSes booted via EFI, there indeed would be no version of 64-bit Windows using boot.ini.

  39. rje says:

    An even bigger mistake than that was inventing EFI at all, considering OpenFirmware already existed.

  40. 640k says:

    EFI was invented only to enable DRM/TCPA/Palladium on the x86 platform. OpenFirmware cannot, by design, support that.

Comments are closed.

Skip to main content