I destroyed my PowerPC Mac with a hammer as soon as Steve Jobs, our Leader, declared them to be obsolete and went out and bought a much faster Intel Mac.
Besides x86 chips have always been faster than PPC ones. Except before the Leader announced the change. Then of course they had always been slower. This may seem a bit contradictory to you, but that's because you don't understand the Reality Distortion principle.
"Someone asked me the difference between the Sex Pistols and the Beatles. It's chalk and cheese. I was only a nipper when then Beatles were going, but I was fucking glad when they broke up" Steve Jones
I bet if you tried any USB device that needed to stream data you'd see the same issues you see with your headset. Or worse actually, the driver for the headphones is a Microsoft one, right? When it stutters I'd say it's because it failed to keep up with the stream. The fact it doesn't bluescreen or hang at that point means it manages to recover at that point. If you buy a cheapo streaming USB device, I'd expect it to crash horribly if its timing assumptions were violated.
Map registers are an abstraction the DMA API uses to track the system resources needed to make one page of memory accessible by your device for a DMA transfer. They may represent a bounce buffer - a single page of memory which the device can access that the DMA will use to double-buffer part of your transfer. They could (in the world of the future) represent entries in a page map that maps pages in the physical address space into the device's logical address space (another DDK term). Or in the case of a 32-bit adapter on a 32-bit system where there's no need for translation, it might represent absolutely nothing at all. However since you probably want to write a driver that makes your device work on any Windows system, you should ignore this last case and focus on the ones where translation is needed.
You'll want to allocate enough map registers to handle your maximum transfer size. This limit might be exposed by your hardware, or as a tunable parameter in the registry, or just by common sense (you probably don't need to transfer 1GB in a single shot now do you?). However since map registers can be a limited resource, you may not always get the number you asked for (it's an in/out parameter to IoGetDmaAdapter). In that case you'll need to cut down your maximum transfer size - either rejecting larger transfers or breaking them up into smaller pieces and staging them.
A map register is a abstraction for a resource that maps one page of memory into the memory that is visible to the device. When you map a transfer the HAL could double buffer, or program an IOMMU, or it could do nothing (this was almosts always the case on x86). And the Intel version of IOMMU is apparently better optimised for virtualising DMA. Though it seems like the AMD one would work too.
Mind you, there's an issue with drivers not following the rules because they could get away with it on x86. Still the NT DMA model has always supported all of these options (no buffering, an IOMMU or a bounce buffer) though - it's very foresighted in that respect.
Actually bus master DMA does make PCI harder. It's still possible on Windows though - the model is that Windows creates scatter/gather lists for you. The API also has plugs for the HAL potentially adding an extra layer of buffering in software once you start a transfer and tear it down at the end of the transfer. On x86 most of these plugs have traditionally been unused. On Risc they were used but with PAE enabled they are used to allow devices that can't bus master above 4GB to be used on 64 bit systems. I think some NUMA servers might have a non trivial implementation of DMA too. Basically the NT kernel has always had an abstraction for things like DMA to keep code portable.
I still think you're too blase about virtualising USB though. Of course you can add a driver to do it, my point is that by doing so you add a lot of latency. I'm suspect a lot of USB device drivers won't be able to handle that.
The flu, Stock market is down, GM tossing Pontiac, then this? Man, Obama is sure playing with "NYC's head" today. Paranoid enough?
Maybe the plan is to do all this stuff, or at least encourage CNN to tell us it is happening for the next four years. By that point we'll be nervous wrecks. Then in the run up to the election talk only about Bo the whitehouse dog and release loads of spurious stories about how New York now has drunking water again and zombie numbers are decreasing.
Too bad that torrent clients and the bit torrent protocol in general require you to seed. Tit for tat protocol remember. If you want the data, you have to share the data. Well, at least if you want it in this century instead of 4GB or more @ 1kb/s (WoW and AoC, I am looking at you). Did you even have any idea at all how Bittorent works?
If I stop seeding once I have the file it doesn't affect the download time at all, it's not like people bear a grudge against my IP address. Not that they could actually, it's dynamic.
But seriously...some protection is better than no protection at all, and your fallacious argument about suing grannies is just silly. They've sued DEAD PEOPLE.
Yeah, and it was a PR disaster and didn't achieve anything. If I were them I'd concentrate on finding hard core pirates and targetting them.
I remember reading 68K emulation on the PPC worked like this. Instructions on a 68K are 16 bits wide. The emulator would fetch a 68K instruction word, and use it as an index into a table. Each entry in the table had enough space for 16 bytes, 4 32 bit PPC instructions. Most 68K instructions could be done in situ, a small minority needed more space. So there was a 1MB table of instructions that made up the emulator.
Of course things like this make you wonder why the PPC didn't have some sort of hardware support for this scheme. It seems to me that you could easily have an "indirect instruction" mode rather than stepping through the PPC instructions to fetch, shift and jump. At this point each PPC instruction is 4 in the table plus the address generation for the loop (I'd guess 4 to 8), plus some more instructions to keep track of things like flags (4-8)
Later on Apple moved to a "dynamic recompilation" emulator. I can't find any details of what this means technically, but it sounds like rather than fetching an instruction and jumping into the table they fetched the instuctions for a basic block and copied them into ram and then jumped there instead. Just doing that saves you the fetch/shift and jump. Of course it's still not very efficient. E.g. a mov instruction will end up at least 4 PPC instructions. Mind you the copy routine could stop copying when it hits a NOP.
There are much deeper optimisations to be done though - like not keeping track of the flags until you know they are needed, which is something other binary translators do. I don't know fore sure if the Apple's DR emulator did those, but it's probable.
Because the Nazis had a large conventional army and the insurgents in Iraq don't. I.e. a battle between two large tank armies would be completely different.
USB is much harder to virtualise than PCI. PCI devices look like like memory to the host. You could easily hack the HAL in Windows so that devices can appear on the virtualized machine. I'm not sure how the UI would work, but I could imagine you'd right click on a device in device manager and send it to the VM. The host version of Windows would then unload the driver and unmap the device from memory. Then it would map it into the guest address space and let plug and play do the rest.
USB, by contrast is a complete pain. The host builds a structure in memory and the USB controller zips through it and generates the packets. Also USB controllers and not hot pluggable from the point of view of Windows - you need to reboot the machine when they appear or disappear. What's worse is that one controller will typically control many devices - in fact on a netbook there is typically only one USB 2.0 controller in the whole system. And there are other issue too - the USB 2.0 controller only handles the USB 2.0 devices. USB 1.0 devices are handled by a companion controller. Both controllers have to be on the same machine.
Of course maybe you could have some sort of stub host controller driver on the guest machine that forwards the IRPs (device driver request packets) to the host. Looking at VMWare this is probably what it does.
Still either of these require extensive work in the host OS. And probably in the guest one too. There are horrible timing issues too with USB no matter what you do. Lots of USB device drivers are probably sensitive to timing, slow things down and they will bluescreen or stop working. And there are things like bus suspension.
I think you could do it, but it won't be reliable.
Of course, that's general USB device support. Specific cases like USB Mice and Keyboards are no problem at all, because the host handles the device access and can send messages with mouse position and keyboard scan codes into the guest. So it doesn't matter if the host has a USB mouse and keyboard. I think things like mass storage devices could be made to work too. The general case where you have ISO and interrupt endpoints or timing sensitive drivers that stream data and need to handle bus suspension is really hard however.
Loads of people are torrenting at any one time. Probably the vast majority of them will torrent a few files and then stop. A small minority will torrent 24/7 maxing out their pipes.
Now if you want to shut down filesharing it is this small minority that you want to target, firstly because they are a legally inviting target - it's hard for them to claim they are innocent if you can show they were maxing out their DSL connection 24/7. Also from a PR point of view it's better to sue the hard core pirates than the casual ones - you avoid headlines about grandmothers being sued for thousands of dollars because their grandkids downloaded a couple of songs. Last but not least they are the ones seeding most of the files because the casual torrenters download what they want and then shutdown the application.
Normally of course there's no good way looking at one torrent to work out which torrenters are the hard core minority and which are casual torrenters.
Enter PeerGuardian.
The hard core torrenters will download and install it and the casual ones won't bother. Now you have an easy way to distinguish the two. Try to connect from a few IP addresses on the blocklist, and try to connect from a few that aren't. The last point is important - anti piracy organisations have lots of employees and could easily ask those employees to run some sort of tool from their home DSL connection, or they could buy a few DSL modems and stick them in the basement, or use a VPN to a pool of residential IP connections. I.e. it's quite easy for them to get hold of IP addresses which are not in their organisational IP block. So long as they don't attack torrents from those IP addresses there is no reason for those addresses to be blacklisted.
So PeerGuardian provides no protection for downloaders and it provides very useful information to anti piracy organisations.
If you don't want to get sued, don't seed and don't install things like PeerGuardian.
I am off down the road Where the fairy lanterns glowed And the little pretty flitter-mice are flying A slender band of gray It runs creepily away And the hedges and the grasses are a-sighing. The air is full of wings, And of blundery beetle-things That warn you with their whirring and their humming. O! I hear the tiny horns Of enchanged leprechauns And the padded feet of many gnomes a-coming! O! the lights! o! the gleams! O! the little twinkly sounds! O! the rustle of their noiseless little robes! O! the echo of their feet - of their happy little feet! O! the swinging lamps in the starlit globes.
I must follow in their train Down the crooked fairy lane Where the coney-rabbits long ago have gone. And where silvery they sing In a moving moonlit ring All a twinkle with the jewels they have on. They are fading round the turn Where the glow worms palely burn And the echo of their padding feet is dying! O! it's knocking at my heart- Let me go! let me start! For the little magic hours are all a-flying.
O! the warmth! O! the hum! O! the colors in the dark! O! the gauzy wings of golden honey-flies! O! the music of their feet - of their dancing goblin feet! O! the magic! O! the sorrow when it dies.
--J.R.R. Tolkein
Two things spring to mind. One - Tolkein was a crap poet, and Two you owe me $55.
This isn't for home users, it's for corporate ones.
Corporate users have a mix of badly behaved 32 bit user/kernel mode code, 16 bit Windows applications and probably a few Dos ones. Plus they have a internet applications that only work on IE6. Much of this they might have bought from third parties or produced in an unofficial project where the original programmer left or 'didn't have time' to hand over source code or explain anything so know one else knows how to modify it.
Without virtualisation some of this would not work, with it it will since they can set up a clone of their old environment in virtual XP. Looking at the screenshots it's quite well integrated too, you can launch the apps from the Win7 start menu.
Slashdot Mirror
V'ir nyJnlD guBhtuG gung xyVatbA ybbxF n ovG yvxR ebg13
I destroyed my PowerPC Mac with a hammer as soon as Steve Jobs, our Leader, declared them to be obsolete and went out and bought a much faster Intel Mac.
Besides x86 chips have always been faster than PPC ones. Except before the Leader announced the change. Then of course they had always been slower. This may seem a bit contradictory to you, but that's because you don't understand the Reality Distortion principle.
Here in Taiwan people use old CDs as bike reflectors.
I always liked Start (or Windows key)->cmd->Ctrl+Shift+Enter. Gives you an elevated (i.e. with Admin rights) command prompt on Vista.
Ship first, patch later and frequently.
Release early, release often?
"Someone asked me the difference between the Sex Pistols and the Beatles. It's chalk and cheese. I was only a nipper when then Beatles were going, but I was fucking glad when they broke up"
Steve Jones
If a few lay-men webanaughts can find prior art in patents that were enough to force a company to settle out of court
I think that should read "a few lay-men webanaughts claimed to find prior art in patents that were enough to force a company to settle out of court"
Get real here, 90% of "lay-men webanaughts" hate Microsoft. Claims of prior art will get modded up regardless of legal merit.
I bet if you tried any USB device that needed to stream data you'd see the same issues you see with your headset. Or worse actually, the driver for the headphones is a Microsoft one, right? When it stutters I'd say it's because it failed to keep up with the stream. The fact it doesn't bluescreen or hang at that point means it manages to recover at that point. If you buy a cheapo streaming USB device, I'd expect it to crash horribly if its timing assumptions were violated.
No, in Windows the a WDM driver calls Windows and asks for a scatter gather list. Also you allocate something called map registers
http://blogs.msdn.com/peterwie/archive/2006/03/02/542517.aspx
Map registers are an abstraction the DMA API uses to track the system resources needed to make one page of memory accessible by your device for a DMA transfer. They may represent a bounce buffer - a single page of memory which the device can access that the DMA will use to double-buffer part of your transfer. They could (in the world of the future) represent entries in a page map that maps pages in the physical address space into the device's logical address space (another DDK term). Or in the case of a 32-bit adapter on a 32-bit system where there's no need for translation, it might represent absolutely nothing at all. However since you probably want to write a driver that makes your device work on any Windows system, you should ignore this last case and focus on the ones where translation is needed.
You'll want to allocate enough map registers to handle your maximum transfer size. This limit might be exposed by your hardware, or as a tunable parameter in the registry, or just by common sense (you probably don't need to transfer 1GB in a single shot now do you?). However since map registers can be a limited resource, you may not always get the number you asked for (it's an in/out parameter to IoGetDmaAdapter). In that case you'll need to cut down your maximum transfer size - either rejecting larger transfers or breaking them up into smaller pieces and staging them.
A map register is a abstraction for a resource that maps one page of memory into the memory that is visible to the device. When you map a transfer the HAL could double buffer, or program an IOMMU, or it could do nothing (this was almosts always the case on x86). And the Intel version of IOMMU is apparently better optimised for virtualising DMA. Though it seems like the AMD one would work too.
Mind you, there's an issue with drivers not following the rules because they could get away with it on x86. Still the NT DMA model has always supported all of these options (no buffering, an IOMMU or a bounce buffer) though - it's very foresighted in that respect.
Actually bus master DMA does make PCI harder. It's still possible on Windows though - the model is that Windows creates scatter/gather lists for you. The API also has plugs for the HAL potentially adding an extra layer of buffering in software once you start a transfer and tear it down at the end of the transfer. On x86 most of these plugs have traditionally been unused. On Risc they were used but with PAE enabled they are used to allow devices that can't bus master above 4GB to be used on 64 bit systems. I think some NUMA servers might have a non trivial implementation of DMA too. Basically the NT kernel has always had an abstraction for things like DMA to keep code portable.
I still think you're too blase about virtualising USB though. Of course you can add a driver to do it, my point is that by doing so you add a lot of latency. I'm suspect a lot of USB device drivers won't be able to handle that.
Damn right. I think if everyone were more phlegmatic about this it the terrorists would see them as less desireable targets.
The flu, Stock market is down, GM tossing Pontiac, then this? Man, Obama is sure playing with "NYC's head" today. Paranoid enough?
Maybe the plan is to do all this stuff, or at least encourage CNN to tell us it is happening for the next four years. By that point we'll be nervous wrecks. Then in the run up to the election talk only about Bo the whitehouse dog and release loads of spurious stories about how New York now has drunking water again and zombie numbers are decreasing.
Massive victory.
Too bad that torrent clients and the bit torrent protocol in general require you to seed. Tit for tat protocol remember. If you want the data, you have to share the data. Well, at least if you want it in this century instead of 4GB or more @ 1kb/s (WoW and AoC, I am looking at you). Did you even have any idea at all how Bittorent works?
If I stop seeding once I have the file it doesn't affect the download time at all, it's not like people bear a grudge against my IP address. Not that they could actually, it's dynamic.
But seriously...some protection is better than no protection at all, and your fallacious argument about suing grannies is just silly. They've sued DEAD PEOPLE.
Yeah, and it was a PR disaster and didn't achieve anything. If I were them I'd concentrate on finding hard core pirates and targetting them.
Actually it's a bit like the joke.
Q) Why do you carry that heavy idol around with you?
A) It keeps away tigers.
Q) That's ridiculous!
A) No it's not, I've never seen any tigers.
I remember reading 68K emulation on the PPC worked like this. Instructions on a 68K are 16 bits wide. The emulator would fetch a 68K instruction word, and use it as an index into a table. Each entry in the table had enough space for 16 bytes, 4 32 bit PPC instructions. Most 68K instructions could be done in situ, a small minority needed more space. So there was a 1MB table of instructions that made up the emulator.
Of course things like this make you wonder why the PPC didn't have some sort of hardware support for this scheme. It seems to me that you could easily have an "indirect instruction" mode rather than stepping through the PPC instructions to fetch, shift and jump. At this point each PPC instruction is 4 in the table plus the address generation for the loop (I'd guess 4 to 8), plus some more instructions to keep track of things like flags (4-8)
Later on Apple moved to a "dynamic recompilation" emulator. I can't find any details of what this means technically, but it sounds like rather than fetching an instruction and jumping into the table they fetched the instuctions for a basic block and copied them into ram and then jumped there instead. Just doing that saves you the fetch/shift and jump. Of course it's still not very efficient. E.g. a mov instruction will end up at least 4 PPC instructions. Mind you the copy routine could stop copying when it hits a NOP.
There are much deeper optimisations to be done though - like not keeping track of the flags until you know they are needed, which is something other binary translators do. I don't know fore sure if the Apple's DR emulator did those, but it's probable.
Because the Nazis had a large conventional army and the insurgents in Iraq don't. I.e. a battle between two large tank armies would be completely different.
USB is much harder to virtualise than PCI. PCI devices look like like memory to the host. You could easily hack the HAL in Windows so that devices can appear on the virtualized machine. I'm not sure how the UI would work, but I could imagine you'd right click on a device in device manager and send it to the VM. The host version of Windows would then unload the driver and unmap the device from memory. Then it would map it into the guest address space and let plug and play do the rest.
USB, by contrast is a complete pain. The host builds a structure in memory and the USB controller zips through it and generates the packets. Also USB controllers and not hot pluggable from the point of view of Windows - you need to reboot the machine when they appear or disappear. What's worse is that one controller will typically control many devices - in fact on a netbook there is typically only one USB 2.0 controller in the whole system. And there are other issue too - the USB 2.0 controller only handles the USB 2.0 devices. USB 1.0 devices are handled by a companion controller. Both controllers have to be on the same machine.
Of course maybe you could have some sort of stub host controller driver on the guest machine that forwards the IRPs (device driver request packets) to the host. Looking at VMWare this is probably what it does.
Still either of these require extensive work in the host OS. And probably in the guest one too. There are horrible timing issues too with USB no matter what you do. Lots of USB device drivers are probably sensitive to timing, slow things down and they will bluescreen or stop working. And there are things like bus suspension.
I think you could do it, but it won't be reliable.
Of course, that's general USB device support. Specific cases like USB Mice and Keyboards are no problem at all, because the host handles the device access and can send messages with mouse position and keyboard scan codes into the guest. So it doesn't matter if the host has a USB mouse and keyboard. I think things like mass storage devices could be made to work too. The general case where you have ISO and interrupt endpoints or timing sensitive drivers that stream data and need to handle bus suspension is really hard however.
PeerGuardian is a trap. Consider.
Loads of people are torrenting at any one time. Probably the vast majority of them will torrent a few files and then stop. A small minority will torrent 24/7 maxing out their pipes.
Now if you want to shut down filesharing it is this small minority that you want to target, firstly because they are a legally inviting target - it's hard for them to claim they are innocent if you can show they were maxing out their DSL connection 24/7. Also from a PR point of view it's better to sue the hard core pirates than the casual ones - you avoid headlines about grandmothers being sued for thousands of dollars because their grandkids downloaded a couple of songs. Last but not least they are the ones seeding most of the files because the casual torrenters download what they want and then shutdown the application.
Normally of course there's no good way looking at one torrent to work out which torrenters are the hard core minority and which are casual torrenters.
Enter PeerGuardian.
The hard core torrenters will download and install it and the casual ones won't bother. Now you have an easy way to distinguish the two. Try to connect from a few IP addresses on the blocklist, and try to connect from a few that aren't. The last point is important - anti piracy organisations have lots of employees and could easily ask those employees to run some sort of tool from their home DSL connection, or they could buy a few DSL modems and stick them in the basement, or use a VPN to a pool of residential IP connections. I.e. it's quite easy for them to get hold of IP addresses which are not in their organisational IP block. So long as they don't attack torrents from those IP addresses there is no reason for those addresses to be blacklisted.
So PeerGuardian provides no protection for downloaders and it provides very useful information to anti piracy organisations.
If you don't want to get sued, don't seed and don't install things like PeerGuardian.
Keeping very quiet.
People laughed at poor old Charles Manson, but it turns out he was actually spot on.
Helter Skelter has arrived and it is time to KILL THE PIGS!
[Guitar Solo]
GOBLIN FEET
I am off down the road
Where the fairy lanterns glowed
And the little pretty flitter-mice are flying
A slender band of gray
It runs creepily away
And the hedges and the grasses are a-sighing.
The air is full of wings,
And of blundery beetle-things
That warn you with their whirring and their humming.
O! I hear the tiny horns
Of enchanged leprechauns
And the padded feet of many gnomes a-coming!
O! the lights! o! the gleams! O! the little twinkly sounds!
O! the rustle of their noiseless little robes!
O! the echo of their feet - of their happy little feet!
O! the swinging lamps in the starlit globes.
I must follow in their train
Down the crooked fairy lane
Where the coney-rabbits long ago have gone.
And where silvery they sing
In a moving moonlit ring
All a twinkle with the jewels they have on.
They are fading round the turn
Where the glow worms palely burn
And the echo of their padding feet is dying!
O! it's knocking at my heart-
Let me go! let me start!
For the little magic hours are all a-flying.
O! the warmth! O! the hum! O! the colors in the dark!
O! the gauzy wings of golden honey-flies!
O! the music of their feet - of their dancing goblin feet!
O! the magic! O! the sorrow when it dies.
--J.R.R. Tolkein
Two things spring to mind. One - Tolkein was a crap poet, and Two you owe me $55.
Right and jealousy doesn't enter into it all.
MS Bob was managed by his girlfriend who he later married.
And actually the Search Doggy from Windows XP came from Bob
http://toastytech.com/guis/bob.html
Search Doggy was a very good dog, he always found my files when I lost them.
OTOH, including "all" of Windows XP SP3 seems kind of egregious...
XPSP3 isn't necessarily that big.
nLite can strip it down to 189MB
http://wiki.eeeuser.com/howto:nlitexp
This isn't for home users, it's for corporate ones.
Corporate users have a mix of badly behaved 32 bit user/kernel mode code, 16 bit Windows applications and probably a few Dos ones. Plus they have a internet applications that only work on IE6. Much of this they might have bought from third parties or produced in an unofficial project where the original programmer left or 'didn't have time' to hand over source code or explain anything so know one else knows how to modify it.
Without virtualisation some of this would not work, with it it will since they can set up a clone of their old environment in virtual XP. Looking at the screenshots it's quite well integrated too, you can launch the apps from the Win7 start menu.