I'd hate to have to relearn C++ just for this! Any libraries/URLs would be great and yes, Google didn't help much here :-(
This is for an upcoming project in which my product (Java based) would provide support for Microsoft's Hyper-V virtualization platform. Unlike VMware, which provides a Web-service, the Hyper-V APIs are mere extensions of WMI. I'd prefer not to use commercial tools such as J-Integra for Java integration into COM/WMI and the few open source tools I found are way outdated.
I would rather use JNI with C than C++. Anybody know where I can find libraries et cetera for using C for WMI operations? In the same vein as Python clients can be used? (And yes, I know C is not an OOP language :D ).
Thanks in advance.
WMI is acessed via COM right?
While it is more verbose and more error-prone (it is easy to accidentally use different pointers for the vtable and the "this" parameter), you can also use COM from the C language.
You also could use C++ but treat it as "C with language extensions to make using COM easier".
The JNI interface itself is a derivative of COM and you will find those methods and the methods of the WMI interfaces much easier to use if you use enough C++ to treat interfaces as implemented by C++ classes.
The other thing that will be helpful is that you will be able to use the COM interface pointers and reference counting as a way to bind the lifecyle of the COM interface to the lifecycle of your JNI-implemented Java classes.
I used an approach like this to implement a Java bridge, via JNI, to some C Language interfaces on Windows. I hand-rolled COM interfaces and a .lib that is used in building the JNI DLL.
The difficult part, with WMI, is that you will want to use the standard COM APIs to Instantiate the COM objects, whereas I created my own custom "factory" code, since it was all a private implementation.
You can download a snapshot of my development tree for the ODMJNI 1.0 0.50beta Function-Complete Release. If you look at info.odma.odmjni100 in the development tree you'll see how the JNI DLL is built (using VC++ 2005 Express Edition) and Java 1.5. The OdmJniBind.java class consists of the static methods that are used in the Java classes to coordinate object lifecycles between Java Classes and COM Object interfaces. (the OdmNative peer section of the tree provides the implementation of the OdmNative100.lib that is used in compiling the odmjni100.dll that is used via JNI.
#z0ltan
You can write your code in C but you ll have to save the file as CPP. As someone had mentioned earlier, for DCOM support your file needs to be a CPP file.
#Umi
For Java Integration - compile your WMI code in C/CPP as a DLL (with proper JNI header files) and then you will have to load the DLL library file. Once this is done, you can access the WMI methods in DLL files just like calling a Java Method.
Related
I have an existing library in C, which I want to be able to allow remote access to (either from Linux or Windows).
I looked at the usual RPC suspects like Thrift and Protobuf, but neither of these deal cleanly with C-style function calls (things like pass-by-ref, char* instead of string, * instead of List<> etc).
In short, to use either of these it looks like I would need to write a complete IDL from scratch, and add a lot of boilerplate code to transfer C-style function calls into these environments.
Are there any RPC libraries around that
can deal directly with C header files (or have tools to auto
generate the initial IDL from C definitions)?
are cross-platform Linux/Windows compatible?
require the absolute minimum of boilerplate code?
support sockets
are relatively high performance (XML-RPC i'm looking at you)?
Well, there's protobuf-c, an implementation of protobuf in C.
And then there's the classical XDR, found on most/(all?) unix-like systems, versions exist for windows as well. See also the Linux xdr(3) man page which contains an overview of the API.
Note that both protobuf and XDR are serialization libraries, they don't provide RPC. The "companion RPC library" to XDR is called, well, RPC, but I don't think anyone writes new code with that, and AFAICS it's unix-specific (portmap doesn't run on windows, does it? And it's generally a bad idea anyway.). Then there's protobuf-c-rpc which is the C version of the protobuf RPC library; probably a better bet than classic RPC.
The GObject Reference Manual states that the GObject system was designed to export functions written in C to other languages by using some generic glue code. It is also noted that this glue exists for perl and python explicitly. Omitted however, is how exactly where to find and how to use it.
So, lets suppose I have written a new GObject (for the sake of simplicity, the example given in the same manual) complete with C sources and header files, compiled it, and appropriately installed it, locating it where system libraries are to be found. Now I want to instantiate and use the object in a Python program. Or a Perl Program. Or even a Java program. Or any other programming language that has glib bindings available. How exactly can this be done?
Note that I want to use the object directly, most probably through the already existing generic glue code. I am aware of the possibility to use DBus to export the object from a running C program and access it with Python. But I look for no IPC-Solution. Compiled C library objects shall be more or less directly exported to another programming language.
You're looking for GObject Introspection. Once you have that set up properly you can use PyGObject (Python), Gjs (JavaScript), Vala, etc. pretty easily.
All the languages are, obviously, different, but since you sound most intested in Python... the Python GTK+ 3 Tutorial explains the process using GTK+ as an example.
Here's a few examples below. GType and GObject are standards and do not provide the glue code. You'll just want to look for the language you want to use and see if anyone has implemented the glue yet. If not, maybe you can :)
https://wiki.gnome.org/PyGTK/WhatsNew28
http://search.cpan.org/~rmcfarla/Glib-1.020/GType.xs
I am looking for some implementation of SPICE (electronic circuits simulator) written in C language which can be used as library.
I found some SPICE clone for Python and for Java, but not for C.
So far, I am using ngspice. It is very good clone of SPICE3, it is written in C, it has very good documentation. Is it possible to use it as library (so I can compile it into shared library and use it in my C project)? I compiled ngspice from source, but the result is CLI interface. Is there any option I can compile it into shared library?
But I am fine with any other SPICE clone.
ngspice now (mid-2013) now has an option to build as a shared library or dll to link into your app - it's documented in chapter 19 of the June 2013 manual (not the manual in the ngspice-25 release).
The 'Unix Way' would be to use the CLI program as is and use the 'system' standard library call to execute the binary (or fork/exec). Much less work than what you are trying to propose and with the amount that you are going to be calling the external application the overhead of doing the system call will be negligible.
I'm in the process of teaching myself C (coming from Java). I appreciate the language a lot, and one of the main reasons I am learning it is so that I can utilize the JNI feature built into Java to write native code when necessary. My question is mainly about the Windows API. Can I use the functions and features of the API using just C?
Will the Windows API be compatible with pure C code or does it contain classes and such that can only be utilized by C++ code?
Also, if I compiled a shared library on a Windows machine as (lib.sl NOT lib.dll), would it work on another machine (Mac/Linux)?
The Windows API (aka Win32 API) is a pure C library.
No you cannot use a Windows shared library on another non-Windows machine unless there is a software that supports Windows ABI - such as Wine or ReactOS.
Win32 API like others have pointed out is pure C. It means, once you get a hold of it, you will know everything about how the Operating system works. It is the same case usually with other operating systems as well. If you are after MFC/COM+ or Java wrappers, it is quite the opposite even if you can build great programs.
I am looking into making a C program which is divided into a Core and Extensions. These extensions should allow the program to be extended by adding new functions. so far I have found c-pluff a plugin framework which claims to do the same. if anybody has any other ideas or reference I can check out please let me know.
You're not mentioning a platform, and this is outside the support of the language itself.
For POSIX/Unix/Linux, look into dlopen() and friends.
In Windows, use LoadLibrary().
Basically, these will allow you to load code from a platform-specific file (.so and .dll, respectively), look up addresses to named symbols/functions in the loaded file, and access/run them.
I tried to limit myself to the low-level stuff, but if you want to have a wrapper for both of the above, look at glib's module API.
The traditional way on windows is with DLLs. But this kind of obselete. If you want users to actually extend your program (as opposed to your developer team releasing official plugins) you will want to embed a scripting language like Python or Lua, because they are easier to code in.
You can extend your core C/C++ program using some script language, for example - Lua
There are several C/C++ - Lua integration tools (toLua, toLua++, etc.)
Do you need to be able to add these extensions to the running program, or at least after the executable file is created? If you can re-link (or even re-compile) the program after having added an extension, perhaps simple callbacks would be enough?
If you're using Windows you could try using COM. It requires a lot of attention to detail, and is kind of painful to use from C, but it would allow you to build extension points with well-defined interfaces and an object-oriented structure.
In this usage case, extensions label themselves with a 'Component Category' defined by your app, hwich allows the Core to find and load them withough havng to know where their DLLs are. The extensions also implement interfaces that are specified using IDL and are consumed by the core.
This is old tech now, but it does work.