O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
I upgraded my son's PC from Vista to Windows 7 32 bit - I really should have upgraded to 64 bit. Is it too late now? Can I some how still upgrade/change my current setup to 64 bit? or I'm done for it?
mac wrote: >I upgraded my son's PC from Vista to Windows 7 32 bit - I really > should have upgraded to 64 bit. Is it too late now? Can I some > how still upgrade/change my current setup to 64 bit? or I'm done for it?
The 32 bit to 64 bit requires a new custom installation, so the "upgrade" process would not work, anyway. The worst case scenario is that you would have to talk to a telephone representative with a thick west Asian accent and explain what happened.
I found that ith 64-bit Windows 7, I could no longer run Win16 and any DOS programs. They didn't tell me that.
Fishface wrote: > I found that ith 64-bit Windows 7, I could no longer run Win16
With Windows 95 introducing 32-bit application support in 1995 and 64-bit versions of Windows showing up in 2003 (which don't support 16-bit apps), you've had 6 to 14 YEARS to get rid of the old 16-bit applications or get their authors to upgrade them to 32-bit versions. Most likely you are using abandonware so it will never get upgraded. If that really old software were critical to you, why did you change the OS that supported them? You determine which applications you need to accomplish your tasks. Then you choose the OS that supports those applications. Choosing the OS first and then finding out what apps you can use is ass-backwards logic: you're backing in through the door to only then discover what you can do after you enter versus looking forward to see if that's where you want to go.
Also, no one is preventing you from using virtual machines (VirtualPC, VirtualBox, and VMWare Server are free) under which to install and run DOS; however, you'll probably use FreeDOS or Caldera's OpenDOS since you can't get MS-DOS from Microsoft anymore. You can even use a multi-boot manager, like GAG at gag.sourceforge.net, to select which OS to load from which [primary] partition but you have to be careful about the order in which you install the different operating systems since they tend to each step on the bootstrap record in the MBR - but then GAG lets you replace it as do other MBR utilities or running FIXMBR or FDISK /MBR, along with being careful about changing the partition numbering which can screw over the boot.ini setup for NT-based pre-Vista versions of Windows.
If you want complete isolation and protection, you could even use trays with removable drives where each drive has a different OS on it.
Did you even try running the 16-bit installer under a compatibility mode starting with Windows 95? Did you try using the XP Mode (assuming you downloaded it to install it since it is an out-of-bandwidth update for Windows 7)? XP Mode is only available if your hardware supports processor-based virtualization AND if using the Pro, Ultimate, or Enterprise edition of Windows 7. The crippled editions, like Home, don't have all the features in the non-crippled editions. You didn't say WHICH edition you have. If XP Mode didn't work, you may have to disable its integration features but that will probably result in reduced performance for the app running on that emulated platform, loss of mouse integration between emulated and real environments, etc.
Compatibility modes and XP Mode (emulation layer) still do not permit 16-bit apps from having direct access to hardware, installing or loading memory managers (since the real OS handles that now), or other DOS gimmicks needed by those really old 16-bit apps. Direct manipulation of hardware is to be controlled by the NT-version OS, not by applications or their ancilliary software.
Of course, since the installation for Windows 7 includes both its 32-bit and 64-bit versions, you could just choose to install the 32-bit version (even on 64-bit hardware). 64-bit hardware has been available for a long time and yet the default pre-installed configs of Vista were for its 32-bit version (to reduce the volume of tech support calls). Just what was that massive speed boost you expected to achieve from installing the 64-bit version of the OS? Just how many 64-bit applications do you actually have?
> and any DOS programs.
No NT-based version of Windows permits running DOS, a *separate* operating system. Lots of DOS *applications* continue to run under NT-based versions of windows as long as they don't attempt direct access to the hardware. Considering the age of "DOS" programs (versus just console-mode programs; i.e., those that use stdin/stdout instead of a fancy GUI), you're again talking about 16-bit programs (so mentioning DOS is redundant since you already mentioned 16-bit programs).
> They didn't tell me that.
Typical of the vast majority of non-technical users who hear of a new version, who have been well trained in the "newer is better" marketing mantra, and blithely buy and move to the newer stuff without any real cause to do so. Seen the same thing happen with users that update their BIOS for no real cause other than, gee, it's newer. Same with video driver updates on an otherwise already working host. Oooh, newer, must have it, resistance is futile, will be assimilated.
>> I found that ith 64-bit Windows 7, I could no longer run Win16
> With Windows 95 introducing 32-bit application support in 1995 and > 64-bit versions of Windows showing up in 2003 (which don't support > 16-bit apps), you've had 6 to 14 YEARS to get rid of the old 16-bit > applications or get their authors to upgrade them to 32-bit versions. > Most likely you are using abandonware so it will never get upgraded. If > that really old software were critical to you, why did you change the OS > that supported them? You determine which applications you need to > accomplish your tasks. Then you choose the OS that supports those > applications. Choosing the OS first and then finding out what apps you > can use is ass-backwards logic: you're backing in through the door to > only then discover what you can do after you enter versus looking > forward to see if that's where you want to go.
> Also, no one is preventing you from using virtual machines (VirtualPC, > VirtualBox, and VMWare Server are free) under which to install and run > DOS; however, you'll probably use FreeDOS or Caldera's OpenDOS since you > can't get MS-DOS from Microsoft anymore. You can even use a multi-boot > manager, like GAG at gag.sourceforge.net, to select which OS to load > from which [primary] partition but you have to be careful about the > order in which you install the different operating systems since they > tend to each step on the bootstrap record in the MBR - but then GAG lets > you replace it as do other MBR utilities or running FIXMBR or FDISK > /MBR, along with being careful about changing the partition numbering > which can screw over the boot.ini setup for NT-based pre-Vista versions > of Windows.
> If you want complete isolation and protection, you could even use trays > with removable drives where each drive has a different OS on it.
> Did you even try running the 16-bit installer under a compatibility mode > starting with Windows 95? Did you try using the XP Mode (assuming you > downloaded it to install it since it is an out-of-bandwidth update for > Windows 7)? XP Mode is only available if your hardware supports > processor-based virtualization AND if using the Pro, Ultimate, or > Enterprise edition of Windows 7. The crippled editions, like Home, > don't have all the features in the non-crippled editions. You didn't > say WHICH edition you have. If XP Mode didn't work, you may have to > disable its integration features but that will probably result in > reduced performance for the app running on that emulated platform, loss > of mouse integration between emulated and real environments, etc.
> Compatibility modes and XP Mode (emulation layer) still do not permit > 16-bit apps from having direct access to hardware, installing or loading > memory managers (since the real OS handles that now), or other DOS > gimmicks needed by those really old 16-bit apps. Direct manipulation of > hardware is to be controlled by the NT-version OS, not by applications > or their ancilliary software.
> Of course, since the installation for Windows 7 includes both its 32-bit > and 64-bit versions, you could just choose to install the 32-bit version > (even on 64-bit hardware). 64-bit hardware has been available for a > long time and yet the default pre-installed configs of Vista were for > its 32-bit version (to reduce the volume of tech support calls). Just > what was that massive speed boost you expected to achieve from > installing the 64-bit version of the OS? Just how many 64-bit > applications do you actually have?
>> and any DOS programs.
> No NT-based version of Windows permits running DOS, a *separate* > operating system. Lots of DOS *applications* continue to run under > NT-based versions of windows as long as they don't attempt direct access > to the hardware. Considering the age of "DOS" programs (versus just > console-mode programs; i.e., those that use stdin/stdout instead of a > fancy GUI), you're again talking about 16-bit programs (so mentioning > DOS is redundant since you already mentioned 16-bit programs).
>> They didn't tell me that.
> Typical of the vast majority of non-technical users who hear of a new > version, who have been well trained in the "newer is better" marketing > mantra, and blithely buy and move to the newer stuff without any real > cause to do so. Seen the same thing happen with users that update their > BIOS for no real cause other than, gee, it's newer. Same with video > driver updates on an otherwise already working host. Oooh, newer, must > have it, resistance is futile, will be assimilated.
What a brilliant post. You've boiled it all down better than anything I've seen written to date by some of those high priced nabobs. You've also made it really really clear that there is absolutely no reason for all of us to change at this time or even in the near term..
> I upgraded my son's PC from Vista to Windows 7 32 bit - I really should > have upgraded to 64 bit. Is it too late now? Can I some how still > upgrade/change my current setup to 64 bit? or I'm done for it?
>I upgraded my son's PC from Vista to Windows 7 32 bit - I really should >have upgraded to 64 bit. Is it too late now? Can I some how still >upgrade/change my current setup to 64 bit? or I'm done for it?
> mac
I have not yet done an actual switch from XP, but I am researching to get ready for the move - the machine I built was designed for W7. What I have been reading is that the upgrade path to upper versions of W7 is supposedly seamless. Meaning if you installed the Home Premium edition and then wanted to upgrade to Ultimate the process would be as simple as upgrading Firefox or AVG. It sounds like it would not be necessary to clean install the new version. So you may be in luck "upgrading" from 32 bit to 64 bit - other than reinstalling all the drivers for 64 bit. Have you tried sticking the disk in and starting the install process just to see what it says? You can always cancel out before it starts installing anything. Google/Bing is your friend.
VanguardLH wrote: > With Windows 95 introducing 32-bit application support in 1995 > and 64-bit versions of Windows showing up in 2003 (which don't > support 16-bit apps), you've had 6 to 14 YEARS to get rid of the > old 16-bit applications or get their authors to upgrade them to > 32-bit versions. Most likely you are using abandonware so it will > never get upgraded.
And I've had absolutely no reason to do so until now.
So, you advocate updating software that still works, but not the operating system? Well that makes good sense.
> If that really old software were critical to you, why did you change the > OS that supported them?
Obviously not critical software, and I had other reasons. I am a heavy multitasker and like to keep a lot of apps open and working in the background. I don't like to wait for 32-bit Windows to page things out to disk.
> You determine which applications you need to accomplish your tasks. > Then you choose the OS that supports those applications. Choosing > the OS first and then finding out what apps you can use is ass- > backwards logic: you're backing in through the door to only then > discover what you can do after you enter versus looking forward to > see if that's where you want to go.
To some extent, yes, but sometimes you take a little bad with the good that outweighs it. I can replace my American Heritage dictionary with the 32-bit version from 1995 and it will even tell me how to pronounce the words. I have two other computers in this room that are running XP Home for the foreseeable future and on which I can run stuff like All Clear flow charting software that costs $300 to upgrade. And Intellidraw which Adobe killed when they bought Aldus. I had to replace my modem for faxing. That was $12. My 1994 Laserjet 4 doesn't have a 64-bit driver, but my Mom needs one. My two scanners don't have 64-bit drivers, but the frequency with which I scan does not preclude doing it from one of the other computers. And then there's that FoodPro food analysis program that costs a small fortune to upgrade...
I tried the Windows 7 beta with 8GB of RAM and liked it enough to make these sacrifices. I'm not switching operating systems just for the hell of it. I have given it a great deal of thought.
> Also, no one is preventing you from using virtual machines (VirtualPC, > VirtualBox, and VMWare Server are free) under which to install and > run DOS; however, you'll probably use FreeDOS or Caldera's > OpenDOS since you can't get MS-DOS from Microsoft anymore. > You can even use a multi-boot manager, like GAG at > gag.sourceforge.net, to select which OS to load from which [primary] > partition but you have to be careful about the order in which you install > the different operating systems since they tend to each step on the > bootstrap record in the MBR - but then GAG lets you replace it as do > other MBR utilities or running FIXMBR or FDISK /MBR, along with being > careful about changing the partition numberingwhich can screw over the > boot.ini setup for NT-based pre-Vista versions of Windows.
Yes, and I'm looking forward to doing all of these things at the same time, and even while I'm sleeping (I occasionally fall asleep at the keyboard and render video before bed).
> If you want complete isolation and protection, you could even use trays > with removable drives where each drive has a different OS on it.
I might if I decided to try online banking, but I don't think so...
> Did you even try running the 16-bit installer under a compatibility mode > starting with Windows 95?
I believe so, yes.
> Did you try using the XP Mode (assuming you downloaded it to install it > since it is an out-of-bandwidth update for Windows 7)?
I don't even have it installed yet. I've been running XP since my 150 GB Raptor got the click of death running the beta, and before backing up. I decided to just wait for the official release. But I liked the taste well enough.
> XP Mode is only available if your hardware supports processor-based > virtualization AND if using the Pro, Ultimate, or Enterprise edition of > Windows 7. The crippled editions, like Home, don't have all the features > in the non-crippled editions. You didn't say WHICH edition you have. > If XP Mode didn't work, you may have to disable its integration features > but that will probably result in reduced performance for the app running > on that emulated platform, loss of mouse integration between emulated > and real environments, etc. Compatibility modes and XP Mode > (emulation layer) still do not permit 16-bit apps from having direct access > to hardware, installing or loading memory managers (since the real OS > handles that now), or other DOS gimmicks needed by those really old > 6-bit apps. Direct manipulation of hardware is to be controlled by the NT- > version OS, not by applications or their ancilliary software.
My hardware does support Virtualization and I did order Professional, specifically for this capability. I purchased the half-price upgrade, which, as it turns out, was not actually half off the street price of that version.
> Of course, since the installation for Windows 7 includes both its 32-bit > and 64-bit versions, you could just choose to install the 32-bit version > (even on 64-bit hardware).
If I was happy watching my hard drive LED blink while I sat dead in the water, I would have kept XP.
> 64-bit hardware has been available for a long time and yet the default > pre-installed configs of Vista were for its 32-bit version (to reduce the > volume of tech support calls).
Yes. But for me, it is time. Gateway, now owned by Acer seems to be now shipping with mostly 64-bit flavors of Windows.
> Just what was that massive speed boost you expected to achieve from > installing the 64-bit version of the OS? Just how many 64-bit applications > do you actually have?
I'm just here for the multitasking and memory management. My Vegas software does have a 64-bit version, as does Macrium Reflect and 7-Zip. I look forward to a browser with Flash support that doesn't crap-out when I have 22 windows open. Future software upgrades will probably only be 64-bit, although Win32 apps do run pretty well.
> No NT-based version of Windows permits running DOS, a *separate*
> operating system. Lots of DOS *applications* continue to run under > NT-based versions of windows as long as they don't attempt direct access > to the hardware. Considering the age of "DOS" programs (versus just > console-mode programs; i.e., those that use stdin/stdout instead of a > fancy GUI), you're again talking about 16-bit programs (so mentioning > DOS is redundant since you already mentioned 16-bit programs).
Yeah, I know. Mostly command-line stuff from yesteryear that I don't use much, anyway. I'll miss that Win16 app that makes a window of my choice stay on top, too.
> Typical of the vast majority of non-technical users who hear of a new > version, who have been well trained in the "newer is better" marketing > mantra, and blithely buy and move to the newer stuff without any real > cause to do so.
Believe me, I am *not* that person.
> Seen the same thing happen with users that update their BIOS for no real > cause other than, gee, it's newer. Same with video driver updates on an > otherwise already working host.
I'll read what it fixes and flash if it seems worthwhile, but sometimes they might fix a blunder they are too embarrassed to mention. They're always fixing video driver bugs. Unfortunately, it seems, they sometimes create others.
> Oooh, newer, must have it, resistance is futile, will be assimilated.
I did resist the Core i7 12 GB upgrade, didn't I? I can alway overclock my Q9550 higher, but at the moment, the hard drives are what slows me down the most.
Fishface wrote: > So, you advocate updating software that still works, but not the > operating system? Well that makes good sense.
After reading further, you'll see that I advocate using the OS determined by the apps that you deem critical. If the current software performs all the tasks you require of it then there is no reason to migrate it to a different OS, especially if you can't run your software on the new OS. Stick with what works until it no longer works.
> Obviously not critical software, and I had other reasons. I am a heavy > multitasker and like to keep a lot of apps open and working in the > background.
For backwards compatibility (as far back as you want to go), using virtual machines seems you best choice provided the old software doesn't require direct access to the hardware (which obviates many games). VirtualPC is free but doesn't support USB devices. VMWare Server is free but I personally do not care for the superfluous web server and web-centric interface in version 2 (I still use version 1). VirtualBox is another choice. Then you can have all those new and old apps running at the same time.
> I don't like to wait for 32-bit Windows to page things out to > disk.
Paging has nothing to do with whether you are running 16-, 32-, or 64-bit apps. If you are running out of free system memory space then add more physical RAM. Even if all those old 16-bit apps ran under the newer 64-bit OS, you'll still need more RAM if you don't want to page out to the slower virtual memory.
>> You determine which applications you need to accomplish your tasks. >> Then you choose the OS that supports those applications. Choosing >> the OS first and then finding out what apps you can use is ass- >> backwards logic: you're backing in through the door to only then >> discover what you can do after you enter versus looking forward to >> see if that's where you want to go.
> To some extent, yes, but sometimes you take a little bad with the good > that outweighs it. I can replace my American Heritage dictionary with > the 32-bit version from 1995 and it will even tell me how to pronounce > the words. I have two other computers in this room that are running XP > Home for the foreseeable future and on which I can run stuff like All > Clear flow charting software that costs $300 to upgrade. And Intellidraw > which Adobe killed when they bought Aldus. I had to replace my modem > for faxing. That was $12. My 1994 Laserjet 4 doesn't have a 64-bit > driver, but my Mom needs one. My two scanners don't have 64-bit > drivers, but the frequency with which I scan does not preclude doing it > from one of the other computers. And then there's that FoodPro food > analysis program that costs a small fortune to upgrade...
Again, VMs would work. VirtualPC is a headed VMM (virtual memory manager) which means you have to keep its console running so its VMs continue running. If you exit its console, the VMs gets unloaded. VMWare Server is headless because it runs as a service, not as a user app. You can kill its console buts its VMs are still loaded. You can run the OS that is best for the old software, especially if it won't run in your new OS. For printers, you would have to enable file & printer sharing and then share the printer in the guest (VM) with your host. My aunt had a scanner whose software never supported anything beyond Windows 98. She has greeting card software that will run under Windows XP but also under Windows 98. So I created a Windows 98 guest under which she can use her old scanner and old software.
> Yes, and I'm looking forward to doing all of these things at the same time, > and even while I'm sleeping (I occasionally fall asleep at the keyboard > and render video before bed).
VirtualPC will make you leave its console open to keep its VMs loaded; however, it will minimize to a tray icon. VMWare Server's console can be closed and its VMs remain running. My aunt didn't realize that so she was leaving the Windows 98 guest running all the time, even when she wasn't using it, and wasting the RAM on it. It's been too long since I trialed VirtualBox to remember it is a headless VMM.
> If I was happy watching my hard drive LED blink while I sat dead in the > water, I would have kept XP.
The size of reads/writes to your hard disk won't change because you went with a 64-bit processor and bus. Your hard disk will be just as active under a 64-bit OS as it was under a 32-bit OS. Sector and track sizes aren't going to change because you switch from a 32- to 64-bit OS.
>> Just what was that massive speed boost you expected to achieve from >> installing the 64-bit version of the OS? Just how many 64-bit applications >> do you actually have?
> I'm just here for the multitasking and memory management.
I don't see how 64-bit is going to improve the context switching for multitasking. Perhaps you meant that you can have MORE processes concurrently running because you can increase the max RAM available for user processes. Of course, there is the diminishing returns where you end up loading more but end up slowing the response of your host to where it is slower than when you had less memory under an earlier version of the OS with fewer apps concurrently running. I suspect having more apps running concurrently than you could have before (and all within real memory) is what you were looking for.
> I look forward to a browser with Flash support that doesn't crap-out when > I have 22 windows open.
You'll be disappointed. The crashes, hangs, or artificats in software won't be rectified by going to 64-bit OS. The problems is within the code for the apps themselves. They will still have the same max number of threads, the same max buffer sizes, and so on. If the apps were recompiled for use under a 64-bit OS then the problems might abate but not if there merely ported the app.
As yet, I don't recall hearing that Adobe has a 64-bit version of their Flash player. I haven't checked again for a couple months.
> Future software upgrades will probably only be > 64-bit, although Win32 apps do run pretty well.
Well, yes, perhaps in about 6 years from now. Windows XP x64 has been around since 2003 (since 2001 if you include their Itanium version). Vista x64 has been around since the start of 2007. Where is that flood of 64-bit apps due to the availability of 64-bit versions of Windows? Windows 7 doesn't add 64-bit over XP x64 or Vista 64 so it's not like apps are going to accelerate any faster to 64-bit conversions. Also, most 32-bit apps gain no benefit over a port to 64-bit support.
More likely you'll see new apps come out with 64-bit versions if they decide there is any advantage in producing 2 versions: a 32-bit version to support all the then-to-be-legacy hosts and the newer 64-bit platforms that become increasingly prevalent. Maintaining 2 codebases without any advantage within the program means it won't happen.
> I'll miss that Win16 app that makes a window of my choice > stay on top, too.
Sounds like the old 16-bit app doesn't leave its console window open after it exits but then that is expected. You'll have to open a console (cmd.exe) to have it manage the console and keep it there when the DOS app exits.
> I'll read what it fixes and flash if it seems worthwhile, but sometimes they > might fix a blunder they are too embarrassed to mention.
I've yet to see a BIOS vendor that wouldn't acknowledge when they had a problem with a particular version of their BIOS. However, by the time anyone knows about it, they have a fix. I understand why users would update for that reason - because there really is a reason to upgrade. That's not how the vast majority of users operate. They hear of a new version for the BIOS or even run a utility that checks for them and announces the new version. Of course, they must have it without reading any of its release notes to determine what, if anything, it gives them (as a fix or a new feature that they really need).
> They're always fixing video driver bugs.
Along with introducing new ones. In fact, somethimes the "update" is to drop support for older games because the changes needed to support newer games is incompatible with the code needed for the older games. So you update your video driver only to remove support for your old game that you still play. Most users just upgrade forward. They don't actually test through many versions of the video driver to determine which works best with their suite of software. I have older games series developed back in 1996-1999. They don't play well with the latest versions of the video driver. In fact, they don't play well past a certain version but it takes time and testing to walk backward through the versions to find what works best. Nothing I installed later required a later version of the driver so I didn't run into a conflict between old and new software that require different versions of the driver under which they best perform. If there was a conflict, the resolution would be to drop the old games, or use multi-booting to an older OS and older video driver for those old games.
I figure VMs (whether as separate VMM interfaces or the integrated XP mode) help to provide backward compatibility with old apps. In fact, the reason why Microsoft added XP mode was to separate that legacy support to make it easy to separate from continuing that compatibility support. If the software needs direct hardware access, multi-boot is probably the best solution although it means only one OS is running at a time. I haven't experimented with Microsoft's Hyper-V which runs a hypervisor and ALL your operating systems run as virtual machines (and to know if there would still be a problem running a DOS as a VM where it has direct hardware access).
>> So, you advocate updating software that still works, but not the >> operating system? Well that makes good sense.
> After reading further, you'll see that I advocate using the OS > determined by the apps that you deem critical.
Uh, actually, that was a little sarcasm...
>> I don't like to wait for 32-bit Windows to page things out to >> disk.
> Paging has nothing to do with whether you are running 16-, 32-, or > 64-bit apps. If you are running out of free system memory space then > add more physical RAM. Even if all those old 16-bit apps ran under the > newer 64-bit OS, you'll still need more RAM if you don't want to page > out to the slower virtual memory.
Yes, well, I had the memory maxed out. I tried Windows 7 64-bit and my task-switching was instant. I could switch from one big app to another I understand that all applications don't benefit. I only want the system to be able to address more memory.
> Again, VMs would work. VirtualPC is a headed VMM (virtual memory > manager) which means you have to keep its console running so its VMs > continue running. If you exit its console, the VMs gets unloaded. > VMWare Server is headless because it runs as a service, not as a user > app. You can kill its console buts its VMs are still loaded. You can > run the OS that is best for the old software, especially if it won't run > in your new OS. For printers, you would have to enable file & printer > sharing and then share the printer in the guest (VM) with your host. My > aunt had a scanner whose software never supported anything beyond > Windows 98. She has greeting card software that will run under Windows > XP but also under Windows 98. So I created a Windows 98 guest under > which she can use her old scanner and old software.
Interesting, but I don't quite understand how I can share the printer without a 64-bit driver except from another 32-bit VM, if you are implying that is possible.
> The size of reads/writes to your hard disk won't change because you went > with a 64-bit processor and bus. Your hard disk will be just as active > under a 64-bit OS as it was under a 32-bit OS. Sector and track sizes > aren't going to change because you switch from a 32- to 64-bit OS.
Not the problem-- just running out of addressable physical RAM, I think.
>> I'm just here for the multitasking and memory management.
> I don't see how 64-bit is going to improve the context switching for > multitasking. Perhaps you meant that you can have MORE processes > concurrently running because you can increase the max RAM available for > user processes. Of course, there is the diminishing returns where you > end up loading more but end up slowing the response of your host to > where it is slower than when you had less memory under an earlier > version of the OS with fewer apps concurrently running. I suspect > having more apps running concurrently than you could have before (and > all within real memory) is what you were looking for.
The benefits are most apparent when you have a large amount of random access memory (RAM) installed on your computer (typically 4 GB of RAM or more). Because a 64-bit operating system can handle large amounts of memory more efficiently than a 32-bit operating system can, a 64-bit system can be more responsive when running several programs at the same time and switching between them frequently.
>> I look forward to a browser with Flash support that doesn't crap-out when >> I have 22 windows open.
> You'll be disappointed. The crashes, hangs, or artificats in software > won't be rectified by going to 64-bit OS. The problems is within the > code for the apps themselves. They will still have the same max number > of threads, the same max buffer sizes, and so on. If the apps were > recompiled for use under a 64-bit OS then the problems might abate but > not if there merely ported the app.
Perhaps it is not a limitation of the bittedness of the browser. That is an experiment to which I look forward. I just know that with about twenty-two Internet Explorer windows open, very strange things begin to happen. I can no longer copy from IE, and new windows cease to spawn. Of course, other large apps are running concurrently. I agree that most people's needs are well met by a 32-bit operating system.
> As yet, I don't recall hearing that Adobe has a 64-bit version of their > Flash player. I haven't checked again for a couple months.
Still just the Linux Beta. I hate Adobe, and not just for that.
>> Future software upgrades will probably only be >> 64-bit, although Win32 apps do run pretty well.
> Well, yes, perhaps in about 6 years from now. Windows XP x64 has been > around since 2003 (since 2001 if you include their Itanium version).
Yes, but the driver model changed completely. I think I would actually prefer XP in the 64-bit. Maybe I'll run it in a VM!
> Vista x64 has been around since the start of 2007. Where is that flood > of 64-bit apps due to the availability of 64-bit versions of Windows? > Windows 7 doesn't add 64-bit over XP x64 or Vista 64 so it's not like > apps are going to accelerate any faster to 64-bit conversions. Also, > most 32-bit apps gain no benefit over a port to 64-bit support.
I really just want to use more RAM than 32-bit Windows allows. It will be nice to give 2GB to a VM. Very few of my apps will benefit from the 64-bit compilation.
> More likely you'll see new apps come out with 64-bit versions if they > decide there is any advantage in producing 2 versions: a 32-bit version > to support all the then-to-be-legacy hosts and the newer 64-bit > platforms that become increasingly prevalent. Maintaining 2 codebases > without any advantage within the program means it won't happen.
It really doesn't have to be two codebases. Only apps that can use more RAM are going to need different code.
>> I'll miss that Win16 app that makes a window of my choice >> stay on top, too. > Sounds like the old 16-bit app doesn't leave its console window open > after it exits but then that is expected. You'll have to open a console > (cmd.exe) to have it manage the console and keep it there when the > DOS app exits.
Because it ran in the Win16 WOW subsystem, and it was possible under Win16, it could make any app, even Win32 apps stay on top of the Z order. It's very handy, at times. Still available on the web. I see it available for download at this unknown source:
Fishface wrote: > I tried Windows 7 64-bit and my task-switching was instant. I could > switch from one big app to another I understand that all applications > don't benefit. I only want the system to be able to address more > memory.
Hmm, as soon as I release the Alt+Tab key combo, the switch has always been immediate for me, even back to 9x-based versions of Windows. The switching has never been a problem for me. Having more applications loaded that physical memory can accomodate does cause a slowdown but in the application itself. Also, I've seen users *claim* they are multitasking when, in fact, they are single tasking. A user that leaves programs dormant when they switch away from them isn't multitasking. If you were using a word processor to reformat a huge document, along with having a newsreader download all article bodies for your subscribed newsgroups, along with your database program committing all the pending changes, along with conversion and merging of multiple video files, and so on then you are actually multitasking. Most "multitasking" that users claim is like them digging a hole with a shovel, putting it down and then hooking up the sprinkler to water the garden, then hauling the trashbins to the curb, and returning to the shovel to do some more digging. That's single tasking as far as the user is concerned. There are occasions when someone walks into my cubicle and has a verbal discussion with me while I'm watching a database update on one monitor but entering input via touch typing on a keyboard to a different host as I'm updating a document on test procedures. I get some weird looks from those visitors wondering how I manage to do 3 things at once. That's multitasking by the user. Even that's not a normal condition for me and, in fact, is just me switching very fast between the tasks. Humans don't multitask.
It sounds like you are *switching* between dormant applications. By going 64-bit you can then have even more applications lying dormant for even longer periods of time before you switch back to them.
> Interesting, but I don't quite understand how I can share the printer > without a 64-bit driver except from another 32-bit VM, if you are > implying that is possible.
That was the idea. Run inside a VM an operating system that supports your needs for that old software or hardware. For hardware drivers, they must not *directly* access the hardware but instead use mini-port or class drivers. These describe how to communicate with the device rather than provide a direct interface to it. They are part of the Windows Driver Model (en.wikipedia.org/wiki/Windows_Driver_Model). For example, and for a printer that I don't even have, I use the printer wizard in a VM to add an HP LaserJet 4L printer. To access that printer, I would have to enable file & printer sharing and go through the networking wizard to set it up. On my host, I'd add a printer but browse to the networked printer defined in the VM (which must be running to find that printer). I haven't completed this setup because I don't have a situation of a printer where no driver exists for the host OS that I use. One gotcha is that the workgroup you use for your VM has to be the same as the workgroup for your host OS to do the sharing, but there could be other gotchas.
Yet I can't see how immediately switching focus to another dormant or active application when I release Alt+Tab could be made any faster. Apparently I have not encountered a long hang when *I* am single-tasking between the applications. I have seen active applications (they are performing some lengthy and CPU intensive processing even when switched away from) that will lag but that's not due to the context switch. That's due to the application not getting to its code to refresh its window (i.e., repaint) or accept user input. The OS did an instant switch. That the switched-to app isn't ready isn't the OS' fault.
> I just know that with about twenty-two Internet Explorer windows open, > very strange things begin to happen. I can no longer copy from IE, > and new windows cease to spawn. Of course, other large apps are > running concurrently.
I've had up to 72 concurrent tabs open and a web page loaded in each (just don't load pages that continually update themselves which keeps updating the disk files). I ran out of reasons to have more tabs open so that's been my max so far. At the same time, I've had Outlook, Dialog (newsreader), and some other apps loaded, too. On occasion, I may be doing a video merge but it sucks so much CPU horsepower and floods the data bus with disk I/O that it will always affect anything else that runs - but it hasn't limited me to how many tabs I can have concurrently loaded in IE8. Because I am consuming more than the 2GB physical memory in my host, slowdown is apparent due to paging to disk. So I would have a more responsive host if I could add more physical memory (that was accessible to user processes) but that's a responsiveness issue, not how many tabs I can have open. Obviously once all my physical and pagefile space got used up then I'd be hurting to allocate more memory to any application.
I guess it comes down to how many dormant applications you want to leave sitting dead in memory before you happen to get back to them. I tend to be overly neat so I'm always cleaning up, plus it simply gets confusing when you have umpteen programs loaded concurrently. It's like leaving all your kitchen drawers pulled out and all the kitchen cabinet doors left open because you might need to access one of them eventually. Taken to the extreme, you could add add terabytes of memory to your computer and then have all applications loaded into memory and the Start menu doesn't load them but merely switch between them. Interesting thought, isn't it, except for the startup time before Windows becomes usable due to all the loading. Alas, the hard disk remains a crippling factor in speed hence why SSDs are making a comeback.
> I found that ith 64-bit Windows 7, I could no longer run Win16 and any > DOS programs. They didn't tell me that.
This is not specific to Windows 7. In fact, none of the 64bit Windows variants that are available since 2001 support 16bit programs.
I suppose the reason why it isn't written on the box is that in 2009 the majority of users probably doesn't care. If you still need 16bit support then there are many ways to run 16bit apps in 64bit Windows, like VirtualPC, DOSBox, Sun VirtualBox etc, which probably provide a much better 16bit support than any 32bit WindowsNT (W2k, WinXP and later) has provided.
|
