Slashdot Mirror
Programming References for the Win32 Environment?
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?"
MSDN
It's free & it contains what you'll need to know.
Finding info is tricky sometimes; nothing's perfect.
---
Oregon
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.
9 95 X/o/qid=1012577986/sr=8-2/ref=sr_aps_b_1_2/202-426 8607-1287006
http://www.amazon.co.uk/exec/obidos/ASIN/157231
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.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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.
/.), I spent much more time trying to get the GUI to draw nicely and look decent than making it work.
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
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.
You are in a maze of twisty little passages, all alike.
MSDN page regarding references for programming languages. (This of course is a joke)
If it ain't a Model M, it's a piece of crap.
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.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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.
.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.
That said, if you have the option of using
Either way, much better than sifting through MFC you'll never use again.
Let's not stir that bag of worms...
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.
-TheDawgLives suckitdown
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, 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 and Win32 Perl Scripting: Administrator's Handbook, 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).
DO NOT LEAVE IT IS NOT REAL
who the hell modded that OT? The guy proposes two great alternative to using MFC and other microsoft-only solutions to writing programs for Windows. plus if they use his sugestion, the guy dont have to re-write the entire program should his customer change platforms.
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.
Program-to-the-metal API programming is properly done in C (no C++) and Petzold is OK but maybe a bit overrated. The Waite Group publishing API Bible series has been my trusty API reference (there was a 3-volume set, replaced with a 1-volume Windows NT Super Bible). Waite Group also has this Black Art of Windows Game Programming book that really explained the message loop and the GDI (graphics API) the best, but it is for Windows 3.1 and is obsolete.
/. post to say anything good about it. Not only that, MFC along with COM and ActiveX all goes out the Window when Visual Studio 7 and the .Net runtime comes along with managed C++, C-hash, and VB .Net. The New Windows development API will be a lot, lot, like Borland Delphi/Builder, which is another way to go if you don't want to start at the API level.
.NET stuff.
Programming in C++ typically means the horrid MFC; I think it is horrid and I have not seen a
If you still want to do the API but in C++ with the odd COM object thrown in, check out ATL Internals, not to be confused with Inside ATL, the more moronic MicroSoft Press book. ATL is like STL for Windows and is probably the intelligent way to use C++ for the Windows API until the dust settles with this
Qt is supposed to be cross platform and native L&F
If you're looking for an equivalent to Stevens' book, then Petzold is definitely the one. It's the book that does explain all the truly important things you need to know (on top of knowing the programming language itself, that is) to get yourself off the ground in Windows. It's essentially the holy scripture among Windows programmers.
Its limitation, if any, is that it's pretty much centered on classical Windows programming. It doesn't even mention any of the "modern" additions, like ActiveX, DirectX, internet programming, or whatever your favourite buzzwords would be. There is (in the edition I have) a single chapter on OLE, but that's not written by Charles Petzold himself --- and it shows.
I send you this file in order to have your advice.
MSDN. It's free, it's updated often.
If you're doing gui work, you need Programming Windows 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 by Jeffrey Prosise.
If you require operating systems services like threads, processes, jobs/fibers, dlls, Unicode, etc., you need Programming Applications for Microsoft Windows by Jeffrey Richter. No ifs, ands, or buts.
Then (maybe before?) hit codeguru and codeproject.
[o]_O
CodeGuru is your friend
I do everything the voices in my head tell me to...
You don't have to excuse yourself, there's nothing wrong with programming for Windows. Personally, I find it a rather nice system to use, much more coherent than programming for the various different Unix variants.
As for documentation, I know people have said it before, but MSDN really is excellent (and much better than Unix man pages too.) You'd be best off ordering the help files on CD otherwise you'll psend too much time waiting for the thing to load.
I read some of Petzgold's book in a bookshop once, it seemed rather incomplete.
Get Visual Studio and an MSDN cd and you're sorted.
just go to relisoft got a lot of useful techniques and free reference books they wrote.
> Qt is supposed to be cross platform and native
> L&F
Cross platform, yes. Native L&F, no. Qt implements its own widgets across all supported platforms.
For a cross platform class library that wraps around the native widget set of the target platform check out wxWindows at http://www.wxwindows.org. Very featureful and totally free. Only downside is that while the available documentation is quite extensive, theres still a slight learning curve in getting started coding for wxWindows. The available tutorials combined with the (extremely) helpful mailing list does help to alleviate this somewhat. Truly great stuff IMHO.
- Arcadio
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
Let's not stir that bag of worms...
See Mahogany for a fairly large cross platform project implemented with wxWindows.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
The three books and MSDN that this post mentions are all that you need if your using c++.
Only the MFC book is C++, the other two are C. Pablo mentioned 'Advanced Programming in the UNIX Environment', which means he should have no problem at all with C.
[o]_O
- 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.
- 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.
- 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, 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. 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.
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!
S.
Use free (gratis) and free (open source, GPL) portable development tools. Some popular dev tools: cygwin, java, perl, php, python and others. Stop using costly, proprietary, platform-specific tools. vi$ual$tudio is not visual, it is an ugly cumbersome interface wrapping an ugly command line poor excuse for a compiler. I hear that programmers at m$ don't even use it. In learning to use m$ tools I eventually learned the wisdom in avoiding using these tools. Historically, Win32 APIs are derived from Win16 APIs derived from Excel for DOS (a GUI spreadsheet with windows) ported from Excel for Macintosh that used the Macintosh APIs. The Win APIs still look very similar to the original Macintosh APIs. Learn to wrap(hide and bury) these ugly APIs in your own real portable functions/classes. Don't ever call someone else's functions directly. For example, create a function myRunMainEventLoop that works for Windows, Macintosh, OpenGL, KDE, Gnome, pure XWindows and whatever platform.
what license is wxWin under?
(btw- swing can produce native look-and-feel for the desktop system it's running on. it's just the occasional slow responses that give away the fact it's java.)
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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
I did. How the hell does that help with his *class* programming assignment? If he's programming Windows for school, he's either learning Visual Basic or using C/C++. Since he didn't say VB specifically, I assumed C/C++. Saying Java or Perl is completely useless, and doesn't answer the guy's question.
And yes, I am a Java programmer. But the "anti-ms" crowd of high-schoolers on here really gets on my nerves.
I would consider wx for a cross-platform project I'm doing but I need a richtext editor component, which it lacks. QT looks like my best option.
you clearly misunderstood what was being asked. the guy is fully understanding of UNIX, so I highly doubt he's a student. He said he's writing for a school, which means he probably volunteered for his local public school board to write up a small app for managing a db of student records or something. The school uses Windows, so being a UNIX guru he was clueless on writing win32 apps, and came here to /. with a legit question about writing programs for win32.
/., but modding a post under the false opinion that it is ms-bashing shows you're a lousy moderator. Like the moderator instructions state - dont mod a post down because it's against your own opinion)
The poster of the comment you modded OT suggested going cross-platform should the school change platforms sometime in the future. The post shows *nothing* with advocacy against microsoft. looking at other posts in the thread, it appears others agree with this cross-platform idea for the same reason the original poster did.
now if he was a student, the school would teach him how to use MFC and Visual* tools to develop applications, making unnecessary for him to do an ask slashdot.
(btw - i too am against the level of ms bashing on
last note: i am not the poster of the OT post were talking about. i am pro-proper-moderating. that's all.
GPL
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
This is true. I forgot that it lacked that... I wonder if Mahogany implemented theirs as part of wx that could be reused in other projects? I vaguely remember hearing about a wx rich text control that was "in development", whatever that means.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
If you prefer to utilize the low level API's then use the MSDN from Microsoft. If you can use a toolkit I completely recommend the Qt toolkit from Trolltech. A Non-Commercial version is available for Windows but only works with Visual C++ from MS. It has support for all the important stuff including GUI, Threads, Sockets, and full Translation support. Plus if you utilize Qt your code can be recompiled on *nix, Mac, or Windows with VERY few modifications. That's just my take on it though. Best of luck.
... has a good bok that may help: Prescription Medicide : The Goodness of Planned Death ;-)
-- Argel
... 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.
Stupid job ads, weird spam, occasional insight at
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.
.
Let's not stir that bag of worms...
Want to -really- know the Windows API, the best challenge would be to write Assembler code, start with: Iczelion's Win32 Assembly Homepage
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
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.
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
XFree 86 For Windows
Enjoy
Chris
"As flies to the wanton boys are we to the gods; they kill us for sport." - William Shakespeare, King Lear
It really depends. Do you want to go for VC++ or for VB? Of course, there always is MSDN 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 (Charles Petzold)
Win32 System Programming, Second Edition: A Windows 2000 Application Developer's Guide (Johnson Hart)
Just some ideas to mess around with.
Hope this helps.
-Vic
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.
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.
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.
Social Contract? I don't remember signing any Social Contract!
I took the @carleton.ca email address to assume he was a student - also the use of "for school" as his description. It's certainly not unheard of to be forced to program on windows for a CS class. Intel and Microsoft have been donating tons of equipment to CS programs.
And when I was in school, at least, the textbooks tended to be crap, and secondary references were often necessary.
The above comment is completely off-topic and useless, and led to other useless discussion. At least one other moderator agreed with me (redundant). Windows Programming is not Java or perl programming. Saying, Skip MFC's, use the Win32 API or the C++ Builder libraries would be on-topic. If I said that Petzold's book was good/bad/okay would be on-topic. Saying that I think MSDN is well organized or poorly organized or useful or filled with bad examples would be on-topic.
Unfortunately, slashdot discussions like this tend to stoop to the lowest common denominator. Although why the OP couldn't search Amazon or google is also beyond me.
license
"The wxWindows 2 licence is essentially the L-GPL (Library General Public Licence), with an exception stating that derived works in binary form may be distributed on the user's own terms. This is a solution that satisfies those who wish to produce GPL'ed software using wxWindows, and also those producing proprietary software."
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.
[o]_O
Native L&F, no. Qt implements its own widgets across all supported platforms.
:)
While Qt does implement its own widgets, it does still have the native look and feel. I think the Mac is the only platform where there is such a thing as true native widgets.
On Windows, the concept of "native widgets" really only applies to the look and feel. After all, there are many products/compilers to make Windows programs, and they are not all based on MFC (for instance, Borland does their own widgets AFAIK). I believe this is because use of MFC requires licensing. This means Qt is nothing strange on Windows.
And X11 has no concept of native widgets or native look either, but we won't get into that
I like writing DLLS in assembly and using them From VB. It makes for a good time debugging.
Both C++ builder and DELPH use VCL. Delphi is built on Object pascal, which is a borland only goat fuck exactly like C++ but has different operators, syntax and ideosyncracys. Borland IDEs generally have better integrated GUI drawing tools then visual C++ (It's been a while but I found VCL to not be generally superiour to MFC, just different), VB is just not a raw enough tool to do much more then it's developers foresaw but is actually easier to use the C++ builder (but of course has some just plain strange things about it, don't all environments).
The 'microsoft answer' is to do 90% of your programming in VB, cutting in 9%+ C++ for performance intensive components and maybe 1% assembler. You don't want to use Win32 APIs for most tasks, any abstraction is better VCL/MFC even an old version of OWL is better. In VB you sometimes need to use the Win32 API to get past the tool, of course you sometimes just can't construct the objects you are supposed to be passing pointers to. All in all VB is better then most of the
There are also tricks to be found in MSDN you can use VB to generate 'standard' obj files and link them via command line linker. This is not for the faint of heart. But I would rather do that then get anywhere near SWING (a true java compiler if it's 'just in time' to save your project. Would it get by the religous police?).
COM is analogous to CORBA, you can access these functions through the Win32 API but just as with the GUI APIs you don't want to. All the type librarys and VB abstract COM objects.
Access/Jet is obsolete, don't even learn it. Use ADO and the free redistributable version of SQL server (MSDE? Microsoft Data Engine? it's late alphabet soup in my head). SQL server really is quite good and it's free (free version has 5 user limit, only performs worth a damn with 1 user).
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.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
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.
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
if you don't like swing, you can use awt which tends to look like any native app on most systems assuming you know what you are doing.. people use swing to be consistant with swing (and because its easy), if you want native looking apps use awt
Unless you're actually forced to program in C++ or the like, I'd suggest grabbing a copy of the free command line c# compiler from microsoft, pick up the Orielly C# book and go have fun. The new 'Windows Forms' model is terrific (goodbye MFC!) and C# has enough hooks to the low level system to make it a comfortable launching pad.
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 . It's an absolutely awesome book.
If it ain't broke, it doesn't have enough features yet.