Talk:Component Object Model

JavaScript vs JScript

"Other libraries and languages that are cfdhvfb fdf d ctf g COM-aware include the Microsoft Foundation Classes, VBScript, Visual Basic, ECMAScript (JavaScript) and Delphi."

JScript is more technically accurate than Javascript, since COM uses Microsoft's implementation and extension of ECMAScript and not Netscape's.

COM lite

There's a "lighter" way of using COM too. According to the COM Specification (draft version 0.9 from October 1995, which doesn't seem to be available from Microsoft anymore, but you can get it from this archive.org page), COM objects don't need to be instances of COM classes or CoClasses (see chapter 3.6 of COM Specification). As long as an object supports at least one COM interface, it can be called a COM object. Its class doesn't have to be publicly available for instantiation. So COM interfaces can be used as an efficient means of communicating with any kind of applications or DLLs. It's object-oriented unlike plain vanilla DLL API functions. Many applications use COM interfaces internally. Did you know that Borland Delphi objects' interfaces are COM-compatible by default, even if you don't bother dealing with CoWhatever? COM interfaces are a simple but very powerful concept.

Visual Basic does this too; it implements IDispatch-based interfaces for all your objects, even those that you don't export. Perhaps VB uses a private, internal ClassFactory for these, but it probably doesn't. Shinobu 04:26, 27 June 2007 (UTC)

---

It's all well and good redirecting from OCX to COM, but nowhere in this article does it tell me what an OCX file actually is? A DLL that implements some interfaces?

An OCX control, or OLE custom control is essentially a coclass implementing the intefaces necessary to enable applications that can embed controls via those interfaces, to embed objects of this class as a visible, interactive control. Usually their implementation is housed in a dynamic link library with the .ocx extension. Shinobu 04:26, 27 June 2007 (UTC)

---

Where are the lists of standard COM libraries so that you can actually use them for developement?

I've been looking at writing HTA (HTML Applications). These are basically applications made by running a scripted web page locally completely outside of the security sandbox.

It's a cool way to program because, as PHP programmers have found, there's no easier way to generate a user interface than to spit out HTML. And DHTML is a cool way to script a user interface.

But since JavaScript doesn't have libraries for system access, you need to link to COM libraries at run time for every nonweb like thing you want to do.

This should be easy, since Microsoft has supplied COM libraries for everything, and always has.

But just try to find documentation of WHAT COM Libraries exist, what the interfaces to them are, what versions shipped with which version of Windows. THERE'S NO DOCUMENTATION!

Add to that the fact that COM objects don't have reflection and you have a nutty situation.

It's like being a plumber, except that you can only order pipe fittings by number, and you're not allowed to see the catalog. Oh and the catalog numbers are 64 bits long. -- wrong: actually they're 128 bits

Can anyone help me out here?

CafeAlpha@nightstudies.net

Perhaps you can install the Platform SDK? It's a heavy download, but it contains all you ever wanted to know about Windows programming. Shinobu 04:18, 27 June 2007 (UTC)

---

It's really a bit inaccurate to say that .NET is a replacement of COM. Not only does .NET do a lot more than COM, COM+ is still very much alive and well, and Microsoft are still encouraging its use in enterprise applications. Writing COM+ objects in .NET is a common way to do it, so the two technologies are more complementary than competing. ShaneKing 12:42, 3 Feb 2004 (UTC)

So edit the article :-) We need severe technical info here - David Gerard 00:09, Feb 4, 2004 (UTC)

---

can someone write a dumbed down section? the first paragraph reads like an alien language.

I've added "In software engineering" to the intro, so you know after three words that it is in fact an alien language ;-) I couldn't see how else to simplify the explanation in the intro. It really is a bit esoteric for the non-geek, but I hope the "In software engineering" up front is adequate warning - David Gerard 11:21, 2 Oct 2004 (UTC)

ActiveX

I'm unsure whether ActiveX is a synonym of COM. Isn't it -- like DirectX -- based on COM? --GatesPlusPlus 11:26, 6 Feb 2005 (UTC)

Yup, ActiveX is just another technology using COM, right? What redirect it here? --minghong 08:37, 13 May 2005 (UTC)

Has since been fixed. Shinobu 08:51, 2 July 2007 (UTC)

More malicious uses of ActiveX over legitimate uses?

I read or heard somewhere that there are more bad uses of ActiveX rather than legitimate uses. Is this true? -x42bn6 8 July 2005 04:15 (UTC)

No. ActiveX is the same as Automation. It's a software componentry system that is used extensively by your system, and by a lot of software people use daily. ActiveX is just a specification of how software components interact with each other. This is not intrinsically good or bad. However, what is bad, is letting untrusted native software loose on your computer. So if your browser asks you to install an ActiveX control, or Firefox plugin, decline. What can be done in webpages using ActiveX controls and Firefox plugins can usually be done with Java applets, and these can be properly sandboxed, making them (barring bugs in the Java VM) completely safe. So if a website owner decided to use an ActiveX control or Firefox plugin instead, you have a very good reason to be very suspicious indeed. Only install ActiveX controls, Firefox plugins, or any software for that matter, if you fully trust the source. Shinobu 04:15, 27 June 2007 (UTC)

ActiveX text

The text looks like its taken directly from MS:

---

What is Active-X

What is ActiveX?

ActiveX is a set of technologies from Microsoft that enables interactive content for the World Wide Web. Before ActiveX, Web content was static, 2-dimensional text and graphics. With ActiveX, Web sites come alive using multimedia effects, interactive objects, and sophisticated applications that create a user experience comparable to that of high-quality CD-ROM titles. ActiveX provides the glue that ties together a wide assortment of technology building blocks to enable these "active" Web sites. What Are Its Primary Benefits?

   * Active Web Content with Impact that will attract and retain users.
   * Open, Cross-Platform Support on Macintosh®, Windows® and UNIX® operating systems.
   * Familiar Tools from a wide assortment of tools and programming language vendors, including Visual Basic®, Visual C++®, Borland® Delphi®, Borland C++, Java, and Java-enabled tools. Developers can use what they know and be productive immediately.
   * Existing Inventory of ActiveX controls available today for immediate use by Web producers.
   * Industry Standards, with built-in support for key industry and de-facto marketplace standards, including HTML, TCP/IP, Java, COM, and others.

What Are Its Elements?

ActiveX includes both client and server technologies.

   * ActiveX Controls are the interactive objects in a Web page that provide interactive and (UTC)user-controllable functions and hence enliven the experience of a Web site.
   * ActiveX Documents enable users to view non-HTML documents, such as Microsoft Excel or Word files, through a Web browser.
   * Active Scripting controls the integrated behavior of several ActiveX controls and/or Java Applets from the browser or server.
   * Java™ Virtual Machine is the code that enables any ActiveX-supported browser such as Internet Explorer 3.0 to run Java applets and to integrate Java applets with ActiveX controls.
   * ActiveX Server Framework provides a number of Web server-based functions such as security, database access, and others.

What Can It Do?

ActiveX brings innovation and interactivity to the Web. Because it is supported by many different languages and tools, it enables developers with varied backgrounds and expertise to bring their creativity to the Web. Based on a refinement of the existing COM standard already known by thousands of developers, it can leverage the knowledge and work of the development community without a steep learning curve. And because it is a third-generation technology with extensive third-party support, it provides the richest development platform for both Internet and intranet Client/Server applications available today. ActiveX takes the most creative and innovative software development efforts and enables them to work together seamlessly in a Web site. With thousands of these software components already existing, an exciting collection of interactive objects is available for immediate use by Web producers. Why Is It Important?

ActiveX makes it fast and easy for developers and Web producers to create unique, interactive Web sites that will make the Internet fundamentally more useful and productive. Web producers don't have to start from scratch and build all the parts of their interactive Web site by hand, because there are already more than 1,000 reusable controls available in the market. And because ActiveX can be used with a wide variety of programming languages from dozens of vendors, developers and Webmasters can make use of their current expertise to more quickly create compelling content. They can also accommodate a wide range of users, as ActiveX will be supported on multiple operating system platforms. How Does It Compare with Java?

ActiveX provides a standard mechanism to extend any programming language, including Java. ActiveX extends the capabilities of the Java language by allowing Java developers to integrate their applets with the richness of ActiveX. ActiveX ties Java applets together with objects created in other languages, so that Java programmers can link to ActiveX controls directly from their Java programs. By the same token, objects written in other programming languages from multiple vendors can link to Java applets. ActiveX is the glue that ties them all together, delivering the most powerful Web technologies in an open, integrated platform. By providing a common way to extend and link programming languages including Java, ActiveX maximizes developers' resources for interactive Web development. See ActiveX and Java for more information on extending Java with ActiveX. Who Supports It?

Small, medium and large software companies currently create ActiveX controls, including companies such as Borland, Oracle and Sybase/Powersoft. As a result of their work, there are more than 1,000 existing ActiveX controls available for use today by Web producers. In addition, 14 companies who create Web design and development tools have built ActiveX support into their products, allowing their customers to both create and make use of ActiveX controls in their programs. Microsoft's Internet Explorer supports ActiveX, and Microsoft provides the ActiveX plug-in for Netscape® Navigator®, enabling the broadest range of Internet users to view ActiveX-enabled Web pages. Where Does It Run?

ActiveX is currently supported on the Windows operating system. Microsoft is working with Metrowerks to support ActiveX on the Macintosh platform, and is also working with Bristol and Mainsoft to support it on UNIX platforms. Developers who write ActiveX controls and other ActiveX objects will be able to reach the widest possible user audience with this cross-platform solution.

---

so it is probably a copyvio and would need to be reworked... --RN 07:30, 30 July 2005 (UTC)

DLL Hell

Because the location of each component is stored in a system-wide location (the Windows registry), there can be only one version of a certain component installed. Thus, COM seriously suffers from DLL hell, where two or more applications require different versions of the same component. Wrong. That is decision of component developer if he wants to register new component version under old version name, and it is wrong decision if components are not compatible.

The point is "COM makes wrong decisions more destructive by requiring system-wide registry of registered components"

The point is nothing like "COM is defective and cannot be used to make solid solutions". --tyomitch 09:20, 14 November 2005 (UTC)

F.e. typicall windows installation have MS XML 2.0, 3.0 and 4.0 installed and working together just fine. Also COM have "Component Categories" http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnesscom/html/componentcategories.asp feature which allows to not hardcode used component names in application.

Additionally, since COM uses the registry intensively, it is sensitive to registry corruption. And most of the software are sensitive to file system corruption. What the point?

I don't know. Go ahead and fix it if you like. --tyomitch 09:20, 14 November 2005 (UTC)

There is no DLL hell in COM, since interfaces and coclasses are referred to using their GUIDs, not names, and the DLLs themselves can be located anywhere in the system. Thus, at the very least, the claim made by the article that "because the location of each component is stored in a system-wide location (the Windows registry), there can be only one version of a certain component installed" is outright wrong - and it is the only claim that is made in the "DLL hell" section, which is why I removed it altogether. Yet it was promptly inserted back. Care to explain what "DLL hell" with regard to COM mean, then? -- int19h 07:35, 30 April 2007 (UTC)

Easy - if you have OOActiveXControl v2 installed on your system, then you install OldApp 2001 and it registers OOActiveXControl v1, applications that depend on interfaces and classes in OOActiveXControl DLL v2 will break when they can't find them. There's also the case of poorly written components that change behaviour between versions without incrementing interface names, etc. You can't say that it is immune to DLL hell, but you could probably reword a lot of the text in there to make it clearer instead. MatthewMastracci 22:22, 30 April 2007 (UTC)

The breakage will only occure if you overwrite the OOActiveXControl.2 DLL with OOActiveXControl.1 DLL. This may happen when installing components into SYSTEM32 folder, but it is widely recognized to be bad practice, and COM certainly does not enforce it - the application could just as well put the DLL into its own folder and register it from there. As for poorly written components that change behaviour for existing interfaces - well, they aren't strictly COM-compliant, since COM reference guide specifically says this is forbidden. It's not in any way unique to COM, either - the same problem exists in Java/.NET land; so I don't think that the name "DLL hell" is in any way applicable here. -- int19h 07:28, 1 May 2007 (UTC)

Your points are fair enough, but take a look at the DLL hell page:

DLL hell as described above was a very common phenomenon on pre-Windows 2000 versions of Microsoft operating systems, the primary cause being that the operating system did not restrict DLL installations. Application installers were expected to be good citizens and verify DLL version information before overwriting the existing system DLLs. Standard tools to simplify application deployment (which always involves shipping the dependent operating system DLLs) were provided by Microsoft and other 3rd party tools vendors. Microsoft even required application vendors to use a standard installer and have their installation program certified to work correctly, before being granted use of the Microsoft logo. The good citizen installer approach did not mitigate the problem, as the rise in popularity of the Internet provided more opportunities to obtain non-conforming applications.

If people can improperly register or write shared components, this leads to DLL hell. It doesn't really matter if it violates COM specs - if it can happen with the dumbest of users and/or programmers, it can happen. We can't really take out the section on DLL hell, but you can put in mitigating factors like COM spec violation, SxS DLLs, local registration, etc.. MatthewMastracci 21:15, 2 May 2007 (UTC)

But, if a spec is designed with the specific intention to end DLL hell, and if it capably provides the means for programmers to do so, then it is misleading to view the spec as a CONTRIBUTOR to this problem. The fact that programmers face difficulties conforming to the specifications (and recognized "best practices") is immaterial. If people always carefully followed the spec (and installer/registration guidelines), there wouldn't be DLL Hell. Given the myriad scenarios, this is nearly impossible (hence, DLL hell) but one might at least mention that it provides a PATH toward this end, where raw DLLs did/do not. — Preceding unsigned comment added by Powermonger666 (talk • contribs) 13:14, 21 January 2011 (UTC)

Pretty much. All of the claims pertaining to "DLL Hell" in COM are false. I suspect that this was introduced by someone who saw that COM components are packaged up in DLLs and then went: "Oh my gosh; it must have the same DLL hell". As no substantiated claims have been made to support the "DLL hell" criticism (note: Not implying that there was never such a thing on the Windows 9x line with regular DLLs) this criticism seems unfounded. As it is potentially harmfull it is now removed. Useerup (talk) 06:23, 23 March 2011 (UTC)

Not all are false, the description of registration-free COM is true. Also it does not matter if it is potentially harmful, what matter is whether is it true.--Alvin-cs ✉ 19:41, 29 March 2011 (UTC)

DLL hell effect happens even if someone upgrades library.dll V1 to V2 if some client depends on (possibly undocumented) behavior of the old version. COM (with registration) does not make it easier. Some situations can be solved by always creating a new interface, however sometimes author of component needs to innocently e.g. fix a bug and does not know that some client will break. Registrations-free COM solves that by isolating such breakage to the application which upgraded its DLLs.--Alvin-cs ✉ 19:41, 29 March 2011 (UTC)

Where's the laymen's version of this article?

This article may be great for what it is, (or not, I don't have the expertise to say), but isn't an encyclopedia suposed to explain things to people who don't already understand the subject matter?

I am a programmer of sorts, mostly a self-trained hack, but fairly skilled. But I come from the unix world mostly. I sure wish there were a wikipedia article that would explain some of microsoft's alphabet soup of technologies to people who don't already know most of it. I can click links all day in these wikipedia articles, from COM to OLE to WinFX to .NET, but they all seem to link back to each other and none of them explain it to non wondows-experts.

--Headybrew 11:05, 29 May 2006 (UTC)

Hm. I think the opening sentence already describes what COM does / what it's for, and if you want technical or historical details, you can read those sections. Is there any specific part of the article that is hard to understand? Shinobu 03:53, 27 June 2007 (UTC)

The opening paragraph is ridiculously obtuse, with unnecessarily technical language used instead of providing a basic introduction to the article and allowing more detailed description in the body of the article 90.195.27.222 (talk) 00:41, 2 February 2010 (UTC)

.NET performance

"Also, a COM component should theoretically always have better performance than a matching managed .NET component."

Is this actually true? In theory .NET is faster, since it doesn't require every function call to be virtual, and doesn't need to constantly AddRef/Release object references.

It does the same and 10 times more, it's just hidden from the programmer. How the hell do you think it manages reference counting, if not with functions similar to AddRef/Release?

Pretty simple, it doesn't use reference counting at all, but a tracing, compacting, generational garbage collector. -- int19h 18:45, 25 May 2007 (UTC)

Cleanup

This article needs some cleanup, especially the History section, which tends to repeat itself quite a bit. Also, I deleted the line "Also, a COM component should theoretically always have better performance than a matching managed .NET component" because it's a controversial and unsubstantiated claim. Depending on who you talk to, some people will say that JIT compiled langauges should theoretically be faster than natively compiled languages because the JIT language has the oportunity for machine-specific optimizations. Without any citation, it's just noise and doesn't really add anything to the article.12.34.246.4 22:25, 30 November 2006 (UTC)

COM Obsolete?

COM has a sordid history. It has left a trail of technology that will be with us for years to come. It all started when it was decided that it would be a good idea were it possible, for example, to embed a spreadsheet inside a word processor document such that updates to the spreadsheet would automatically update the document. At the same time, software componentry as a solution to the code reuse problem was very promising. Programmers were expected to master incantations of environment, instantiation, interface probing, graceful degradation of function in the event the latest object version is unavailable, reference counting, and so on and so forth. After all those things are done, there is still the minor detail of slaying the dragon the program one is trying develop is supposed to slay. What is missing from COM is ease of reflection that allows a programmer to make runtime decisions based on what is on offer in a COM library. That is what the .NET Framework excels at and why COM is the past and the .NET Framework the present and future.--151.200.244.58 18:38, 2 December 2006 (UTC)

COM isn't "the past". Everything that guy discussed is true (except for "reflection" as noted below), but he assumes a runtime. Everything is easier with a runtime. Without a runtime, one is forced to tackle the problems listed above, and that is MOSTLY what "COM" is -- a way of tackling these problems for machine-compiled components. It is still used widely (e.g. DirectX). — Preceding unsigned comment added by Powermonger666 (talk • contribs)

COM has a support of something similar to what we call "Reflection" in .NET. Its called TypeLibraries. COM from the begining supported this concept of enquiring the "type" of a object, provided the object supported ITypeLib/ITypeInfo interfaces. Also COM supports the popular IDispatch to implement Automation in components which make them accessable in scripting languages. 72.78.10.98 10:03, 13 March 2007 (UTC)Vijay Ravi

Apprently the .NET CLR is a DCOM object, refering to Windows Internals fifth edition, so how come .Net depreciate COM? So COM is not .Net doesn't replace COM it is a wrapper for COM .. —Preceding unsigned comment added by Bibo1978 (talk • contribs) 13:27, 31 May 2010 (UTC)

In the ".NET" section, it says "Several of the services that COM+ provides have been largely replaced by recent releases of .NET. For example, the System.Transactions namespace in .NET provides the TransactionScope class, which provides transaction management without resorting to COM+." but that's not the case. System.Transsactions is the .NET way of using COM+ Enterprise Services. — Preceding unsigned comment added by Powermonger666 (talk • contribs) 18:33, 21 January 2011 (UTC)

Object diagrams

When visualizing COM objects, one often draws cute little diagrams like:

   ______________________
  |      ____________    |
  |     |            |   |
O-+-----| InterfaceA |   |
  |     |____________|   |
  |    ________________  |
  |   |  ____________  | |
  |   | |            | | |
  | O-+-| InterfaceB | | |
  |   | |____________| | |
  |   |  ____________  | |
  |   | |            | | |
O-+---+-| InterfaceC | | |
  |   | |____________| | |
  |   |________________| |
  |______________________|

Since these are so commonly used, wouldn't it make some sense to have an example in the article? Not as horrible ASCII art of course, but as SVG? Shinobu 03:47, 27 June 2007 (UTC)

Note: you also often see things like this, e.g. in Microsoft's documentation

                     O
               ______|_
              |        |
InterfaceA O--|        |
              |        |
InterfaceC O--|        |
              |________|

The top circle represents IUnknown. Shinobu 07:56, 4 July 2007 (UTC)

Separate category for COM

Looking at the number of Wikipedia articles that can be categorized under COM, how about creating a "Component Object Model" category like .NET has? —Preceding unsigned comment added by Xpclient (talk • contribs) 09:51, 4 February 2008 (UTC)

Not a bad idea. Just add [[Category:Component Object Model]] to relevant pages and write a blurb for the category page. I'd do it myself, but I'm going down for maintenance. Shinobu (talk) 04:46, 6 September 2008 (UTC)

Historical information is highly misleading

This article completely ignores the DCE RPC layer that COM evolved from. In particular, ignoring that omits the fact that major parts of the COM history are non-microsoft. —Preceding unsigned comment added by 202.160.48.164 (talk) 20:21, 18 December 2008 (UTC)

DCOM is based on DCE RPC (and that should certainly be mentioned) but COM is not. —Preceding unsigned comment added by 86.178.56.128 (talk) 21:19, 9 March 2010 (UTC)

Reference needed on every paragraph?

Does there really need to be a citation for every single paragraph? Does anyone think we should remove most of those links?

COM+

I really wish the blurb on COM+ were more thorough and detailed. I just started work at a company with an enterprise app that leans on COM+ heavily, and I had hoped to come away with a better understanding of how it works and why one would want to use it.

Chrisfeohpatti (talk) 16:03, 30 March 2009 (UTC)

Then you'd better ask the app's developers. That's be faster than crawling all the way on your own. — Vano 08:53, 21 November 2009 (UTC)

COM deprecation in favor of .NET

Although remoting/marshalling is a common problem both .NET and COM address, I don't see how COM is deprecated in favor of .NET. .NET is by no means an alternative to COM for native development, even after C++/CLI is introduced (due to the dependency on .NET Fx). —Preceding unsigned comment added by 41.235.169.14 (talk) 23:11, 17 July 2009 (UTC)

COM Application binary interface

Is that specification available anywhere? Looks like everyone knows the details (since they write COM-compatible compilers/libraries) but no one says a thing! How disgusting... — Vano 10:30, 27 January 2010 (UTC)

Instantiation

This section starts "COM standardizes the instantiation (i.e. creation) process of COM objects by requiring the use of Class Factories". Class Factories are absolutely NOT required for object creation.

Example 1: Many system COM objects are created with an API call (e.g. CoGetMalloc).

Example 2: In a Document Object Model implemented in COM the root object may well have a factory, but other objects are created using methods on the root. —Preceding unsigned comment added by 86.178.56.128 (talk) 21:32, 9 March 2010 (UTC)

COM from other vendors.

In 1995, Bristol Technology, Inc. developed OLE1 technology for use in UNIX platforms. However, when MS released OLE2, Microsoft raised the fees to a level that it became unaffordable for BT to continue developing OLE2. See related article at http://www.techlawjournal.com/courts/bristol/Default.htm Wheger (talk) 20:27, 18 March 2010 (UTC)wheger

COM and DCOM

I've always wondered how some objects are valid DCOM objects (for example objects created by VB6), and some objects can only be used by local COM (for example, all of MS Office). If you could DCOM to DAO (a MS database object), you could set up a DAO Network Database Server: You can't do that because of some difference in the object. But nothing here or at DCOM to explain how the interface differs.122.107.141.71 (talk) 23:52, 11 October 2010 (UTC)

apartment types

Not adding these directly to the article, because I don't have secondary sources.

• Microsoft abbreviates the neutral apartment as NA, not NTA.
• For STA, this is not correct: "Thus, the COM run-time provides automatic synchronization to ensure that each method call of an object is always executed to completion before another is invoked." If the method in the STA calls into another apartment (except NA), then another method can be run in the STA while the first method is waiting, so the methods need to prepare for this kind of reentrancy.
• In Windows 8, there is also Application Single-Threaded Apartment (ASTA). App threading and DirectX

85.131.104.149 (talk) 06:59, 25 June 2013 (UTC)

bittness (32 bit, 16 bit, 64 bit)

Came looking for a description of the difference between 32 bit COM and 64 bit COM, (and if COM+ thunking is possible) — Preceding unsigned comment added by 203.206.162.148 (talk) 05:47, 24 March 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Component Object Model. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090215185257/http://innovatia.com/software/papers/com.htm to http://www.innovatia.com/software/papers/com.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:23, 11 August 2017 (UTC)