In my project i have a requirement to call methods in a Jar file using VC++. Is there any way to call the methods inside the jar file from VC++. If sample code is there then it will help a lot.
Thanks in Advance!
Arun
IKVM.Net ( http://www.ikvm.net ) is a .Net implementation of the Java libraries, which is not really what you want, but it includes a command-line tool called ikvmc (see http://sourceforge.net/apps/mediawiki/ikvm/index.php?title=Ikvmc) which will translate the java byte-code to .Net IL code, and produces a .Net assembly DLL. I've used this successfully to translate a Java library to an assembly that I then included in a C# project.
If you are using C++ as your target language then you must use JNI ( http://java.sun.com/docs/books/jni/). JNI defines an interface to exchange data and call methods from/to Java and native code. It is pretty straightforward to write a JNI wrapper to a class that contains methods returning and taking in input simple parameters ( that is native types, no collection , no arrays). When methods involves classes, collections, arrays and so on it can become quickly cumbersome to write the JNI wrapper by hand. This article provides a good overview: http://java.sys-con.com/node/45840. In this case you may evaluate a wrapper generator such as GIWS: http://www.scilab.org/products/other/giws.
If you are using the .NET environment as your target platform then IKVM is one option. However when we had to do this for a real project we preferred JNBridge and we had been quite successful with this (commercial) tool. We didn't evaluate IKVM for a business reason: our customer wanted only officially supported middleware.
Related
I'd like to build a DSL and use it as follows:
The DSL compiles to Java.
Export the DSL compiler and package it (i.e. as a JAR), so I can invoke the DSL compiler from a Java application to compile "code written in my DSL" into "Java source code" (I'll use other libraries to programmatically compile Java into bytecode).
Can I use JetBrains MPS to build a DSL and export its compiler as described? If no, other suggestions are appreciated?
I raised the question on MPS Support forum, and the answer I got was that it's not possible to export a compiler for my DSL (e.g. as JAR) from MPS IDE and then invoke the exported compiler from some Java application (think of a Java backend service) passing a text input representing a program written on my DSL.
Though you can use ant to invoke the "MPS code generator" (which is responsible for generating the target language code, e.g. Java, representing the input DSP program), but the generator expects as input "the MPS model" of your DSL program (I guess it's some AST like MPS internal representation of the DSL program). But the only way to generate "the MPS model" of your DSL program is by using Jetbrains' MPS IDE (or a stripped version of it, or intellij with a plugin for your DSL). In other words, the only way to write/edit programs in your DSL and be able to compile them, is by using Jetbrains MPS IDE (or one of its derivatives).
Link to the question I posted on MPS Support forum and the answer.
It seems to me your question is not so far from this documentation entry: https://confluence.jetbrains.com/display/MPSD32/Building+standalone+IDEs+for+your+languages
Maybe you cannot do it directly as a jar library, but it is possible, with some ant or gradle magic, to call a DSL compiler (or, as it's called in MPS, a generator) from an ant task. Documentation about this can be found at https://www.jetbrains.com/help/mps/building-mps-language-plugins.html#
I know it says building plugins but the same mechanism is used.
Why you would want to do this, though, eludes me, since the strong point of MPS is IDE support and very advanced multi-language integration, not necessarily code generation.
invoke the exported compiler [...] passing a text input representing a program written on my DSL
Your idea is sadly inherently flawed. There is no such thing as an MPS "DSL compiler" which takes text as input. In MPS there are generators which transform your DSL into another MPS language, in your case your target language would be BaseLanguage (MPS version of Java). After the transformation, the Java source code is generated as .java files and is automatically compiled as .class files. So yeah, this can be done with an Ant script built in BuildLanguage and called from cmd. But, the generator does NOT take as input text but an AST. The AST is your program "coded" (proper term would be modeled) in MPS.
So what you actually want is a parser (if your language is textual and parseable that is), which has text as input and AST as output. Once you have the AST in any form, you can somehow put it into an MPS model.
Please refer to my other answer where I commented on some portability (basically import, export) in MPS here. I have mentioned (not only) a project I am working on there. It allows to import a language and programs into MPS.
If you don't want to use MPS' IDE at all, but to work with text, it loses the advantage of MPS as a language workbench (LWB) with projectional editor. Maybe you should use another textual LWB (f.e. Xtext) or a parser generator (f.e. ANTLR). If the grammar definitions in parser generators scare you, you could use a model-based parser generator like YAJCo (I have contributed).
I have native (unmanaged) C++ DLLs that are being wrapped by a single C++/CLI dll (linking through the .lib files). These unmanaged C++ DLLs have quite a few classes with a ton of methods and a ton const data (e.g. strings, hex values, etc) which are defined in included headers.
But for the C++/CLI wrapper DLL its only a wrapping and marshalling layer for the native dll. However its binary size is as big as the native dll.
I believe this is causing me to hit the hardcoded limit which throws the exception when it is being loaded by a C# application:
System.TypeLoadException: Internal limitation: too many fields
The C# application will never use the fields defined in the headers for the native DLLs.
It was able to alleviate this issue through enabling of string pooling (shaving off a few MB), but it seems like a hack.
Why is a simple wrapper of a DLL the same size as that DLL? Is there a way where I can mark the const data such that the C# application won't load them?
You are falling into a pretty common trap, the C++/CLI compiler works too well. It is capable of compiling any C++03 compatible native C++ code into IL when #pragma managed or /clr is in effect. Works well at runtime too, it gets just-in-time compiled by the jitter to machine code, just like regular managed programs will be.
That's the good news. The bad news is that this code does not execute like managed code. It doesn't get verified and it doesn't get the garbage collector love. It also doesn't run as efficiently as regularly compiled C++ code, you are missing out on the extra time that the C++ code optimizer has available get the absolute best possible machine code.
And the one restriction that made your program bomb. Any global variables and free functions are compiled into members of the hidden <Module> class. Required because the CLR doesn't support globals. Members of a managed class get a metadata token, a number that uniquely identifies them in the metadata tables. A token is a 32-bit value with the low 16-bits used to number them. Kaboom when you created a <Module> class with more than 65535 members.
Clearly this is all quite undesirable. You'll need to pay more attention to what code gets compiled to IL and what code gets compiled to machine code. Your native C++ source code should be compiled without the /clr option in effect. Shift+click select those files and set the option. Where necessary, use #pragma un/managed to switch the compiler back and forth within one source code file.
Why is a simple wrapper of a DLL the same size as that DLL? Is there a way where I can mark the const data such that the C# application won't load them?
This is typically because you're compiling the entire project with /CLR.
If you're very careful to only include the absolute bare minimum requirements into the .cpp files which are compiled with /CLR, and only compile the .cpp files which are managed classes with /CLR, the wrapper projects tend to be far simpler and smaller. The main issue is that any header that's used by a /CLR compiled .cpp file creates proxy types for all of the C++ types, which can explode into a huge number of fields or types in the assembly.
Using the PIMPL idiom to "hide" the native code behind and opaque pointer can also dramatically shrink the number of types exposed to the managed portion of the assembly, as this allows you to not include the main headers within the managed code.
Been using VS2010 express. Writing in C# which i figured was a good middle step towards object oriented languages. One thing that has made my code somewhat repetitive is the inability to use multiple class inheritance in C#. I.e. I can't say class A inherits from class B and class C.
c# is great because you can quickly and easily get windows with buttons textboxes and dials up and running. This is not available in C++ in the express version since the MFC libraries are not included.
Now, I have thought of just desinging a C# front end which saves parameters to a file then execute a c++ which reads the file, runs and then saves a file which i open with another(or the same) c# backend exec to read and play ard with the results. But this would make it cumbersome always executing the whole sequence again if you want to change something. Not to mention debugging, will probably need to have to instances running.
Reading on of the Visual studio 2012 Express for desktop announcment, it stated that "You can also combine C++, C#, and Visual Basic projects into a single solution, making it easy to write a single application using any of the available languages." http://blogs.msdn.com/b/visualstudio/archive/2012/09/12/visual-studio-express-2012-for-windows-desktop-is-here.aspx?PageIndex=3
Now I would be happy with that, after all I dont expect and dont need at this stage to do any wizbank stuff i.e special button functionality/design which is easier and provided with the MFC in C++.
My question is: Has anyone tried this in Visual Studio 2012 in the Express for windows desktop version in Windows 7''? I.e can you combine a c++ and a c# projects which interact, trace the code form one project to another when debugging for example? Are there any special restrictions? I mean if its combining executables only its not much use, but i expect its more than that, but how much more? For example, can an object designed in C# instanciate an object designed in c++ pass it a reference to other objects like classes which hold inputs and outputs or data which are proccessed in the c++ class and still accesible in the c# code to display results etc?
I am asking this before downloading the new express version because I expect it will set me back a couple of months since going from C# to C++ i would think is like going from Visual Basic to C. I wouldnt want to get into all the trouble (i dont mind really but it would be huge step back) to find out i cant "seemlesly" integrate a c# front end with a C++ proccesing solution.
You have three options for interfacing C++ with C#:
pinvoke: You specify function signatures in C# and give them an attribute specifying what DLL they reside in. This is fairly painful to do if you need to pass around any complex types at all.
COM: A C++ DLL would implement a COM object called by the C# code.
C++/CLI: Allows mixing of managed and unmanaged C++ code in a single C++ project. It is very nice for interfacing with other libraries but, in VS 2010 at least, lacks helpful features such as intellisense. If you really wanted to go this route, I would write three projects: Your core C++ code as a static library, your C++/CLI DLL to wrap it, and your C# application.
I am working on a VC++ DLL that uses SWIG (Simplified Wrapper and Interface Generator) for C#. The DLL does not use ATL or MFC, it is set to use only the Standard Windows Libraries. Now because of some memory issues, I want to output formatted messages from functions to a log file. What are the different way to do that? Is there a pre-existing trace class that I can use?
I know just 3 different ways to do it:
Use one of the existing log libraries for C++. This is the most flexible approach since you can profit from many nice features like formatting, different appenders etc
Use OutputDebugString function. This function sends message to the debugger, but does not put it to any file by default.
Implement your own simple logger
I hope this helps.
I think that java executables (jar files) are trivial to decompile and get the source code.
What about other languages? .net and all?
Which all languages can compile only to a decompile-able code?
In general, languages like Java, C#, and VB.NET are relatively easy to decompile because they are compiled to an intermediary language, not pure machine language. In their IL form, they retain more metadata than C code does when compiled to machine language.
Technically you aren't getting the original source code out, but a variation on the source code that, when compiled, will give you the compiled code back. It isn't identical to the source code, as things like comments, annotations, and compiler directives usually aren't carried forward into the compiled code.
Managed languages can be easily decompiled because executable must contain a lot of metadata to support reflection.
Languages like C++ can be compiled to native code. Program structure can be totally changed during compilation\translation processes.
Compiler can easily replace\merge\delete parts of your code. There is no 1 to 1 relationship between original and compiled (native) code.
.NET is very easy to decompile. The best tool to do that would be the .NET reflector recently acquired by RedGate.
Most languages can be decompiled but some are easier to decompile than others. .Net and Java put more information about the original program in the executables (method names, variable names etc.) so you get more of your original information back.
C++ for example will translate variables and functions etc. to memory adresses (yeah I know this is a gross simplification) so the decompiler won't know what stuff was called. But you can still get some of the structure of the program back though.
VB6 if compiled to pcode is also possible to decompile to almost full source using P32Dasm, Flash (or actionscript) is also possible to decompile to full source using something like Flare