9 ms·

Windows has a real problem with huge monolithic dlls that inexplicably pull in other huge monolithic dlls. Especially when each dllmain() has its own weird sid

Windows has a real problem with huge monolithic dlls that inexplicably pull in other huge monolithic dlls. Especially when each dllmain() has its own weird side effects. It leads to bizarre behavior all the time such as this. The weirdest thing that ever happened to me was when Visual Studio 2012 hung in the installer. After debugging with an older VS, it turned out the installer rendered some progress bar with Silverlight, which was hung on audio initialization, which was hung on a file system driver, which was hung on a shitty Apple-provided HFS driver. Uninstalling HFS fixed the installer. Why does an installer even need audio when it never played sound? Because Microsoft dependencies are fucked.

agumonkey 8y ago
It's a mystery how MS manages to exist. Or maybe it's just consumer market emergent chaos mastery.
userbinator 8y ago
Getting even more to the point: why does an installer even need to use Silverlight to render a progress bar!?!? As far as I know, these things have been there since 16-bit Windows and continue to work fine in Win10: https://docs.microsoft.com/en-us/windows/desktop/controls/progress-bar-control https://docs.microsoft.com/en-us/windows/desktop/controls/pr...
- jcelerier 8y ago
  > continue to work fine in Win10: putting the head in the sand like this won't make the problem go away. UX designers demand stuff that is smoother than win32 progress bars, that has spline-interpolation-like behaviour with some nice little tween at the end when going to the next page, with varying smooth color gradients all over the place. go make this UI with pure Win32 primitives : https://youtu.be/v0GG8uh80V4?t=158 https://youtu.be/v0GG8uh80V4?t=158
  - rkagerer 8y ago
    I hate animations like that. All they do is distract me, waste my time while I'm waiting to see and interact with the next thing, and move my target out from under me while I'm trying to go click it. I always turn off all the animation settings right out of the box. I wouldn't be surprised if one day soon this fad gives way back to a renaissance of clean, simple, instant UI's and everyone will feel like their devices got a lot snappier.
    - phailhaus 8y ago
      > I wouldn't be surprised if one day soon this fad gives way back to a renaissance of clean, simple, instant UI's and everyone will feel like their devices got a lot snappier. No, don't think so. Instant UI's are disorienting because there's no visual cue for what is about to happen, and they don't give your brain an intuition as to how the interface behaves (e.g. a sidebar slides in from the side rather than the top). We're used to instant UI's because we've learned the patterns over time, but they're very unnatural to new/ocassional users. Some interfaces overdo the animation timing though, they can be very fast and still give users enough of a cue to understand what happened.
      - Retric 8y ago
        Animations that change colors within a narrow range are fine, moving UI elements around is a huge anti pattern that annoys users without any benifits. It’s the same issue as flat buttons, users need to know what’s clickable, and what has been clicked. They don’t need shading etc, but feedback has masssive utility. Sadly, our field generally lacks the kind of real feedback that corrects such incompetence.
        phailhaus 8y ago
        > moving UI elements around is a huge anti pattern that annoys users without any benifits. Still disagree, and I think you're thinking of really obnoxious examples. I'm imagining about a ~150ms animation for the following: 1. A sidebar sliding out from the side 2. Dialogs swooping in and out from the top of the screen 3. Form panes sliding out when replaced These quick, almost-no-time visual cues are incredibly important at giving your interface a sense of presence and physicality. Without them, your UI elements are flickering in and out of existence without any perceivable reason, and can often leave the user wondering what changed.
phaedrus 8y ago
Granted Microsoft sets a particularly egregious example here, but the way we (don't) track dependencies is f'ed up across the whole software industry. It should be (nay, needs to be) possible - in an automated way, with a visual UI - to see a piece of software as a cloud of features and click and drag away or cut+paste and get JUST the parts of the code the feature ACTUALLY requires. Yes, like dependency inversion, but I'm talking about all the way down to the assembly instructions level. Before you object that that's just not possible: yes, but only because we've already scrambled the eggs and can't unscramble them. The problem is the way we develop(ed) the whole stack (down to the assembly language and kernel calls level) is bass ackwards. Consider that the foundations of how everything is organized (vis a vis dependency injection or lack thereof in low level libraries) dates back to a time when computers were many orders of magnitude smaller and you were expected to have a good idea what was in the libraries you included. Now, the situation is reversed - you have no idea what's in the libraries you include and no idea what they include, etc. But we still program as if it should be the responsibility of the user to understand the library / program and what it uses transitively.
- tenaciousDaniel 8y ago
  > a visual UI to see a piece of software as a cloud of features and ... get just the parts of the code the feature actually requires oooohhh I love that idea. I wonder if this could be utilized for npm.
  - fit2rule 8y ago
    I'm seeing it being at least a bit feasible with package managers that allow the ability to config/build packages and install them locally according to needs by the developer .. something like Gobolinux with its bundle garden, combined with a configuration-management tool that can build every package with every possible configuration .. Bit of a goose, though. As in, not sure it'll fly in its current (scrambled eggs) state. Perhaps a rewrite is really what's needed .. or maybe HaikuOS can deliver this without much ruffling of feathers?
    - 8y ago
juliangoldsmith 8y ago
I've never gotten the hate for static linking, which would avoid issues like this. You'd always have the version of your dependencies that you're expecting. Also, dynamic linking completely neuters LTO. There's not much point to (theoretically) saving a few megabytes of RAM when you're pulling in twice as much unused code.
- pathseeker 8y ago
  >I've never gotten the hate for static linking vulnerabilities
  - DrScientist 8y ago
    Sure - but most computers are used by people who are the sole user, so local user to user security as a concept isn't useful. Most code isn't part of the remote attack surface. Also there would be no software bugs if bugs only existed in the past... ie bugs come with updates, not just fixed by updates. There are trade offs, and Linux developers decided to make it what was easiest for them and remove the ability for the user to choose. If there wasn't a need for stability and isolation then docker et al wouldn't exist.
  - juliangoldsmith 8y ago
    Based on what cesarb said, that's a problem with the build system.
- cesarb 8y ago
  > I've never gotten the hate for static linking I believe most of the dislike for static linking can be traced to a single incident: a really bad (as in "remote code execution" bad) vulnerability in zlib, CVE-2002-0059. Back then, it was common to statically link to zlib (and zlib is a very popular library, the DEFLATE algorithm it implements being the "standard" compression algorithm), so instead of just replacing a single dynamic library and rebooting, everything had to be audited for the presence of embedded copies of zlib. Quoting from a message from a few years later (http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html http://mail.openjdk.java.net/pipermail/build-dev/2007-May/00...): "[...] Updating the main system zlib package was easy, but finding all the embedded copies was a nightmare. I think we ended up grepping every binary and library in every package for symbols and other bits of code that looked like zlib. All the different versions involved compounded this. And when everything is found and patched and built and tested there's the cost of bandwidth to distribute all the extra stuff. So when people talk of removing static libraries they're talking about real costs -- time and money. After zlib there was a definite feeling of "never again"."
MagicPropmaker 8y ago
There's also the problem that Apple refuses to write decent software or follow the rules on Windows (which is why your Apple HFS driver failed.) Microsoft, on the other hand, writes some of the best MacOS and iOS software.
- goalieca 8y ago
  Wait, so an IDE installer pulling in a web framework for .net that initializes an audio driver that requires HFS all So that a progress bar can be better than their own native one (pick an API whether wpf, win32, ...) one is somehow not Microsoft’s fault to some degree? I find it really hard to believe they write some of the best iOS/ macOS software if they release this shit on windows.
eridius 8y ago
What was the HFS driver hung on?

agumonkey 8y ago

It's a mystery how MS manages to exist. Or maybe it's just consumer market emergent chaos mastery.

userbinator 8y ago

Getting even more to the point: why does an installer even need to use Silverlight to render a progress bar!?!? As far as I know, these things have been there since 16-bit Windows and continue to work fine in Win10: https://docs.microsoft.com/en-us/windows/desktop/controls/progress-bar-control https://docs.microsoft.com/en-us/windows/desktop/controls/pr...

jcelerier 8y ago
> continue to work fine in Win10: putting the head in the sand like this won't make the problem go away. UX designers demand stuff that is smoother than win32 progress bars, that has spline-interpolation-like behaviour with some nice little tween at the end when going to the next page, with varying smooth color gradients all over the place. go make this UI with pure Win32 primitives : https://youtu.be/v0GG8uh80V4?t=158 https://youtu.be/v0GG8uh80V4?t=158
- rkagerer 8y ago
  I hate animations like that. All they do is distract me, waste my time while I'm waiting to see and interact with the next thing, and move my target out from under me while I'm trying to go click it. I always turn off all the animation settings right out of the box. I wouldn't be surprised if one day soon this fad gives way back to a renaissance of clean, simple, instant UI's and everyone will feel like their devices got a lot snappier.
  - phailhaus 8y ago
    > I wouldn't be surprised if one day soon this fad gives way back to a renaissance of clean, simple, instant UI's and everyone will feel like their devices got a lot snappier. No, don't think so. Instant UI's are disorienting because there's no visual cue for what is about to happen, and they don't give your brain an intuition as to how the interface behaves (e.g. a sidebar slides in from the side rather than the top). We're used to instant UI's because we've learned the patterns over time, but they're very unnatural to new/ocassional users. Some interfaces overdo the animation timing though, they can be very fast and still give users enough of a cue to understand what happened.
    - Retric 8y ago
      Animations that change colors within a narrow range are fine, moving UI elements around is a huge anti pattern that annoys users without any benifits. It’s the same issue as flat buttons, users need to know what’s clickable, and what has been clicked. They don’t need shading etc, but feedback has masssive utility. Sadly, our field generally lacks the kind of real feedback that corrects such incompetence.
      - phailhaus 8y ago
        > moving UI elements around is a huge anti pattern that annoys users without any benifits. Still disagree, and I think you're thinking of really obnoxious examples. I'm imagining about a ~150ms animation for the following: 1. A sidebar sliding out from the side 2. Dialogs swooping in and out from the top of the screen 3. Form panes sliding out when replaced These quick, almost-no-time visual cues are incredibly important at giving your interface a sense of presence and physicality. Without them, your UI elements are flickering in and out of existence without any perceivable reason, and can often leave the user wondering what changed.

phaedrus 8y ago

Granted Microsoft sets a particularly egregious example here, but the way we (don't) track dependencies is f'ed up across the whole software industry. It should be (nay, needs to be) possible - in an automated way, with a visual UI - to see a piece of software as a cloud of features and click and drag away or cut+paste and get JUST the parts of the code the feature ACTUALLY requires. Yes, like dependency inversion, but I'm talking about all the way down to the assembly instructions level. Before you object that that's just not possible: yes, but only because we've already scrambled the eggs and can't unscramble them. The problem is the way we develop(ed) the whole stack (down to the assembly language and kernel calls level) is bass ackwards. Consider that the foundations of how everything is organized (vis a vis dependency injection or lack thereof in low level libraries) dates back to a time when computers were many orders of magnitude smaller and you were expected to have a good idea what was in the libraries you included. Now, the situation is reversed - you have no idea what's in the libraries you include and no idea what they include, etc. But we still program as if it should be the responsibility of the user to understand the library / program and what it uses transitively.

tenaciousDaniel 8y ago
> a visual UI to see a piece of software as a cloud of features and ... get just the parts of the code the feature actually requires oooohhh I love that idea. I wonder if this could be utilized for npm.
- fit2rule 8y ago
  I'm seeing it being at least a bit feasible with package managers that allow the ability to config/build packages and install them locally according to needs by the developer .. something like Gobolinux with its bundle garden, combined with a configuration-management tool that can build every package with every possible configuration .. Bit of a goose, though. As in, not sure it'll fly in its current (scrambled eggs) state. Perhaps a rewrite is really what's needed .. or maybe HaikuOS can deliver this without much ruffling of feathers?
  - 8y ago

juliangoldsmith 8y ago

I've never gotten the hate for static linking, which would avoid issues like this. You'd always have the version of your dependencies that you're expecting. Also, dynamic linking completely neuters LTO. There's not much point to (theoretically) saving a few megabytes of RAM when you're pulling in twice as much unused code.

pathseeker 8y ago
>I've never gotten the hate for static linking vulnerabilities
- DrScientist 8y ago
  Sure - but most computers are used by people who are the sole user, so local user to user security as a concept isn't useful. Most code isn't part of the remote attack surface. Also there would be no software bugs if bugs only existed in the past... ie bugs come with updates, not just fixed by updates. There are trade offs, and Linux developers decided to make it what was easiest for them and remove the ability for the user to choose. If there wasn't a need for stability and isolation then docker et al wouldn't exist.
- juliangoldsmith 8y ago
  Based on what cesarb said, that's a problem with the build system.
cesarb 8y ago
> I've never gotten the hate for static linking I believe most of the dislike for static linking can be traced to a single incident: a really bad (as in "remote code execution" bad) vulnerability in zlib, CVE-2002-0059. Back then, it was common to statically link to zlib (and zlib is a very popular library, the DEFLATE algorithm it implements being the "standard" compression algorithm), so instead of just replacing a single dynamic library and rebooting, everything had to be audited for the presence of embedded copies of zlib. Quoting from a message from a few years later (http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000055.html http://mail.openjdk.java.net/pipermail/build-dev/2007-May/00...): "[...] Updating the main system zlib package was easy, but finding all the embedded copies was a nightmare. I think we ended up grepping every binary and library in every package for symbols and other bits of code that looked like zlib. All the different versions involved compounded this. And when everything is found and patched and built and tested there's the cost of bandwidth to distribute all the extra stuff. So when people talk of removing static libraries they're talking about real costs -- time and money. After zlib there was a definite feeling of "never again"."

MagicPropmaker 8y ago

There's also the problem that Apple refuses to write decent software or follow the rules on Windows (which is why your Apple HFS driver failed.) Microsoft, on the other hand, writes some of the best MacOS and iOS software.

goalieca 8y ago
Wait, so an IDE installer pulling in a web framework for .net that initializes an audio driver that requires HFS all So that a progress bar can be better than their own native one (pick an API whether wpf, win32, ...) one is somehow not Microsoft’s fault to some degree? I find it really hard to believe they write some of the best iOS/ macOS software if they release this shit on windows.

eridius 8y ago

What was the HFS driver hung on?