Technical How-Tos and money saving tips
ATL is a library provided by Microsoft for C++ programmers using Microsoft’s Visual Studio IDE. The library is a collection of C++ templates that provide capabilities such as lists, queues, stacks, as well as other data structures and the functionality to add and remove items to and from those data structures. Since they are templates, a programmer can use their own, custom types with these extended data structures and capabilities.
It’s an enormous time saver for C++ developers.
When a library, DLL, Framework, or remote service is made available, with subroutines made available for other programs to use, the subroutines, their names, the parameters they take, and the types of data those subroutines return are called the application programming interface.
In other words, when a program makes a call into one of the subroutines to get work done, it can only do it through one of the public subroutines. There may be plenty more capability inside the library that provides the API, but only the routines exposed publicly can be called by external programs.
DirectX is a Microsoft technology built into all modern versions of Windows that handles multi media. There are libraries and APIs to handle playing sounds/music, playing videos, rendering 3D graphics, and display the Windows’ Graphical User Interface.
When a program is loaded from disk and then begins to run, it usually asks the operating system and other components to perform some work on its behalf, such as reading or writing files, or asking 3rd party software components to do other work on its behalf, such as drawing or rotating 3D objects on the screen.
On a Windows based computer, these external code components that are not part of the primary program running are stored in files with the name “.DLL” appended to the end of the file name. These files have subroutines that other programs can use. Programs that need to use these shared routines load these DLL files from disk at run time (this is the “dynamic” part) and “link” to them, meaning they can then call them after they’re loaded.
A lot of programmers (usually Visual BASIC programmers who don’t have experience outside of Visual BASIC) incorrectly believe that DLL means COM Component. This is because the only type of DLL that can be made with Visual BASIC is a COM component DLL. It’s important to understand that a DLL is simply nothing more than a plain old collection of subroutines packaged together in a single file with “.DLL” appended to the end. There is a standard way to collect the routines in the file though, but a DLL isn’t necessarily a COM component. As a matter of fact, the vast majority of DLLs are NOT COM components. COM components are a special breed of DLL that have much more than just subroutines in them. They also have meta data describing the subroutines, their names, their parameters, etc… and confirm to a very strict specification in order to be a COM component, so that it can be installed, globally, on the machine. Plain old DLLs can’t be installed globally, don’t have the extra meta data, and can simply be copied into a programs folder in order to be used by that program. Plain old DLLs can be copied all over the hard drive and even different versions of them.
This is important to know, because if you’re ever involved with a programmer that only knows the old style Visual BASIC (the one before VB.NET), if you ever say “DLL”, they’re going to think “COM”. And if they ever say “DLL”, they’re going to mean “COM”. Lots of miscommunications can and have happened because of this lack of understanding by VB neophytes. If you hand them a regular DLL, they’re going to try their hardest to “install” it, which can’t be done with regular DLLs. They will likely come to you and tell you there’s something wrong with your DLL. You’ll now understand why they think this and you’ll now be able to educate them.
So, all COM components are DLLs, but not all DLLs are COM components (most DLLs are not COM components).
When a piece of software runs, it continuously needs to request more memory from the operating system and constantly returns no longer needed memory back to the system. Programs will also move data around to different parts of allocated memory. If they need memory for a list of items, they may request enough memory to hold the entire list, but if the list may be changing in size over time, they may break the list into manageable pieces and only allocate small pieces at a time as items are added or removed from the list. These are forms of “memory management”.
Computer memory is a very limited resources available to programs, especially as modern operating systems generally have dozens of programs running simultaneously, all competing for the limited amount of memory. This make memory management a critical part of software development.
One of the many tactics in memory management is garbage collection, which consists of hunting down unused memory and reclaiming it back for other programs to use.
As a piece of software continues to run, it continuously requests segments of memory to use for its own purposes. It eventually no longer needs some of the memory that it asked for and returns it back to the memory manager. Sometimes programmers forget to explicitly release used memory back tot he memory manager and none of their program code has any references to the used memory any more. When this happens, it’s called a “memory leak” and unused memory starts piling up as unavailable.
Garbage collection is the process of a memory manager that occasionally looks for memory that’s been asked for use by programs, granted, and the discarded inappropriately. The garbage collector then reclaims that memory back to the “free pool” of memory .
Different technologies and operating systems have their own implementation of memory management and of garbage collection. Microsoft .NET technologies have a garbage collector that runs in its own thread. It is triggered at unpredictable moments to find and reclaim discarded memory.
An IDE is a programming tool that integrates many (if not all) of the utilities a programmer needs to write a program. Most IDEs contain at least the following utilities:
Many IDEs have more than that. Some popular IDEs are:
An Integrated Development Environment provides a seamless solution for a programmer to write a program, minimizing the amount of time the programmer has to leave that environment to accomplish his programming tasks.
For example, to write a Windows program with say, Microsoft Visual Studio, a programmer simply opens the file menu, choose “New Project”, chooses the language and chooses a Windows Forms application template, and Visual Studio creates source files, displays a tree view with all of the source files, and writes some skeleton code. It also provides a blank window that the developer can then drag and drop Windows controls onto, like buttons, radio buttons, list boxes, menus, etc… Once the developer has visually designed the window for his application, he can then set properties on each component by clicking a component, then changing properties in an IDE provided properties grid for that component. Then the developer can write some code to respond to user initiated events, such as clicking a button, choosing a menu item, etc…
After the developer has written some code, he can the execute the program to test it. The IDE will compile the programmer’s source code into code that the machine can execute. It will then start the new program so the programmer can try it out.
The programmer can also set what are called “break points” on certain lines in his code so that as the programming is running, if it gets to one of those lines of code, the IDE will bring itself up front and display the source code and the values of the program variables that the programmer can examine while the new program is suspended. The programmer can also step through his code, one line at a time using the IDE.
Without an IDE, much of this is impossible or very difficult. An IDE makes programming easier and quicker and helps the programmer write code with fewer bugs and get his finished product out earlier.
Mono (the other white meat) is a technology created by the open source community to provide Microsoft .NET technologies on non-Microsoft platforms like Linux, Mac OSX, and now iPhone.
Read this article for a description of Microsoft.NET technologies:
Microsoft .NET Technologies
Mono is simply the Linux and Mac version of that technology. Mono is not supported by Microsoft in any way. As such, Mono gets updated with new capabilities after .NET is updated with the latest. Once .NET is updated, the Mono development team examines 
what’s new to .NET, then they implement their own code to provide the same capabilities. In general, Mono is about 6 months behind the latest Microsoft .NET technologies.
To download the Mono framework or to become involved in the Mono development team, go to the mono web site.
In addition to Windows, Mac, & Linux, Mono is now available for the iPhone with a product call MonoTouch. Now, you don’t have to learn a proprietary language (objective C) to write iPhone applications. This will make iPhone development MUCH easier.
As of this writing, Microsoft .NET technologies have been around for roughly a decade (the 1st 2 or so years were beta).
It’s difficult to give a quick definition of “.NET” because it covers so much material.
.NET (sometimes spelled DotNet or Dot Net, but always pronounced “dot net”) is called a “managed” environment. This means, programs written with the .NET technologies don’t actually run as “raw” programs on the machine’s CPU. The binary (or executable) files aren’t created for any particular CPU hardware. This means one EXE file can run on various types of different hardware without needing to be recompiled. For example, a program written in C# or VB.NET for a Windows Mobile device that uses say an ARM processor, can run, as-is on an Intel or AMD based PC. The code in the EXE or DLL files is coded for a virtual processor that doesn’t really exist. The Microsoft .NET technology that comes installed on all modern Windows machines knows how to interpret the code in a .NET EXE or DLL. It will convert it to the local CPU’s code as it’s needed. Since the code isn’t converted into actual machine code until it’s time to run, the .NET runtime environment has complete control over what the program can do and can even deny an application to ability to say, send files over the network. Security was built into .NET technologies from the very early design phases. Though, nothing is impossible, it is very difficult to write a .NET program that can work around the security built into the .NET technologies. As the technology matures, more and more loopholes are closed off. Today, it’s a very robust technology.
.NET technologies provide a run time environment. This is the part that translates the binary code from a program into the machine code for the CPU. It also handles garbage collection and memory management, as well as security.
The .NET Framework is a HUMONGOUS library of classes available for the .NET developers to use. The original version of the .NET Framework (v1.0), released in Feb 2002 had over 10,000 classes. Each class having a dozen or more methods, properties, and events. As of this writing, the current version is 3.5 and 4.0 is just around the corner. The .NET Framework has classes for handling strings, databases, network communication, encryption, graphics, window management, etc… The capabilities are so large, there’s probably not a single person alive that knows everything that it provides.
.NET is fully object oriented, from the run time environment, to the framework, to the languages. Speaking of languages, Microsoft provides and supports two .NET languages (C# and VB.NET). There are plenty of other languages available too from Cobol.NET to RPG.NET to Python.NET. If there’s a popular language out there, there’s probably a .NET version of it.
The primary development tool for writing .NET software is Microsoft Visual Studio. It comes in various flavors from the free “Express” edition to the top of the line “Team Suite” edition.
Microsoft’s .NET Framework is available on Windows, Windows Mobile, XBox 360, and various other platforms. Microsoft does not provide a version for Mac or Linux, but an the open source community has solved that problem by recreating .NET technologies, from scratch, for Linux, Windows, and Mac with the Mono project. The primary development product for Mono is Sharp Develop. It’s a free, open source, fully capable IDE that works on Windows, Mac, and Linux.
.NET is a very developer friendly platform because it helps prevent common programmer errors like memory over writes, deallocating memory, is fully object oriented, and provides so much functionality is the very large framework, and has a very powerful IDE. There is a very large user community around .NET technologies too, so help is available all over the internet and in hundreds of .NET user groups all around the world. Your local town probably has a .NET user group too.
A library is a collection of routines that’s usually meant to be shared for multiple programs. Generally this involves providing a file (usually in the form of a DLL or a COM Component) that gets distributed with each program that uses it. With more modern development technology, it’s usually more than just a collection of global routines, but a collection of classes for use in Object Oriented programs.
A framework is a library, but it usually much more. Sometimes a framework is not distributed as a single file (or even multiple files) with each program that uses it. A framework is usually a large component that’s installed on a machine, and that one installed instance is used by multiple programs on the machine. An update to the framework affects all programs on the machine that use it. Some examples of frameworks are:
There are thousands of frameworks available. Some are free, some need to be purchased, some are part of your Operating System.
A Framework generally consists of lots and lots of functionality, providing a complete solution for a programmer to code a certain type of capability into their program.