[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: 64 or 32 bit Win 7
- Subject: Re: 64 or 32 bit Win 7
- From: "Robert Holmgren" holmgren@xxxxxxxx
- Date: Sun, 9 May 2010 11:31:05 -0400
** Reply to message from J R FOX on Mon, 3
May 2010 12:26:24 -0700 (PDT)
> I suspect most of the people on this list -- just as in the
> case of most of the people I know -- are still in a 'Why Go
> There ?' mode, as regards 64 bit. Maybe if I was putting
> together a quad-core screamer . . . . But nothing I'm doing
> now, up to and including various things with video streams,
> really require it. (Robert might have a different take
> on that.)
Not really. I think it's a personal, 50-50 call at this point
in time.
> Certainly nothing with everyday business apps.
> I suppose it would be a different story if the 32-bit
> OS-es were suddenly to go away.
That will happen. I recall reading that the successor to Win7
will be 64-bit only. And quad-core "screamers" will be
standard. 64-bit is faster and can address huge memory spaces,
assuming 64-bit software.
The unanswered question in my mind is whether 16-bit software
can ever be "thunked" under a 64-bit OS. I read different
statements about this: some say it is technically impossible;
but if 64 can thunk 32-bit, and considering that a 16-bit memory
address is also 32-bits long (the selector + the memory offset),
then I don't see why not. I think Microsoft simply doesn't want
to go to the trouble to support obsolete software.
Our energy should be focused on finding the most flexible,
lightest-weight virtualization solution. The essential
requirements:
- the DOS emulator must be able to "see" the entire 64-bit file
system
- it must be possible for programs inside the emulator to
launch 32/64-bit programs outside of the emulator without too
much complication. (Think printing, for example: you need to
be able to put documents in the print spool, and/or format them
with Ghostscript. Countless reasons why we must be able to
launch external apps...)
- the emulator must run concurrently with the real operating
system (no "BootCamp"-like nonsense). From the Desktop, the
emulator (and XyWrite within it) should appear as simply one of
many running apps
- the emulator should load quickly; we don't want a 30-second
delay every time we fire up the emulator
- networking, the old UNC kind, which XyWrite understands very
well on a LAN
I haven't investigated these issues very much. DOSBox places
the apps that it runs in a very isolated situation, on a virtual
drive that the real operating system can't "see", like Z:.
Accessing other drives requires a lot of configuration. And
DOSBox is buggy. I have higher hopes for VPC 2007 running, say,
Windows 2000 stripped down to its barest bones. Or even Win98
2nd Edition. I think DOS 6.22, although possible, would just be
too primitive in terms of interfacing with the external file
system. ISOs of these operating systems are available all over
the Internet. If there is even the slightest possibility that
M$ might withdraw VPC 2007, we should DL VPC2007 SP1 now,
customize it for XyWrite, and stash it where everybody can
access it.
In my opinion, these are the issues that we should be
discussing. Iron them out, and there should be no hesitation
about adopting 64-bit operating systems.
-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------