   Loading DLL's and paths
  i've been loading my dll using the entire path. this work's oki want to just load the dll by using its name only (mydll.dll) and having the dll in the same folder as the calling exe.according to msdn loadlibrary should always search the folder of the exe for the dll but i can;t get it to work. (dll not found error).if i use name only (mydll.dll) and put the dll in the window/system32 folder it works !anyone know where i'm going wrong ?   
  If you're running your app from within visual studio, it sets the working directory to be the directory that your solution is in, not the directory the EXE is in.There's two solutions:1. Go to Project Settings (Alt+F7) -> Configuration Properties -> Debugging, and set Working Directory to $(TargetDir)2. Instead of using "mydll.dll" as the parameter to LoadLibrary(), call GetModuleFileName(NULL, ...) to get the path to the EXE file, then strip off everything after the last backslash, append "mydll.dll", and use that as the path to LoadLibrary.Personally, I'd go for option 1.   ;  mmm.....we 'll i've tried option one and still no lucki' ve put the dll in the same folder as the generated 'debug' exe. ;  What do you get in the debug output from the following:TCHAR szBuff[256];GetCurrentDirectory(sizeof(szBuff)/sizeof(szBuff[0]), szBuff);OutputDebugString(szBuff);OutputDebugString("\n");? That'll tell you what your current directory is.   ;  I personally don't like option 1 as it is rather flaky if someone is to change the working directory on you (i.e. changing it in a shortcut)Option 2 is the way to go.   ;  You could also try using SetDllDirectory().   ;Quote:Original post by AAAI personally don't like option 1 as it is rather flaky if someone is to change the working directory on you (i.e. changing it in a shortcut)Option 2 is the way to go.Or even if someone puts a library of the same name in the windows directory. I don't like having to remember the path searching order.   ;  The directories that Windows searches for DLLs is (in order):The same directory as the .exeThe working directoryThe C:\Windows\System32 directoryThe C:\Windows directoryThe directories in %PATH%So by putting the DLLs in the same directory as the .exe, you don't have to worry about your working path being changed. (You also don't have to worry about someone putting a DLL in the C:\Windows\System32 directory, even though they'd have to be an administrator for that, so there's not much you can do about that!)   ;Quote:Original post by CodekaThe directories that Windows searches for DLLs is (in order): [...]Yeah, I know. I just don't like to rely in this sort of things. Who knows whether windows 2020 will have the same logic...   ;Quote:Original post by ravengangrelYeah, I know. I just don't like to rely in this sort of things. Who knows whether windows 2020 will have the same logic...Given that it's documented to work like that, you can be quite sure that it'll always works like that. Especially given the lengths Microsoft go to in the name of backwards compatibility, even for undocumented things!Besides, if you're not going to rely on that, what option do you have? Always hard-code the path?I think Oobydoobyscoobydo has bigger problems if the only way to get it to work is hard-coding the full path or putting it in system32. Oobydoobyscoobydo, can you show us the code you use to load the DLL, and also what the return value of GetLastError is?   