Hubbry Logo
Plug-in (computing)Plug-in (computing)Main
Open search
Plug-in (computing)
Community hub
Plug-in (computing)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Plug-in (computing)
Plug-in (computing)
Plug-in (computing)
View on Wikipedia
from Wikipedia
Mozilla Firefox displaying a list of installed plug-ins
Look up plug-in or add-on in Wiktionary, the free dictionary.

In computing, a plug-in (also spelled plugin) or add-in (also addin, add-on, or addon) is a software component that extends the functionality of an existing software system without requiring the system to be re-built. A plug-in feature is one way that a system can be customizable.[1]

Applications support plug-ins for a variety of reasons including:

Examples

[edit]

Examples of plug-in use for various categories of applications:

Mechanism

[edit]
Example Plug-In Framework

The host application provides services which the plug-in can use, including a way for plug-ins to register themselves with the host application and a protocol for the exchange of data with plug-ins. Plug-ins depend on the services provided by the host application and do not usually work by themselves. Conversely, the host application operates independently of the plug-ins, making it possible for end-users to add and update plug-ins dynamically without needing to make changes to the host application.[10][11]

Programmers typically implement plug-ins as shared libraries, which get dynamically loaded at run time. HyperCard supported a similar facility, but more commonly included the plug-in code in the HyperCard documents (called stacks) themselves. Thus the HyperCard stack became a self-contained application in its own right, distributable as a single entity that end-users could run without the need for additional installation-steps. Programs may also implement plug-ins by loading a directory of simple script files written in a scripting language like Python or Lua.

Helper application

[edit]

In the context of a web browser, a helper application is a separate program—like IrfanView or Adobe Reader—that extends the functionality of a browser.[12][13] A helper application extends the functionality an application but unlike the typical plug-in that is loaded into the host application's address space, a helper application is a separate application. With a separate address space, the extension cannot crash the host application as is possible if they share an address space.[14]

History

[edit]

In the mid-1970s, the EDT text editor ran on the Unisys VS/9 operating system for the UNIVAC Series 90 mainframe computer. It allowed a program to be run from the editor, which can access the in-memory edit buffer.[15] The plug-in executable could call the editor to inspect and change the text. The University of Waterloo Fortran compiler used this to allow interactive compilation of Fortran programs.

Early personal computer software with plug-in capability included HyperCard and QuarkXPress on the Apple Macintosh, both released in 1987. In 1988, Silicon Beach Software included plug-in capability in Digital Darkroom and SuperPaint.

See also

[edit]
  • Add-on (Mozilla) – Software modules to extend Firefox web browsers
  • Applet – Small software application
  • Browser extension – Program that extends the functionality of a web browser
  • Theme – Preset package containing graphical appearance and functionality details

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Plug-in (computing)

View on Grokipedia
from Grokipedia
In computing, a plug-in (also spelled plugin or add-on) is a modular software component that extends the functionality of an existing application or host program without modifying its core codebase. These components integrate through standardized interfaces, such as application programming interfaces (APIs), to add specific features like media playback, data processing, or user interface enhancements. By design, plug-ins operate dependently on the host software, enabling customization and extensibility while maintaining the original program's integrity. The origins of plug-ins trace back to the early 1970s, when introduced the concept in its Time Sharing Option (TSO) system for mainframe computing. Practical implementations emerged in the late with early software, including text editors like and publishing tools such as on Apple Macintosh systems. The term "plug-in" was coined in the by Software for add-ons to their graphics programs, like Digital Darkroom. Plug-ins proliferated in the 1990s alongside the growth of the and web browsers, allowing dynamic content delivery and marking a shift toward modular software architectures. Plug-ins encompass diverse types tailored to specific computing environments, including browser plug-ins for web enhancements (e.g., ad blockers or password managers), content management system (CMS) plug-ins for customization (e.g., in , where over 60,000 are available), and audio/video editing plug-ins for media manipulation in tools like Adobe Premiere. Other categories include (IDE) plug-ins for coding aids, plug-ins for threat detection, and e-commerce plug-ins for online store features. Historical examples like (deprecated in 2020) and enabled multimedia in browsers, while modern ones like integrations boost performance tracking. Despite their benefits in improving efficiency and , plug-ins can introduce vulnerabilities, such as risks from outdated or poorly coded modules, necessitating regular updates from reputable sources.

Fundamentals

Definition

A plug-in, also known as a plugin or add-on, is a software component that extends the functionality of an existing application or system by adding specific features, typically loaded dynamically at runtime without requiring modifications to the host program's core . This design allows the host application to remain unchanged while incorporating new capabilities through well-defined interfaces, such as APIs or extension points. Plug-ins are commonly implemented as separate modules, often in the form of dynamic link libraries (DLLs) or shared objects, enabling seamless integration and removal. The primary goals of plug-ins include promoting modularity, which breaks down complex applications into independent, reusable parts; extensibility, allowing the host to support ongoing enhancements via additional components; and interoperability, ensuring compatibility across different systems through standardized protocols. Unlike built-in features that are hardcoded into the application during development, plug-ins are optional and frequently developed by third parties, providing flexibility for users to customize functionality without altering the original software. This distinction supports a ecosystem where developers can contribute specialized extensions, such as media playback or data processing tools, to broaden the application's utility. In computing, the term plug-in primarily refers to user-space extensions for end-user applications, such as web browsers, text editors, or multimedia software, rather than low-level system components like kernel modules or hardware drivers. These extensions operate within the application's runtime environment, focusing on enhancing user-facing features while maintaining isolation from core system operations. For instance, plug-ins enable browsers to handle diverse content types beyond native support.

Key Characteristics

Plug-ins in computing are characterized by their modularity, functioning as self-contained units that encapsulate specific functionality with well-defined interfaces, enabling independent development, testing, and updates without altering the core host application. This design principle promotes and reduces between components, allowing developers to build and maintain extensions in isolation. A core trait is , where plug-ins can be installed, enabled, or disabled at runtime without requiring a restart of the host application, often leveraging just-in-time integration mechanisms such as runtime discovery catalogs. This capability supports on-demand loading of components, enhancing resource efficiency and enabling seamless extensibility during operation. Interoperability is achieved through standardized protocols, APIs, or hooks that facilitate communication between the plug-in and the host, such as the historical Plugin Application Programming Interface (), which provided a cross-browser mechanism for embedding and interacting with native content. These interfaces ensure portability and consistent behavior across environments, typically relying on contract-based exports and imports defined via metadata or attributes. The advantages of this include enhanced flexibility for rapid feature addition, fostering growth through third-party contributions, and simplifying by isolating updates to individual modules. However, inherent traits like potential stability risks arise from third-party integration, which can introduce compatibility issues or runtime errors if contracts mismatch.

Examples and Use Cases

Web Browser Plug-ins

Web browser plug-ins are software components that extend the functionality of web browsers by enabling the rendering and interaction with content not natively supported by the browser's engine, such as multimedia formats and interactive applications. These plug-ins primarily handle non- elements, including animations, video playback, and dynamic content execution, allowing early web developers to create rich internet experiences beyond basic text and images. For instance, they facilitated the delivery of complex animations and interactive elements that standard could not achieve at the time. Notable examples include , which supported vector-based animations, video, and audio streaming within web pages. enabled real-time streaming of audio and video content, popular in the late 1990s and early 2000s for media delivery. provided a framework for rich media applications, including video playback and interactive features, as a competitor to Flash. applets allowed the embedding of platform-independent interactive applications, such as simulations and games, directly in browsers. However, these technologies faced deprecation trends starting in the due to persistent security vulnerabilities and the maturation of native web standards. reached end-of-life on December 31, 2020, with content blocked from January 12, 2021. support ended on October 12, 2021. deprecated the Java browser plug-in in JDK 9 (2017), with full removal planned for later versions. 's browser plug-in similarly faded as streaming shifted to HTML5-based solutions. Integration of web browser plug-ins occurs through HTML elements like <object> and <embed>, which specify the plug-in to invoke and the content to load. The <object> element, for example, uses attributes such as type to declare the type (e.g., application/x-shockwave-flash for Flash) and data for the resource , often paired with <param> tags for configuration.

html

<object data="example.swf" type="application/x-shockwave-flash" width="300" height="150"> <param name="movie" value="example.swf"> </object>

<object data="example.swf" type="application/x-shockwave-flash" width="300" height="150"> <param name="movie" value="example.swf"> </object>

The <embed> tag serves a similar purpose but is less standardized, embedding external content directly. For security, plug-ins typically operate in a sandboxed environment to limit access to system resources, though NPAPI-based implementations often ran with elevated privileges, exposing browsers to risks like code execution exploits. These plug-ins significantly impacted by enabling early rich internet applications, such as and cross-platform , but their history of and performance issues— including frequent vulnerabilities in Flash and —prompted a shift to alternatives like <video>, <canvas>, and for native multimedia support without external dependencies. Major browsers, including , dropped NPAPI support except for Flash in version 52 (March 2017), accelerating the transition.

Software Application Plug-ins

Software application plug-ins extend the capabilities of standalone desktop programs, particularly in and creative domains, by integrating additional features without altering the core application. These plug-ins allow users to customize workflows, support new file formats, and automate repetitive tasks, enhancing efficiency in professional environments. Unlike browser extensions, they are designed for persistent integration within host applications, enabling deeper functionality such as real-time processing or specialized toolsets. In image editors like , plug-ins commonly add filters and effects for image manipulation, such as or generative AI tools, which streamline creative processes for photographers and designers. For instance, third-party plug-ins can introduce advanced support or custom UI elements, allowing users to apply complex transformations directly within the editing interface. Similarly, integrated development environments (IDEs) like rely on plug-ins for language-specific support, including , , and code analysis for languages such as , C/C++, and Python, which facilitate development. Media players, exemplified by VLC, use plug-ins to expand compatibility, enabling playback of formats like HEVC/H.265 through libraries such as libde265, ensuring seamless handling of diverse files across user libraries. Plug-ins provide targeted functionality, such as adding format support for media, executing scripts for batch operations, or customizing user interfaces to match specific workflows. A notable example is the Batch Image Manipulation Plugin (BIMP) for , an open-source image editor, which applies multiple manipulations—like resizing, , and format conversion—to groups of images in a single process, saving time for bulk editing tasks in . These additions often integrate via standardized APIs, allowing developers to build tools that interact with the host application's data structures without requiring recompilation of the main software. The ecosystem for software application plug-ins typically involves distribution through dedicated repositories or app stores, where developers upload versions aligned with the host application's updates to ensure compatibility. For Adobe applications, plug-ins are managed via the Creative Cloud desktop app's , enabling easy installation and updates for tools integrated with Photoshop or . Eclipse plug-ins are hosted on the Eclipse , a central repository that supports discovery, installation, and versioning guidelines to maintain stability across IDE releases. VLC's add-ons are available through the official addons site, with plugins like extensions versioned to match player updates for consistent performance. GIMP plug-ins, including batch tools, are distributed via the GIMP Registry, a community-driven that facilitates and compatibility checks with the editor's versions. This structured distribution promotes widespread adoption while mitigating conflicts from mismatched updates. In professional software, plug-ins emphasize performance optimization to handle resource-intensive tasks efficiently, such as accelerating image rendering in Photoshop through optimized algorithms or reducing latency in Eclipse's code indexing via lightweight integrations. Cross-platform compatibility is a key focus, with frameworks like Eclipse's architecture ensuring plug-ins function uniformly on Windows, macOS, and , while VLC's allows codec plug-ins to leverage native libraries across operating systems for uninterrupted playback. These aspects are critical for enterprise users, where reliability and portability directly impact productivity in diverse computing environments.

Technical Mechanism

Architecture

The architecture of a plug-in in computing revolves around a modular structure that allows third-party code to integrate seamlessly with a host application without altering its core codebase. At its foundation, the host application exposes a set of application programming interfaces (APIs) and hooks—predefined points where extensions can attach functionality—enabling plug-ins to interact with the host's services, data, and events. Plug-ins, in turn, consist of essential components such as entry points (functions or methods that the host invokes to initialize or access the plug-in), data structures for storing configuration or state, and callback functions that allow the plug-in to respond to host events or requests. This separation ensures that plug-ins operate as self-contained units, promoting reusability and maintainability across different host environments. Interface standards form the contractual backbone of plug-in integration, defining how components communicate through well-specified protocols. In Windows environments, the (COM) serves as a prominent example, providing a binary-standardized, object-oriented framework where plug-ins are implemented as COM objects exposing interfaces—collections of methods accessible via interface pointers—for querying, activation, and data exchange. COM ensures location transparency, allowing plug-ins to run in-process or out-of-process while adhering to a platform-independent contract that supports languages like C++ and supports distributed interactions. In macOS, traditional plug-ins can be bundled as loadable code modules using the Core Foundation framework (CFPlugIn), which employs universally unique identifiers (UUIDs) to match plug-ins to host requirements, along with C-based entry points. However, modern macOS extensibility typically uses App Extensions, which are separate, isolated bundles that provide functionality to the system or other apps without loading code directly into the host process, managed by the PlugInKit framework for security and compatibility. These standards enforce and versioning, preventing mismatches that could destabilize the host. Design patterns further refine plug-in architectures to handle instantiation, communication, and efficiently. The factory pattern is commonly employed for dynamic instantiation, where the host uses a centralized factory mechanism—such as COM's CoCreateInstance or a configuration-driven plugin loader—to create plug-in instances based on runtime specifications, avoiding hardcoded dependencies and enabling plug-and-play extensibility. Event-driven communication patterns facilitate asynchronous interactions, with the host broadcasting events (e.g., user actions or data changes) that plug-ins subscribe to via callbacks or observers, decoupling components and allowing multiple plug-ins to respond without . patterns address potential conflicts by isolating plug-in resources, such as using namespaces for memory allocation or thread pools to prevent interference, ensuring the host remains stable even with concurrent plug-ins. These patterns, as outlined in established practices, emphasize configuration-time binding over compile-time, enhancing modularity. Security architecture is integral to mitigate risks from untrusted plug-ins, which could exploit vulnerabilities to access sensitive data or system resources. Sandboxing isolates plug-ins by executing them in restricted environments, such as separate processes or virtualized spaces, limiting their access to the host's full capabilities and containing potential exploits. Permission models enforce granular access controls, requiring explicit declarations of required privileges (e.g., read/write to specific APIs or storage) that users must approve, often with tiered levels like read-only or full access, as seen in web browser extensions where manifests specify permissions that trigger user warnings for high-risk operations. Isolation techniques, including address space separation and , further prevent unauthorized interactions, with hosts like add-ins running in a dedicated runtime that enforces performance limits and audits access to ensure integrity in distributed or multi-tenant scenarios.

Loading Process

The loading process of plug-ins in computing begins with the discovery phase, where the host application scans predefined directories, registries, or configuration files to identify available plug-in modules. This typically involves examining file extensions such as .DLL on Windows or .so on systems, often guided by manifest files that declare the plug-in's metadata, dependencies, and entry points. For instance, in systems like Python, discovery can occur through package metadata entry points defined in pyproject., allowing the host to enumerate and select compatible plug-ins without hardcoding paths. Similarly, in the platform, the runtime scans a plugins directory at startup, parsing plugin.xml manifests to build an in-memory registry of available extensions. Once discovered, the loading phase employs dynamic linking mechanisms provided by the operating system to bring the plug-in into memory. On Windows, this is achieved via the LoadLibrary function, which maps the DLL into the process's , performs resolution, and invokes the DllMain with a DLL_PROCESS_ATTACH notification for initialization. On systems, the dlopen function loads the shared object, optionally with flags like RTLD_LAZY for deferred binding or RTLD_NOW for immediate resolution, returning a handle for further operations. During this step, verification occurs, such as checks to ensure integrity and authenticity. If loading fails—due to missing dependencies, invalid signatures, or file not found—the host retrieves error details via GetLastError on Windows or dlerror on systems, logs the issue, and may fall back to default behavior or skip the plug-in without crashing the application. The execution lifecycle of a loaded plug-in emphasizes on-demand activation to optimize resource use, where the host interacts with the plug-in through defined APIs or function pointers obtained via dlsym (Unix) or GetProcAddress (Windows). Initialization routines, such as those in Eclipse's Plugin class, are called only when a specific feature is triggered, enabling the plug-in to register callbacks, allocate resources, and contribute to the host's functionality. Throughout execution, the plug-in operates within the host's , adhering to isolation rules like class loader boundaries to prevent unauthorized access. Unloading occurs via dlclose or FreeLibrary when the plug-in is no longer needed, decrementing reference counts and invoking cleanup entry points (e.g., DLL_PROCESS_DETACH) to free memory and release resources, with error handling to manage partial failures. Performance considerations in plug-in loading revolve around the inherent overhead of dynamic operations, including file I/O for discovery and linking, symbol resolution latency (potentially mitigated by lazy binding), and memory mapping costs, which can add milliseconds to startup times in large systems. To address this, many architectures cache manifest data in after initial discovery, as seen in Eclipse's plugin registry, reducing repeated scans on restarts. Optimization techniques include preloading critical plug-ins at host startup for frequently used components or employing just-in-time loading to defer non-essential ones, balancing responsiveness with resource efficiency.

Helper Applications

Helper applications are standalone programs that a host application, such as a , launches externally to handle specific tasks or file types that the host cannot process internally. These programs operate independently to extend the host's capabilities, for instance, by invoking an external PDF viewer like Reader to render PDF documents downloaded via the browser. Unlike plug-ins, which embed code directly into the host's for seamless integration, helper applications maintain separation to avoid direct interference with the host process. A key distinction lies in their execution model: helper applications run in distinct operating system processes, providing without loading any code into the host's memory. This separation means there is no direct code integration, and any necessary communication between the host and the helper occurs through (IPC) mechanisms, such as passing file paths via command-line arguments, pipes for data streaming, or sockets for networked interactions in more complex scenarios. For example, early web browsers like Netscape used Acroread (Adobe Acrobat Reader) as a helper application to display PDFs by launching it with the file as an argument, allowing the viewer to handle rendering independently. Similarly, web applications can invoke external email clients through the mailto: protocol, where the browser launches the user's default email program—such as Microsoft Outlook or Apple Mail—with pre-filled recipient and subject details. This external approach offers advantages in simplicity, as developers can leverage existing standalone tools without building custom integrations, enabling quick support for diverse formats like audio streaming via players. It also facilitates multitasking, allowing the helper to continue operating even if the host application is closed. However, these benefits come with limitations, including higher startup latency due to process initialization and increased from managing multiple independent processes. Additionally, the isolation can introduce security risks if the helper processes untrusted content, though it inherently limits the blast radius compared to in-process extensions.

Extensions and Modules

Extensions and modules represent related yet distinct approaches to extending software functionality, often serving as alternatives or complements to plug-ins in modern computing environments. Extensions typically refer to user-installable add-ons that enhance application capabilities through scripting and web technologies, such as , CSS, and , without necessitating recompilation of the host software. For instance, browser extensions like those for operate within a sandboxed environment, leveraging APIs to interact with web pages and user interfaces, thereby providing features such as content modification or . In contrast, modules are generally compiled components that integrate more deeply into the host application, either statically linked during build time or dynamically loaded but often requiring a restart for activation; in Python, for example, modules consist of Python source files compiled to (.pyc) files for efficient execution upon import. Compared to plug-ins, which emphasize runtime loadability for on-demand extension without interrupting the application, extensions and modules exhibit less dynamism in their integration. Extensions rely on interpretive scripting languages, allowing quick installation and updates via stores or repositories, but they operate within constrained permissions to mitigate risks. Modules, particularly statically linked ones, become part of the application's binary, promoting tighter coupling and performance but demanding recompilation for changes; even dynamically loadable modules, such as those in the , require server restart to enable or disable, differing from the seamless, hot-swappable nature of many plug-ins. This static or semi-static nature reduces overhead but limits flexibility during execution. Representative examples illustrate these concepts effectively. Browser extensions, such as ad-blockers like , use to inject scripts into web pages for real-time content filtering, installed directly through the browser's extension store without altering the core browser code. In server software, Apache's loadable modules—compiled as shared objects—extend functionality for tasks like URL rewriting (mod_rewrite) or SSL support (mod_ssl), loaded at startup via configuration directives rather than runtime invocation. Python modules, such as the standard library's math module, provide reusable code units imported at runtime but pre-compiled for speed, enabling developers to build applications modularly without external plug-in architectures. In contemporary , there has been a notable evolution toward web-based extensions over traditional plug-ins, driven primarily by security considerations. Legacy plug-in architectures, like in browsers, exposed systems to vulnerabilities by granting plugins unrestricted access outside the browser's sandbox, leading to exploits in components such as . Browsers like Chrome phased out support by late 2015, promoting extensions built on secure web technologies that confine operations within isolated contexts, thereby enhancing overall stability and reducing attack surfaces without sacrificing extensibility. This shift underscores a broader trend in toward safer, more maintainable extension mechanisms.

History and Evolution

Origins

The origins of plug-ins in lie in the modular software designs of the and , which emphasized and runtime extensibility to manage growing system complexity. In Unix systems, the pipe mechanism, invented by Douglas McIlroy and implemented in Version 3 Unix in early 1973, represented an early form of by allowing independent programs to interconnect via standard input and output streams, facilitating reusable components without tight coupling. This concept laid foundational principles for later plug-in architectures by promoting loose integration of software modules. Building on these ideas, dynamic linking emerged in the late as a key enabler for plug-in-like extensibility, permitting libraries to be loaded and shared at runtime to avoid and improve efficiency. A pivotal advancement was the shared libraries facility in , detailed in the 1987 paper "Shared Libraries in SunOS" by Robert A. Gingell, Meng Lee, Xuong T. Dang, and Mary S. Weeks, which introduced and runtime symbol resolution to support modular extensions in environments. These developments addressed the need for scalable software amid increasing demands for and networked applications. The first prominent plug-in systems appeared in the early 1990s, driven by browser vendors and creative software firms seeking to enhance core applications without expanding their base footprint. introduced plug-in support in Photoshop 2.0 in 1991 to enable third-party filters for advanced image processing, motivated by the desire to extend editing capabilities for professional users. Similarly, Navigator 2.0 launched the (NPAPI) in 1995, allowing developers to embed content like animations and viewers directly into web pages, spurred by the explosive growth of the and the need for richer browser experiences. Key innovators, including and later with ActiveX controls in 3.0 in 1996, alongside , propelled adoption by prioritizing extensibility to handle diverse demands without overburdening primary software.

Modern Developments

In the 2000s, plug-ins reached their peak popularity, particularly in web browsers, where became dominant for delivering multimedia content, animations, and interactive applications across millions of users worldwide. However, this era also exposed significant security vulnerabilities, as plug-ins like Flash and those using the Plugin Application Programming Interface () often ran with unrestricted access to system resources, leading to frequent exploits, crashes, and data breaches that affected user privacy and device integrity. These issues prompted major browser vendors to deprecate NPAPI support; fully removed it in version 45 in September 2015, while Mozilla Firefox followed suit by ending support for most NPAPI plug-ins in version 52 in 2017, except for Flash temporarily. Adobe ultimately announced the end-of-life for Flash Player on December 31, 2020, blocking all content thereafter to mitigate ongoing risks, marking the decline of traditional browser plug-ins. Contemporary trends have shifted away from legacy plug-ins toward native web standards and integrated ecosystems that enhance security and performance without external dependencies. and (Wasm) have emerged as key alternatives, enabling browser-native execution of complex code—such as high-performance computations and graphics—directly in environments, reducing the need for proprietary plug-ins. In software applications, plug-in models have evolved into curated marketplaces; for instance, launched its extensions marketplace in November 2015, allowing developers to distribute and install modular enhancements like language servers and debuggers seamlessly within the IDE. Emerging technologies are revitalizing plug-in architectures with enhanced isolation and integration capabilities. In desktop applications built with , sandboxing confines renderer processes to restricted environments akin to Chrome's, preventing malicious code from accessing APIs or system resources, a feature enabled by default since Electron 20 in 2022. AI-driven plug-ins have gained traction post-2022, exemplified by OpenAI's plugins (introduced in March 2023 but deprecated in 2024 in favor of custom GPTs), which extended language models to perform tasks like web browsing, code execution, and data analysis via secure API integrations. Cross-platform frameworks like Qt continue to support robust plug-in systems, using high-level APIs for extending functionalities such as image formats or database drivers, with modern deployments leveraging metadata and static linking for reliable, platform-agnostic loading across Windows, , and macOS. Looking ahead, plug-in development emphasizes heightened security through and zero-trust principles, where components are isolated in ephemeral environments to verify every access request, mitigating risks in scenarios. This aligns with broader security trends, integrating runtime monitoring and immutable images to protect against attacks, ensuring plug-ins operate under least-privilege models in cloud-native and AI-integrated applications.

References

  1. https://www.computerhope.com/jargon/p/plugin.htm
  2. https://www.ionos.com/digitalguide/server/know-how/what-is-a-plug-in/
  3. https://www.spiceworks.com/tech/tech-general/articles/what-are-plugins/
  4. https://retrocomputing.stackexchange.com/questions/30594/what-was-ibm-vs-pc
  5. https://www.quark.com/about/blog/40th-anniversary-quark-part-one
  6. https://eshop.macsales.com/blog/64930-hypercard-one-stack-at-a-time/
  7. https://www.geeksforgeeks.org/techtips/what-are-plugins/
  8. https://wpexperts.io/blog/wordpress-statistics-2025/
  9. https://queue.acm.org/detail.cfm?id=1053345
  10. https://learn.microsoft.com/en-us/dotnet/framework/mef/
  11. https://www.cs.bu.edu/faculty/matta/Teaching/cs835/S00/Papers/router-plugins.pdf
  12. https://www.arl.wustl.edu/projects/archive/gigabitkits/References/Router_Plugins/wucs-98-08.pdf
  13. https://www.chromium.org/developers/npapi-deprecation/
  14. https://www.chromium.org/developers/design-documents/plugin-architecture/
  15. https://developer.mozilla.org/en-US/docs/Glossary/Plugin
  16. https://www.w3.org/TR/html401/struct/objects.html
  17. https://archive.org/stream/PRIVATEHTMLCOURSES/HTML_XHTML_CSS_JavaScript_djvu.txt
  18. https://learn.microsoft.com/en-us/lifecycle/announcements/silverlight-end-of-support
  19. https://www.oracle.com/technetwork/java/javase/migratingfromapplets-2872444.pdf
  20. https://www.adobe.com/products/flashplayer/end-of-life-alternative.html
  21. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/52
  22. https://helpx.adobe.com/photoshop/kb/plug-ins-extensions-photoshop-cc.html
  23. https://helpx.adobe.com/photoshop/kb/plugins.html
  24. https://marketplace.eclipse.org/listings/category/programming-languages
  25. https://eclipseide.org/
  26. https://addons.videolan.org/browse?cat=325&ord=latest
  27. https://alessandrofrancesconi.it/projects/bimp/
  28. https://github.com/alessandrofrancesconi/gimp-plugin-bimp
  29. https://helpx.adobe.com/creative-cloud/apps/integration-with-other-apps/manage-plugins/install-plugins-extensions-using-creative-cloud-desktop-app.html
  30. https://wiki.eclipse.org/Version_Numbering
  31. https://addons.videolan.org/
  32. https://www.gimp.org/registry/
  33. https://developer.adobe.com/photoshop/uxp/2022/
  34. https://github.com/eclipse-lsp4e/lsp4e
  35. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/LoadingCode/Concepts/Plugins.html
  36. https://learn.microsoft.com/en-us/windows/win32/com/the-component-object-model
  37. https://developer.apple.com/documentation/corefoundation/cfplugin
  38. https://developer.apple.com/documentation/technologyoverviews/app-extensions
  39. https://martinfowler.com/eaaCatalog/plugin.html
  40. https://developer.chrome.com/docs/extensions/reference/permissions-list
  41. https://learn.microsoft.com/en-us/office/dev/add-ins/concepts/privacy-and-security
  42. https://packaging.python.org/en/latest/guides/creating-and-discovering-plugins/
  43. http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
  44. https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya
  45. https://man7.org/linux/man-pages/man3/dlopen.3.html
  46. https://www.oreilly.com/library/view/web-security-privacy/0596000456/ch12s02.html
  47. https://www.princeton.edu/~ota/html2/acrobat.html
  48. https://people.eecs.berkeley.edu/~brewer/papers/janus.pdf
  49. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers
  50. http://www.pierobon.org/articles/helplug.html
  51. https://developer.chrome.com/docs/extensions/develop
  52. https://docs.python.org/3/tutorial/modules.html
  53. https://httpd.apache.org/docs/2.4/mod/
  54. https://httpd.apache.org/docs/2.4/mod/mod_so.html
  55. https://blog.chromium.org/2014/05/update-on-npapi-deprecation.html
  56. https://www.cs.dartmouth.edu/~doug/reader.pdf
  57. https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
  58. https://www.bleepingcomputer.com/news/software/mozilla-to-drop-support-for-all-npapi-plugins-in-firefox-52-except-flash/
  59. https://blog.chromium.org/2023/04/how-webassembly-is-accelerating-new-web.html
  60. https://code.visualstudio.com/updates/vNovember
  61. https://www.electronjs.org/docs/latest/tutorial/sandbox
  62. https://openai.com/index/chatgpt-plugins/
  63. https://doc.qt.io/qt-6/plugins-howto.html
  64. https://linuxsecurity.com/features/future-of-container-security
  65. https://thenewstack.io/how-zero-trust-models-work-in-container-security/
Add your contribution
Related Hubs
User Avatar
No comments yet.