Linked by David Handlos on Thu 25th Sep 2008 18:07 UTC
Windows A Windows developer and Sysadmin has compiled a "Watch List" of the small but annoyingly important things to keep in mind when moving from 32 bit Windows to Windows x64.
Order by: Score:
Hmm...
by 1c3d0g on Thu 25th Sep 2008 19:33 UTC
1c3d0g
Member since:
2005-07-06

...except of course, if your CPU doesn't support x86_64 instructions, like Intel's Atom. It's a shame really, and I'm hopeful the next Atom version will have 64-bit support included.

Reply Score: 3

RE: Hmm...
by David Handlos on Thu 25th Sep 2008 19:38 UTC in reply to "Hmm..."
David Handlos Member since:
2008-09-10

I'm hoping so too...whether I like it or not, I keep ending up in the Windows environment, and sooner or later they're going to stop making 32-bit versions of their OS.

Reply Score: 2

RE: Hmm...
by deathshadow on Fri 26th Sep 2008 01:20 UTC in reply to "Hmm..."
deathshadow Member since:
2005-07-12

Uhm... Last time I checked the Atom is an EM64T processor fully capable of running x64 versions of windows - I have one here running XP x64 just fine as well as a AMD64 build of Ubuntu, so what exactly are you saying?

Reply Score: 2

RE[2]: Hmm...
by null_pointer_us on Fri 26th Sep 2008 01:32 UTC in reply to "RE: Hmm..."
null_pointer_us Member since:
2005-08-19

Some chipsets -- especially some mobile chipsets -- do not support the x86-64, even when the processor does. Also, on some motherboards with x86-64 chipsets the motherboard traces aren't connected for 64-bit addressing. That's likely the cause of the confusion.

Anyone who wants more info can read here:
http://support.microsoft.com/kb/929605/en-us

(Look under the "WORKAROUND" section.)

Reply Score: 2

RE[2]: Hmm...
by Thom_Holwerda on Fri 26th Sep 2008 08:38 UTC in reply to "RE: Hmm..."
Thom_Holwerda Member since:
2005-06-29

Uhm... Last time I checked the Atom is an EM64T processor fully capable of running x64 versions of windows - I have one here running XP x64 just fine as well as a AMD64 build of Ubuntu, so what exactly are you saying?


The most popular models of the Atom processor (the N and Z mobile versions) have the 64bit extensions disabled. Only the desktop version of the Atom can run in 64bit mode.

Reply Score: 2

RE: Hmm...
by Redeeman on Fri 26th Sep 2008 02:59 UTC in reply to "Hmm..."
Redeeman Member since:
2006-03-23

...except of course, if your CPU doesn't support x86_64 instructions, like Intel's Atom. It's a shame really, and I'm hopeful the next Atom version will have 64-bit support included.

Except that the intel atom cpu actually DOES have x86_64 support..

Reply Score: 2

RE[2]: Hmm...
by 1c3d0g on Fri 26th Sep 2008 13:01 UTC in reply to "RE: Hmm..."
1c3d0g Member since:
2005-07-06

Not the mobile versions, sadly, like Thom pointed out. :-(

Reply Score: 2

I must say...
by suryad on Thu 25th Sep 2008 20:16 UTC
suryad
Member since:
2005-07-09

I quite like the x64 experience and after having convinced a few people to take the plunge they keep thanking me for it everyday. The only gripe for me was drivers but XP x64 is chugging along great for me. I just need a vpn client and then I would be set.

Reply Score: 2

RE: I must say...
by cujo on Thu 25th Sep 2008 21:37 UTC in reply to "I must say..."
cujo Member since:
2005-07-06

I'm not trying to be rude or anything, but why did you even bother to convince people to go 64 bit? Unless you need the memory why does it even matter? It seems like you set yourself up for headaches and the benefit is not much for most people.

Reply Score: 1

RE[2]: I must say...
by David Handlos on Thu 25th Sep 2008 21:46 UTC in reply to "RE: I must say..."
David Handlos Member since:
2008-09-10

Well, beyond the memory benefit, 32-bit operating systems are going to be phased out at some point. Last time I checked, Windows 2008 was supposed to be the version of server OS running 32-bit.

Reply Score: 1

RE[3]: I must say...
by cujo on Thu 25th Sep 2008 21:48 UTC in reply to "RE[2]: I must say..."
cujo Member since:
2005-07-06

No argument there, but why run 64 bit now, when there are these headaches?

I tried it with linux for a while before I realized it was a waste of time for me. I never bothered with 64 bit xp or vista.

Reply Score: 1

RE[4]: I must say...
by David Handlos on Thu 25th Sep 2008 21:56 UTC in reply to "RE[3]: I must say..."
David Handlos Member since:
2008-09-10

You're right, there are some people who don't need to go 32-bit, and could probably stay that way for several more years.

In my case, and in the case of anyone who's building large-scale apps, the extra memory is a life-saver.

In another case, there are applications (like Microsoft Exchange 2007) that are being released as 64-bit only applications. That's definitely a minor occurrence, but I had to help someone out with that exact situation.

Reply Score: 1

RE[5]: I must say...
by cujo on Thu 25th Sep 2008 23:56 UTC in reply to "RE[4]: I must say..."
cujo Member since:
2005-07-06

Interesting. I was just curious if I was missing out on something as my needs don't really dictate that I run a 64 bit OS. There are times when the extra memory would be nice (running multiple OSs in vmware), but I've been coping.

Reply Score: 1

RE[6]: I must say...
by suryad on Fri 26th Sep 2008 12:54 UTC in reply to "RE[5]: I must say..."
suryad Member since:
2005-07-09

I will reply by saying most of my friends have over 4 gb ram. They do video editing, (hd footage), lots of gaming, are java developers etc etc. Whenever I do any sort of development using enterprise oracle products, I can easily use up 2.5 gb of memory. If I was using 32 bit, well that does not leave me with much headroom. And if I am bored, I just stop doing some work and turn on some Crysis without having to turn off any of the software.

My brother who is editing HD footage is already consuming over 4 gb of ram and now he has to go and grab 4 more gb to not cause any sort of disk swapping.

Also as far as I understand, 64 bit processes all have DEP enabled by default. No ifs ands or buts so in terms of security its a good idea.

And also before building machines, we do our research to see what works and does not work. So it just works for us and we are quite happy. ;) No offense taken from all the people who asked why. Main thing was memory usage, server based OS and didnt want to upgrade to Vista. Its just a win win situation fellas. ;)

Reply Score: 2

RE[4]: I must say...
by Liquidator on Fri 26th Sep 2008 07:01 UTC in reply to "RE[3]: I must say..."
Liquidator Member since:
2007-03-04

I am in the same situation. A year ago, I installed Vista x64 on a high-end computer and I didn't feel any difference in terms of speed because basically, I use only Opera, Adobe Reader and MS Office.

However, in the case of David, it's different because he is dealing with servers that can need a lot of memory in some cases. High-end servers can be dramatically relieved with the extra memory unleashed by the x64 architecture.

But unless we are forced to migrate to x64, I don't see any compelling reason to migrate to x64 on the desktop for regular users who don't use professional applications (CAD, 3D, audio, video).

Reply Score: 2

And don't forget IE...
by rklrkl on Thu 25th Sep 2008 20:21 UTC
rklrkl
Member since:
2005-07-06

I'm surprised that this didn't make the list:

"The default Internet Explorer is 32-bit"

The 64-bit IE is there, but buried in a sub-menu of the Start Menu. You may not think this is important, but it actually severely hampers the porting of any plug-ins (Flash, Java, Adobe Reader etc.) to the 64-bit platform because lazy-backsided vendors will claim "we don't need a 64-bit plug-in because no-one ever runs 64-bit IE".

A vicious cycle of course - no-one runs 64-bit IE because there's no 64-bit plug-ins (and it's buried in a sub-menu) and so on and so on. Sadly, Adobe in particular are criminal with their abject lack of 64-bit support of any of the platforms for virtually anything they write. Shame on them!

Bemusingly, the best platform to run 64-bit apps in the many, many years since the Athlon 64 came out is actually Linux - which has far, far more 64-bit apps than the Windows platform (and becaose of that, I suspect a much higher percentage of Linux users run 64-bit than the percentage of Windows users that run 64-bit).

Reply Score: 4

RE: And don't forget IE...
by google_ninja on Thu 25th Sep 2008 20:29 UTC in reply to "And don't forget IE..."
google_ninja Member since:
2006-02-05

32-bit browser plugins are a pain on linux too.

Reply Score: 2

RE[2]: And don't forget IE...
by dcwrwrfhndz on Thu 25th Sep 2008 22:07 UTC in reply to "RE: And don't forget IE..."
dcwrwrfhndz Member since:
2006-05-26

At work I have a Centos desktop (so not that bleeding edge), running 64-bit Firefox on which I installed (had to) 32-bit flash9 and nspluginwrapper. The setup is pretty easy and straightforward.

Reply Score: 4

RE[2]: And don't forget IE...
by sbergman27 on Thu 25th Sep 2008 22:31 UTC in reply to "RE: And don't forget IE..."
sbergman27 Member since:
2005-07-24

32-bit browser plugins are a pain on linux too.

Most modern distros use nspluginwrapper by default. I haven't had to worry about 32 bit vs 64 bit plugins for a long time.

Reply Score: 2

RE[3]: And don't forget IE...
by hollovoid on Fri 26th Sep 2008 01:42 UTC in reply to "RE[2]: And don't forget IE..."
hollovoid Member since:
2005-09-21

nspluginwrapper is messy with 64bit, some people have no issues, but many have crash after crash. Although I have gotten things moving along, my 64 bit experience on linux has been far more frustrating than in windows, especially in the browser plug in respect.

Reply Score: 2

RE[4]: And don't forget IE...
by sbergman27 on Fri 26th Sep 2008 01:59 UTC in reply to "RE[3]: And don't forget IE..."
sbergman27 Member since:
2005-07-24

nspluginwrapper is messy with 64bit, some people have no issues, but many have crash after crash.

I guess I'm one of the people who hasn't had any issues... on Fedora Core 6, Fedora 7, Fedora 8, Fedora 9, Centos 4.x, Centos 5.x, Ubuntu Feisty, Edgy, Gutsy, Intrepid Alpha, on AMD x64 4000+, Intel Core2 Duo 2140, Core2 Quad Q6600, and dual quad core clovertowns, with memory varying from 512MB to 8GB, running from USB, PATA, SATA, SCSI and various combinations, and using NVidia GeForce 6800 AGP, Radeon 9100+ AGP, VIA Chrome 9 IGP, and Intel X4500 IGP video, locally on the console, on Xterminals on the LAN, and over VPNs on NX. Guess my configuration just happens to do well with nspluginwrapper. Lucky me.

Edited 2008-09-26 02:10 UTC

Reply Score: 2

RE[5]: And don't forget IE...
by hollovoid on Fri 26th Sep 2008 12:12 UTC in reply to "RE[4]: And don't forget IE..."
hollovoid Member since:
2005-09-21

is there a horseshoe and rabbits foot by your computer by chance. ;)

Its weird and from the plethora of posts ive gone through on forums, I know im not alone on this. luckily my need to use it is far and few between, but usually when I have it working, an update somewhere inevitably trashes it and im back to square one.

Reply Score: 2

RE: And don't forget IE...
by David Handlos on Thu 25th Sep 2008 20:42 UTC in reply to "And don't forget IE..."
David Handlos Member since:
2008-09-10

Looking back, you're right, I should have put that in the list.

Since it wasn't as frustrating as the ODBC Administrator issue, that's probably why it didn't make the cut.

Reply Score: 2

RE: And don't forget IE...
by evangs on Fri 26th Sep 2008 05:55 UTC in reply to "And don't forget IE..."
evangs Member since:
2005-07-07

Does a 64 bit browser make any sense? You need more than 4 GB of memory to run your browser?

Reply Score: 2

RE[2]: And don't forget IE...
by sbergman27 on Fri 26th Sep 2008 06:07 UTC in reply to "RE: And don't forget IE..."
sbergman27 Member since:
2005-07-24

Does a 64 bit browser make any sense?

Get rid of all the 32 bit apps and you don't have to have the 32 bit libs in memory. Plus you get the extra registers available in x86_64. Maybe some year the libs won't even have to be on disk. If we're going to do 64 bit, let's do 64 bit rather than this half-way thing with all the unnecessary (and confusing) duplication.

"Do or do not. There is no try." -Yoda

Edited 2008-09-26 06:08 UTC

Reply Score: 3

RE[3]: And don't forget IE...
by evangs on Fri 26th Sep 2008 17:39 UTC in reply to "RE[2]: And don't forget IE..."
evangs Member since:
2005-07-07

If we're going to do 64 bit, let's do 64 bit rather than this half-way thing.


I guess that's my point. There's no reason for the majority of people to run a 64 bit OS. What use is a 64 bit music player, video player, browser, IM or office suite? Numbers for commercial 3D and graphics packages do not show any significant improvement when run as 64 bit applications.

Cue some tard who will chime in with how I should go back to using an abacus or some such for not embracing "progress".

Reply Score: 2

RE[4]: And don't forget IE...
by google_ninja on Fri 26th Sep 2008 19:02 UTC in reply to "RE[3]: And don't forget IE..."
google_ninja Member since:
2006-02-05

Would mod that up if i could, 64bit is important for kernels and apps that need to address an insane amount of ram, and thats about it.

Reply Score: 2

RE[5]: And don't forget IE...
by sbergman27 on Fri 26th Sep 2008 19:44 UTC in reply to "RE[4]: And don't forget IE..."
sbergman27 Member since:
2005-07-24

64bit is important for kernels and apps that need to address an insane amount of ram, and thats about it.

I understand what you are saying, and agree to a point. However, as long as threads like this one are relevant, we do have a problem that needs to be solved. The 32 bit/64 bit thing involves overhead in the form of development time, testing time, user confusion, 32 *and* 64 bit libraries being loaded into memory, etc. etc. etc. Unless you think that 64 bit in user space is going to go away, we really need to move forward to a unified architecture for x86 if only for simplicity's sake, regardless of whether a 64 bit browser has measurable advantages over a 32 bit one.

I believe it was William of Ockham who said that one should not multiply architectures unnecessarily. And if he didn't he should have.

Reply Score: 2

RE[2]: And don't forget IE...
by tyrione on Fri 26th Sep 2008 08:13 UTC in reply to "RE: And don't forget IE..."
tyrione Member since:
2005-11-21

Does a 64 bit browser make any sense? You need more than 4 GB of memory to run your browser?


What's your reason for owning a computer. I mean, just get a phone and surf seeing as that seems to be the beginning and end of your existence to have one.

Reply Score: 0

Some additions
by google_ninja on Thu 25th Sep 2008 20:28 UTC
google_ninja
Member since:
2006-02-05

IIS can run either as a 64-bit or 32-bit process


This is true, however if you are talking about the need to run an ASP.net app in 32-bit, it is alot less drastic to flip the "Enable 32-bit Applications" flag in the app pool advanced settings screen.

Unfortunately, if the application was designed to run as a 32-bit application, it may run into dependency issues when moving up to 64-bit. For example, if the application depended on registry entries, system files, or ODBC settings that were set up for 32-bit applications, the program would likely fail, since it wouldn't be able to access those resources while in 64-bit mode.


One big thing I ran into was that JET interop simply doesn't exist in the 64-bit framework. I have an app that will import Excel files, and for the life of me couldn't figure out why it would work on one machine, but not another. If you need JET interop, go into the project properties in studio, go to the Build tab, and flip Platform Target from "Any CPU" to "x86". This will force the JIT compiler to generate 32-bit native code instead of 64-bit.

Reply Score: 2

memory limit
by dwave on Thu 25th Sep 2008 20:52 UTC
dwave
Member since:
2006-09-19

The paragraph about memory limits is a bit misleading. In 32bit address space you can reference up to 2^32 addresses, or 4 GB of RAM. If your OS limits your app to a lower ceiling, that's another problem.

As the 16.8 million TB of 64bit registers seems an awful lot, most consumer-grade 64bit-CPUs also have a built-in limit of how much memory they can really address. What's important is the width of the address bus. In AMD X2 CPUs this used to be limited to 40bit, upgraded to 48bit with the X4.

Reply Score: 2

RE: memory limit
by deathshadow on Fri 26th Sep 2008 01:26 UTC in reply to "memory limit"
deathshadow Member since:
2005-07-12

The paragraph about memory limits is a bit misleading. In 32bit address space you can reference up to 2^32 addresses, or 4 GB of RAM. If your OS limits your app to a lower ceiling, that's another problem.

Not ENITRELY accurate - since that address space needs to also be shared with any memory mapped hardware... Like video cards, audio card framebuffers and of course BIOS.

Which is why my Q6600 with 4 gigs of RAM can only address two and a half gigs of RAM in windows after making room for the 640 meg Ge8800GTS driving my primary display, the 512 meg Ge8400GS driving the outer two displays, the 128 megs of onboard ram in my old EMU Morpheus, the buffer allocation for the Audigy 2 ZS, much less the mainboard, etc. Even a machine with just a single video card and integrated sound is lucky to come up with 3 gigs of addressable space free.

Some OS get around this by swapping memory allocation as needed, but this can be slow as molassas and hang processes waiting for the swap to occur.

Reply Score: 3

RE[2]: memory limit
by PlatformAgnostic on Fri 26th Sep 2008 02:52 UTC in reply to "RE: memory limit"
PlatformAgnostic Member since:
2006-01-02

That's not an accurate way of describing what goes on. Given chipset support, you can simply map the extra memory 'covered' by the video card to a physical address higher than 4GB. There's no swapping involved. Windows does not enable this feature for client SKUs since video and audio drivers tended to barf on a 32-bit system when given a physical address bigger than 32 bits.

User mode processes get 2GB of virtual space by default. I'm curious about why this is limited to 800MB for IIS, but swapping is not involved at all regardless of the reason.

Reply Score: 2

RE[3]: memory limit
by salgau_catalin on Fri 26th Sep 2008 04:05 UTC in reply to "RE[2]: memory limit"
salgau_catalin Member since:
2006-01-08
RE[3]: memory limit
by deathshadow on Sat 27th Sep 2008 03:43 UTC in reply to "RE[2]: memory limit"
deathshadow Member since:
2005-07-12

That's not an accurate way of describing what goes on. Given chipset support, you can simply map the extra memory 'covered' by the video card to a physical address higher than 4GB. There's no swapping involved.


and that memory is bus accessable to the CPU (and by extension system RAM and the HDD) across the PCI x16 bus HOW exactly? Oh wait, you have to memory map it into that bottom 4 gigs to access it - in other words a memory swap - with all the headaches of protecting the RAM being swapped out from being accessed.

Nice try though.

Reply Score: 2

RE[4]: memory limit
by PlatformAgnostic on Sat 27th Sep 2008 08:33 UTC in reply to "RE[3]: memory limit"
PlatformAgnostic Member since:
2006-01-02

Not exactly:

Imagine you have two processes on an x86 machine. Each one gets 2 GB of private virtual address space. Let's say that each one is using 1.5 GB of space. Let's also assume that the kernel is caching 2 GB of file-backed data in the file cache. You've now got 5 GB of physical memory consumed.

One thing to note here, is that you don't have to have memory mapped into the user or kernel virtual address space for it to be used as cache... the Windows Memory Manager will happily keep cache pages around and keep track of them without consuming any of the 32-bit address space (except for some small control structures).

Even if you ignore the file mapping thing, each process gets 2 GB of address space and you already have to swap between them when you switch to a thread of a different process, so if you open four 1 GB images in 4 instances of Photoshop, you can consume 4 GB of RAM on a 32-bit system (assuming you had an Advanced Edition of Windows Server).

The reason this wasn't allowed on Client SKUs was that if you tried to use the typical GPU driver in this situation, the system would barf when the physical addresses are truncated by the driver and passed to the hardware.

Incidentally, the PAE-enabled Windows Server kernels do not support nearly as much memory as the 32-bit hardware with PAE supports because the per-physical-page descriptors begin to take up a whole lot of space and these have to reside in mapped virtual memory. I think the capped limit is no more than 900MB worth of these PFN entries (at 28 bytes per page, that's 32GB of physical memory supported).

Virtual memory is a lot more subtle than you think it is.

Reply Score: 2

.NET and Java diffs
by salgau_catalin on Fri 26th Sep 2008 04:20 UTC
salgau_catalin
Member since:
2006-01-08

"Microsoft.NET applications may be able to run in 64-bit mode automatically"
I somehow doubt this. Executable files have a Machine type value in their header. This tells Windows what architecture that file was made for. If you try and run an AMD64 file on a 32 bit Windows build, you'll get an error stating it's not a Win32 executable.
While I haven't read the background on WOW64, I doubt it makes an exception when it comes to .NET applications.
A .NET application is a normal windows application that imediatelly calls the .NET framework. While Windows could in theory have exceptions in place, that would make it very unflexible and modifications to this would need WOW64 updates.
So I'm betting on two .NET runtimes, 32 and 64 bits, that make no effort to update 32 bit code to 64 bit.
On the other side of the box, the Java JIT compiler should be indeed capable as the Java application itself is platform independent and any features unavailable on a 64 bit CPU would be worked around by the VM, at a small speed cost, on other architectures.

Reply Score: 0

RE: .NET and Java diffs
by jayson.knight on Fri 26th Sep 2008 05:34 UTC in reply to ".NET and Java diffs"
jayson.knight Member since:
2005-07-06

All that sounds good except for one thing...you're wrong. The code is JITed on the fly to be compatible with whatever processor it's running on. IL is processor/machine independent and is agnostic to the differences between 32 and 64 bit platforms. The .Net framework itself takes care of that at runtime.

Reply Score: 3

Curious About One Thing
by jayson.knight on Fri 26th Sep 2008 05:41 UTC
jayson.knight
Member since:
2005-07-06

What do you mean by "64-bit applications cannot access 32-bit libraries, or vice versa" I think you might be misinformed, but I would like to hear you expound a little more into this.

Edited 2008-09-26 05:41 UTC

Reply Score: 2

RE: Curious About One Thing
by PlatformAgnostic on Sat 27th Sep 2008 03:46 UTC in reply to "Curious About One Thing"
PlatformAgnostic Member since:
2006-01-02

They cannot make direct calls to each other... you can't load a 32-bit dll in a 64-bit program and expect to call into it because there's no good way to switch processor modes when doing that or to provide the correct views of data that's above the 4GB line. There are a couple of other technical reasons why this is impossible.

There is an extensive user-mode thunking layer that allows 32-bit executables to communicate with the kernel, and with RPC servers in other processes, but that's the extent of it.

Reply Score: 2

Push to x64
by REM2000 on Fri 26th Sep 2008 08:28 UTC
REM2000
Member since:
2006-07-25

Just like the push to 32bit from 16bit, during the transition many people thought why do i need to upgrade to 32bit, i don't have anywhere near 4GB RAM, i only have 2MB, 4MB, 8MB etc.

I know aswell as memory there are other architectural reasons to complete the move.

I think it's important that users start the mirgration over to x64 OS's. Drivers will be created, software will be developed, ready for when we do require x64, which personally i think is sooner than alot of people think.

More and more people are watching HD movies on their computers, recording tv shows on MCE computers. The standard is 2GB RAM on PC's, how long before that changes to 4GB RAM and that to 6GB or 8GB RAM?

We need to start getting into the mindset ready for the migration so we don't have a last minute scrabble.

I mean if your next PC came with 4GB or even 8GB RAM wouldn't you want to use it all? I know many people will say they only use their computers for email and surfing, however a lot of people also use their computers for games, video editing, image editing etc, all three OS's Mac OSX, Windows & Linux are all incredibly stable thus allowing for more and more applications to be mutlitasked and ran at the same time, we have more background tasks (music playing etc..).

I hope Microsoft start a push in the consumer space for x64 windows, even if the machines come with 2GB RAM, just prepping everyone for the migration is worthwhile.

Edit : Thought whilst watching the article on MultiTouch.

The other thing i suppose to bear in mind is new technology. So for example if the multitouch system explained in the other OSNews article is ready for release but requires 1GB/2GB of RAM to run then again x64 will become a Necessity.

Edited 2008-09-26 08:36 UTC

Reply Score: 3

Mad design decisions
by moltonel on Fri 26th Sep 2008 09:36 UTC
moltonel
Member since:
2006-02-24

I usually avoid bashing Windows and comparing to Linux, but come on :

* 32bit libs in "SysWOW64" folder, and 64bit libs in "system32" folder ? Makes perfect sense (sarcasm). Same goes for "program files" folder, even if less troubling (but why do those need to be in different folders at all ?).

* Separate configuration locations for 32bit and 64bit (in registry) ? Who stores bitwidth-sensitive data in there ? And relies on the OS to handle the case when both 32bit and 64bit versions of the program being installed at the same time ?

* Configured data sources (ODBC) only working for n-bits program if configured via n-bits GUI ? I'd really expected better.


Compare this with Linux, where there a "/lib32" and a "/lib64" folder which contain the expected, plus a "/lib" symlink that points to "/lib64". All the rest (configuration , applications, etc) is in the standard (bitwidth-agnostic) locations. I've been using 64bit Linux on my laptop since 2004, and it allways worked just as well as my 32bit machines.

Of course I know why Microsoft does these kind of hacks : backward-compatibility. That's the price paid for proprietary software, which often won't issue any update once the package has been sold. And Microsoft has been blessing this behaviour by working around 3rd-party bugs in each new version of Windows. They've been doing it for at least 15 years, and can't turn back.

Pardon the pun, but the bazaar is much tidyer and well-kept than the cathedral.

Reply Score: 4

Mixing 32-bit/64-bit
by tdemj on Fri 26th Sep 2008 17:15 UTC
tdemj
Member since:
2006-01-03

In order to mix 32-bit and 64-bit code, you have to make your library an out of process COM server.

Device drivers (including printer drivers) must be 64-bit on x64.

Reply Score: 1

Running Vista? Get 64 bit!
by werfu on Fri 26th Sep 2008 21:47 UTC
werfu
Member since:
2005-09-15

Seriously, do you know any casual user (I mean like my mom), that would bother because their 64bits system files are installed into the system32 directory? All of these excuse are somewhat doubtfull when it come to ordinary people. Except for badly written application, all of the WoW64 layer stuff should be transparent.

What advantage is there to run 64bit? Hum, let me see... RAM!!! Vista loves RAM. It love it so much that it can but rape your hard drive so hard that it will be screaming "Help I can't handle that page file anymore! " I work in a computer store (custom built) and we sell lots of RAM. Our standard family system has 2gigs of RAM and our gamer one begins with 4gigs. We sell 8gigs system more and more often. A lot of people who take Vista get the 64bits edition too, just because they wont have to reinstall their machine when they'll add more than 3.5gigs of RAM.

What I'm recommending, is that if you're running on Vista and not planning on using old or esoteric hardware, get 64bits. The performance difference is minimal, and the memory usage only increase slightly. Most drivers are now stable in both version and theres more and more application that can take advantage of more RAM. Just give it a try. If you don't like it, than reinstall to 32bit, your OEM license do both ;)

Reply Score: 2