Barence writes "Microsoft is planning to make Windows 8 a 128-bit operating system, according to details leaked from the software giant's Research department. The discovery came to light after Microsoft Research employee Robert Morgan carelessly left details of his work on the social-networking site LinkedIn. His page read: 'Working in high-security department for research and development involving strategic planning for medium and long-term projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM.' It has since been removed."
Neither has AMD or Intel. Most 64-bit processors provide 40 or 48 bits of address space; they ignore the other two or three bytes of the address (often they support a larger virtual address space than physical, but even then it's usually less than 64-bit). I've yet to see a consumer-grade machine with more RAM than PAE (36-bit addressing) could address. That said, memory is not the only place where the number of bits is important. Hard drives are typically addressed by 512-byte blocks, so 32 bits gives you 2TB, which is a single disk these days. 64 bits gives you 8ZB, which is quite a lot, but it's not a completely unreasonable amount; some people are going to find that constraining in the next few years, which is why ZFS uses 128 bits. It's not that 128 bits are necessary, so much that 65 bits are and 128 is the most computationally-convenient size after 128. Making sure everything in the kernel supports 128-bit filesystem offsets is an important for long-term project.
If we start using PCRAM then we are likely to want to use byte-addressable filesystems, rather than keep relying on blocks, which reduces the size you can address with 64 bits to 16EB, which is a lot less; there are almost certainly already people with datasets larger than this. Because PCRAM has similar characteristics to DRAM, the most convenient way of addressing it is likely to be mapping it directly into the CPU's address space, rather than treating it as a device. You could use paging tricks and only map accessed files, but having two MMUs doesn't make life very simple for operating system writers, so ideally you're going to want to have all of your persistent storage in your address space (like MULTICS: everything old is new again). If you do this, then you may well want to have more than a 64-bit address space within ten years. And, when I say 'you' I mean 'companies with a lot of spare money to spend on IT infrastructure'.
Let me guess: you've never written any ring 0 code for x86. PAE doesn't hide the memory. It modifies the page table structure slightly (so does 64-bit, by the way, it makes the page tables deeper which makes every TLB fault slower). You have a 32-bit virtual address space and a 36-bit physical address space. No process can see more than 4GB of RAM, but if you have two processes then they can each see a different 4GB of physical RAM. None of my processes currently uses more than 760MB of address space, but I have 3GB of RAM and 3GB of swap used, so with a PAE system and 8GB of RAM each process would be using physical memory and I'd have 2GB for filesystem cache.
Oh, and when people talk about PAE, they also often mean PAE or PSE. PSE just makes pages bigger (up to 4MB), which can be used to address 64GB of RAM without changing the size of the page tables. This is better in some situations, because it involves smaller page tables and fewer TLB faults, but it means that you are swapping 4MB at a time, which can be very slow if you are swapping a lot.
That would make Windows a 128 bit wrapper around a 64 bit implementation of a 32 bit extension for a 16 bit patch to an 8 bit operating system, originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.
Well, that settles it, then! Why on earth would I buy a paltry 64-bit Windows 7 when a much shinier and newer 128-bit Windows 8 is right around the corner? I'd best hold off until then! Thanks, Microsoft!
- BSOD now in 4D (3 spatial dimensions and time, more precisely from 1988 to 2015) - That is what requires Security Essentials to have a string sample in memory of every Windows virus/trojan before 2006 - Bill Gates finally agreed that 640k wasnt enough for everyone. - Codenamed Windows TNG, where no bit has gone before - You actually will need all that memory to not require swapping (unless you load more than 3 apps)
It refers to a 128 bit filesystem ala ZFS, not the whole OS.
Either we're not reading the same article, or I suspect you didn't read it at all. At no point is a filesystem mentioned.
I'm with you, I don't know where he got filesystem from:
The senior researcher's profile said he was: "Working in high security department for research and development involving strategic planning for medium and longterm projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM."
Not only does it say 'architecture', it also says 'architecture compatibility'.
Why is that important? Because it does not mean that Windows 8 will necessarily be 128bit, just capable of being 128bit - for all we know, his entire role is ensuring that the teams code to a set standard which allows ease of porting to 128bit in future.
What's the point of having 128 bit compatibility? 128 bit CPUs don't even exist yet. Heck most of us are still just using 32, and haven't even visited the 64 generation yet.
Okay, but the question is what does that mean? If it just means 128-bit operations or registers, then that's been around since the original SSE. If it means 128-bit addressing (like it usually does), then who the fuck is making those chips and why? Very few 64-bit chips actually support the full 64-bits of address space (certainly not Intel or AMD), simply because there's no need. You could make every computer on earth part of a huge shared-memory system and have room to spare, not that you'd ever do such a thing. Once systems get far enough apart, shared memory stops making sense as maintaining coherence/consistency becomes too much of an overhead. If you were building a cluster as a shared memory system, and each node had 1 TB of RAM, you could fit ten million nodes in before you started to have address space problems. Even the most wasteful of Stupid Virtual Memory Tricks aren't going to put a lot of pressure on 64-bit addressing any time soon.
I mean I guess I can see the point for the distant future, and hey who the hell knows when Windows 9 is planned for much less will actually arrive, so it can't hurt to make sure it's 'compatible'... I'm just more surprised that any of the partners listed would have 128-bit on even far-reaching roadmaps.
The original IBM System 38 and its descendants, such as OS/400, OS/500, etc., had a 128-bit address space. In these architectures, the large number of address bits were used to provide an address space that spanned both memory and disks and was used to provide processor-level protection for objects stored there. Using large address spaces to ensure hardware protection of system objects is a good start on a highly secure OS and is probably where this is going.
And Intel is no stranger to hardware object protection, either. The iAPX-432 chipset, although not a commercial success, showed that hardware-level protection of objects is feasible, with more complex access controls than can be provided with reasonable performance than with software implementations of complex access control schemes (note I said complex - one of the reasons that the chip failed commercially is that, besides having a braindead two-chip implementation and instruction lengths that varied at the bit level, it could not support simple protection schemes as quickly as software was able to do). Intel is looking for what to do with the extra transistors that feature shrinks provide - adding better protection at the hardware level might be a win.
No, IBM never produced an "OS 500". The branding went from OS/400 to i5/OS to today's "IBM i".
No, the system never had a 128-bit address space. The address space of OS400 went from 48-bit to 64-bit when IBM started using 64-bit Power-based processors in those systems.
Yes, the instruction set uses 128-bit pointers, but only the rightmost 64 bits of the pointer are used in the current system.
Yes, The 64-bit address space covers both system memory and disk storage.
Because with huge servers and clustering you can get some insanely huge numbers when it comes to HDD space. But as I'm sure we all know when it comes to a 128 OS, we are usually talking about addressing, ala 16bit, 32bit, 64bit.
You don't need 128 bits for addressing. 2^32 is "only" 4 gigabytes, which was always achievable in theory and actually achieved in practice over a decade ago.
Having a memory — RAM or disk — above 2^64, however, is not achievable in even in theory... 2^64 is only 100 times less, for example, than the estimated number of sand-grains on Earth [wolframalpha.com].
Being able to process as much as 128 bits in one CPU-instruction is nice, and SSE extensions allow that. But neither size_t nor off_t need to exceed 64 bits. Ever... In fact, in the amd64 instruction set [wikipedia.org], only 48 bits can be used to address memory — the rest are for the CPU instruction, so that both the operation and the operand fit in one 64-bit word. The amd64-architecture is thus "limited" to 256 TB — that's the largest RAM an amd64-machine can have and the largest file and amd64-machine can mmap [wikipedia.org].
64-bit systems were truly useful, because — by making size_t and off_tthe same, they allowed software to be rid of having to segment access to files, which could, potentially, be too large to memory-map in their entirety (many legacy mmap-implementations are still limited to 2- or 4-Gb files). 128-bit systems are not adding that benefit...
(And, of course, most systems — including even the most modern Linux and BSD — still have rather poor mmap-implementations, compared to their highly-optimized read and write calls... But that's another topic...)
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
Terje
Since Win8 / Win9 won't be out for 5/10 years...
Why am I getting flashbacks to a discussion that people had back in the 8 bit days?
"Making the entire os 32-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)... Having 32 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines."
I never heard this discussion, but you know it happened. Probably almost verbatim.
Yeah, I think I remember him. He thought the Internet was a passing fad, claimed he'd single-handedly defeat spam, promised Microsoft was taking security seriously in 2000, all kinds of nonsense like that. Had a really dorky haircut too.
The senior researcher's profile said he was: "Working in high security department [emphasis mine] for research and development involving strategic planning for medium and longterm projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM."
My first reaction was that if you can't fix the security problems in the people, you surely can't expect to fix the security problems in the software. But that might be a little hasty.
My guess is that the actual security gaffe here was little or nothing. He mentioned he worked in this department, and that they have future plans that exceed today's capabilities. Meh. So what. If he had posted the details of what he was doing, then it would have been newsworthy. As it is, this barely notable. Any one of us here could probably guess that MS likely has people looking into the progression beyond 64 bit technology.
It is reasonable to believe that at some point in the next several years the hardware companies he mentions will have some plan to start building 128 bit cpus. My guess is that this guy's job is to make sure that MS has input into the design process where it can, and to provide feedback to the MS dev teams so MS can start planning to include compatibility features relatively early on, to hopefully be the OS of choice when this hardware someday becomes available. I'm guessing that Windows 8 probably won't be seen for a long time. The article mentions 2012, but given MS's rush to push out 7 to stem the bleeding caused by Vista they may rely on it for longer than normal, much like they did with XP after the ME debacle. If I were writing an OS that would likely debut in 4 to 8 years, I would probably want a heads up from the hardware vendors about how to write an OS for their next gen proc. Also, if MS were planning a future move to a fully 128-bit OS, they might start by inserting 128-bit code into a 64-bit OS.
For the uninitiated, v- and a- are Microsoft's way of identifying vendors (Microsoft is their client for whatever reason) and CSGs respectively (a fancy acronym for contractors).
Someone else posted a link to an ArsTechnica article about this. They had more info from the LinkedIn post, which indicated that the work was being done to target the IA-128 instruction set (which is currently only available as a simulator, no actual silicon, *yet*). But, since Intel hasn't abandoned Itanium yet, and they are targetting it at Enterprise and High Performance Computing, I could totally see Intel evolving the Itanium architecture from 64-bits to 128-bits. After all, there are a few servers in the world that handle truly epic amounts of data, and really might be able to use more than 64-bits.
It's probably that they are laying the groundwork now, for release 5 or 10 years down the road.
The article, and indeed the blurb he wrote in his profile, does not necessarily point to a 128bit OS, just that the Windows 8 kernel will have 128bit 'architecture compatibility', which probably means hes ensuring that they remove all burdens of porting to the 128bit architecture now, rather than later.
128, 64, 32, 16, 8 (Score:5, Funny)
Who needs 128? I haven't even used all 64 of my current bits yet.
-l
Re:128, 64, 32, 16, 8 (Score:5, Informative)
If we start using PCRAM then we are likely to want to use byte-addressable filesystems, rather than keep relying on blocks, which reduces the size you can address with 64 bits to 16EB, which is a lot less; there are almost certainly already people with datasets larger than this. Because PCRAM has similar characteristics to DRAM, the most convenient way of addressing it is likely to be mapping it directly into the CPU's address space, rather than treating it as a device. You could use paging tricks and only map accessed files, but having two MMUs doesn't make life very simple for operating system writers, so ideally you're going to want to have all of your persistent storage in your address space (like MULTICS: everything old is new again). If you do this, then you may well want to have more than a 64-bit address space within ten years. And, when I say 'you' I mean 'companies with a lot of spare money to spend on IT infrastructure'.
Parent
Re:PAE hides that memory (Score:5, Informative)
Let me guess: you've never written any ring 0 code for x86. PAE doesn't hide the memory. It modifies the page table structure slightly (so does 64-bit, by the way, it makes the page tables deeper which makes every TLB fault slower). You have a 32-bit virtual address space and a 36-bit physical address space. No process can see more than 4GB of RAM, but if you have two processes then they can each see a different 4GB of physical RAM. None of my processes currently uses more than 760MB of address space, but I have 3GB of RAM and 3GB of swap used, so with a PAE system and 8GB of RAM each process would be using physical memory and I'd have 2GB for filesystem cache.
Oh, and when people talk about PAE, they also often mean PAE or PSE. PSE just makes pages bigger (up to 4MB), which can be used to address 64GB of RAM without changing the size of the page tables. This is better in some situations, because it involves smaller page tables and fewer TLB faults, but it means that you are swapping 4MB at a time, which can be very slow if you are swapping a lot.
Parent
Re:128, 64, 32, 16, 8 (Score:5, Funny)
With that uid, it's because your pr0n is ASCII art.
Parent
Re:128, 64, 32, 16, 8 (Score:5, Funny)
I'd make you a little ASCII lawn to get off of but I'm still looking for my dentures.
-l
Parent
Re:128, 64, 32, 16, 8 (Score:5, Insightful)
Lameness filter encountered. Post aborted!
Filter error: Please use fewer 'junk' characters.
It's a sad day when you can no longer post ASCII art onto a forum. Have we come so far that we've forgotten where we come from?
Parent
Re:128, 64, 32, 16, 8 (Score:4, Funny)
Parent
128 bit? (Score:5, Funny)
Volume: 11 (Score:5, Funny)
Re:Volume: 11 (Score:5, Funny)
bare with me
*Shudder*
Parent
Re:Volume: 11 (Score:5, Funny)
Well, his (her?) user name IS "no undies".
Parent
Re:Volume: 11 (Score:5, Funny)
In my 128-bit OS, the volume does nothing because SoundMax hasn't released drivers yet.
Parent
And our friend Robert (Score:5, Funny)
Fuck Everything (Score:5, Funny)
We're doing five blades.
Re:Fuck Everything (Score:5, Funny)
Parent
Re:Fuck Everything (Score:5, Funny)
WE'LL DO IT LIVE!!!
Parent
Re:Fuck Everything (Score:5, Funny)
Parent
Re:Fuck Everything (Score:5, Informative)
I almost wet my pants during the Fusion ads in the Superbowl. Becaues they did go to 5 (+1) blades.
http://www.theonion.com/content/node/33930 [theonion.com]
Parent
That would make... (Score:5, Funny)
When will MS learn (Score:4, Insightful)
Windows 7 isn't even officially released and already nonsense is leaking about the next release with promises they can't keep.
FIrst let them release WinFS.
128 bit OS? (Score:5, Funny)
16.8 million terabytes of RAM should be enough for anyone.
Re:128 bit OS? (Score:4, Funny)
Parent
Upgrade paths (Score:5, Funny)
Well, that settles it, then! Why on earth would I buy a paltry 64-bit Windows 7 when a much shinier and newer 128-bit Windows 8 is right around the corner? I'd best hold off until then! Thanks, Microsoft!
Filesystem, or FPU... not processor or memory (Score:5, Informative)
This has been discussed on OSNews and it is most likely about the filesystem or FPU and not memory addressing.
http://www.osnews.com/story/22301/128-Bit_Support_in_Windows_8_9_ [osnews.com]
For security (Score:5, Funny)
Quoth Balmer, "Let's see hackers find our security holes in this address space!"
Why they need 128 bits? (Score:5, Funny)
- That is what requires Security Essentials to have a string sample in memory of every Windows virus/trojan before 2006
- Bill Gates finally agreed that 640k wasnt enough for everyone.
- Codenamed Windows TNG, where no bit has gone before
- You actually will need all that memory to not require swapping (unless you load more than 3 apps)
128 bit C data type? (Score:5, Funny)
long long long?
really long long?
Re:128 bit C data type? (Score:5, Insightful)
int128_t?
It blows my mind how few people use stdint.h when it makes a lot more sense to use that these days.
Parent
Re:Not really (Score:5, Informative)
Either we're not reading the same article, or I suspect you didn't read it at all. At no point is a filesystem mentioned.
Parent
Re:Not really (Score:5, Informative)
It refers to a 128 bit filesystem ala ZFS, not the whole OS.
Either we're not reading the same article, or I suspect you didn't read it at all. At no point is a filesystem mentioned.
I'm with you, I don't know where he got filesystem from:
The senior researcher's profile said he was: "Working in high security department for research and development involving strategic planning for medium and longterm projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM."
Clearly says architechture.
Parent
Re:Not really (Score:5, Informative)
Why is that important? Because it does not mean that Windows 8 will necessarily be 128bit, just capable of being 128bit - for all we know, his entire role is ensuring that the teams code to a set standard which allows ease of porting to 128bit in future.
Parent
Re:Not really (Score:5, Informative)
I'm still confused.
What's the point of having 128 bit compatibility? 128 bit CPUs don't even exist yet. Heck most of us are still just using 32, and haven't even visited the 64 generation yet.
Parent
Re:Not really (Score:5, Interesting)
Clearly says architechture.
Okay, but the question is what does that mean? If it just means 128-bit operations or registers, then that's been around since the original SSE. If it means 128-bit addressing (like it usually does), then who the fuck is making those chips and why? Very few 64-bit chips actually support the full 64-bits of address space (certainly not Intel or AMD), simply because there's no need. You could make every computer on earth part of a huge shared-memory system and have room to spare, not that you'd ever do such a thing. Once systems get far enough apart, shared memory stops making sense as maintaining coherence/consistency becomes too much of an overhead. If you were building a cluster as a shared memory system, and each node had 1 TB of RAM, you could fit ten million nodes in before you started to have address space problems. Even the most wasteful of Stupid Virtual Memory Tricks aren't going to put a lot of pressure on 64-bit addressing any time soon.
I mean I guess I can see the point for the distant future, and hey who the hell knows when Windows 9 is planned for much less will actually arrive, so it can't hurt to make sure it's 'compatible'... I'm just more surprised that any of the partners listed would have 128-bit on even far-reaching roadmaps.
Parent
Re:Not really (Score:5, Interesting)
The original IBM System 38 and its descendants, such as OS/400, OS/500, etc., had a 128-bit address space. In these architectures, the large number of address bits were used to provide an address space that spanned both memory and disks and was used to provide processor-level protection for objects stored there. Using large address spaces to ensure hardware protection of system objects is a good start on a highly secure OS and is probably where this is going.
And Intel is no stranger to hardware object protection, either. The iAPX-432 chipset, although not a commercial success, showed that hardware-level protection of objects is feasible, with more complex access controls than can be provided with reasonable performance than with software implementations of complex access control schemes (note I said complex - one of the reasons that the chip failed commercially is that, besides having a braindead two-chip implementation and instruction lengths that varied at the bit level, it could not support simple protection schemes as quickly as software was able to do). Intel is looking for what to do with the extra transistors that feature shrinks provide - adding better protection at the hardware level might be a win.
Parent
Re:Not really (Score:5, Informative)
No, IBM never produced an "OS 500". The branding went from OS/400 to i5/OS to today's "IBM i".
No, the system never had a 128-bit address space. The address space of OS400 went from 48-bit to 64-bit when IBM started using 64-bit Power-based processors in those systems.
Yes, the instruction set uses 128-bit pointers, but only the rightmost 64 bits of the pointer are used in the current system.
Yes, The 64-bit address space covers both system memory and disk storage.
This Wikipedia article about IBM System i [wikipedia.org] is a pretty good reference about this kind of stuff.
Parent
Re:Not really (Score:5, Funny)
Even the most wasteful of Stupid Virtual Memory Tricks aren't going to put a lot of pressure on 64-bit addressing any time soon.
You heard it here first, folks: 64-bit ought to be enough for anybody.
Parent
128 Bit Architecture = cloud computing (Score:5, Insightful)
Shared memory space among lots of computers, using IP (possibly IPv6) as a protocol.
That's probably what they are referring to if they mean 128 bit address space (not datapath).
Parent
You don't need 128 bits for addressing (Score:5, Interesting)
You don't need 128 bits for addressing. 2^32 is "only" 4 gigabytes, which was always achievable in theory and actually achieved in practice over a decade ago.
Having a memory — RAM or disk — above 2^64, however, is not achievable in even in theory... 2^64 is only 100 times less, for example, than the estimated number of sand-grains on Earth [wolframalpha.com].
Being able to process as much as 128 bits in one CPU-instruction is nice, and SSE extensions allow that. But neither size_t nor off_t need to exceed 64 bits. Ever... In fact, in the amd64 instruction set [wikipedia.org], only 48 bits can be used to address memory — the rest are for the CPU instruction, so that both the operation and the operand fit in one 64-bit word. The amd64-architecture is thus "limited" to 256 TB — that's the largest RAM an amd64-machine can have and the largest file and amd64-machine can mmap [wikipedia.org].
64-bit systems were truly useful, because — by making size_t and off_t the same, they allowed software to be rid of having to segment access to files, which could, potentially, be too large to memory-map in their entirety (many legacy mmap-implementations are still limited to 2- or 4-Gb files). 128-bit systems are not adding that benefit...
(And, of course, most systems — including even the most modern Linux and BSD — still have rather poor mmap-implementations, compared to their highly-optimized read and write calls... But that's another topic...)
Parent
Re:Not really (Score:5, Insightful)
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
Terje
Parent
Re:Not really (Score:5, Insightful)
None of the linked articles say that the 128 bits is for the filesystem only, but I still believe you're right:
Making the entire os 128-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.)
Having 128 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines.
This has been done before, afair IBM has used a 128 (or 129!) bit address space for their AS400 platform, where everything is memory mapped.
I.e. there is no visible file system, you just access objects by address (which is really a handle).
I believe Amazon's cloud storage is similar, in that the only way to access a blob of data is via a 128-bit handle.
Terje
Since Win8 / Win9 won't be out for 5/10 years...
Why am I getting flashbacks to a discussion that people had back in the 8 bit days?
"Making the entire os 32-bit would simply waste a _lot_ of memory, for zero real gain. (Rather the opposite: A larger working set always leads to slower code.) ... Having 32 bits available for filesystem/storage makes it quite feasible to have globally unique addresses for everything, across huge populations of machines."
I never heard this discussion, but you know it happened. Probably almost verbatim.
Parent
Re:Not really (Score:5, Funny)
The is no Robert Morgan that works at Microsoft. Not sure who this guy is but if he does work at MS its not his real name.
Well, not anymore, anyway. :-)
Parent
Re:Not really (Score:5, Funny)
Just like that other chap who was always making wild statements about what Microsoft was going to do next.
They let him go too. What was his name again? Will? Billy? ...something.
Parent
Re:Not really (Score:5, Funny)
Yeah, I think I remember him. He thought the Internet was a passing fad, claimed he'd single-handedly defeat spam, promised Microsoft was taking security seriously in 2000, all kinds of nonsense like that. Had a really dorky haircut too.
Parent
Re:Not really (Score:5, Insightful)
The senior researcher's profile said he was: "Working in high security department [emphasis mine] for research and development involving strategic planning for medium and longterm projects. Research & Development projects including 128-bit architecture compatibility with the Windows 8 kernel and Windows 9 project plan. Forming relationships with major partners: Intel, AMD, HP and IBM."
My first reaction was that if you can't fix the security problems in the people, you surely can't expect to fix the security problems in the software. But that might be a little hasty.
My guess is that the actual security gaffe here was little or nothing. He mentioned he worked in this department, and that they have future plans that exceed today's capabilities. Meh. So what. If he had posted the details of what he was doing, then it would have been newsworthy. As it is, this barely notable. Any one of us here could probably guess that MS likely has people looking into the progression beyond 64 bit technology.
It is reasonable to believe that at some point in the next several years the hardware companies he mentions will have some plan to start building 128 bit cpus. My guess is that this guy's job is to make sure that MS has input into the design process where it can, and to provide feedback to the MS dev teams so MS can start planning to include compatibility features relatively early on, to hopefully be the OS of choice when this hardware someday becomes available. I'm guessing that Windows 8 probably won't be seen for a long time. The article mentions 2012, but given MS's rush to push out 7 to stem the bleeding caused by Vista they may rely on it for longer than normal, much like they did with XP after the ME debacle. If I were writing an OS that would likely debut in 4 to 8 years, I would probably want a heads up from the hardware vendors about how to write an OS for their next gen proc. Also, if MS were planning a future move to a fully 128-bit OS, they might start by inserting 128-bit code into a 64-bit OS.
Parent
Re:Not really (Score:5, Interesting)
Parent
Re:Not really (Score:5, Informative)
Parent
Re:Not really (Score:5, Interesting)
Someone else posted a link to an ArsTechnica article about this. They had more info from the LinkedIn post, which indicated that the work was being done to target the IA-128 instruction set (which is currently only available as a simulator, no actual silicon, *yet*). But, since Intel hasn't abandoned Itanium yet, and they are targetting it at Enterprise and High Performance Computing, I could totally see Intel evolving the Itanium architecture from 64-bits to 128-bits. After all, there are a few servers in the world that handle truly epic amounts of data, and really might be able to use more than 64-bits.
It's probably that they are laying the groundwork now, for release 5 or 10 years down the road.
Parent
More information (Score:5, Informative)
Parent
Not sure... (Score:5, Funny)
But I'll tell you how it will end.
The final architecture EVER will be 640-bit. And that WILL be enough for everyone.
Parent
Re:fishy (Score:5, Insightful)
Parent