Accessing Windows Libraries from C++ (not MS VC++)

[SSteven]

Hi

I am considering using C++ as a programming language for writing business applications on multiple platforms. This requires me to access GUI Libraries and RDBMSs.

On MS-Windows, for the RDBMS, I will need to access SqlServer. For the GUI library, lets say I want to access Windows Forms. As I understand, C++/CLI (which is a MS product) is generally used to provide access on Windows to .NET (and therefore to Windows Forms and possibly SqlServer through ADO.NET). To use C++/CLI, MS VC++ is needed.

My question is can Windows Libraries (such as Windows Forms, SqlServer, etc.) be accessed from C++ (eg: the MinGW C++ compiler) itself or can they be accessed only using MS VC++? Assuming it is possible to access Windows libraries directly from C++ itself, do I need to go through C++/CLI (ie: the route in this case being C++ --> C++/CLI --> Windows Libraries). If so, how can C++/CLI be accessed from C++ (eg: the MinGW compiler)?

Thanks
Steven

[LB]

I don't directly know the answer to your question, but what's wrong with making your code able to detect and use the platform's native GUI library? E.g. detect that Visual Studio is the compiler and so use Windows Forms. With CMake this is easy to facilitate.

Alternatively, why not just use a library that does that for you, such as Qt?

[freddie1]

I utilize both MSVC and Mingw for all my projects. I like being able to test my code against two unrelated compilers. I have no issues with creating GUIs or connecting to Microsoft specific RDBMS (SQL Server / MS Access, etc.) through Mingw compiled code. However, I write straight Windows SDK code and don't code against any Class Frameworks such as .NET or C++/CLI.

In your case, since you wish to write code that's platform agnostic, I see no alternative to the use of something like QT or wxWidgets. These are issues I don't know much about, since I code only under Windows.

[SSteven]

Hi

Thanks for the replies.

When targeting Windows SDK from the minGW C++ compiler, which GUI library are you accessing? Is it Windows Forms?

Also, when targeting Windows SDK from the minGW C++ compiler, is it possible to use the WPF (Windows Presentation Foundation) GUI library (which is a part of .NET) and the UWP GUI library? (UWP - Universal Windows Platform - is new with Windows 10 and is native.)

According to MSDN, when .NET is accessed from a C++ program and is compiled using the VC++ compiler (The command for this is "cl /clr filename.cpp". The /clr switch specifies .NET's Common Language Runtime), the executable file will contain MSIL rather than native code.
In this regard, I'd like to ask:
a) In this VC++ compilation, does the Windows SDK come into the picture?
b) Through the Windows SDK, is it possible to access .NET classes from a C++ program which is compiled using the minGW C++ compiler? If so, would such a compilation produce native code or MSIL? I'm guessing the minGW compiler would know nothing of MSIL.

Thanks
Steven

[freddie1]

When targeting Windows SDK from the minGW C++ compiler, which GUI library are you accessing? Is it Windows Forms?

I don't use any components of .NET, Windows Forms, or WPF. All the functionality for doing anything that Windows is capable of doing is installed in dlls in \System32 such as user32.dll (user interface), gdi32.dll (graphics), kernel32.dll (tasking, memory management,the file system, etc). When you install the Windows SDK, one of the Visual Studio editions, or the Mingw compiler collection the necessary libraries to access the functionality contained within these core system dlls are also installed. Here I'm talking about the very lowest level abstractions you can code against. That's how I code. Coding that way I'm able to access any core Windows functionality such as COM (Component Object Model), OLE (Object Linking and Embedding), OLEDB, ODBC (Open Database Connectivity), or ADODB (ActiveX Data Objects), equally as well through Mingw or MSVC. Here are the C++ Command Line Compilation strings I am presently using for a major project I am working on now; first in Mingw x86 and x64, then MSVC....

// GCC g++ Command Line Compilation
// g++ SaleAdministration.cpp Strings.cpp CSql.cpp WordFunctions.cpp XLFunctions.cpp frmLogOn.cpp frmDBConnection.cpp frmWildlife.cpp frmSaleTracking.cpp frmProspectus.cpp frmBidOpening.cpp frmSysUtilities.cpp frmSecurity.cpp -lKernel32 -lgdi32 -luser32 -lole32 -loleaut32 -lodbc32 -luuid -oSaleAdministration.exe -mwindows -m64 -s -Os
// g++ SaleAdministration.cpp Strings.cpp CSql.cpp WordFunctions.cpp XLFunctions.cpp frmLogOn.cpp frmDBConnection.cpp frmWildlife.cpp frmSaleTracking.cpp frmProspectus.cpp frmBidOpening.cpp frmSysUtilities.cpp frmSecurity.cpp -lKernel32 -lgdi32 -luser32 -lole32 -loleaut32 -lodbc32 -luuid -oSaleAdministration.exe -mwindows -m32 -s -Os 

MS VC++

SaleAdministration.cpp
Strings.cpp
CSale.cpp
CSql.cpp
WordFunctions.cpp
XLFunctions.cpp
frmLogOn.cpp
frmDBConnection.cpp
frmWildlife.cpp
frmSaleTracking.cpp
frmProspectus.cpp
frmBidOpening.cpp
frmSysUtilities.cpp
frmSecurity.cpp
frmExtensions.cpp

Kernel32.lib
User32.lib
Gdi32.lib
odbc32.lib
shell32.lib
ole32.lib
oleaut32.lib
uuid.lib
Comctl32.lib
SaleAdmnRes.obj

/O1 /Os /MT /GA

In the above command line compuilation strings you can see such entities as 'kernel32.lib', 'odbc32.lib', etc. It is these libraries which allow me to call the Windows functions in their core system dlls. And as I said, this works just fine using the Microsoft C++ compiler or the GNU compiler.

But what you are talking about with such Microsoft specific technologies as .NET, Windows Forms, WPF, CLR, etc., are Microsoft specific OOP based encapsulations/abstractions of these core system capabilities which I asm using directly in the manner I described above. If you plan to utilize any of these Microsoft specific libraries its likely you'll have to stick to the Microsoft compiler. I'm not 100% sure of that, but fairly certain. Since I don't code that way is the reason I'm leaving some doubt. Perhaps someone else here may know better. If so - jump in.

[LB]

Since you want to target multiple platforms, you should avoid directly using the Windows API unless you have to. Use a cross-platform library that abstracts the operating system from you and handles the portability issue for you.

[freddie1]

That's basically the advice I gave Steven in my 1st reply LB...

In your case, since you wish to write code that's platform agnostic, I see no alternative to the use of something like QT or wxWidgets....

But, if the multiple platform thing isn't really a requirement, then you have a lot of alternatives under Windows, and that would include pure Api and CLR and .NET.