Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Programming References for the Win32 Environment? 86

Posted by Cliff from the MFC-Bible-and-its-420-commandments dept.
Pablo asks: "I have to do some programming in Windows (for school, not by choice). To say that I know jack-all about Windows programming would be flattering myself. I never do any programming under *NIX without my trusty copy of Stevens' 'Advanced Programming in the UNIX Environment' by my side. I'm wondering if there is an equivalent 'bible' reference book for Windows programming. Does anyone have any recommendations?"
This discussion has been archived. No new comments can be posted.

Programming References for the Win32 Environment? More

Programming References for the Win32 Environment?

Comments Filter:

  • Only one answer really (Score:5, Informative)

    by oregon ( 554165 ) on Friday February 01, 2002 @11:34AM (#2937342) Homepage
    MSDN [microsoft.com]

    It's free & it contains what you'll need to know.

    Finding info is tricky sometimes; nothing's perfect.

    • MSDN *IS* the way to go...once you know what info you need and where its likely to be hiding.

      Unfortunately, Pablo didn't go into any detail wrt what kind of windows programming he was doing....perhaps he's under the impression that there's only one kind of target available on Windows?

      That said, if he can choose his IDE, I would strongly recommend going with Borland's implementation of whatever language will be used. Borland has, by far, the best IDEs available in a Windows environ.

      As for a Windows bible, well, Windows has gotten too big to have a single "bible" book - it depends alot on what you want to do and almost as much on what constraints you have in doing it, so I'll recommend publishers instead. I've never been disappointed by the usability and reference value I've found in MTP (MacMillan Technical Publishing) books. Second choice would be PTR/PH (Prentice Hall Series on MS Technologies) books. Wrox and O'Reilly have good titles as well. Microsoft Press books are unavoidable, but they tend to have the same attitude toward their publishing as they do towards their software (and I'll leave it at that).

      • "That said, if he can choose his IDE, I would strongly recommend going with Borland's implementation of whatever language will be used. Borland has, by far, the best IDEs available in a Windows environ."

        Yes, I know it's offtopic, but I'm really curious...on the M$ side of things, after moving up from DOS environments, i've basically only been exposed to the Visual Studio products. So I was hoping you could possibly point out a few of the reasons that you believe the Borland IDEs are the best available...is it the compilers themselves? IDE features/lack thereof? Documentation? Tools?

  • Petzold (Score:2, Informative)

    by Anonymous Coward
    The bible is "Programming Windows" by Charles Petzold. This has been around since 3.1 and is a very good tutorial. Use MSDN as your reference.

    http://www.amazon.co.uk/exec/obidos/ASIN/1572319 95 X/o/qid=1012577986/sr=8-2/ref=sr_aps_b_1_2/202-426 8607-1287006
    • Mod Parent up - Charles Petzold is a Win32 God (or demon as it may be ;). his book will teach you Everything you need to know to write against the win32 api. He's the win32 equiv of your Stevens book for Unix.
    • Yeah Petzold is a must have volume, if you want to learn MFC though then I would thouroughly reccoment "Inside Visual C++" by David Kruglinski. It has to be said that most of the Microsoft Press books are pretty good when it comes to windows development.

      However I must say that this is about the most useless Ask Slashdot I have seen in a while, it is so insanely easy to find an answer to this question on the web that the author must be either incredibly lazy, incredibly desperate for that post accepted karma boost or incredibly feckless.
    • This has been around since 3.1 and is a very good tutorial.
      Actually it's been around since 2.0 -- or was it 1.0? The earliest edition I've seen (either 1.0 or 2.0, can't remember) referred to Windows as "The MS-DOS Presentation Manager". Which fit in with the original purpose, which was to make DOS look like OS/2 [charlespetzold.com]. My copy is for Windows 3.0, the first version anybody outside Microsoft took seriously. I remember being extremely irritated by three things:
      1. No only was the book expensive, but it didn't include a disk with the source code. You had to write away to CP himself to get that, and it wasn't cheap either.
      2. In keeping with the design philosophy of Windows, CP has a "complexity is power, power is complexity" philosophy. This is reflected both in his programming style, and in his prose.
      3. I expended considerable mental energy on the chapter on memory management -- which left me fairly angry when I read the very last paragraph. This explained that the preceding text (unchanged from the previous edition) was only useful if you planned to write real-mode or protected-mode programs. No sane programmer does these things -- that's why 3.0 was the first version anybody took seriously.
      In any case this book (or another like it -- somebody must have written something better by now) is only useful if you need to study the whole basic Windows API from first principles. Very few programmers need to do this. Most build on some high-level API, and only descend to the Petzold level when they need to.

      If you just need to hack out some quick GUI application, you should use an IDE environment that supports this. Some good ones are available free. If your stay in Windowsville is short and involuntary, you might consider a Java IDE [borland.com], so at least you'll pick up some skills that you can take back to the Unix world. Or if you neeed native code, you might consider Delphi [borland.com]. Strangely enough, Delphi is quite popular amongst low-level Windows API hackers. This does seem strange, given that Delphi uses a dialect of Pascal, and Windows is very C-centric. But a lot of people feel that Delphi's advantages offset this semantic impedence gap.

      • I expended considerable mental energy on the chapter on memory management -- which left me fairly angry when I read the very last paragraph. This explained that the preceding text (unchanged from the previous edition) was only useful if you planned to write real-mode or protected-mode programs. No sane programmer does these things -- that's why 3.0 was the first version anybody took seriously.

        Maybe you don't understand your architecture to enough depth to see the real problem.

        First of all, x86 developers either write real mode or protected mode programs. To claim that "no sane programmer" writes for either mode is to claim that there are no sane programmers! :)

        You probably had a problem with the 24-bit segment:offset memory addressing model of x86 real mode. That's a hack to get more memory than can be addressed by the 16-bit machine integers of the time. There's a similar hack to address higher than 2^32 bytes of memory in modern x86 systems.

        The other possibility is that you were confused by protected mode's memory page access controls. Since this is a much simpler thing to work with than segment:offset addressing, I'll give you the benefit of the doubt and not go into it.
  • try java, perl, or some other cross-platform language. since you're writing for a school, it'll be easier to port the app to Linux or Macs should the school decide to change sometime in the future.

    Chances are good you're developing a GUI app, so Java's Swing and Perl's Tk Libraries will do well for you.

    The big plus is you dont need to learn all about MFC classes and such beforehand, hence making your life easier if you already know the abovementioned languages. You'll also have the skills of using those languages when you back to your UNIX programming.
    • Swing is fine if you want your app to look like VB shareware from 1993. If you are going to develop anything non-trivial, you're much better off sticking with MFC despite its learning curve and sometimes less-than-elegant implementation.

      Having done only a tiny amount of Swing work (so I'm not the most qualified judge of it in the world, but hey, this is /.), I spent much more time trying to get the GUI to draw nicely and look decent than making it work.

      If cross-platform is your highest criteria, than some implementation of Java is probably your best bet, but otherwise, I'd stick with native code and API's.
      • yeah, i can agree that getting a Swing GUI app to look correctly is tricky, but would be just as tricky in other settings like the Perl/Tk API. However, I have found that the more I've worked with Swing, the easier it becomes just out of practice using it and the experience gained out of it.

        IMO, saying it looks like VB is stretching it. If it looks like a 93 VB app then someone probably didnt know what they were doing when they coded up the GUI part of the tool. I know for one there's a GNUtellium written in Java that looks like any other Windows app when I run it using the Windows-look-n-feel.

        There are IDEs out there for targeting the JVM that include GUI-builders. These may work in getting things to look good, but I've never used them, so i cant say which are good/bad.
    • I agree, using a cross-platform library is certainly the way to go. I recommend, though, using a library such as wxWindows [wxwindows.org] that is not only cross-platform but also has multiple language bindings *and* looks and feels like the native system. One Wx::Windows app written in C++, Perl, or Python will compile and run natively on Windows, *nix, and Macintosh, and it will behave like a standard Win32, GTK+, Motif, or Mac (there's a port in progress to OS X) application, unlike Swing or Tk. It's also a hell of a lot more elegant than Tk, although I don't know much about Swing. I don't know what sort of project the poster is specifically considering, but it can almost certainly be done using a toolkit like this.

      See Mahogany [sourceforge.net] for a fairly large cross platform project implemented with wxWindows.

  • Thoughts (Score:3, Insightful)

    by JMZero ( 449047 ) on Friday February 01, 2002 @12:14PM (#2937592) Homepage
    As others have said, avoid MFC like the plague - just write Petzold "Programming Windows" style code. As long as you can find all the API's you need (MSDN helps, but often doesn't search well - example code is a lot better), C programming under Windows is pretty easy.

    That said, if you have the option of using .NET it's probably the best way to go right now. C#, or even VB.NET, are pretty dang easy to use. Might even make for compatible code once Mono is working.

    Either way, much better than sifting through MFC you'll never use again.

    • Re:Thoughts (Score:3, Informative)

      by mmaddox ( 155681 )

      I concur - Petzold is a god. In addition, though, give some consideration to Brent Rector's Win32 Programming [amazon.com]. This book is almost unknown, but it is a far, far more cumulative reference and guide to the Win32 APIs than the last couple of editions of Petzold's book.

      For MFC? The latest edition of Inside Visual C++ is called Programming Visual C++ [amazon.com]. After David Kruglinski's untimely death while hanggliding, George Shepherd and Scot Wingo took over. Their other book, MFC Internals [amazon.com] is among the best programming books ever written, even if it IS about MFC.

      The best book on COM and ATL 3.0 is Developer's Workshop to COM and ATL 3.0 [amazon.com] by Andrew Troelsen. This book is meant for programmers, and will take you through COM in C++, then show you how to take all the shortcuts of ATL (Active Template Library). It's hardly known, but it's a really well-written book - much better than the more oft-quoted standards.

      OReilly has a few good books, and Addison Wesley books are consistently good. Both companies books are generally geared to the more advanced, experienced programmer. Almost any book by one of the following authors will be useful:
      Chris Sells, Don Box, Brent Rector, Mike Woodring, George Shepherd, Scot Wingo, Mike Blaszczak, Jeffrey Richter, Charles Petzold, Jeff Prosise. Starting with the books I mention, a C++ programmer can quickly begin to find his/her way about the arbitrariness that is Windows.

      Of course, .NET is a monkey wrench for some developers. Rest assured that C++/ATL/COM is still there, though, and forms the best and only solution for native-code Windows programming. I can't recommend too many books for .NET - it's just too early. The Microsoft MSDN site [microsoft.com] is the best reference so far, as well as a great reference for all the rest. Best of luck!

    • > As others have said, avoid MFC like the plague

      This is just pure speculation on my part, but I suspect most people who code using MFC probably didn't learn MFC because they wanted to but probably because they felt they needed to. From what I understand, MFC proficiency is still very valuable and will help you land a Windows developer position if that is what you want to do.

      I'm still wondering if I should devote some time into learning MFC. I'm leaning towards "yes". I for one don't mind developing for Windows as the amount of jobs available for Windows developers are plentiful. I wish somebody could give me a straight answer if learning MFC at this point is a waste of time or not.

      - Arcadio

      • MFC (Score:1)

        by JMZero ( 449047 )
        I honestly don't know how many companies have MFC projects running. I've actually come accross more Delphi apps than MFC based ones. I've talked to a lot of people that started an app in MFC, but then switched either to clean C++ or to Visual Basic. It mostly comes down to "corporate development culture".

        Perhaps the best thing to do is talk to some prospective future employers and find out what they use. There's a lot of different skill sets you could acquire - and you might as well acquire a set of skills you'll:

        1. Get work with
        2. Enjoy using
        • This poll [sellsbrothers.com] indicates that some 75% of VC++ developers (poll states around 3 million) are MFC programmers. This would seem to indicate a fair number of MFC projects in existence, at least among the Visual C++ community. Granted, given the TOTAL number of Windows programmers, this number is quite small, as the vast majority are almost certainly Delphi or VB users; so you're correct.
          • I wouldn't have guessed the number would be so high, nor would I have though Delphi would rank so high.

            I guess that's the problem with making judgements based on only your own experience.

            Have a good day.

            .
  • When I was in school, I used Turbo C++. The reference books from borland that came with the compiler (there were about 6 or 7 different books 2 of which were dedicated to the Windows API) were all I needed. When I moved on to C++ Builder I found that the help files that were installed with it had all the info I needed to program in Windows and Open GL.

  • What sort of programming, exactly? (Score:3, Insightful)

    by babbage ( 61057 ) <cdeversNO@SPAMcis.usouthal.edu> on Friday February 01, 2002 @12:39PM (#2937716) Homepage Journal
    I don't know much about Windows programming myself, but it seems like if you want to really get into the guts of things, you'll have to deal with MFC and COM. I've never dealt with MFC, so I can't tell you anything about it, but from the little bit that I know about COM it seems to be a pretty nice system actually.

    Basically COM treats things in a client-server way, so that you can e.g. write a Python client to Excel that will let Excel do all the heavy lifting -- optionally in the background -- and then you get back the results and display them in a GUI or insert into a database or pipe out across the network or what have you. Conversely, you can write a COM server that can have Excel (or whatever, that's just the example I'm using) act as a client, with your Python (or whatever) program doing the work. Moreover, with DCOM (which seems to be the exact same thing but with an amended title), the clients & servers don't have to be on the same machine (as you'd probably expect of anything calling itself client-server). The bridge from this present-day model to the pervasively distributed .NET framework we keep hearing about should be pretty obvious.

    When you get into COM, it's much more similar to the Unix "small programs / filters" model than I was expecting, at least in certain abstract ways. Obviously you hear a lot of griping about it, especially here on Slashdot, but COM does seem to be a pretty solid framework for GUI application development, and much better than Motif, GTK, Bonobo, Swing etc, from what little I know about those systems. (I'm not trying to flame or troll, just speaking as a interested observer / non-developer of gui frameworks.)

    But again, what are you trying to do exactly? Aside from suggesting digging up some COM (and, presumably, MFC) references, the next question is what problem are you trying to solve, and what tools are you considering using? I've played around with Windows Python, based largely on what I learned about it & COM by reading Python Programming on Win32 [oreilly.com], and it seems like it isn't too hard (and it's much nicer than Visual Basic for the same tasks). I also read Dave Roth's Win32 Perl Programming: The Standard Extensions [roth.net] and Win32 Perl Scripting: Administrator's Handbook [roth.net], and the material was good but I'm not convinced that Perl is as good of a fit for the Win32 world -- it's great for short scripts, task automation, sysadmin stuff, etc, but I don't think I'd use it for a user-driven GUI application as I would with Python. (And keep in mind that, in general, I much prefer Perl to Python, and almost always use Perl over Python on other platforms, but I'm trying to match the tool to the role here...).

    You might also want to look into Visual Basic & Access -- as a lot of Win32 apps seem to be little more than a VB front end for an Access backend -- as well as VC++, MySQL (works great on Windows, IME), Delphi (never used it but I hear nothing but great things about it), and RealBasic (Mac oriented but can cross-develop to Win32, and again I hear nothing but great things about it).

    • RE: I don't know much about Windows programming myself, but it seems like if you want to really get into the guts of things, you'll have to deal with MFC and COM.

      Uh, hold it. The "guts" of Windows programming is the Win32 API. MFC is a set of foundation classes that ride on top of the Win32 and encapsulate them in a bunch of frustrating ways. MFC does not gain you the "guts" of anything - in fact, it tries to abstract away from the API to classes.
      It's an ugly hack of macros and classes, complete with its own implementations of strings and collection classes (some of which leak memory) and various constructs with hidden gotchas like CArchive (serialise your class via CArchive attacked to a CSocketFile attached to a CSocket! If you like debugging that, then you might also like pounding nails into your head).

      COM is nothing more than a binary format for code that provide a way to get interfaces to said binary code into any language that can understand said interfaces. Windows likes to do things in a COM way these days which means that knowledge of same is valuable. But even then they're trying to replace it with .NET considering the messier parts of pure COM (ever tried hand-coding any of that stuff?)
    • I don't know much about Windows programming myself, but it seems like if you want to really get into the guts of things, you'll have to deal with MFC and COM.


      Sigh. Any comment that starts with this kind of statement is not insightful.

      MFC is not required for windows application programming, but it probably is for student projects. Jeff Prosise's book Programming Windows with MFC is the book to use in this case. You'll find that MFC makes certian standard things very very easy to make. Unfortunetly trying to go outside those standard things starts getting very hard very fast. At that point you'll want to program straight to the Win32 interface. If you need to do this Charles Petzold's book Programming Windows is the way to go.

      COM is required in very few places in windows programming. In half the places where it is required, direct X mostly, it's wrapped in such a way that you don't need to learn anything about it. The only student projects that will need COM for anything will be projects about COM.

      -rr
      • Well I didn't mod me up. I was trying to be as helpful as I can -- no one seemed to be mentioning COM at the time I posted it -- but I didn't have any illusions about it being "insightful". :)

        Nonetheless, it does seem like COM is a pretty versatile system for getting applications to intercommunicate & build off one another. My understanding is that, for example, Internet Explorer is nothing but a bundle of COM objects that interoperate well (a network stack, an html renderer, a gui manager, etc), and if you want to you can embed those components in your own applications relatively painlessly. My understanding is that working with MFC puts you pretty close to the core OS, and thus is okay for making things more or less from scratch, but using COM gives you bigger chunks to build applications out of.

        I don't see where this guy mentions what sort of Windows programming he has to do, but it seems like if he needs to understand the raw metal (so to speak), then yes MFC is probably the kit he needs to use, but if he's after something higher level like COM might be easier & more productive.

        That's my understanding anyway, but like I say I'm not a gui programmer, I do network & database stuff. I'm just trying to summarize what I've been told in the past...

      • COM is required in very few places in windows programming. In half the places where it is required, direct X mostly, it's wrapped in such a way that you don't need to learn anything about it.

        I think that it gets more use in OLE actually. The things that make the most common use of the COM are things like OLE controls (ActiveX controls), OLE document objects (linking/embedding excel docs in word docs, etc), and scriptable objects (objects that expose IDispatch ... especially automation interfaces for the Office applications).

        DirectX, by comparison, sees less use (except in games or some popular media applications).
    • The java equivalent of COM is JavaBeans, not Swing. Swing is just a GUI toolkit.
  • Which method you use depends a lot on what your assignment is.

    If you're doing something fairly simple using text MFC is OK (I'm assuming you have access to Visual C++). Just use the wizard to create a skeleton application and then fill in the rest.

    In a lot of cases the best option is to choose "Dialog based" within the wizard and uncheck "Document/View architecture". By choosing these options, you minimize the amount you have to know about MFC internals.

    On the other hand, if your application doesn't seem to be a good fit with what MFC offers or you want to limit the size, I would use C or C++ and just use the Windows API.

    As others have mentioned MSDN is a good source of info. Petzold's book is also useful, but it was orginally written for Windows 1.0 and despite revisions, is still a bit dated. I would also recommend "Win32 Programming" by Brent E. Rector and Joseph M. Newcomer for Windows API programming. For MFC programming take a look at "Programming Windows With MFC" by Jeff Prosise.
  • I send you this file in order to have your advice.

    MSDN [microsoft.com]. It's free, it's updated often.

    If you're doing gui work, you need Programming Windows [amazon.com] by Charles Petzold. Anyone who tells you otherwise, I would love to hear from.

    If you don't mind a slow ass gui that gobbles memory and will leave you crying early in the morning, then get Programming Windows with MFC [amazon.com] by Jeffrey Prosise.

    If you require operating systems services like threads, processes, jobs/fibers, dlls, Unicode, etc., you need Programming Applications for Microsoft Windows [amazon.com] by Jeffrey Richter. No ifs, ands, or buts.

    Then (maybe before?) hit codeguru [codeguru.com] and codeproject [codeproject.com].
    • The three books and MSDN that this post mentions are all that you need if your using c++.
    • I have here at work, "Programming Windows 95" by Charles Petzold, written 1996.

      I see that "Programming Windows" is published in late 1998.

      Is it worth it to get the new book, or am I better off with the 95 version. I suspect that they may be the same book, just diffrent titles for each revision.

      --
      Ian
      • If you have "Programming Windows 95", you know how thorough Petzold is. "Programming Windows" is basically the same but with an emphasis on Windows 98 and Windows 2k. That said, whenever you come across something strange, you can just hit MSDN to figure out what went wrong, so I'm gonna go out on a limb and say you're ok.
  • CodeGuru [codeguru.com] is your friend
  • MSDN is a great resource, to be sure. But it won't get you started on how to write Windows applications. Once you get the hang of that, you'll live and die by MSDN!

    As for how to write Win32 apps: First of all, Charles Petzold is the god of Windows programming books. Check out his book "Programming Windows: The Definitive Guide to the Win32 API".

    After that, I'd check out "Win32 Programming" by Rector and Newcomer, published by Addison-Wesley. It has served me well.

    Good luck!
  • For app level coding in C using the basic Win32 calls look for Charles Petzold Programming Windows, 5th Edition. For MFC programming look for Jeff Prosise Programming Windows with MFC. Both of these are excellent resources.

    I've yet to find a device driver book that's better than the DDK help files and sample code.

    -rr
  • ... has a good bok that may help: Prescription Medicide : The Goodness of Planned Death [amazon.com] ;-)
  • ... Johnson Hart, Win32 System Programming. It makes a lot of comparisons to the comparable Unix facilities for I/O, security, processes, threads, sockets, IPC, and dynamically loaded libraries.

    It's old (1997; think Windows 95 and NT 3.51), and there's nothing about graphical user interfaces, or "modern" stuff such as COM. For what it covers, it's a great introduction, seemingly aimed at Unix programmers.

  • Challenge yourself! (Score:1, Informative)

    by rootmon ( 203439 )
    Want to -really- know the Windows API, the best challenge would be to write Assembler code, start with: Iczelion's Win32 Assembly Homepage [tripnet.se]

    If you're familiar with C, check out the generic Win32 sample at MSDN to get you started with the basic framework: Generic Win32 Ap [microsoft.com]

    Windows C++ Programmers prefer ATL/WTL nowadays to the bloat of MFC. ATL (Active Template Library) makes it easy to write COM components and WTL (Windows Template Library) is a lightweight C++ wrapper for Win32 functions that MS uses internally. They released WTL unsupported with the last few Platform SDK CDs. Some tutorials and articles on ATL/WTL. [codeguru.com]

    Now you can also go the maverick route and install Cygwin and XFree86 on Windows (next best thing to being able to code on *nix.)
    Cygwin GNU Tools for Windows [cygwin.com]
    XFree 86 For Windows [cygwin.com]

    Enjoy
    Chris
  • It really depends. Do you want to go for VC++ or for VB? Of course, there always is MSDN [microsoft.com] that has more information than any volumes of books could ever give.

    Say you choose VC++, you have to ask yourself, do you want to use the Win32 API or MFC? The Win32 API sticks to 'normal' C/C++ type code, where as MFC tends to go off on its own tangent of C++. Of course, MFC (Microsoft Foundation Classes) is all object oriented, and thus designed for C++.

    Personally, I like using the Win32 API, mainly beacuse the Windows programs I write don't depend on the GUI and interface rather than what they do (mainly small games where the layer connecting program to Windows) doesn't need to use MFC. Plus, I can tie in the Win32 API better with the way I program and streamline the code better.

    Some books I recommend:
    Programming Windows, The Definitive Guide to the Win32 API [amazon.com] (Charles Petzold)
    Win32 System Programming, Second Edition: A Windows 2000 Application Developer's Guide [amazon.com] (Johnson Hart)

    Just some ideas to mess around with.

    Hope this helps.

    -Vic

  • Help File (Score:1, Troll)

    by scott1853 ( 194884 )
    Just get the API help files. They come with ANY professional development environment.

    Don't bother with MSDN unless you have hours to spend trying to figure out where information is hiding and you feel like reading propaganda in what are suppose to be technical documents. MSDN is just another place for MS to charge a fee and promote other products.

    Just as an example, prior to the release of Windows XP, they had a 4 page article discussing the new features that would benefit developers in XP, and all they could discuss is 32-bit color large icons and new APIs to support Luna, which IIRC required an extra 5 lines per control creation.

    Anyways, in using the API Reference, if you're not sure what a parameter is suppose to do because the documentation is confusing, just pass NULL and 9 times out of 10 it'll work.
    • Microsoft doesn't charge for use of the MSDN library. The library is as easy to use as any help file on the subject (and includes more information than JUST programming interface documentation).

      The bit about XP is ridiculous considering that it's a switch to a whole new kernel. Things work considerably differently under the NT kernel. If you only read about Luna and high color icons, you probably weren't reading anything intended for actual Windows developers.
      • They don't charge for the library, just for access to the important things like betas and whatever "secret" information they give you for the $2000 a year they charge for professional access.

        As far as the Luna article, WTF makes you think I don't know what I'm doing? I'm sorry, but a front page article titled "What's new in XP" on the Microsoft DEVELOPERS Network constitutes something being released for developers.

        Anyways, you probably work for Microsoft, hence the obvious bias. IF you can't find something to complain about, then you just aren't paying attention.
        • They don't charge for the library, just for access to the important things like betas and whatever "secret" information they give you for the $2000 a year they charge for professional access.

          It's not secret information. You are paying for their software and any special services beyond free access to MSDN Library over the net.

          You do not have to pay for the whole "universal subscription" (only important if you're running an organization with tons of different development arms really). Most people get the library subscription (revisions of the MSDN library on DVD for some finite period).

          As far as the Luna article, WTF makes you think I don't know what I'm doing?

          You know practically nothing about Microsoft's developer support.

          I'm sorry, but a front page article titled "What's new in XP" on the Microsoft DEVELOPERS Network constitutes something being released for developers.

          The point of my previous comment was that you are unable to read or comprehend such articles. WindowsXP is very different from previous consumer versions of Windows and to suggest otherwise only demonstrates how little you know about the product.

          Anyways, you probably work for Microsoft, hence the obvious bias.

          I don't work for Microsoft.
  • When I was required to do Windows programming five years, my colleagues referred Charles Petzold's Programming Windows to me. It was a wonderful book for beginners to start out with and it is probably the closest the Windows world has to the "Stephens' books".

    You may find more information at his site: charlespetzold.com [charlespetzold.com].

  • I've discovered from personal experience that using Google or your favorite all-purpose search engine to search for existing sample code out there on the web is a great way to learn new Win32 programming techniques. This is a major advantage of Windows programming; it's more mainstream so finding example application code that is easy to read and understand is quite easy. If you're a learn-by-example kind of programmer, then I highly recommend it.

    Of course, a comprehensive online reference such as MSDN or what Borland packages with their Builder suites is also good for quickly looking up function prototypes and descriptions.

  • I like writing DLLS in assembly and using them From VB. It makes for a good time debugging.

  • It's interesting to see the suggestions people have here. Most of them either assume you're going to use MS Visual C++, assume you're going to use MS Something, or say "Use Whizz-Bang-Free-Tool, it's GPL'd!". Although there's a certain amount of merit in each case, I note that you didn't specify either what type of programming you needed to do, or what development tool(s) you had available.

    You asked specifically about books, so... Petzold's book on the Windows API is invaluable if you're going to be programming in C or C++ (or if you're brave enough to try assembler). Its use is more limited (IMHO) if you're using other languages, though it might still be good to have on the shelf. The only serious MFC books I know about are the Prosise one mentioned by others, and the one by Kruglinski et al. If you're going to learn MFC (lucky you! :-)) then I'd suggest having a good look through both in a bookshop, and buying the one whose style you prefer. Finally, any Windows programmer -- whatever tool(s) they are using -- really needs access to the MSDN if they're going to do anything beyond the basics. There is simply no better source of raw information available. It's not always as well-written or reliable as it might be, but there's still nothing else with the breadth of information it contains. It's also pretty language-neutral as a reference, which is relatively rare in the Windows world.

    Since many have also introduced tools into the mix, I'll offer some opinions here as well. Perhaps it will help if you haven't yet decided what to use.

    My first piece of advice is to remember that there are alternatives to Microsoft's tools. Borland's C++ Builder is a nicer tool than Microsoft's Visual C++ in many ways, and their VCL library is much better designed than Microsoft's MFC. Borland's Delphi (essentially an OO version of Pascal, designed for Windows development) is also well-regarded by everyone I've met who uses it, though somehow it never managed to gain much mainstream acceptance. You can also get various free/GPL'd/open source tools, but <asbestos suit on> most of them are lower quality than the professionally developed alternatives and/or missing significant features <asbestos suit off>. There are obvious exceptions, e.g., GCC is a remarkably good C++ compiler (though lacking the standard of IDE you get with Visual C++ or C++ Builder). The exceptions are just that, though. This is advice from a professional Windows programmer, who makes his living by using these tools.

    If you just have to develop a simple application -- your typical college project but with a requirement for a Windowns front-end -- then I'd suggest going for one of the popular RAD tools, probably Visual Basic, C++ Builder or Delphi. I'm pretty sure you used to be able to get all of these at heavily reduced prices if you were studying, though I don't know if that's still the case; alas, my days as a student are past... All of these RAD tools do a pretty good job of insulating you from the absurd complexities of the Win32 APIs, and let you get on with writing code that actually does something useful. Just pick your language of choice, BASIC, Pascal or C++, and off you go. I wouldn't dream of trying to write a simple Windows app in C today, BTW; there's just no need to go writing all that boilerplate code or messing with low-level APIs if you're doing a project at college.

  • A couple of people here mentioned Petzold. That's where I got my first introduction to programming Windows. Most of his code is written in C (they call it "SDK-style").

    For a good C++ reference, take a look at Jeff Prosise's Programming Windows with MFC [amazon.com] . It's an absolutely awesome book.

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close