C

Socket programming

• http://www.thegeekstuff.com/2011/12/c-socket-programming/
• Beej's Guide to Network Programming
• http://www.slideshare.net/hominhchuc/writing-client-server-programs-in-c-writing-clientserver-programs-in-c (see slides pp 19-23 & reference p31)

Example 1

http://www.linuxhowtos.org/C_C++/socket.htm

$ gcc server.c -o server
$ gcc client.c -o client
$ ./server 51717
$ ./client 192.168.0.21 51717
Please enter the message: Who are you?
I got your message

where 192.168.0.21 is the ip address on the server.

If everything works correctly, the server will display your message on stdout, send an acknowledgement message to the client and terminate. The client will print the acknowledgement message from the server and then terminate.

We can actually run the client on a different machine although we can also run both client and server on the same machine. Once we use the port (51717) one time, we can not use the same port to run it again??? We can choose any port number between 2000 and 65535.

Windows programming

Resource

• http://www.stanford.edu/class/cs193w/
• Petzold Programming Windows 1998
• Kruglinski Programming Microsoft Visual C++, 1998

Difference between Win32 project and CLR (common language runtime) project

See here.

A Win32 project is used if you want to end up with a DLL or a Win32 application usually using the bare WinAPI. A CLR project is used to create C++/CLI project, i.e. to use C++/CLI to target the .NET platform.

The main difference between projects is what Visual Studio comes up with in terms of pre-created files. A windowed Win32 application for example (what you get when you choose Win32 project, but not a DLL) is created with a file for resources (menus, acceleators, icons etc.) and some default code to create and register a window class and to instantiate this window.

Quoted from http://en.wikipedia.org/wiki/Common_Language_Runtime

The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET framework and is responsible for managing the execution of .NET programs. In a process known as Just-in-time compilation, the compiled code is converted into machine instructions that, in turn, are executed by the computer's CPU. The CLR provides additional services including memory management, type safety and exception handling. All programs written for the .NET framework, regardless of programming language, are executed by the CLR. It provides exception handling, garbage collection and thread management. CLR is common to all versions of the .NET framework.

The CLR is Microsoft's implementation of the Common Language Infrastructure (CLI) standard.

Difference between Win32, MFC and .NET

http://stackoverflow.com/questions/821676/how-do-i-decide-whether-to-use-atl-mfc-win32-or-clr-for-a-new-c-project

Using the CLR will provide you with the most expressive set of libraries (the entire .NET framework), at the cost of restricting your executable to requiring the .NET framework to be installed at runtime, as well as limiting you to the Windows platform (however, all 4 listed technologies are windows only, so the platform limitation is probably the least troublesome).

However, CLR requires you to use the C++/CLI extensions to the C++ language, so you'll, in essense, need to learn some extra language features in order to use this. Doing so gives you many "extras," such as access to the .net libraries, full garbage collection, etc.

Using Win32 directly provides the smallest executables, with the fewest dependencies, but is more work to write. You have the least amount of helper libraries, so you're writing more of the code.

Win32 is the raw, bare-metal way of doing it. It's tedious, difficult to use, and has alot of small details you need to remember otherwise things will fail in relatively mysterious ways.

MFC builds upon Win32 to provide you an object oriented way of building your application. It's not a replacement for Win32, but rather an enhancement - it does alot of the hard work for you.

System.Windows.Forms (which is what I assume you meant by CLR) is completely different, but has large similarities to MFC from its basic structure. It's by far the easiest to use, but requires the .NET framework, which may or may not be a hindrance in your case.