I have developed a C++ DLL in windows which has many CUDA accelerated functions.
Currently i haven't created the DllMain function as it is not mandatory.
I know that there are many limitations on the functions that can be called in the DllMain.
I just want to know that is it safe to call a CUDA Runtime function in DllMain just to initialize the default context, so that the subsequent CUDA calls are faster?
I'm using Visual Studio 2008, CUDA 5.0 and Windows 8 for development.
Reading the DLLMain documentation, I would advise against it. From the docs:
Warning There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL.
More specifically:
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose.
Since the CUDA Runtime API requires cudart.dll, this applies to your question.
So I would create an initialization function for your library that does CUDA initialization, and require it to be called explicitly at application startup.
Related
Libraries built with Mingw-w64 require those dll:
libwinpthread-1.dll
libstdc++-6.dll
libgcc_s_seh-1.dll
I wonder what's up with that, what each dll does? Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Why mingw requires to always bring those dll with your exe?
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler. It's so bloated though, 9 gb for installation.
Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Newer versions of GCC (4.8+ if I'm correct) should support SEH on MinGW.
I wonder what's up with that, what each dll does?
They provide the runtime and standard library.
libwinpthread: PThreads implementation on Windows (Threading)
libstdc++: C++ Standard Library (C/C++ library functions etc.)
libgcc_s_seh: Exception handling (SEH)
Why mingw requires to always bring those dll with your exe?
Because your program uses them. If you write a program without threads, standard library and exception and any OS interaction you wont need them.
These DLL's bring everything you need to run your program. Btw. this is not a MinGW only thing, and happens on other systems / compilers too. Often you just don't note this because the OS already ships the libraries, eg. MSVC libraries are very likely on a Windows machine. Dynamic linking always requires some sort of library files, that are .dll on Windows and .so on Linux.
If you have it available on your system use ldd <your application> to see what libraries are dynamically linked.
You can install these MinGW libraries into the system libraries or somewhere where the OS can find it. This enables your programs to use it and you no longer have to ship it with every application (what avoids duplication).
On the other side another option is to static link them. Unlike dynamic linking, you don't need any DLL; on the downside is a increase of you applications size (as now the three libraries are baked into the exe now).
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler.
This depends on your situation. But probably my answer will give you some more insight.
I want to know the benefit of pre-JIT compilation (ngen.exe). What is the role of the Native Image Generator (NGen) process and why is it required?
Please provide an example.
For code execution on the .NET platform, the Common Intermediate Language (CIL) representation needs to be translated into machine code. If this happens immediately before execution this is referred to as JIT (Just In Time) compilation. Output of JIT is not persisted so your managed application has to go through JIT for every launch.
Alternatively, you can use pre-compilation to reduce startup overheads related with JIT compilation. NGen performs pre-compilation and keeps the native images in a native image cache. Then applications can run with the native images and may experience faster startup time due to reduced JIT compilation overhead. Initially, NGen was an install-time technology, developers made application installers issue NGen commands to trigger pre-compilation during install time. For more details, check out NGen Revs Up Your Performance with Powerful New Features. This article provides an example application that leverages NGen.
With Windows 8 (.NET 4.5), a new NGen mode: "Auto NGen" has been introduced. Basically, the .NET runtime generates usage logs for managed applications. When the system is idle, an automatic maintenance task runs in the background and generates native images. This way developers no longer have to deal with NGen explicitly. Note that this feature is only enabled for .NET 4.5+ applications that target Window Store or use the GAC. Here's an MSDN page that may be helpful:
Creating Native Images
And this is high-level overview of NGen and related technologies:
Got a need for speed? .NET applications start faster
Lastly, .NET framework libraries themselves use NGen for better performance. When .NET framework is serviced, some of the native images get invalidated. Then NGen needs to run to re-generate the invalid native images. This is done automatically via the .NET Runtime Optimization service which runs during idle time.
When a .NET compiler compiles C# or VB.NET code it half compiles them and creates CIL code. When you run this half-compiled .NET EXE file the JIT runs in the background and compiles the half CIL code in to full machine language. This mode is termed as normal JIT.
You can also go the other way around saying you do not want runtime compilation by running a full compiled EXE file. This compilation is done by using negen.exe. In this scenario the JIT does not participate at runtime. This is termed as pre-JIT mode.
If you want to see how they affect performance you can see this YouTube video which demonstrates normal-JIT and pre-JIT mode of compilation:
Explain JIT, Ngen.exe, Pre-jit, Normal-Jit and Econo-Jit.? (.NET interview questions)
Per MSDN:
The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.
I have used NGEN in the past during installation so that the software would start up faster.
NGen (Native Image Generator) basically compiles .NET byte code (CIL) into native code for the computer it's running on. The benefit is that given that you're not compiling the code to native every time, you run it or need it, but you do it just once, the application starts and run faster. If you want more information there are plenty of resources out there about the benefits of JIT vs. Ahead of Time Compilation (which is what NGen does).
I am going through my project code base, which consits of libraries and
applications. Some libraries are Dll's. Code is written in C++ for Windows
using MS VS 2010.
I taught for Dll we should write DllMain function which is entry point for
the DLL application. But in my project for DLL "DllMain" function is not present.
My question when we require DllMain and when it is not required?
Thanks for your time and help.
DllMain is not mandatory. If you have some initialization code required to run when loading the dll, you should create a DllMain function, and treat the initialization there. Otherwise it's not required.
See here some more information.
I am working on a project which captures all User Interactions. MSDN tells (this)
SetWindowsHookEx can be used to inject a DLL into another process. A
32-bit DLL cannot be injected into a 64-bit process, and a 64-bit DLL
cannot be injected into a 32-bit process. If an application requires
the use of hooks in other processes, it is required that a 32-bit
application call SetWindowsHookEx to inject a 32-bit DLL into 32-bit
processes, and a 64-bit application call SetWindowsHookEx to inject a
64-bit DLL into 64-bit processes.
My Question is, what happens if an application was built against Any CPU. Do I need to call SetWindowsHookEx from a DLL built against Any CPU.
I have written HookLogger_32.exe loading HookFunctions_32.dll (both x86) and HookLogger_64.exe loading HookFunctions_64.dll (both x64) setting WH_CBT and WH_MOUSE globally (not a specific thread).
The HookLogger_32.exe, HookLogger_64.exe, HookFunctions_32.dll and HookFunctions_64.dll are written in C++.
When I click on a .NET application built against Any CPU, these DLLs get injected (through SetWindowHookEx). The Windows OS hangs & I have to forcefully restart my machine.
When the same .NET application is built against x86 or x64, and when I click on the application after the HookLoggers (both 32 & 64 bit) are started everything is working fine.
Any reasons for this undefined behavior.
The platform on which I am working is a 64-bit machine.
You need to inject from a DLL with a corresponding bitnse - i.e. "any CPU" becomes either 32 or 64 bit at runtime... and your DLL must match the runtime bitness !
Something useful in your situation is known as "side-by-side assembly" (two versions of the same assembly, one 32 and the other 64 bit)... I think you will find these helpful:
Using Side-by-Side assemblies to load the x64 or x32 version of a DLL
http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx
http://www.thescarms.com/dotnet/Assembly.aspx
Here you can find a nice walkthrough which contains lots of helpful information pieces - it describes .NET DLL wrapping C++/CLI DLL referencing a native DLL
UPDATE:
To make hooking really easy and robust see this well-tested and free library - among other things it works with AnyCPU !
I guess your main problem is that you are trying to inject a .NET assembly to native process and that surely won't work. I'm not even sure if SetWindowsHookEx supports injecting .NET assembly in CLR process. The solution to your problem is:
Rewrite/Recompile your dll using native compiler such as C++/Delphi/VB etc, for x86 and x64 platform.
Make sure your dll depends on system libraries only. For example, it shouldn't depend on any dll that doesn't ship with windows, because you may crash target process. You can use "Dependency Walker" tool to identify dependencies.
As mentioned in MSDN, you should have an executable injector for each cpu you wish to support. In this case x86 and x64.
Or you could use a better injection/hooking library such as madCodeHook or Detours. This way you will overcome problem #3, not to mentioned dozens of pros they provide.
Just from your description of the problem my guess is...
Your Any CPU compiled program is loading an x86 stub which is firing your 32bit hook, then the x86 stub checks and sees that the environment has 64bit support and launches the 64bit CLR version.
In this scenario your 32bit hook dll is getting the WH_SHELL message and is trying to inject into a process (the x86 stub) that has already ended OR its injecting the 32bit hook into the 64bit CLR process. Thus your "very ambiguous and needs to be elaborated on" system crash.
If you care to elaborate about what your code is actually doing, then more help (and less generalizations and 'just use program A') will be given. Are you actually injecting code into the process or are you calling SetWindowsHookEx with the dwThreadId of the process.
On a 32-bit computer, it should be pretty obvious was bitness an Any CPU application takes on.
A 64-bit computer gets two separate installations of the .NET Framework: one for each bitness. A .NET application compiled as with Any CPU as the target normally runs on the 64-bit installation, but it can also run on the 32-bit installation if referenced by another application that directly targets x86. Thus, you can only be sure what you're getting if you know how the application is being run: as an independent process, or via reference.
I wouldn't make any assumptions. Don't assume the process is 64-bit on a 64-bit computer: it can potentially be 32-bit. Check it properly to see which mode it is running in. Then, inject from 32-bit or 64-bit accordingly.
The reason that you must use the same bitness as the target process is that, for technical reasons into which I won't get, such hooks cannot cross what is called the SysWOW barrier. SysWOW is what allows 32-bit applications to run on a 64-bit computer, 16-bit applications to run on a 32-bit computer, etc. You are "crossing the barrier" when you communicate between applications running on different sides of SysWOW--that is, one is running within SysWOW (32-bit), and the other is not (64-bit). Simply put, a process must be entirely in or out of SysWOW. Thus, you cannot have add 32-bit code to a 64-bit process, and vice versa.
When an MFC application starts, is it possible to check for the Visual C++ runtime before the "application configuration" error is displayed?
I assume it must be done via pure Win32 API at some point before the CRT loads.
The error is coming from the operating system, before your program is even finished loading. There is no part of the program, not even initialization, which has run yet. Thus no way your program can eliminate the error message by itself.
Edit: You might be able to set the runtime DLL as a delay-loaded DLL to get your program loaded in the absence of the runtime. Then you'd have to substitute your own function for the .exe entry point and have it check for the existence of the runtime library. There are many technical difficulties associated with this approach, and I'm not even sure it would work at all - but it might be possible.
Well, you get that error because you're missing the redistributables. So instead of trying something like that, you should rather install the VC++ redistributables from Microsoft (as prerequisite for your application). I used to keep a list of the downloads here.