A DLL is similar to a folder, but it allows for multiple programs/executables to access it at once, thus conserving memory (I think).
What is Mac's equivalent of a DLL? I was looking through the Google Chrome folders inside ~/Library/Application Support, and instead of the regular Windows Default.dll there was just a folder, "Default" as a regular file, with contents, I assume, would regularly be inside the DLL.
Does the Mac equivalent provide the same function?
The equivalents to a Windows DLL on OS X are Frameworks (Cocoa) or dylibs (BSD). The system supplied ones are in /usr/lib and /System/Library/Frameworks respectively.
The folder you mention, Library/Application Support is similar to the Application Data (or AppRoaming now?) folders in Windows, containing your applications' personal settings.
While I don't know what the equivalent for Chrome's default.dll on OS X is, the application bundle contains the following:
Guessing from the size, it looks like Google Chrome Framework might be important (the folder Frameworks just above doesn't contain much of interest)
There's no real DLLs in OS X, Linux, or any POSIX for that matter. They don't make the differentiation.
Why?
A lot of Mac stuff, for one, is self-contained (.app's are really just folders after all).
The binaries in Mac OS X (and Linux and other *Nixes) use the ELF (which stands for Executable and Library Format) for both libraries and executables.
The Default file that you found in there was probably an ELF binary.
Update: dmckee points out that .dylibs are under the Mach-O format exclusive to Macs. It's hard to distinguish the two by sight, however, because neither of them actually require any extension.
The closest Linux and Mac equivalents are called "shared object files" (usually taking a .so extension) and dynamic libraries (usually taking a .dylib extension).
Shared objects are used extensively on typical Linux systems. Dynamic libraries are not quite as ubiquitous because the .app format allows a very safe distribution mechanism for supporting multiple architectures at the cost of larger executable "files".
