Originally posted by: JustaGeek
...
When I migrate to the new, "better", "SUPERIOR" (uhumm...) Operating System, I expect the programs with my paid subscription to work.
They don't.
SpySweeper, Registry Mechanic, System Mechanic, all these programs that give me (however false) sense of security MUST work - but they don't...
The application developers should write 64-bit versions. It's been...what?...twelve months now?
You paid for the software, right?
Microsoft does publish workarounds (and a compatibility database) to fix (or notify the user of) buggy third-party programs, but sometimes the original developers have to fix things!
And frankly, I don't care if there were implementation problems with XP back in 2001.
There were implementation problems with Windows 95, 98, 98SE, Me, NT, NT 3.51, NT 4.00, 2000, XP, 2003 Server, and anything I've forgotten. Specifically, 95, 98, and XP all had various compatibility problems with system utilities and security software because sometimes new OS features break old interfaces (or hacks, as the case may be). In this case, the new features are clearly superior, but they will just as clearly result in an inferior experience for some end users until third-party software has been updated.
How can YOU claim that Vista 64 is SUPERIOR, and then say "Oh, yes, the problems, well, it's expected."
No - not with the "Superior" system.
I realize you paid for specific security software, but I fail to see how your system is less secure just because you moved to Vista x64. The OS already has a decent software firewall. apoppin linked to a third-party firewall that is likely much stronger. Many people, like me, also use routers w/ firewalls. I don't see the problem here. Windows Defender is fine for what it does, and regular updates are free. Avast is good if you need antivirus. There are other free alternatives.
And everything that DOES work, WORKS in 32-bit mode.
Huh? Don't you mean
most things?
For many pieces of software, 32-bit mode is either better or equivalent to 64-bit mode. This is true because there are inherent disadvantages to 64-bit code -- namely, code and data sizes are larger -- and this can offset the inherent advantages to 64-bit code -- namely, more general-purpose registers, native 64-bit math, and better support for large memory usage. Programs that access the disk a lot (which usually requires 64-bit math), do intensive integer calculations, or use lots of memory can show a very large increase in performance when compiled and run as 64-bit code. But compiling the whole operating system to 64-bit would be stupid when 32-bit programs can be run on the same OS and processor with little or no performance penalty. Who cares if Notepad or Messenger have a ~1-3% performance increase when the code size has increased dramatically?
And honestly, I don't understand your argument with the 256 and 768 Video Cards.
A 32-bit system has only 2^32 or 4 GB of virtual address space, into which both system memory and video memory must be mapped. With 4 GB system memory, video memory will effectively "hide" system memory. And when you compare test results under these conditions with video cards that have different amounts of video memory, the amount of usable system memory will also vary between the two systems. So you are benchmarking a computer with 3.0 GB system memory against one that has 3.5 GB system memory -- not very fair (even though I think it would make little difference in the fps graphs).
That said, I would greatly prefer Vista x64 benchmarking for two reasons:
1. If all the benchmarks are 64-bit, that is where the performance optimization will occur, and 64-bit drivers have generally lagged behind the 32-bit drivers -- sometimes by large margins.
2. chizow's arguments will only become more valid over time -- why not switch now?
3. 64-bit benchmarking would prevent arguments like the one in this thread.
AFAIK, the Graphics Drivers are still written in 32-bit code, and that makes them address the same area from the 4GB Threshold down. It will not be automatically freed-up for your applications to use. The driver will still be addressing it between 3.25 to 4GB range, or 3.75to 4GB, plus all the PCI memory within the same range, even on the 64-bit platform.
From everything I have read, 32-bit kernel-mode drivers
will not work in a 64-bit OS. When the kernel is compiled as 64-bit, so must the drivers. However, much of the source code for the 64-bit driver may have been ported from the 32-bit driver. (Producing 64-bit machine code is just as simple as flipping a switch; nevertheless the code itself must be checked and quite possibly fixed/reoptimized to make the driver run as 64-bit code.) 32-bit driver code that is not ported
well will not work well (or even at all) in 64-bit mode w/ memory remapping.
Why...? Because all the drivers are (again) designed in 32-bit code, and implemented, or rather adapted, for the 64-bit system.
That is partially true, but are you sure you understand the implications?
nVidia said they had to rewrite their drivers from scratch for Vista. The source code (i.e. the set of keywords, functions, and variables from which the binary versions are normally generated) is neither 32-bit nor 64-bit. If they started over, why would nVidia not make the bulk of the new driver source code portable (i.e. independent of bit-width)?
However, it does seem logical that nVidia would create specific optimizations for the 32-bit machine code; after all, most people with nVidia hardware are using 32-bit operating systems.
IMO, the area between the 3 - 4GB will be "dead" for the users forever - it just makes sense, for compatibility reasons.
You are confusing physical address space (i.e. system memory) with virtual address space, which can be mapped or remapped to just about anything including ranges of system memory, MMIO, video memory etc. A 64-bit system has 2^64 or 17,179,869,184 GB of virtual address space.* That's plenty of space in which to map 4 GB of system memory, 1 GB of video memory, and whatever else is needed by other devices.
* IIRC, the AMD64 architecture uses less than 64-bit addressing, but it's far more than we will need in the next few years.
This 1 page
article with a nice graph shows it best.
The graph is misleading. As the last paragraph explains:
Conclusion: Windows XP x64 Edition and Windows Vista 64-bit eliminate the 3 GB to 3.4 GB RAM allocation limit on x86-based computers with large address infrastructures like the HP workstations listed above, and the memory remapping feature in the HP Workstation BIOS even recovers the RAM in the PCI address range (MMIO) by remapping it above the top of physical RAM. Therefore, nearly all the physical RAM can be made available.
Memory remapping shuffles virtual address space around as needed to make additional room for device memory. Specifically, the video memory and MMIO get relocated to higher virtual addresses (i.e. above system memory). This frees the system memory in that range for use by the operating system and applications.
And please, with all due respect - please stop that "superiority" nonsense. If it doesn't work properly, it is not superior.
The OS itself is superior.
Your
computer with the OS and some incompatible product keys is what is inferior.
If Microsoft does not code workarounds for your security software, and instead the third-party developers actually produce 64-bit versions of their software, how will Vista x64 have become "superior"? The answer is that your definition of "superior" is completely relative to your own situation and not an objective problem with Vista x64 at all.
How can you fault an OS for something that one cannot reasonably expect
the makers of the OS to fix? To me, the people who need to shape up and produce non-experimental code are the ones who haven't even made their 64-bit capable security software publicly available -- not the ones who spent years producing a great 64-bit OS.
Let's call it "experimental" for now.
No, it is production-ready, or at least as much as 32-bit Vista.
Facebook
Twitter