upgrade mistake

[mac]

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

 

[Fishface]

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.

 

[VanguardLH]

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.

 

[Pen]

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..

 

[Tony Neville]

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?

His CPU is definately a 64-bit one?

Tony.

 

[TVeblen]

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]

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.

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.

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).

 

[Fishface]

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...

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 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.

Well, I believe it. I've seen it with mine own eyes, unless my XP install is
totally borked. From the FAQ here:
http://windows.microsoft.com/en-US/...and-64-bit-Windows-frequently-asked-questions

Would I benefit from using a 64-bit computer?

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.

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.

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.

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.

Not a console app, actually. ToTop, mentioned here:
http://www.epie.org/k12/PCMAGUTL.HTM

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:

ftp://ftp.eunet.bg/pub/simtelnet/msdos/pcmag/v11n16.zip

The MD5 Hash of totop.exe matches mine.

5143170C5EFEDD1CA516B4090403FFA4

( HashTab: http://beeblebrox.org/ )

Oh, I might have to upgrade my SnagIt Screen Capture software. Again!

 

[VanguardLH]

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.

Well, I believe it. I've seen it with mine own eyes, unless my XP
install is totally borked. From the FAQ here:
http://windows.microsoft.com/en-US/...and-64-bit-Windows-frequently-asked-questions

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.

 

[Benjamin Gawert]

* Fishface:

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.

Benjamin