how can i use c++ to create professional windows application

hello friends ^_^
first of all thanks for creating this community.

i just learned c++ and i can program almost everything i want in it (thanks god, it was my dream came true), and now i want to go one step ahead and create some applications with graphical user interface. so here are my questions:
1. whats best softwares that can help me? (i am looking for powerful softwares, i mean something like unity but for creating application instead of game)
2. whats the libraries and other things that i can use them to create application for windows, mac and other oses (i prefer to create my application without using any other software and i want to know how you can create GUI application, 0-100 with c++ coding)

anyways please give an advise that what should i do and where should i start.

thanks everyone :)
Last edited on
closed account (E0p9LyTq)
Using Microsoft's Visual Studio Integrated Development Environment to create Microsoft Windows applications is not a bad way to go.

Programming for Windows isn't easy, no matter what tools you use.
http://zetcode.com/gui/winapi/
http://www.winprog.org/tutorial/
If you want to create a cross platform GUI app you need to use a framework.
Some options:
FLTK => https://en.wikipedia.org/wiki/FLTK
GTK+ =>https://www.gtk.org/
Qt = > https://en.wikipedia.org/wiki/Qt_(software)
wxWidgets => https://en.wikipedia.org/wiki/WxWidgets
JUCE => https://en.wikipedia.org/wiki/JUCE


closed account (E0p9LyTq)
To show you how complicated Windows programming can be a few examples follow, here is a very simple C++ console mode program:
1
2
3
4
5
6
#include <iostream>

int main()
{
   std::cout << "Hello World!\n";
}


Here is a bare-bones Windows program in C/C++:
1
2
3
4
5
6
7
8
#include <windows.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
   MessageBox(NULL, TEXT("Hello World!"), TEXT("Hello Message"), MB_OK);

   return 0;
}


To create a minimal Windows GUI application in C/C++ requires a lot more work (lots of comments to explain the code, compiled as C++ source):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
// a minimal Windows API application skeleton

// INCLUDES ====================================================================
#include <windows.h>

// FUNCTION PROTOTYPES =========================================================
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);


// entry point for a Windows application =======================================
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int nWinMode)
{
   // define the window class name
   static const TCHAR szAppName[] = TEXT("WIN_API");

   // create an instance of the window class structure
   WNDCLASSEX wc;

   wc.cbSize        = sizeof(WNDCLASSEX);
   wc.style         = CS_HREDRAW | CS_VREDRAW;
   wc.lpfnWndProc   = WndProc;
   wc.cbClsExtra    = 0;
   wc.cbWndExtra    = 0;
   wc.hInstance     = hInstance;
   wc.hIcon         = (HICON)   LoadImage(NULL, IDI_APPLICATION, IMAGE_ICON, 0, 0, LR_DEFAULTCOLOR);
   wc.hIconSm       = (HICON)   LoadImage(NULL, IDI_APPLICATION, IMAGE_ICON, 0, 0, LR_DEFAULTCOLOR);
   wc.hCursor       = (HCURSOR) LoadImage(NULL, IDC_ARROW, IMAGE_CURSOR, 0, 0, LR_SHARED);
   wc.hbrBackground = (HBRUSH)  (COLOR_WINDOW + 1);
   wc.lpszMenuName  = NULL;
   wc.lpszClassName = szAppName;

   if (0 == RegisterClassEx(&wc))
   {
      MessageBox(NULL, TEXT("Can't Register the Window Class!"), szAppName, MB_OK | MB_ICONERROR);
      return E_FAIL;
   }

   // define the application title
   static const TCHAR szAppTitle[] = TEXT("Win32 API Skeletal Application");

   // create the window
   HWND hwnd = CreateWindow(szAppName, szAppTitle,
                            WS_OVERLAPPEDWINDOW,
                            CW_USEDEFAULT, CW_USEDEFAULT,
                            CW_USEDEFAULT, CW_USEDEFAULT,
                            NULL, NULL, hInstance, NULL);

   // check if the window was created, exit if fail
   if (NULL == hwnd)
   {
      MessageBox(NULL, TEXT("Unable to Create the Main Window!"), szAppName, MB_OK | MB_ICONERROR);
      return E_FAIL;
   }

   // show and update the window
   ShowWindow(hwnd, nWinMode);
   UpdateWindow(hwnd);

   static BOOL bRet;
   static MSG  msg;

   // enter the main message loop
   while ((bRet = GetMessage(&msg, NULL, 0, 0)) != 0) // 0 = WM_QUIT
   {
      // check for error
      if (-1 == bRet)
      {
         // handle the error and possibly exit

         // for this app simply report error and exit
         MessageBox(NULL, TEXT("Unable to Continue!"), szAppName, MB_OK | MB_ICONERROR);
         return E_FAIL;
      }
      else
      {
         TranslateMessage(&msg);
         DispatchMessage(&msg);
      }
   }

   // the app is done, exit normally, return control to Windows
   return (int) msg.wParam;
}


// processes the messages that Windows sends to the application ================
LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
   // choose which Windows messages you want to use
   switch(message)
   {
   case WM_PAINT:
      HDC         hdc;
      PAINTSTRUCT ps;
      hdc = BeginPaint(hwnd, &ps);

      // draw some text centered in the client area
      RECT rect;
      GetClientRect(hwnd, &rect);
      DrawText(hdc, TEXT("This is a skeletal Windows application!"), -1, &rect, DT_SINGLELINE | DT_CENTER | DT_VCENTER);

      EndPaint(hwnd, &ps);
      return S_OK;

   case WM_DESTROY:
      // exit the application
      PostQuitMessage(0);
      return S_OK;
   }

   // let Windows process any unhandled messages
   return DefWindowProc(hwnd, message, wParam, lParam);
}


The Windows Application Programming Interface (API) was created using C. Microsoft created the MFC (Microsoft Foundation Class) library to leverage the power of C++ to create Windows apps.

WIN_MFC.h:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// derive essential MFC classes

#pragma once

#include <afxwin.h>

// main window class
class CMainWnd : public CFrameWnd
{
public:
   CMainWnd();

private:
   DECLARE_MESSAGE_MAP()
};


// application class
class CTheApp : public CWinApp
{
public:
   BOOL InitInstance();
};


WIN_MFC.cpp:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// listing 1-4 - a minimal MFC program

#include "WIN_MFC.h"

// construct a window
CMainWnd::CMainWnd()
{
   Create(NULL, __T("An MFC Application Skeleton"));
}

// initalize the application
BOOL CTheApp::InitInstance()
{
   m_pMainWnd  = new CMainWnd;

   m_pMainWnd->ShowWindow(m_nCmdShow);
   m_pMainWnd->UpdateWindow();

   return TRUE;
}


// application's message map
BEGIN_MESSAGE_MAP(CMainWnd, CFrameWnd)
END_MESSAGE_MAP()


// instantiate the application
CTheApp  theApp;

create application for windows, mac and other oses (i prefer to create my application without using any other software and i want to know how you can create GUI application, 0-100 with c++ coding)


In a sense, your goals are somewhat mutually exclusive, and like many things in life, you have to make hard choices. Here's what I mean....

There isn't a standard C++ way of creating apps with GUIs. GUIs aren't part of the C or C++ standards. So to create GUIs with C or C++ you absolutely need platform specific libraries or frameworks.

Having said that, all operating systems have platform specific low level APIs (Application Programming Interfaces) for creating GUI apps. The keywords above are 'platform specific'. You could sink a lot of time into learning the low level Windows Api (Furry Guy posted some code above), but it would be useless to you for creating Mac, Android, Linux, or any other OS app.

The answer to that would be the cross language frameworks which provide a high level abstraction layer which you code against, and then the framework generates code for each specific operating system. In that way you'll be using the C++ language, but its use would be somewhat in conflict with your other goal of using a minimal of framework or library code - hense the 'hard choices' I mentioned at first.

The hard choice I've personally made is to mostly limit myself to Windows and write low level Api code which runs close to 'bare metal', i.e., its not being filtered down through piles of higher level 'abstraction layers' of framework code. But it definitely won't run on Mac or Linux.

hi again;
thanks all of you for replies, now i have a general understanding of what i am looking for but still i got a few questions:

@FurryGuy
Microsoft Windows applications is not a bad way to go.

some one told me windows forms application is good for c# but not good for c++. idk if its true or not. (btw i am so comfortable with visual studio and i like it so much, i wish it had good things for gui too)

for your second reply:
To show you how complicated Windows programming can be

everything will be complicated when you don't know anything about it and in this case i read the codes that you sent. i can understand everything but functions you used, if i learn this functions i don't think i would have problem.

@Thomas1965
thanks so much! i checked links and it helped me a lot. but my question is whats the best cross platform GUI? (fastest, strongest - i don't care about price of the software)
i searched and i find out that QT and GTK+ are more popular and recommend by more people but i still want to know your opinion.

@freddie1
so you recommend using cross platform GUIs, right? but why yourself doesn't use them? i mean whats the weakness of cross platform GUIs that you prefer limit yourself and do the harder way but not using them.

at the end i have one question that if i find an answer for it i think i am good to start:
in professional applications or softwares that has been written in c++ like Itunes or browsers like Google chrome or Microsoft edge, enterprises use Cross Platform GUIs or use low level Api and why?
also in case they are using Cross (or single) Platform GUIs, which software they use mostly?

again thanks everyone :)
Last edited on
but my question is whats the best cross platform GUI?
I am afraid there is not satisfying answer. It like asking "What's the best religion?" or "What's the best programming language".

Personally I prefer C# WinForms for GUI apps because I found it easiest to use. Together with Xamarin you can use it for many platforms like Android, Apple store

What are your intensions? Do you want to write apps for yourself and friends or do you want to sell your apps in an app store or do you want to become a professional programmer?

Some professional programmers I know use C++ only for the backend and use Java, HTML or C#/WPF for the front end(GUI)
If no one said it, it is usually best to wrap all your code up without any GUI junk in it on the front end. Then you can use any gui you want, and just call your code from there. It can be tempting to write the code in tandem with the GUI tools ... and then you are tied to one choice and quickly the code becomes a mess. Get everything working apart from the interface first for large projects.

If you really need cross platform, call the C++ library that does all the work from Java is a strong choice. Most non windows machines have a windows emulation that can run the windows program, is that acceptable for the project? They are a little sluggish for games but do OK for everything else.


@freddie1
so you recommend using cross platform GUIs, right? but why yourself doesn't use them? i mean whats the weakness of cross platform GUIs that you prefer limit yourself and do the harder way but not using them.


Well, since you asked…

It sounds like you are interested in having your code work with multiple platforms, so, yes, that would be my recommendation to you, i.e., a cross platform framework. The only other alternative would be learning the Apis of each of the platforms for which you want to code.

There are two reasons I don’t use cross platform tookkits.

First, I don’t need one. I work for a large organization that manages millions of acres of forest land and is involved in large scale forest management and timber harvesting, and I write all the code which manages this. And we only use Windows. Our desktop systems only run Windows, and our handheld data recorders run various incarnations of Windows CE, Windows Mobile, or Windows Embedded. All these I coded directly against the Windows API.

Secondly, I’m old. I started out in coding when hardware had next to no memory by today’s standards, and processors were slow. It was critical to write high performance small code. You can’t do that with cross platform frameworks. These all depend on super fast processors and massive amounts of RAM. Which all modern hardware has. So it isn’t a problem. But for me personally, I get no satisfaction from writing such code. So I don’t do it or use any coding techniques or tools which don’t generate code I’m not proud of or code which doesn’t give me any satisfaction. There aren’t many like me, but I’m not completely alone. To get an idea of what I’m talking about, check these out…

http://lispian.net/2011/11/01/lasagna-code/

http://lispian.net/2011/11/25/lasagna-code-redux/

In fact, I’ve taken that issue so far that I don’t even use the standard C++ setup of runtime systems to generate my code. I tend to use Microsoft’s C++ compiler, but I’ve written my own replacements for both the C Standard Library and the C++ Standard Library. Perhaps it might be well to dwell on this a bit. You’ve already looked at FurryGuy’s Win Api and MFC code. Here is a somewhat condensed version of FurryGuy’s Api code with some comments and unnecessary error handling code removed for simplification purposes…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
#ifndef UNICODE
   #define UNICODE
#endif
#ifndef _UNICODE
   #define _UNICODE
#endif   
#include <windows.h>


LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
   switch(message)
   {
     case WM_PAINT:
       {
          HDC         hdc;
          RECT        rc;
          PAINTSTRUCT ps;
          hdc = BeginPaint(hwnd, &ps);
          GetClientRect(hwnd,&rc);
          DrawText(hdc, L"This is a skeletal Windows application!", -1, &rc, DT_SINGLELINE | DT_CENTER | DT_VCENTER);
          EndPaint(hwnd, &ps);
          return 0;
       }   
     case WM_DESTROY:
       {
          PostQuitMessage(0);
          return 0;
       }   
   }

   return DefWindowProc(hwnd, message, wParam, lParam);
}


int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int nWinMode)
{
   wchar_t szAppTitle[] = L"Win32 API Skeletal Application";
   wchar_t szAppName[]  = L"WIN_API";
   HWND hwnd            = NULL;
   WNDCLASS             wc;
   MSG                  msg;
   
   memset(&wc,0,sizeof(wc));
   wc.lpszClassName = szAppName;
   wc.lpfnWndProc   = WndProc;
   wc.hInstance     = hInstance;
   wc.hbrBackground = (HBRUSH)  (COLOR_WINDOW + 1);
   RegisterClass(&wc);   
   hwnd = CreateWindow(szAppName, szAppTitle, WS_OVERLAPPEDWINDOW,200, 200, 800, 600, NULL, NULL, hInstance, NULL);
   if(hwnd)
   { 
      ShowWindow(hwnd, nWinMode);
      while(GetMessage(&msg,NULL,0,0))   
      {
         TranslateMessage(&msg);
         DispatchMessage(&msg);
      }  
   }   
      
   return (int) msg.wParam;
}


That code above and FurryGuy’s original will produce a stand alone executable (built with /MT Linkage to C Runtime) of 37,888 bytes in x86 or 39,936 bytes in x64 as Release builds with VC15 from Visual Studio 2008. With Visual Studio 2015 and VC19, which you likely use, those numbers would be about double or a bit more.

The code produces a window/dialog/Form with a line of text across the middle. Built like that you would be able to distribute it to your friends or anyone else as just a simple exe file and it would run if put anywhere on their PC. However, if you built it with /MD linkage (see Code Generation Tab in Project Properties), it would require a large multi-megabyte setup program and redistributable for it to run on another PC.

Likewise if you built it with MFC. It would then require the MFC Library of the proper version for it to run on another PC.

Ditto for cross platform toolkits. There would be multi-megabytes of dlls and other stuff to get the program to run on another machine.

Using my custom runtimes, which I use in conjunction with C++, I can build the above program in 3,072 bytes in x86 or 4,096 bytes in x64. And these are stand alone executables. My command line compilation string for that would be this…

cl Form1.cpp /O1 /Os /FeForm2.exe /GR- /GS- TCLib.lib kernel32.lib user32.lib gdi32.lib

So, like I said….you asked.
Last edited on
Topic archived. No new replies allowed.