x64 - ready for prime time?

Discussion in 'Windows 64bit' started by =?Utf-8?B?ZGZvc2Jlbm5lcg==?=, Jul 19, 2006.

  1. I suppose it depends on what a person wants to accomplish. I purchased a new
    server this month and installed W2K3x64 on it, but quite a number of the
    network utilities I'd use aren't supported.

    I'm sure that 32-bit Windows will more than handle the load on this system,
    using x64 was more of an experiment with the latest technology. Has anyone
    else tested out x64, then stepped back to 32?

    Maybe in a year when my next server is purchased I'll look at x64 again. It
    seems like it needs to mature and receive more vendor support.
    --
    MCSE NT/2000/2003
    =?Utf-8?B?ZGZvc2Jlbm5lcg==?=, Jul 19, 2006
    #1
    1. Advertising

  2. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    Peter Lawton Guest

    As you say it's not x64 Windows that isn't ready for prime time it's the
    extremely slow pace of software support from other vendors (including MS)

    We're a Thin Client house running Citrix on W2003 x64 and although I've just
    very sucessfully moved our terminal servers to x64 a lot of our other
    servers have to stay on i386 because of lack of software vendor support.

    1) ISA - no x64 compatible ISA from MS in sight at all, not even the version
    they haven't released yet.

    2) Exchange - x64 only in the next release

    3) Symantec AV - No sign of an x64 parent server yet and their "x64" client
    is a 32bit hack that won't even update it signatures from their own parent
    server.

    4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    companies won't support their products on SQL2005 yet.
    Also the apps that will happily run on a SQL2005 back end often won't
    actually install on it (MS guilty here too, together with the other usual
    suspects)

    Peter Lawton

    "dfosbenner" <> wrote in message
    news:...
    >I suppose it depends on what a person wants to accomplish. I purchased a
    >new
    > server this month and installed W2K3x64 on it, but quite a number of the
    > network utilities I'd use aren't supported.
    >
    > I'm sure that 32-bit Windows will more than handle the load on this
    > system,
    > using x64 was more of an experiment with the latest technology. Has
    > anyone
    > else tested out x64, then stepped back to 32?
    >
    > Maybe in a year when my next server is purchased I'll look at x64 again.
    > It
    > seems like it needs to mature and receive more vendor support.
    > --
    > MCSE NT/2000/2003
    Peter Lawton, Jul 19, 2006
    #2
    1. Advertising

  3. All good points. Backup Exec 10d has an x64 agent, I'm about to try it out
    this week.

    If I go with x64, and it's stable, then hopefully the other tools will
    follow. Otherwise if I go 32bit, I'd have to reformat/reinstall to go to
    x64, NOT something I can do with a production server. SQL 2005 will be our
    main app on this box, and the applications are in house VB apps.
    --
    MCSE NT/2000/2003


    "Peter Lawton" wrote:

    > As you say it's not x64 Windows that isn't ready for prime time it's the
    > extremely slow pace of software support from other vendors (including MS)
    >
    > We're a Thin Client house running Citrix on W2003 x64 and although I've just
    > very sucessfully moved our terminal servers to x64 a lot of our other
    > servers have to stay on i386 because of lack of software vendor support.
    >
    > 1) ISA - no x64 compatible ISA from MS in sight at all, not even the version
    > they haven't released yet.
    >
    > 2) Exchange - x64 only in the next release
    >
    > 3) Symantec AV - No sign of an x64 parent server yet and their "x64" client
    > is a 32bit hack that won't even update it signatures from their own parent
    > server.
    >
    > 4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    > companies won't support their products on SQL2005 yet.
    > Also the apps that will happily run on a SQL2005 back end often won't
    > actually install on it (MS guilty here too, together with the other usual
    > suspects)
    >
    > Peter Lawton
    =?Utf-8?B?ZGZvc2Jlbm5lcg==?=, Jul 19, 2006
    #3
  4. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    Peter Lawton Guest

    The BackupExec 10d x64 agent works fine in my experience and SQL2005 is one
    app that does work very well on x64.

    I'm actually running 32bit SQL2000 on W2003 x64 on one of our servers at the
    moment so that I don't have to re-install the OS to go to SQL2005 x64 when
    our app vendors will support it

    Peter Lawton

    "dfosbenner" <> wrote in message
    news:...
    > All good points. Backup Exec 10d has an x64 agent, I'm about to try it
    > out
    > this week.
    >
    > If I go with x64, and it's stable, then hopefully the other tools will
    > follow. Otherwise if I go 32bit, I'd have to reformat/reinstall to go to
    > x64, NOT something I can do with a production server. SQL 2005 will be
    > our
    > main app on this box, and the applications are in house VB apps.
    > --
    > MCSE NT/2000/2003
    >
    >
    > "Peter Lawton" wrote:
    >
    >> As you say it's not x64 Windows that isn't ready for prime time it's the
    >> extremely slow pace of software support from other vendors (including MS)
    >>
    >> We're a Thin Client house running Citrix on W2003 x64 and although I've
    >> just
    >> very sucessfully moved our terminal servers to x64 a lot of our other
    >> servers have to stay on i386 because of lack of software vendor support.
    >>
    >> 1) ISA - no x64 compatible ISA from MS in sight at all, not even the
    >> version
    >> they haven't released yet.
    >>
    >> 2) Exchange - x64 only in the next release
    >>
    >> 3) Symantec AV - No sign of an x64 parent server yet and their "x64"
    >> client
    >> is a 32bit hack that won't even update it signatures from their own
    >> parent
    >> server.
    >>
    >> 4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    >> companies won't support their products on SQL2005 yet.
    >> Also the apps that will happily run on a SQL2005 back end often won't
    >> actually install on it (MS guilty here too, together with the other usual
    >> suspects)
    >>
    >> Peter Lawton

    >
    Peter Lawton, Jul 19, 2006
    #4
  5. I was able to install and do a test backup with Backup Exec 10d, it worked
    fine. I also got confirmation that Diskeeper is fully supported on x64.

    I can live with the lack of SAVCE AVServer if I have to. It's disappointing
    though.
    Also, APC says they don't support x64 for PowerChute Bus. Edition. I cannot
    understand why. It seems to work when I tested it.

    I also found out Shavlik NetChkPro won't scan x64 systems until an update in
    4Q06.


    --
    MCSE NT/2000/2003


    "Peter Lawton" wrote:

    > The BackupExec 10d x64 agent works fine in my experience and SQL2005 is one
    > app that does work very well on x64.
    >
    > I'm actually running 32bit SQL2000 on W2003 x64 on one of our servers at the
    > moment so that I don't have to re-install the OS to go to SQL2005 x64 when
    > our app vendors will support it
    >
    > Peter Lawton
    >
    > "dfosbenner" <> wrote in message
    > news:...
    > > All good points. Backup Exec 10d has an x64 agent, I'm about to try it
    > > out
    > > this week.
    > >
    > > If I go with x64, and it's stable, then hopefully the other tools will
    > > follow. Otherwise if I go 32bit, I'd have to reformat/reinstall to go to
    > > x64, NOT something I can do with a production server. SQL 2005 will be
    > > our
    > > main app on this box, and the applications are in house VB apps.
    > > --
    > > MCSE NT/2000/2003
    > >
    > >
    > > "Peter Lawton" wrote:
    > >
    > >> As you say it's not x64 Windows that isn't ready for prime time it's the
    > >> extremely slow pace of software support from other vendors (including MS)
    > >>
    > >> We're a Thin Client house running Citrix on W2003 x64 and although I've
    > >> just
    > >> very sucessfully moved our terminal servers to x64 a lot of our other
    > >> servers have to stay on i386 because of lack of software vendor support.
    > >>
    > >> 1) ISA - no x64 compatible ISA from MS in sight at all, not even the
    > >> version
    > >> they haven't released yet.
    > >>
    > >> 2) Exchange - x64 only in the next release
    > >>
    > >> 3) Symantec AV - No sign of an x64 parent server yet and their "x64"
    > >> client
    > >> is a 32bit hack that won't even update it signatures from their own
    > >> parent
    > >> server.
    > >>
    > >> 4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    > >> companies won't support their products on SQL2005 yet.
    > >> Also the apps that will happily run on a SQL2005 back end often won't
    > >> actually install on it (MS guilty here too, together with the other usual
    > >> suspects)
    > >>
    > >> Peter Lawton

    > >

    >
    >
    >
    =?Utf-8?B?ZGZvc2Jlbm5lcg==?=, Jul 20, 2006
    #5
  6. You will a number of error balloons. They appear to be bogus.

    "dfosbenner" <> wrote in message
    news:...
    >I was able to install and do a test backup with Backup Exec 10d, it worked
    > fine. I also got confirmation that Diskeeper is fully supported on x64.
    >
    > I can live with the lack of SAVCE AVServer if I have to. It's
    > disappointing
    > though.
    > Also, APC says they don't support x64 for PowerChute Bus. Edition. I
    > cannot
    > understand why. It seems to work when I tested it.
    >
    > I also found out Shavlik NetChkPro won't scan x64 systems until an update
    > in
    > 4Q06.
    >
    >
    > --
    > MCSE NT/2000/2003
    >
    >
    > "Peter Lawton" wrote:
    >
    >> The BackupExec 10d x64 agent works fine in my experience and SQL2005 is
    >> one
    >> app that does work very well on x64.
    >>
    >> I'm actually running 32bit SQL2000 on W2003 x64 on one of our servers at
    >> the
    >> moment so that I don't have to re-install the OS to go to SQL2005 x64
    >> when
    >> our app vendors will support it
    >>
    >> Peter Lawton
    >>
    >> "dfosbenner" <> wrote in message
    >> news:...
    >> > All good points. Backup Exec 10d has an x64 agent, I'm about to try it
    >> > out
    >> > this week.
    >> >
    >> > If I go with x64, and it's stable, then hopefully the other tools will
    >> > follow. Otherwise if I go 32bit, I'd have to reformat/reinstall to go
    >> > to
    >> > x64, NOT something I can do with a production server. SQL 2005 will be
    >> > our
    >> > main app on this box, and the applications are in house VB apps.
    >> > --
    >> > MCSE NT/2000/2003
    >> >
    >> >
    >> > "Peter Lawton" wrote:
    >> >
    >> >> As you say it's not x64 Windows that isn't ready for prime time it's
    >> >> the
    >> >> extremely slow pace of software support from other vendors (including
    >> >> MS)
    >> >>
    >> >> We're a Thin Client house running Citrix on W2003 x64 and although
    >> >> I've
    >> >> just
    >> >> very sucessfully moved our terminal servers to x64 a lot of our other
    >> >> servers have to stay on i386 because of lack of software vendor
    >> >> support.
    >> >>
    >> >> 1) ISA - no x64 compatible ISA from MS in sight at all, not even the
    >> >> version
    >> >> they haven't released yet.
    >> >>
    >> >> 2) Exchange - x64 only in the next release
    >> >>
    >> >> 3) Symantec AV - No sign of an x64 parent server yet and their "x64"
    >> >> client
    >> >> is a 32bit hack that won't even update it signatures from their own
    >> >> parent
    >> >> server.
    >> >>
    >> >> 4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    >> >> companies won't support their products on SQL2005 yet.
    >> >> Also the apps that will happily run on a SQL2005 back end often won't
    >> >> actually install on it (MS guilty here too, together with the other
    >> >> usual
    >> >> suspects)
    >> >>
    >> >> Peter Lawton
    >> >

    >>
    >>
    >>
    Colin Barnhorst, Jul 20, 2006
    #6
  7. You may see a number of bogus error balloons from PowerChute. I do.

    "dfosbenner" <> wrote in message
    news:...
    >I was able to install and do a test backup with Backup Exec 10d, it worked
    > fine. I also got confirmation that Diskeeper is fully supported on x64.
    >
    > I can live with the lack of SAVCE AVServer if I have to. It's
    > disappointing
    > though.
    > Also, APC says they don't support x64 for PowerChute Bus. Edition. I
    > cannot
    > understand why. It seems to work when I tested it.
    >
    > I also found out Shavlik NetChkPro won't scan x64 systems until an update
    > in
    > 4Q06.
    >
    >
    > --
    > MCSE NT/2000/2003
    >
    >
    > "Peter Lawton" wrote:
    >
    >> The BackupExec 10d x64 agent works fine in my experience and SQL2005 is
    >> one
    >> app that does work very well on x64.
    >>
    >> I'm actually running 32bit SQL2000 on W2003 x64 on one of our servers at
    >> the
    >> moment so that I don't have to re-install the OS to go to SQL2005 x64
    >> when
    >> our app vendors will support it
    >>
    >> Peter Lawton
    >>
    >> "dfosbenner" <> wrote in message
    >> news:...
    >> > All good points. Backup Exec 10d has an x64 agent, I'm about to try it
    >> > out
    >> > this week.
    >> >
    >> > If I go with x64, and it's stable, then hopefully the other tools will
    >> > follow. Otherwise if I go 32bit, I'd have to reformat/reinstall to go
    >> > to
    >> > x64, NOT something I can do with a production server. SQL 2005 will be
    >> > our
    >> > main app on this box, and the applications are in house VB apps.
    >> > --
    >> > MCSE NT/2000/2003
    >> >
    >> >
    >> > "Peter Lawton" wrote:
    >> >
    >> >> As you say it's not x64 Windows that isn't ready for prime time it's
    >> >> the
    >> >> extremely slow pace of software support from other vendors (including
    >> >> MS)
    >> >>
    >> >> We're a Thin Client house running Citrix on W2003 x64 and although
    >> >> I've
    >> >> just
    >> >> very sucessfully moved our terminal servers to x64 a lot of our other
    >> >> servers have to stay on i386 because of lack of software vendor
    >> >> support.
    >> >>
    >> >> 1) ISA - no x64 compatible ISA from MS in sight at all, not even the
    >> >> version
    >> >> they haven't released yet.
    >> >>
    >> >> 2) Exchange - x64 only in the next release
    >> >>
    >> >> 3) Symantec AV - No sign of an x64 parent server yet and their "x64"
    >> >> client
    >> >> is a 32bit hack that won't even update it signatures from their own
    >> >> parent
    >> >> server.
    >> >>
    >> >> 4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    >> >> companies won't support their products on SQL2005 yet.
    >> >> Also the apps that will happily run on a SQL2005 back end often won't
    >> >> actually install on it (MS guilty here too, together with the other
    >> >> usual
    >> >> suspects)
    >> >>
    >> >> Peter Lawton
    >> >

    >>
    >>
    >>
    Colin Barnhorst, Jul 20, 2006
    #7
  8. Dfosbenner:
    I use an APC RS 1500 with both of my Windows x64 towers plugged in. X64
    automatically picks up the monitor cable for the APC as a battery. In “Power
    Options Properties†a tab is added named “Power Meter†which lists the APC
    as a battery. Also under “Power Schemes†there are two entries “plugged inâ€
    and “running on batteriesâ€, I set the lines “turn off hard drivesâ€,
    “standby†and “hibernate†to “never†under both power schemes. When
    installing the APC software the message “APC Power Chute Personal Edition is
    unable to disable Windows native power management. You may receive messages
    windows relating to your battery. Occasionally I will receive a low battery
    message and twice in over two years the tower with the monitoring cable
    plugged in went into hibernation but that was before I changed the power
    scheme to never. My APC switches to battery regularly due to voltage changes
    and a few power outages and has had no effect on either towers’ function.
    Most likely server x64 will respond the same.


    "dfosbenner" <> wrote in message
    news:...
    >I was able to install and do a test backup with Backup Exec 10d, it worked
    > fine. I also got confirmation that Diskeeper is fully supported on x64.
    >
    > I can live with the lack of SAVCE AVServer if I have to. It's
    > disappointing
    > though.
    > Also, APC says they don't support x64 for PowerChute Bus. Edition. I
    > cannot
    > understand why. It seems to work when I tested it.
    >
    > I also found out Shavlik NetChkPro won't scan x64 systems until an update
    > in
    > 4Q06.
    >
    >
    > --
    > MCSE NT/2000/2003
    >
    >
    > "Peter Lawton" wrote:
    >
    >> The BackupExec 10d x64 agent works fine in my experience and SQL2005 is
    >> one
    >> app that does work very well on x64.
    >>
    >> I'm actually running 32bit SQL2000 on W2003 x64 on one of our servers at
    >> the
    >> moment so that I don't have to re-install the OS to go to SQL2005 x64
    >> when
    >> our app vendors will support it
    >>
    >> Peter Lawton
    >>
    >> "dfosbenner" <> wrote in message
    >> news:...
    >> > All good points. Backup Exec 10d has an x64 agent, I'm about to try it
    >> > out
    >> > this week.
    >> >
    >> > If I go with x64, and it's stable, then hopefully the other tools will
    >> > follow. Otherwise if I go 32bit, I'd have to reformat/reinstall to go
    >> > to
    >> > x64, NOT something I can do with a production server. SQL 2005 will be
    >> > our
    >> > main app on this box, and the applications are in house VB apps.
    >> > --
    >> > MCSE NT/2000/2003
    >> >
    >> >
    >> > "Peter Lawton" wrote:
    >> >
    >> >> As you say it's not x64 Windows that isn't ready for prime time it's
    >> >> the
    >> >> extremely slow pace of software support from other vendors (including
    >> >> MS)
    >> >>
    >> >> We're a Thin Client house running Citrix on W2003 x64 and although
    >> >> I've
    >> >> just
    >> >> very sucessfully moved our terminal servers to x64 a lot of our other
    >> >> servers have to stay on i386 because of lack of software vendor
    >> >> support.
    >> >>
    >> >> 1) ISA - no x64 compatible ISA from MS in sight at all, not even the
    >> >> version
    >> >> they haven't released yet.
    >> >>
    >> >> 2) Exchange - x64 only in the next release
    >> >>
    >> >> 3) Symantec AV - No sign of an x64 parent server yet and their "x64"
    >> >> client
    >> >> is a 32bit hack that won't even update it signatures from their own
    >> >> parent
    >> >> server.
    >> >>
    >> >> 4) SQL applications - Although a lot will work on SQL2005 x64 a lot of
    >> >> companies won't support their products on SQL2005 yet.
    >> >> Also the apps that will happily run on a SQL2005 back end often won't
    >> >> actually install on it (MS guilty here too, together with the other
    >> >> usual
    >> >> suspects)
    >> >>
    >> >> Peter Lawton
    >> >

    >>
    >>
    >>
    Dennis Pack x64, v64B2 \(5384\), OPP2007B2, Jul 20, 2006
    #8
  9. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    Lynn McGuire Guest

    >I suppose it depends on what a person wants to accomplish. I purchased a new
    > server this month and installed W2K3x64 on it, but quite a number of the
    > network utilities I'd use aren't supported.
    >
    > I'm sure that 32-bit Windows will more than handle the load on this system,
    > using x64 was more of an experiment with the latest technology. Has anyone
    > else tested out x64, then stepped back to 32?
    >
    > Maybe in a year when my next server is purchased I'll look at x64 again. It
    > seems like it needs to mature and receive more vendor support.


    Nope. Backwards compatibility is not there for Win16 and Dos16 apps.

    NTVDM needs to be ported to Windows X64 by MS.

    And yes, I know about DosBox. It is not acceptible.

    Lynn
    Lynn McGuire, Jul 20, 2006
    #9
  10. Lynn -
    You know I understand the why, but I have to tell you - there is zero
    chance that NTVDM will ever be ported to 64bit by MS. I'd suggest that the
    virtual machine route is pretty much your only option to have x64 Windows
    and still be able to use DOS applications.

    --
    Charlie.
    http://msmvps.com/xperts64


    Lynn McGuire wrote:
    >> I suppose it depends on what a person wants to accomplish. I purchased
    >> a new server this month and installed W2K3x64 on it, but quite a number
    >> of the network utilities I'd use aren't supported.
    >>
    >> I'm sure that 32-bit Windows will more than handle the load on this
    >> system, using x64 was more of an experiment with the latest technology.
    >> Has anyone else tested out x64, then stepped back to 32?
    >>
    >> Maybe in a year when my next server is purchased I'll look at x64 again.
    >> It seems like it needs to mature and receive more vendor support.

    >
    > Nope. Backwards compatibility is not there for Win16 and Dos16 apps.
    >
    > NTVDM needs to be ported to Windows X64 by MS.
    >
    > And yes, I know about DosBox. It is not acceptible.
    >
    > Lynn
    Charlie Russel - MVP, Jul 21, 2006
    #10
  11. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    Lynn McGuire Guest

    >> Nope. Backwards compatibility is not there for Win16 and Dos16 apps.
    >>
    >> NTVDM needs to be ported to Windows X64 by MS.
    >>
    >> And yes, I know about DosBox. It is not acceptible.


    > You know I understand the why, but I have to tell you - there is zero chance that NTVDM will ever be ported to 64bit by MS. I'd
    > suggest that the virtual machine route is pretty much your only option to have x64 Windows and still be able to use DOS
    > applications.


    Then Windows x64 will not be accepted on the desktop. Microsoft
    will start losing the battle to Linux / MaxOS / FreeBSD because they
    do support Dos16 and Win16 apps out of the box (via Wine). The
    number of mission critical Dos16 and Win16 apps is just totally
    amazing.

    I now that I keep harping on this but the firestorm is coming. MS is
    just being stupid here.

    Lynn
    Lynn McGuire, Jul 21, 2006
    #11
  12. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    Peter Lawton Guest

    I've just converted all our terminal servers sucessfully to x64 and none of
    the 50 odd apps our users need wouldn't run under x64 (two apps needed an
    update to the latest version)

    Personally I can't help feeling that if anyone's still relying on Win16 and
    Dos16 apps it's probably well past time that they upgraded their apps in any
    case.

    I expect it's going to be quite a few more years yet before MS stop
    supporting 32bit OS completely anyway, so why would anyone be so keen to
    upgrade to the latest and greatest x64 OS and still be happy to rely on
    16bit and DOS apps?

    Peter Lawton

    "Lynn McGuire" <> wrote in message
    news:...
    >>> Nope. Backwards compatibility is not there for Win16 and Dos16 apps.
    >>>
    >>> NTVDM needs to be ported to Windows X64 by MS.
    >>>
    >>> And yes, I know about DosBox. It is not acceptible.

    >
    >> You know I understand the why, but I have to tell you - there is zero
    >> chance that NTVDM will ever be ported to 64bit by MS. I'd suggest that
    >> the virtual machine route is pretty much your only option to have x64
    >> Windows and still be able to use DOS applications.

    >
    > Then Windows x64 will not be accepted on the desktop. Microsoft
    > will start losing the battle to Linux / MaxOS / FreeBSD because they
    > do support Dos16 and Win16 apps out of the box (via Wine). The
    > number of mission critical Dos16 and Win16 apps is just totally
    > amazing.
    >
    > I now that I keep harping on this but the firestorm is coming. MS is
    > just being stupid here.
    >
    > Lynn
    >
    >
    >
    Peter Lawton, Jul 22, 2006
    #12
  13. Nope, I absolutely do NOT agree. It is time and more to let go of 16 bit
    applications. And the tradeoffs are far better behaviour moving forward by
    not having to provide support for 16 bit apps.

    I repeat - run the 16 bit application in a (free) virtual environment.
    Either VMWare or Virtual Server, I don't care. The app will run just fine.


    --
    Charlie.
    http://msmvps.com/xperts64


    Lynn McGuire wrote:
    >>> Nope. Backwards compatibility is not there for Win16 and Dos16 apps.
    >>>
    >>> NTVDM needs to be ported to Windows X64 by MS.
    >>>
    >>> And yes, I know about DosBox. It is not acceptible.

    >
    >> You know I understand the why, but I have to tell you - there is zero
    >> chance that NTVDM will ever be ported to 64bit by MS. I'd suggest that
    >> the virtual machine route is pretty much your only option to have x64
    >> Windows and still be able to use DOS applications.

    >
    > Then Windows x64 will not be accepted on the desktop. Microsoft
    > will start losing the battle to Linux / MaxOS / FreeBSD because they
    > do support Dos16 and Win16 apps out of the box (via Wine). The
    > number of mission critical Dos16 and Win16 apps is just totally
    > amazing.
    >
    > I now that I keep harping on this but the firestorm is coming. MS is
    > just being stupid here.
    >
    > Lynn
    Charlie Russel - MVP, Jul 22, 2006
    #13
  14. Lynn's favourite app is a great little DOS application that will never get
    ported - LIST. I run my copy of LIST in a Win95 VM that I have here. Works
    fine for my needs.

    --
    Charlie.
    http://msmvps.com/xperts64


    Peter Lawton wrote:
    > I've just converted all our terminal servers sucessfully to x64 and none
    > of the 50 odd apps our users need wouldn't run under x64 (two apps needed
    > an update to the latest version)
    >
    > Personally I can't help feeling that if anyone's still relying on Win16
    > and Dos16 apps it's probably well past time that they upgraded their apps
    > in any case.
    >
    > I expect it's going to be quite a few more years yet before MS stop
    > supporting 32bit OS completely anyway, so why would anyone be so keen to
    > upgrade to the latest and greatest x64 OS and still be happy to rely on
    > 16bit and DOS apps?
    >
    > Peter Lawton
    >
    > "Lynn McGuire" <> wrote in message
    > news:...
    >>>> Nope. Backwards compatibility is not there for Win16 and Dos16 apps.
    >>>>
    >>>> NTVDM needs to be ported to Windows X64 by MS.
    >>>>
    >>>> And yes, I know about DosBox. It is not acceptible.

    >>
    >>> You know I understand the why, but I have to tell you - there is zero
    >>> chance that NTVDM will ever be ported to 64bit by MS. I'd suggest that
    >>> the virtual machine route is pretty much your only option to have x64
    >>> Windows and still be able to use DOS applications.

    >>
    >> Then Windows x64 will not be accepted on the desktop. Microsoft
    >> will start losing the battle to Linux / MaxOS / FreeBSD because they
    >> do support Dos16 and Win16 apps out of the box (via Wine). The
    >> number of mission critical Dos16 and Win16 apps is just totally
    >> amazing.
    >>
    >> I now that I keep harping on this but the firestorm is coming. MS is
    >> just being stupid here.
    >>
    >> Lynn
    Charlie Russel - MVP, Jul 22, 2006
    #14
  15. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    roman modic Guest

    Hello!

    "Charlie Russel - MVP" <> wrote in message news:...
    > Lynn's favourite app is a great little DOS application that will never get ported - LIST. I run my copy of LIST in a Win95 VM that
    > I have here. Works fine for my needs.
    >


    Is there no 32-bit alternative to LIST? For example
    I use 32-bit "FAR Manager" instead of 16-bit
    "Norton Commander":
    http://farmanager.com/index.php?l=en
    http://en.wikipedia.org/wiki/Norton_Commander

    Roman
    roman modic, Jul 22, 2006
    #15
  16. no. There is not, I'm afraid. And Vern Buerg, the author, is not likely to
    ever port it to Windows. It's written almost entirely in assembly, and
    making that a 32-bit app is just not going to happen. Too bad, really, but I
    understand.

    --
    Charlie.
    http://msmvps.com/xperts64


    roman modic wrote:
    > Hello!
    >
    > "Charlie Russel - MVP" <> wrote in message
    > news:...
    >> Lynn's favourite app is a great little DOS application that will never
    >> get ported - LIST. I run my copy of LIST in a Win95 VM that I have here.
    >> Works fine for my needs.

    >
    > Is there no 32-bit alternative to LIST? For example
    > I use 32-bit "FAR Manager" instead of 16-bit
    > "Norton Commander":
    > http://farmanager.com/index.php?l=en
    > http://en.wikipedia.org/wiki/Norton_Commander
    >
    > Roman
    Charlie Russel - MVP, Jul 22, 2006
    #16
  17. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    DP Guest

    Let me take a guess at what I think Lynn is referring to. If I'm wrong, I
    apologize.
    I'd be willing to bet that if you went across America and looked into the
    factories, distribution plants, printing plants, dairies, meat packers, etc,
    you'll find a lot of them with computers that are using old DOS programs to
    monitor and control activities. This could be running manufacturing
    machinery and printing presses, controlling inventory, even doing payroll
    and accounts payable/receivable.
    It could be that the original creator of this program went out of business a
    long time ago in one of the many shakeouts in the industry. Or it could be
    the creator of the program never had the programming moxie to bring it up to
    date in a reliable fashion so that it could work on later editions of
    Windows.
    Meanwhile, the end users possibly didn't have the bucks to upgrade. Or maybe
    they were using an old computer system and the DOS program worked for them.
    Anyway, I'm speculating here, but suffice it to say that in the real world
    where profit and loss matter, you might find that the end users are not as
    techonologically cutting edge as we x64 users might be. There's all sorts of
    reasons that businesses have had to stick with mission-critical DOS
    programs. Eventually, they'll have to upgrade computers as old ones die off.
    But when they go looking for new computers and OS's, they're probably going
    to look for ones that can still run their old DOS programs.
    Lynn, was I close?




    "Charlie Russel - MVP" <> wrote in message
    news:Og7i%...
    > no. There is not, I'm afraid. And Vern Buerg, the author, is not likely to
    > ever port it to Windows. It's written almost entirely in assembly, and
    > making that a 32-bit app is just not going to happen. Too bad, really, but
    > I understand.
    >
    > --
    > Charlie.
    > http://msmvps.com/xperts64
    >
    >
    > roman modic wrote:
    >> Hello!
    >>
    >> "Charlie Russel - MVP" <> wrote in message
    >> news:...
    >>> Lynn's favourite app is a great little DOS application that will never
    >>> get ported - LIST. I run my copy of LIST in a Win95 VM that I have here.
    >>> Works fine for my needs.

    >>
    >> Is there no 32-bit alternative to LIST? For example
    >> I use 32-bit "FAR Manager" instead of 16-bit
    >> "Norton Commander":
    >> http://farmanager.com/index.php?l=en
    >> http://en.wikipedia.org/wiki/Norton_Commander
    >>
    >> Roman

    >
    >
    DP, Jul 22, 2006
    #17
  18. I'm sure that's true. There are lots of legacy applications still out there,
    certainly. And they probably shouldn't be running on Windows x64. But they
    also should do quite well running in a virtual machine, since very few of
    them are likely to care about USB ports or Firewire ports, etc.

    --
    Charlie.
    http://msmvps.com/xperts64


    DP wrote:
    > Let me take a guess at what I think Lynn is referring to. If I'm wrong, I
    > apologize.
    > I'd be willing to bet that if you went across America and looked into the
    > factories, distribution plants, printing plants, dairies, meat packers,
    > etc, you'll find a lot of them with computers that are using old DOS
    > programs to monitor and control activities. This could be running
    > manufacturing machinery and printing presses, controlling inventory, even
    > doing payroll and accounts payable/receivable.
    > It could be that the original creator of this program went out of
    > business a long time ago in one of the many shakeouts in the industry. Or
    > it could be the creator of the program never had the programming moxie to
    > bring it up to date in a reliable fashion so that it could work on later
    > editions of Windows.
    > Meanwhile, the end users possibly didn't have the bucks to upgrade. Or
    > maybe they were using an old computer system and the DOS program worked
    > for them. Anyway, I'm speculating here, but suffice it to say that in the
    > real world where profit and loss matter, you might find that the end
    > users are not as techonologically cutting edge as we x64 users might be.
    > There's all sorts of reasons that businesses have had to stick with
    > mission-critical DOS programs. Eventually, they'll have to upgrade
    > computers as old ones die off. But when they go looking for new computers
    > and OS's, they're probably going to look for ones that can still run
    > their old DOS programs. Lynn, was I close?
    >
    >
    >
    >
    > "Charlie Russel - MVP" <> wrote in message
    > news:Og7i%...
    >> no. There is not, I'm afraid. And Vern Buerg, the author, is not likely
    >> to ever port it to Windows. It's written almost entirely in assembly, and
    >> making that a 32-bit app is just not going to happen. Too bad, really,
    >> but I understand.
    >>
    >> --
    >> Charlie.
    >> http://msmvps.com/xperts64
    >>
    >>
    >> roman modic wrote:
    >>> Hello!
    >>>
    >>> "Charlie Russel - MVP" <> wrote in
    >>> message news:...
    >>>> Lynn's favourite app is a great little DOS application that will never
    >>>> get ported - LIST. I run my copy of LIST in a Win95 VM that I have
    >>>> here. Works fine for my needs.
    >>>
    >>> Is there no 32-bit alternative to LIST? For example
    >>> I use 32-bit "FAR Manager" instead of 16-bit
    >>> "Norton Commander":
    >>> http://farmanager.com/index.php?l=en
    >>> http://en.wikipedia.org/wiki/Norton_Commander
    >>>
    >>> Roman
    Charlie Russel - MVP, Jul 23, 2006
    #18
  19. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    Lynn McGuire Guest

    > Let me take a guess at what I think Lynn is referring to. If I'm wrong, I apologize.
    > I'd be willing to bet that if you went across America and looked into the factories, distribution plants, printing plants,
    > dairies, meat packers, etc, you'll find a lot of them with computers that are using old DOS programs to monitor and control
    > activities. This could be running manufacturing machinery and printing presses, controlling inventory, even doing payroll and
    > accounts payable/receivable.
    > It could be that the original creator of this program went out of business a long time ago in one of the many shakeouts in the
    > industry. Or it could be the creator of the program never had the programming moxie to bring it up to date in a reliable fashion
    > so that it could work on later editions of Windows.
    > Meanwhile, the end users possibly didn't have the bucks to upgrade. Or maybe they were using an old computer system and the DOS
    > program worked for them.
    > Anyway, I'm speculating here, but suffice it to say that in the real world where profit and loss matter, you might find that the
    > end users are not as techonologically cutting edge as we x64 users might be. There's all sorts of reasons that businesses have had
    > to stick with mission-critical DOS programs. Eventually, they'll have to upgrade computers as old ones die off. But when they go
    > looking for new computers and OS's, they're probably going to look for ones that can still run their old DOS programs.
    > Lynn, was I close?


    Yup, my prediction is that people will be screaming when they get
    Windows x64 on their latest box and try to run their Dos16 or Win16
    mission critical app on it.

    My OPINION is that MS is missing the boat here on forwards
    compatibility. These apps need to work out of the box.

    I dont even care if MS automatically installs their own virtual environment.
    I just want a default solution that works out of the box.

    Lynn
    Lynn McGuire, Jul 26, 2006
    #19
  20. =?Utf-8?B?ZGZvc2Jlbm5lcg==?=

    John Boy Guest

    Lynn McGuire wrote:
    > Yup, my prediction is that people will be

    screaming when they get
    > Windows x64 on their latest box and try to run their Dos16 or Win16
    > mission critical app on it.
    >
    > My OPINION is that MS is missing the boat here on forwards
    > compatibility. These apps need to work out of the box.
    >
    > I dont even care if MS automatically installs their own virtual environment.
    > I just want a default solution that works out of the box.
    >
    > Lynn
    >
    >


    And I suppose you want your old black and white
    Capehart TV to display OTA HDTV without any
    additional hardware?
    John Boy, Jul 27, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim L
    Replies:
    21
    Views:
    928
    Ed Mullen
    Feb 17, 2005
  2. Porkys1982
    Replies:
    0
    Views:
    1,766
    Porkys1982
    Dec 10, 2006
  3. John Barnes

    Not ready for prime time

    John Barnes, Jun 5, 2005, in forum: Windows 64bit
    Replies:
    16
    Views:
    662
    Keith
    Jun 6, 2005
  4. Replies:
    0
    Views:
    412
  5. Giuen
    Replies:
    0
    Views:
    875
    Giuen
    Sep 12, 2008
Loading...

Share This Page