Discord Messenger, a client that runs on Windows 95 and admits it breaks the terms

What Discord Messenger is, and the motto that explains it

Discord Messenger is a free messaging client designed to be compatible with Discord while remaining backwards compatible with Windows, down to Windows 2000 according to the README, with support for even older versions attempted. The screenshots in the repository are the clearest evidence of what that means in practice: the same application rendered on Windows 11, Windows XP, Windows 95 and Windows NT 3.1.

The project's motto, stated in the README, is that it is time to ditch MSN and Yahoo. That is not decoration, it is the design constraint. Anyone still running Windows 95 in 2026 is not doing so because they chose it, and the messenger they grew up with no longer exists as a service. Discord Messenger exists to put a modern chat client on that hardware.

The stated minimum requirements make the same point with numbers. For the MinGW build, Windows NT 3.1, Windows 95 or newer, and a Pentium Pro or Pentium 2 processor. For the Microsoft Visual C++ build, Windows XP SP2 or newer and a Pentium 4. Memory is listed as 64 MB, with a note that you can go lower but might start hitting the page file. A 64 megabyte budget is the constraint that dictates almost every other decision in the codebase.

Two smaller details in that list are worth pausing on. The Visual Studio path cannot go below Windows XP SP2 at all, which is a toolchain limitation rather than a code one, since the compiler will not emit code that runs on anything older. And the release notes for the current version describe it as a beta, with a note at the top of the README that this is beta software and there may be issues that need fixing. The project has been called beta for as long as the version history goes back, which is worth knowing before you point it at anything important.

The homepage is not on GitHub. It is at iprogramincpp.com, and there is a Discord server for the client, with a note that you currently need an official client to accept invitations, which is a small but telling constraint given the subject matter.

The disclaimer, and what it means for your account

The README has a disclaimer section, and it is short enough to quote in full because every part of it matters.

It says that using third-party clients is against Discord's terms of service, that although the risk of getting banned is low the risk is there, and that the author of the software is not responsible for the status of your Discord account. It links to a post from Discord's own account as the reference for the policy.

That is an unusually clear statement from a project that exists to be a third-party client. Most projects in this space either omit the issue or bury it. This one puts it near the top, states the risk without inflating or minimising it, and points at the platform's own words rather than paraphrasing them.

What the disclaimer does not do is change the analysis. The reason Discord restricts third-party clients is that its API surface was designed for its own application, and clients built outside that surface can break in ways that range from a missing feature to a protocol change that starts failing silently. The low probability of enforcement and the real probability of breakage are separate things, and the disclaimer addresses only the first.

For a reader deciding whether to install this, the practical framing is about which account goes in. An account you use for a hobby server, where losing it costs you nothing, is a different proposition from the one that holds your friends' history, your roles and your years of messages. The client either works on that hardware or nothing does, and the project is candid that it is a beta. Those two facts together are the whole decision.

One related constraint deserves a mention because it is easy to trip over. To join the project's own Discord server you currently need an official client to accept the invitation. That is a small reminder that this client is not a complete replacement, and that the ecosystem it lives in still assumes the official application exists alongside it.

Three build paths, and the Windows version macros underneath them

The build documentation is the most substantial part of this repository, and it exists because the target range is so wide that no single toolchain reaches all of it.

The Visual Studio route is the easy one and the README says so directly: it can only support down to Windows XP SP2, but it is easier to get started. You need OpenSSL compiled for Win32 or a prebuilt OpenSSL 3.x distribution, with a warning not to download the Light variants because they contain only the DLLs and no import libraries. You set an environment variable named `OPENSSL_INSTALL`, or `OPENSSL_INSTALL64` for a 64-bit build, pointing at the distribution. libwebp is optional, and if you want a later version you drop `libwebp.lib` into `vs/libs`. Then you open the solution file and build it, with both x86 and x64 targets available.

The MinGW route from Linux is the one that goes furthest back. It has an explicit limitation: 64-bit compilation with MinGW is not currently supported, which is why the Makefile uses an `i686-w64-mingw32` prefix. It also has a warning that the MinGW your package manager provides may not target your desired platform, and a pointer to a Pentium toolchain build guide for Pentium 1 support and native Windows 95 and NT 3.x targets. The installation is a single apt line covering mingw-w64 and the posix variants of the C and C++ compilers, followed by checking out the project's own fork of OpenSSL and building it with its `buildit` script, and optionally its fork of libwebp.

The sequence after that is where the cross-compilation actually happens:

git submodule update --init
sudo apt install mingw-w64 gcc-mingw-w64-x86-64-posix g++-mingw-w64-x86-64-posix
mkdir build && cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../win32.cmake
make -j12

The `win32.cmake` toolchain file is the project's own, and the guide notes you can pass a `TOOLCHAIN_PATH` if you built with a custom toolchain. The final make invocation takes the build mode and the character encoding as variables:

make DEBUG=no UNICODE=[no|yes] [-j (your core count)]
make IS_MINGW_ON_WINDOWS=yes DISABLE_WEBP=yes

The second of those is for the third method, building with MinGW on native Windows, which uses MinGW 6.3.0, the last release of the original Minimalist GNU for Windows, with a specific list of twelve mingw32 packages to install. That path also requires both the MinGW and msys `bin` directories on your PATH, because the Makefile shells out to `mkdir.exe` and `find.exe` from msys on the Windows side.

Underneath all three are two version macros with defaults that reveal the project's centre of gravity:

WINVER  ?= 0x0501
WIN32IE ?= 0x0500
DMPREFIX ?= i686-w64-mingw32

`0x0501` is Windows XP and `0x0500` is Windows 2000. So the default build declares compatibility with Windows 2000, not with Windows 95, and reaching NT 3.1 requires the Pentium toolchain and a deliberate change. A project that ships screenshots of Windows 3.1 is not necessarily built that way by default, and the difference is worth knowing before you assume a checkout will run on your oldest target.

Static linking is why a 2026 build runs on a Pentium Pro

There is one line in the Makefile that explains most of what makes this project possible, and it is a linker flag.

When building with MinGW from Linux, the toolchain configuration adds `-static-libgcc -static-libstdc++ -Wl,--no-whole-archive`. Statically linking the GCC and C++ runtime libraries is what removes the dependency on a matching `libgcc_s_dw2-1.dll` and `libstdc++-6.dll` from the target machine. On a current Windows install those are usually present, so the flag is unremarkable. On Windows 95 or NT 3.1 they are not, and a dynamically linked binary simply does not start.

That single decision is what lets a 2026 codebase run on a 1990s operating system. There is nothing clever about it beyond recognising that the runtime DLL is the actual barrier, and it is the kind of constraint that gets forgotten in every project that stops targeting old systems.

The same reasoning explains the OpenSSL instructions, which look fussy until you see why. The Shining Light Productions distribution of OpenSSL for Win32 puts its headers in an `include` directory and its libraries in a `lib/MinGW` subdirectory, while the Makefile expects the include directory at `$(OPENSSL_DIR)/include` and the libraries directly in `$(OPENSSL_DIR)`. So the README tells you to copy both into a new folder, assign that folder to `OPENSSL_DIR`, and make sure the libraries are in its root. That is not a quirk of the project, it is a quirk of a third-party binary distribution, and the project is documenting it so you do not lose an afternoon to a linker error.

There is a second, subtler reason to build OpenSSL yourself, given in the third method's notes. If you want to run on Windows versions that lack the Microsoft Visual C++ 2015 runtime, and the file named `VCRUNTIME140.DLL` is the one that matters, then a prebuilt OpenSSL linked against that runtime will not load. The README points to a separate section on compiling OpenSSL for older Windows versions for exactly this case. So the dependency chain runs deeper than it looks: your OpenSSL build determines which runtimes your application needs, and that determines which Windows versions you can reach.

The `DEBUG` and `UNICODE` switches complete the picture. The default is a debug build with symbols, which is the right default for a developer and the wrong one for a release, and the encoding can be switched between Unicode and ANSI builds, which for a chat client with emoji and non-Latin scripts is a decision someone had to make explicitly.

The synchronous HTTP client, and dark mode as an unimplemented feature

The unimplemented list is the most revealing part of the README, because each omission traces back to the same decision.

The item that explains the rest is on the technical list rather than the feature list: using an asynchronous HTTP library is unimplemented but planned. A Discord client without an asynchronous HTTP layer is a client whose message sending, attachment upload and history loading block the thread they run on. On a current machine that is invisible. On a Pentium Pro with 64 megabytes of RAM, an asynchronous HTTP stack with its own buffers and event loop is exactly the kind of thing that does not fit.

So the client is synchronous, and that single choice explains a family of smaller limitations. The user interface will freeze during a large attachment upload. Server switching will block. Whether that is acceptable depends entirely on the hardware, and on the hardware this project targets it may well be the only workable option, because the alternative is not running at all.

The same reasoning shows up in the visible feature list. Dark mode on modern systems is listed as unimplemented, which is a striking omission for a chat client in 2026 and a direct consequence of targeting Windows 95, where there is no dark mode to detect and no native theming to hook. Entering voice channels is also unimplemented, and there the constraint is both the audio stack and the compute.

The rest of the unimplemented list is more ordinary. A friends list, member lists in group messages and direct messages, blocking and closing direct messages, removing someone as a friend, muting channels, changing a nickname, and more options in the preferences menu. These read as the ordinary backlog of a client that has been developed by one person against an unusual constraint set, and the README is honest about which category each item falls into by splitting implemented from planned.

What is implemented is the messaging core. Viewing and interacting with servers and direct messages, viewing and downloading images and attachments, uploading attachments, editing and deleting messages, replying, a typing indicator, URL hotlinks with an untrusted link warning dialog, the member list in servers, pinned messages, embeds, profile pictures in the direct message list, and user notes.

That last one, the untrusted link warning, is worth a note. A client that renders a URL from a message and asks the operating system to open it is handing a string to a component that can launch something. Adding a confirmation dialog for that is a deliberate refusal to make the default path silent, and it costs one dialog.

MIT licensing, dependency forks, and a project that is still beta

The licence is the MIT License, with the text in a `LICENSE` file at the repository root, and the README states it directly. That permits use, modification and redistribution with attribution and no warranty, which is the right licence for a client whose main asset is that people can fix it.

The dependency situation is more interesting than the licence, and it is a real adoption consideration. Discord Messenger does not use upstream OpenSSL or upstream libwebp for the deepest targets. It maintains its own fork of OpenSSL, built by a script named `buildit` that accepts a toolchain path, and its own fork of libwebp, which you build and then point `LIBWEBP_DIR` at. Both forks live under the same GitHub organisation, so they are maintained alongside the client rather than vendored into it, and building the client from the Linux path means building two dependencies first.

That is a maintenance cost, and it is a deliberate one. Upstream OpenSSL dropped support for the toolchains that can target Windows 95, so a client that wants to run there needs a fork that has kept that support. The same logic applies to libwebp. Neither fork is in this repository, and neither is covered by this repository's licence, so anyone redistributing the client is dealing with at least three separate licence and maintenance questions.

The repository layout reflects the same structure. There is a `src` directory for the application, a `vs` directory holding the Visual Studio solution and its bundled libraries, a `deps` directory, a `res` directory for resources, a `doc` directory that includes the Pentium toolchain guide, and a directory named `hacks` whose name tells you most of what is in it.

The version history is where the beta status shows. The recent releases are v1.11 labelled as a beta on 2026-09-08, v1.10 as a beta in September 2025, and v1.09 as a beta in June 2025. Three betas across about fifteen months, and the last push was on 2026-09-08. That is a slow, steady cadence for a project where the last push is the newest release, which is consistent with a maintainer who builds carefully and ships when the thing works rather than one who publishes continuously.

So the summary is a deliberately small, deliberately old client with a permissive licence, a dependency situation you should understand before you build it, and an explicit warning about the platform's terms of service that most projects in its position would have left out.

Editorial conclusion

Use Discord Messenger if you need a Discord client on a machine that cannot run the official one, and you have read the terms of service issue and accepted the possibility of losing the account, because the project states that risk itself. Do not use it as a daily client on an account you cannot afford to lose, and do not expect parity: voice channels, dark mode, a friends list and channel muting are all listed as unimplemented. Verify first by cloning with git submodule update --init, building the Visual Studio solution if you only need XP SP2 and up, and confirming the WINVER default of 0x0501 in the Makefile matches the oldest Windows you actually intend to run on.

Frequently asked questions

Official sources

1. DiscordMessenger/dm on GitHub
2. License: MIT
3. Project website
4. README
5. Releases