Fishface said:
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).
