Do you guys think this book is outdated?

This is a discussion on Do you guys think this book is outdated? within the Windows Programming forums, part of the Platform Specific Boards category; I want to buy this book but I would hate to be reading outdated information. Programming Windows, 5th edition, Charles ...

  1. #1
    C lover
    Join Date
    Oct 2007
    Location
    Virginia
    Posts
    265

    Do you guys think this book is outdated?

    I want to buy this book but I would hate to be reading outdated information.

    Programming Windows, 5th edition, Charles Petzold (ISBN: 1-57231-995-X)

    So two questions:

    1) Do you guys think this book is outdated and would be a wasted effort? If yes, could you recommend something else for win32 programming?

    2) Does anyone even use Win32 directly anymore?

  2. #2
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Hello Syscal...

    To answer your questions...

    Any book on windows published before 2009 is going to be outdated because of the sweeping changes made with Windows 7. The only real authority at this time is the Microsoft published Windows Software Deveopment Kit which is a full disclosure of all windows function calls, and includes code samples and tools.
    Download details: Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1

    That said... any book on windows programming is going to relate at least basic concepts and program structures that have been in use since Windows began. Even though it doesn't cover anything newer than Windows ME, the Peltzoid book is still one of the better "getting started" manuals.

    Do people still work at the Windows api level... Heck yes. I do it every day. It's still the best way to produce small, fast and trouble free software for Windows. If portability is not a concern then all those needless layers of "abstraction" in Java, .NET etc. are nothing but wasted memory, time and code.

    To give you an example: I'm currently in "late alpha" phase (i.e. in limited testing while I write the help files) of a project I'm hoping to release as freeware just after New Years... The project includes three programs, all under 200k in size, written entirely in C (PellesC to be exact). If I'd gone with the currently popular choices of Java or one of the other cross platform systems, my program sizes would be 1mb or more and the whole thing would run at about half it's present speed.

    So, yes, Windows API level programming is still a 100% viable option for any programmer who's looking to suck the best performance from the smallest code sizes.

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    With the added cost of complexity and development time, of course. It's up to you to determine if it's worth it or not.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    With the added cost of complexity and development time, of course. It's up to you to determine if it's worth it or not.
    Well, I don't think it's more complex than say Java...

    There is some added development time but given the current project is a hobby thing, worked on mostly in spare time, I have no way of guaging how much.

    Personally, I've always preferred to get "down and dirty" with the machine. I started out writing diagnostics in ASM then Pascal on z-80 machines, so I guess that's where I got most comfortable.

    I've looked at OOP languages like C++ etc. and quite frankly can't make heads or tails of them. It would take me longer to learn the language than it took to complete this project.

  5. #5
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Java/C++ is much easier, if you ask me.
    There are also frameworks for C for GUI. Though object-oriented languages are better suited for this since OO is really suited for GUI.

    Anyway, the thing is also that to you, OOP languages doesn't sound like the right tool for the job. To some it does. To some it doesn't. But it doesn't change the fact that Win32 API is very low-level and complex. And there are frameworks that can take away some of that complexity, regardless of what language.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    Java/C++ is much easier, if you ask me.
    There are also frameworks for C for GUI. Though object-oriented languages are better suited for this since OO is really suited for GUI.

    Anyway, the thing is also that to you, OOP languages doesn't sound like the right tool for the job. To some it does. To some it doesn't. But it doesn't change the fact that Win32 API is very low-level and complex. And there are frameworks that can take away some of that complexity, regardless of what language.
    No argument.... For someone just learning or at least taking up the craft after the whole OOP think started, I should think it would be easier. Half the work is done by the IDE these days, programming has become almost multiple choice...

    However; most of us are best at what we learn first, then everything else is either filtered through that or compared to it.

    You are quite correct that this old codger (60 next summer) is happier with the lower level stuff. I've tried making sense of C++ and the minute objects and methods get tossed in this old head just freezes right up... And not for the lack of trying, I assure you.

    FWIW... My Windows code is GUI based, buttons, toolbars, popup lists and tootips... all the good stuff. LOL. Here's a little screen shot, just to give you a bit of a tease about my upcoming project release.
    Last edited by CommonTater; 03-16-2011 at 11:52 AM.

  7. #7
    Registered User
    Join Date
    Oct 2010
    Posts
    1
    Quote Originally Posted by CommonTater View Post
    You are quite correct that this old codger (60 next summer) is happier with the lower level stuff. I've tried making sense of C++ and the minute objects and methods get tossed in this old head just freezes right up... And not for the lack of trying, I assure you.
    LOL. I'm 46 and definitely with you on this. C++ aint no big deal, but I like being in the "driver's seat" when it comes to programming. I really like it when I see:

    mov ax, ??
    inc ax
    move ??, ax
    etc...

    At least THEN I get to say, "Oh! That's what the damned thing is actually doing!" The increasing levels of abstraction may get the job done faster, but the resulting product gets worse and worse. I don't know exactly what it's written in, but my VZAccess Manager for my wireless Internet connection must be written in one of these "higher-level" langs like Java or whatever because it is slow as snot in January!

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    I'd be careful with those words.
    Abstraction raises the quality of the code, and raising the quality of the code raising the quality of the product. In other words, the quality of the product is proportional to the abstraction level.
    Of course, that doesn't mean there are other variables affecting the outcome, as well. The experience of the developer, for example.
    And I wouldn't say that all high-level languages are slow. Java, C#, etc may be slower, that is true, but C++ can beat C at its own game if done properly.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    I'd be careful with those words.
    Abstraction raises the quality of the code, and raising the quality of the code raising the quality of the product. In other words, the quality of the product is proportional to the abstraction level.
    Of course, that doesn't mean there are other variables affecting the outcome, as well. The experience of the developer, for example.
    I suppose "quality" might be defined in different ways but I don't see how "more code is better" works for the benefit of anyone except the poor schlub that's paid by the byte.

    On Windows OSs, code sizes, for even relatively simple functionality, have been increasing steadily since the early 1990s when OOP entered widespread use in Delphi. Larger code sizes generally mean more bugs and/or reduced performance.

    A cute little story from my Pascal days... I was trying to learn Delphi and downloaded this example program to study. It was a real simple MCI player, had a dialog to open a file and a quit button to exit, no transport controls. Thing compiled at about 1.3mb so I rewrote the same functionality at winapi level in Pascal for an 18K program size. I then continued on to add a display for the filename, play, pause, stop buttons and a seek bar which drove the program size up to a wopping 43k.

    Think how compact --and how fast-- Windows could be if they'd stuck with it's C roots... Windows 7 installs at about 8gb... I'm betting that if it were written entirely in procedural code without all the bs about direct X, .net, java, etc, etc, etc ... if they'd stuck to grass roots code... they could provide the same functionality in under 2gb.

    Is it better because there's a ton of methods and abstractions in there?
    Given some of Win7's problems... I'd be prone to debate the assertion.

    Is user code better because of abstration?
    I'd say that's debatable. While it may be more portable, I seriously doubt that OOP and Abstraction bring much else to the table.

    I do find myself wondering how many "bugs" actually go undetected because they are buried in levels of code the programmer has no access to...

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by CommonTater View Post
    I suppose "quality" might be defined in different ways but I don't see how "more code is better" works for the benefit of anyone except the poor schlub that's paid by the byte.

    On Windows OSs, code sizes, for even relatively simple functionality, have been increasing steadily since the early 1990s when OOP entered widespread use in Delphi. Larger code sizes generally mean more bugs and/or reduced performance.
    Do you honestly believe that high-level languages mean more code? It's the other way around. What can be accomplished in C in 100 lines of code can be done in, say, 10 lines of code in a higher-level language.

    A cute little story from my Pascal days... I was trying to learn Delphi and downloaded this example program to study. It was a real simple MCI player, had a dialog to open a file and a quit button to exit, no transport controls. Thing compiled at about 1.3mb so I rewrote the same functionality at winapi level in Pascal for an 18K program size. I then continued on to add a display for the filename, play, pause, stop buttons and a seek bar which drove the program size up to a wopping 43k.
    Also, don't forget this: a lot of code with higher-level languages comes in libraries. Well-tested, powerful and fast. And also take up a lot of space since it has a lot of functionality.
    With your Delphi example, you likely statically linked your executable, bringing in all that code into your executable as compared to your pure C approach which relied only on Windows code. But that doesn't matter.
    Compare the size of the code written to make it work in Delphi vs C. You will probably see a large difference.

    Think how compact --and how fast-- Windows could be if they'd stuck with it's C roots... Windows 7 installs at about 8gb... I'm betting that if it were written entirely in procedural code without all the bs about direct X, .net, java, etc, etc, etc ... if they'd stuck to grass roots code... they could provide the same functionality in under 2gb.
    Absolute and utter nonsense. Suggest you research what exactly is contained in a Windows installation. It isn't just code. And had they written all of it in C, it would have been buggy as hell.
    Now, how do I figure that? Because even if you are a good C programmer, the language wasn't built for modern needs in mind. Simply put, what can be written easily, safely and in a few lines of code in a higher-level language takes a lot longer and more lines of code in C. Cover it up all you want, make it pretty, whatever, but it's still fact. Hard cold truth.

    Is it better because there's a ton of methods and abstractions in there?
    Given some of Win7's problems... I'd be prone to debate the assertion.
    There would be 10 tons of code if it was written entirely in C.
    Also consider that Microsoft itself isn't all to blame. 3rd party software and drivers cause a lot of trouble.

    Is user code better because of abstration?
    I'd say that's debatable. While it may be more portable, I seriously doubt that OOP and Abstraction bring much else to the table.
    You are misguided. That OOP and abstraction makes code "better" is a known fact. A proven fact. That is why it's used in modern programming languages.
    Whether you find it good or not is another matter. You must be trained to take advantage of the tools to make good use of them. Otherwise they may end up being in the way.

    I do find myself wondering how many "bugs" actually go undetected because they are buried in levels of code the programmer has no access to...
    I wonder how many bugs a C program would have since a C programmer would write everything him/herself instead of relying on perfectly tested and functioning code.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Elysia View Post
    Do you honestly believe that high-level languages mean more code?
    Output code... the stuff that ends up in end user hands... absolutely.

    OOP and abstraction are probably responsible for 99% of the bloat and some of the crappiest software I've ever used. I already gave you an example of how ridiculous it's gotten, right from Delphi's own samples... 1.3mb vs 18k... both programs were built on the same pascal compiler, one was witten with forms and VCL the other used the libraries provided by Windows. ... a 72 to 1 size ratio for exactly the same functionality.

    I wonder how many bugs a C program would have since a C programmer would write everything him/herself instead of relying on perfectly tested and functioning code.
    Now that's just plain old fashioned disinformation Elysia... Take a close look at C source code, 80% of it is library calls. That might even reach 90% in Windows code. I don't write a printf() subroutine into my code... I call it from the library in the same manner as a Delphi programmer would call Print().

    What's really different is that now we have developers building libraries that are merely wrappers around other libraries. Delphi's VCL was --at my time-- nothing but a bunch of subclassed windows controls, so poorly written you had to include almost the entire VCL to use even one of the controls. This resulted in programs that were an inch of active code and a foot of dormant code linked in for no good reason at all. I found it easier and far more flexible to just go to the source and use the windows control directly; almost always the result was faster and more stable.

    It is a serious mistake to think that just because a program is written in a certain language it will be inherrently more (or less) buggy (or stable). That is a function of code quality which *should* be a reflection of the skill of the programmer....

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by CommonTater View Post
    Output code... the stuff that ends up in end user hands... absolutely.
    That speaks volumes about the size of that program, you know.

    OOP and abstraction are probably responsible for 99% of the bloat and some of the crappiest software I've ever used. I already gave you an example of how ridiculous it's gotten, right from Delphi's own samples... 1.3mb vs 18k... both programs were built on the same pascal compiler, one was witten with forms and VCL the other used the libraries provided by Windows. ... a 72 to 1 size ratio for exactly the same functionality.
    Again, because you included the library code in the executable.
    And this doesn't scale. It's a fixed amount of overhead.

    Now that's just plain old fashioned disinformation Elysia... Take a close look at C source code, 80% of it is library calls. That might even reach 90% in Windows code. I don't write a printf() subroutine into my code... I call it from the library in the same manner as a Delphi programmer would call Print().
    So they are in other languages, too, such as Java/C++. Only they call the C++/Java libraries, instead of the Windows libraries.
    How much extra code do you have to write to make your code properly work with the Windows calls instead of a generic C++ solution?
    Try comparing a pure Windows program and a MFC program. Bare bones with only one window.
    The simplicity of the MFC program will be significant compared to the pure C program because so much less code is required to complete the task.
    In other words, the more functionality you have to write, the more complexity and the more code you get with pure library calls. Somewhere, you will gain smaller code with, say, C++ than C.

    What's really different is that now we have developers building libraries that are merely wrappers around other libraries. Delphi's VCL was --at my time-- nothing but a bunch of subclassed windows controls, so poorly written you had to include almost the entire VCL to use even one of the controls. This resulted in programs that were an inch of active code and a foot of dormant code linked in for no good reason at all. I found it easier and far more flexible to just go to the source and use the windows control directly; almost always the result was faster and more stable.
    Yet, you speak of the past. Is that the case today? Is that the case with other frameworks in other languages, such as C++, Java, C#? I would think not.
    It might be big, but it's also rich and easy.

    It is a serious mistake to think that just because a program is written in a certain language it will be inherrently more (or less) buggy (or stable). That is a function of code quality which *should* be a reflection of the skill of the programmer....
    You are right. But consider this:
    Given two people, one with a screwdriver and one with an "automatic" screwdriver, who can pull out 100 screws fastest, assuming they are both professionals with their tool?
    The answer is, of course, going to be the one with the "automatic" screwdriver.
    What is my point? My point is that each software has a timetable. And a budget. That is, one cannot take too long to program the software, and one cannot hire too many programmers to program it.
    This equation simply says that given two programs, in C and your favorite high-level language, the one in the high-level language would probably have more features or have less bugs, under real world situations.
    Yes, you can make a very good program in C. It would just take longer.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    Talk about going off topic, look like this thread has fallen to the zealots!

    To answer the original poster - yes its a good book, probably the best on Win32, but its not used as much today due to:

    • Lots of changes since this book was written 12 year ago, although this book will certainly get you started
    • Many windows coders have switched to C# (including the author of the book)
    • Lots of really decent cross platform toolkits have arrived (Qt, wxWidgets) that have made coding in straight WinAPI less appealing

  14. #14
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    This equation simply says that given two programs, in C and your favorite high-level language, the one in the high-level language would probably have more features or have less bugs, under real world situations.
    Yes, you can make a very good program in C. It would just take longer.
    Ok... I'm going to let you win this round. I don't think we're going to reach a consensus here because I'm arguing "code purity" while you're on about "programming practicality".... I will maintain that the more access I have to the system's nuts and bolts the more compact and stable my code will become... You will aruge that removing (or at least obfuscating) that level of access prevents mistakes... We're not going to settle this one today....

    Cheers Elysia... interesting conversation as always.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. a phone book program
    By mackieinva in forum C Programming
    Replies: 2
    Last Post: 09-19-2007, 06:31 AM
  2. URGENT: Help wanted...in C
    By iamjimjohn in forum C Programming
    Replies: 16
    Last Post: 05-18-2007, 05:46 AM
  3. C++ Templates book discussion
    By manutd in forum C++ Programming
    Replies: 38
    Last Post: 01-18-2007, 02:56 PM
  4. need a quick opinion before i order this book
    By Iamien in forum Game Programming
    Replies: 1
    Last Post: 01-10-2004, 10:59 AM
  5. I"m selling a book...
    By St0rmTroop3er in forum Game Programming
    Replies: 2
    Last Post: 12-13-2003, 12:55 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21