• Welcome to Tux Reports: Where Penguins Fly. We hope you find the topics varied, interesting, and worthy of your time. Please become a member and join in the discussions.

Looking toward 7 - and 16 bit progs.

T

Tony

Flightless Bird
I see Windows 7 on my horizon, and I also have several 16 bit legacy
programs I've used for years and want to keep. On one hand I hear
"Windows 7 and 16 bit? Fahgeddaboutit". On the other I hear that most
will work OK in compatibility mode in Windows 7. Anyone know the
straight dope on this? Thanks!

Tony
 
T

Tim Meddick

Flightless Bird
If a program will not run in "XP Compatibility Mode" under Win7, you can
always load a previous version of Windows to run in Microsoft's Virtual PC
(included with Win7) and run your software from under a "guest" operating
system.

==

Cheers, Tim Meddick, Peckham, London. :)




"Tony" <labombarda@hollow.oak> wrote in message
news:9OWdnWEvSMjP2RnR4p2dnAA@giganews.com...
>I see Windows 7 on my horizon, and I also have several 16 bit legacy
>programs I've used for years and want to keep. On one hand I hear
> "Windows 7 and 16 bit? Fahgeddaboutit". On the other I hear that most
> will work OK in compatibility mode in Windows 7. Anyone know the
> straight dope on this? Thanks!
>
> Tony
 
N

Nil

Flightless Bird
On 05 Sep 2010, Tony <labombarda@hollow.oak> wrote in
microsoft.public.windowsxp.general:

> I see Windows 7 on my horizon, and I also have several 16 bit
> legacy programs I've used for years and want to keep. On one hand
> I hear "Windows 7 and 16 bit? Fahgeddaboutit". On the other I
> hear that most will work OK in compatibility mode in Windows 7.
> Anyone know the straight dope on this? Thanks!


There is no straight dope. It will vary by program. Most 16-bit
programs will run just fine under 32-bit Windows 7.
 
P

Patok

Flightless Bird
Tim Meddick wrote:
> If a program will not run in "XP Compatibility Mode" under Win7, you can
> always load a previous version of Windows to run in Microsoft's Virtual
> PC (included with Win7) and run your software from under a "guest"
> operating system.


Can you install a DOS version in the VPC?

--
You'd be crazy to e-mail me with the crazy. But leave the div alone.
--
Whoever bans a book, shall be banished. Whoever burns a book, shall burn.
 
T

Tony

Flightless Bird
On 9/5/2010 10:34 PM, Nil wrote:
> On 05 Sep 2010, Tony<labombarda@hollow.oak> wrote in
> microsoft.public.windowsxp.general:
>
>> I see Windows 7 on my horizon, and I also have several 16 bit
>> legacy programs I've used for years and want to keep. On one hand
>> I hear "Windows 7 and 16 bit? Fahgeddaboutit". On the other I
>> hear that most will work OK in compatibility mode in Windows 7.
>> Anyone know the straight dope on this? Thanks!

>
> There is no straight dope. It will vary by program. Most 16-bit
> programs will run just fine under 32-bit Windows 7.



I appreciate the "encouraging word" Nil - thank you.

Tony
 
T

Tim Meddick

Flightless Bird
Microsoft Virtual PC (I have it on my XP PC) simulates a new PC with a BIOS
setup program and no operating system.

You create a "virtual" hard-drive, which is a file that resides on your own
hard-drive, and choose a size for it.

Likewise, you specify RAM (cannot be more than your PC has) for a given
installation.

You then install an OS to your virtual PC in exactly the same way as if it
were a real PC.

You can create as many "guest" operating systems as you like, and run them
windowed, or full-screen.

I have, to date, installed copies of :

DOS5
DOS6.22
DOS7.1
Win3.11
Win95
Win98SE
WinME
WinNT4
WinXP Home
Linux DSL

Whereas, with something like Win98SE I installed it from a cd-rom ISO image
file, with DOS I installed them either with a floppy disk or just used an
image of one.

VPC can use both the real cd/dvd or floppy drives attached to your system
OR can use image files (ISO files for cd/dvds or IMA / VFD uncompressed
disk images for floppies) as if they were real drives.

*Being able to read & write to floppy images.

Download Microsoft Virtual PC from :
http://www.microsoft.com/downloads/...02-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en

Download DOS floppy disk images (for use with VPC or Winimage)
from : http://www.bootdisk.com/bootdisk.htm

Also, you can use Winimage [free] to manipulate / read /write floppy
disk images and ISO images from :
http://www.winimage.com/download/winima85.exe



==

Cheers, Tim Meddick, Peckham, London. :)




"Patok" <crazy.div.patok@gmail.com> wrote in message
news:i61kok$uo3$1@news.eternal-september.org...
> Tim Meddick wrote:
>> If a program will not run in "XP Compatibility Mode" under Win7, you can
>> always load a previous version of Windows to run in Microsoft's Virtual
>> PC (included with Win7) and run your software from under a "guest"
>> operating system.

>
> Can you install a DOS version in the VPC?
>
> --
> You'd be crazy to e-mail me with the crazy. But leave the div alone.
> --
> Whoever bans a book, shall be banished. Whoever burns a book, shall burn.
 
V

VanguardLH

Flightless Bird
Patok wrote:

> Tim Meddick wrote:
>
>> If a program will not run in "XP Compatibility Mode" under Win7, you can
>> always load a previous version of Windows to run in Microsoft's Virtual
>> PC (included with Win7) and run your software from under a "guest"
>> operating system.

>
> Can you install a DOS version in the VPC?


You can install any IBM/MS OS in a guest (VM). Question is if you can
find the old IBM/MS-DOS to install (versus just getting a bootable
kernel, like at bootdisk.com). There were some free DOS around (e.g.,
FreeDOS).

Be aware that any program that attempts direct access to the hardware
will fail inside a VM. Direct calls to drivers or hardware interfaces
are not allowed since the VM is still running atop of an NT-based
version of Windows. Calls through the system API will work okay.

As I recall, programs that load and rely on DPMI or other memory
management schemes won't work inside a VM. If you have old DOS programs
that require direct access to hardware or using memory mgmt schemes then
better is to use multiple partitions and a boot manager to select
between them where an NT-based version is in one partition and a
DOS/Win9x-based version is in the other partition.

Since the OP is asking in a Windows XP newsgroup, and ASSUMING that the
DOS programs of interest actually installed and ran okay under Windows
XP, then they should install and run okay in the Windows XP
Compatibility Mode available in Windows 7. If that doesn't work, the OP
might want to look at DosBox:

http://en.wikipedia.org/wiki/DOSBox
http://www.dosbox.com/

If the "legacy programs" are games, the DosBox site even has lists of
old DOS games and remarks regarding their usability under DosBox.
 
B

Bill in Co

Flightless Bird
If you've got to go to that trouble, it would be worth sticking with WinXP.
(You can still get some used systems if needbe, methinks; I doubt if you can
get them new anymore, though - which is really too bad. XP is bloated
enough :).

Tim Meddick wrote:
> If a program will not run in "XP Compatibility Mode" under Win7, you can
> always load a previous version of Windows to run in Microsoft's Virtual PC
> (included with Win7) and run your software from under a "guest" operating
> system.
>
> ==
>
> Cheers, Tim Meddick, Peckham, London. :)
>
>
>
>
> "Tony" <labombarda@hollow.oak> wrote in message
> news:9OWdnWEvSMjP2RnR4p2dnAA@giganews.com...
>> I see Windows 7 on my horizon, and I also have several 16 bit legacy
>> programs I've used for years and want to keep. On one hand I hear
>> "Windows 7 and 16 bit? Fahgeddaboutit". On the other I hear that most
>> will work OK in compatibility mode in Windows 7. Anyone know the
>> straight dope on this? Thanks!
>>
>> Tony
 
P

PA Bear [MS MVP]

Flightless Bird
Why not check Win7 Help? => http://windows.microsoft.com/en-US/windows7/help

Or post your question in this forum? =>
http://social.answers.microsoft.com/Forums/en-US/w7programs/threads
--
~PA Bear


Tony wrote:
> I see Windows 7 on my horizon, and I also have several 16 bit legacy
> programs I've used for years and want to keep. On one hand I hear
> "Windows 7 and 16 bit? Fahgeddaboutit". On the other I hear that most
> will work OK in compatibility mode in Windows 7. Anyone know the
> straight dope on this? Thanks!
 
T

Tim Meddick

Flightless Bird
While what you say is perfectly true concerning software running inside VPC
and attempting to access hardware resources, with the exception of any
cd/dvd drives and floppy disk drives attached to the system.

The VPC application is able to gain access to these devices, as, if it
could not, the installation of guest operating systems could not be done
using cd/dvd-roms or by floppy disk.

Having said all this, Virtual PC provides support for some PC's which
posses Hardware Assisted Virtualization. Although this feature is not
common, if your PC has it, hardware *would* then be accessible to a guest
OS running in a VPC window.

==

Cheers, Tim Meddick, Peckham, London. :)




"VanguardLH" <V@nguard.LH> wrote in message
news:i61n3u$f4l$1@news.albasani.net...
> Patok wrote:
>
>> Tim Meddick wrote:
>>
>>> If a program will not run in "XP Compatibility Mode" under Win7, you
>>> can
>>> always load a previous version of Windows to run in Microsoft's Virtual
>>> PC (included with Win7) and run your software from under a "guest"
>>> operating system.

>>
>> Can you install a DOS version in the VPC?

>
> You can install any IBM/MS OS in a guest (VM). Question is if you can
> find the old IBM/MS-DOS to install (versus just getting a bootable
> kernel, like at bootdisk.com). There were some free DOS around (e.g.,
> FreeDOS).
>
> Be aware that any program that attempts direct access to the hardware
> will fail inside a VM. Direct calls to drivers or hardware interfaces
> are not allowed since the VM is still running atop of an NT-based
> version of Windows. Calls through the system API will work okay.
>
> As I recall, programs that load and rely on DPMI or other memory
> management schemes won't work inside a VM. If you have old DOS programs
> that require direct access to hardware or using memory mgmt schemes then
> better is to use multiple partitions and a boot manager to select
> between them where an NT-based version is in one partition and a
> DOS/Win9x-based version is in the other partition.
>
> Since the OP is asking in a Windows XP newsgroup, and ASSUMING that the
> DOS programs of interest actually installed and ran okay under Windows
> XP, then they should install and run okay in the Windows XP
> Compatibility Mode available in Windows 7. If that doesn't work, the OP
> might want to look at DosBox:
>
> http://en.wikipedia.org/wiki/DOSBox
> http://www.dosbox.com/
>
> If the "legacy programs" are games, the DosBox site even has lists of
> old DOS games and remarks regarding their usability under DosBox.
 
P

Paul

Flightless Bird
Tim Meddick wrote:

>
> Having said all this, Virtual PC provides support for some PC's which
> posses Hardware Assisted Virtualization. Although this feature is not
> common, if your PC has it, hardware *would* then be accessible to a
> guest OS running in a VPC window.
>
> ==
>
> Cheers, Tim Meddick, Peckham, London. :)


I've tested the Hardware Assisted Virtualization on VPC 2007 and
can see no practical difference with it turned on or turned off.
It makes a slight difference to the crashing problems some
Linux distros have in that environment (some distros crash in VPC 2007),
and in particular, some part of the Linux kernel seems to be interested in
whether the environment is virtualized or not. Other than
that, as far as I can see here, it's a giant no-op.

I have a copy of Win2K running in VPC 2007 right now. Hardware
virtualization is enabled in the interface (that "tick box" in the
setup interface). This is what Everest (from Lavalys) shows.

DEC 21140 Fast Ethernet Adapter
Intel 82371AB PCI ISA IDE Xcelerator
Intel 82371AB/EB PIIX4 - IDE Controller
Intel 82371EB PIIX4E - Power Management Controller
Intel 82443BX/ZX Host bridge/controller (AGP Disabled)
S3 Trio32/Trio64 video adapter

There is no evidence of access of native hardware in there.
(My system is X48/ICH9, with an Nvidia video card,
and none of it is visible. The above items are all emulated.)

It's the same old emulated hardware that would be present
if the hardware virtualization box was unticked. I'd certainly
like to be shed of the S3 emulation, and would much prefer to
see my Nvidia video card instead, but that isn't going to
happen.

*******

I haven't had an opportunity to test this on AMD hardware (like AM2 or later),
and perhaps VPC 2007 behaves differently in that case (like perhaps
the IOMMU makes a difference). Maybe someone else could test that
in VPC 2007 and see whether Everest reports more hardware is visible.

http://en.wikipedia.org/wiki/X86_virtualization

(Free version of Everest, sufficient for this test)

http://majorgeeks.com/download4181.html

*******

It might also be fun, to run Everest in "WinXP Mode" on Windows 7,
and see whether the bus looks any different than the above. I don't
have Windows 7 here, so can't test that.

Paul
 
V

VanguardLH

Flightless Bird
Tim Meddick wrote:

> While what you say is perfectly true concerning software running inside VPC
> and attempting to access hardware resources, with the exception of any
> cd/dvd drives and floppy disk drives attached to the system.
>
> The VPC application is able to gain access to these devices, as, if it
> could not, the installation of guest operating systems could not be done
> using cd/dvd-roms or by floppy disk.
>
> Having said all this, Virtual PC provides support for some PC's which
> posses Hardware Assisted Virtualization. Although this feature is not
> common, if your PC has it, hardware *would* then be accessible to a guest
> OS running in a VPC window.


The only real hardware available inside a virtual machine is the CPU.
All other hardware is emulated or a pass-through *driver* is used.
Pass-through mode to connect a real CD drive to emulate a CD drive
inside the VM is *not* accessing the hardware directly (which, for
example, would be to access the hardware interface of a device by its
address). The passthrough mode permits redirection of the emulated
device to the kernel-mode driver for the real device. DOS programs that
directly access the hardware weren't going through a driver which
provided an API to the OS and apps running at kernel level to provide
the actual physical interface to the device. The lack of a USB
pass-through adapter in VirtualPC is why you can't use USB devices
inside of it. HID devices, like mice and keyboard, are completely
emulated (no pass-through mode) and why a USB foot pedal listed as a HID
device in Device Manager still cannot be seen into the VM. While
VirtualPC 2007 has no pass-through mode for USB devices, the Windows
Virtual PC (XP Mode in Windows 7) does have a pass-through mode for USB
devices. In Windows 7's XP mode, there is redirection permitted for USB
storage devices. That redirection goes to the driver that provides the
interface between OS and device. It is not providing direct access to
the the device to an app, like the guest running under a VMM. Under
DOS, you can access a device without using a driver for it. That's what
I mean by direct access. For example, and only from memory, I think
address 80 was for the first IDE mass storage device (hard disk) and 81
was for the second one (in the order they were detected by the BIOS).
It was possible to remove a hard disk partition by using debug.exe which
sent commands directly to the device, not through system API calls or
driver interfaces.

The CPU is directly accessible but often reported by the VMM as
something else (and how some malware can detect they are running inside
a VM so they remain quiescent hoping you'll install them outside the
VM). That's it. The pass-through drivers provide their own interface
from the emulated device to the real hardware. The VMM on the host has
to provide the redirection for the USB, serial, and parallel devices
inside the guest. Because of this *redirection*, you can disconnect the
guest's CD drive and connect it to any other physical drive on the host.
All the rest is emulated hardware.

HAV (hardware-assisted virtualization) only provides hardware-level code
to more quickly what would be needed by software emulation. In some
cases, HAV can actually slow the VM. As I recall reading about
Sun/Oracle VirtualBox, they actually recommended disabling HAV because
the made slower the responsiveness of their VM (i.e., the code for their
software emulation was better optimized than the firmware on the CPU's
die). HAV does *not* magically provide direct access to hardware
devices from inside a VM. I don't recall if HAV helps or hinders
performance for VPC. HAV is for helping the VMM (Virtual Machine
Manager) do its job or to eliminate translation for guest system calls,
not alter the emulated environment generated by the VMM. The VMM can
use HAV. The HAV eliminates [some of] the abstraction layer needed
between guest and VMM. Yeah, you can access hardware from the guest if
you use standard kernel API calls but not if you attempt direct access
to the hardware device's interface (i.e., you are not using the system
API). The HAV assists the VMM, not bypasses it. It is an enabler for
full virtualization so an unmodified OS can run as a guest (in a VM).
Putting the translations for the abstraction layer or VM traps into
firmware doesn't suddenly change how the scheme works. It facilitates
the use of the faster hardware instead of having to use the slower
software. Hardware is always faster than software (well, usually that's
true unless the firmware is not optimized). The VMM remains in control
of the virtualized environment that it defines to the guest. If it
doesn't, it is a "leaky" VMM and not worthy as a contender in today's
competition for VMMs.

Do some reading:
http://en.wikipedia.org/wiki/Hardware-assisted_virtualization
 
T

Tim Meddick

Flightless Bird
That is disappointing - and not at all what the literature implies when
extolling the virtues of running VPC on a PC that supports Hardware
Virtualization!

==

Cheers, Tim Meddick, Peckham, London. :)




"Paul" <nospam@needed.com> wrote in message
news:i63p7m$a4b$1@speranza.aioe.org...
> Tim Meddick wrote:
>
>>
>> Having said all this, Virtual PC provides support for some PC's which
>> posses Hardware Assisted Virtualization. Although this feature is not
>> common, if your PC has it, hardware *would* then be accessible to a
>> guest OS running in a VPC window.
>>
>> ==
>>
>> Cheers, Tim Meddick, Peckham, London. :)

>
> I've tested the Hardware Assisted Virtualization on VPC 2007 and
> can see no practical difference with it turned on or turned off.
> It makes a slight difference to the crashing problems some
> Linux distros have in that environment (some distros crash in VPC 2007),
> and in particular, some part of the Linux kernel seems to be interested
> in
> whether the environment is virtualized or not. Other than
> that, as far as I can see here, it's a giant no-op.
>
> I have a copy of Win2K running in VPC 2007 right now. Hardware
> virtualization is enabled in the interface (that "tick box" in the
> setup interface). This is what Everest (from Lavalys) shows.
>
> DEC 21140 Fast Ethernet Adapter
> Intel 82371AB PCI ISA IDE Xcelerator
> Intel 82371AB/EB PIIX4 - IDE Controller
> Intel 82371EB PIIX4E - Power Management Controller
> Intel 82443BX/ZX Host bridge/controller (AGP Disabled)
> S3 Trio32/Trio64 video adapter
>
> There is no evidence of access of native hardware in there.
> (My system is X48/ICH9, with an Nvidia video card,
> and none of it is visible. The above items are all emulated.)
>
> It's the same old emulated hardware that would be present
> if the hardware virtualization box was unticked. I'd certainly
> like to be shed of the S3 emulation, and would much prefer to
> see my Nvidia video card instead, but that isn't going to
> happen.
>
> *******
>
> I haven't had an opportunity to test this on AMD hardware (like AM2 or
> later),
> and perhaps VPC 2007 behaves differently in that case (like perhaps
> the IOMMU makes a difference). Maybe someone else could test that
> in VPC 2007 and see whether Everest reports more hardware is visible.
>
> http://en.wikipedia.org/wiki/X86_virtualization
>
> (Free version of Everest, sufficient for this test)
>
> http://majorgeeks.com/download4181.html
>
> *******
>
> It might also be fun, to run Everest in "WinXP Mode" on Windows 7,
> and see whether the bus looks any different than the above. I don't
> have Windows 7 here, so can't test that.
>
> Paul
 
T

Tim Slattery

Flightless Bird
Tony <labombarda@hollow.oak> wrote:

>I see Windows 7 on my horizon, and I also have several 16 bit legacy
>programs I've used for years and want to keep. On one hand I hear
>"Windows 7 and 16 bit? Fahgeddaboutit". On the other I hear that most
>will work OK in compatibility mode in Windows 7. Anyone know the
>straight dope on this? Thanks!


The 64-bit versions of MS's operating systems won't run 16-bit
programs. That can be overcome by using a virtual machine. The 32-bit
versions of the OSs - including 32-bit Win7 - will run 16-bit
programs. A few older programs that try to access hardware directly
will have problems, but most will run fine.

--
Tim Slattery
Slattery_T@bls.gov
http://members.cox.net/slatteryt
 
Top