- Forum
- Windows Programming
- Transitioning from console applications
Transitioning from console applications to windows applications
- Hello, I've been doing console programming for a while and I've just started to transition from console programming to windows programming.
- I've been reading many tutorials, and i have been looking at templates and functions on the msdn website, and in visual studio,etc.
- I just wanted to know if anyone could recommend the next step for me (i have a basic understanding about instances, windows--of instances--, handles, and event driven program), and any potential books that i should use.
- I've heard good things about Pretzold's(i believe that's the authors name) book, is this book still up to date, or is it outdated? If it is outdated, would you mind recommending other readings to me(feel free to do so even if it is not outdated)?
- I apologize in advance for the barrage of questions and my inexperience.
- I've been reading many tutorials, and i have been looking at templates and functions on the msdn website, and in visual studio,etc.
- I just wanted to know if anyone could recommend the next step for me (i have a basic understanding about instances, windows--of instances--, handles, and event driven program), and any potential books that i should use.
- I've heard good things about Pretzold's(i believe that's the authors name) book, is this book still up to date, or is it outdated? If it is outdated, would you mind recommending other readings to me(feel free to do so even if it is not outdated)?
- I apologize in advance for the barrage of questions and my inexperience.
- I've heard good things about Pretzold's(i believe that's the authors name) book, is this book still up to date, or is it outdated? If it is outdated, would you mind recommending other readings to me(feel free to do so even if it is not outdated)? |
No, the book isn't outdated, but some believe the underlying techniques espoused by Petzold might be. I don't feel that way, but some do. I've given my thoughts on the issue here ...
http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0
The only part that might be outdated are the graphics end of things. If you are into fancy graphics, then you'll likely want to use something other than GDI.
Last edited on
| freddie1 wrote: |
|---|
| No, the book isn't outdated, but some believe the underlying techniques espoused by Petzold might be. I don't feel that way, but some do. I've given my thoughts on the issue here ... http://www.jose.it-berater.org/smfforum/index.php?topic=3389.0 The only part that might be outdated are the graphics end of things. If you are into fancy graphics, then you'll likely want to use something other than GDI. |
- Ah i see. Well, i have a pdf copy of Petzolds fifth edition and the hardcover i ordered should be here by Friday or next Monday the latest.
- Before reading your article, it seemed to me that WinAPI/Win32 in C and "WinAPI/Win32 in C++" are the same thing. However, after reading your article , i do feel as though i'm writing in C and not C++, but i'm actually fine with that as i know a tad bit of C and it seems that i'm only using pre user defined structures,functions, and data types.
- They definitely use
typdefalot in WinAPI. When i started reading multiple tutorials, and looking at the VS 2012 template code, it seemed to be somewhat annoying. However, now it seems as though some of the names are reminiscent of the old 16-bit operating systems and others attempt to use Hungarian notation. In short, it does feel as though i'm coding in C when i'm writing code for WinAPI.
- Additionally, i've heard of wrappers such as MFC and i have only heard bad things about them such as "they are for lazy programmers who like to use other people's code" however, i've never heard the stance that you've taken. Do you really think that it's important to be familiar with how wrappers work in addition to regular WinAPI/Win32? As a result of what i had previously heard, i was shying away from MFC and other wrappers at least from the time being. The only positive thing i had heard about MFC previously is that it encapsulated WinAPI/Win32 in some ways.
There are so many aspects to this issue thejman that it would be hard to hit them all short of writing a 5000 word disertation on it. I personally prefer WinApi and mostly C'isms in my code. However, taking the 'devil's advocate' role, let me state that there are a lot of plusses to wrappers such as MFC and others.
For example, some folks believe its not worth it to get too wrapped up in UI code. According to that arguement, 'real' coders should concentrate on the non-visual logic type code that forms the most important part of most serious applications, for example, business logic. According to that arguement, use the easiest framework possible to generate user interface code. Or use the toolkit with the lowest learning curve. Or whatever. If something else comes into vogue in another year or two (and it will), move to that instead. Keep your code modular though - UI code seperate from logic code, so its easy to migrate. Persuing that line of arguement even further, why even use C or C++ to write the user interface, when it can be done so much easier and quicker in Visual Basic, .NET, or a host of others. Something that you'll likely not see written in this or any other C or C++ forum I'll state right now. And that is, that C and C++ are really, really poor choices for writing most Windows programs. In fact, casting about for some worse choice for writting Windows programs, the only thing I can come up with worse than C or C++, Win 32 Api, Petzold style, is assembler. And even that isn't too much harder than straight Petzold style Win32! For example, look at Iczelion's translations of Petzold's programs ...
http://win32assembly.programminghorizon.com/tutorials.html
which can also be obtained from Steve Hutcheson's MASM32 site.
Another issue is that the various wrapper frameworks oftentimes wrap functionality that is hard to learn, for example low level database access using ODBC, or ActiveX/COM. You could easy sink a couple years into learning those. With class frameworks, you can likely throw something together that'll work in a few months.
And if you use class frameworks, you'll reinforce the learning you did in console mode programming regarding usage of classes. You'll see how they are put together using inheritance.
Well, I've just made something of a case for not doing Petzold and Win32 Api.
I do it in spite of all of the above because I look at it as something of a labor of love. I think the way Microsoft built the Windows Api is a thing of immense intellectual beauty. I've dabbled with UI code in other operating systems, and I think its all ugly as sin compared to Windows. Just my opinion, for sure.
I'm actually a firm believer in OOP, but I seldom use a lot of C++ isms. I mostly do my OOP in C because I hate the code bloat C++ gives me. Also, as opposed to likely many here, I tend to shy away from heavy usage of inheritance in my code, preferring encapsulation. As such, my brand of OOP is closer to the COM way of doing things, and I use COM heavily. Well, I gotta go. Hope this help[s.
For example, some folks believe its not worth it to get too wrapped up in UI code. According to that arguement, 'real' coders should concentrate on the non-visual logic type code that forms the most important part of most serious applications, for example, business logic. According to that arguement, use the easiest framework possible to generate user interface code. Or use the toolkit with the lowest learning curve. Or whatever. If something else comes into vogue in another year or two (and it will), move to that instead. Keep your code modular though - UI code seperate from logic code, so its easy to migrate. Persuing that line of arguement even further, why even use C or C++ to write the user interface, when it can be done so much easier and quicker in Visual Basic, .NET, or a host of others. Something that you'll likely not see written in this or any other C or C++ forum I'll state right now. And that is, that C and C++ are really, really poor choices for writing most Windows programs. In fact, casting about for some worse choice for writting Windows programs, the only thing I can come up with worse than C or C++, Win 32 Api, Petzold style, is assembler. And even that isn't too much harder than straight Petzold style Win32! For example, look at Iczelion's translations of Petzold's programs ...
http://win32assembly.programminghorizon.com/tutorials.html
which can also be obtained from Steve Hutcheson's MASM32 site.
Another issue is that the various wrapper frameworks oftentimes wrap functionality that is hard to learn, for example low level database access using ODBC, or ActiveX/COM. You could easy sink a couple years into learning those. With class frameworks, you can likely throw something together that'll work in a few months.
And if you use class frameworks, you'll reinforce the learning you did in console mode programming regarding usage of classes. You'll see how they are put together using inheritance.
Well, I've just made something of a case for not doing Petzold and Win32 Api.
I do it in spite of all of the above because I look at it as something of a labor of love. I think the way Microsoft built the Windows Api is a thing of immense intellectual beauty. I've dabbled with UI code in other operating systems, and I think its all ugly as sin compared to Windows. Just my opinion, for sure.
I'm actually a firm believer in OOP, but I seldom use a lot of C++ isms. I mostly do my OOP in C because I hate the code bloat C++ gives me. Also, as opposed to likely many here, I tend to shy away from heavy usage of inheritance in my code, preferring encapsulation. As such, my brand of OOP is closer to the COM way of doing things, and I use COM heavily. Well, I gotta go. Hope this help[s.
| freddie1 wrote: |
|---|
| There are so many aspects to this issue thejman that it would be hard to hit them all short of writing a 5000 word disertation on it. I personally prefer WinApi and mostly C'isms in my code. However, taking the 'devil's advocate' role, let me state that there are a lot of plusses to wrappers such as MFC and others. For example, some folks believe its not worth it to get too wrapped up in UI code. According to that arguement, 'real' coders should concentrate on the non-visual logic type code that forms the most important part of most serious applications, for example, business logic. According to that arguement, use the easiest framework possible to generate user interface code. Or use the toolkit with the lowest learning curve. Or whatever. If something else comes into vogue in another year or two (and it will), move to that instead. Keep your code modular though - UI code seperate from logic code, so its easy to migrate. Persuing that line of arguement even further, why even use C or C++ to write the user interface, when it can be done so much easier and quicker in Visual Basic, .NET, or a host of others. Something that you'll likely not see written in this or any other C or C++ forum I'll state right now. And that is, that C and C++ are really, really poor choices for writing most Windows programs. In fact, casting about for some worse choice for writting Windows programs, the only thing I can come up with worse than C or C++, Win 32 Api, Petzold style, is assembler. And even that isn't too much harder than straight Petzold style Win32! For example, look at Iczelion's translations of Petzold's programs ... http://win32assembly.programminghorizon.com/tutorials.html which can also be obtained from Steve Hutcheson's MASM32 site. Another issue is that the various wrapper frameworks oftentimes wrap functionality that is hard to learn, for example low level database access using ODBC, or ActiveX/COM. You could easy sink a couple years into learning those. With class frameworks, you can likely throw something together that'll work in a few months. And if you use class frameworks, you'll reinforce the learning you did in console mode programming regarding usage of classes. You'll see how they are put together using inheritance. Well, I've just made something of a case for not doing Petzold and Win32 Api. I do it in spite of all of the above because I look at it as something of a labor of love. I think the way Microsoft built the Windows Api is a thing of immense intellectual beauty. I've dabbled with UI code in other operating systems, and I think its all ugly as sin compared to Windows. Just my opinion, for sure. I'm actually a firm believer in OOP, but I seldom use a lot of C++ isms. I mostly do my OOP in C because I hate the code bloat C++ gives me. Also, as opposed to likely many here, I tend to shy away from heavy usage of inheritance in my code, preferring encapsulation. As such, my brand of OOP is closer to the COM way of doing things, and I use COM heavily. Well, I gotta go. Hope this help[s. |
- I see, that's an interesting take on the situation.
- Well, i originally wanted to write windows programs in c++ as c++ is my main language, so i will probably move on to another (possibly more suitable ) language in the future. With that being said, i intend to focus on using c and c++ at the moment.
- Additionally, it seems that there is a good case for not learning WinAPI/Win32/Petzold however, i guess i'll just learn MFC and possibly other wrappers such as QT after i'm done with WinAPI as i feel like it would be a good foundation, and give me a lot of understanding (if not more). Thus, when i'm done with regular WinAPI i'll look into MFC and possibly other wrappers.
- An another note, do you know what the advantages and disadvantages of specific wrappers are (such as MFC or Qt) relatively to one another?
| i guess i'll just learn MFC and possibly other wrappers such as QT after i'm done with WinAPI as i feel like it would be a good foundation, and give me a lot of understanding (if not more). Thus, when i'm done with regular WinAPI i'll look into MFC and possibly other wrappers. |
The best approach here depends whether you are a "top-down" learner or a "bottom-up" learner.
IMO, wrapper libs are much, much easier to learn and use, and they teach you pretty much the same concepts. The downside is that they tend to add bloat.
Learning WinAPI first will definitely help if you move to something like Qt or wxWidgets. But starting with Qt/wx will help just as much if you move to WinAPI. The concepts are all pretty much the same.. the only thing that's different is the usage.
The best approach here depends whether you are a "top-down" learner or a "bottom-up" learner. |
That's an interesting concept Disch. The reason I say that is because it has always seemed to me too that there are various ways different folks have their heads wired. I've always thought that mine's likely wired weird, because I tend to find things hard that most other folks find easy, and vice versa.
I tried to learn MFC after already knowing a good bit of C Api style code, and after doing Windows in a couple of other languages too. And I couldn't believe how hard and awkward it was. At least for me. I could never reconsile that with the idea that this was somehow an easier way to write Windows programs. But my conclusion was that for some or most folks it probably was - just not for me.
I never really answered the OP's question as to whether its necessary to know the intimate details of the code being wrapped. I'm guessing that if the class design is good enough, it wouldn't be necessary to use a back door to get something done. I know I've read many opinions of folks such as Petzold himself (and other authors), who have stated that its good info to know.
The point that I've always fallen back to though is that Win32 Api (now Win64 too I guess) has been a very valid coding paradigm for a very long time - since the beginning of Windows really in 1986. That's an unbelievably long time for one coding technique to be viable in this rapidly changing field. In that period of time piles of coding frameworks have come and gone, but Win32 still remains. And I'm even beginning to think that now that Microsoft has its new WinRT thing with tablets, they'll just leave Win32/64 alone for us corporate/business/goverment/science folks who build that sort of software as opposed to consumer junk.
Topic archived. No new replies allowed.