D
Deleted member 11852
Guest
That was one version of one API. Tossing in new APIs with new versions of an OS is how things has worked for six decades.I was late to this. But sort of a reminder that the move to windows 10 away from 7 was a larger departure than most people believe. A lot of people ragged on MS for locking DX12 onto windows 10. But when they released 12on7 and people tried to play Gears5 it wasn’t nearly working so great.
So heads up there could be a lot of changes under the hood and a lot of legacy I/O stuff can be changed wrt W10. There is a lot of stuff happening with windows at the base level. Windows 10 at launch is a very different Windows 10 as of today’s patch. I’m not sure how much legacy knowledge will continue to apply for come the newer releases that are supposed to be due out this year.
What is the heads up, specifically? I'm looking at roadmaps for the next four planned versions of Windows 10 and there are no changes to the fundamental Windows architecture. You can't just change this without breaking software and hardware which is why these far-horizon tech roadmaps exist. Assuming you're looking a the same roadmap as me - the latest is dated May 3rd, can you tell me change code you think suggests something?
They've managed to implement LZX file compression and Advanced 4Kn (4 KByte native sectors) in Windows 8 withouth throwing anything in the bin, and similarily 2 MB clusters in exFAT and NTFS simply required an updated release of Windows 10.
Now add support for 64 KB sectors (either native or emulated with deep queue 512 Byte I/O requests) and make this the default I/O granularity, and see the disk throughput skyrocket (although this would probably require a CPU with native support for 64 KB virtual memory pages, which is not even announced yet).
These are software changes. Software is easy to change. Inserting a hardware decompressor into the storage-I/O-RAM-CPU/GPU pipeline managed by different kernel drivers is is a different kettle of fish.