Book Reviews

[Rhoon]

Hi all,

I'm considering getting into Windows programming. I have 6 on and off years of C ... generic Dos/Unix stuff. 1 year of solid Java and I'm fairly decent with C++. I'm wondering what I need to consider when getting into windows programming and I'm eager to find out what books everyone recommends. I've found DEitel and Deitel to have really readable C++ / Java books. Whats everyone's thoughts on the books you've read/ sources you've used to gain steps into C++ Programming for windows. Also whats the difference between using MFC and not using it? Thanks for any advice.

Andrew

 

[xwb]

You are in a real minefield here. It depends on which aspect of Windows you wish to learn. Windows is a very big OS so there is lots to learn. The part I find difficult is not having the same level of control that you do with Unix/DOS. Sometimes, methods are forced on you and it is hard work fighting it.

There is Windows as in NT, 95, XP etc and Windows CE, which has now been renamed PocketPC 2002. 95/98/ME are slightly different from NT/2K/XP but most programs that will work on one will normally work on the other. CE programs are quite different. At the moment, they are only used for PDAs, but you might find it in your central heating or video player on day.

With windows programming, first, there is the SDK (System Development Kit). These are native C calls or macros which are used for controlling most of windows. Similar to X-Motif but not always consistent. Sometimes parameters are the opposite of what you expect them to be.

Creating libraries is similar to Unix: there are .lib and .dll. .lib is the same as .a on Unix and .dll is .so (or .sl if you are on HPUX). The linkers are not one-pass so you only need to specify the libraries once.

Then there is MFC where all objects are based on CObject. Most of MFC is just a bunch of wrappers for SDK. It is fairly comprehensive, very much like Java but the problem is that MFC programs are huge. The thing I hate about MFC is that it forces you do do programs the Microsoft way, which may not always be the most efficient for your particular application. I don't know if you can still find MFC books.

With MFC, Dialogs are split into 2: the control part and the data part (document view?). This is automatically generated by the wizards. The problem that I have is that there are so many files, I find it difficult to remember what to change but 10 million lemmings can't be wrong so it is probably just me. I don't use MFC anyway.

ATL (Active template library) is based on STL. It basically contains the non-GUI bits of MFC as templates. The result is that you can switch from MFC to ATL easily and the programs are a lot smaller. Having said that, it is better to use the STL templates than the ATL ones: prefer string to CString, map to CMap. If you stick to STL, the code is relatively portable and you don't get the really strange problems that arise from using ATL.

WTL (Windows template library) is based on ATL. It is the GUI bit of MFC as templates. This is nice in that you can download it from MSDN and it is only 700K. With WTL, your GUI programs come out smaller too but there is a catch: there are no books on it as yet. There are a few tutorials on the net but they are pretty trivial. The nice bit is you can see the contents of the template and how it uses the SDK (non-MFC) calls.

I don't know how much Unix programming you've done. IPCs on Windows are similar but quite messy. Most of this is just through experience and looking up MSDN. I have yet to see a book on it. Shared memory needs to be locked or unlocked before use. Semaphores and threads are well behaved. Inter process messaging can be done with Mailslots (similar to message queues on Unix), DDE (similar to RPCs on Unix), RPC/DCOM (similar to CORBA on Java), pipes and unnamed pipes (on NT only).

Communications is quite simple but like everything Microsoft, it has its own API equivalents for sockets, serial communications etc. The nice bit is that serial comms is very simple compared to what it was in DOS. Again, all this info is from MSDN. There are hardly any books on the subject.

For graphics, there is Active X or OpenGL. Active X is specifically MS, OpenGL can be used on Unix too. There are quite a few tutorials on OpenGL on the net. Active X is actually for multimedia. It is a lot nicer to use than the Windows API and is a lot faster too. Again, there are not many books on the topic. I don't normally recommend the "For Dummies" books because they are too trivial but the one on "Windows Game Programming" is very good. If you are thinking 3D, you are probably on your own. Whenever I've asked a question about it, no one has ever given an answer. Anyway, the calls have so many parameters, it is easy to get one of them wrong.

Database connectivity depends on the database you are connecting to. So far, I've only connected to Oracle using OCI but that is Oracle's interface. I don't know about the other databases. You'd probably have to look at ODBC and DAO for that.

Windows programs can be run in Windows mode or Console mode. Console mode is basically DOS but with a completely different API. Look up "Using the Console" on MSDN.

Device drivers on Windows are completely different from Unix. You have to download the DDK (Device Driver's Development Kit - notice this has 3Ds) for that. Also, there are different DDKs for different versions of Windows.

MSDN is a collection of all sorts. Some of the information is recent and some of it is very old and totally outdated. Some of it is only applicable to Windows 3.x. If you are picking up stuff from MSDN, don't treat it as gospel because it may only refer to a specific version of Windows: not necessarily the one you are using.

I don't know about .net references to it every so often. In fact, lots of people will tell you how wonderful .net is but they won't be able to tell you what it is. It is like "structured programming" - everyone has a different definition. I have yet to see a definition of what .net is.

I know this is pretty useless as far as recommending books is concerned but nowadays, you basically look up everything Microsoft on MSDN.