aehimself 396 Posted December 16, 2022 On 12/15/2022 at 4:12 PM, Fr0sT.Brutal said: I was sure the manner of trashing Windows folder with 3rd party libs have gone long ago. There's more than enough trash there already even at a clean installation so it doesn't really count 🙂  Anyway, it's the easiest solution to support all your 32 and 64 bit apps with everything they might need. After all, Microsoft is doing the same with msvcr*.dlls-s when you install the runtime... 1 Share this post Link to post
Fr0sT.Brutal 900 Posted December 19, 2022 On 12/16/2022 at 7:08 PM, aehimself said: There's more than enough trash there already even at a clean installation so it doesn't really count 🙂  Anyway, it's the easiest solution to support all your 32 and 64 bit apps with everything they might need. After all, Microsoft is doing the same with msvcr*.dlls-s when you install the runtime... That's religious question and so discussions are useless. There are pro's and contra's for both options, however I'm the fan of portable self-sufficient apps personally 1 Share this post Link to post
aehimself 396 Posted December 19, 2022 21 minutes ago, Fr0sT.Brutal said: That's religious question and so discussions are useless. There are pro's and contra's for both options, however I'm the fan of portable self-sufficient apps personally I completely agree with you there. However, I dislike redundancy. if you have 3 portable 32 bit and 2 portable 64 bit programs using libmysql.dll to connect to a database I'd find it wasteful and harder to maintain in case you are updating the client library.  But as you said - it all comes down to user preferences. Share this post Link to post
Fr0sT.Brutal 900 Posted December 19, 2022 1 hour ago, aehimself said: harder to maintain in case you are updating the client library Updating a library used by some 3rd party software mostly turns out to be bad idea. In theory this should allow getting updates and patches independently from vendor but in fact libs tend to ignore backward compatibility (not saying any names but it is you, OpenSSL). And a host app could be using some quirks that become non-actual in newer lib versions. So this is the highway to DLL hell. Look at MSVCR, you have to keep all major versions of this crap just to run a wide range of software. Share this post Link to post
aehimself 396 Posted December 19, 2022 3 minutes ago, Fr0sT.Brutal said: Updating a library used by some 3rd party software mostly turns out to be bad idea. Again - you are correct but only if said library is redistributed with a software. For example, libmysql and oci is not allowing this (libmariadb might but I never read their EULA) and Oracle is notorious of shipping faulty software. Therefore, I'd update them at all places even if I have issues in only one software.  LibSSL is also a good example from this perspective. If a serious security flaw is found, it's easier to update only 2 files per architecture than scanning your entire drive. Share this post Link to post
miab 25 Posted December 19, 2022 Installation in System32 and SysWow64 is convenient for the developer, but for the end user I would rather provide a version with libraries in the application directory. Share this post Link to post