Windows programming without visual this++

[Candy]

As I asked on a different forum too, I would like to get the hang of Windows API programming, and in particular, the visual programming. I don't consider this crossposting since the other forum had 2 weeks to reply and didn't get further than advising Java, Liberty Basic or some c++ environment.

As for the real question, I want to learn Windows API programming using the API calls, no premade code. I want to do so in C++, preferably in dev-c++ or mingw32, might install cygwin if it has some advantages (not for osdev though). I've tried to search for tutorials or books on the subject but I cannot find anything that doesn't tell me to use some visual this++ or that builder, so I can really appreciate some help from people here.

TIA, Candy

[Tim]

The Windows programming bible is Programming Windows by Charles Petzold. He targets developers writing for the core Win32 API, without any MFC, .NET or Visual Basic. (However, I believe newer versions of his books are turning towards .NET.)

Basic Win32 programming is the same everywhere, so even if you do find a book or tutorial which assumes you're using Visual C++, you shouldn't find many differences. For example, if it says, "go to the project settings dialog", you go to your makefile.

You will, however, need to get hold of a resource editor, which is one of the few visual tools which Win32 programming almost requires (you could write your .RC file in a text editor, but that would be no fun). Clearly Visual Studio has a resource editor built in, so you would need to find a replacement for that. I haven't used any free resource editors, but I hear Dev-C++ provides one.

[sonneveld]

While Petzold's book is great for learning the base WIN32 api.. he does leave out a fair bit though. No mention of the registry or common controls (tabs, list controls, property box).. this is the fifth edition book and it says "designed for win98,me, 2000, xp" so you would have thought they'd mention the registry at least.

- Nick

[ark]

if you can find a copy of Programming Windows 95 by Petzold (it's basically Programming Windows, Fourth Edition), it does have a chapter on the common controls, although in all honesty the Windows Platform SDK documentation is probably clearer about how to use most of them. Programming Windows 95 doesn't have the chapters on graphics that the fifth edition book has.

All editions use some obsolete functions (such as SetWindowLong) and outdated practices (such as returning BOOL from a dialog procedure) that are, according to the Platform SDK documentation, not compatible with 64-bit Windows, but Petzold is still probably the best place to start learning.

[Tim]

Joel: The concepts of SetWindowLong and returning BOOL from a DlgProc aren't obsolete. Because sizeof(long) != sizeof(void*), SetWindowLong is replaced with SetWindowLongPtr, taking LONG_PTR instead of LONG, and DlgProc returns BOOL_PTR instead of BOOL. What Petzold teaches is still correct for 32 bits, and mainly correct for 64 bits.

Anyway, the point of Petzold's book isn't to teach 100% of the Windows API -- MSDN will do that -- but teach you how to program Windows applications. He does that the best of any literature I've seen, and you can't beat the combination of Petzold plus MSDN.

[Candy]

Because sizeof(long) != sizeof(void*),

In what twisted form of 64-bit compiler implementation is that? Afaik, long is nearly DEFINED as equal to a pointer's length

[Tim]

The sizes of long and pointers aren't related. The standard says that char <= short <= int <= long <= long long, but that's all. Also, sizeof(char) == 1 always. (Note this means that all integers can be the same size: there is at least one C compiler, targetting digital signal processors, where all integers -- even chars -- are 32 bits, and sizeof(long) == 1).

Even on the PC, pointers and integers have traditionally been different. On a 16-bit x86 compiler pointers can either be 16 or 32 bits, whereas, so far as I've seen, longs are 32 bits. In fact, I'm sure I don't need to remind anyone that far pointers are more like structs, with a separate 16-bit segment and offset.

Anyway, my experience of 64-bit programming -- admittedly theoretical, unless somebody buys me a 64-bit CPU -- is from Win64, where ints and longs are 32-bit and pointers are 64-bit. If you want a 64-bit integer on Win64 (maybe to store a pointer in) you use long long on a C99 compiler, or __int64 on the Microsoft compiler.

[df]

i thought int was always standard register size, so on a 64bit cou

int = 64
long = 32
short = 16

ilp64!

[Tim]

Nah, int is however big the compiler vendor wants it to be. But long is never smaller than int, and int is never smaller than short.

BTW, ILP64 is "ints, longs and pointers are 64 bits", which is the scheme that Candy described. ILP32 is the scheme we're familiar with currently ("ints, longs and pointers are 32 bits"). Win64 compilers have IL32P64 (don't know if that's the right term). I guess they said, "2[sup]32[/sup] should be enough for anyone, and if it's not, they can use long long". This would certainly help compatibility; I wouldn't be surprised if most software (outside of embedded systems) expected int and long to both be 32 bits in size.

[Candy]

Nah, int is however big the compiler vendor wants it to be. But long is never smaller than int, and int is never smaller than short.

BTW, ILP64 is "ints, longs and pointers are 64 bits", which is the scheme that Candy described. ILP32 is the scheme we're familiar with currently ("ints, longs and pointers are 32 bits"). Win64 compilers have IL32P64 (don't know if that's the right term). I guess they said, "2[sup]32[/sup] should be enough for anyone, and if it's not, they can use long long". This would certainly help compatibility; I wouldn't be surprised if most software (outside of embedded systems) expected int and long to both be 32 bits in size.

On sparc's at least, long is 64-bit. That's why I'd expected them to be 64-bit on the AMD's too...

As for my logic, I was hoping on I32LP64. That would make all pointers the right size, and leave normal (non-double) names for all types from 1-8 bytes.

[ark]

That is basically what I said. I didn't say the concepts were obsolete, I said the function was obsolete (meaning it is referred to as "superseded by SetWindowLongPtr" in the official docs) and that the practice of returning BOOL from a DialogProc is outdated (meaning that the official docs now specify that DialogProc should return an INT_PTR).

Just to be clear on this, I'm not discouraging Petzold as a learning tool. I learned from Petzold, and his book is also the best I've seen at explaining just how to create a Windows program. I was even saying that if you buy his book, you might also want to consider trying to get your hands on Programming Windows 95 because it has chapters the latest doesn't have and vice versa. I was merely pointing out the fact that there are some things that the official documentation refers to as better practice that the Petzold books have not been updated to use.