Good Computer Programming Book

[ThermalRunaway]

I have some experience in programming microcontrollers using assembly and C, but now I'm looking into the possibility of learning to program small applications under Windows and to that end I've started searching for some decent books on the subject.

I would prefer to stay with C as the language although I would be willing to consider other languages as well. I was wondering whether anyone could recommend some good books on the subject as I've not yet been able to find a book that teaches the sorts of things I'm hoping to learn. The book needs to teach C, as well as teach the art of programming under Windows. For example, I'm going to want to learn how to program a GUI application with buttons, text boxes, menus etc. I'm also going to want to learn how to communicate with a computer's peripherals such as USB port, parallel port etc in order that I can control or obtain information from (or send information to) electronic projects that I interface to the computer.

I've seen quite a few books advertised that teach C programming, but I'm not sure whether these types of books would teach me Windows specific programming?

Advice appreciated.

Brian

 

[Joel Rainville]

I'm going to want to learn how to program a GUI application with buttons, text boxes, menus etc.

I'm also going to want to learn how to communicate with a computer's peripherals such as USB port, parallel port etc in order that I can control or obtain information from (or send information to) electronic projects that I interface to the computer.

If you find a book that covers all of this, do not buy it. It will suck.

GUI programming in itself will fill a good sized book. If you wanna stick to C, you can scratch MFC books off the list, as it relies heavily on C++. I think you should start with a Win32 C tutorial and see if you're willing to do Win32 GUI programming with C. GUI programming usually lends itself quite nicely to C++ or any OOP language. But it can obviously be done in C.

The basic Win32 API is plain C. If you don't like to read off your screen, you need a Win32 API reference book. However, all this information is available online at https://msdn.microsoft.com/library, or can be obtained in the Win32 Platform SDK, which also contains tutorials. You can also get a useful help file from the LCC-Win32 project. This is what I use most of the time, with the occasional visit to MSDN online.

USB programming will also fill a book. Two books actually, because you first need to learn about device drivers. You probably wanna keep that for later.

Parallel & serial port programming is much easier and is easily covered in small tutorials on the web. You shouldn't need a book for that once you are comfortable with Win32 programming.

In general, are you more comfortable with reference-style books or tutorial-like ones?

 

[Optikon]

I'm going to want to learn how to program a GUI application with buttons, text boxes, menus etc.

I'm also going to want to learn how to communicate with a computer's peripherals such as USB port, parallel port etc in order that I can control or obtain information from (or send information to) electronic projects that I interface to the computer.

If you find a book that covers all of this, do not buy it. It will suck.

GUI programming in itself will fill a good sized book. If you wanna stick to C, you can scratch MFC books off the list, as it relies heavily on C++. I think you should start with a Win32 C tutorial and see if you're willing to do Win32 GUI programming with C. GUI programming usually lends itself quite nicely to C++ or any OOP language. But it can obviously be done in C.

The basic Win32 API is plain C. If you don't like to read off your screen, you need a Win32 API reference book. However, all this information is available online at https://msdn.microsoft.com/library, or can be obtained in the Win32 Platform SDK, which also contains tutorials. You can also get a useful help file from the LCC-Win32 project. This is what I use most of the time, with the occasional visit to MSDN online.

USB programming will also fill a book. Two books actually, because you first need to learn about device drivers. You probably wanna keep that for later.

Parallel & serial port programming is much easier and is easily covered in small tutorials on the web. You shouldn't need a book for that once you are comfortable with Win32 programming.

In general, are you more comfortable with reference-style books or tutorial-like ones?

I have a mindshare E-book on the usb spec and coding... found it very useful.. too big to u/l probably though..

 

[ThermalRunaway]

Thanks for the reply both.

Joel:

The only reason I mention sticking to C is mainly due to my experience in programming microcontrollers in C. I realise that programming Windows applications in C is in a completely different league altogether (and also a different type of C too) but I felt that it would be easier to learn C for Windows with my previous experience than it would be to learn a completely new language. With regard to C++, I don't have any objection to learning that but I wouldn't want it to confuse my limited understanding of ANSI C so I wasn't sure that'd be such a good idea for now. Can you offer any advice on this?

With regard to the USB, Parallel and Serial part I do intend to learn how to use these ports from within my programs to control external electronics but I agree with you - it's something that should and will be left until I've developed a good understanding of programming in the first place. I thought it necessary to mention this so I could paint a picture of my end goal which is to be capable of writing simple applications that run under windows and allow me, with the use of a Windows GUI, to control and exhange information with my electronics projects.

So with all of this in mind, what do you think my plan of attack should be? From what you've told me I'm thinking I should first commit myself to becoming competent in my chosen language, be it ANSI C or an object orientated language like C++ and then, once I've crossed this hurdle, tackle actual application programming for Windows. Once I've done all of that (if I get that far), I can then look at how I go about using my applications so control output ports such as parallel, serial or USB. I understand you saying that USB is highly complex, and I'm sure that it is, but bearing in mind that I only want to do very very simple things with the ports I'm hoping it's a realistic goal to achieve.

Can you recommend any good books? I prefer tutorial style books for learning and reference books to keep so that I've always got information to hand. I'm also a little confused as to whether I should set my sights on C programming or C++ programming for my Windows applications. Depending on my choice there, can you recommend any good development environments (compilers)?

Thanks Joel.

Optikon:

I'd be interested in getting hold of that ebook. Maybe we can sort something out?

Brian

 

[Joel Rainville]

I realise that programming Windows applications in C is in a completely different league altogether (and also a different type of C too)

Maybe not as much as you think. Have you looked at the PDF "tutorial" (which is 360+ pages, so it's really a book) on Win32 C programming? It should give you a pretty good idea. It might also be all that you need to get a firm grasp at C on the PC...

but I felt that it would be easier to learn C for Windows with my previous experience than it would be to learn a completely new language. With regard to C++, I don't have any objection to learning that but I wouldn't want it to confuse my limited understanding of ANSI C so I wasn't sure that'd be such a good idea for now. Can you offer any advice on this?

Putting it simply, once you know C++, you basically know C. You can write a mix of C and C++ and a C++ compiler won't raise an eyebrow. It's not good practice, but it can be done. Like I said, C++ is basically C with OOP. Bjarne Stroustrup (75% chances my spelling is wrong here ) who invented C++ just fixed what he didn't like about C and came up with the OO part.

So with all of this in mind, what do you think my plan of attack should be? From what you've told me I'm thinking I should first commit myself to becoming competent in my chosen language, be it ANSI C or an object orientated language like C++ and then, once I've crossed this hurdle, tackle actual application programming for Windows.

Yep, that's what I think, although don't be too @nal about it. I mean, you're gonna learn the language and get proficient at it by doing something with it, namely windows programming. Don't wait forever to write your first Windows program because you haven't memorized the for syntax yet :lol: And to be even more specific, I think you should stick with C for now. That's what my book suggestion below is based on. Keep the OO for later. You might find you don't need it at all and be perfectly happy with plain C.

Once I've done all of that (if I get that far), I can then look at how I go about using my applications so control output ports such as parallel, serial or USB. I understand you saying that USB is highly complex, and I'm sure that it is, but bearing in mind that I only want to do very very simple things with the ports I'm hoping it's a realistic goal to achieve.

Serial and parallel port programming is very easy, and it probably should be one of your very first projects once you're comfortable with the windows programming basics. Do a search for "parallel port programming" on this forum, and you'll find links to good tutorials. There were at least 2 posted in the last couple of weeks. The USB part, I would keep for later though.

Can you recommend any good books?

Yep, Charles Petzold's Programming Windows :

https://www.amazon.com/exec/obidos/...102-8188217-9279304?v=glance&s=books&n=507846

Commonly refered to as the bible of Windows programming, it's at its 5th edition. I believe I used 2nd or 3rd edition when I first started. Very good, I believe Petzold was one of the very first authors to write a complete book about Windows programming. And of course at the time, C was still the preferred "serious" language, so the whole book uses C, unlike most other Windows programming books. It is also a tutorial style book. If I remember correctly, he takes you through writing a Paint-style application through most of the chapters.

But start with that tutorial above. It has a 200 pages long "C introduction". If you absolutely wan to buy a C book, get a copy of the ANSI C standard, or the K&R reference and put it up on a shelf because in my opinion, you don't need that at your debuts. It'll be a useful reference later when you write complicated low-level USB stuff, or just to annoy people on message boards about their lack of knowledge on "the standard". The latter is 80% of what it is used for on software development forums. :lol:

I'm also a little confused as to whether I should set my sights on C programming or C++ programming for my Windows applications. Depending on my choice there, can you recommend any good development environments (compilers)?

Keep in mind, a C++ compiler compiles C code, but not the other way around. Learning C++ is learning the object oriented part of C++. All the other stuff is just like plain old C, with very few exceptions.

Free development environment :

• The Windows Platform SDK (Software Development Kit). You'll find it on Microsoft's website by entering "platform sdk" in anything that looks like a search box :lol: It contains everything you need to get started, except for the visual, point & click, rapid application development stuff. Just the bare bones.
• **broken link removed** <- Just agree to the terms, fill out the survey with as few details as you can, and you'll get to the free download
• **broken link removed**
• MinGW, a modified GNU GCC that produces win32 binaries. Supports, C, C++ and even Fortran :shock: I have never used this but it works, I have used programs written in this environment.

Try one. If you hate it, try the next one. At the end, use the one you hate the least :lol:

There's Microsoft Visual C++ which is the "visual", point & click part missing from the Platform SDK. It's not free but is available in most schools at student-friendly prices... Or you could "borrow" it from someone to "evaluate" it

Hope it actually helps and doesn't confuse you more. If something's not quite clear, don't hesitate...

 

[ThermalRunaway]

Joel: Thanks very much for your advice I'll be taking a look at all the information you've given me over the weekend, I appreciate that!

Just one more thing. Say in a year's time (or however long it takes) when I've developed into a half decent programmer and I'm able to write the simple applications I need to control my Electronics projects, and everything is right with the world. Is there a qualification that covers this kind of thing? For example, I enquired at my local college last week about the possibility of doing a course on C programming. The guy laughed, shook his head, and told me that he wished there was something like that available, but unfortunately they don't run anything like it at all. I was pretty amazed that a big college like that didn't run a course on C programming, but there you go - I don't know what sorts of programming courses are even available.

The only reason I'm really interested in a qualification to be honest is so that I can put something on my CV which says I've got some experience with programming. It's certainly not the reason I want to learn to program, I want that out of self-interest. It seems to me that you're very knowledgeable in this area, so what qualifications do you have (if any) in computer programming?

Thanks again Joel.

Brian

 

[Joel Rainville]

I enquired at my local college last week about the possibility of doing a course on C programming. The guy laughed, shook his head, and told me that he wished there was something like that available, but unfortunately they don't run anything like it at all. I was pretty amazed [...]

I am amazed too :shock:

However, even if they did offer such a course, chances are you will know more in a few weeks than the guy teaching it at your local college.

My advice is this : start teaching yourself and build some confidance with the language. Once you decide your hard work and programming skills deserve recognition, you'll probably already have a project that is worth building a small website around, to showcase it and make it available for download to others. Describe that real-world project on your CV, with a link to it. In my opinion, this will give you much more credibility than a 30 hours or so college course on C programming, which anyone can do and forget all about it the next day.

That's the self-taught, self-made software developer approach.

Software development, just like electronics, is about problem solving logic. The language you use doesn't matter as much as why and especially how you use it.

I like to think of programming languages as toy blocks :

High level languages like Visual Basic, Delphi and the likes are Mega Bloks. You assemble big pieces together, but some of the details are hidden from you.

A low-level languages like C is like Lego blocks. More flexible, you can use the standard sized blocks in different colors, pick up a few smaller ones and assemble everything in a much more flexible way.

Assembly language would be like molding your own Lego blocks before assembling them together :lol:

But all three levels can be succesfully used to solve problems. It's how you use them and what you build with them that makes you a good, credible software programmer, or Lego block builder :lol:

 

[ThermalRunaway]

I quite enjoy assembly level programming, but only on small scale stuff like 8-bit microcontrollers. I could never imagine using Assembly to program an application under Windows, and I don't think many other people would either. In any case, I think my assembly experience is advantageous because 1) it gives you an appreciation for what happens under the bonnet of your programs and 2) no compiler is perfect so if your program doesn't work the exact way you want it to, you can take a look at the code it's generating and debug on that level instead. So Assembly experience is useful even if you don't actually use it to program with!

With regard to the qualification thing, I do agree with your suggestion but on the other hand I think it's useful to have the qualification to show for yourself too. The thing is, when you're applying for jobs these days your applications will often undergo a computer selection process before they reach anyone making human decisions. So a computer will read your CV and, based on the qualifications that you have, it'll decide whether to put your application forward to be considered for interview or not. So while you might be more than capable of doing a job, that doesn't necessarily mean you'll get the job because your application may not get to the interview selection stage. Because of this reason only, qualifications themselves can be extremely useful.

Brian

 

[Nigel Goodwin]

I quite enjoy assembly level programming, but only on small scale stuff like 8-bit microcontrollers. I could never imagine using Assembly to program an application under Windows, and I don't think many other people would either.

This is why modern computer games require such fast computers, the Commodore Amiga games were generally written entirely in 68000 assembler, plus having the superior Amiga hardware (at the time), so were blisteringly fast, even though clocked under 8MHz!.

When you consider how fast even a Pentium 1 runs, games should really fly! - but no, write it in C, run it under Windows, make it crawl like a snail on a bad day :lol:

Obviously the Amiga had the advantage of superior hardware, but even more importantly, it had FIXED hardware - so you knew EXACTLY what you were writing for, and didn't have to try and cope with different sound or video cards.

 

[ThermalRunaway]

This is true. The fact that you were talking about fixed hardware also meant you could "bang" the hardware directly, avoiding proper software protocols which you would otherwise have to take. Quite a few Amiga games were written in this way. It's a bit of a naughty way to go about things really but it increased the speed of the programs and when you're talking about fixed hardware it's not such a big problem.

Brian

 

[ThermalRunaway]

Mind you, while we're on the subject I think there's more to the reason why Windows applications run slowly than the fact that they're often written in higher level languages and designed to run on different hardware configurations. Windows is slow as "a snail on a bad day" because it doesn't manage it's resources properly (infact Windows seems to CONSUME resources). Windows is also a bad multi-tasking OS and, although the situation with multi-tasking has improved drastically with XP, it's still not good enough. AmigaOS on the other hand was a much much more efficient Operating System. It allocated system resources much more effectively and, rather than consume all the resources for itself it made the full resources of the system available to the applications. This is what makes a GOOD operating system. Windows is a BAD operating system because it consumes all the resources for itself, leaving little for the applications which run on top of it. Also, AmigaOS had a very good pre-emptive multi-tasking system which I believe even today out performs Windows. Obviously there's the issue of hardware which has moved on to such a drastic amount that you could never really compare AmigaOS running on a 50Mhz Amiga to Windows running on a 3Ghz PC. But if you were to take away the hardware issue, I believe AmigaOS would run circles around Windows, even today.

The fact that AmigaOS never made it as a mainstream OS is one of the modern sad stories of technology and is a prime example of "the best product isn't necessarily the winning product". There are other examples of this throughout history as well - betamax was a better standard than VHS (in terms of picture quality) and yet it lost out. A lot of it is down to marketing rather than who has the best product itself.

Brian

 

[Joel Rainville]

AmigaOS [...] is a prime example of "the best product isn't necessarily the winning product". [...] A lot of it is down to marketing rather than who has the best product itself.

Windows is a bad operating system because it does everything, or at least it tries to. These days, Windows XP is a business desktop OS, a file sharing server, a printer spooler, a home PC OS, a gaming OS, etc.

It's bad because it does everything. It's good because it does everything.

If you wanna see Win32 assembly, head over to https://www.masm32.com. I have a small Notepad replacement program written in assembly that's lightning fast, even on that bloated Windows XP.

 

[Nigel Goodwin]

Windows is also a bad multi-tasking OS and, although the situation with multi-tasking has improved drastically with XP, it's still not good enough. AmigaOS on the other hand was a much much more efficient Operating System.

It's not just Windows that's a poor multi-tasker, Intel processors aren't very good for it either - the old 68000 was a much better choice for a multi-tasking operating system.

AmigaOS was also quite heavily based on Unix, including case sensitive file names and long filenames (something which Windows still doesn't do properly!).

 

[Joel Rainville]

It's not just Windows that's a poor multi-tasker, Intel processors aren't very good for it either - the old 68000 was a much better choice for a multi-tasking operating system.

The problem with Intel processors is that it stayed backward compatible, which is also its big advantage over other platforms.

I once worked in a dishwashers manufacturing shop. On the assembly line, they had a 80286 PC running a small DOS application controlling some part of the process through the serial port (or something that looked like a serial port). Came a time when obtaining a 80286 replacement to do the job was getting too complicated. It was replaced by a brand new Pentium III system, which, with a bit of tweaking could run the original DOS application. In-house software developers could then take their time to come up with replacement software, although it wouldn't surprise me to learn that they never did.

Try to imagine that with any other hardware platform.

In theory, the Apple/MAC is a superior platform. In practice, what you wrote on a MAC 10 years ago is a pain, if not impossible to run today.

Backward compatibility is what won the war for the Windows/Intel (sometimes called Wintel) systems. Like I said, it's bad at everything, but it does everything.

 

[ThermalRunaway]

I agree with some of what you're saying, with regard to Intel insisting on providing backwards compatability with their CPUs. However, I don't feel it's the advantage that it appears to be. A brand new Pentium processor of today would be quite capable of running an emulation of an older CPU and therefore, backwards compatability could be more cheaply obtained in software. Also, I've met plenty of programs which are "XP" only. I think that's more a feature of Windows than it is of the CPU running the show underneath, but the fact remains that in some cases, Windows isn't very backwards compatible at all.

I also disagree that this backwards comaptability won the war for Windows. It's clear that Windows did win the war, but it wasn't due to compatability issues, it was more to do with far superior and clever marketing. Apple Macs weren't very good during the eighties and early ninetees (infact I loathed them) but Amiga and it's OS was years ahead of the competition. It's Operating System alone was far superior to Windows or MacOS and, if the war had been based on these points alone, Windows would have failed miserably. But Windows was marketed very cleverly and managed to get into the business world very early on. Because all businesses like to have computers which are compatible with each others, it quickly became the standard to have a PC running Windows in your business, and this is what really jump-started the home market for Windows as well. People wanted to buy a computer for the home which they could use to do their work stuff on in their spare time. It'd be no good buying an Amiga or a Mac or something else to do this work, because you needed to maintain compatability with the machines at work, so most families were prompted to buy a PC for the home due to this fact alone. Meawhile Commodore were doing a pretty good job of ruining things completely for the Amiga by neglecting platform development, failing to invest in the designs, and marketing very badly. The Amiga was doomed to failure because of Commodore's bosses and when it met it's demise, the Mac was able to fill the gap in the market that the Amiga left. The Amiga was once king of graphics and video - now the Mac has that title.

So basically Windows won the war mainly due to it's better Marketing techniques. You've got to take your hat off to Bill Gates for that, if nothing else.

Brian

 

[Joel Rainville]

I agree with some of what you're saying, with regard to Intel insisting on providing backwards compatability with their CPUs. However, I don't feel it's the advantage that it appears to be. A brand new Pentium processor of today would be quite capable of running an emulation of an older CPU and therefore, backwards compatability could be more cheaply obtained in software. Also, I've met plenty of programs which are "XP" only. I think that's more a feature of Windows than it is of the CPU running the show underneath, but the fact remains that in some cases, Windows isn't very backwards compatible at all.

You're confusing backward and upward compatibility. That "XP only" program you're talking about will still work in the next version of Windows. That's backward hardware compatibility. Or upward software compatibility if you prefer. Or the other way around. I'm getting confused myself. The fact is, old software runs on new hardware, not the other way around.

Marketing indeed won the war. Guess what that marketing was (and is!) based on? Year after year after year, IBM and Microsoft could come up to the owner of a big company and tell him that he could get faster processing just by replacing the hardware, and that it would run the existing software just fine. And that's basically why you still have an IBM-clone PC running Windows at home. Because the owner of that big company bought into the Microsoft/Intel solution 20 years ago, and kept doing it up until now. If at any point Intel decided to break the chain of backward compatibility (and they would have had very good reasons to do so, I think we all agree on that), things might be different today.

 

[Joel Rainville]

A brand new Pentium processor of today would be quite capable of running an emulation of an older CPU and therefore, backwards compatability could be more cheaply obtained in software.

True, but that's not exactly what Intel and Microsoft are aiming for. They want that brand new Pentium to be backward compatible with last year's Pentium. It will take a while before a processor has enough power to do that in software to allow for a complete reengineering of the x86 architecture.

The Intel x86 hasn't evolved overnight. It's the constant backward compatibility offered year after year that won the war. It's like slowly winning a chess game using only your pawns

 

[ThermalRunaway]

But any CPU called a "Pentium" should be in some way compatible with another CPU with the same name anyway. Obviously newer Pentium processors may take advantage of new developments in technology, but basic compatability should be there, otherwise you could argue that they shouldn't call it a Pentium anymore. If we go back to Nigel's example of the 68000 series (a fantasic processor in it's day) the various version of this processor are very much compatible with each other, provided you write good code that is. If we take the last of the 68000 series (the 68060) and compare it to the first (the 68000) the 68060 is backwards compatible with it. The 68060 has newer and more improved features that software writers can take advantage of, but a 68060 can quite easily run code which was written for the 68000 because they are the same series of processor. The backwards compatability you're talking about is the leap from 8086 series to the Pentium series of processors. Apparently even these are backwards compatible, and it's this that I feel would be more cheaply accomplished from within software.

If you go back to the 68000 series again, the next CPU up from the 68060 is the PPC series of processors which, because they are not compatible with one another, are given a different series "name".

Brian

 

[Joel Rainville]

...

 

[Joel Rainville]

But any CPU called a "Pentium" should be in some way compatible with another CPU with the same name anyway. Obviously newer Pentium processors may take advantage of new developments in technology, but basic compatability should be there, otherwise you could argue that they shouldn't call it a Pentium anymore.

Indeed, and it is the currently reality. What's your point?

If we go back to Nigel's example of the 68000 series (a fantasic processor in it's day) the various version of this processor are very much compatible with each other, provided you write good code that is. If we take the last of the 68000 series (the 68060) and compare it to the first (the 68000) the 68060 is backwards compatible with it. The 68060 has newer and more improved features that software writers can take advantage of, but a 68060 can quite easily run code which was written for the 68000 because they are the same series of processor.

Yes, but someday they decided to stop the chain and start from scratch. That's where you start to lose market share. That's where the best marketing strategy in the world won't save your product. Not in this world anyway.

The backwards compatability you're talking about is the leap from 8086 series to the Pentium series of processors. Apparently even these are backwards compatible, and it's this that I feel would be more cheaply accomplished from within software.

You're not getting my point. The newer Pentiums don't really care about compatibility with the 8086. It's just that they happen to be compatible with it because the x86 has always been backward compatible, year after year. That's why it doesn't make much sense to do it in software. It's already there in hardware, inherited from years of backward compatibility.

Maybe you're confused by the "Pentium" brand name? The pentium is just the next evolution after the 80486 and was in fact for a while called the 80586 before entering the market. Current Pentiums would be something like 80786s or so. It's the same basic x86 architecture, on serious steroids.

If you go back to the 68000 series again, the next CPU up from the 68060 is the PPC series of processors which, because they are not compatible with one another, are given a different series "name".

Why do you care about the actual brand names used? We're talking actual architecture and compatibility here, not what the processors are called.

Here's the actual backward compatibility chain. There's no leap between the Pentium and the 8086. The link is indirect, through years of evolution. Get it?

8086 < 80286 < 80386 < 80486 < Pentium < Pentium II < Pentium III < etc...