I have some C++/CLI code which derives from the .NET System Namespace classes.
Is there a way to reuse this code for Universal Windows Platform Apps?
I can't get a reference to the System Namespace in C++, though in C# it is possible. It looks like there is only support for C++/Cx code and not for managed C++/CLI.
The syntax and keywords of the C++/CX extension resembles C++/CLI a great deal. But that's where similarity ends, they have nothing whatsoever in common. C++/CX gets compiled directly to native code, just like native C++. But C++/CLI is compiled to MSIL, the intermediate language of .NET. Their syntax looks so similar because they both solve the same problem, interfacing C++ to a foreign type system. .NET's in the case of C++/CLI, WinRT in the case of C++/CX.
Which is the basic reason why you cannot use the System namespace, it is a .NET namespace. You instead use the std namespace, along with the Platform and Windows namespaces for WinRT specific types. The compiler cannot import .NET reference assemblies with the /ZW compile option in effect, only WinRT metadata files, the ones with the .winmd filename extension. Which are an extension to the COM .tlb type library file format, the ones you previously had to import with the #import directive.
Which in itself is another major source for confusion, the internal .winmd file format was based on the format of .NET metadata. Most .NET decompilers can show you the content of a .winmd file because of this. But again just a superficial similarity, it is completely unrelated to a .NET assembly. It can just contain declarations, not code. Best to compare it to a .h file you'd use in a native C++ project. Or a .tlb file if you previously had exposure to COM.
Knowing how COM works can be very helpful to grok what this is all about. It is in fact COM that lies at the core of WinRT, the basic reason why your C++/CX project can be easily used by a program written in a completely different language like Javascript or VB.NET. A WinRT app is actually an out-of-process COM server. A class library or WinRT component is actually an in-process COM server. COM object factories work differently, the scope is limited to the files named in the package manifest. C++/CX is part of the language projection that hides COM, along with the C++ libraries you link that implement the Platform namespaces. WinRT would be still-born if programmers had to write traditional COM client code. You still can in native C++, the WRL library does little to hide the plumbing.
WinRT readily supports code written in a managed language like C# or VB.NET, the language projection is built into the framework and highly invisible. But not C++/CLI, a structural limitation. A Store/Phone/Universal app targets a subset of the .NET Framework named .NETCore. Better known these days as CoreCLR, the parts that were open-sourced. Which does not support module initializers, critical to C++/CLI.
Enough introduction and getting to the answer: no, you have no use for your C++/CLI code and you'll have to rewrite it. You'll have a decent shot at porting the native C++ code that your C++/CLI wrapper interfaced with, as long as it observes the api limitations. You should always start there first, given that it is easy to do and instantly tells you if your native C++ code is using verboten api functions, the kind that drains a battery too quickly or violates the sandbox restrictions.
The ref class wrappers however have to be significantly tweaked. Little reason to assume that will be a major obstacle, it could still structurally be similar. Biggest limitations are the lack of support for implementation inheritance, a COM restriction, and having to replace the code that used .NET Framework types with equivalent C++ code. The typical hangup is that there tends to be a lot of it, the original author would normally have favored the very convenient .NET types over the standard C++ library types. YMMV.
in the windows SDK there is this file residing in the Lib-directory. Is it possible to use this file with VB6? Google found nothing about it.
If not, in which language (Excep c++) can I use it?
resp. for what is it good for (yes, I know .net winforms)
Thanks regards
Oops
That file provides the COM interface information for the .NET objects that are exposed via COM interop. You can't use it directly, as it only provides the interface information.
My target DLL file is Microsoft DirectInput dll file which is located here:
C:\Windows\System32\Dinput.dll
I have monitored an application which uses it for API. I just see that it has call for "DirectInputCreateEx" on Dinput.dll and I did not found any other useful information.
Now I want to call and execute "DirectInputCreateEx" on Dinput.dll using VBScript.
Is this possible? How?
You could only do this (possibly) if it was a COM object. VBScript does not support calling normal API functions.
You can get around this by creating a COM wrapper for it in C++ or similar language.
I would like to know the exact differences between API and DLL.
Thank you.
Pretty much the only connection between the two terms is that if you do native Windows programming, APIs you use or write will usually manifest as DLL files. But neither is this the only concrete form an API can take, nor does every DLL represent an API.
API means "Application Programming Interface" - it's an abstract term for a collection of code entities (functions, classes, etc. - depends on the programming language) that's intended to be used by programmers at large to access the functionality of an application or library.
A DLL is a file format on Windows that contains executable code as a way to modularize applications.
An application programming interface (API) is an interface implemented by a software program that enables it to interact with other software. It facilitates interaction between different software programs similar to the way the user interface facilitates interaction between humans and computers. - Wikipedia
A Dynamic Link Library (DLL) is a one way of providing an API. (Interface to the programmer) You may have various other methods, like Web services.
A DLL is a library of code, and API is an interface to a library of code.
DLL = Dynamic-link library
API = Application programming interface
A DLL is just a file on Windows systems that has some code in that can be used by other executable files. An API is a way of using one piece of software, or a software library, to be used with another. For example there is a Windows Registry API that allows you to use the registry, but the code that runs when you use the API is stored in a DLL.
Updates:
DLL (Dynamic Link Library) is a code component (some what like the Beans in Java). DLLs contains the methods or functions or routines or whatever you call those code fragments.
And an API is an interface between an application and that DLL. Most of the time DLLs are used to provide services to other applications, these DLLs are called Server DLLs and if a DLL is requesting some service by using the API call or its dynamic invocation then it is said to be the Client DLL. So simple think, APIs are nothing but the methods or functions which are accessible from outside of that DLL.
Hope you got the idea now.
API are the header files (.h) which contain function and class declarations (input and output parameters), the implementation of these declaration i.e definitions of class or functions will be in particular dlls.
But to connect (dynamic linking) both these .h and .dll files, you require .lib files, these files will resolve the address of function definition during run-time and that particular dll files are loaded. Hence, libraries contain (APIs(.h), lib and dll files).
APIs make application development independent of underlying library implementations.
Example:
if you write a program in C to print "Hello World". And if you run the
same program in windows and Linux.
Both these executable will use different system libraries to display it on screen, as C language provides set of APIs like "STDIO.h","STDLIB.h", You need not worry about the underlying library implementations.
So you can think, API as header files, which connect function/class declarations with function/class definitions. Hence, the name "Application program interface".
You will have to be specific. DLL can stand for:
Data Link Layer,
Dynamic Link Library (Shared library on Windows Platform). It can also be a resource library too.
An API (Application Programming Interface) is an interface that's implemented by software programs to interact with other sotware. E.g. JDBC api is needed if a database connection is required in java.
From Wikipedia:
An API is implemented by applications,
libraries, and operating systems to
determine their vocabularies and
calling conventions, and is used to
access their services.
The purpose of a DLL (Dynamic libraries almost always offer some form of sharing, allowing the same library to be used by multiple programs at the same time).
In essence, the WINAPI (Windows API) are all implemented in DLL files, such as mmsystem.dll for MMSYSTEM Sound API.
References:
API
DLL
An API is an interface for communication of different components of an application, where dll is a library file which contains code so that your program can use using your API
Every DLL has some (is an?) interface (API) because otherwise it would be useless, but not every API is a DLL as in example You can have Web Api where You are using remote endpoints using in example HTTP protocol - not even a file like in DLL case
A simplified answer.
API is always (by definition) an application programming interface. It's a collection of methods that can be used as an interface to an app, a web service, etc.
DLL is a shared library file of the same format as executable. It contains code and data to be shared between other EXEs so you don't have to recompile them every time a DLL is updated. DLLs, for example, allow you upgrade Windows versions and keep the applications running on the latest version. It may contain code that's reusable by one or more executables, like an API. One the other hand, it may contain only data, like icons (.icl) and fonts (.fon).
I asked a question earlier asking how to use the Windows 7 taskbar progress bar without the .dll files, but I realized that in VS2010 you can embed a .dll into your application. I set this option to embed to true, but when trying to use the code for said .dll, I get this error:
Interop type "Windows7ProgressBar" cannot be embedded. Use the application interface instead.
Not quite understanding what I have to do, I finally found a single .dll which is only 20KB (instead of the three required for the Windows API) and I can't quite use it yet.
Any help is appreciated!
The VS2010 option named "Embed Interop Type" only works for COM interop libraries. Not sure what "Windows7ProgressBar" might mean but it certainly doesn't sound much like an interop type. The native COM interface name is ITaskbarList4. Perhaps you are trying to embed a class wrapper for this interface, that won't work.
Consider using the ILMerge tool to combine assemblies.