ThermalRunaway said: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.
Joel Rainville said:ThermalRunaway said: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?
ThermalRunaway said: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?
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'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)?
ThermalRunaway said: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 [...]
ThermalRunaway said: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.
ThermalRunaway said: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.
ThermalRunaway said: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.
Nigel Goodwin said: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.
ThermalRunaway said: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.
ThermalRunaway said: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.
ThermalRunaway said: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".
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?