I have looked at the Microsoft Forms 2.0 Object Library (FM20.DLL) and Microsoft Windows Common Controls (comctl32.dll), as both exist (I think) as OLE providers on my system. (I am doing this by opening them in VBA in Excel to look at the libraries with their members) and playing around with them in VBA.
My bigger problem is that I don't understand the relationship between the libraries themselves and ActiveX - how do I know which members can be created as ActiveX objects? (For example, you can create "Excel.Application", but not "MSForms.UserForm").
I want to be able to script (using OLE) a form using some library, display it, respond to events, etc. I would prefer using something that is already available (like the libraries mentioned above, if possible) to prevent having to install extra software.
If you can give an example (in any language) to get me started, that would be very helpful and much appreciated.
As per HansPassant's comment, what worked is using MS Forms 2.0, which has an ActiveX object, "Forms.Frame.1", which can be created and used in my program.
I found a program called ActiveXHelper, which allows one to see all the registered ActiveX objects on the system.
I'm writing a framework for COM clients in Windows and would like to test it against some preinstalled COM servers. Are there some well known servers I could use to run my unit tests?
You can check that for yourself in the registry at HKEY_CLASSES_ROOT\CLSID. Some of the first ones are part of the core of COM, e.g. {0000031A-0000-0000-C000-000000000046}, the class moniker.
You can also use OleView.exe, it comes with the Windows SDK and Visual Studio (at least the flavors with C++), and check out under Object Classes > All Objects. Copy this tool into a clean Windows installation and check the stock objects.
However, avoid the PSFactoryBuffere (PS* in general), as they are proxy-stub marshalers and some are probably free-threaded marshaled themselves.
What might be interesting are the interfaces accessible from those objects, so you'll want to look for stock type libraries in OleView.exe.
When learning Windows phone 8 development, I found that its API can be divided into:
1. Managed (.NET API)
2. Managed & Native (Windows Phone Runtime API)
3. Native (Win32 & COM)
My question is why the .NET API is called "Managed". What does this word means?
Thanks.
.NET is called managed, because object lifetimes are automatically managed by the runtime environment (CLR, Common Language Runtime).
In contrast, native (and COM) code requires that object lifetimes are managed by the developer, either by explicitly invoking the respective cleanup calls (e.g. delete, Release()), or by using resource management classes (e.g. std::unique_ptr, _com_ptr_t).
The term managed also refers to additional services provided by the CLR as code continues to run, such as memory management (e.g. providing a compacting heap), security (e.g. verifying that an assembly's code is safe/valid), threading, and the like.
.NET is based on some kind of bytecode similar to the Java Virtual Machine. This allows garbage collection and checks when casting object types.
As far as I know the word "managed" refers to the fact that .NET provides a data management that handles both garbage collection and object casting checks (and something more).
"Managed code" is a synonym for .NET code (as far as it is not mixed with non-.NET-objects).
I need to find the product version of an installed application using the product code GUID. Is there a way to do this using a simple API call of some sort? I have found ways to do it using P/Invoke and the WindowsInstaller namespace, but I am trying to avoid using P/Invoke.
The Windows Installer exposes Win32 API functions (P/Invoke) as you have discovered. It also has COM automation interfaces that wrap these APIs but I'm sure you can guess is this is even less elegant. Windows Installer XML (WiX) Deployment Tools Foundation (DTF) has an MSI interop library that wraps it as managed code but I'm sure you can guess what it's doing under the covers: P/Invoke.
There are ways of getting it from the registry but this is not the official API and is less elegant IMO.
So to answer your question, you are already doing it in a very good and professional way.
If you want to get sneaky you can look through the registry to figure it out. When an MSI is installed windows creates a set of registry keys under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
or
HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<munged-ProductCode>
(depending on your machine/MSI bitness)
Under that registry location there should be a registry value named "ProductVersion". The trick is to know how to 'munge' a windows GUID (see http://www.vmwareinfo.com/2011/09/surgically-eliminating-windows.html).
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).