This update is basically the same as what a new build would have been if released. It's why for Redstone 2 we'll likely see the occasional full build, with build equivalent updates like these in between to replace only those files changed since the last build. The only difference between a full build and update changes is that unchanged files still get a build bump. Resolved issues (this may not be all fixes, Microsoft have never released a complete changelog at least for major updates): We have fixed an issue where keyboard input on some Windows tablet devices would not rotate to landscape normally. [*]We have fixed an issue that results in Windows Updates being delayed on systems with Connected Standby. [*]We have fixed a problem with text input with Korean Input Method Editor (IME) in some Store apps. [*]We fixed an issue causing Store apps to stop launching due to a licensing issue. [*]We have fixed an issue with apps that synchronize using DDE for inter-process communication. Updated component descriptions: DAM Kernel Driver [*]DirectX Kernel, DirectX Graphics MMS, Canonical Display Driver [*]Microsoft Connection Manager Profile Installer [*]Store License Manager [*]MSCTF Server DLL [*]Multi-User Windows USER API Client DLL [*]Powershell Workflow Servicecore [*]Win32 Cabinet Self-Extractor
that display driver update explains the crashing bugs i contacted both nvidiot and amd to release a update soon
Yes, the DirectX and GDI related fixes seem to be one of the things they left off the list. The list is basically just a summary of the issues resolves, I'm sure if they released a commitlog like you see through projects on GIT it would be quite long!
As I mentioned, just because it isn't on the list it doesn't mean the issue hasn't been resolved. The updating of those graphics components don't seem to correspond to the fixes they listed, so I presume it is to fix something else. I think you'll find the list of changes that they will release with RS1 will seem quite minor compared to the actual changes they've done. The list is merely a key summary, not a commitlog listing.
I'm confused, new build, new feature that works. This update fixed features that did not work, what am I missing?
it still breaks my work so until the next driver release for amd or nvidiot the crashes in display drivers are bad and can hurt what im working on
Not necesarily. The reason why builds typically had changed features etc is because those changes just happened to be ready at the time. Even in the cases of bug fixes etc, we got new builds that may not have had new features, like recently. You have to consider that earlier in the development process of Windows 10 insider, TH2 insider, and RS1 insider, is that there were extended periods at times between builds. This meant that by the time the new builds came out, there just had naturally been changes as part of the natural development of the OS. New features can very easily be accommodated in an update, not a build, seeing as features relate to a specific element of the OS. Thefore, only the files related to that specific element, and from those only the files containing the feature related code, need to be changed. In the development cycle of the builds there are only a limited number of changes each time, just over time they accumulate such that by the time we got a new build the list had grown and the number of files changed was large. You would probably find the number of actual files changes between build 14390 and 14393 would be quite limited. This update .cab is 7.8 MB for x64. The equivalent cab for actual code changed files files between 14390 and 14393 would probably not be much larger. Even if it were a large change and 100 MB, it's hardly the 3 GB we see on each new build. In fact, if we were to receive the .esd as a .cab instead, if it included all the files it would be significantly larger. The main differences between a build and an update is that the other files don't get a build bump. Such is the nature of the updates that Microsoft did mention they were looking at just releasing new 'builds' as updates for the RS2 testing. This would actually be better because you only receive the changed files, not needlessly the whole lot. Also it would install as an update, not a refresh like builds have done so, so far. There would still be full releases, initially (of course), then every couple of months or whenever they see the number of changes in the update files as large enough to warrant it. No point downling a 2 GB cab for example! The added benefit of this method is that changes could be more frequent, at least when compared to the average of what we've seen prior to the last few weeks. There would still be the internal test cycles etc, but at least an update once a week is managable. A complete new build every week gets a bit much, takes time to install, creates wear on a SSD, fills the drives with the junk backup files (rollbacks can still be done with the update, you simply uninstall it!), and creates extra server load. Quite silly when you consider that only say, from week to week, only a couple of percent of a total build download file size has actually undergone code change. I should point out Microsoft were only looking into that, it might not eventuate, or it might not occur straight away for RS2.
Have they actually said that? I've watched that "Windows Weekly" video with Dona at PDC where she mentioned that they're looking into making distribution more efficient, but the idea I got was that they're going to make the actual transfer of those builds more efficient, not that they're going to stop with the model of delivering full builds as in-place upgrades. After all they'll still have to do full builds of the mainline branch as part of the development process, and it only makes sense to have testers run those exact same builds, not separately updated components.
Since the "in-place upgrade" mechanism is integral to the whole process, it would not make sense to remove it from insider testing. That being said, I now expect the unexpected.
Even if they did have the changes distributed in an update each week there will still be the builds where the full process can be tested. Having a new complete builds each time to test this, especially in the early stages, isn't as beneficial as you may think. Having a full build once a month for this testing and cumulative update released every week would strike a nice balance with keeping insiders up to date so they can report any issues, give feedback etc, and not putting people off from participating in the Insider programme due to having to install a new build all the time. When RS2 reaches close to RTM a new build could be released each week, and maybe with an interim update. Two complete builds a week is also a little tedious like recently, I feel a once a week build release and an interim update would strike a much better balance (when close to RTM) and still allows for the install testing with each weekly build, and monthly build earlier on.
have you been an insider till this clean install ? did you quit , which version infos does it show now ?