- Forum
- Windows Programming
- Windows API and current programing
Windows API and current programing
I was scanning through E-Bay tonight because the book I currently have states that it is briefly going to cover making a window using Windows API and then move on to other ways of writing Windows code (MFC and Forms).
What I noticed on E-Bay is that books based on Windows API all drop off after windows 2000. So I was wondering if coding with Windows API is still the norm, or if most people are now using windows forms or Windows MFC.
If I were to learn one of these (Forms, MFC, API) which would be the best choice?
What I noticed on E-Bay is that books based on Windows API all drop off after windows 2000. So I was wondering if coding with Windows API is still the norm, or if most people are now using windows forms or Windows MFC.
If I were to learn one of these (Forms, MFC, API) which would be the best choice?
I don't know a ton about the subject, but MFC is really just a wrapper for WinAPI. It turns the API into something that is higher level. If you want to learn the basics of windows programming, go for the API. If you want to make something useful without re-inventing the wheel, go for MFC.
OK, so changing the topic a little, do you know if a code written for WinAPI would run faster than a code written in MFC?
I know that one using forms supposedly doesn't run as fast because it holds a lot of extra auto-coding behind it.
I know that one using forms supposedly doesn't run as fast because it holds a lot of extra auto-coding behind it.
The difference would likely be neglidgible, as they are both running native code. There would simply be the overhead with MFC of a function wrapper or two, and that isn't much. In some cases it might make a difference though.
In terms of size, with MFC you would likely have to distribute the MFC dll with your executable. It used to be around a Megabyte, but might be bigger now.
The reason I personally never got too much into MFC is that it seemed a lot harder to me than just the Api direct method. I know that's strange, because the whole purpose of MFC was to make life easier for coders - not harder. All I can say to that is that everybody'd head is wired a little different, and for me it was harder. Maybe my head's wired in some unusual way. I think for most folks its easier.
On the other hand, what might have made the difference for me was my commitment to C++. For me, that was never very strong. I've only ever used those parts of C++ that I saw as a definite improvement over C. And for me, that wasn't that much. Therefore, when trying to unravel the complexities of MFC, which involved wrapping the underlying API with a C++ based class framework, I saw it as just substituting one type of complexity for another with a net gain of zero - and less than zero if you then factor in the fact that every object call had to be translated through one or two wrappers, and you would now have to distribute a dll dependency. So I guess I've just made the case for direct Api - although that wasn't my initial intention. But I tend to run on.
Getting back to your initial question though. I don't think you would see much difference in speed. The optimazations of the modern C++ compilers are awesome, and pretty much unravel a lot of the smokescreen and misdirections put up class frameworks.
In terms of size, with MFC you would likely have to distribute the MFC dll with your executable. It used to be around a Megabyte, but might be bigger now.
The reason I personally never got too much into MFC is that it seemed a lot harder to me than just the Api direct method. I know that's strange, because the whole purpose of MFC was to make life easier for coders - not harder. All I can say to that is that everybody'd head is wired a little different, and for me it was harder. Maybe my head's wired in some unusual way. I think for most folks its easier.
On the other hand, what might have made the difference for me was my commitment to C++. For me, that was never very strong. I've only ever used those parts of C++ that I saw as a definite improvement over C. And for me, that wasn't that much. Therefore, when trying to unravel the complexities of MFC, which involved wrapping the underlying API with a C++ based class framework, I saw it as just substituting one type of complexity for another with a net gain of zero - and less than zero if you then factor in the fact that every object call had to be translated through one or two wrappers, and you would now have to distribute a dll dependency. So I guess I've just made the case for direct Api - although that wasn't my initial intention. But I tend to run on.
Getting back to your initial question though. I don't think you would see much difference in speed. The optimazations of the modern C++ compilers are awesome, and pretty much unravel a lot of the smokescreen and misdirections put up class frameworks.
Thanks Freddie1, That was actually a much better explanation than how my book said it. I guess I'll learn MFC for now since that's what my current book will be covering, but I'll also get a book on API and will just have to decide which makes sense for me.
Do you have any recommendations of a good API book?
Do you have any recommendations of a good API book?
The Windows API doesn't scale. It gets increasingly difficult to develop and maintain a large Windows application using the API directly. MFC allows you to use the Object Oriented facilities of C++ to wrap Windows objects and application objects and move programming to a slightly level.
Topic archived. No new replies allowed.