- Forum
- Windows Programming
- Windows programming: where to start?
Windows programming: where to start?
Pages: 12
| My ultimate goal would be to create a more or less complex application |
What kind of application - GUI, game ?
For GUI I would recommend .NET with WPF and C#.
IMO only learn WIN32 for educational/information purposes. Nowadays nobody (ok somebody's going to say they do here to confirm the rule...) uses WIN32 to create an application.
There's also x-platform QT.
There's also x-platform QT.
Last edited on
I help maintain an active win32 MFC program. MFC/32 is astonishingly still very much alive, and will be for some time. But learning legacy tools just because someone out there maintains code in them is not time well spent unless you know you will be doing exactly that.
| Windows programming: where to start? |
There are several different, nearly exclusive, ways to go.
Overview of Windows Programming
https://docs.microsoft.com/en-us/cpp/windows/overview-of-windows-programming-in-cpp
When I was first learning Windows programming it was Win32 and Windows 98 all the way. "The Bible" was "Programming Windows, Fifth Edition" by Charles Petzold.
The 6th edition of his book was .NET and C# for Win 8/8.1.
The API (Application Programming Interface) for Windows apps is HUGE. Frameworks such as .NET or MFC try to hide all the nitty-gritty details.
If you want to learn Windows programming you should use Visual Studio. Yes, the bugger is HUGE, eating up a lot of HD space. But Windows IS MS, so why not use the IDE MS has. Tight integration and a decent debugger when needed.
VS 2019 is the current version, 2022 is still in preview status.
If having the best C++ standard compliance getting 2022 when it goes into full release status would be the thing to do. 2019 is 100% compliant now, but any C++20 defect fixes won't be patched in.
Some say winapi is legacy and it should no longer be learned because of modern ready and easy to use toolkits but I think the truth is opposite...
libraries such as MFC or Qt are legacy, these were first developed some 20 years ago, the code is vintage and upgrade to recent standard is likely not possible.
some say learning win32 is not productive because writing programs takes significantly more time which is ignorant statement because nobody would write always from scratch..
If you write class Window, class Button, class this and class that then reusing these classes is become productive on it's own.
Another major benefit is you can update and adjust your code when ever something doesn't work or whenever you want something to look differently or work better.
If you want UI library to be native and standard compliant and have all the flexibility then win32 is the only choice because none of the current libraries will offer you freedom to do it your own way.
libraries such as MFC or Qt are legacy, these were first developed some 20 years ago, the code is vintage and upgrade to recent standard is likely not possible.
some say learning win32 is not productive because writing programs takes significantly more time which is ignorant statement because nobody would write always from scratch..
If you write class Window, class Button, class this and class that then reusing these classes is become productive on it's own.
Another major benefit is you can update and adjust your code when ever something doesn't work or whenever you want something to look differently or work better.
If you want UI library to be native and standard compliant and have all the flexibility then win32 is the only choice because none of the current libraries will offer you freedom to do it your own way.
MFC was originally released in 1992, the last stable release was 24 July 2019. (According to wikipedia)
Two years since an update, still is a good track record that MS isn't completely discouraging developers from using it.
There have been newer versions released since that. One released yesterday (10 Aug) with the update to VS 2019.
Two years since an update, still is a good track record that MS isn't completely discouraging developers from using it.
There have been newer versions released since that. One released yesterday (10 Aug) with the update to VS 2019.
Last edited on
@Gary the Monkey
What do you mean by "WinAPI is older than..."?
don't all UI libraries use winapi?, can it go out of date or out of choice to develop new UI libraries, or is there an alternative?
What I wanted to say is that MFC, Qt and UI libraries in general are libraries that even though still updated go out of date by design, a design whose change is not possible.
by "design" I'm referring to:
1. Use modern and not so modern C++ features, ex. use of namespaces or use of modules and similar from recent standards.
2. A design that makes use of STL instead of implementing their own and forcing library user to learn UI specific containers and strings that are useful only within framework.
3. A design that is easy to upgrade and adapt to new C++ standards, upgrade that doesn't completely break existing codebases.
4. A design that is not all macros, one that doesn't force me to use library macros in my code.
Put aside companies that choose MFC or Qt, they do it so because it's cost effective, we are coders not company managers.
What do you mean by "WinAPI is older than..."?
don't all UI libraries use winapi?, can it go out of date or out of choice to develop new UI libraries, or is there an alternative?
What I wanted to say is that MFC, Qt and UI libraries in general are libraries that even though still updated go out of date by design, a design whose change is not possible.
by "design" I'm referring to:
1. Use modern and not so modern C++ features, ex. use of namespaces or use of modules and similar from recent standards.
2. A design that makes use of STL instead of implementing their own and forcing library user to learn UI specific containers and strings that are useful only within framework.
3. A design that is easy to upgrade and adapt to new C++ standards, upgrade that doesn't completely break existing codebases.
4. A design that is not all macros, one that doesn't force me to use library macros in my code.
Put aside companies that choose MFC or Qt, they do it so because it's cost effective, we are coders not company managers.
Last edited on
well even WinRT is based on WinAPI from what I remember..
it would be worth looking at it but from what I see many people don't.
I guess because using new MS technology is always countered with skepticism.
WinRT seems like .NET way of writing framework for C++, which may be why it's not as popular, surely the performance is slightly worse than native API.
WinRT is language and platform agnostic which surely has some drawbacks, maybe someone who use it can explain downsides...
it would be worth looking at it but from what I see many people don't.
I guess because using new MS technology is always countered with skepticism.
WinRT seems like .NET way of writing framework for C++, which may be why it's not as popular, surely the performance is slightly worse than native API.
WinRT is language and platform agnostic which surely has some drawbacks, maybe someone who use it can explain downsides...
What I wanted to say is that MFC, Qt and UI libraries in general are libraries that even though still updated go out of date by design, a design whose change is not possible. |
This is to ensure full employment for programmers. Where I used to work we had a mission critical application built by an outside contractor where a Windows Class Framework was utilized. Every couple years the class framework was updated so we had to spend another couple hundred thousand dollars every couple years to upgrade to the new version (it was a multi-million dollar class application). Of course, every version became more bloated and slower with dependencies and so forth, so we had to buy more powerful hardware to run the application. All kinds of money involved. Good for programmers, Good for hardware manufacturers, so on and so forth. It's what makes the world go round.
Eventually I coded the whole application Win32 Api SDK style using PowerBASIC. Eventually the creator of the PowerBASIC programming language passed away and for a backup I recoded the entire thing in C++ (C++ will outlive Bjarne Stroustrup). The C++ version I still have for a backup if ever needed, but it has never been needed. The organization is still running my PowewrBASIC 32 bit executable (this has been going on for like 20 years now).
This was an application (not mine - the original) that an army of coders worked on for several years. At best it only ever half worked. Sound familiar? When I recoded it in PowerBASIC Win32 SDK style there were two seperate executables involved which came to about 1200K, however they each compressed to around 175k or so. These were stand alone executables requiring no run time dependencies other than a 32 bit Windows Operating System. No installation was ever needed; users could stick the executables on a server and pull them across the wire, or run them local.
My C++ versions were even a bit smaller than the PowerBASIC versions but to accomplish that I used my own custom C Runtime and my own classes (nothing from C++ Standard Library - too much bloat there under Windows).
I've really no recommendations for the original poster. I'm astounded Microsoft still allows Win32 SDK code to work. I guess for various technical reasons known only to them they have to. I guess if I were just starting out now even I would have to go the class framework route. One has to do what one has to do to survive.
| I guess if I were just starting out now even I would have to go the class framework route |
I'd hope not @freddie1, your story offers fairly compelling, if anecdotal, evidence that you were (are) onto something.
| I'm astounded Microsoft still allows Win32 SDK code to work. |
First there was DOS and Win16. Then Win32, and now Win64, somewhat. The two are linked together in a few places.
Should Windows continue to evolve* one day I expect Win32 to become as inviable as Win16 is now with current Windows systems.
IOW, deader than a Dodo.
*Can anyone say Windows 125?
| Should Windows continue to evolve* one day I expect Win32 to become as inviable as Win16 is now with current Windows systems. |
This is already true, Win32 is no longer called Win32, it's WinAPI.
And I don't think WinAPI will go out of scope anytime in the future.
WinAPI is an umbrella term for various APIs available for the multiple Windows versions, a catch-all for previous and future API versions. The name change reflects its roots in 16-bit Windows, through 32-bit Windows and onto 64-bit Windows.
Win32 was specific to Windows for 32-bit architecture machines, with some slurp over to 64-bit since 64-bit Windows can run 32- and 64-bit apps.
My comment was about future versions of Windows no longer natively supporting 32-bit apps, much the same as current Windows, Win10, doesn't really support 16-bit apps natively. With a 3rd party framework and some rejigging of Windows it is possible. Easier if the OS is 32-bit than 64-bit.
Win32 was specific to Windows for 32-bit architecture machines, with some slurp over to 64-bit since 64-bit Windows can run 32- and 64-bit apps.
My comment was about future versions of Windows no longer natively supporting 32-bit apps, much the same as current Windows, Win10, doesn't really support 16-bit apps natively. With a 3rd party framework and some rejigging of Windows it is possible. Easier if the OS is 32-bit than 64-bit.
@kameshbhai511
add to that 1TB drive at least 500GB SSD.
But, what do you mean by "most of the games are developing in PYthon language"?
are you joking? I never heard of game running on an interpreter lol
add to that 1TB drive at least 500GB SSD.
But, what do you mean by "most of the games are developing in PYthon language"?
are you joking? I never heard of game running on an interpreter lol
| The post you're replying to is giving off huge "bot-generated" vibes. |
A post that has now joined with the Galactic Aether Winds.
What happened to this thread? Looks like reasonable replies have been removed along with the cruft.
Nah, IMO by the look of things the only stuff removed was that of the user who closed their account.
And some schmutz bot action.
There's been an increased number of hissy fits from new users lately, leeching info from here as if we are required to be their unpaid tutors that end in closed accounts.
And some schmutz bot action.
There's been an increased number of hissy fits from new users lately, leeching info from here as if we are required to be their unpaid tutors that end in closed accounts.
There is some mention of WinRT in a seeming one sided conversation, any idea what the other side was?
I'm not sure I agree with malibor on it but I'm only seeing one side and I'm no expert on it...yet :-)
I'm not sure I agree with malibor on it but I'm only seeing one side and I'm no expert on it...yet :-)
Well, in a nutshell (and very much IMO) the now booted closed account user complained from the get-go that CPlusPlus wasn't a resource that was up to his standards of free information, being years out of date. Demanded the site owner cater to his whims and wants.
The closed account posts were pretty much in the vein of "WinAPI is dead because I say so."
Nothing to lose sleep over, really. I like reading the differing opinions of others, even if happen to believe one side or the other. As long as it is a discussion and civil.
When things turn Holy War, then I vacate.
The closed account posts were pretty much in the vein of "WinAPI is dead because I say so."
Nothing to lose sleep over, really. I like reading the differing opinions of others, even if happen to believe one side or the other. As long as it is a discussion and civil.
When things turn Holy War, then I vacate.
Pages: 12