Virtual machines like the JVM and .NET CLR come with their own standard class libraries. The classes from these libraries can be utilised from any language that compiles to the corresponding machine's bytecode.
Is it possible to implement a similar class library for the LLVM so that the classes from such a library can be utilised from any language that compiles to LLVM bytecode similarly to the aforementioned classes of the JVM and .NET CLR class libraries?
Raw LLVM IR isn't suitable for such task, as it's not cross-platform, nor machine-independent. You might look for things like HLVM and VMKit, which are built on top of LLVM.
Related
Since the command-line tools x86_64-w64-mingw32-widl on Linux and widl on Windows both are able to produce type libraries, the .tlb files, for COM clients to import, it's reasonable to surmise that it might be doable to use MinGW toolset to build a COM client that is able to acquire COM interfaces by using smart pointers offered by the .tlb file, instead of calling function CoCreateInstance to get the interfaces. The question is how?
Visual C++ has its nonstandard directive #import to introduce the smart pointer types (and other stuff) to C++ code. What is the counterpart when we are using MinGW g++?
By the way, I've been googling all day and found it difficult to find useful information about "MinGW + COM". Most of them use Visual C++. If you know somewhere out there a good online tutorial on this topic is, please let me know. Thanks.
I testing an UWP application and I want to use a proxy to consume a WCF service. I have a proxy that is a library for .net 4.6 but I can't add this project as reference in the project of universal application. It is normal because is a library for .net 4.6.
So I am trying to create a portable library and I have two options, to create a portable library. This option let me say what targets can I use. I select .net 4.6 and windows universal 10.0. The problem is that I can't add a reference to the System.ServiceModel that I need to use the proxy.
The other option is portable library for windows universal. In this cases I can't select the target projects, it has sense because it is only for universal applications. In this case I can add the reference to the System.ServiceModel.
I know that in a portable library I only can use the libraries of the target project more restrictive, in this case I guess that is windows universal, no .net 4.6. But then, why do I can add the reference in the portable library for universal applications and not in the portable library in which I am using .net?
I would like to have a generic portable library to be able to use the proxy in WPF applications and universal windows applications.
Thanks.
Unfortunately there isn't a simple subset relationship between different target frameworks; i.e. in your case UWP is not a subset of .NET 4.6, therefore when you create a portable class library targeting both, you don't simply have all the APIs from the smaller framework available.
When dealing with clientside System.ServiceModel code the situation is even more confusing: although both target platforms include basic support for WCF proxies, the APIs are different enough that there is no portable equivalent that would be available when creating a PCL. This is the reason for the behavior that you are seeing: you can create a proxy both in a .NET 4.6 class library and in a UWP class library, but you can't create it in a portable class library targeting both of them. You will need to create 2 separate libraries.
If you're only going to call the proxies from the platform specific WPF an UWP code, then this shouldn't really be a problem, but I suspect that you would like to call them from the business logic code which you would prefer to implement in a portable class library.
You can achieve this as follows:
Create an interface for the proxy class in a common portable class library for UWP and .NET 4.6.
Reference this common library from both platform specific class libraries: UWP and .NET 4.6. The proxies in these 2 libraries should implement the common portable interface. I haven't tried it, but if you configure the service references to reuse the types from your portable class library, the generated proxies should already implement your interfaces. This way you could avoid create wrappers around your proxies in each of the platform specific class libraries.
You can now write business logic in the common portable class library and only ever work with proxies using the common interface. To get concrete instances of this interface on each platform use a portable dependency injection framework, such as Ninject.
In application code for each platform you will then initialize the dependency injection framework by registering the correct proxy implementation of the interface, either UWP one or .NET 4.6 one. Of course you will also reference the common portable class library from both applications, as well as the correct platform specific class library in each application.
I have a piece of code that compiles for both the Silverlight and the .NET targets. It depends on Json.NET and SharpZipLib. My goal is to make a portable library that Silverlight and .NET projects can both link against.
Since there is no version of SharpZipLib targeting "portable-net40+sl50", I have a problem.
However, if I knew how, I would be willing to write the wrapper code myself.
So: How can I write a portable library that depends on Silverlight's SharpZipLib when being linked against from Silverlight and depends on .NET's SharpZipLib when being linked against from .NET?
Is that at all possible or is that something only Microsoft can do?
If your code uses a limited sub-set of the SharpZipLib API, you could create a "dummy" PCL library comprising this API subset, but without any functionality implemented.
What you then must do is to change the strong name (assembly name and signing) and version of the existing .NET and Silverlight SharpZipLib:s to be the same as your "dummy" PCL SharpZipLib and re-compile the platform specific libraries as well.
With this set of assemblies (PCL, .NET and Silverlight) you will now be able to consume the PCL library from other PCL libraries. In a platform specific application that makes use of PCL libraries that in turn consumes the SharpZipLib library, you should explicitly reference the platform specific SharpZipLib library that has the same strong name and version as the PCL analogue.
You should find more about this technique ("bait-and-switch") here and here. The PCL Storage project is also a good example of where this technique has been applied.
I am a .net developer who has never touched c++. I don't want to either :)
Unfortunately, I have to work with c++ module in .net 4.0 and I am clueless.
Is there a tool that can generate a .net assembly for a given c++ module?
If not, what are my next steps to successfully call these c++ libraries?
There are many ways:
COM Interop
Tlbimp.exe (Type Library Importer)
How to: Generate Primary Interop Assemblies Using Tlbimp.exe
The Type Library Importer converts the type definitions found within a COM type library into equivalent definitions in a common language runtime assembly.
PInvoke/DllImport
Calling Native Functions from Managed Code
The common language runtime provides Platform Invocation Services, or PInvoke, that enables managed code to call C-style functions in native dynamic-linked libraries (DLLs). The same data marshaling is used as for COM interoperability with the runtime and for the "It Just Works," or IJW, mechanism.
C++/CLI
Mixed (Native and Managed) Assemblies
How To: Migrate to /clr
This is more advanced because it will most probably require the C++ module to be updated and re-compiled.
Mixed assemblies are capable of containing both unmanaged machine instructions and MSIL instructions. This allows them to call and be called by .NET components, while retaining compatibility with components that are entirely unmanaged. Using mixed assemblies, developers can author applications using a mixture of managed and unmanaged functionality. This makes mixed assemblies ideal for migrating existing Visual C++ applications to the .NET Platform.
Say,if the .dll or .lib is written in C,can it be used by other languages like PHP/Python?
A DLL is binary. As long as your language can consume a binary library (with the OS the binary was compiled for), you should be okay (see exceptions below). LIB files are for the compiler so you'll only be able to use those by C/C++ languages at compile time.
The exception to this is .NET and COM. .NET generates special assembly DLLs to be used by other .NET languages (C#, VB.NET, C++/CLI, IronPython, etc). COM generates special DLLs as well where components (specialized classes) are exposed through the DLL. Natively, C++ and VB6 support COM. .NET languages can access COM DLLs through an interop. Many other languages also support COM bindings by various means.
Go here for a discussion on this topic and more details about the differences.