Windows Vista - 64 bit in the Mainstream

Play Windows Vista - 64 bit in the Mainstream
Sign in to queue


Gary Schare and Bruce Burns sit down (well, sort of, Bruce stands, Gary leans) with us to talk about the sudden uptake of the latest Windows 64 bit client OS. It's very encouraging that Windows 64 is finding its way onto consumer client systems and into mainstream computing. This spike in uptake also poses some challenges for ISVs who are not 64 bit "ready". 32 bit Windows applications should just work on 64 bit Windows, right? Well, sort of. Tune in.



Download this episode

The Discussion

  • User profile image
    i love vista but the inability to load unsigned dirvers just sucks.. thats the only reason i dont go 64 bit right now :/

    its not like vista64 cant load em either, its just that someone decided that it shouldnt be allowed even if i know what im doing.. thats erally user unfreindly.. it the exactly the kind of thing microsoft haters bring up when the say that vista thinks its better than its user.

    could there please be an opttion to load unsigned drivers for every boot?
  • User profile image
    I have recently installed WinXP 64 bit and with the exception of some minor tweaks and driver issue (actually, I was just too lazy to fix the last device as I don't care for it) - I am happy with it. However, many programs were and are still being written for 32 bit systems, so if there was supposed to be better performance via xp64, I really haven't seen it and I even upped my ram to 4g on my laptop.

    I am however, very interested in a converted Server 2008 to Workstation because from what people have said, it is what vista should have been.
  • User profile image

    "I am however, very interested in a converted Server 2008 to Workstation because from what people have said, it is what vista should have been."

    Actually, this is entirely incorrect and doesn't make a lot of sense... Vista and Windows Server 2008 are fundamentally EXACTLY the same (minus the obvious server/client specific features and componentry that makes sense in each context - the core OS is the same OS. The differences are in tuning, security policy and shell for the most part - yes, server core is a server-only construct as are other server-related components and features - but, again......., they are fundamentally the same......).

    I don't understand this "Windows Server 2008 on the client" nonsense. It's a server OS, built for serving. Again, it is VERY similar to Vista architecturally. In fact, Vista and 2008 come from the same sources......


  • User profile image
    Adobe Photoshop is one of the few commonly used client applications that actually has some prospect to add real value with the extra memory that 64 bit clients make possible.  The fact that they are just getting around to 64 bit support should tell you something about how little real value most customers can expect from all that extra memory.  Of course, once all the compatibility issues for 64 bit have  been dealt with, there will be no reason not to use 64 bit.  But only users of very selected applications are going to see any real value from it.

    As Charles points out, many core does not come for free.  Few companies are going to invest in parallel processing unless they are going to be able to show their customers some real value from it.  People who think advances are adopted just because technophiles think they are great should take a look at the history of IPV6.  Today, many core also does not come for free from a power perspective.  People who expect users to burn that power just to make some lights flash faster should take a look at the history of the Pentium 4.
  • User profile image
    Charles, while I agree that they are fundamentally the same operating systems there seems to be a big difference in the user experience between Vista and Windows Server 2008; meaning that users on the server operating system find it more stable and responsive. I guess this is because of the different tuning (as you mentioned) and actual components that are loaded in memory - or that Vista is not tuned to the workloads they throw at it.

    I run Windows Server 2008 x64 on a box with 8 GB of RAM and am truly enjoying the benefit of more RAM (and it even plays nice with Call of Duty 4). There is no way I'm ever going to install Vista (again) on my box and it's by far the best development setup I've seen (you've got to love the combination of VS 2008 SP1, .NET 3.5 SP1, IIS 7 and SQL Server 2008).

    See you at the PDC (wahoo).
  • User profile image
    I just think the "why not load unsigned drivers" is rather silly / foolish and not the right way to go.

    if it were up to me *ALL* drivers from any vendor for *ANY* OS would have a digital signature as a common standard.

    I see a whole lot of upside / user benefit to signed software and really no downside (if the vendor does thier bit)

    for example if a driver crashes / BSOD's a system the vendor info should be there to tell the user who to complain to, the author's company that released the buggy code.
    today if a driver crashes a system on windows folks blame microsoft.
    what does a Linux user (not a developer a *USER*) do? 

    and why can't a driver be signed? 
    let me see, I paid say $500.00 for a video card, the vendor is selling them by the 100,000's so they could not afford $300 to $2000 to sign drivers for that hardware ?? 

    even a cheap USB dongle device like a memory stick....  so an OEM like say SanDisk is going to sell like 2 or 3 million times say $30 buks each... so they can't afford to pony up?

    look at the cruddy Nvidia drivers that were first out for Vista, and other hardware that had / has buggy drivers
    why should we pay top dollar to companies that want to skimp on QA and defect tracking ??


    why should Microsoft have to scan crash dumps trying to figure out who trashed the kernel ??
    while MSFT can still be a centeral depot of data the dispatch of the crash dump to the vendor should be quick and easy so that MSFT can focus on the OS , not on sluthing who donnit.

    does that start to put signing in a different light?
  • User profile image
    The problem isn't IHVs; they can get a driver signed no problem. It's sort of "homebrew" drivers; people make drivers for USB devices sometimes or maybe even run say an nvidia driver with a modified INF. The former isn't usually a problem; unless thye're written by an idiot, they should always be done in user mode (granted, there are idiots out there that must like the torture and crashiness of writing kernel mode USB drivers...). The latter is a bit of an annoyance for me since I get my laptop's video drivers off laptopvideo2go since Dell's are always woefully out of date. Still, WHQL drivers are still available there, just sans the modified INF which means my chipset won't be supported on every driver.
  • User profile image

    ENd of last year I built high end desktop and decided to have vista ultimate 64 on it. In start i not felt much issues cause i not have direct comparision to 32 bit vista. Now as i getting more familiar i feel my system performs slow compare to 32 bit vista OS. Boot time is also slower 64 bit.

    Apart from that i get issues with application compatibility on 64 bit. Just recently i really felt that i made mistake by having 64 bit when i found lot of media center plugins are not ready for 64 bit specially recently Tv Tonic have a NBC Olympics plugin for vista media center only for 32 bit. Few days back i was reading on channel 9 or channel 8 about Microsoft's new utility called steadystate. I was excited with its features and to my disappointment that too was only for 32 bit.

    So now after having 64 bit for more than 6 months i feel like only advantage i've got is having more than 3gb RAM.
     How can I expect 3rd party apps compatible with 64 bit when some of Microsoft's own apps are not ready for 64 bit.

  • User profile image

    I must point out here, that the signed driver requirement does not equal a WHQL requirement. Third party verified certification will suffice, which in your example would be a nvidia certificate. Modified inf files do not invalidate that type of signature on a device driver.

  • User profile image
    This was a security decision and the correct one to make. There is a channel 9 vid with the Vista security don who states that 32 bit vista is vulnerable because it lets you install unsigned drivers.

    This was a difficult decision to take, especially when you take into consideration the "mantra" of not breaking previous software favoured by Bill Gates. In the long run people will have all the driver software on their machine being signed. How can that be a bad thing? The option to continue with your bad practices is available as you are now, but as people become more security savvy, they will appreciate that sometimes you do indeed have to break stuff in order to move forward - taking the rough with the smooth.

    If the proprietor of your software is unable, or unwilling to update their software to allow a secure and accountable install, then you ought to direct your disapprobation, dismay, dejection and disgust at them, not the people trying to secure the darn thing.
  • User profile image
    Correct me if I'm wrong but my understanding was that the signed driver requirement is for drivers that run in the Kernel (chipset, network, etc).  I understood that any driver that run in User space (graphics on Vista, USB devices, etc) do not require being signed.  Signing drivers on Kernel mode drivers should improve the quality of those drivers since companies will be more likely to test then release rather than do 2000 revisions of a driver to stabilize it.
  • User profile image
    TvTonic has worked with 64 bit for about a week now. They fixed it pretty fast.
  • User profile image

    You know, Gary looks allot like Lance Mountain Smiley

    I first noticed 64 bit Vista on big Media Center laptops and it's getting more common.
    Usually musicians are the most particular about their "gear" but I've been surprised at how much lots of them are demanding 64bit support and taking up Vista64 bit. The smart hardware manufacturers (Echo, Edirol/Roland) are making sure that their drivers work with 64bit and the bigger slower ones aren't and people are annoyed.

    64bit will hopefully be one of the things that starts getting Vista more respect.

  • User profile image
    I agree that in that area Microsoft needs to step up to the plate:  Get the 64 bit version thing to be a non-issue with MSFT apps, tools etc....
  • User profile image
    Ah, my mistake.
  • User profile image
    ... and Vista 64 is available only in full retail version not in OEM, which makes it even harder to get.

    Even MS Tech Support didn't know that for the first several months. They were persistently trying to get me 64 bit for my OEM Vista Sad. Until after I got rerouted 100 times and talked to one of the managers who said OEM is not upgradable to 64, buy retail. So now I have 2 Vistas, what a waste, since I need only 1.
  • User profile image
    64-bit IS available in OEM version.

    I think Microsoft should stop creating 32-bit software for server and desktop. Unless it's for portable, low spec of embedded stuff.

    In Belgium, a great computerstore is selling pc's with the 64-bit oem version of Vista. Even the cheapest model of 310 €.
  • User profile image

    Here is the "OEM" version of Vista Ultimate 64bit

  • User profile image

    It's true that kernel mode drivers are the only drivers that require signing in Vista, and it is a good thing since A) when a bad kernel mode driver causes a blue-screen, Microsoft can get them to fix the problem and B) most things should be running in user mode anyway since it's more feature rich and less crashy. The problem is that some drivers need to run in kernel mode -- graphics drivers for instance -- since they need to be right down to the metal in order to be performant (although nvidia and ATI have taken steps to keep as little of their drivers as possible in kernel-mode in Vista). Also some devs don't like to be logical and make their drivers in kernel mode for no good reason -- the unofficial xbox controller driver for instace.

  • User profile image
    I thought in Vista Graphics drivers run in User space.  MS made the decision to take the slight performance hit to make the system more reliable is what I heard.

    Most drivers belong in user space.  The ones that need to be in the kernel should be signed anyway.  IMHO anyway.
  • User profile image
    I use Vista 64-bit, and to overcome the legacy and driver annoyances, I simply installed VMWare and XP 32-bit.  Going forward, it seems to me that VMs solve a lot of problems.  VMWare lets me connect my old HP scanner, for which no Vista driver exists, and DVD43 does its thing (with just one small glitch).

    If VM did a better job with DirectX display elements, they could be broadly useful.

    I am intrigued by Server 2008, mostly because of Hyper-V.  I now think workstations should have VMs, as a built-in element.
  • User profile image
    You're right actually I've checked it today and TV Tonic released the NBC Olympics 64 bit for Media center. I hope that will increase with more people having 64 bit OS in future.
  • User profile image
    I'm running Win XP 64 for quite a long time (actually, since it's RC1, if I recall correctly).

    So yes, most of the ISV's apps works correctly.
    For Microsoft ones, it's kind a lottery. Mostly not because of the app itself, but because of crappy restrictions you put on the installer. That's kind a shame, isn't it ?

    Simplest example : Windows Live. It's now impossible to get MSN Messenger or any of those Live Apps installed on Win XP 64. Not that the apps won't work, just that the installer will detect XP x64 and refuse to continue.

    WHY ? Why do you push ISVs to go 64 if you restrict your own apps ?
  • User profile image
    I understand and agree with the driver signing requirement.  Currently, you can boot with it disabled from the F8 menu, should you have reason to do so.  What is so frustrating is that you can't enable that option permanently.  I don't need to be lectured on the evils of poor, unsigned drivers, but if I want to load them anyway, I should have the ability to do that without having to F8 my system every time it boots.

    The number of people who even understand the issue is small, and the number of people who would forcefully disable the driver signing is even smaller, but it SHOULD be an option for people who want to do it.  It's extremely frustrating for those of us who, knowing the risks -- for whatever reason -- want to load an unsigned driver.

    This is also not an oversight.  At some point in the betas, you could use bcdedit and disable the checking.  This is reasonable, and makes sense.  You should be able to do that from a technical standpoint.  However sometime before RTM, they specifically disabled the ability to disable driver signing permanently with bcdedit.

    The real question is, why?  I think it was either a money-grab for the cert authorities, or a way to force more control over the environment, to the end of trying to impede the efforts of homebrew drivers and hackers -- groups of people that historically don't pour a lot of money into Microsoft's pockets.
  • User profile image
    One of the things that sucks about Vista 64 (and it's due to this "security" feature) is you can not get ext3 filesystem support on it.
  • User profile image
    Let me add some precisions concerning developing 64 bits applications on macintosh.

    As it was said, Mac OS X is a 64 bits OS, and the amount of work needed to port an App to 64 bits depends on the nature of the App. So saying that developing a 64 bits application is difficult in not correct, it depends on the type of application. 

    So if you got a Cocoa application or an X11 (Xwindow) application, no problem, porting to 64 bits is easy to do. You application can call any other modern APIs as OpenGL, Quartz, Core foundation, Quicktime, Core Audio, Core Image (you name it, all the great stuff in OS X), they are all 64 bits safe. So for any Cocoa application, the port is easy. For any Unix X11 application, the port is easy.

    Now comes the problem of Carbon. Carbon is the legacy APIs from the original Mac OS which was cleaned, enriched and put in OS X in order to allow developers to port easily existing Mac OS applications to Mac OS X. Carbon is a procedural API, it served well the mac, and its transition to OS X, but it seems that Apple wants people to move on, the legacy APIs in Carbon are not worth any more any further development as Apple moves forward. At some point Mac OS X needs to drop this legacy API. A good occasion to do that is the transition to 64 bits and Apple recognized that. Even though a working implementation of a 64 bits Carbon was available in the first betas of Mac OS X leopard, Apple decided to drop the support of 64 bits in Carbon in order to encourage developers to move to Cocoa.

    So what's the result for developers having a Carbon application that they want it to be 64 bits? Well they need to rewrite the UI code. That's there where the precisions are needed. Developers need only to migrate their UI code to Cocoa as only the UI related APIs in Carbon are not supported in 64 bits. All the low level Carbon C APIs (also commonly used by Cocoa applications) are available in 64 bits. So basically porting a Carbon application to 64 bits means migrating the UI code to Cocoa. That's not bad, many very big code has already done that, like Mathematica or Cinema4D. Note also that some applications relying on QuickDraw for the drawing should also migrate to Quartz instead as QuickDraw is anyway a depreciated technology, hence not supported in 64 bits.

    To summarize, there are already a lot of Cocoa applications out there, the comment on the video made it believe that any applications out there is not Cocoa based and that you need to switch to Cocoa to have a 64 applications, but that's not the point as many applications are already Cocoa based and very easy to port on 64 bits. This is also the case for all Unix application which rely on X11, they can be ported to run on 64 bits very easily because Apple builds a 64 bits safe X11 implementation.

    Applications using Carbon for their UI should use Cocoa instead to run in 64 bits, this can be a bigger effort for some developers like Adobe which has a very old code base relying on legacy APIs, but in the long term it will be very beneficial for Apple because it won't need to support a old API, that makes the OS less complex and easy to change.

    The example of Adobe Photoshop is a good example of an old code base which will need some work in order to migrate to Cocoa. That's why the next version of Photoshop will be 64 only on windows, the mac has to wait for the following version. But here again. in the long term it will be beneficial for Adobe and the mac that Photoshop get cleaned from his old legacy code so that it will be able to move forward more easily. 

    Also another mistake in the video concerns Adobe Lightroom. Lightroom is a cocoa application, and the latest version (the version 2.0) run in 64 bits on mac.
  • User profile image
    Tarpido - In my Windows environment, I have run XP and Vista x64 exclusively (except one older box) for over 5 years now. Vista x64 is (in my humble opinion) the best 64-bit OS I've yet run.

    Chances are that your machine is slower after several months because you've installed a ton of apps and software on it. Much of that software will often load a start-bar "utility" or a background service at boot-up time. I've seen some machines with startup apps numbering into the 40's and 50's. Several tens of apps all trying to load at the same time as the OS is loading and initializing will often add several seconds each to your boot time.

    To get an idea of what's slowing down your machine, run MSCONFIG and loot at the Startup tab to see what loads when Windows starts up. I strongly encourage you to un-check the apps that you DON'T want to load when you boot your machine. Note - this doesn't remove the item from the list - it just stops it loading automatically at boot.

    You should also review the Services tab to check what services are starting up when you boot - note that most of the Microsoft services will be required by some part of the OS so turn off auto-starting service with caution, but you may well find a bunch of stuff starting up automatically that you don't need.

    You ask "How can I expect 3rd party apps compatible with 64 bit when some of Microsoft's own apps are not ready for 64 bit." I understand your concerns, but note that the stars have only just aligned to make 64-bit a reality in the retail market (to which utilities like SteadyState are targeted). Rest assured, most teams at MS are now planning to or are already building apps that are compatible with Windows 64-bit.

    Note, however, that many apps don't necessarily need to be converted to 64-bit! Many apps that will never consume significant amounts of RAM will be unlikely to benefit from being converted to 64-bit. Apps that WILL need to be converted include those that are likely to consume significant amounts of RAM and anything that runs in the kernel including all drivers (this may be where SteadyState currently falls short). Apps that consume significant amounts of RAM include apps that works on graphics / video / audio (e.g. Photoshop, Expression), software development tools (e.g. Visual Studio), databases (e.g. SQL Server, Oracle) and other servers (e.g. Exchange), etc.

    For many other apps though, recompiling them to 64-bit will only increase their disk, IO and memory footprint, so many smaller apps will remain 32-bit for some time.

    You, the user, however will benefit from running these 32-bit apps on 64-bit OS though as you'll be able to run more of these apps simultaneously in your ne PC's much larger memory space.

Add Your 2 Cents