Why is Windows 7 64-bit not 64-bit?

Sounds to me like you'd be happier in the Linux world, Spock3. The shells have gotten much better over the years, providing a GUI almost as user-friendly as Windows. But the best thing is being able to tailor it exactly as you wish.

No operating system is perfect. I wouldn't say Windows is "far" from it. Considering what else is out there, they do a lot right while helping you avoid resorting to coding (there's plenty of 3rd party apps to help you do almost anything).

In my mind, we'll probably need a computer to create it's own version of an operating system before it's nearly perfect. Why? Because it'll be super efficient and won't try to protect itself from customization. The "core" and "shell" approach works. Windows is still too intertwined within itself. Ideally, Windows 9 would be a rock solid lean operating system where you could overlay any shell you wish upon it's open API. You could end up with shells that look like iOS, Windows 7, or any popular flavor of Linux. But that will never happen in Windows. Microsoft has profit making interests as top priority.

It's already been very well defined as to what operating systems need to provide in a given hardware environment. They need to provide functionality efficiently and reliably, as well as cope with process co-existence, security and priority. Then all you need is a user interface shell attached to monitor and manipulate it. Device compatibility? All you need is a driver for it and a comprehensive SDK would make it relatively easy to allow almost any device to work seamlessly.

But then quantum computing will come around and shake everything up again.

I'd recommend either buying better hardware so you're not grasping straws to improve performance, or learn Linux and build your own "prefect" system. Since you have such a clear idea of what makes a perfect system it shouldn't be hard.

...Well I have an answer for you. Use real musicians that play real music. It would probably sound better and you can record it and mix it on your PC, I know I could do it on mine![/QUOTE]

That's not an answer. There is nothing wrong with virtual instrumentation. As for what sounds better, that's a matter of individual taste. And virtual instrumentation uses up no more Ram than real instrumentation (which also costs one heck of a lot more and is far more cumbersome to use). While I will agree the OP is overly concerned with whether his system is pure 64 bit or not, your "answer" is not an answer.

Lady Fitzgerald said:

...Well I have an answer for you. Use real musicians that play real music. It would probably sound better and you can record it and mix it on your PC, I know I could do it on mine!

That's not an answer. There is nothing wrong with virtual instrumentation. As for what sounds better, that's a matter of individual taste. And virtual instrumentation uses up no more Ram than real instrumentation (which also costs one heck of a lot more and is far more cumbersome to use). While I will agree the OP is overly concerned with whether his system is pure 64 bit or not, your "answer" is not an answer.[/QUOTE]

I know that, he has been winding everyone up so and dismissing everything everyone suggested so I came up with that as a joke

Spock3 said:

"He's a dumb ass or a troll!"
This seems to be the best answer so far.
I didn't know you have such people on this forum.

Yup! Those who don't understand logic are dumbasses. And since I said you're a dumbass or a troll, I have come to the conclusion that you're not a troll.

32-bit processes can't load 64-bit DLLs and 64-bit processes can't load 32-bit DLLs. By default, 64-bit applications can use 8 TB of user mode address space. There is the option to specify that all memory below 2 GB be allocated to the application. Because 32-bit DLL can't address memory space above 2GB, the thunk layer would have to copy all data into the low 2GB of the 64-bit application. Obviously, this won't work if the 64-bit application tries to pass a pointer to data that is larger than 2GB.
Also 32-bit DLLs use x86 style exception handling and 4K pages. On an IA-64 processor, the native page size is 8K and the WOW64 emulator is responsible for simulating 4K pages. Because on an x86 machine exceptions do not "unwind" from user mode to kernel mode and back, WOW64 implements x86-style exception without switching from x86 code to IA-64 and back.
Finally, another reason why 64-bit and 32-bit processes can't load each other's DLLs is that system DLLs (kernel32.dll, user32.dll, and gdi32.dll) expect only one instance per process, 32-bit or 64-bit. If a process contained more than one instance of, say user32.dll, Win32k.sys will not be able to distinguish between them and wouldn't know which one to call.
So a 64-bit application must have all the Dll that are 64-bit.
And therefore I ask again why does Windows 7 Ultimate 64-bit still have 32-bit dlls??

And your comment on the text is what?

Spock3 said:

And your comment on the text is what?

you can copy and paste text about workings of 64bit windows.. is there anything with the 32bit code in 64bit os that stops you from doing your work?
what practical problems do you have with your os.. not something you think or read or imagine.. are your work hindered in anyway?
and is those problems really because of 32bit code in 64bit windows?
if you just want 64bit pure windows 7.. no one can help you windows 7 is the way it is.