This is my first post here. Please let me know if am doing wrong in posting.
Well coming to the question, I have a jar(bundled collection of jars into one) and this jar doesnt have a main method. I have to convert this jar to dll and write a C code using that dll. (Native language bindings). So, are there any good tools to convert jar to native dll? I was googling and came across ikvmc but this converts jar to .Net dll. What is the difference between a normal dll and .Net dll? Can i use ikvmc to do my work? Or are there any other tools which converts jar to native dll? I see many tools that can covert jar to exe but not jar to dll. Please help me.Thanks..
Look at instantiating a JVM in C and then wrap that code in a new DLL as required.
How to call Java functions from C++?
Related
I'm building a windows mobile 6.0 application and I wanted to use restsharp library to consume data from a rest service. I've found information that RestSharp can be compiled for compact framework 3.5 (as is not available from the official site).
But, does anybody have successfully compiled the assembly for CF? If yes, could anybody provide a link to download the assembly. Thanks
I do not know a download location for the ready-to-use assembly.
I would start a new CF2 project and in another instance of VS open the original restsharp solution. Additionally open two file explorer to copy files of the restsharp source to the new CF2 project directory. You should maintain the same solution layout and folders (if any). Then copy the files over to CF2 dirs and use Add Existing Files in the CF2 solution. You need to use the same namespace and project and solution names (makes live easier).
Now try to compile. If you are lucky, everything compiles without error. But mostly you have to either adjust code or write CF2 compatible wrappers. If there are two many FullFramework constructs that can not be 'emulated' in CF2, you may have to give up. But as you said, there are CF compatible sources.
You mentionend CF3.5 and asked for CF2. Possibly RestSharp will only compile as CF3.5 assembly.
See also: RestSharp: Don’t Serialize null Properties
BTW: the GitHub repo (https://github.com/restsharp/RestSharp) shows a CF solution file RestSharp.Compact.sln and RestSharp.Compact.csproj. These should work with VS2008.
I noticed how you don't have to link opengl32.lib by yourself when you use libraries such as SFML and I'm really wonder how that could be since I have to link opengl32 in my projects that are using my own multimedia library which is a static library? Is it simply because the SFML library is a dynamic library and opengl32 is linked in the SFML project?
This is not a question about SFML, it's rather a question about all DLLs in general.
Yes, DLLs can reference other DLLs, or statically compile them internally. To inspect external dependencies, Microsoft long ago developed a tool called Dependency Walker, in which you can drag a DLL or executable and see which DLLs it depends on (and thus are automatically loaded). The tool used to be shipped with Visual Studio by default, but you can now download it from here for free. That page kind of explains everything else about it.
If a dynamic library is using another dynamic library, it will automatically get loaded into the process, yes.
I am currently working on an iOS project using the Unity framework.
When I export an Xcode project from Unity, there are a whole bunch of files exported.
Besides some source files, there are also .dll files for the Mono project.
But there are also .dll.s files.
For troubleshooting, it would be great to know what they are used for.
There is one .dll.s file for every dll, so it could be some sort of source which is compiled into the dll?
When there are exceptions somewhere in the code, Xcode often jumps into one of these .dll.s files and it looks as if they contain some sort of assembly code.
Directions would be nice, Google isn't really helpful here ...
TIA,
best regards,
Flo
They're the IL code in the dll files compiled into arm assembly. This is the code that eventually end up in the final app binary.
The big picture: what I am trying to accomplish is writing code in both C# and C++, to strike a good performance/productivity balance. It is not for code reuse reasons; I just want to be able to write new code in native C++ when it suits me, without committing to all its horrors.
I have a solution with 4 projects:
GUI: C# WPF interface
Logic_Cs: C# DLL, high level reference implementation of game logic
Logic_CLI: CLI DLL, interface between managed and unmanaged code
Logic_Cpp: C++ lib with native implementation
At some point, all of this was working just fine. In my GUI project I could switch between C#/C++ implementation merely by using the namespace from the appropriate DLL.
Then I apparently changed something, and now I can not get the namespace in the Logic_CLI project to be recognized in the GUI project, even though the Logic_Cs namespace still works just fine.
Yes, I added correct references, set dependencies, rebuilt AND recreated my entire solution structure from scratch; nothing helps.
I notice the C# DLL builds to a folder in its own project directory, while CLI builds to the solution directory; but the GUI application seems to look for the DLL's in their correct directory anyway, and im not getting any complaints about the DLL; it just refuses to import the namespace from it.
Earlier, when all this was working, I wasnt explicitly exporting anything from the CLI DLL; nor am I doing so for the C# DLL. It should 'just work', no?
I have my sources split up in several directories, so for each directory I get back a DLL. Is it possible to create a DLL from several other DLL's ?
EDIT: I'm using C++ with Windows CE Platform Builder 6.0 ( it's not managed )
There is no tool that will do this automatically for native code DLLs. You would have create a new DLL and add the existing source code to that project. However, doing this is likely to require changes to the source code.
Use ILMerge
Here you can download this.
Here is Sample for implementation.
You can't create one DLL from multiple DLLs. Any such tool would be awkward since each DLL could have it's own DllMain.
You CAN create a DLL from multiple static libraries though. It shouldn't be too hard to reconfigure your setup that way.