Microsoft Leaks Details of 128-bit Windows 8

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

Comments

More information

[SlashDotDotDot]

here.

Re:Not really

[BrokenHalo]

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.

Re:Not really

[noundi]

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.

Filesystem, or FPU... not processor or memory

[FunkyELF]

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_

Re:128, 64, 32, 16, 8

[TheRaven64]

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

Re:Not really

[Richard_at_work]

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.

Re:Fuck Everything

[ElSupreme]

BEST Onion article EVER!

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

Re:Not really

[commodore64_love]

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.

PAE doesn't hide mem, just can't use all at once

[Lemming Mark]

PAE doesn't "hide" memory, really. You can only address 4GB (i.e. a 32-bit address space) of virtual memory at once but that can be *anywhere* across the 36-bit physical address space. As long as no individual app needs more than 4GB of memory you're (mostly) OK. The kernel can alter the mappings as it needs to poke at anywhere interesting in all of physical RAM. It's less efficient than mapping it all in at once but you can manage quite well.

Re:PAE hides that memory

[TheRaven64]

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.

Re:Not really

[atari2600]

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

Re:Not really

[jdgeorge]

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 is a pretty good reference about this kind of stuff.

Re:April fools!

[olivesaregross]

From Windows IT Pro: "All your rumors are belong to me: Windows 8 to be 128-bit? No. Good God, no. People can be so silly sometimes. Writers at PC World, Ars Technica, Slashdot and many other publications fell for an obviously faked LinkedIn profile from a supposed Microsoft researcher who claimed he was working on a 128-bit kernel for Windows 8. There's just one problem. This guy doesn't exist. No one with his name has ever worked at Microsoft Research. His job title is fake. Microsoft is not working on a 128-bit kernel for Windows 8. And, best of all, the guy's listed university? It's an "online supplier of academic degrees," according to Wikipedia. OK, that's five problems, or four more than those geniuses on the web should have needed to figure out this rumor was fake. Seriously, you guys make me laugh so hard sometimes I could cry. It's just sad." http://windowsitpro.com/Articles/Index.cfm?ArticleID=102939&feed=rss&subj=0