Mi a megoldás erre a hibaüzenetre? (msvcrt.dll)

Veszélyes manőver ez, mert azzal járhat, hogy install után az a program működni fog, ami ezt a .dll-t igényli, de nem fog az többi, ami meg a másik, a rendszerben lévő, hasonnevű .dll-el dolgozott együtt.

Azt teheted, hogy a szükséges .dll-t megszerzed, de nem installálod fel, hanem abba a könyvtárba másolod be, ahol az a program van, amelyik rikoltozott a hibaüziben lévő belépési pont hiánya miatt.

A .dll-ek aktiválási sorrendje ugyanis az, hogy először a forrás directory-ból próbálja meg a rendszer a betöltésüket, ha ez nem megy, akkor a rendszer speciális, erre szolgáló könyvtárából, majd ha ez sem sikerül, akkor a path-ban megadott könyvtárak valamelyikéből.

#2

Ez hülyeség, ilyet nem szabad csinálni.

Le kell tölteni a megfelelő MSVCRT-t, és feltelepíteni, abból nem lehet gond. Szépen megfér egymás mellet több, eltérő verziójú MSVCRT, és egyébként visszafelé is kompatibilisek.

Ha random dll-eket töltögetsz le a netről, simán előfordulhat, hogy valami vírust szedsz le, ilyet nem szabad csinálni!

"1. Ne fér meg két azonos nevű dll."

Én ilyet nem is írtam, nem tudom, hol olvastad.

"2. Nem kompatibilisek visszafelé, de ha mégis, a régi biztos, hogy nem kompatibilis az újabbal."

De, kompatibilis. Az új MSVCRT tartalmazza a régi verziók összes függvényét a 2015-ös verzió óta: [link]

"De hát, nem fér meg."

De, megfér, nem egyszer volt már feltelepítve nálam is több, mint pl. itt (nem az én képem): [link]

A 2015 utáni verziókból meg úgyis csak egyet tud feltelepíteni. Na, arra mondhatod, hogy nem fér meg, de hát nem is engedné a telepítő.

"Fogd már fel, hogy ha a függvények belépési pontja eltér, akkor nincs kompatibilitás, mert nem fogja tudni a függvényt meghívni. Éppen ezt az állapotot idézte meg a kérdező."

A DLL függvényeket szignatúra alapján szokás meghívni, a függvény belépési pontját a Windows feloldja (lásd GetProcAddress függvény: [link] ).

"A régi meg, hogy is lenne kompatibilis az újabbal? Honnan tudna olyan hívást kiszolgálni, amiről nem is tud?"

Az ÚJ kompatibilis a RÉGIVEL, nem fordítva. Azaz a régi DLL helyére simán be lehet rakni az újat (drop-in replacement), menni fog. Amikor egy új MSVCRT-t feltelepítesz, pont ez a történik, az új msvcrt.dll felülírja a régit. És megy probléma nélkül.

A cikkben, amit #8-as hozzászólásban linkeltem, is ugyanez van: "Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017, 2019, or 2022. There's no need to recompile with a matching toolset. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them."

"Éppen ezt az állapotot idézte meg a kérdező."

Igen, a kérdezőnél vagy régi MSVCRT van fent, vagy semmilyen, vagy eltérő architektúrájú, vagy sérült, ami fent van.

És most visszakanyarodunk az elejéhez: le kell tölteni a legújabb MSVCRT-t, és megoldódik a probléma, ennyi.