Do not put common DLLs in the same directory as the executable

[friedlinguini]

Feature already in Vim?

No response

Feature description

I recently tried to upgrade Neovim on Windows (via Chocolatey), but the upgrade script was unable to delete some libraries, including libEGL.dll, libGLESv2.dll, and some others. It turned out that these were being kept open by another application.

My guess is that because nvim.exe is in the system path, the other application was trying to use similar libraries (my suspicion is because it was using Qt5), found these libraries on the system path, and held them open. While the other application is the main culprit (I've filed a bug with them as well), keeping local copies of these DLLs in a different directory off the system path is probably wise.

[justinmk]

keeping local copies of these DLLs in a different directory off the system path is probably wise.

is this a change we need to make in our MSI / WIX installer ? @3N4N

[3N4N]

keeping local copies of these DLLs in a different directory off the system path is probably wise.

is this a change we need to make in our MSI / WIX installer ?

I don't know. I'll see if I can find the answer. On a related note, there is an open ticket #14552 for possibly removing nvim-qt. If that's done, neovim won't need these DLLs (they're all dependencies of nvim-qt), making this current ticket unnecessary.

[3N4N]

keeping local copies of these DLLs in a different directory off the system path is probably wise.

is this a change we need to make in our MSI / WIX installer ?

I forgot to check back in. My findings can be summarized as this: if the DLLs are not in the same folder as nvim.exe or in the $PATH, then nvim won't be able to find those DLLs either. I may be wrong; read and experiment this doc for more confidence.

In short: the issue cannot be fixed in the way the ticket title suggests. Other ways may be effective (e.g., not putting nvim's bin folder in $PATH), but that's more of a how-to-use-Windows question than a how-to-use-neovim question.

I think we can close this.

[friedlinguini]

You can't LoadLibrary the relevant DLLs? Or link the libraries to nvim-qt.exe statically?

IIRC, the Chocolatey installer is what put nvim.exe on the path, so implying that I'm using Windows wrong by following the installer directions on the neovim site is a bit disingenuous. Given that nvim.exe is a console application, saying that it shouldn't be on the path makes it difficult to use it as such anyway.

[3N4N]

First let's get the interpersonal point out of the way, I didn't mean to imply you're using Windows wrong. I realize my wording was suspect, but look at it this way: there is no right way to use Windows. It's all crap all around, every way you use it.

You can't LoadLibrary the relevant DLLs? Or link the libraries to nvim-qt.exe statically?

(First, nvim-qt is a separate project, created and maintained separately, but other than this--) That can possibly be done. If you are familiar with DLLs (I'm not; I have a Windows computer but my programming laptop runs Ubuntu), you could propose a concrete solution and make a PR.

But before that, could you share some literature (blogs, etc.) discussing software that keeps their DLLs in separate folder? All of the third-party apps I use (e.g., nomacs) keep their required DLLs in the same folder the binary is in, like neovim.

Given that nvim.exe is a console application, saying that it shouldn't be on the path makes it difficult to use it as such anyway.

I use shimming. I don't use chocolatey so I can't speak for that, but its alternative, Scoop, uses this concept. The concept is: you keep one directory for keeping binaries and you put that directory in $PATH. If I want to use nvim, instead of putting C:\PROGRA~2\nvim\bin in $PATH, I put a shim of it in my dedicated bin directory (e.g., C:\bin). When run, the shim will in turn run the binary it points to and relay it the commandline arguments. Not saying it's the "right" way, but there is a reason this concept exists for Windows uniquely. Because Windows is not like other girls OS's.

[justinmk]

but the upgrade script was unable to delete some libraries, including libEGL.dll, libGLESv2.dll, and some others

This may be mitigated now since we will no longer will ship neovim-qt and its DLLs. #23668