4 ms·

Windows Update is based on packages, which can be installed or not installed and depend on other packages and also conflict with packages. Unlike Linux packages

Windows Update is based on packages, which can be installed or not installed and depend on other packages and also conflict with packages. Unlike Linux packages, these packages act more like ... patches, I guess. I think Windows Update spends most of its CPU time on building and solving a big dependency graph.

pbhjpbhj 8y ago
How is that different to apt, it also has to solve dependencies for packages. Using slapt-get (Slackware version of apt-get) back in the day was quite the revelation after manually solving dependencies.
- blattimwind 8y ago
  > How is that different to apt, it also has to solve dependencies for packages. Because it is way more complicated than apt: https://docs.microsoft.com/en-us/windows/deployment/update/how-windows-update-works https://docs.microsoft.com/en-us/windows/deployment/update/h...
  - yjftsjthsd-h 8y ago
    Is that more complicated? There's a lot of dark in there, but the general steps look comparable. And even if they did over engineer it to their own detriment, I'm not sure how that's supposed to give me more sympathy unless are solving problems that other package managers can't handle, which might be true but certainly isn't obvious to me.
    - Someone 8y ago
      I think apt-get installs packages, Windows Update applies patches. In Windows, can have individual updates to a library that fix bugs b1, b2, respectively b3. If so, you can install eight different variants of that library. If, later, a fix for bug b4 is released, its installer must be able to handle each of those variants. The installer also allows you to roll back any of those patches (example: patch b1, patch b3, patch b2, roll back b1, patch b3, patch b1 again) In practice, it’s impossible to handle that combinatorial explosion, so you get updates that require b1 to b3 to be fixed, that require service pack x, etc. However, the system still is designed to handle that. It sort-of must, given that Microsoft occasionally releases updates that it hasn’t tested on all possible hardware configurations, but that (may) solve a specific problem (https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-qfe-ldr-wth/ https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-q... is dated, but, I think, still illustrates the problem)
      - blattimwind 8y ago
        That's my understanding as well. Afaik this is one of the reasons service packs existed, they essentially wrapped a huge number of updates up in one big, complicated blob labelled "this replaces update 329904, 1374663, 3072984, 3979717, ... 7308332, 8042597, 8091796, 9793445 and is applicable to basically all machines", coalescing a big chunk of their dependency tree.
      - pbhjpbhj 8y ago
        So instead of applying patches once (but yes, for each variant) at the server end and simply downloading and writing to disk, they create patches (in as many variations as they'd need libraries) and download those, then add the extra step of using potentially low-powered client processing to apply the patches (as binary diffs?) ... seems like something that would have been faster on a 9600 baud download line, and when server processing was more expensive; but for the last decade or so?
acdha 8y ago
Yeah, and it’s apparently written in VBScript because a new VM’s first update takes many times longer than, say, compiling Firefox from source. If they had an optimization to handle superseded patches it’d shave multiple hours off of that process.
- rincebrain 8y ago
  There are known problems that have been patched [1] causing the insanely long install times we all associate with new Win7 installs. The fact that they didn't have a mechanism to forcibly install said improvement updates in the older versions before they install the kitchen sink for hours is infuriating, but I can't be that annoyed at them for not rewriting history. I can, however, be annoyed that they decided never to formally make an SP2 and consequently left anyone running those Win7 environs up shit creek without a paddle, though I imagine that's a bug not a feature, given how afraid they are of another XP. [1] - https://decentsecurity.com/enterprise/#/windows-7-fast-update/ https://decentsecurity.com/enterprise/#/windows-7-fast-updat...
  - acdha 8y ago
    It’s a little better but fresh Windows 8, 8.1, and 10 VMs still take much, much longer to boot than, say, an equivalent Linux upgrade. It might be less bad than Windows 7 but I’ve never measured it precisely since it’s still in the “come back after a leisurely lunch” range.
craftyguy 8y ago
I don't buy it. I just updated an Arch Linux machine that had been powered off for a while, ~3GB of packages (~200 packages IIRC) were updated (along with new/changed dependencies for some of them) in about 10 minutes, not accounting for download time which is totally dependent upon inet connection speed. During that 10 minutes, my system was 100% usable, and I was able to save all of my work and reboot it at my earliest convenience.
- Marsymars 8y ago
  Anecdotally, I recently updated my Arch VM after about a week of uptime, and it somehow OOM'd mid-kernel update. Guidance online suggested it was technically recoverable, but seemed easier to just blow the unbootable VM away and recreate.
chris_wot 8y ago
It does. A few years ago, I decided to chase down what Windows Update does, so I ran regmon to see what configuration keys it builds in for tracing. Turns out it has a LOT of trace parameters in Windows 7 (and I assume for Windows 10 as well). It basically has tracing for each component.[1] But one component in particular takes a long time - and that component seems to be the one that determines the package dependencies. Honestly, if Microsoft would fix this one thing, I suspect they could speed up their update process by a factor of 2 or 3, possibly higher. As an aside, the Windows Update datastore and the Windows AD datastore must be seriously some of the very last things to use the ESENT. Dunno if Exchange still uses it. Awful way of doing things though. Windows Update is overly complicated and utterly unweildy. My perspective is that it was rather bolted together in the years when Microsoft decided to make the filesystem a database. They now have an inelegant mess that they cannot easily get rid of. I would hate to be someone who had to work on Windows Update code! 1. https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-logs https://docs.microsoft.com/en-us/windows/deployment/update/w...
- buckminster 8y ago
  In Windows 7 I had a look at it in a debugger. It seemed to be doing the topological sort using a dumb bubble sort style algorithm. Once there were enough updates it got really slow really quickly.
  - chris_wot 8y ago
    Oh man, that explains a lot.
  - rincebrain 8y ago
    Yeah, IIRC one of the things they patched in their updates of the WU client was a combinatoric nightmare where it scaled time nonlinearly with the number of other updates. [1] [1] - https://support.microsoft.com/en-us/help/3161647/windows-update-client-for-windows-7-and-windows-server-2008-r2-june-20 https://support.microsoft.com/en-us/help/3161647/windows-upd...

pbhjpbhj 8y ago

How is that different to apt, it also has to solve dependencies for packages. Using slapt-get (Slackware version of apt-get) back in the day was quite the revelation after manually solving dependencies.

blattimwind 8y ago
> How is that different to apt, it also has to solve dependencies for packages. Because it is way more complicated than apt: https://docs.microsoft.com/en-us/windows/deployment/update/how-windows-update-works https://docs.microsoft.com/en-us/windows/deployment/update/h...
- yjftsjthsd-h 8y ago
  Is that more complicated? There's a lot of dark in there, but the general steps look comparable. And even if they did over engineer it to their own detriment, I'm not sure how that's supposed to give me more sympathy unless are solving problems that other package managers can't handle, which might be true but certainly isn't obvious to me.
  - Someone 8y ago
    I think apt-get installs packages, Windows Update applies patches. In Windows, can have individual updates to a library that fix bugs b1, b2, respectively b3. If so, you can install eight different variants of that library. If, later, a fix for bug b4 is released, its installer must be able to handle each of those variants. The installer also allows you to roll back any of those patches (example: patch b1, patch b3, patch b2, roll back b1, patch b3, patch b1 again) In practice, it’s impossible to handle that combinatorial explosion, so you get updates that require b1 to b3 to be fixed, that require service pack x, etc. However, the system still is designed to handle that. It sort-of must, given that Microsoft occasionally releases updates that it hasn’t tested on all possible hardware configurations, but that (may) solve a specific problem (https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-qfe-ldr-wth/ https://blogs.technet.microsoft.com/mrsnrub/2009/05/14/gdr-q... is dated, but, I think, still illustrates the problem)
    - blattimwind 8y ago
      That's my understanding as well. Afaik this is one of the reasons service packs existed, they essentially wrapped a huge number of updates up in one big, complicated blob labelled "this replaces update 329904, 1374663, 3072984, 3979717, ... 7308332, 8042597, 8091796, 9793445 and is applicable to basically all machines", coalescing a big chunk of their dependency tree.
    - pbhjpbhj 8y ago
      So instead of applying patches once (but yes, for each variant) at the server end and simply downloading and writing to disk, they create patches (in as many variations as they'd need libraries) and download those, then add the extra step of using potentially low-powered client processing to apply the patches (as binary diffs?) ... seems like something that would have been faster on a 9600 baud download line, and when server processing was more expensive; but for the last decade or so?

acdha 8y ago

Yeah, and it’s apparently written in VBScript because a new VM’s first update takes many times longer than, say, compiling Firefox from source. If they had an optimization to handle superseded patches it’d shave multiple hours off of that process.

rincebrain 8y ago
There are known problems that have been patched [1] causing the insanely long install times we all associate with new Win7 installs. The fact that they didn't have a mechanism to forcibly install said improvement updates in the older versions before they install the kitchen sink for hours is infuriating, but I can't be that annoyed at them for not rewriting history. I can, however, be annoyed that they decided never to formally make an SP2 and consequently left anyone running those Win7 environs up shit creek without a paddle, though I imagine that's a bug not a feature, given how afraid they are of another XP. [1] - https://decentsecurity.com/enterprise/#/windows-7-fast-update/ https://decentsecurity.com/enterprise/#/windows-7-fast-updat...
- acdha 8y ago
  It’s a little better but fresh Windows 8, 8.1, and 10 VMs still take much, much longer to boot than, say, an equivalent Linux upgrade. It might be less bad than Windows 7 but I’ve never measured it precisely since it’s still in the “come back after a leisurely lunch” range.

craftyguy 8y ago

I don't buy it. I just updated an Arch Linux machine that had been powered off for a while, ~3GB of packages (~200 packages IIRC) were updated (along with new/changed dependencies for some of them) in about 10 minutes, not accounting for download time which is totally dependent upon inet connection speed. During that 10 minutes, my system was 100% usable, and I was able to save all of my work and reboot it at my earliest convenience.

Marsymars 8y ago
Anecdotally, I recently updated my Arch VM after about a week of uptime, and it somehow OOM'd mid-kernel update. Guidance online suggested it was technically recoverable, but seemed easier to just blow the unbootable VM away and recreate.

chris_wot 8y ago

It does. A few years ago, I decided to chase down what Windows Update does, so I ran regmon to see what configuration keys it builds in for tracing. Turns out it has a LOT of trace parameters in Windows 7 (and I assume for Windows 10 as well). It basically has tracing for each component.[1] But one component in particular takes a long time - and that component seems to be the one that determines the package dependencies. Honestly, if Microsoft would fix this one thing, I suspect they could speed up their update process by a factor of 2 or 3, possibly higher. As an aside, the Windows Update datastore and the Windows AD datastore must be seriously some of the very last things to use the ESENT. Dunno if Exchange still uses it. Awful way of doing things though. Windows Update is overly complicated and utterly unweildy. My perspective is that it was rather bolted together in the years when Microsoft decided to make the filesystem a database. They now have an inelegant mess that they cannot easily get rid of. I would hate to be someone who had to work on Windows Update code! 1. https://docs.microsoft.com/en-us/windows/deployment/update/windows-update-logs https://docs.microsoft.com/en-us/windows/deployment/update/w...

buckminster 8y ago
In Windows 7 I had a look at it in a debugger. It seemed to be doing the topological sort using a dumb bubble sort style algorithm. Once there were enough updates it got really slow really quickly.
- chris_wot 8y ago
  Oh man, that explains a lot.
- rincebrain 8y ago
  Yeah, IIRC one of the things they patched in their updates of the WU client was a combinatoric nightmare where it scaled time nonlinearly with the number of other updates. [1] [1] - https://support.microsoft.com/en-us/help/3161647/windows-update-client-for-windows-7-and-windows-server-2008-r2-june-20 https://support.microsoft.com/en-us/help/3161647/windows-upd...