People are talking about the latest and greatest 'security' feature in Windows that has to be backed by hardware... (Strange, shouldn't software be improved in software? I digress). It seems to be about simply telling the processor to not and never treat as executable what is written in certain regions of memory. That, of course, will only be supported by upcoming hardware.
Not that I really know what I am writing about here... but is this really terribly new? If I recall my extremely brief career of programming 68K assembler (even recursion, yay!) there were registers for data and separate ones for addresses. The former were for, well, data and the latter for addresses to jump to. I don't know whether these ancient processors actually enforced this separation more strictly and I don't see how this distinction alone will give you protection in case of a loop running wild, but it surely looks like the conceptual distinction has been there for quite a while. Perhaps hackers sneered at that as 'self-manipulating code' may have seemed quite cool, but there must be something to having a barrier like this.
In a next step, a question I'd like to ask is how this kind of system treats scripting languages – somehow the scripts themselves aren't machine executable but they are still going to be executed by the interpreter. I can't see such a solution offer much protection there.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.