x64 WindowsXP OR x64 Windows Vista

[Angelico_Payne]

x64 WindowsXP OR x64 Windows Vista ???

(*colour coded by SOD -Screen of death )

A friend of mine installed x32 Vista on his computer, along with x64 XP.

He claims that it works times better than x64 XP, usability, funcionality, games color/sound...

So he says : "Gosh, if x32 Vista works this great, x64 must be a mind blower!!!"

Well I must admit it looks esteticly more beautiful, I'm steptical...

What do you think - Is x64 Vista that good?!

How anyone tried it out?

[Innocent Devil]

Untill OEMs build x64 drivers,

s/w ppl build x64 versions of x86 apps

(evethough almost all 32bit apps works x64 -- it doesnt take the advantage of x64 platform,so x64 s/w required )

[Mr Snrub]

What do you think - Is x64 Vista that good?!

How anyone tried it out?

Unfortunately nVidia haven't produced 64-bit Vista drivers suitable for the 7800GT so I can't test it in depth, but I did have the 32-bit and 64-bit versions on my system a few builds ago.

They performed pretty much equally, but we are still a long way from any performance enhancing yet so I don't expect there to be a distinction between them.

The bugcheck screen in Vista is still blue, by the way.

Once Vista is launched I'll most likely be ready to replace my XP x64 installation with 64-bit Vista on my 2 main rigs, with a virtual machine running 32-bit XP for any legacy apps or IE plugins when I need them.

[ripken204]

vista will prolly be better. once vista comes out i wont be getting it, ill be wainting for the 64bit vers to come out. by then MS should have taken care of their bugs.

[Angelico_Payne]

So there are no drivers for GPU for Vista x64!!??

[Mr Snrub]

So there are no drivers for GPU for Vista x64!!??

Sure there are built-in ones, but how useable is the "Standard VGA Controller" driver which Windows falls back to for compatibility?

It's not fair to compare Vista 32-bit with Aero Glass in all its glory with Vista 64-bit having to use the unoptimized and poorly-performing compatible driver on the same hardware.

I have a system with an Radeon x800 and ATI have at least provided drivers that work with both 32-bit and 64-bit, but I've not used this other system much for testing.

[Angelico_Payne]

Aha tanx,

I've just been to ATI homepage, and there's an urtical about ATI working closely with MS, on improving and developing certain parts of Vista..

[cluberti]

...it doesnt take the advantage of x64 platform...

Actually, that's not entirely true. 32bit processes running on x64 now have access to 4GB virtual address space when running, rather than 2GB (or 3GB with the /3GB boot.ini option) in 32bit Windows. This can be a huge boon to 32bit application performance, like SQL 2000 databases or mail servers (not Exchange, as it doesn't run on x64 platforms), for instance. While they don't run in 64bit mode, they still get memory benefits.

[Innocent Devil]

That is not the advantage of x64 platform

it can handle HUGE amount, very more than the small 4GB

about 2^63 bytes of memory

however nos OS has support for that amt. (xp x64 support upto 128GB of memory only)

so if u build x64 app, u can see the diff. b/w having able to use full 4GB (x86 app) and 128GB (under x64 xp , & may more in linux)

[cluberti]

That is true, devil, but apps that are 32bit do benefit from running on x64 Windows due to the increased memory address space. Given the choice between 2GB and 4GB address space on a 32bit database, email, transaction (etc) server, would you not choose the 4GB address space over the 2GB? Yes, I agree using a 64bit app on a 64bit platform is preferable, but when that isn't possible, most 32bit apps run just fine on 64bit Windows, with the added benefit of not having to share their 4GB address space allocation.

[Daemonforce]

I am actually pushing for the 64-Bit builds. There is simply no point in torturing yourself with outdated garbage. My only regret is that minimum requirements go up in order to simply crunch numbers in an office with more "security."

Untill OEMs build x64 drivers

Working on it. Right after I build a 64-Bit machine capable of building this crap let alone understanding it.

s/w ppl build x64 versions of x86 apps

The 16-Bit software needs to run in an emulator just to run properly. A Win64 OS does not support this function. A Win32 is no better at this point because it will be the same case as trying to run a 16-Bit app with what I have now. I can officially state that everything I have at this point(Win32) is utter garbage and will be quickly replaced when the important vendors start spitting out 64-Bit binaries. These will run seamlessly with the operating system and it's far better than running the NTVDM for compatibility. I have so many issues about using NTVDM that I won't clutter this thread on why it needs to go. It just does.

That is true, devil, but apps that are 32bit do benefit from running on x64 Windows due to the increased memory address space.

This is the brick wall I'm facing with Vista.

Given the choice between 2GB and 4GB address space on a 32bit database, email, transaction (etc) server, would you not choose the 4GB address space over the 2GB?

Depending on the hardware, I usually go for anything between 1 and 2GB memory while using the least amount of modules possible. While the ability to go over is there, the reason for this choice is performance. I'm an overclocker and I need to state that adding module after module appears to hinder the machine because it's focused on using more and more precision hardware at once. Same thing when adding drives and power hungry peripherals. Oversized modules seem to create some performance problems(unstable) with the hardware I mess with and over time I find it better to use as few modules as possible if I hope to squeeze as much performance as I can. Trying to keep performance from being a slow crawl is the next problem. My solution? Overrated ram. It pulls through for my workstations and my Intel 3.00E can crunch numbers at a pace that competes with an Athlon FX53. Now the problem is price. Either you shell out $$$ to complete a build that keeps you at peace from the aggrevation of waiting on tasks, or the end result is just a pile of garbage that p***es you off because you can't do what you want at the pace you need.

Unfortunately, like we all realize, the decisive move you make here determines the period of time it takes for your new unit to fall into the later category. All machines have a lifespan and you're spending quite a bit of cash, so make it count. =/

The trick is building a computer intended for a set of roles that will function for a very large period of time so that you don't have to worry about it every few weeks. With each new feasible build, it appears that the speed that these boxes hit retirement is increasing at an exponential rate. When I first took a look at 64-Bit computers I expected these to be around for a long time. They will be. They still are. It's also making junk out of everything made before 64-Bit technology became feasible to the end-user. This is my biggest problem right now.

Moral: When you see an impact in the computer market that easily forces 75%+ of all previous builds to retire within a matter of months, it's time to wait for a while for the new hardware to take off and start over with the newest hardware available. You don't want to keep pushing for something where most of your production applications become unworkable upon the next operating system change.

Now lets talk about Windows XP. It was introduced and targeted to most if not all users by 2001. All the current flavors of it have been established as of last year. XP is a very stable operating system and compatible with the several unique applications produced. One exception to this is the x64 build. Windows XP 64-Bit Edition is the only XP flavor in its class and appears to be the missing link when looking for the Web Edition of the 64-Bit Windows Server 2003 series. I have concluded that Windows XP64 absolutely will not install in any environment outside of DOS. I can't even run the setup autorun inside of Windows. If you boot the disc, setup needs to examine your hardware before entering the BSOI(This fails if your machine doesn't meet the requirements). The preinstallation data is a bit scattered across the CD, but runs like a clone of the other flavors. Driver support is minimum. By minimum I mean none. o_O Some applications are made to take advantage of XP64, but none of significant importance. Hardware utilization is a bit interesting since you can add and use about as much hardware as a server OS is willing to detect(with the right drivers if needed and available...o_O). Other than that, performance is pretty good on a machine designed to handle it.

Then there's Vista...

Vista is the most horrible operating system I have seen at the current mark. To start, it's packed about 1GB bigger than it was at the PDC03 stage and expands about 3x bigger than the PDC03 builds. It doesn't play nice with virtual machines(video and disk). Installation takes upwards of 4 hours where PDC03 and XP average 20-30 minutes. The overall functions when finished are medicore at best. The start menu has gotten a few cosmetic revisions and functions seem to stay under one solid menu for scrolling programs(EW!). Icons look nicer than I've ever seen but hog resources. Drive descriptions are so complete that the most simple X86 PC noob can understand. It looks like server tools are broken at this point(no IIS 7.0). The machine "hiccups" every few seconds as if it's reading/writing random spots on the drive. The repository eats upwards of 2GB and the system is using half of it all the time for God knows what purpose(blame indexing service). Now here is the good part: The boot manager. Remember when you used to get a black screen with errors about missing files/directories followed by a reboot when you hit a key? Doesn't happen anymore. Vista uses a local boot manager located on the system root. You add winload to your system directory and add an entry to your boot.ini called USENEWLOADER and you magically get a pretty boot manager complete with operating system boot assignments and even listed hex errors with nice little details in English! Hitting a key at this point? No more reboots, it just goes back to the boot manager so you can quickly make another choice. This is by far the most useful. I plan on adding this to a CD/DVD soon to force-load HALs, PAE or loading everything in ram. This is going to be a lot of fun and it will be even more fun if I can utilize it for the Vista preinstallation environment.

Overall the performance is crap on pretty much any system you use. God forbid I load it onto a computer powered by some K6 or equivalent. You're definitely going to want a lot of push and shove after you deploy Vista. There is talk of 64-Bit builds in the making and I will definitely be pushing for it. I hate to say it but this just isn't 32-Bit territory anymore. For anything other than the newest hardware, it's a total warzone where you're struggling when just browsing directories. I'm hoping the RTM builds will work better than this garbage, but it's very unlikely. We'll have to see if and when it finally gets to that stage.

Yes, I agree using a 64bit app on a 64bit platform is preferable, but when that isn't possible, most 32bit apps run just fine on 64bit Windows, with the added benefit of not having to share their 4GB address space allocation.

Edited February 21, 2006 by Daemonforce

[cluberti]

s/w ppl build x64 versions of x86 apps

I also have to state that building an x64 version of a 32bit application shouldn't be hard for most vendors - assuming they aren't using direct access to functions and are using the default exposed Win32 APIs, a relatively simple code review and recompile using an x64 compiler should be all that is needed. Now if a vendor uses filter drivers, direct access to functions, built-in application memory management outside the NT memory manager, or any other such type function then yes, building an x64 version of that application will require some work.

[Daemonforce]

s/w ppl build x64 versions of x86 apps

I also have to state that building an x64 version of a 32bit application shouldn't be hard for most vendors - assuming they aren't using direct access to functions and are using the default exposed Win32 APIs, a relatively simple code review and recompile using an x64 compiler should be all that is needed.

Hey lets make Win32s dependent on the .NET Framework!

The Win32 wars....Begun it has.

Now if a vendor uses filter drivers, direct access to functions, built-in application memory management outside the NT memory manager, or any other such type function then yes, building an x64 version of that application will require some work.

I'm glad I try to keep things simple.

[Innocent Devil]

What about Win64 APIs ??

is there any ??

@Daemonforce

About Windows installation time

It always need moooore time 2 install such a big (Vista is abt 3GB) os compared 2 win xp (~550MB)

But why windows setup is very slow compared 2 Linux ??

I install win xp in 20 mins ,end up with < 1 GB hdd consumed (of course nLited)

Then i install SuSE Linux 10 OSS in 30 to 40 mins and it trasferres abt 6GB

So inherantly windows setup is slow

Edited February 22, 2006 by Innocent Devil

[cluberti]

What about Win64 APIs ??

From the Microsoft site:

Developers with 32-bit Windows skills will be comfortable and productive creating the next generation of application for Windows XP Professional x64 Edition. Developers will find the development environment virtually identical to the development environment for 32-bit Windows; the Microsoft Win64™ application programming interface (API) is the same as the Microsoft Win32® API. The existing APIs have been modified where necessary to allow them to reflect the precision of the platform on which they are running. The result is programming simplicity and a short learning curve for the developer—writing code for 64-bit Windows is just like writing code for 32-bit Windows.

As to Windows setup time being slow, yes, Vista is a slow, slow setup. Windows XP setup rarely takes me longer than 30 minutes though, on midrange hardware. You have to remember that Windows setup is registering a lot of system components, not just copying files over to the disk.