Turmoil Continues in XP land

[PCR]

Bill Blanton wrote:
| "PCR" <pcrrcp@netzero.net> wrote in message
| news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
|> Bill Blanton wrote:
|
|> | The "real" computer hardware doesn't matter at all. The VM
|> | communicates only
|> | with the host OS.
|>
|> OK. So, the host OS must first be able to recognize a new device.
|> Then, it's a matter of whether the VPC has something for that too
|> already built in. OK, then.
|
| No, the VM will operate even if the host OS does not have a similar
| device.
| However, if your host OS does not have a display adapter, for example,
| you're not going to "see" it. Or if your host OS does not have a sound
| card, you're not going to "hear" the virtual output.

I see, then, VM makes no attempt to recognize any device at all. It
presumes the device exists & it's up to the host OS to direct input &
output to them. Alright, then. How is a USB flash drive unavailable for
use by VM then? Wouldn't it just be a drive letter presented to VM by
the host OS, & visa versa?

|> |> But the virtual BIOS does access the real hardware at some point
|> |> -- doesn't it? --
|> |
|> | No, never. The virtual BIOS is just a set of software routines
|> | within the VM .
|> | The VM accesses Windows. Windows accesses the hardware.
|> |
|> | That's the point of it. Physical hardware doesn't matter. As long
|> | as the
|> | program running the VM is supported by the OS, the OS loaded within
|> | the VM will operate.
|>
|> Alright. I think I get it now. The VM BIOS communicates only with the
|> host OS to know what devices are available.
|
| (Excluding the CPU) It doesn't care what devices are on the host. It
| has its
| own set of virtual devices. It's its own "machine"

Would this for instance be a single virtual printer device? Or could
there be a number of them depending on type/model of printer?


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[Bill Blanton]

"PCR" <pcrrcp@netzero.net> wrote in message news:uRU9L%23$0IHA.4004@TK2MSFTNGP03.phx.gbl...
> Bill Blanton wrote:
> | "PCR" <pcrrcp@netzero.net> wrote in message
> | news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
> |> Bill Blanton wrote:
> |
> |> | The "real" computer hardware doesn't matter at all. The VM
> |> | communicates only
> |> | with the host OS.
> |>
> |> OK. So, the host OS must first be able to recognize a new device.
> |> Then, it's a matter of whether the VPC has something for that too
> |> already built in. OK, then.
> |
> | No, the VM will operate even if the host OS does not have a similar
> | device.
> | However, if your host OS does not have a display adapter, for example,
> | you're not going to "see" it. Or if your host OS does not have a sound
> | card, you're not going to "hear" the virtual output.
>
> I see, then, VM makes no attempt to recognize any device at all. It
> presumes the device exists & it's up to the host OS to direct input &
> output to them.

guest OS > virtual devices > host OS > real device

Something like that. It's a lot more complicated I'm sure,


> Alright, then. How is a USB flash drive unavailable for
> use by VM then? Wouldn't it just be a drive letter presented to VM by
> the host OS, & visa versa?

There is no virtual USB device in the virtual machine. You can use
a USB device (KB, mouse, drive), but not tied directly to the VM.

>
> |> |> But the virtual BIOS does access the real hardware at some point
> |> |> -- doesn't it? --
> |> |
> |> | No, never. The virtual BIOS is just a set of software routines
> |> | within the VM .
> |> | The VM accesses Windows. Windows accesses the hardware.
> |> |
> |> | That's the point of it. Physical hardware doesn't matter. As long
> |> | as the
> |> | program running the VM is supported by the OS, the OS loaded within
> |> | the VM will operate.
> |>
> |> Alright. I think I get it now. The VM BIOS communicates only with the
> |> host OS to know what devices are available.
> |
> | (Excluding the CPU) It doesn't care what devices are on the host. It
> | has its
> | own set of virtual devices. It's its own "machine"
>
> Would this for instance be a single virtual printer device? Or could
> there be a number of them depending on type/model of printer?

Printers are treated differently, and aren't really fully virtualized.

 

[PCR]

Bill Blanton wrote:
| "PCR" <pcrrcp@netzero.net> wrote in message
| news:uRU9L%23$0IHA.4004@TK2MSFTNGP03.phx.gbl...
|> Bill Blanton wrote:
|> | "PCR" <pcrrcp@netzero.net> wrote in message
|> | news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
|> |> Bill Blanton wrote:
|> |
|> |> | The "real" computer hardware doesn't matter at all. The VM
|> |> | communicates only
|> |> | with the host OS.
|> |>
|> |> OK. So, the host OS must first be able to recognize a new device.
|> |> Then, it's a matter of whether the VPC has something for that too
|> |> already built in. OK, then.
|> |
|> | No, the VM will operate even if the host OS does not have a similar
|> | device.
|> | However, if your host OS does not have a display adapter, for
|> | example, you're not going to "see" it. Or if your host OS does not
|> | have a sound card, you're not going to "hear" the virtual output.
|>
|> I see, then, VM makes no attempt to recognize any device at all. It
|> presumes the device exists & it's up to the host OS to direct input &
|> output to them.
|
| guest OS > virtual devices > host OS > real device
|
| Something like that. It's a lot more complicated I'm sure,

Alright. Are you sure the VM doesn't make an attempt to see what the
host OS has to offer? Doesn't it have to know how many partitions are
available at least? What if there are two printers or two of anything?

|> Alright, then. How is a USB flash drive unavailable for
|> use by VM then? Wouldn't it just be a drive letter presented to VM by
|> the host OS, & visa versa?
|
| There is no virtual USB device in the virtual machine. You can use
| a USB device (KB, mouse, drive), but not tied directly to the VM.

So, a USB flash drive can be used for input/output, but not as a boot
media? Then, a drive letter for it is presented to the guest OS but not
the to the VM BIOS?

|>
|> |> |> But the virtual BIOS does access the real hardware at some
|> |> |> point -- doesn't it? --
|> |> |
|> |> | No, never. The virtual BIOS is just a set of software routines
|> |> | within the VM .
|> |> | The VM accesses Windows. Windows accesses the hardware.
|> |> |
|> |> | That's the point of it. Physical hardware doesn't matter. As
|> |> | long as the
|> |> | program running the VM is supported by the OS, the OS loaded
|> |> | within the VM will operate.
|> |>
|> |> Alright. I think I get it now. The VM BIOS communicates only with
|> |> the host OS to know what devices are available.
|> |
|> | (Excluding the CPU) It doesn't care what devices are on the host.
|> | It has its
|> | own set of virtual devices. It's its own "machine"
|>
|> Would this for instance be a single virtual printer device? Or could
|> there be a number of them depending on type/model of printer?
|
| Printers are treated differently, and aren't really fully virtualized.

That was just an example. I suppose the VM has a frozen set of device
types it can use. I'm trying to determine whether there is also a frozen
set of drivers for any particular device type, or whether there is only
one virtual driver per device type. Is it one size fits all per device
type? I guess it would have to be that way, if the VM makes no attempt
at discovery-- unless the host OS is very specific in what it presents
to the VM on a per device basis.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[Bill Blanton]

"PCR" <pcrrcp@netzero.net> wrote in message news:u56nv$J1IHA.5472@TK2MSFTNGP06.phx.gbl...
> Bill Blanton wrote:
> | "PCR" <pcrrcp@netzero.net> wrote in message
> | news:uRU9L%23$0IHA.4004@TK2MSFTNGP03.phx.gbl...
> |> Bill Blanton wrote:
> |> | "PCR" <pcrrcp@netzero.net> wrote in message
> |> | news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
> |> |> Bill Blanton wrote:
> |> |
> |> |> | The "real" computer hardware doesn't matter at all. The VM
> |> |> | communicates only
> |> |> | with the host OS.
> |> |>
> |> |> OK. So, the host OS must first be able to recognize a new device.
> |> |> Then, it's a matter of whether the VPC has something for that too
> |> |> already built in. OK, then.
> |> |
> |> | No, the VM will operate even if the host OS does not have a similar
> |> | device.
> |> | However, if your host OS does not have a display adapter, for
> |> | example, you're not going to "see" it. Or if your host OS does not
> |> | have a sound card, you're not going to "hear" the virtual output.
> |>
> |> I see, then, VM makes no attempt to recognize any device at all. It
> |> presumes the device exists & it's up to the host OS to direct input &
> |> output to them.
> |
> | guest OS > virtual devices > host OS > real device
> |
> | Something like that. It's a lot more complicated I'm sure,
>
> Alright. Are you sure the VM doesn't make an attempt to see what the
> host OS has to offer?

For the most part, yes. There are special cases such as the CPU, mouse,
and KB

> Doesn't it have to know how many partitions are
> available at least?

No, you set up and use a virtual disk. You partition and format it
just as a real disk. The VM doesn't need to know what file system the
host is using or how its disk structure is set up. Virtual disk I/O is translated
to file I/O before it reaches the host, and vice versa



> What if there are two printers or two of anything?

I think you can use 2 or more printers, but as I said before printers
aren't fully virtualized. I've never had a need to set up a printer on
a VM, so don't know much about that aspect. If I need to print something
I copy/paste it into the host.

As far as fully virtualized devices such as the display adapter, there is only
one per VM. It doesn't matter that your real machine has two.



>
> |> Alright, then. How is a USB flash drive unavailable for
> |> use by VM then? Wouldn't it just be a drive letter presented to VM by
> |> the host OS, & visa versa?
> |
> | There is no virtual USB device in the virtual machine. You can use
> | a USB device (KB, mouse, drive), but not tied directly to the VM.
>
> So, a USB flash drive can be used for input/output, but not as a boot
> media? Then, a drive letter for it is presented to the guest OS but not
> the to the VM BIOS?

You can "share" a USB storage device, which is analogous to networking,
or you can put your virtual HD on a USB device, but you cannot access
the USB device at the USB level.



> |>
> |> |> |> But the virtual BIOS does access the real hardware at some
> |> |> |> point -- doesn't it? --
> |> |> |
> |> |> | No, never. The virtual BIOS is just a set of software routines
> |> |> | within the VM .
> |> |> | The VM accesses Windows. Windows accesses the hardware.
> |> |> |
> |> |> | That's the point of it. Physical hardware doesn't matter. As
> |> |> | long as the
> |> |> | program running the VM is supported by the OS, the OS loaded
> |> |> | within the VM will operate.
> |> |>
> |> |> Alright. I think I get it now. The VM BIOS communicates only with
> |> |> the host OS to know what devices are available.
> |> |
> |> | (Excluding the CPU) It doesn't care what devices are on the host.
> |> | It has its
> |> | own set of virtual devices. It's its own "machine"
> |>
> |> Would this for instance be a single virtual printer device? Or could
> |> there be a number of them depending on type/model of printer?
> |
> | Printers are treated differently, and aren't really fully virtualized.
>
> That was just an example. I suppose the VM has a frozen set of device
> types it can use.

Right. It has a set of built in devices.

> I'm trying to determine whether there is also a frozen
> set of drivers for any particular device type, or whether there is only
> one virtual driver per device type.

It emulates the devices, and the OS installed within the VM does the device
discovery and installs the drivers for the virtual devices. They are devices
for which Windows already has drivers. If you install an OS that does not
have drivers for the virtual devices, you would have to hunt them down
and install them yourself Just like in real life -)
..

Here's the list for VPC2004

BIOS - AMI BIOS
Chipset - Intel 440BX
Sound card - Creative Labs Sound Blaster 16 ISA Plug and Play
Network adapter - (multi-function) DEC 21140A 10/100
Video card - S3 Trio 32/64 PCI with 8 MB Video RAM




> Is it one size fits all per device
> type? I guess it would have to be that way, if the VM makes no attempt
> at discovery-- unless the host OS is very specific in what it presents
> to the VM on a per device basis.

The guest OS finds and communicates with the virtual devices. The virtual devices
do I/O with the host OS. The guest and host OS are oblivious of one another.
As far as the host OS is concerned, it (the VM) is a Windows program requesting
I/O through normal Windows program calls. Not low level functions.



Heh, we should probably wrap up this way OT thread soon. Besides that,
OE is going to start falling over itself

 

[PCR]

Bill Blanton wrote:
| "PCR" <pcrrcp@netzero.net> wrote in message
| news:u56nv$J1IHA.5472@TK2MSFTNGP06.phx.gbl...
|> Bill Blanton wrote:
|> | "PCR" <pcrrcp@netzero.net> wrote in message
|> | news:uRU9L%23$0IHA.4004@TK2MSFTNGP03.phx.gbl...
|> |> Bill Blanton wrote:
|> |> | "PCR" <pcrrcp@netzero.net> wrote in message
|> |> | news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
|> |> |> Bill Blanton wrote:
|> |> |
|> |> |> | The "real" computer hardware doesn't matter at all. The VM
|> |> |> | communicates only
|> |> |> | with the host OS.
|> |> |>
|> |> |> OK. So, the host OS must first be able to recognize a new
|> |> |> device. Then, it's a matter of whether the VPC has something
|> |> |> for that too already built in. OK, then.
|> |> |
|> |> | No, the VM will operate even if the host OS does not have a
|> |> | similar device.
|> |> | However, if your host OS does not have a display adapter, for
|> |> | example, you're not going to "see" it. Or if your host OS does
|> |> | not have a sound card, you're not going to "hear" the virtual
|> |> | output.
|> |>
|> |> I see, then, VM makes no attempt to recognize any device at all.
|> |> It presumes the device exists & it's up to the host OS to direct
|> |> input & output to them.
|> |
|> | guest OS > virtual devices > host OS > real device
|> |
|> | Something like that. It's a lot more complicated I'm sure,
|>
|> Alright. Are you sure the VM doesn't make an attempt to see what the
|> host OS has to offer?
|
| For the most part, yes. There are special cases such as the CPU,
| mouse,
| and KB

OK.

|> Doesn't it have to know how many partitions are
|> available at least?
|
| No, you set up and use a virtual disk. You partition and format it
| just as a real disk. The VM doesn't need to know what file system the
| host is using or how its disk structure is set up. Virtual disk I/O
| is translated
| to file I/O before it reaches the host, and vice versa

Oh. So, the guest OS doesn't get drive letters for the pre-existing
partitions of the host, (except as may be set up in a kind of Networking
situation you say below). OK, I see. For full partitions, it can only
set up & use its own virtual partitions. Alright. But the ones it does
set up do remain past one session. Fine.

|> What if there are two printers or two of anything?
|
| I think you can use 2 or more printers, but as I said before printers
| aren't fully virtualized. I've never had a need to set up a printer on
| a VM, so don't know much about that aspect. If I need to print
| something
| I copy/paste it into the host.

OK. It can be done, but it's easier to copy/paste. Someone who did want
to run a word processor in the guest OS could do so by going through the
extra trouble. OK, fine.

| As far as fully virtualized devices such as the display adapter,
| there is only
| one per VM. It doesn't matter that your real machine has two.

Very well. The virtual OS doesn't get to pick/choose.

|>
|> |> Alright, then. How is a USB flash drive unavailable for
|> |> use by VM then? Wouldn't it just be a drive letter presented to
|> |> VM by the host OS, & visa versa?
|> |
|> | There is no virtual USB device in the virtual machine. You can use
|> | a USB device (KB, mouse, drive), but not tied directly to the VM.
|>
|> So, a USB flash drive can be used for input/output, but not as a boot
|> media? Then, a drive letter for it is presented to the guest OS but
|> not the to the VM BIOS?
|
| You can "share" a USB storage device, which is analogous to
| networking,
| or you can put your virtual HD on a USB device, but you cannot access
| the USB device at the USB level.

OK. One could transfer downloads & other data from a real Win98 machine
through a USB drive, then. Very good.

|> |>
|> |> |> |> But the virtual BIOS does access the real hardware at some
|> |> |> |> point -- doesn't it? --
|> |> |> |
|> |> |> | No, never. The virtual BIOS is just a set of software
|> |> |> | routines within the VM .
|> |> |> | The VM accesses Windows. Windows accesses the hardware.
|> |> |> |
|> |> |> | That's the point of it. Physical hardware doesn't matter. As
|> |> |> | long as the
|> |> |> | program running the VM is supported by the OS, the OS loaded
|> |> |> | within the VM will operate.
|> |> |>
|> |> |> Alright. I think I get it now. The VM BIOS communicates only
|> |> |> with the host OS to know what devices are available.
|> |> |
|> |> | (Excluding the CPU) It doesn't care what devices are on the
|> |> | host. It has its
|> |> | own set of virtual devices. It's its own "machine"
|> |>
|> |> Would this for instance be a single virtual printer device? Or
|> |> could there be a number of them depending on type/model of
|> |> printer?
|> |
|> | Printers are treated differently, and aren't really fully
|> | virtualized.
|>
|> That was just an example. I suppose the VM has a frozen set of device
|> types it can use.
|
| Right. It has a set of built in devices.
|
|> I'm trying to determine whether there is also a frozen
|> set of drivers for any particular device type, or whether there is
|> only one virtual driver per device type.
|
| It emulates the devices, and the OS installed within the VM does the
| device
| discovery and installs the drivers for the virtual devices. They are
| devices
| for which Windows already has drivers. If you install an OS that does
| not
| have drivers for the virtual devices, you would have to hunt them down
| and install them yourself Just like in real life -)
| .
|
| Here's the list for VPC2004
|
| BIOS - AMI BIOS
| Chipset - Intel 440BX
| Sound card - Creative Labs Sound Blaster 16 ISA Plug and Play
| Network adapter - (multi-function) DEC 21140A 10/100
| Video card - S3 Trio 32/64 PCI with 8 MB Video RAM
|
|
|
|
|> Is it one size fits all per device
|> type? I guess it would have to be that way, if the VM makes no
|> attempt at discovery-- unless the host OS is very specific in what
|> it presents to the VM on a per device basis.
|
| The guest OS finds and communicates with the virtual devices. The
| virtual devices
| do I/O with the host OS. The guest and host OS are oblivious of one
| another.
| As far as the host OS is concerned, it (the VM) is a Windows program
| requesting
| I/O through normal Windows program calls. Not low level functions.

Alright. Then, I guess the guest OS is more/less stuck with generic
capabilities common to various devices that can be connected to the host
machine. The guest OS won't know of anything special in them. It won't
have specialized drivers. However, on the plus side, it does get to use
devices that otherwise might not work on a Win98 machine for lack of
drivers.

| Heh, we should probably wrap up this way OT thread soon. Besides that,
| OE is going to start falling over itself

I agree. I think I've found out enough for now. Thanks for all of this
information. It's enough for me. .


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net

 

[Bill Blanton]

"PCR" <pcrrcp@netzero.net> wrote in message news:%231ZLVhZ1IHA.416@TK2MSFTNGP04.phx.gbl...
> Bill Blanton wrote:
> | "PCR" <pcrrcp@netzero.net> wrote in message
> | news:u56nv$J1IHA.5472@TK2MSFTNGP06.phx.gbl...
> |> Bill Blanton wrote:
> |> | "PCR" <pcrrcp@netzero.net> wrote in message
> |> | news:uRU9L%23$0IHA.4004@TK2MSFTNGP03.phx.gbl...
> |> |> Bill Blanton wrote:
> |> |> | "PCR" <pcrrcp@netzero.net> wrote in message
> |> |> | news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
> |> |> |> Bill Blanton wrote:
> |> |> |
> |> |> |> | The "real" computer hardware doesn't matter at all. The VM
> |> |> |> | communicates only
> |> |> |> | with the host OS.
> |> |> |>
> |> |> |> OK. So, the host OS must first be able to recognize a new
> |> |> |> device. Then, it's a matter of whether the VPC has something
> |> |> |> for that too already built in. OK, then.
> |> |> |
> |> |> | No, the VM will operate even if the host OS does not have a
> |> |> | similar device.
> |> |> | However, if your host OS does not have a display adapter, for
> |> |> | example, you're not going to "see" it. Or if your host OS does
> |> |> | not have a sound card, you're not going to "hear" the virtual
> |> |> | output.
> |> |>
> |> |> I see, then, VM makes no attempt to recognize any device at all.
> |> |> It presumes the device exists & it's up to the host OS to direct
> |> |> input & output to them.
> |> |
> |> | guest OS > virtual devices > host OS > real device
> |> |
> |> | Something like that. It's a lot more complicated I'm sure,
> |>
> |> Alright. Are you sure the VM doesn't make an attempt to see what the
> |> host OS has to offer?
> |
> | For the most part, yes. There are special cases such as the CPU,
> | mouse,
> | and KB
>
> OK.
>
> |> Doesn't it have to know how many partitions are
> |> available at least?
> |
> | No, you set up and use a virtual disk. You partition and format it
> | just as a real disk. The VM doesn't need to know what file system the
> | host is using or how its disk structure is set up. Virtual disk I/O
> | is translated
> | to file I/O before it reaches the host, and vice versa
>
> Oh. So, the guest OS doesn't get drive letters for the pre-existing
> partitions of the host, (except as may be set up in a kind of Networking
> situation you say below). OK, I see. For full partitions, it can only
> set up & use its own virtual partitions. Alright. But the ones it does
> set up do remain past one session. Fine.

Yes, If you do a "save" on the session.


>
> |> What if there are two printers or two of anything?
> |
> | I think you can use 2 or more printers, but as I said before printers
> | aren't fully virtualized. I've never had a need to set up a printer on
> | a VM, so don't know much about that aspect. If I need to print
> | something
> | I copy/paste it into the host.
>
> OK. It can be done, but it's easier to copy/paste. Someone who did want
> to run a word processor in the guest OS could do so by going through the
> extra trouble. OK, fine.
>
> | As far as fully virtualized devices such as the display adapter,
> | there is only
> | one per VM. It doesn't matter that your real machine has two.
>
> Very well. The virtual OS doesn't get to pick/choose.
>
> |>
> |> |> Alright, then. How is a USB flash drive unavailable for
> |> |> use by VM then? Wouldn't it just be a drive letter presented to
> |> |> VM by the host OS, & visa versa?
> |> |
> |> | There is no virtual USB device in the virtual machine. You can use
> |> | a USB device (KB, mouse, drive), but not tied directly to the VM.
> |>
> |> So, a USB flash drive can be used for input/output, but not as a boot
> |> media? Then, a drive letter for it is presented to the guest OS but
> |> not the to the VM BIOS?
> |
> | You can "share" a USB storage device, which is analogous to
> | networking,
> | or you can put your virtual HD on a USB device, but you cannot access
> | the USB device at the USB level.
>
> OK. One could transfer downloads & other data from a real Win98 machine
> through a USB drive, then. Very good.

Yes, you can "share" drives/folders (not just USB) through a virtual network
between the host and guest OS. You can also network through the
host to get the guest online.




>
> |> |>
> |> |> |> |> But the virtual BIOS does access the real hardware at some
> |> |> |> |> point -- doesn't it? --
> |> |> |> |
> |> |> |> | No, never. The virtual BIOS is just a set of software
> |> |> |> | routines within the VM .
> |> |> |> | The VM accesses Windows. Windows accesses the hardware.
> |> |> |> |
> |> |> |> | That's the point of it. Physical hardware doesn't matter. As
> |> |> |> | long as the
> |> |> |> | program running the VM is supported by the OS, the OS loaded
> |> |> |> | within the VM will operate.
> |> |> |>
> |> |> |> Alright. I think I get it now. The VM BIOS communicates only
> |> |> |> with the host OS to know what devices are available.
> |> |> |
> |> |> | (Excluding the CPU) It doesn't care what devices are on the
> |> |> | host. It has its
> |> |> | own set of virtual devices. It's its own "machine"
> |> |>
> |> |> Would this for instance be a single virtual printer device? Or
> |> |> could there be a number of them depending on type/model of
> |> |> printer?
> |> |
> |> | Printers are treated differently, and aren't really fully
> |> | virtualized.
> |>
> |> That was just an example. I suppose the VM has a frozen set of device
> |> types it can use.
> |
> | Right. It has a set of built in devices.
> |
> |> I'm trying to determine whether there is also a frozen
> |> set of drivers for any particular device type, or whether there is
> |> only one virtual driver per device type.
> |
> | It emulates the devices, and the OS installed within the VM does the
> | device
> | discovery and installs the drivers for the virtual devices. They are
> | devices
> | for which Windows already has drivers. If you install an OS that does
> | not
> | have drivers for the virtual devices, you would have to hunt them down
> | and install them yourself Just like in real life -)
> | .
> |
> | Here's the list for VPC2004
> |
> | BIOS - AMI BIOS
> | Chipset - Intel 440BX
> | Sound card - Creative Labs Sound Blaster 16 ISA Plug and Play
> | Network adapter - (multi-function) DEC 21140A 10/100
> | Video card - S3 Trio 32/64 PCI with 8 MB Video RAM
> |
> |
> |
> |
> |> Is it one size fits all per device
> |> type? I guess it would have to be that way, if the VM makes no
> |> attempt at discovery-- unless the host OS is very specific in what
> |> it presents to the VM on a per device basis.
> |
> | The guest OS finds and communicates with the virtual devices. The
> | virtual devices
> | do I/O with the host OS. The guest and host OS are oblivious of one
> | another.
> | As far as the host OS is concerned, it (the VM) is a Windows program
> | requesting
> | I/O through normal Windows program calls. Not low level functions.
>
> Alright. Then, I guess the guest OS is more/less stuck with generic
> capabilities common to various devices that can be connected to the host
> machine. The guest OS won't know of anything special in them. It won't
> have specialized drivers. However, on the plus side, it does get to use
> devices that otherwise might not work on a Win98 machine for lack of
> drivers.
>
> | Heh, we should probably wrap up this way OT thread soon. Besides that,
> | OE is going to start falling over itself
>
> I agree. I think I've found out enough for now. Thanks for all of this
> information. It's enough for me. .

OK then, and later..
I'll bid a goodnight,, with a wiki-link -]
http://en.wikipedia.org/wiki/X86_virtualization
It's a general overview of virtualization, and touches on hardware support
for processor virtualization..(which we didn't discuss). Interesting stuff.

 

[PCR]

Bill Blanton wrote:
| "PCR" <pcrrcp@netzero.net> wrote in message
| news:%231ZLVhZ1IHA.416@TK2MSFTNGP04.phx.gbl...
|> Bill Blanton wrote:
|> | "PCR" <pcrrcp@netzero.net> wrote in message
|> | news:u56nv$J1IHA.5472@TK2MSFTNGP06.phx.gbl...
|> |> Bill Blanton wrote:
|> |> | "PCR" <pcrrcp@netzero.net> wrote in message
|> |> | news:uRU9L%23$0IHA.4004@TK2MSFTNGP03.phx.gbl...
|> |> |> Bill Blanton wrote:
|> |> |> | "PCR" <pcrrcp@netzero.net> wrote in message
|> |> |> | news:O4UZkKz0IHA.4912@TK2MSFTNGP03.phx.gbl...
|> |> |> |> Bill Blanton wrote:
|> |> |> |
|> |> |> |> | The "real" computer hardware doesn't matter at all. The VM
|> |> |> |> | communicates only
|> |> |> |> | with the host OS.
|> |> |> |>
|> |> |> |> OK. So, the host OS must first be able to recognize a new
|> |> |> |> device. Then, it's a matter of whether the VPC has something
|> |> |> |> for that too already built in. OK, then.
|> |> |> |
|> |> |> | No, the VM will operate even if the host OS does not have a
|> |> |> | similar device.
|> |> |> | However, if your host OS does not have a display adapter, for
|> |> |> | example, you're not going to "see" it. Or if your host OS
|> |> |> | does not have a sound card, you're not going to "hear" the
|> |> |> | virtual output.
|> |> |>
|> |> |> I see, then, VM makes no attempt to recognize any device at
|> |> |> all. It presumes the device exists & it's up to the host OS to
|> |> |> direct input & output to them.
|> |> |
|> |> | guest OS > virtual devices > host OS > real device
|> |> |
|> |> | Something like that. It's a lot more complicated I'm sure,
|> |>
|> |> Alright. Are you sure the VM doesn't make an attempt to see what
|> |> the host OS has to offer?
|> |
|> | For the most part, yes. There are special cases such as the CPU,
|> | mouse,
|> | and KB
|>
|> OK.
|>
|> |> Doesn't it have to know how many partitions are
|> |> available at least?
|> |
|> | No, you set up and use a virtual disk. You partition and format it
|> | just as a real disk. The VM doesn't need to know what file system
|> | the host is using or how its disk structure is set up. Virtual
|> | disk I/O is translated
|> | to file I/O before it reaches the host, and vice versa
|>
|> Oh. So, the guest OS doesn't get drive letters for the pre-existing
|> partitions of the host, (except as may be set up in a kind of
|> Networking situation you say below). OK, I see. For full partitions,
|> it can only set up & use its own virtual partitions. Alright. But
|> the ones it does set up do remain past one session. Fine.
|
| Yes, If you do a "save" on the session.
|
|
|>
|> |> What if there are two printers or two of anything?
|> |
|> | I think you can use 2 or more printers, but as I said before
|> | printers aren't fully virtualized. I've never had a need to set up
|> | a printer on a VM, so don't know much about that aspect. If I need
|> | to print something
|> | I copy/paste it into the host.
|>
|> OK. It can be done, but it's easier to copy/paste. Someone who did
|> want to run a word processor in the guest OS could do so by going
|> through the extra trouble. OK, fine.
|>
|> | As far as fully virtualized devices such as the display adapter,
|> | there is only
|> | one per VM. It doesn't matter that your real machine has two.
|>
|> Very well. The virtual OS doesn't get to pick/choose.
|>
|> |>
|> |> |> Alright, then. How is a USB flash drive unavailable for
|> |> |> use by VM then? Wouldn't it just be a drive letter presented to
|> |> |> VM by the host OS, & visa versa?
|> |> |
|> |> | There is no virtual USB device in the virtual machine. You can
|> |> | use a USB device (KB, mouse, drive), but not tied directly to
|> |> | the VM.
|> |>
|> |> So, a USB flash drive can be used for input/output, but not as a
|> |> boot media? Then, a drive letter for it is presented to the guest
|> |> OS but not the to the VM BIOS?
|> |
|> | You can "share" a USB storage device, which is analogous to
|> | networking,
|> | or you can put your virtual HD on a USB device, but you cannot
|> | access the USB device at the USB level.
|>
|> OK. One could transfer downloads & other data from a real Win98
|> machine through a USB drive, then. Very good.
|
| Yes, you can "share" drives/folders (not just USB) through a virtual
| network
| between the host and guest OS. You can also network through the
| host to get the guest online.
|
|
|
|
|>
|> |> |>
|> |> |> |> |> But the virtual BIOS does access the real hardware at
|> |> |> |> |> some point -- doesn't it? --
|> |> |> |> |
|> |> |> |> | No, never. The virtual BIOS is just a set of software
|> |> |> |> | routines within the VM .
|> |> |> |> | The VM accesses Windows. Windows accesses the hardware.
|> |> |> |> |
|> |> |> |> | That's the point of it. Physical hardware doesn't matter.
|> |> |> |> | As long as the
|> |> |> |> | program running the VM is supported by the OS, the OS
|> |> |> |> | loaded within the VM will operate.
|> |> |> |>
|> |> |> |> Alright. I think I get it now. The VM BIOS communicates only
|> |> |> |> with the host OS to know what devices are available.
|> |> |> |
|> |> |> | (Excluding the CPU) It doesn't care what devices are on the
|> |> |> | host. It has its
|> |> |> | own set of virtual devices. It's its own "machine"
|> |> |>
|> |> |> Would this for instance be a single virtual printer device? Or
|> |> |> could there be a number of them depending on type/model of
|> |> |> printer?
|> |> |
|> |> | Printers are treated differently, and aren't really fully
|> |> | virtualized.
|> |>
|> |> That was just an example. I suppose the VM has a frozen set of
|> |> device types it can use.
|> |
|> | Right. It has a set of built in devices.
|> |
|> |> I'm trying to determine whether there is also a frozen
|> |> set of drivers for any particular device type, or whether there is
|> |> only one virtual driver per device type.
|> |
|> | It emulates the devices, and the OS installed within the VM does
|> | the device
|> | discovery and installs the drivers for the virtual devices. They
|> | are devices
|> | for which Windows already has drivers. If you install an OS that
|> | does not
|> | have drivers for the virtual devices, you would have to hunt them
|> | down and install them yourself Just like in real life -)
|> | .
|> |
|> | Here's the list for VPC2004
|> |
|> | BIOS - AMI BIOS
|> | Chipset - Intel 440BX
|> | Sound card - Creative Labs Sound Blaster 16 ISA Plug and Play
|> | Network adapter - (multi-function) DEC 21140A 10/100
|> | Video card - S3 Trio 32/64 PCI with 8 MB Video RAM
|> |
|> |
|> |
|> |
|> |> Is it one size fits all per device
|> |> type? I guess it would have to be that way, if the VM makes no
|> |> attempt at discovery-- unless the host OS is very specific in what
|> |> it presents to the VM on a per device basis.
|> |
|> | The guest OS finds and communicates with the virtual devices. The
|> | virtual devices
|> | do I/O with the host OS. The guest and host OS are oblivious of one
|> | another.
|> | As far as the host OS is concerned, it (the VM) is a Windows
|> | program requesting
|> | I/O through normal Windows program calls. Not low level functions.
|>
|> Alright. Then, I guess the guest OS is more/less stuck with generic
|> capabilities common to various devices that can be connected to the
|> host machine. The guest OS won't know of anything special in them.
|> It won't have specialized drivers. However, on the plus side, it
|> does get to use devices that otherwise might not work on a Win98
|> machine for lack of drivers.
|>
|> | Heh, we should probably wrap up this way OT thread soon. Besides
|> | that, OE is going to start falling over itself
|>
|> I agree. I think I've found out enough for now. Thanks for all of
|> this information. It's enough for me. .
|
| OK then, and later..
| I'll bid a goodnight,, with a wiki-link -]
| http://en.wikipedia.org/wiki/X86_virtualization
| It's a general overview of virtualization, and touches on hardware
| support
| for processor virtualization..(which we didn't discuss). Interesting
| stuff.

OK, then. Goodnight. If it is a free download, surely I will take it a
day after the horrible day this Win98 crumbles to dust & I must puchase
a used XP-irradiated machine. I'm not half as stubborn as Colorado!


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR
pcrrcp@netzero.net