There is, it's called COM, and Windows as an operating system and ecosystem is built on top of it. (Though COM as a specification is not limited to Windows)
The language you use for defining the types is creatively named "Interface Definition Language (IDL)", and the "MIDL" compiler converts the interface definitions into C & C++ types and objects which can be used. Both via in-process/inter-process function calls, or via RPC/DCOM (Distributed COM).
"As a cross-language component model, COM relies on an interface definition language, or IDL, to describe the objects and associated functions. The COM IDL is based heavily on the feature-rich DCE/RPC IDL, with object-oriented extensions. Microsoft's own implementation of DCE/RPC, known as MSRPC, is heavily used as the primary inter-process communication mechanism for Windows NT services and internal components, making it an obvious choice of foundation."
"DCOM (Distributed COM) extended the reach of COM from merely supporting a single user with separate applications communicating on the Windows desktop, to activating objects running under different security contexts, and on different machines across the network. With this were added necessary features for configuring which users have authority to create, activate and call objects, for identifying the calling user, as well as specifying required encryption for security of calls."
If you want to learn more about this (it's an incredibly powerful concept that has a wide range of uses and is very much still used today), my recommendation would be:
1. The book: "Essential COM (1997)" by Don Box, one of the architects of COM at Microsoft in the 90s
2. The online tutorial "COM in plain C", which is one of the only (it might even be, like, THE only) resources for learning how COM actually works, since generally you use C++ frameworks to interact with it and they cover up all the details.
Disclaimer: I'm no expert in COM myself, I'm also working through these same learning materials.
I have a strong interest in FFI/Interop between languages and so have been working through things like "What is an ABI, conceptually?", understanding the C++ Itanium ABI, reading about vtable's, manually emulating C++ classes and class-inheritance with C structs of function pointers (vtables) etc.
COM is foundational here so it's the thing on my list atm. Hope you find this useful!
I think the history of the internal politics at Microsoft in regards to .NET and also the external industry trends is fascinating.
The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance.
I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the 1990s, Microsoft was already researching how to enhance and extend the COM interoperability model. (Otherwise known as "how do we get multiple programming languages to talk to each other?")
Based on some old interviews with Don Box[1], instead of this work being productized and released as "COM+ version 3" or whatever, it morphed into the CLR. This was a natural evolution that would have happened even without Sun's JVM threat.
C# the language, on the other hand, was a more direct response to Java the language since Microsoft's J++ (Java clone) was abandoned because of Sun's lawsuit.
As for .NET, it's interesting that Microsoft always had this large internal group of programmers (mostly Windows kernel and Office teams) that didn't fully buy into the .NET vision. On the other hand, Bill Gates himself was a big believer in it. My pet theory is that since Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly, he had a natural affinity for the vision of high-level C# & .NET being pervasive throughout Windows. Even with Bill's support, there was always an ongoing internal tension between the C++ vs the NET framework camps. (On a related note, it seems like Apple's internal programmers are more happily embracing Swift over Objective-C to a greater degree than Microsoft's internal adoption of C# over C++.)
Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android.
.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.
(On a related note, I also wrote an old comment about the decline of .NET's WPF and its limited adoption: https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465
Once the decision is made to
distribute a C++ class as a DLL, one
is faced with one of the fundamental
weaknesses of C++, that is, lack of
standardization at the binary level.
Although the ISO/ANSI C++ Draft
Working Paper attempts to codify which
programs will compile and what the
semantic effects of running them will
be, it makes no attempt to standardize
the binary runtime model of C++. The
first time this problem will become
evident is when a client tries to link
against the FastString DLL's import library from
a C++ developement environment other
than the one used to build the
FastString DLL.
Struct padding is done differently by different compilers. Even if you use the same compiler, the packing alignment for structs can be different based on what pragma pack you're using.
Not only that if you write two structs whose members are exactly same, the only difference is that the order in which they're declared is different, then the size of each struct can be (and often is) different.
For example, see this,
struct A
{
char c;
char d;
int i;
};
struct B
{
char c;
int i;
char d;
};
int main() {
cout << sizeof(A) << endl;
cout << sizeof(B) << endl;
}
Compile it with gcc-4.3.4, and you get this output:
8
12
That is, sizes are different even though both structs have the same members!
Code at Ideone: http://ideone.com/HGGVl
The bottom line is that the standard doesn't talk about how padding should be done, and so the compilers are free to make any decision and you cannot assume all compilers make the same decision.
If you are serious about laying a solid foundation, start with Don Box' [Essential COM](https://www.amazon.com/dp/0201634465). If you don't want to have to guess about every single line of code you are going to write, this is absolutely mandatory reading.
I applaud your efforts to go with native C++ to deal with COM - you need to go through the pain to truly appreciate today's luxurious (managed) development environment :)
However, if your wallet doesn't extend to acquiring these dusty old books, the Microsoft COM tutorial material here could help set you on the right track.
COM is a binary interface standard for objects. It allows various programs to write to interfaces without all having to have been written in the same langauge with the same compiler. There are also related services available.
GUIDs are globally unique numbers that COM uses to identify interfaces.
COM doesn't resolve different DLL version problems. It only allows a single DLL to be registered for each GUID.
The .pas file is generated from the type library, which is typically contained within the COM DLL.
The .pas file defines the interface to the COM DLL. COM DLL's which come with embedded type libraries have self-describing interfaces. You still need documentation to understand what the interfaces and methods do, and how the parameters are used. But you don't need to write the boiler plate interface code yourself.
When a COM DLL has an embedded type library, you can create import units in your programming language of choice, not just Delphi.
The language you use for defining the types is creatively named "Interface Definition Language (IDL)", and the "MIDL" compiler converts the interface definitions into C & C++ types and objects which can be used. Both via in-process/inter-process function calls, or via RPC/DCOM (Distributed COM).
https://en.wikipedia.org/wiki/Component_Object_Model#DCE/RPC...
If you want to learn more about this (it's an incredibly powerful concept that has a wide range of uses and is very much still used today), my recommendation would be:1. The book: "Essential COM (1997)" by Don Box, one of the architects of COM at Microsoft in the 90s
2. The online tutorial "COM in plain C", which is one of the only (it might even be, like, THE only) resources for learning how COM actually works, since generally you use C++ frameworks to interact with it and they cover up all the details. ---------Disclaimer: I'm no expert in COM myself, I'm also working through these same learning materials.
I have a strong interest in FFI/Interop between languages and so have been working through things like "What is an ABI, conceptually?", understanding the C++ Itanium ABI, reading about vtable's, manually emulating C++ classes and class-inheritance with C structs of function pointers (vtables) etc.
COM is foundational here so it's the thing on my list atm. Hope you find this useful!
The common thinking is that C# & .NET was a ripoff of Sun Java because of the "write once run anywhere" threat. That's sort of true but missing some nuance.
I'm not a MS insider but here's my understanding of what happened. We have to separate the C# language from the CLR runtime. In the 1990s, Microsoft was already researching how to enhance and extend the COM interoperability model. (Otherwise known as "how do we get multiple programming languages to talk to each other?")
Based on some old interviews with Don Box[1], instead of this work being productized and released as "COM+ version 3" or whatever, it morphed into the CLR. This was a natural evolution that would have happened even without Sun's JVM threat.
C# the language, on the other hand, was a more direct response to Java the language since Microsoft's J++ (Java clone) was abandoned because of Sun's lawsuit.
As for .NET, it's interesting that Microsoft always had this large internal group of programmers (mostly Windows kernel and Office teams) that didn't fully buy into the .NET vision. On the other hand, Bill Gates himself was a big believer in it. My pet theory is that since Bill Gates programmed in BASIC in the 1970s and not in low-level C/C++/assembly, he had a natural affinity for the vision of high-level C# & .NET being pervasive throughout Windows. Even with Bill's support, there was always an ongoing internal tension between the C++ vs the NET framework camps. (On a related note, it seems like Apple's internal programmers are more happily embracing Swift over Objective-C to a greater degree than Microsoft's internal adoption of C# over C++.)
Two major forces outside of Microsoft's control curtailed .NET's planned world dominance: (1) the rise of Javascript in the browser which negated .NET Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and Android.
.NET is still very popular but it definitely did not fulfill the more ambitious dreams that Bill Gates had for it.
(On a related note, I also wrote an old comment about the decline of .NET's WPF and its limited adoption: https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465
No. That is not possible. It's because of lack of standardization of C++ at the binary level.
Don Box writes (quoting from his book Essential COM, chapter COM As A Better C++)
Struct padding is done differently by different compilers. Even if you use the same compiler, the packing alignment for structs can be different based on what pragma pack you're using.
Not only that if you write two structs whose members are exactly same, the only difference is that the order in which they're declared is different, then the size of each struct can be (and often is) different.
For example, see this,
Compile it with
gcc-4.3.4, and you get this output:That is, sizes are different even though both structs have the same members!
Code at Ideone: http://ideone.com/HGGVl
The bottom line is that the standard doesn't talk about how padding should be done, and so the compilers are free to make any decision and you cannot assume all compilers make the same decision.
I applaud your efforts to go with native C++ to deal with COM - you need to go through the pain to truly appreciate today's luxurious (managed) development environment :)
Back when the world (and I) were younger, Kraig Brockshmidt's book "Inside OLE" was the tome for making sense of COM (before COM even was COM). This book predates managed code, so no chance of managed confusion here. There's a second edition, too.
Don Box's books "Essential COM" and "Effective COM" were later, but welcome additions to the store of (unmanaged) COM knowledge.
However, if your wallet doesn't extend to acquiring these dusty old books, the Microsoft COM tutorial material here could help set you on the right track.
Happy hacking.
Your question is a little large for a full explanation here. A quick high-level introduction to COM can be found in the book Understanding ActiveX and OLE. A more detailed but still introductory introduction is Inside COM. The best book on the subject is Don Box's Essential COM.
A couple of quick answers:
The .pas file is generated from the type library, which is typically contained within the COM DLL.
The .pas file defines the interface to the COM DLL. COM DLL's which come with embedded type libraries have self-describing interfaces. You still need documentation to understand what the interfaces and methods do, and how the parameters are used. But you don't need to write the boiler plate interface code yourself.
When a COM DLL has an embedded type library, you can create import units in your programming language of choice, not just Delphi.
If you want to know COM there is no better reference than Don Box's Essential COM, one of the finest computing books I have ever read.