Turmoil Continues in XP land

[Guest Bill Blanton]

Re: Turmoil Continues in XP land

 

I can't respond to your message. Outlook express is too stupid too

handle a thread this deep, so I'll put it here:

 

 

 

"PCR" <pcrrcp@netzero.net> wrote in message news:e2833JD0IHA.4004@TK2MSFTNGP03.phx.gbl...

> Bill Blanton wrote:

> | "PCR" <pcrrcp@netzero.net> wrote in message

> | news:ur%23M2SyzIHA.4040@TK2MSFTNGP04.phx.gbl...

> |> Bill Blanton wrote:

> |> | "PCR" <pcrrcp@netzero.net> wrote in message

> |> | news:ObJvEPpzIHA.4912@TK2MSFTNGP03.phx.gbl...

> |> |> Bill Blanton wrote:

> |> |> | "Bill in Co." <not_really_here@earthlink.net> wrote in message

> |> |> | news:ezMUmjZzIHA.2064@TK2MSFTNGP05.phx.gbl...

> |> |> |> PCR wrote:

> |> |> |>> Bill in Co. wrote:

> |> |> |>>> PCR wrote:

> |> |> |>>>> Bill in Co. wrote:

> |> |> |>>>>> PCR wrote:

> |> |> |>>>>>> Bill in Co. wrote:

> |> |> |>>>>>>> PCR wrote:

> |> |> |>>>>>>>> Bill in Co. wrote:

> |> |

> |> |> |>>>>>>>>> One can also install Microsoft's Virtual PC, which

> |> |> |>>>>>>>>> allegedly allows you to run Win98SE (or some other

> |> |> |>>>>>>>>> operating systems)

> |> |

> |> |> | Software-wise there isn't much difference. You are however

> |> |> | confined to the

> |> |> | emulated hardware of the virtual machine.

> |> |

> |> |

> |> |> |>>>> I think the partition would be fake-- just a simulation!

> |> |> |>>>> You'd never be able to do normal maintenance on it, like a

> |> |> |>>>> scandisk & defrag-- I don't think!

> |> |> |

> |> |> | No, the disk structure is emulated just as a real disk. You can

> |> |> | scandisk, defrag,

> |> |> | go in and muck around witht the partition tables or boot

> |> |> | sectors, install a boot

> |> |> | manager, muti-boot, whatever..

> |> |

> |> |

> |> |> That's an excellent emulation, then. But how can that be? Are you

> |> |> be able to boot to DOS or to a Starup Diskette to do that? I

> |> |> thought WinXP couldn't! Or is this done from some sort of CD boot

> |> |> to a repair console?

> |> |

> |> | Yes, you can boot to a boot floppy or CD. Real or virtual. I've

> |> | got a folder

> |> | full of virtual boot media. (much faster booting than the real

> |> | thing)

> |> |

> |> | It's a PC as far as the OS is concerned, and boots the same way.

> |> | The virtual

> |> | BIOS loads the MBR, the MBR loads the boot sector, which loads

> |> | Windows.

> |> |

> |> | The virtual hadr disk is one big file on the host machine. Copying

> |> | the file

> |> | is analogous to cloning your HD.

> |>

> |> That's very impressive. But the BIOS is virtual too? So, even this

> |> BIOS won't work, until you've boot to XP first & began the Win98

> |> simulation?

> |

> | It's not XP, though I think that it the minimum requirement for VPC.

> | VPC

> | is software that emulates a PC. It runs as a "process" on the host OS.

> | Not necessarily XP.

>

> I guess the only other choice would be Vista, then, for now. But,

> whichever it is, it must boot first to set up (or allow VPC to set up?)

> the process that is VPC. I suppose the host OS continues to run-- so,

> you now have two machines running at once & can click between the two?

 

Yea, the virtual machine runs as a process in its own "window", just as other

programs. You can toggle to a "Full screen" if you want the total effect.

Boot the host OS, run the program VPC, then choose which virtual machine to

run. (sorta' like an "open file" on your favorite word processor)

> | You boot the virtual machine and install your OS, just as you do on a

> | "real"

> | machine.

>

> Hmm. Amazing. I would have thought the VPC came with Win98

> pre-installed.

 

When you set up a new virtual machine, it's basically a PC with a blank

hard drive. You can boot with your floppy, fdisk, run the windows setup,

whatever you want. I believe that when Connectix owned it you could

install Linux. I'm not sure if MS has blocked this or not. You can also run

more than one virtual install at once, depending on your resources. (memory,

a fairly fast CPU)

 

Virtual Windows installs also require a license, and in the case of XP and

Vista, you do have to activate your copy.

 

>

> | Even though your BIOS is burned into a chip, it is still just

> | software code

> | that loads when you boot.

>

> Of course, you know, not all BIOS code is the same. Therefore, some

> recognize devices (maybe even the MB?) that others do not & have

> capabilities (large HDD support, multi-booting, etc.) that others do

> not. Normally, one wouldn't want to put another machine's BIOS into his!

 

The "virtual motherboard" contains well supported devices, and does not

change. You can specify what size HD, up to a limit, but other than that

you don't have any control over the harware, It would be nice if the

interface was open and devs could write out new virtual devices, which

you could then "plug in". It might open up a whole new market.

 

>

> | Virtualzation software just removes that "physical" hardware layer,

> | and

> | replaces it with "virtual" hardware.

>

> This virtual BIOS that VPC supplies-- doesn't it need to be specific to

> the machine that it will run on?

 

No, it's the same BIOS and devices no matter what PC you put it on.

It's virtual ;-)

 

> I see elsewhere you said...

>

> "Unfortunately VPC does not support USB."

>

> "There's not as much config in there as most BIOSs. But there is IDE

> boot order,

> IDE device config settings. password config, pwer management (IIRC)..

> some other basic stuff.... clock..."

>

> Too bad they didn't write it to actually use the BIOS that is installed

> in the machine or to make a copy & use the copy (as I think Colorado

> speculated it might be doing). Then, it would have the full

> capabilities-- & no one would have to give up his flash drive!

 

That kinda' gets away from the whole concept. It wouldn't be virtual then.

It'd be closer to a real OS, and have to support the myriad machines on the

market. If your accessing the real hadrware, you have to read/write to the

real hardware. What would be the point? In that case it would be a full

blown OS.

 

 

>

> | When the OS accesses the hardware it calls upon the

> | virtual hardware and the virtual hardware returns the information

> | pertaining to its own configuration, just as your "real" hardware

> | does.

> | It's all just a stream of bits and bytes. What's "hardware" to the OS

> | anyway?

>

> Unfortunately, though, it seems VPC has no bits for USB-- Colorado is

> chagrinned! He loves his flash drive!

 

Who doesn't love a flash drive?! ;-)

 

Like I said somewhere else,, MS hasn't done much with it since they bought

Connectix out. Frankly, they haven't done much but change all the "Connectix"

strings to "Microsoft". In VPC2004 you could still find some errant "Connectix"

strings in the help files.

 

VMWare supports USB. On VPC, you can create virtual CDs which will

load/run/boot faster than any physical USB device.

 

>

> |>

> |> |> |>>>

> |> |> |>>> Would that really be necessary, considering you're only

> |> |> |>>> running a session of it for a limited time, which ends when

> |> |> |>>> you quit VPC? And maybe it uses something called a virtual

> |> |> |>>> disk (I forgot the correct term), which disappears when you

> |> |> |>>> quit VPC.

> |> |> |>>

> |> |> |>> Huh? I thought it would be permanent. What good is a

> |> |> |>> disappearing Win98?

> |> |> |>

> |> |> |> I think the session disappears - not that you have to reinstall

> |> |> |> W98 each time!

> |> |> |

> |> |> | You have a choice when you shut down, Save changes, delete

> |> |> | changes, or save and save state (think hibernate). Install your

> |> |> | favorite

> |> |> | program, shut

> |> |> | down and save. Install some crap program, trash the OS, then

> |> |> | shut down without a save. It's great for testing programs before

> |> |> | putting them on your production machine. That's just one use of

> |> |> | course.

> |> |>

> |> |> I thought it would be something like that-- not too bad!

> |> |>

> |> |> | Personally, I haven't had a real need to multi-boot, since

> |> |> | installing VPC.

> |> |> |

> |> |> |

> |> |> |>>>> Probably, lots of system settings would look weird-- if you

> |> |> |>>>> could even find them!

> |> |> |

> |> |> | No, not at all.

> |> |>

> |> |> So... doing as I do here answering posts in this NG... all of my

> |> |> Master Posts still would apply? All of the settings I point to

> |> |> for a fix would be in the same places & mean the same thing?

> |> |

> |> | If it's software code, pretty much. Hardware is a different matter.

> |>

> |> OK. I was wondering whether I could still look things up &

> |> participate in this NG from an XP virtual Win98. Sounds like it

> |> could be mostly doable, but looking up hardware settings & Registry

> |> keys to post would become problematic.

> |

> |

> | The Windows registry on a virtual Windows install is the same as on a

> | real

> | machine.

> |

> | It is just that the hardware is fixed. There's a basic virtual video

> | adapter,

> | sound card, generic IDE adapter, network card. Reg-wise those values

> | would be

> | different than what your "real" system has. Just as your hardware is

> | different than

> | most other PCs.

>

> Too bad the VPC wouldn't feed it real information from what is actually

> plugged into the XP/Vista machine. BUT-- I'm sure that is because Win98

> may not have drivers to run some of them.

>

> |>

> |> |>What about files such

> |> |> as...?...

> |> |>

> |> |> HIMEM.SYS

> |> |> Type: System file

> |> |> Loc: C:\WINDOWS

> |> |> Size: 33,181 bytes

> |> |> Mod: Friday, April 23, 1999 10:22:00 PM

> |> |>

> |> |> Are they the same on a virtual machine? Can one enter a Windows

> |> |> DOS session & would the commands be the same?

> |> |

> |> | Yes, and yes.

> |>

> |> Very impressive what they did.

> |

> | Connectix developed it. MS bought them and haven't done much with it

> | since.

> | VMWare is probably the leader in virtualazation, but is not free. Not

> | for the cool stuff anyway ;-)

>

> It really is pretty amazing as is. Thanks for all of this information,

> Blanton. It's good to see you still will pop into this NG!

 

Virtualization _is_ pretty amazing. (IMO, it's the coolest software since

the speadsheet.) The potential could be huge.

 

Good to see you again too PCR. (you watching the game?.. I bet you hate to see

Boston winning... <eg>)

[Guest PCR]

Re: Turmoil Continues in XP land

 

Bill Blanton wrote:

| I can't respond to your message. Outlook express is too stupid too

| handle a thread this deep, so I'll put it here:

 

That happens when we get to be too gabby. So far, only Chauvin has kind

of complained, though he is too politic to really tell.

 

| "PCR" <pcrrcp@netzero.net> wrote in message

| news:e2833JD0IHA.4004@TK2MSFTNGP03.phx.gbl...

|> Bill Blanton wrote:

|> | "PCR" <pcrrcp@netzero.net> wrote in message

 

....snip

|> |> |> |>>>> I think the partition would be fake-- just a simulation!

|> |> |> |>>>> You'd never be able to do normal maintenance on it, like

|> |> |> |>>>> a scandisk & defrag-- I don't think!

|> |> |> |

|> |> |> | No, the disk structure is emulated just as a real disk. You

|> |> |> | can scandisk, defrag,

|> |> |> | go in and muck around witht the partition tables or boot

|> |> |> | sectors, install a boot

|> |> |> | manager, muti-boot, whatever..

|> |> |

|> |> |

|> |> |> That's an excellent emulation, then. But how can that be? Are

|> |> |> you be able to boot to DOS or to a Starup Diskette to do that?

|> |> |> I thought WinXP couldn't! Or is this done from some sort of CD

|> |> |> boot to a repair console?

|> |> |

|> |> | Yes, you can boot to a boot floppy or CD. Real or virtual. I've

|> |> | got a folder

|> |> | full of virtual boot media. (much faster booting than the real

|> |> | thing)

|> |> |

|> |> | It's a PC as far as the OS is concerned, and boots the same way.

|> |> | The virtual

|> |> | BIOS loads the MBR, the MBR loads the boot sector, which loads

|> |> | Windows.

|> |> |

|> |> | The virtual hadr disk is one big file on the host machine.

|> |> | Copying the file

|> |> | is analogous to cloning your HD.

|> |>

|> |> That's very impressive. But the BIOS is virtual too? So, even this

|> |> BIOS won't work, until you've boot to XP first & began the Win98

|> |> simulation?

|> |

|> | It's not XP, though I think that it the minimum requirement for

|> | VPC. VPC

|> | is software that emulates a PC. It runs as a "process" on the host

|> | OS. Not necessarily XP.

|>

|> I guess the only other choice would be Vista, then, for now. But,

|> whichever it is, it must boot first to set up (or allow VPC to set

|> up?) the process that is VPC. I suppose the host OS continues to

|> run-- so, you now have two machines running at once & can click

|> between the two?

|

| Yea, the virtual machine runs as a process in its own "window", just

| as other

| programs. You can toggle to a "Full screen" if you want the total

| effect.

| Boot the host OS, run the program VPC, then choose which virtual

| machine to

| run. (sorta' like an "open file" on your favorite word processor)

 

Amazing. Sounds like what MS did with its Windows DOS (in a box) but on

a much grander scale.

 

|> | You boot the virtual machine and install your OS, just as you do

|> | on a "real"

|> | machine.

|>

|> Hmm. Amazing. I would have thought the VPC came with Win98

|> pre-installed.

|

| When you set up a new virtual machine, it's basically a PC with a

| blank

| hard drive. You can boot with your floppy, fdisk, run the windows

| setup,

| whatever you want. I believe that when Connectix owned it you could

| install Linux. I'm not sure if MS has blocked this or not. You can

| also run

| more than one virtual install at once, depending on your resources.

| (memory,

| a fairly fast CPU)

 

It's fairly impressive. I wouldn't be too surprised, if MS shut Linux

out & Apple too.

 

| Virtual Windows installs also require a license, and in the case of

| XP and

| Vista, you do have to activate your copy.

 

Is there a lot of activation involved with XP? Is it just the OS or do

installed packages also need it? After you've installed & activated XP

on one machine, can the Installation CDs ever be used again on a

different machine? Would one be able to clone the hard drive & move it

to another machine?

 

|>

|> | Even though your BIOS is burned into a chip, it is still just

|> | software code

|> | that loads when you boot.

|>

|> Of course, you know, not all BIOS code is the same. Therefore, some

|> recognize devices (maybe even the MB?) that others do not & have

|> capabilities (large HDD support, multi-booting, etc.) that others do

|> not. Normally, one wouldn't want to put another machine's BIOS into

|> his!

|

| The "virtual motherboard" contains well supported devices, and does

| not

| change. You can specify what size HD, up to a limit, but other than

| that

| you don't have any control over the harware, It would be nice if the

| interface was open and devs could write out new virtual devices, which

| you could then "plug in". It might open up a whole new market.

 

Too bad they didn't write it to allow a virtual BIOS flash of some sort.

But, in addition to having the BIOS see a new device, there would also

need to be a driver in the virtual OS.

 

|>

|> | Virtualzation software just removes that "physical" hardware layer,

|> | and

|> | replaces it with "virtual" hardware.

|>

|> This virtual BIOS that VPC supplies-- doesn't it need to be specific

|> to the machine that it will run on?

|

| No, it's the same BIOS and devices no matter what PC you put it on.

| It's virtual ;-)

 

I understand now. There are a bunch of standard/generic devices in the

VPC. If the computer has something that won't respond to any of those,

that device just won't work. Too bad.

 

|> I see elsewhere you said...

|>

|> "Unfortunately VPC does not support USB."

|>

|> "There's not as much config in there as most BIOSs. But there is IDE

|> boot order,

|> IDE device config settings. password config, pwer management (IIRC)..

|> some other basic stuff.... clock..."

|>

|> Too bad they didn't write it to actually use the BIOS that is

|> installed in the machine or to make a copy & use the copy (as I

|> think Colorado speculated it might be doing). Then, it would have

|> the full capabilities-- & no one would have to give up his flash

|> drive!

|

| That kinda' gets away from the whole concept. It wouldn't be virtual

| then.

| It'd be closer to a real OS, and have to support the myriad machines

| on the

| market. If your accessing the real hadrware, you have to read/write

| to the

| real hardware. What would be the point? In that case it would be a

| full

| blown OS.

 

But the virtual BIOS does access the real hardware at some point --

doesn't it? -- to know which virtual driver to assign it. That is when,

if it finds something new, they should have coded it to ask for a driver

that it could add to its virtual list. However, I guess the OS that

boots also would need a real driver & interface for the new device.

Also, someone would need to write an app for the OS that uses that

driver. That's too much, I guess.

 

|>

|> | When the OS accesses the hardware it calls upon the

|> | virtual hardware and the virtual hardware returns the information

|> | pertaining to its own configuration, just as your "real" hardware

|> | does.

|> | It's all just a stream of bits and bytes. What's "hardware" to the

|> | OS anyway?

|>

|> Unfortunately, though, it seems VPC has no bits for USB-- Colorado is

|> chagrinned! He loves his flash drive!

|

| Who doesn't love a flash drive?! ;-)

 

I'm very tempted to go shopping for one, myself! I don't expect I'll be

able to boot mine, but it would be great to have the external storage!

:-).

 

| Like I said somewhere else,, MS hasn't done much with it since they

| bought

| Connectix out. Frankly, they haven't done much but change all the

| "Connectix"

| strings to "Microsoft". In VPC2004 you could still find some errant

| "Connectix"

| strings in the help files.

 

Maybe they will do more, but maybe they just wanted to stop it from

becoming an alternative to their product.

 

| VMWare supports USB. On VPC, you can create virtual CDs which will

| load/run/boot faster than any physical USB device.

 

But is the virtual CDs as large as a flash drive?

 

....snip

|> It really is pretty amazing as is. Thanks for all of this

|> information, Blanton. It's good to see you still will pop into this

|> NG!

|

| Virtualization _is_ pretty amazing. (IMO, it's the coolest software

| since

| the speadsheet.) The potential could be huge.

 

They'd have to solve the driver problem for new devices. As is, though,

it does allow Win98, for instance, to function on a machine it otherwise

couldn't, by providing generic drivers for standard devices that may

otherwise be too new for Win98. Odd, they didn't include USB, though!

 

| Good to see you again too PCR. (you watching the game?.. I bet you

| hate to see

| Boston winning... <eg>)

 

As long as it is not baseball, Boston may win all it wants. :-).

 

 

--

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

[Guest Bill Blanton]

Re: Turmoil Continues in XP land

 

 

"PCR" <pcrrcp@netzero.net> wrote in message news:eoW2pya0IHA.6096@TK2MSFTNGP06.phx.gbl...

> Bill Blanton wrote:

> | I can't respond to your message. Outlook express is too stupid too

> | handle a thread this deep, so I'll put it here:

>

> That happens when we get to be too gabby. So far, only Chauvin has kind

> of complained, though he is too politic to really tell.

 

Seems not to happen to you? I have to cut down the "ref" field in the header.

Sometimes it works, sometimes not.

 

>

> | "PCR" <pcrrcp@netzero.net> wrote in message

> | news:e2833JD0IHA.4004@TK2MSFTNGP03.phx.gbl...

> |> Bill Blanton wrote:

> |> | "PCR" <pcrrcp@netzero.net> wrote in message

>

> ...snip

> |> |> |> |>>>> I think the partition would be fake-- just a simulation!

> |> |> |> |>>>> You'd never be able to do normal maintenance on it, like

> |> |> |> |>>>> a scandisk & defrag-- I don't think!

> |> |> |> |

> |> |> |> | No, the disk structure is emulated just as a real disk. You

> |> |> |> | can scandisk, defrag,

> |> |> |> | go in and muck around witht the partition tables or boot

> |> |> |> | sectors, install a boot

> |> |> |> | manager, muti-boot, whatever..

> |> |> |

> |> |> |

> |> |> |> That's an excellent emulation, then. But how can that be? Are

> |> |> |> you be able to boot to DOS or to a Starup Diskette to do that?

> |> |> |> I thought WinXP couldn't! Or is this done from some sort of CD

> |> |> |> boot to a repair console?

> |> |> |

> |> |> | Yes, you can boot to a boot floppy or CD. Real or virtual. I've

> |> |> | got a folder

> |> |> | full of virtual boot media. (much faster booting than the real

> |> |> | thing)

> |> |> |

> |> |> | It's a PC as far as the OS is concerned, and boots the same way.

> |> |> | The virtual

> |> |> | BIOS loads the MBR, the MBR loads the boot sector, which loads

> |> |> | Windows.

> |> |> |

> |> |> | The virtual hadr disk is one big file on the host machine.

> |> |> | Copying the file

> |> |> | is analogous to cloning your HD.

> |> |>

> |> |> That's very impressive. But the BIOS is virtual too? So, even this

> |> |> BIOS won't work, until you've boot to XP first & began the Win98

> |> |> simulation?

> |> |

> |> | It's not XP, though I think that it the minimum requirement for

> |> | VPC. VPC

> |> | is software that emulates a PC. It runs as a "process" on the host

> |> | OS. Not necessarily XP.

> |>

> |> I guess the only other choice would be Vista, then, for now. But,

> |> whichever it is, it must boot first to set up (or allow VPC to set

> |> up?) the process that is VPC. I suppose the host OS continues to

> |> run-- so, you now have two machines running at once & can click

> |> between the two?

> |

> | Yea, the virtual machine runs as a process in its own "window", just

> | as other

> | programs. You can toggle to a "Full screen" if you want the total

> | effect.

> | Boot the host OS, run the program VPC, then choose which virtual

> | machine to

> | run. (sorta' like an "open file" on your favorite word processor)

>

> Amazing. Sounds like what MS did with its Windows DOS (in a box) but on

> a much grander scale.

>

> |> | You boot the virtual machine and install your OS, just as you do

> |> | on a "real"

> |> | machine.

> |>

> |> Hmm. Amazing. I would have thought the VPC came with Win98

> |> pre-installed.

> |

> | When you set up a new virtual machine, it's basically a PC with a

> | blank

> | hard drive. You can boot with your floppy, fdisk, run the windows

> | setup,

> | whatever you want. I believe that when Connectix owned it you could

> | install Linux. I'm not sure if MS has blocked this or not. You can

> | also run

> | more than one virtual install at once, depending on your resources.

> | (memory,

> | a fairly fast CPU)

>

> It's fairly impressive. I wouldn't be too surprised, if MS shut Linux

> out & Apple too.

>

> | Virtual Windows installs also require a license, and in the case of

> | XP and

> | Vista, you do have to activate your copy.

>

> Is there a lot of activation involved with XP? Is it just the OS or do

> installed packages also need it?

 

Office activates, I think.

> After you've installed & activated XP

> on one machine, can the Installation CDs ever be used again on a

> different machine? Would one be able to clone the hard drive & move it

> to another machine?

 

Yea, but there's a time frame or something. I don't really know much about

activation. I think you can call MS if there's a problem. Dunno' really..

 

Moving to another machine is problematic for hardware reasons. In the case

of a virtual hardware machine, not really, since one VM equals another.

 

>

> |>

> |> | Even though your BIOS is burned into a chip, it is still just

> |> | software code

> |> | that loads when you boot.

> |>

> |> Of course, you know, not all BIOS code is the same. Therefore, some

> |> recognize devices (maybe even the MB?) that others do not & have

> |> capabilities (large HDD support, multi-booting, etc.) that others do

> |> not. Normally, one wouldn't want to put another machine's BIOS into

> |> his!

> |

> | The "virtual motherboard" contains well supported devices, and does

> | not

> | change. You can specify what size HD, up to a limit, but other than

> | that

> | you don't have any control over the harware, It would be nice if the

> | interface was open and devs could write out new virtual devices, which

> | you could then "plug in". It might open up a whole new market.

>

> Too bad they didn't write it to allow a virtual BIOS flash of some sort.

> But, in addition to having the BIOS see a new device, there would also

> need to be a driver in the virtual OS.

>

> |>

> |> | Virtualzation software just removes that "physical" hardware layer,

> |> | and

> |> | replaces it with "virtual" hardware.

> |>

> |> This virtual BIOS that VPC supplies-- doesn't it need to be specific

> |> to the machine that it will run on?

> |

> | No, it's the same BIOS and devices no matter what PC you put it on.

> | It's virtual ;-)

>

> I understand now. There are a bunch of standard/generic devices in the

> VPC. If the computer has something that won't respond to any of those,

> that device just won't work. Too bad.

 

The "real" computer hardware doesn't matter at all. The VM communicates only

with the host OS.

 

>

> |> I see elsewhere you said...

> |>

> |> "Unfortunately VPC does not support USB."

> |>

> |> "There's not as much config in there as most BIOSs. But there is IDE

> |> boot order,

> |> IDE device config settings. password config, pwer management (IIRC)..

> |> some other basic stuff.... clock..."

> |>

> |> Too bad they didn't write it to actually use the BIOS that is

> |> installed in the machine or to make a copy & use the copy (as I

> |> think Colorado speculated it might be doing). Then, it would have

> |> the full capabilities-- & no one would have to give up his flash

> |> drive!

> |

> | That kinda' gets away from the whole concept. It wouldn't be virtual

> | then.

> | It'd be closer to a real OS, and have to support the myriad machines

> | on the

> | market. If your accessing the real hadrware, you have to read/write

> | to the

> | real hardware. What would be the point? In that case it would be a

> | full

> | blown OS.

>

> 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.

 

> to know which virtual driver to assign it. That is when,

> if it finds something new, they should have coded it to ask for a driver

> that it could add to its virtual list. However, I guess the OS that

> boots also would need a real driver & interface for the new device.

> Also, someone would need to write an app for the OS that uses that

> driver. That's too much, I guess.

 

Yea, there are drivers, but only for the devices supported by the VM.

 

 

>

> |>

> |> | When the OS accesses the hardware it calls upon the

> |> | virtual hardware and the virtual hardware returns the information

> |> | pertaining to its own configuration, just as your "real" hardware

> |> | does.

> |> | It's all just a stream of bits and bytes. What's "hardware" to the

> |> | OS anyway?

> |>

> |> Unfortunately, though, it seems VPC has no bits for USB-- Colorado is

> |> chagrinned! He loves his flash drive!

> |

> | Who doesn't love a flash drive?! ;-)

>

> I'm very tempted to go shopping for one, myself! I don't expect I'll be

> able to boot mine, but it would be great to have the external storage!

> :-).

>

> | Like I said somewhere else,, MS hasn't done much with it since they

> | bought

> | Connectix out. Frankly, they haven't done much but change all the

> | "Connectix"

> | strings to "Microsoft". In VPC2004 you could still find some errant

> | "Connectix"

> | strings in the help files.

>

> Maybe they will do more, but maybe they just wanted to stop it from

> becoming an alternative to their product.

 

Well, they do have to have their hand in everything..

 

>

> | VMWare supports USB. On VPC, you can create virtual CDs which will

> | load/run/boot faster than any physical USB device.

>

> But is the virtual CDs as large as a flash drive?

 

Depends on the flash drive. As large as a CD.

 

>

> ...snip

> |> It really is pretty amazing as is. Thanks for all of this

> |> information, Blanton. It's good to see you still will pop into this

> |> NG!

>|

> | Virtualization _is_ pretty amazing. (IMO, it's the coolest software

> | since

> | the speadsheet.) The potential could be huge.

>

> They'd have to solve the driver problem for new devices. As is, though,

> it does allow Win98, for instance, to function on a machine it otherwise

> couldn't, by providing generic drivers for standard devices that may

> otherwise be too new for Win98. Odd, they didn't include USB, though!

>

> | Good to see you again too PCR. (you watching the game?.. I bet you

> | hate to see

> | Boston winning... <eg>)

>

> As long as it is not baseball, Boston may win all it wants. :-).

 

Baseball too.. ;-)

Nevermind the BoSox,, the Cubs have the best record in the league!

[Guest PCR]

Re: Turmoil Continues in XP land

 

Bill Blanton wrote:

| "PCR" <pcrrcp@netzero.net> wrote in message

| news:eoW2pya0IHA.6096@TK2MSFTNGP06.phx.gbl...

|> Bill Blanton wrote:

|> | I can't respond to your message. Outlook express is too stupid too

|> | handle a thread this deep, so I'll put it here:

|>

|> That happens when we get to be too gabby. So far, only Chauvin has

|> kind of complained, though he is too politic to really tell.

|

| Seems not to happen to you? I have to cut down the "ref" field in the

| header.

| Sometimes it works, sometimes not.

 

It happens to me! I move the post up in the thread when it does, which

is the same as cutting the Ref field-- I guess!

 

|>

|> | "PCR" <pcrrcp@netzero.net> wrote in message

|> | news:e2833JD0IHA.4004@TK2MSFTNGP03.phx.gbl...

|> |> Bill Blanton wrote:

|> |> | "PCR" <pcrrcp@netzero.net> wrote in message

 

....snip

|> Is there a lot of activation involved with XP? Is it just the OS or

|> do installed packages also need it?

|

| Office activates, I think.

 

OK. I guess they do it for stuff bought separately.

 

|> After you've installed & activated XP

|> on one machine, can the Installation CDs ever be used again on a

|> different machine? Would one be able to clone the hard drive & move

|> it to another machine?

|

| Yea, but there's a time frame or something. I don't really know much

| about

| activation. I think you can call MS if there's a problem. Dunno'

| really..

 

OK. I personally would only have one machine, anyhow.

 

| Moving to another machine is problematic for hardware reasons. In the

| case

| of a virtual hardware machine, not really, since one VM equals

| another.

 

OK. Other than VM, just as with Win98, it's best to fresh install XP to

a new machine. For me, it only would matter if one machine died & I had

to get another & if the other didn't have it pre-installed.

 

|>

|> |>

|> |> | Even though your BIOS is burned into a chip, it is still just

|> |> | software code

|> |> | that loads when you boot.

|> |>

|> |> Of course, you know, not all BIOS code is the same. Therefore,

|> |> some recognize devices (maybe even the MB?) that others do not &

|> |> have capabilities (large HDD support, multi-booting, etc.) that

|> |> others do not. Normally, one wouldn't want to put another

|> |> machine's BIOS into his!

|> |

|> | The "virtual motherboard" contains well supported devices, and does

|> | not

|> | change. You can specify what size HD, up to a limit, but other than

|> | that

|> | you don't have any control over the harware, It would be nice if

|> | the interface was open and devs could write out new virtual

|> | devices, which you could then "plug in". It might open up a whole

|> | new market.

|>

|> Too bad they didn't write it to allow a virtual BIOS flash of some

|> sort. But, in addition to having the BIOS see a new device, there

|> would also need to be a driver in the virtual OS.

|>

|> |>

|> |> | Virtualzation software just removes that "physical" hardware

|> |> | layer, and

|> |> | replaces it with "virtual" hardware.

|> |>

|> |> This virtual BIOS that VPC supplies-- doesn't it need to be

|> |> specific to the machine that it will run on?

|> |

|> | No, it's the same BIOS and devices no matter what PC you put it on.

|> | It's virtual ;-)

|>

|> I understand now. There are a bunch of standard/generic devices in

|> the VPC. If the computer has something that won't respond to any of

|> those, that device just won't work. Too bad.

|

| 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.

 

|>

|> |> I see elsewhere you said...

|> |>

|> |> "Unfortunately VPC does not support USB."

|> |>

|> |> "There's not as much config in there as most BIOSs. But there is

|> |> IDE boot order,

|> |> IDE device config settings. password config, pwer management

|> |> (IIRC).. some other basic stuff.... clock..."

|> |>

|> |> Too bad they didn't write it to actually use the BIOS that is

|> |> installed in the machine or to make a copy & use the copy (as I

|> |> think Colorado speculated it might be doing). Then, it would have

|> |> the full capabilities-- & no one would have to give up his flash

|> |> drive!

|> |

|> | That kinda' gets away from the whole concept. It wouldn't be

|> | virtual then.

|> | It'd be closer to a real OS, and have to support the myriad

|> | machines on the

|> | market. If your accessing the real hadrware, you have to read/write

|> | to the

|> | real hardware. What would be the point? In that case it would be a

|> | full

|> | blown OS.

|>

|> 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. But, the principle is the

same-- if it finds something new, too bad it won't ask for a VM driver

to handle it.

 

|> to know which virtual driver to assign it. That is when,

|> if it finds something new, they should have coded it to ask for a

|> driver that it could add to its virtual list. However, I guess the

|> OS that boots also would need a real driver & interface for the new

|> device. Also, someone would need to write an app for the OS that

|> uses that driver. That's too much, I guess.

|

| Yea, there are drivers, but only for the devices supported by the VM.

 

OK. No way to add new ones as of yet. Too bad.

 

....snip

|> | Like I said somewhere else,, MS hasn't done much with it since they

|> | bought

|> | Connectix out. Frankly, they haven't done much but change all the

|> | "Connectix"

|> | strings to "Microsoft". In VPC2004 you could still find some errant

|> | "Connectix"

|> | strings in the help files.

|>

|> Maybe they will do more, but maybe they just wanted to stop it from

|> becoming an alternative to their product.

|

| Well, they do have to have their hand in everything..

 

Uhuh. I guess they gobbled it up for a reason. And surely they must know

it has a flaw.

 

|>

|> | VMWare supports USB. On VPC, you can create virtual CDs which will

|> | load/run/boot faster than any physical USB device.

|>

|> But is the virtual CDs as large as a flash drive?

|

| Depends on the flash drive. As large as a CD.

 

OK.

 

|>

|> ...snip

|> |> It really is pretty amazing as is. Thanks for all of this

|> |> information, Blanton. It's good to see you still will pop into

|> |> this NG!

|>|

|> | Virtualization _is_ pretty amazing. (IMO, it's the coolest software

|> | since

|> | the speadsheet.) The potential could be huge.

|>

|> They'd have to solve the driver problem for new devices. As is,

|> though, it does allow Win98, for instance, to function on a machine

|> it otherwise couldn't, by providing generic drivers for standard

|> devices that may otherwise be too new for Win98. Odd, they didn't

|> include USB, though!

|>

|> | Good to see you again too PCR. (you watching the game?.. I bet you

|> | hate to see

|> | Boston winning... <eg>)

|>

|> As long as it is not baseball, Boston may win all it wants. :-).

|

| Baseball too.. ;-)

| Nevermind the BoSox,, the Cubs have the best record in the league!

 

The Yankess have begun to win every game now-- just as they should! And

I was almost about to quit watching this season! :-).

 

 

--

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

[Guest Bill Blanton]

Re: Turmoil Continues in XP land

 

 

"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.

 

> |> 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"

[Guest PCR]

Re: Turmoil Continues in XP land

 

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

[Guest Bill Blanton]

Re: Turmoil Continues in XP land

 

 

"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.

[Guest PCR]

Re: Turmoil Continues in XP land

 

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

[Guest Bill Blanton]

Re: Turmoil Continues in XP land

 

"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 :-)

[Guest PCR]

Re: Turmoil Continues in XP land

 

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

[Guest Bill Blanton]

Re: Turmoil Continues in XP land

 

 

"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.

[Guest PCR]

Re: Turmoil Continues in XP land

 

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