We have developed a COM DLL 64 bit on Windows Server 2008 R2 - 64 bit and this dll is successfully register when visual studio 2010 is installed on the machine but when on a fresh machine its unable to register with following error:
module xxxx.dll failed to load
make sure the binary is stored at the specified path or debug it to check for prob with the binary or dependent dll files
After a lot of investigation, we found that if Microsoft C++ runtime 2010 10.0.3019 is installed, then only dll will be registered. Can anyone provide the required list of dependecy. Thanks in advance.
Well yes, it is a XY problem.
When I'm opening a txt file from an application which I made I want to open another instance of this application with the file opened in it. So I don't want to load all the dlls and bins again, but just point to them in the memory (because the files were already loaded by the application which was first opened).
I want to do this because I cannot make the application a MSDI one, because it's to hard to do for me.
I don't think you can interfere much with how images (executables, not bitmaps) are loaded, but they're partly shared anyway. Don't ask me for too much detail, I'm not very familiar with what exactly windows does with images and/or memory mapped files.
That's all much too complex for such a goal anyway - just look into MDI, it'll be simpler.
Each process has it's own address space so, in general, it's not possible to just run another instance and "point to them in the memory". If you're worried about DLL's and such beging loaded twice I'd leave the management of virtual memory up to the OS, it's smart enough to map the same physical page into multiple processes when possible.
Are you sure of this? In what operating system? I have Win XP and I can tell you for sure that this is not happening because when I open a second app it takes as much time as the first one for all the files and dlls to load. Maybe in higher operating systems all apps point to the same adress in memory but not in XP.