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).
Related
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.
I'm coming from C# background, learning C++, specifically on the Windows Phone 8 platform.
Many code samples (installed with the SDK) show usage of the Hat operator ^ (Reference here: Types that wear hats).
For example:
void PhoneDX::Initialize(CoreApplicationView^ applicationView)
{
// ... function body
}
I am wondering:
Why are most of the pointers being defined in that manner, specifically on Windows Phone 8 ?
Is that syntax mandatory? Suppose i am using a C++ native library from another platform (that doesn't use this syntax). Should it work with no issues?
A hat is a compiler-supported smart pointer type that is designed to make Windows Runtime types easier to work with from C++ code. As discussed in "Types That Wear Hats" and the other articles in that series, the C++/CX language extensions are optional: any code that can be written using C++/CX can be written in C++ without using the language extensions, albeit at greater code complexity and verbosity.
The key here is that hats are designed to facilitate code that makes use of Windows Runtime types. In general, you should confine your use of C++/CX and Windows Runtime types to the boundary of your components: most of your code should be standard, portable, normal C++ code. C++/CX should be used (1) to wrap C++ code to make it consumable through the Windows Runtime and (2) to use other Windows Runtime components from your component.
So, yes, the syntax is optional, but you should strongly consider using it when writing code that must work with Windows Runtime types. You should be able to use any ordinary C++ code, without modification, with the caveat that Windows Store apps and Windows Phone apps run with low privileges and some facilities are not available (e.g., there is no console, so console I/O doesn't work, and the runtime provides specialized process lifetime management facilities, so calling exit is a bad idea).
You might have a harder time grasping it since it's somewhat of a compound leap from (1) C# references to (4) C++/CX hats, with a stop in the middle for (2) C++ pointers then (3) reference counted objects.
The ^ smart pointers are a language extension, not part of standard C++, for handling the Windows Runtime types (which are reference counted)
so answering your points:
If you're seeing them a lot with Windows Phone 8, it's because ^ is used for Windows Runtime types, which would be used a lot in that platform samples (since the samples are trying to demonstrate that platform's api and features).
You would need to use conventions for that library, which would probably require that you use the types it defines (if it has its own smart pointers) or standard/regular pointers (i.e. *) or Standard Library smart pointers (i.e. shared_ptr).
Some concepts that should help you understanding this would be the lifetime of C++ objects, deterministic destruction (vs. waiting for a garbage collector to kick in), reference counting, stack/static vs. heap/dynamic allocation of objects.
Most applications created with Microsoft developer tools need some kind of runtime to be installed first.
However most viruses never need any kind of runtime to work. Also they also seem to use undocumented core/kernel APIs without have lib files etc.
So what runtime/application do most virus /virus writers use ?
If the runtime is statically linked in (as opposed to dynamically), then an EXE will be self-contained and you won't need a runtime DLL. However, really, you don't even need a runtime library at all if your code can do everything without calling standard library functions.
As for Windows APIs, in many cases you don't strictly need an import library either -- particularly if you load addresses dynamically via GetProcAddress. Some development tools will even let you link directly against the DLLs (and will generate method stubs or whatever for you). MS tries to ensure that names for documented API calls stay the same between versions. Undocumented functions, not so much...but then, compatibility typically isn't the foremost of concerns anyway when you're deliberately writing malicious software.
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).
We are using a COM Object automation model to make our application available to our customers.
They are using for the most part python to access our applicaton interface.
As we want to be able to install (not yet run, that's another issue) different versions of the application, we are changing our COM components to be regfree.
But that conflicts with the access from scripting languages through IDispatch automation since they need the entries in the registry.
Our approach is to create an application which manages the active version of our actual application. It lets the user decide which version he wants to have and it takes care of the registry entries.
What are the alternatives to our approach?
There is a protocol within COM for doing this. If you version the Interfaces (and change the GUIDS for each version) you can install multiple versions. Microsoft does this with WORD etc.
It is possible to create a Word.Document.5 class which is specific to version 5 of the library, or just word.Document which will create an instance of the highest present on the machine. I'm not sure if this functionality is build into COM or needs to be impemented but it's worth looking into.
Regfree COM objects can be accessed through the Microsoft.Windows.ActCtx object.
As for IDispatch automation requiring entries in the registry -- that's not strictly correct. I presume you're using the default ATL implementation, IDispatchImpl.
We solved this solution by providing our own implementation, IRegFreeDispatchImpl, which used the activation context manipulation APIs in the manner suggested here to wrap all entry points into the DLL with an activation context activation/deactivation.
Well the answer is suggested by yourself. You can write an application which has complete list of all versions of COM components. Once a version is selected by user, you can call regsvr32 application to register that particular version.