I would like to prevent loading of malicious DLLs that may be possible through access of the current working directory as described in http://msdn.microsoft.com/en-us/library/ff919712(VS.85).aspx
The solution implemented in our C++ apps was to make a WinAPI call to SetDllDirectory(""), which would effectively remove the current working directory from the Windows DLL loading search path. However, it seems this solution is not available for our Delphi apps because the SetDllDirectory() function doesn't exist.
Is there an equivalent call in Delphi that does the same thing as SetDllDirectory("")? Thanks!
This should do the trick:
function SetDllDirectory(lpPathName:PWideChar): Bool; stdcall; external 'kernel32.dll' name 'SetDllDirectoryW';
Calling SetDllDirectory('') doesn't work? I see that it is declared properly in the latest versions of Windows.pas. If you have a version of Delphi in which it isn't declared, you can upgrade to the latest version of Delphi, or declare it yourself.
Update: And there you go... Jens just posted the declaration.
uses DSiWin32;
if not DSiSetDllDirectory('path') then
....
DSiSetDllDirectory will also take care of dynamic linking and will fail gracefully on pre-XP SP1 systems.
DSiWin32 is released as a freeware.
Related
After upgrade app from Clarion 9.1 to Clarion 10 and after first build an error acquiring.
Error: Unresolved External SHGetFolderPathA in EFOCUS.obj. I include efocus.clw in solution. Efocus.clw and efocus.inc are in C10 folder.
Help me please
I dont use the enhanced focus feature, but a couple of things might help:
SHGetFolderPathA is deprecated but should still be around since its in Shell32.dll. Its possible SV eliminated it from their lib in lieu of the replacement call (see https://msdn.microsoft.com/en-us/library/windows/desktop/bb762181(v=vs.85).aspx ), but I doubt it. Even so, you could make your own lib using the DLL and Libmaker.exe (which is shipped in \c10\bin).
It may be simpler than this. Delete the clw and obj from your app folder (or sub-folder where the .RED directs them) and recompile.
Is there a Haskell equivalent of POSIX' dlopen or Windows' LoadLibrary? All the FFI stuff only seems to work with libraries specified at link time.
A quick hoogling brings up System.Posix.DynamicLinker. You can also try the plugins package for more high-level stuff.
For Windows, there is System.Win32.DLL. The result of getProcAddress can be converted to a function pointer using castPtrToFunPtr.
I'm currently trying to load a plugin assembly dynamically in a monotouch app.
To do this, I'm referencing the plugin dll in my app project, setting the limker to 'sdk only' and then i'm trying to call Assembly.Load(filename) within my app when the plugin is required.
This is the same approach that I've previously successfully used in monodroid. However currently, this is failing in monotouch with a FileLoadException.
Is this approach possible in monotouch? Is there a special file path you need to include? Or is this not supported in the aot environment?
Note: Obviously there are other ways I can achieve a similar effect - and I do have a backup plan... but this is my preferred route (if I can make it work)
Code like:
var a = Assembly.Load ("mscorlib.dll");
Assert.NotNull (a);
works fine with both the simulator and devices. However the parameter for Load is assemblyString which is not a filename (even if the exception thrown make you think it is).
Many other overloads exists (for Load) and other methods too (e.g. LoadFrom) but they might not all work inside MonoTouch (since some runtime support might be missing).
NOTE
Handling of mscorlib.dll is special (and works in more cases than other assembles, i.e. shortcuts). However the reflection-based methods seems to work as expected in more cases, e.g.:
string filename = System.IO.Path.GetFileName (GetType ().Assembly.Location);
Assembly assembly = Assembly.ReflectionOnlyLoadFrom (filename);
Assembly.Load (or any other way of loading code dynamically) is not supported in MonoTouch.
This is an iOS restriction - all the executable code has to be in the app (and it has to be native code, which is why we use AOT to generate native code at compile time).
I'm trying to link my XPCOM extension against the 1.9.3a3pre SDK and I get the following:
error LNK2001: unresolved external symbol _moz_xmalloc
So, what lib do I need to link to? The documentation doesn't say.
This is on Windows right now, but I'll need it to build on Mac and Linux (32bit/64bit) as well.
Edit: Now with bounty.
Edit: Update: Turns out FF3.7 was cancelled. So I don't have to worry about this until FF4.
I have same error, and linking to mozalloc helps for that.
define 'XPCOM_GLUE' in C++ Preprocessor Definition property. It will fix the linking error.
Try defining MOZ_NO_MOZALLOC when compiling your extension, you will then get a DLL that uses your CRT's allocators. (Don't forget to use the NS_* allocators for XPCOM-compatible memory.)
Add MOZ_NO_MOZALLOC in C++->Preprocessor->Definition property.
Use xpcomglue_s_nomozalloc.lib instead of xpcomglue_s.lib in Linker->Input->Additional Dependencies
It will be OK!
reminder note: another option that can cause this even though everything else seems to be configured correctly in the project, is pointing at the wrong libs folder - such as 32 bit version for a 64 bit build.
edit v40 mozalloc.lib has changed name to mozglue.lib and has some additional methods.
edit v41 mozglue.lib has changed name to mozcrt.lib
I'm trying to test out a library that provides a VC++ example; however, I use gcc/g++ for all of my projects.
Well, the way the VC++ example accesses the library is it uses the #import directive, passing the location of the library DLL, then it does a using namespace LIBRARYNAME, and then it's able to create some undefined type (I'd assume it's defined in the DLL) and create a new instance of it with __uuidof. From then on, to call one of the library functions the example just does a createdObj->foo() and that's that.
Well... g++'s #import is different from VC++'s import (see here), so this example won't work for me.
Is there any way this can be converted to compile under g++, or am I SOL until the library developer provides me with a static library I can try out?
If you are using cygwin, then this page: http://www.cygwin.com/cygwin-ug-net/dll.html will provide you with all the help you need.
If you are using mingw, you can accomplish the same thing, but you probably won't have grep and sed, so you'll have to use some other method of doing the filtering to get your .def file.
If you were using #import in VC++ it means the DLL isn't a regular DLL, it's a COM DLL.
Since gcc doesn't have COM support, you'll just have to wait for the library author to write a non-COM version.
Maybe it could have helped you to use the OLEViewer and "View type information" to extract the basics of the IDL. Or maybe you could just use the VC++ generated .tlh and .tli files and import them into your G++ project.
I guess this answer is way too late, but right now I'm encountering similar issues myself so I just got into this thread. Hope you found the solution on time.
Regards.