...are not enough.

It's funny, I just saw someone talk about something in our source code, using the phrase, "it's 32 bits so we won't run out."

Surely it depends on what he's describing. If it's an id that only updates once a day then he's probably right. I wrote a booking system that used 32 bit ints to reference its bookings, of which there are between 2 and 3 hundred a day. Given that anything older than 12 months old is purged even when the counter wraps round (in a couple of hundred years or so) everything will still work. I could probably used something smaller.

However if you're talking about address space then maybe when you're opening large datasets having only 32 bits will cause problems.

And 640 is more than enough for anyone...

In this particular case, memory addressing.

At my previous job, I saw things smack the hard wall of 32 bit limits, and slowly transition to 64 bit. And here I am, different job, and seeing the same thing again. And it is frustrating to see things are actually worse now for the consumer space. Plenty of warning that problems were coming, and nothing.

Well, I suppose I should specify here, this is mostly a Windows desktop issue. Windows server has been out as 64 bit for a while, and the major apps too. Linux has been ready for a long time, but hasn't broken into the consumer space in any serious way as a desktop platform. OS X is ready, but only just recently, and still is a small segment.

Microsoft? Gleefully still letting OEMs ship out 32 bit versions of Windows, even on boxes leaving the factory with 4gb of RAM. No unification of the installer to just do the right thing. And it's going to bite a lot of people hard here soon. It's already happening in the enthusiasts areas, it's only a matter of time for the rest of the space.

I also saw first hand today how Vista 64 doesn't handle things well when put under pressure. Running a process that was chewing on all four cores on my processor, and taking about 1.7-2.0 gb of ram. Things were ok for a while, but I walked away and the screensaver and lock occurred. Came back, and waited over 3 minutes for it to decide to unlock. And then found the source of the slowdown. My process was stalled, but still had memory held. And the display system (likely Aero) had 2.9 gigs of memory. How did this OS ship again? And why didn't SP1 fix anything? I was so frustrated by this that I reloaded the box with XP Pro 64 bit before calling it a day. I mean, I know Vista sucks. But we said XP sucked too when it came out. But not nearly this bad. XP was at least usable.

*sigh*

And a dirty little secret is that, on many many systems, any RAM beyond 2GB (or sometimes as much as 3GB) actually requires 64-bit addressing on most Intel-based platforms.

Cheers

Yep, that too. People think the limitation is 4gb of RAM, but it's 4gb of addressable space. That video card RAM, NIC buffer, and tons of other things need to be in the addressable space of 32 bits somewhere, so it pushes out RAM from being usable. I didn't even try to load a 32 bit os on my Mac Pro, but a friend did on his, and he only gets 2gb usable.

Certain higher end servers running 32 bit OSs would boot with a gig or less of usable RAM, due to all the address space reservation for hot plug PCI slots and other components. That was where PAE was used as a bandaid until things could move to 64 bit on x86. PAE doesn't work well for performance though, and it's pretty much a nogo for the consumer space since the video card RAM often gets pushed out into a separate 4gb space that has to be paged into.

Intel and Microsoft were so convinced Itanium was going to be the 64 bit migration path that they didn't bother with a plan B. And now many of us get to feel the fallout of that decision years later. It's a shame AMD is falling behind again, their Athlon 64/Opteron was a good kick in the teeth to Intel to get them back in gear. Sure it cemented x86 as the common PC architecture for a while longer, but it prevented everything from hitting a brick wall when the Itanic sank.

Yawn.



(Yeah, I know. OSF/1 was before that.)

"The "2." was dropped from the version name since Sun had no plans for changes so major and incompatible to justify a Solaris 3.0 release, and was running out of unambigous 2.x numbers (2.10 can be read as either "two point ten" or "two point one zero", one of which implies an upgrade from 2.9, the other does not). (Plus Sun marketing was rumored to want to point out Solaris 7 > NT 5, but then Microsoft renamed NT 5 to Windows 2000 the next week.)"

Yeah. Sun's always has odd notions of marketing. ISTR that they had sendmail skip from version 4 to version 7 in order to make version numbers match. (Of course, they then modified it to require a Sun-specific configuration file version number that prevented you from using any of the new features.)

I got a new laptop recently. I'd like to run Vista or 2008 x64, but I can't get x64 drivers for everything on it...

My server, on the other hand, has been running Windows 2003 x64 quite happily for about 18 months now (with Ubuntu and Debian running under VMware).

Yep, and we all know how successful Solaris has been as a consumer desktop OS... :-P

Thats probably what frustrates me the most about my current situation in consumer land. The warning were on the wall for a long time because of the server transitions years back. But, here we are:


The one issue I have at home with Vista x64 (besides it falling on it's face when pushed hard) is that Cisco doesn't offer a 64 bit version of their IPSec VPN solution. Downgrading to Vista 32 bit and only 2gb of RAM just doesn't work either.

Does Vista not allow running of 32-bit apps alongside 64-bit ones ??

Effectively, it's a kernel module, and needs to match the kernel's ISA.

Yes it does. Windows doesn't support running 32-bit drivers on a 64-bit OS (or vice-versa). Windows doesn't (in general) support loading 32-bit DLLs into 64-bit processes (or vice-versa). To do this, you can provide both 32-bit and 64-bit DLLs (as various shell extensions, e.g., do), or you can provide 32-bit or 64-bit thunking DLLs. Or you can provide your stuff as COM components (which, simplifying the technical details, provide transparent thunking in a lot of scenarios).

Presumably, the VPN software is either largely implemented in a kernel module (which would need to be 64-bit), or it's a Winsock layered service provider (which is, IIRC, a user-mode DLL), and therefore needs to be available in 32- and 64-bit versions.

PAE ~=~ LIM EMS, as far as I can tell...

Ah, for the days when Lotus had that sort of pull on the industry. Or when the most advanced applications were spreadsheets. (I bet Google Docs' spreadsheet is more powerful than 1-2-3 was when EMS was developed.)

Ah, you're making me remember back to the early-to-mid-90's when SGI (MIPS) had all these different compiler flags
so you could easily build 32-bit apps, 64-bit apps, 64-bit apps with 32-bit libraries, etc., etc.

Let's see, when did the 64-bit MIPS R4000 come out? 1991 ?

Of course, Windows was yet a few years away from leaving 16-bits -- despite having had 32-bit x86's available since 1986 or so.
And MacOS wasn't making very good use of its (pseudo) 32-bit 68000.... (available since 1978 !)