Talk:Dynamic-link library

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
WikiProject Microsoft Windows / Computing  (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing (marked as Mid-importance).
WikiProject Computer Security / Computing   
WikiProject icon This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.

Comment on GUIDs[edit]

which places the DLL's location and its globally unique ID (GUID) in the registry. Programs can then use the DLL by looking up its GUID in the registry to find its location.

This is wrong DLLs don't have GUIDs. A DLL can have one or more components inside and those are the ones that have unique GUIDs. For example:

[HKEY_CLASSES_ROOT\CLSID\{00000105-0000-0010-8000-00AA006D2EA4}\InprocServer32] @="C:\\Program Files\\Common Files\\Microsoft Shared\\DAO\\dao360.dll"

[HKEY_CLASSES_ROOT\CLSID\{00000106-0000-0010-8000-00AA006D2EA4}\InprocServer32] @="C:\\Program Files\\Common Files\\Microsoft Shared\\DAO\\dao360.dll"

different GUIDs pointing to the same DLL. -- 11:05, 22 January 2007 (UTC)

User: introduced many small factual errors in his (obviously good-faith) edits, so I decided to revert them and merge the valuable additions gradually.

E.g. DLLs aren't limited to PE files (they were NE in 16-bit Windows); SYS, DRV and FO? have nothing to do with them, except they are also PE; ordinals are mandatory, while names aren't; and so on.

I expect to edit the article further. --tyomitch 06:55, 28 November 2005 (UTC)


The article still needs information on at least the following points.

  • address space
  1. this is a technical idea, and should be explained, or carry a link to a descriptive page. —Preceding unsigned comment added by (talk) 09:17, 25 November 2008 (UTC)
  • DLL search paths
  1. directory of executing application
  2. current directory (if different from executing app)
    • May add additional directories here with SetDllDirectory
    • GetDllDirectory retrieves a list of these paths.
  3. Windows system directory
  4. 16-bit windows system directory (obsolete)
  5. Windows directory (GetWindowsDirectory)
  6. Directories in the PATH environment variable
  • SetDllDirectory(NULL) resets the search path to the defaults.
  • DLL main entry point
    • Notifications
    • DisableThreadLibraryCalls disables DLL_THREAD_ATTACH AND DLL_THREAD_DETACH notifications.
  • DLL process and thread interaction and safety
  • Semi-standard exported functions
  • #pragma comment(lib, "Example.lib")
  • Delay loading DLLs (lazy binding)
    • #pragma comment(lib, "/DelayLoad:Example.dll")
  • DLLs in Delphi
    • Compiler and language considerations
      • Real project file contents... - ie exports section can be put anywhere, not exactly at the end
      • Some words about Delphi's specific data type string in libraries (Can be used inside, but when passed in parameter or result, BORLANDMM.DLL must be included to the project. How to obtain this)
    • Examples
      • Other directives like index, name, resident
      • Calling conversions (why cdecl??? stdcall is default, even if there are only soft differences)
      • Using dll without external directive (LoadLibrary(...), GetProcAddress(...)...)

Are you sure all this detail belongs here? Most of this is pure MSDN material. Peter-HHH (talk) 23:41, 13 January 2011 (UTC)

Requested move[edit]

There's just one thing called Dynamic-Link Library; no disamb needed disamb, if necessary, should go by some other name. --tyomitch 09:19, 4 December 2005 (UTC)

Add *Support or *Oppose followed by an optional one sentence explanation, then sign your vote with ~~~~
  • Support. There is no usage outside of computing, and there are probably several orders of magnitude more people who will use dynamic link library in the context of Microsoft DLLs. Jsmethers 22:11, 4 December 2005 (UTC)


  • The article was previously moved from Dynamic-Link Library to Microsoft Dynamic Link Library. This is a request to move it back. Most references have already been changed to point to the new locations. Even before the move, there were a large number if errors in the use of Dynamic Link Library. These errors clearly show there is ambiguity in the use of Dyanmic-Link Library alone.
    • Some used it in the context of Microsoft's implementation and pointed to the generic shared library page, which contains information about the concept of dynamic linking used in libraries.
    • Some used it in the context of dynamic linking used in libraries and pointed to the page on Microsoft's implementation.
Please, give an example of such usage. --tyomitch 09:16, 4 December 2005 (UTC)
The links in these articles should simply be fixed. The addition of a disambiguation line at the top of the Dynamic Link Library page should be sufficient reminder to prevent erroneous linking. Jsmethers 22:11, 4 December 2005 (UTC)
  • Microsoft uses both Dynamic Link Library and Dynamic-Link Library throughout their documentation.
But never Dynamically linked library; that one is more suitable for a disamb page, IMO. --tyomitch 09:16, 4 December 2005 (UTC)
  • This change is more or less a focus on a noun-phrase used within the Microsoft subfieled of computing. Microsoft should be added to denote this context.
Microsoft doesn't calls it Microsoft Dynamic Link Library; it's a made up name. --tyomitch 09:16, 4 December 2005 (UTC)
Microsoft also does not call Windows Microsoft Windows. The context is assumed. The problem is one of how much context should be in the title of a wikipedia article.
FWIW, it does. Run "winver" and see what it says. --tyomitch 13:24, 5 December 2005 (UTC)
The article should be called by the most common use (by orders of magnitude), and a friendly disambiguation link should be added at the top. Jsmethers 22:11, 4 December 2005 (UTC)
  • It focuses on adjective versus adverb and verb tenses. One of the following permutations may be used when writing and speaking about dynamic link libraries.
    • dynamic link library
    • dynamically linked library
    • dynamic linking library
    • dynamically linking library
I cannot find an official policy regarding the use of disamb pages, but usually the most common use of a word bypasses disamb, and links to a disamb page in its first line. Cf. Plasma and Plasma (disambiguation); Laser and Laser (disambiguation); etc. --tyomitch 09:16, 4 December 2005 (UTC)
See disambiguation, it's a guideline. The most common name used when searching wikipedia should be used as the title of the article. Such searches should not go directly to a disambiguation page.
  • This article should be moved back.
  • A friendly link should be placed at the top of the page which points to the disambiguation page.
  • The current disambiguation page should be moved to Dynamically linked library or Dynamic link library (disambiguation).
  • The other permutations should probably redirect to the disambiguation page.
  • A seperate article on the concept of dynamic linking should be created.
Jsmethers 22:11, 4 December 2005 (UTC)
  • To put this requested move in context, it would be like asking the Microsoft Windows be moved to simply Windows because Microsoft Windows is commonly refered to as just Windows in the Microsoft community.
Windows did redirect to Microsoft Windows since June 11. Then on September 16, an anon came and changed it into a disamb page without any discussion. --tyomitch 09:16, 4 December 2005 (UTC)

  • The article Dynamic link library is now a redirect to Microsoft Dynamic Link Library. There may be no need to move this article anymore unless it is desired that the word Microsoft be taken out. In fact, it may be desireable to leave it in this state so that in the furture someone will not come along and move the article again, but simple change the redirect.

Jsmethers 01:16, 6 December 2005 (UTC)

I believe that the article should be moved back, namely because the official (per Microsoft Manual of Style for Technical Publications) spelling-out of DLLs is dynamic-link library. (What's more interesting, it's all-lowercase there.) If anyone else decides to participate in this discussion, he is welcome; the discussion is open to everybody. --tyomitch 17:46, 6 December 2005 (UTC)
I moved the article to Dynamic-link library, which happened to be free. In case this is controversial (which is unlikely, given consensus with User:Jsmethers and no concern from others), perhaps a prior discussion here would be better than breaking out another move conflict. --tyomitch 18:00, 6 December 2005 (UTC)
bohan 2006-02-04
This is a boring terminology versus lexicography debate..
If i understand it correctly, in wikipedia, disambiguation pages are used when a term may refer to several different concepts, and redirections are used when a term is a synonym for a "preferred", unambiguous term that refers to only one concept. When there is no preferred term, or when the preferred term does not refer to only one concept, the wikipedia system doesn't work anymore. In the case of this page, it only talks about the concept of dynamically loaded libraries in the "domain" of Microsoft's operating system, while the concept stays the same on all systems. Since it is very probable that someone searches the term used as the title of this article while looking for a more general explanation of the concept, i think it should at least refer to Dynamic library (disambiguation) or Dynamic library or simply the broader concept of Library (computer_science) (there really is mess on the former two links).
This article should talk about Dynamic-link libraries in general (as they exist in windows, os/2, linux, unix, etc...), not Microsoft's particular vision of them. The current contents of this article should go to a Microsoft-specific article. —Preceding unsigned comment added by (talk) 13:16, 19 September 2008 (UTC)

Linux operating system also supports dynamic linked library so that information must be included in this article as well. —Preceding unsigned comment added by Dinesh372 (talkcontribs) 13:33, 19 November 2009 (UTC)

What is dll and why is it bad for my memory?[edit]

Does "disabling caching of dll into memory" help and why? I have too little RAM already and need it used as efficiently as possible. And how to do that?

  • When you program something, most "things" you do are prewritten. These can be on static libraries or dinamic libraries. The difference between these two is that a static library stores "inside" the .exe, while the DLL stores outside. This may give inconvenients at time of avability, but size of all programs is reduced a lot.
The size of the executable file is reduced with dynamic libraries. The memory footprint for a single process doesn't change for static vs. dynamic libraries, as in modern OS's it's all demand paged either way. The memory footprint for multiple processes can be reduced with DLLs because just one copy of code from a DLL can be used by multiple processes. With static linking all processes need their own copies of the code from the library. i.e. DLLs are good for memory, not bad. "Disabling caching of DLL into memory" is one of the many "tweaks" that are purported to speed things up and usually do the opposite. Jeh (talk) 19:30, 7 November 2009 (UTC)


With GCC on Win32, it is possible to write DLLs in the same way that shared objects are written on POSIX systems. For example, consider two files, testlib.h:

#ifndef _TESTLIB_H
#define _TESTLIB_H

extern int test_func(int a, int b);


And testlib.c:

#include "testlib.h"

int test_func(int a, int b) {
  return (a + b);

Executing GCC (MinGW) with the following options:

gcc -shared -o testlib.dll testlib.c

Will create a file called "testlib.dll". It can then be linked against any file by including the header "testlib.h" and then passing -L. -ltestlib. I don't know about dynamic loading, but this works for shared linking just fine.—Kbolino 01:55, 15 May 2007 (UTC)


Is the info about the drawback called "DLL Hell" needed here?

Programming examples[edit]

Reading this section of the article, it seems more like a tutorial on how to create DLL's rather than an explanation of what they are specifically. Isn't this generally not encouraged? --Gafaddict (talk) 17:56, 21 February 2008 (UTC)

Linking to DLL Download sites[edit]

I'd like to propose what is already effectively the rule here: no linking to web sites that list DLLs to download. I think all of these violate the WP:EL linking rules

  • As Microsoft holds the copyright to most of the DLLs, it would be encouraging downloads from unauthorized distributors
  • Anyone installing the wrong version of a library is going to make windows even less stable
  • People installing the libraries won't know about running regsvr against them to register COM objects.
  • There is a risk that the DLL download is some form of malware
  • Many (but not all) of the sites appear to be either pay-to-download or scan-your-pc business models.

We could extend this article with a "What to do if a DLL is missing" section, though that may be a magnet for more DLL download sites. SteveLoughran (talk) 12:45, 27 June 2008 (UTC)

DLLs on Symbian[edit]

The definition given for DLL in this article is "DLL, is Microsoft's implementation of the shared library concept in the Microsoft Windows and OS/2 operating systems". Well, there is at least one more operating system using DLLs that I know of: Symbian. I know a little bit about them, but I feel that adding that information to the article will result in quite a mess, as the article is heavily Window-based. Any suggestions from someone more experienced than me in editing the Wikipedia? Jmpep (talk) 03:25, 14 November 2008 (UTC)

Really? Huh... well, let's start with finding some good information, technical details, etc. on DLLs in Symbian. It might be good to create a separate article for the topic. Warren -talk- 03:42, 14 November 2008 (UTC)
Well, all the information I know about Symbian DLL can be seen at I don't know where to find other low-level details such as the file format, for example. Jmpep (talk) 21:20, 14 November 2008 (UTC)

DLL fanboys[edit]

I wrote a section called the "case against DLLs" because virtually all of the dynamic linking articles written in Wikipedia were written by DLL fanboys. The subject is NOT pat, and deserves a counterpoint, which I have written thoughtfully. I have done so before, and the result was having the section clipped out and thrown away. So here is my simple plea: are we presenting all points of view here, or do the fans of one technique or another get to suppress everyone else's viewpoint? DLLs have introduced a lot of unnecessary problems in computing and deserve at least the simple short section I have added, which contains facts and historical background not present in the rest of the article. —Preceding unsigned comment added by (talk) 22:05, 15 December 2008 (UTC)

Disputed content in Dynamic-link_library#The_case_against_DLLs[edit]

...and this is a response to the immediately preceding section here on the talk page, "DLL fanboys":

The problem here is that Wikipedia is not a platform for your point of view... or for mine. A criticism section (and it's hard to argue that this is not that, given the title) is almost inherently going to contain non-neutral point of view material. Now as I read the guidelines and policies - and I could be wrong - such material is ok, but if and only if (you knew this was coming) you find reliable sources that state that point of view, more or less explicitly. And, of course, cite them.

Better yet, since all WP articles are supposed to present a NPOV, if there is such a criticism section then there should also be an equally well referenced "in favor" section.

As WP:RS says, Wikipedia articles should cover all major and significant-minority views that have been published by reliable sources (emphasis added).

Note that taking a set of facts (no matter how well referenced) and deriving from them non-NPOV conclusions (whether positive or negative)--e.g. criticism--is not sufficient. This is considered to be synthesis, a form of original research. The sources themselves must present the point of view being advanced in the article section.

In any case, it is most definitely not the job of a WP editor to edit articles to include his or her own POV. Accordingly, if no reliable sources are provided for the opinions in this section, I will remove the unsourced material as original research within 30 days. If these opinions are really that well supported you should have no problem finding sources in that time. Of course, someone less forgiving may remove it sooner. In that case I would recommend that you keep working on the sources, and put the section and the references back in after you find them. Jeh (talk) 08:59, 23 December 2008 (UTC)

Jeh, please don't just remove the Criticism section, improve it instead! Even Microsoft use the term DLL hell, so I think it is safe to say that there are reputable sources criticising the technology. Somebody who cares more than me just needs to link to them *smiley*
I've made a start by vigorously cutting back the section, leaving a stub just summarising a few of the problems with DLLs. If the original author wants to expand on what I left, please give sources, or it will be removed again. Limeguin (talk) 08:39, 26 January 2009 (UTC)
In the existing section, every statement that's made would also apply (equally) to shared library. There's no corresponding criticism section there. Tedickey (talk) 11:53, 26 January 2009 (UTC)
So then be WP:BOLD and make one, if you can find suitable reliable sources! Content doesn't write itself. :-) Warren -talk- 12:42, 26 January 2009 (UTC)
I agree with "criticism" (in the sense of "DLL's are bad") being misplaced here, however, a separate list of "drawbacks" might improve the article while maintaining neutrality.
- Malicous code injection - replacing a DLL allows to inject malicous code into the context of all processes that load this DLL. This leads to vulnerabilities since DLLs might be loaded from a location with less strict access restrictions than the main executable, or from unexpected locations alltogether (DLL load order).
- Breaking backwards compatibility - Updating a DLL may subtley change behavior of the contained code and thus break other programs that rely on the DLL
- (Windows specific) Cooperative dependency model through which one application setup may break other applications, lack of a standard versioning mechanism, both of which I'd expect ot be discussed in depth on DLL Hell.
I'd write that up if it's agreeable, but I'm not sure what would be sufficient (or even waht would require) citation. Tedickey is right that most of this would belong to shared library, though Peter-HHH (talk) 01:39, 23 May 2013 (UTC)
I came here looking for criticism of DLLs and was disappointed. What is the main purpose of DLLs? "To reduce memory use and software bloat." It seems they fail at both of those, as well as introducing new problems. Will come back when I have found reliable sources. (talk) 04:46, 29 May 2014 (UTC)
"It seems they fail at both of those". How do you know? Have you tested equivalently functional software that didn't use DLLs? Jeh (talk) 15:01, 29 May 2014 (UTC)

"DLL" is a generic computer science term, Not Microsoft-Specific[edit]

Cosmic Engine (talk) 13:38, 20 May 2009 (UTC) DLL is not Microsoft-Specific.[1]

Your link isn't pointing to a reliable source. There might be a reliable source for the statement. Tedickey (talk) 13:43, 20 May 2009 (UTC)

Explicit run-time linking[edit]

The article says:

Note that with implicit run-time linking, referred to as load-time dynamic linking by Microsoft, if the linked DLL file cannot be found, Windows will display an error message and fail to load the application. The application developer cannot handle the absence of DLL files linked implicitly by the compile-time linker.

This needs correction. Visual C 6.0 and later allows for Delay-Loaded DLLs, whereby the application can gracefully handle a DLL that is missing at run time. Mitch Ames (talk) 2009-07-11T09:50:21

Well, correct it then. Jeh (talk) 02:33, 11 July 2009 (UTC)
Done. Mitch Ames (talk) 13:38, 11 July 2009 (UTC)

Magic Number?[edit]

Why is it claimed that the magic number of DLLs is 'MZ'? This is incorrect. Allow me to explain...

A DLL, just like a Windows executable (*.exe) is a PE format executable (PE means Portable Executable). As this article says, even OCX and other extensions are the same thing. The difference between a Windows DLL and an .exe (and all other extensions) is only *one* bit which is different in the PE header.

"The distinction between EXE and DLL files is entirely one of semantics. They both use the exact same PE format. The only difference is a single bit that indicates if the file should be treated as an EXE or as a DLL. Even the DLL file extension is artificial." - Matt Pietrek (

'MZ' is actually the ASCII character representation of the *DOS* header signature found at the very first address of a PE file. When Windows loads a PE (like a DLL), the programmer can get a hModule handle to it. This is simply a (long pointer) void* address which points to the very first address. This happens to be the DOS signature's address also (DOS magic):

typedef struct _IMAGE_DOS_HEADER {
    WORD   e_magic;     //<- Magic number 1st
//... other stuff omitted for clarity
// NOTE: All of this is found in 'winnt.h'

This value is *actually* 0x5A4D (dec. 23117). Converted to ASCII, it is 'MZ' (initials of Mark Zbikowski). But this is still NOT the magic number of the PE format executable. The DOS header is from, you guessed it, the old days of DOS. It's actually a valid DOS executable which can let the user know that Windows is needed to run the code: "This program cannot be run in DOS mode..."

So what is the PE magic number? It's actually defined as 0x00004550 (dec. 17744, and called 'IMAGE_NT_SIGNATURE'). Converted to ASCII characters, this is 'PE00'. This is always checked for when PEs are loaded, parsed, manipulated and executed. My own embedded system checks first for the DOS magic, then for the PE magic before it allows anything else to take place. Windows and other operating systems which handle PEs do the same thing, because this avoids some random hunk of memory being treated like a PE executable (which could be a disaster if it somehow worked).

So, the PE magic number actually looks like this, and is found also in 'winnt.h'

#define IMAGE_NT_SIGNATURE          0x00004550  // ASCII "PE00"

Can we have the article changed to give the correct information to readers? Also, please don't post its ASCII character representation. The magic number is hexadecimal (as usual). It just so happens it was chosen for what it stood for in ASCII, but it's just a hex number (like 0x1BADB002 for the GNU multiboot specification). It should be mentioned that it means 'PE00' in ASCII, but that's not considered the magic number. That is just a character string (or char*) which consists of the same 32 bits. —Preceding unsigned comment added by (talk) 11:43, 17 February 2010 (UTC)

.lib files - why are needed?[edit]

Why do you need anything else than .dll file (function name+function code) and .h file (function name) to use dll? I have heard that on linux you only need .so dynamic library and header file. Is this some name mangling issue? Aquickoverview (talk) 04:57, 16 March 2010 (UTC)

Some formats don't have a symbol table embedded in the file (to make loading faster). Tedickey (talk) 08:08, 16 March 2010 (UTC)
The .lib file is not required, it's (usually) just for convenience: Instead of the code required for explicit linking (declaring a function pointer, loading the DLL and getting the export, calling through pointer), you can use it like a static library (declare the actual function). The code in the .lib is minimal, it ensures loading the DLL on program startup and forwards the function calls to the DLL implementation. Peter-HHH (talk) 00:45, 23 May 2013 (UTC)

External References to Microsoft[edit]

External References to Microsoft knowledge base in the form of direct links will eventually stop working, because Microsoft frequently rearranges its website in a non-compatible manner. —Preceding unsigned comment added by (talk) 13:18, 27 December 2010 (UTC)

Using explicit run-time linking ,c(pp) exaple addendum[edit]

Suggesting to change the c/cpp example code line from

typedef double (*importFunction)(double, double);


typedef double (WINAPI *importFunction)(double, double);

As a source 'suggestion', the MS example at

shows using in that format, by putting the 'WINAPI' in the statement (but not totaly sure what it does yet).

Reason being is that while attempting to learn to use the dll's on dev-c++, I've spent over a day wondering why the static linked function worked, while dynamic linked function crashed the program (after messing the program flow, and partially working). After some time, of looking at another code, it finally worked after adding in the WINAPI word. I'm not sure what other ide's/compilers might require it, but it might be helpful to point it out, to try adding it in into all of the typedef statements. —Preceding unsigned comment added by (talk) 04:51, 28 December 2010 (UTC)

WINAPI resolves to __stdcall on x86, which declares the calling convention - i.e. how arguments and results are passed, and who cleans up the stack after the call. __stdcall is supported by most client compilers. (The problem you encountered was probably a mismatch of the implementaiton in the DLL and the declaration in the client). I'm not sure how much of this belongs into wikipedia, though. Peter-HHH (talk) 00:37, 23 May 2013 (UTC)

unverified implication?[edit]

the "Background for DLL" seems to imply that Microsoft invented the concept of device drivers. Is that true? can someone support/refute that with references? PratikMallya 23:45, 17 April 2011 (UTC)

I really don't see any such implication. Perhaps you could suggest a wording that would not imply that to you? Jeh (talk) 00:33, 18 April 2011 (UTC)
agree - it's a little wordy, but doesn't assert anything about inventing the concept. TEDickey (talk) 00:35, 18 April 2011 (UTC)

Unclear sentence in intro[edit]

What's it mean, "any data file with the same file format can be […]" — "same file format" as what, itself? --Jerome Potts (talk) 00:02, 31 March 2013 (UTC)

Same file format as "regular" DLLs. Jeh (talk) 01:46, 31 March 2013 (UTC)
I fixed the wording and found a reference for the CN. How does it look now? Jeh (talk) 05:47, 31 March 2013 (UTC)
Thank you. --Jerome Potts (talk) 04:24, 1 April 2013 (UTC)

erwer — Preceding unsigned comment added by (talk) 10:55, 23 July 2013 (UTC)

Why is __declspec(dllexport)/import necessary?[edit]

On unixoid operating systems I don't need any source code annotations. Why are they necessary on MS Windows? --RokerHRO (talk) 13:51, 17 March 2015 (UTC)

Source annotation is usually not needed if you provide a linker map file to create the library code.
The microsoft dynamic linking system is archaic and most UNIX systems use a more modern system derived from the SunOS dynamic linking system. There are e.g. issues with using data references instead of just functions that may require source annotations when using archaic implementations. Schily (talk) 14:44, 19 March 2015 (UTC)
Thanks. But why this (IMHO relevant information) is not in the article? :-) --RokerHRO (talk) 22:02, 20 March 2015 (UTC)