I know that I can't use the STL library directly when developing windows driver. But I really need to use the standard c++ containers ( vector, map,etc ) . Any one knows some kernel based implementation of the STL for use under kernel mode, or some other similar library that at least implements the standard containers?
check out this one http://bazislib.sysprogs.org/. This lib contains patched version of STLPort .
Related
I have a Windows application written using MSYS2 and I need to statically link the FTD2XX library in order to access some FTDI devices.
After much testing and Googling I have failed to be able to have the GCC linker use the FTD2XX.lib library.
Is it possible to use the FTD2XX library from FTDI with MSYS2 (GCC) compiler and linker?
I don't know anything about your compiler, but I use the D2XX libraries all the time running the Lahey/Fujitsu FORTRAN compiler. All I need to do is wrapper the paramaeters for C-calls (i.e. explicitly tell the compiler when to pass by value and when to pass by pointer...FORTRAN always passes by pointer).
I would suggest looking at your settings for parameter passing, and make sure that everything matches up. The D2XX manual is very good at explicitly telling you the expected format for the library calls. Good luck.
I built SpiderMonkey 60 under Windows (VS2017) according to the documentation, using
../configure --enable-nspr-build followed by mozmake.
In the output folder (dist\bin) I could see 5 DLLs created:
mozglue.dll, mozjs-60.dll, nspr4.dll, plc4.dll, plds4.dll
In order to run the SpiderMonkey Hello World sample I linked my C++ program with mozjs-60.lib and had to copy over to my program location the following DLLs: mozglue.dll, mozjs-60.dll, nspr4.dll
It seems that plc4.dll, plds4.dll are not needed for the program to run and execute scripts.
I could not find any documentation about what is the purpose of each one of the DLLs. Do I need all 5 DLLs? what is the purpose of each one?
Quoting from NSPR archived release notes for an old version I found this:
The plc (Portable Library C) library is a separate library from the
core nspr. You do not need to use plc if you just want to use the core
nspr functions. The plc library currently contains thread-safe string
functions and functions for processing command-line options.
The plds (Portable Library Data Structures) library supports data
structures such as arenas and hash tables. It is important to note
that services of plds are not thread-safe. To use these services in a
multi-threaded environment, clients have to implement their own
thread-safe access, by acquiring locks/monitors, for example.
It sounds like they are unused unless specifically loaded by your application.
It seems it would be safe to not distribute these if you don't need them.
I am trying to use STM32F4 Discovery board with uCLinux BSP. Is it possible to create an application that uses C++11 function calls?
For example : STL, lambda, etc
You most likely have a GCC based toolchain for that BSP. Lookup which version of GCC is available there. Compare it with this table. https://gcc.gnu.org/projects/cxx-status.html
I have a 32-bit static library (.a) which I need to use in 64-bit project, it's library from one of the legacy project of my company and the source code was lost. So I wonder, is it possible to wrap 32-bit library to 64-bit one without source code?
There is no way to mix 32-bit and 64-bit code in the same process. This is an architectural limitation of x86_64. Depending on your needs, you may be able to package your library as an XPC service and then communicate with it directly via XPC.
I want to use "printf" in driver code (DDK), therefore I've included stdio.h. But the compiler says:
error LNK2001: unresolved external symbol __imp__printf
Any ideas? I seen somewhere that it is not possible - but that's awful - I can't believe it. Why can't I use standard C routines in kernel code?
C functions like printf come from a static cstd.lib or something AFAIK don't they?
Why would WDK provide me with stdio.h then?
The Windows kernel only supports part of the standard C runtime. In particular, high-level functionality — like file streams, console I/O, and networking — is not supported. Instead, you need to use native kernel APIs for similar functionality.
The reason that stdio.h is included with the WDK is because some parts of the C runtime are provided for your convenience. For example, you can use memcmp (although the native RtlCompareMemory is preferred). Microsoft has not picked through the CRT headers to #ifdef out the bits and pieces that are not available in kernel mode. Once you develop some experience writing kernel drivers, you'll get the hang of what's possible in the kernel, and what probably won't work.
To address your high-level question: you're probably looking for some debug/logging mechanism. You really have two options:
DbgPrintEx is the easiest to use. It's basically a drop-in for printf (although you need to be careful about certain types of string inserts when running >=DISPATCH_LEVEL). Output goes to the debugger, or, if you like, to DbgView.
WPP is the industrial-strength option. The initial learning curve is pretty steep (although there are samples in the WDK). However, it is very flexible (e.g., you can create your own shrieks, like Print("My IP address is: %!IPV4!", ip);), and it is very fast (Microsoft ships WPP tracing in the non-debug builds of most Windows components).