3 ms·

>everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade Now, you are being plain funny. Haven't you heard

>everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade Now, you are being plain funny. Haven't you heard of 'DLL Hell' in Windows platform?. You never had 'windows update' break your software for no reason?

muuh-gnu 15y ago
I've never had to upgrade Windows (including all installed apps) to be able to install some other random app. On Linux, having to upgrade the distro (including getting a new desktop environment force-installed) to get a new version of any random app is established practice. Example: http://esr.ibiblio.org/?p=3822 http://esr.ibiblio.org/?p=3822
- acqq 15y ago
  If you claim that you "never had to upgrade Windows to be able to install some other random app" you probably haven't used Windows much then. There are games that need explicit version or newer of DirectX. You can't even produce from the C or C++ sources the binary application that runs on any Windows XP with the latest Visual Studio (11). Any C/C++ application built with Visual Studio 2010 won't run on Windows 2000 or XP prior to SP3. We developers try to build the applications that run on as many targets as possible, but even MSFT doesn't support us enough for that, seeing the older versions as the competition to their newest "shiny thing." Which is not funny considering millions and millions of users still running Windows XP. See the various opinions on MSFT intentionally removing the binary compatibility which already existed in their libraries here: http://news.ycombinator.com/item?id=3648209 http://news.ycombinator.com/item?id=3648209
  - doug11235 15y ago
    > Any C/C++ application built with Visual Studio 2010 won't run on Windows 2000 or XP prior to SP3. By default you can't but you can adjust the build settings and it works fine.
  - hythloday 15y ago
    Do you happen to know how many users are running Windows < XP/SP3? For our install base (games company) it's less than 1%. Is there a compelling reason not to upgrade to SP3 if you're on XP?
- icebraining 15y ago
  Then you're lucky, because plenty of applications required you to install the Service Pack 2 on XP to install them, .NET application often required newer versions, same with games and DirectX, etc.
- MatthewPhillips 15y ago
  Dependencies are bundled on Windows. It means installing App B doesn't affect your App A. It also means that security bugs must be fixed at the app level, not at the library or OS level.
- rbanffy 15y ago
  Not entirely true. While Microsoft won't upgrade your Windows for free (creating the demand for support for ancient versions of the OS - things that will run on XP) they will make software dependent on service packs and fixes. It's not a new version with new functionality, but it's an upgrade nonetheless.
saurik 15y ago
You are using this term incorrectly: the cause of DLL Hell is when one DLL (often a newer one) should be used, but another is used instead (even if it is older). The causes of this were varied. On 16-bit Windows there was a single address space and only a single version of a DLL could be loaded by all processes: the first one to load would "win", and the others would get screwed with the old copy. This was due to 16-bit Windows not having memory protection: it was more of a GUI over DOS, and thereby had cooperative multi-tasking. Even with that fixed, many developers would require a slightly newer version of a library, and rather than ask the user to upgrade their system (an irritating consequence of not having packages or dependencies; APT FTW ;P) would just include the DLL in their installer and unconditionally overwrite any existing copy. After the dynamic loader started supporting "local" versions of libraries (installed to the same folder as the application), a similar problem happened with COM objects, which are centrally registered: someone would install their own version of a shared GUI component, register it with the shared name, overwriting possibly-installed newer copies. Both of these problems were actually solved, but way too many developers simply gave up on Microsoft and Windows beforehand, and then refuse to spend the time to learn about the improvements. In essence, Windows now has reasonable-ish package management, with dependencies: Windows Installer. In addition to dependencies and versioning of packages (which can then be correctly tracked by Windows, much like APT on a Debian/Ubuntu box), Windows Installer supports the notion of "unified installer program" with "merge modules": in essence, you can include someone else's package inside of your package; that way the dependencies can correctly be checked, and old versions won't get overwritten. There are still a few cases that are quite difficult to manage (involving libraries that require a modified ABI over time, but still receive updates), and Microsoft's solution to those is WinSxS. Honestly, while I'm much less familiar with it than on Unix, it only seems a constant multiple more crazy than .la files, which I believe solve a similar problem. These technologies and improvements were all introduced at or before Windows XP, an operating system that was released just over a decade ago. Of course, these are all solutions that developers sometimes ignore, but if you download software for Linux that comes with a .sh installer that scribbles into /lib, you are in for similar "hell".

muuh-gnu 15y ago

I've never had to upgrade Windows (including all installed apps) to be able to install some other random app. On Linux, having to upgrade the distro (including getting a new desktop environment force-installed) to get a new version of any random app is established practice. Example: http://esr.ibiblio.org/?p=3822 http://esr.ibiblio.org/?p=3822

acqq 15y ago
If you claim that you "never had to upgrade Windows to be able to install some other random app" you probably haven't used Windows much then. There are games that need explicit version or newer of DirectX. You can't even produce from the C or C++ sources the binary application that runs on any Windows XP with the latest Visual Studio (11). Any C/C++ application built with Visual Studio 2010 won't run on Windows 2000 or XP prior to SP3. We developers try to build the applications that run on as many targets as possible, but even MSFT doesn't support us enough for that, seeing the older versions as the competition to their newest "shiny thing." Which is not funny considering millions and millions of users still running Windows XP. See the various opinions on MSFT intentionally removing the binary compatibility which already existed in their libraries here: http://news.ycombinator.com/item?id=3648209 http://news.ycombinator.com/item?id=3648209
- doug11235 15y ago
  > Any C/C++ application built with Visual Studio 2010 won't run on Windows 2000 or XP prior to SP3. By default you can't but you can adjust the build settings and it works fine.
- hythloday 15y ago
  Do you happen to know how many users are running Windows < XP/SP3? For our install base (games company) it's less than 1%. Is there a compelling reason not to upgrade to SP3 if you're on XP?
icebraining 15y ago
Then you're lucky, because plenty of applications required you to install the Service Pack 2 on XP to install them, .NET application often required newer versions, same with games and DirectX, etc.
MatthewPhillips 15y ago
Dependencies are bundled on Windows. It means installing App B doesn't affect your App A. It also means that security bugs must be fixed at the app level, not at the library or OS level.
rbanffy 15y ago
Not entirely true. While Microsoft won't upgrade your Windows for free (creating the demand for support for ancient versions of the OS - things that will run on XP) they will make software dependent on service packs and fixes. It's not a new version with new functionality, but it's an upgrade nonetheless.

saurik 15y ago

You are using this term incorrectly: the cause of DLL Hell is when one DLL (often a newer one) should be used, but another is used instead (even if it is older). The causes of this were varied. On 16-bit Windows there was a single address space and only a single version of a DLL could be loaded by all processes: the first one to load would "win", and the others would get screwed with the old copy. This was due to 16-bit Windows not having memory protection: it was more of a GUI over DOS, and thereby had cooperative multi-tasking. Even with that fixed, many developers would require a slightly newer version of a library, and rather than ask the user to upgrade their system (an irritating consequence of not having packages or dependencies; APT FTW ;P) would just include the DLL in their installer and unconditionally overwrite any existing copy. After the dynamic loader started supporting "local" versions of libraries (installed to the same folder as the application), a similar problem happened with COM objects, which are centrally registered: someone would install their own version of a shared GUI component, register it with the shared name, overwriting possibly-installed newer copies. Both of these problems were actually solved, but way too many developers simply gave up on Microsoft and Windows beforehand, and then refuse to spend the time to learn about the improvements. In essence, Windows now has reasonable-ish package management, with dependencies: Windows Installer. In addition to dependencies and versioning of packages (which can then be correctly tracked by Windows, much like APT on a Debian/Ubuntu box), Windows Installer supports the notion of "unified installer program" with "merge modules": in essence, you can include someone else's package inside of your package; that way the dependencies can correctly be checked, and old versions won't get overwritten. There are still a few cases that are quite difficult to manage (involving libraries that require a modified ABI over time, but still receive updates), and Microsoft's solution to those is WinSxS. Honestly, while I'm much less familiar with it than on Unix, it only seems a constant multiple more crazy than .la files, which I believe solve a similar problem. These technologies and improvements were all introduced at or before Windows XP, an operating system that was released just over a decade ago. Of course, these are all solutions that developers sometimes ignore, but if you download software for Linux that comes with a .sh installer that scribbles into /lib, you are in for similar "hell".