Well the problem seems to be that Windows will load DLL files from the same directory that the executable is in by default, and this behaviour is retained for backwards compatibility because a lot of programs expect to work this way...
This is yet another case of a serious design flaw in windows which causes ongoing security problems, and cannot be easily fixed without breaking compatibility and/or extra humps for users or developers to jump through.
This is exploitable by preloading a user's downloads directory with malicious dll files and then waiting for them to download and execute a binary installer from the same downloads directory. Which brings up other windows flaws, installers are usually executable binaries rather than a data file to be processed by a package manager (yes there is msi but it isn't commonly used)... Plus the fact that users commonly install software this way rather than going through a repository.
Other systems simply don't work this way... Libraries are never loaded from the current directory by default, applications on unix systems are usually expected to use system versions of libraries rather than bundling their own, and applications on osx are bundled up with their own libs if required. Linux users typically don't download and run arbitrary binaries, instead they select software from their repo.
This now seems to be another extra hoop that developers must jump through to make windows software, hassle that simply doesn't exist on any other platform.