Actually, I'm thinking about this more and think my post is wrong.
What I said about how I/O works is still right I think, but even if the OS caches the data, read and write calls still go to the OS. It's not like it's cached in the address space of the requesting process. So the syscall overhead will still be present for reads and writes that hit in-cache.
So basically ignore that post... the benefit of caching SHOULDN'T be any more prominent in a virtualized environment.
You're absolutely right, but those movements being significant is a relatively recent thing. I was just talking about that backwards compatibility was a big factor in getting Windows to where it is, not that it was continuing to help it. I'm not sure if it was in this thread or not, but I did say that it has become a bit of a noose around Windows's neck now (I would say XP SP2 was the watershed, but that's just my interpretation based on no data).
P.S. I find it amusing that wine on 64 bit linux can run 16 bit windows apps yet 64 bit windows can't.
Actually, I'd be interested in knowing how this works (assuming it's true). Does Wine do some sort of binary translation? To my knowledge 16-bit instructions aren't available in 64-bit mode, so it can't just be running it natively. Does it do that with all programs, or just 16-bit ones? Anyone know?
I suppose you mean that it's easier for Apple to make big changes such as dumping support for an old OS as it affects less people.
That's a decent point, but I really meant the causality the other way around, and that pointing to Apple and saying "they do it this way instead of how MS is doing it" isn't a terribly good indication that Apple's way is the one that will lead to greater market share.
Depends, is it still the same old 16-bit exe in the versions of Vista people are reporting it to be present? If so, probably "didn't bother to get it working". Many DOS utilities of that time were written in assembly, so getting it working in 64-bit would have basically consisted of rewriting it.
I'm confused, because you seem to know the answer to your question.
Why does MS need a separate XP mode?..does MS just not want such an ability integrated into the OS
MS has finally figured out that trying to keep 20 years of backwards compatibility is starting to do them harm, in terms of not being able to make architectural changes they need to make, in terms of having to maintain bug-for-bug compatibility with earlier versions, and in terms of having to maintain a large compatibility library.
Moving all this support out of the main part of the OS means that they can make these changes. (Whether they actually will... we'll see. Probably not for Win7, but if the virtualization thing works out pretty well, maybe a version or two down the line.)
The reason I am confused is because this would have been great for the Vista transition, and seems to be old technology.
I agree; it would have been great, it HAS been done a few times, and they should have done it for Vista. But that just means they're learning a little from their mistakes.;-)
Why did MS not do the same, and why are the including a hack solution at the last minute.
It *is* basically doing the same... I mean, the technology is rather different, and there are some usability differences (and, not surprisingly, problems with the Win7 approach), but in the end it is basically the same thing.
And with a little focus on Security and performance it should be really close to as it was with the VT extension.
Security I can buy (though you do get some undesirable stuff with "faked" VT like what VirtualPC and VMware do, like a really really easy way to tell if you're running inside a VM), but much less so in performance. There are some fundamental things that you have to do to keep any measure of security that basically amount to at least doubling the time it takes to do a system call; that difference alone will add a noticeable lag, and is something you don't have to do with VT.
It is really just Microsoft not wanting Virtualization.
Which explains why MS bought Connectix in the early 2000s and has been selling VirtualPC since then, and then released a "new" virtualization product with Server 2008 called Hyper-V.
They just keep demonstrating no interest in the area, I agree.
If they didn't have them, they'd have to code workarounds to handle otherwise non-virtualizable instructions. VMware already does this, as does VirtualBox.
Though to be fair, MS already has a product (which I think they bought) that does this -- VirtualPC. So it's not like they'd have to start writing from scratch.
Actually, yes they kind of did. Before VT extensions the guest OS needed to be aware of the fact that it was not running on bare metal.
No it didn't. In fact, that was one of the primary benefits of Vmware over Xen for a long time -- that the guest did NOT need to know that.
Various hacks by VMWare and Xen (NT kernel hacks, funny drivers, etc)
Vmware didn't require NT kernel hacks or funny drivers at all. They provided some for the video and mouse, but they were only to (in the case of video) improve performance and (in the case of the mouse) increase functionality a tiny bit, and weren't strictly required. In fact, the only way to install them was once the guest was already up and running.
Virtual PC -- a Microsoft product (at least after they bought it) -- also supported running unmodified guests.
And they would be wrong. Disk caching in memory has a significant impact on performance.
This is even more true in a virtualized environment. (My data is a little old (based on pre-VT Vmware) and I'm doing a lot of inferring of how things should work, but I don't have much reason to believe that what I describe changes much with a VT-based hypervisor.)
If your OS is on the bare metal, when a program makes an I/O request, there's a syscall trap that goes to the OS which issues an I/O instruction to the hardware; when it returns, the OS sees the interrupt, schedules a task to copy the data to userspace, and then upcalls to the userspace.
If your OS is virtualized, when a program makes an I/O request, there's a syscall trap which goes to the guest OS which issues an I/O instruction; but then that I/O instruction is trapped by the VMM, and the instruction is emulated. Similarly, when the interrupt comes back, I think it should be the hypervisor that receives it (though maybe not), which then simulates an interrupt in the guest OS, which then upcalls to the originating process.
So basically, the VMM adds an extra layer to each I/O operation. If you're doing a lot of I/O, this can become significant. (It's worse under old (non-VT) Vmware, because the syscall the user application issues is then caught by Vmware which simulates a syscall in the guest OS which issues an I/O instruction which goes back to Vmware, so there are TWO extra layers compared to the bare metal.)
Apple did this, not once but twice. Why is Redmond so afraid of trading out the basic underpinnings?
And what's Apple's market share? What's Microsoft's?
You say it yourself: "they used that very stick to beat OS/2 into the ground."
I would say that the single biggest reason that Windows is as prevalent as it is today is that to a very large extent, MS has maintained backwards compatibility at almost any cost. I can only think of a couple exceptions: transitions to the NT line stopped some old DOS programs that access sound cards and stuff directly from working, XP SP2 made a few similar strides (I don't know details), Vista makes a couple more, and x64-based Windows drops support for 16-bit programs (but this is largely the fault of AMD/Intel rather than MS, who would have had to work around processor limitations since 16-bit instructions aren't available in 64-bit mode).
But even with Vista 32-bit, my experience is that each of the three or four DOS programs from the mid-80s still ran. There are few systems that can claim this lineage. So it's no wonder to me that MS doesn't want to give it up.
And it's only recently that the pile of compatibility hacks and inability to make fundamental design decisions has caught up to MS and been harming them from the market's point of view.
"Now grad students are doing it all by themselves for thesis projects."
As a grad student, I found the wording of the summary amusing. I can confirm that yes, we can climb stairs if need be. The elevators in my CS building go out about once every two weeks for instance. (Wasn't that long ago that the motor in one of the shafts caught fire and shut down that shaft for over a week. During which the other shaft broke down too for a short time.)
Of course, the real advance will be when robots follow in our paths and learn to take the elevator when one is available.
Depends on the schoool... my high school for instance offered a typing course, but there weren't a lot of incentives to take it, and it certainly wasn't required. (This was in the past decade.)
I learned touch-typing on Dvorak on my own; I still can't touch-type on qwerty.
Hmmm, you might be right. My understanding was that autoplay was the thing that popped up the dialog asking you what you want to do.
I *really like* that feature, and it's easily worth what I perceive as a small risk for that convenience, but I would also say that if there is media (audio CDs and DVDs?) that does actually start playing automatically, I'd rather it do the pop-up window thing.
the battery (a single rechargeable AA) regularly lasts two weeks through lengthy gaming sessions
No offense, but I'd say that's pretty crappy. I've got this beauty; the mouse takes 2 AA. I use non-rechargables, but I think I've changed the mouse batteries probably about 4 or 5 times in 16 or so months. Even if there were 8 changes, that's still getting twice the life per battery that you are.
That's my primary mouse, so gets used for 8-10 hours/day, 5 days/week.
(OTOH, I have another Logitech mouse that has a built in battery that only ever lasted 2 or 3 weeks probably, and is down to a few days.)
Win-D and Win-M have problems for me (at least under XP). Both don't always restore the correct z-order when you go back from going to the desktop. Win-D has the additional problem that if you open another window after hitting Win-D, you can't get back to the state you were in before. Both of these, IMO, substantially deplete the usability of that feature.
(I also don't know how it compares with Gnome or anything else.)
Heard? I've lived it. I tried for 11 days, hours and hours on the phone to quit AOL. I finally canceled the Visa that they insisted on dinging even after they said I had quit.
Personally, I wouldn't have spent that long. After a couple hours, I would have faxed them a cancel request and left it at that. If they charged my card again, I'd have taken them to small claims court for the amount charged, court costs, and probably tried for some punitive damages.
Then again, I have the time and flexibility to do that right now, a passing interest in law and a small amount of knowledge of torts, and the will to deal with corrupt companies like that.
So I'm not quite sure what Vista does with Audio CDs and DVDs; in my Win2008 box, nothing happens. (I do have autoplay on; it works for USB drives for instance.)
Second, even automatically playing the content for those things won't cause any WAVs to play.
Third, if the poster who said that was exactly correct, autoplaydoesn't do anything automatically, it just asks you what to do.
It's possible that Vista will automatically play CDs and DVDs by default, and if that's the case, I don't think MS went far enough in stopping autorun. But it's still way, way better than continuing to allow autorun.
As an interesting side point on that issue, M$ knew all about Sony's root kit prior to it being released in fact they were involved in evaluating it
[citation needed]
Wikipedia has no mention of such a thing in a reasonably complete article on the rootkit controversy....it was a M$ advertising blogger who announced it to the world not long after it was released
1) Mark Russinovich (the guy who broke the news) discovered it on his own (he described how in his blog) 2) Russinovich wasn't an MS employee at the time he broke the news, and didn't start working there for a few months afterward 3) Calling him an "M$ advertising blogger" is, to a fair extent being a dishonest troll
AOL had things like online encyclopedias and other "premium" content.
They had some nice repositories of code samples and game add-ons and stuff like that. I remember downloading a bunch of addon planes and scenery and stuff like that for the MS Flight Sim back in the mid-90s.
There was just far less on the web itself at that point, and finding the stuff that was there was harder as it was before the days of Google and pretty good search results.
Who verifies the signature? Who verifies the verifiers? What stops a signature from being faked?
if you're going to be paranoid about these things, you might as well be all-the-way paranoid.
Yes, because after all, if we can't make it IMPOSSIBLE to crack, we might as well not make it rather harder?
BTW, most Linux package managers now check signatures on the packages they install. You know why? Because it's a damn good idea. It eliminates most attack vectors and it eliminates almost all of the easily-attackable attack vectors.
(MS is using signatures a bit differently than the Linux folks are, but many of the same principles and benefits apply.)
Slashdot Mirror
Actually, I'm thinking about this more and think my post is wrong.
What I said about how I/O works is still right I think, but even if the OS caches the data, read and write calls still go to the OS. It's not like it's cached in the address space of the requesting process. So the syscall overhead will still be present for reads and writes that hit in-cache.
So basically ignore that post... the benefit of caching SHOULDN'T be any more prominent in a virtualized environment.
You're absolutely right, but those movements being significant is a relatively recent thing. I was just talking about that backwards compatibility was a big factor in getting Windows to where it is, not that it was continuing to help it. I'm not sure if it was in this thread or not, but I did say that it has become a bit of a noose around Windows's neck now (I would say XP SP2 was the watershed, but that's just my interpretation based on no data).
Just out of curiosity, what sort of stuff?
P.S. I find it amusing that wine on 64 bit linux can run 16 bit windows apps yet 64 bit windows can't.
Actually, I'd be interested in knowing how this works (assuming it's true). Does Wine do some sort of binary translation? To my knowledge 16-bit instructions aren't available in 64-bit mode, so it can't just be running it natively. Does it do that with all programs, or just 16-bit ones? Anyone know?
I suppose you mean that it's easier for Apple to make big changes such as dumping support for an old OS as it affects less people.
That's a decent point, but I really meant the causality the other way around, and that pointing to Apple and saying "they do it this way instead of how MS is doing it" isn't a terribly good indication that Apple's way is the one that will lead to greater market share.
Depends, is it still the same old 16-bit exe in the versions of Vista people are reporting it to be present? If so, probably "didn't bother to get it working". Many DOS utilities of that time were written in assembly, so getting it working in 64-bit would have basically consisted of rewriting it.
I'm confused, because you seem to know the answer to your question.
Why does MS need a separate XP mode? ..does MS just not want such an ability integrated into the OS
MS has finally figured out that trying to keep 20 years of backwards compatibility is starting to do them harm, in terms of not being able to make architectural changes they need to make, in terms of having to maintain bug-for-bug compatibility with earlier versions, and in terms of having to maintain a large compatibility library.
Moving all this support out of the main part of the OS means that they can make these changes. (Whether they actually will... we'll see. Probably not for Win7, but if the virtualization thing works out pretty well, maybe a version or two down the line.)
The reason I am confused is because this would have been great for the Vista transition, and seems to be old technology.
I agree; it would have been great, it HAS been done a few times, and they should have done it for Vista. But that just means they're learning a little from their mistakes. ;-)
Why did MS not do the same, and why are the including a hack solution at the last minute.
It *is* basically doing the same... I mean, the technology is rather different, and there are some usability differences (and, not surprisingly, problems with the Win7 approach), but in the end it is basically the same thing.
I'm not sure why you consider it a hack solution.
And with a little focus on Security and performance it should be really close to as it was with the VT extension.
Security I can buy (though you do get some undesirable stuff with "faked" VT like what VirtualPC and VMware do, like a really really easy way to tell if you're running inside a VM), but much less so in performance. There are some fundamental things that you have to do to keep any measure of security that basically amount to at least doubling the time it takes to do a system call; that difference alone will add a noticeable lag, and is something you don't have to do with VT.
It is really just Microsoft not wanting Virtualization.
Which explains why MS bought Connectix in the early 2000s and has been selling VirtualPC since then, and then released a "new" virtualization product with Server 2008 called Hyper-V.
They just keep demonstrating no interest in the area, I agree.
If they didn't have them, they'd have to code workarounds to handle otherwise non-virtualizable instructions. VMware already does this, as does VirtualBox.
Though to be fair, MS already has a product (which I think they bought) that does this -- VirtualPC. So it's not like they'd have to start writing from scratch.
Actually, yes they kind of did. Before VT extensions the guest OS needed to be aware of the fact that it was not running on bare metal.
No it didn't. In fact, that was one of the primary benefits of Vmware over Xen for a long time -- that the guest did NOT need to know that.
Various hacks by VMWare and Xen (NT kernel hacks, funny drivers, etc)
Vmware didn't require NT kernel hacks or funny drivers at all. They provided some for the video and mouse, but they were only to (in the case of video) improve performance and (in the case of the mouse) increase functionality a tiny bit, and weren't strictly required. In fact, the only way to install them was once the guest was already up and running.
Virtual PC -- a Microsoft product (at least after they bought it) -- also supported running unmodified guests.
(I can't speak to anything Xen did.)
And they would be wrong. Disk caching in memory has a significant impact on performance.
This is even more true in a virtualized environment. (My data is a little old (based on pre-VT Vmware) and I'm doing a lot of inferring of how things should work, but I don't have much reason to believe that what I describe changes much with a VT-based hypervisor.)
If your OS is on the bare metal, when a program makes an I/O request, there's a syscall trap that goes to the OS which issues an I/O instruction to the hardware; when it returns, the OS sees the interrupt, schedules a task to copy the data to userspace, and then upcalls to the userspace.
If your OS is virtualized, when a program makes an I/O request, there's a syscall trap which goes to the guest OS which issues an I/O instruction; but then that I/O instruction is trapped by the VMM, and the instruction is emulated. Similarly, when the interrupt comes back, I think it should be the hypervisor that receives it (though maybe not), which then simulates an interrupt in the guest OS, which then upcalls to the originating process.
So basically, the VMM adds an extra layer to each I/O operation. If you're doing a lot of I/O, this can become significant. (It's worse under old (non-VT) Vmware, because the syscall the user application issues is then caught by Vmware which simulates a syscall in the guest OS which issues an I/O instruction which goes back to Vmware, so there are TWO extra layers compared to the bare metal.)
Apple did this, not once but twice. Why is Redmond so afraid of trading out the basic underpinnings?
And what's Apple's market share? What's Microsoft's?
You say it yourself: "they used that very stick to beat OS/2 into the ground."
I would say that the single biggest reason that Windows is as prevalent as it is today is that to a very large extent, MS has maintained backwards compatibility at almost any cost. I can only think of a couple exceptions: transitions to the NT line stopped some old DOS programs that access sound cards and stuff directly from working, XP SP2 made a few similar strides (I don't know details), Vista makes a couple more, and x64-based Windows drops support for 16-bit programs (but this is largely the fault of AMD/Intel rather than MS, who would have had to work around processor limitations since 16-bit instructions aren't available in 64-bit mode).
But even with Vista 32-bit, my experience is that each of the three or four DOS programs from the mid-80s still ran. There are few systems that can claim this lineage. So it's no wonder to me that MS doesn't want to give it up.
And it's only recently that the pile of compatibility hacks and inability to make fundamental design decisions has caught up to MS and been harming them from the market's point of view.
"Now grad students are doing it all by themselves for thesis projects."
As a grad student, I found the wording of the summary amusing. I can confirm that yes, we can climb stairs if need be. The elevators in my CS building go out about once every two weeks for instance. (Wasn't that long ago that the motor in one of the shafts caught fire and shut down that shaft for over a week. During which the other shaft broke down too for a short time.)
Of course, the real advance will be when robots follow in our paths and learn to take the elevator when one is available.
Depends on the schoool... my high school for instance offered a typing course, but there weren't a lot of incentives to take it, and it certainly wasn't required. (This was in the past decade.)
I learned touch-typing on Dvorak on my own; I still can't touch-type on qwerty.
Hmmm, you might be right. My understanding was that autoplay was the thing that popped up the dialog asking you what you want to do.
I *really like* that feature, and it's easily worth what I perceive as a small risk for that convenience, but I would also say that if there is media (audio CDs and DVDs?) that does actually start playing automatically, I'd rather it do the pop-up window thing.
the battery (a single rechargeable AA) regularly lasts two weeks through lengthy gaming sessions
No offense, but I'd say that's pretty crappy. I've got this beauty; the mouse takes 2 AA. I use non-rechargables, but I think I've changed the mouse batteries probably about 4 or 5 times in 16 or so months. Even if there were 8 changes, that's still getting twice the life per battery that you are.
That's my primary mouse, so gets used for 8-10 hours/day, 5 days/week.
(OTOH, I have another Logitech mouse that has a built in battery that only ever lasted 2 or 3 weeks probably, and is down to a few days.)
Meh, tell your friend to try out one of logitech's revolution mice
I want to own an Mx Revolution so badly... I could see myself becoming so dependent on that thumb scroll.
Win-D and Win-M have problems for me (at least under XP). Both don't always restore the correct z-order when you go back from going to the desktop. Win-D has the additional problem that if you open another window after hitting Win-D, you can't get back to the state you were in before. Both of these, IMO, substantially deplete the usability of that feature.
(I also don't know how it compares with Gnome or anything else.)
Heard? I've lived it. I tried for 11 days, hours and hours on the phone to quit AOL. I finally canceled the Visa that they insisted on dinging even after they said I had quit.
Personally, I wouldn't have spent that long. After a couple hours, I would have faxed them a cancel request and left it at that. If they charged my card again, I'd have taken them to small claims court for the amount charged, court costs, and probably tried for some punitive damages.
Then again, I have the time and flexibility to do that right now, a passing interest in law and a small amount of knowledge of torts, and the will to deal with corrupt companies like that.
So I'm not quite sure what Vista does with Audio CDs and DVDs; in my Win2008 box, nothing happens. (I do have autoplay on; it works for USB drives for instance.)
Second, even automatically playing the content for those things won't cause any WAVs to play.
Third, if the poster who said that was exactly correct, autoplay doesn't do anything automatically, it just asks you what to do.
It's possible that Vista will automatically play CDs and DVDs by default, and if that's the case, I don't think MS went far enough in stopping autorun. But it's still way, way better than continuing to allow autorun.
Just out of curiosity, does it work better than the somewhat broken Win-D and Win-M shortcuts (that have also been there for years)?
Should the user be trusted to run "britneynude" if they navigate to it in the actual drive in explorer and open it?
If yes, what's the essential difference? In both cases, the user does have to take affirmative action to cause it to execute.
As an interesting side point on that issue, M$ knew all about Sony's root kit prior to it being released in fact they were involved in evaluating it
[citation needed]
Wikipedia has no mention of such a thing in a reasonably complete article on the rootkit controversy. ...it was a M$ advertising blogger who announced it to the world not long after it was released
1) Mark Russinovich (the guy who broke the news) discovered it on his own (he described how in his blog)
2) Russinovich wasn't an MS employee at the time he broke the news, and didn't start working there for a few months afterward
3) Calling him an "M$ advertising blogger" is, to a fair extent being a dishonest troll
AOL had things like online encyclopedias and other "premium" content.
They had some nice repositories of code samples and game add-ons and stuff like that. I remember downloading a bunch of addon planes and scenery and stuff like that for the MS Flight Sim back in the mid-90s.
There was just far less on the web itself at that point, and finding the stuff that was there was harder as it was before the days of Google and pretty good search results.
Who verifies the signature? Who verifies the verifiers? What stops a signature from being faked?
if you're going to be paranoid about these things, you might as well be all-the-way paranoid.
Yes, because after all, if we can't make it IMPOSSIBLE to crack, we might as well not make it rather harder?
BTW, most Linux package managers now check signatures on the packages they install. You know why? Because it's a damn good idea. It eliminates most attack vectors and it eliminates almost all of the easily-attackable attack vectors.
(MS is using signatures a bit differently than the Linux folks are, but many of the same principles and benefits apply.)