The changelog in the DC++ help lists the important bug fixes, with links to the official bug tracker entries where all the sympthoms and reasons behind the fixes are explained in detail.

The following are the most notable additional, user-visible changes:

• From now on, DC++ supports connecting to secure NMDC (with nmdcs:// URI in the address) hubs but still doesn’t, and likely never will, support secure NMDC client-to-client connections. The reasoning behind the decision, as to why so and why now, is available and discussed in this bug entry and in particular, in this comment.
• Some public hublists allow hub owners to specify an alternative, secure hub address beside the main one (mostly for having an option to connect to the same hub using an encrypted connection). With this release, DC++ starts supporting this feature by displaying the more secure address option in the hub lists, when it is available.
• The MiniUPnPc port mapper gets a Broad device detection option, introduced mainly as a response to this support conversation. The mapper code now also returns better identification of the device to the logs, which can be used to determine exactly which device a port-mapping operation happens on.

For complete information on all of the fixes, please refer to the list of commits. As usual, DC++ 0.883 will be advertised as a testing release first for a small set of the userbase, starting today. This new version should go stable later, in case no problems are reported in the testing period of roughly two weeks.

They recommend all existing Bazaar branches to be converted to Git format by a close deadline. Git has been available for a while, and by now the default code hosting format of the portal, They still do not provide automated tools to do the branch conversion, tough. The post links only instructions (or rather just an example) of how to convert an existing code base to the target Git format.

How does this affect Direct Connect development?

DC++ and other Direct Connect projects had been using Bazaar repositories for more than a decade in the past, but hosting and development of the active projects were moved a long time ago to Mercurial repositories hosted by SourceForge.

There is one exception though : DC++ is still using the Launchpad translation interface for localization. This requires language templates to be committed to the old DC++ Bazaar repository at Launchpad. The end-of-support announcement does not mention this, but from some of the comments it is clear that processing language templates from Git repositories currently does not work at Launchpad.

So this is a breaking change – something that they promise to fix in due course (again, see the comments), and will probably happen sooner than later since Canonical, the company behind Launchpad and Ubuntu, use the same system for localization of their flagship product.

After the conversion to Mercurial the commit history of the projects’ code still remained in the old Bazaar repository at Launchpad. Checking old commits and investigating how and when features came and went over the years is pretty useful for the development – something that often saves time and helps fixing problems or realizing new ideas. Launchpad’s now-defunct code browsing interface for bzr, called Loggerhead, provided a very useful functionality to do this (a function called ‘Blame’ in modern VCS systems). This will be missed since the SourceForge’s Mercurial commit browser user interface does not provide such a feature, from now only the CLI or possibly some other local tools are available to do this.

All in all, the immediate effect of this end of bzr service does not appear to be severe on our development process, but there are other considerations:

ADCH++ have a few forks—abandoned, but technically interesting and containing valuable ideas—that began to demonstrate the extensibility potential behind the barebones structure of the original project. These branches are also hosted on Launchpad in bzr format. In the future, if someone wants to pick up ADCH++ development, the achievements already present in these forked branches could be quite useful.

Additionally, there are branches with additional tools, essential scripts and plugins for both DC++ and ADCH++, source code that is referenced alongside binary downloads, and are otherwise unavailable elsewhere.

One of the biggest question marks remaining is that the announcement doesn’t say a word about what will happen when the bzr code branches will be phased out. Will there be a download provided for code bases that haven’t been converted by the deadline? If so, in what format?

Since we don’t have the answers to these questions yet, it is essential to make a backup all of the branches by the specified deadline, in Bazaar or Breezy (the successor VCS) format. Once that is done, we can decide later how, when, and where they can be made available to the public again.

The following forks and other code branches could be considered to back up:

All the four DC related projects from : https://code.launchpad.net/~poy converted, available at GitLab and LP

From project ADCH++ :
https://code.launchpad.net/~lanowen/adchpp/pyIadchpp converted, available at GitLab and LP
https://code.launchpad.net/~klondike/adchpp/adchpp converted, available at GitLab, Codeberg and LP
(adchpp-hbri has already been moved to GitHub)

From project ADCH++ Lan :
https://code.launchpad.net/~dc4lan/adchpp-lan/trunk converted, available at GitLab, Codeberg and LP

From project ADCH++ GUI :
https://code.launchpad.net/~sulan80/adchppgui/trunk converted, available at GitLab and LP
https://code.launchpad.net/~lanowen/adchppgui/plus converted, available at GitLab and LP

The original DC++ and ADCH++ bzr repositories, in their current state, might also be worth saving, as they could serve as a partial historical backup in case issues arise when converting the up-to-date Mercurial repositories—possibly due to similar future announcements from SourceForge.

If you think anything are missing from the above list, please add them to the comments.

Edit: all the listed repositories are now successfully converted, big thanks goes out to klondike who helped us out with his time and research on the proper conversion process and configured tools what he used to convert his own code repository and then eventually all the rest. Well done!

The base protocol document has been updated with smaller additions that had remained unreleased for quite a while. The extensions document received a few similar updates and now also includes the final draft of the CCPM (client to client private messages) extension.

Both documents have undergone an extensive editorial revision to eliminate typos, mistakes and broken links.

For the complete list of changes please refer to the Version history within each document or visit the ADC project’s home website.

The vulnerability allows a malicious remote user to terminate any ADCH++ hub service by sending a specially crafted INF command with I4 or I6 flags that contain an invalid or malformed IP address.

Hub owners running ADCH++ on *nix operating systems are recommended to update and recompile their hub software as soon as possible to be protected from a possible denial of service attack. If you run ADCH++ on Windows and want to be safe before the next release then please get an updated binary from our builds server or visit the development hub at adcs://hub.dcbase.org:16591 for more information.

The following are the notable changes that’s been made in the user interface:

• The Find text function within contents of hub and private chat windows now offers selected or at-the-cursor text by default to search for
• Similarly a “Search in hubs” by text and TTH context menu function has been added to most textual content windows for easy searching all connected hubs for chat contents
• From now you have a quick way to copy and share magnet links of freshly indexed files, right from the System Log entry by using a new item in the window’s context menu
• A popular request has been filled with adding an option to disable DC++ window previews in the taskbar rather than using the global setting of the operating system

Some under the hood improvements:

• Implemented the ADC encrypted active search results feature (SUDP). The feature is enabled by default on all secure ADCS hubs for search and result transfers between the newest DC++ versions
• More secure processing of XML files coming from foreign sources
• No loss of partially downloaded data in case of an operating system shutdown during non-segmented downloading of large files
• More efficient hash data rebuilding
• Segmented download initial chunk sizes has been tweaked to align with current average internet connection speeds. Please note that due to the special nature of the algorythm DC++ has for multi-source downloads, this change should effectively disable segmenting for the second chunk and on for downloads having only one source in most cases, due to the high bandwitdth availability of most of today’s internet connections. This change might also help you dealing better with those anti-segment evangelists – a few are still around after 25 years…

For a complete list of fixes, as always, please refer to the changelog or the list of commits. As usual, the release availability will be advertised only for a small set of the userbase for now. If no problems are reported, DC++ 0.882 will be set as a stable release within a few weeks.

For successful exploitation, Scripting Plugin version 1.0 should be installed AND enabled in any DC client / versions that support DC Plugins. DC clients having this particular plugin not installed (or installed but as long as the plugin is in disabled state) are NOT vulnerable.

For users running Scripting Plugin version 1.0 it is highly recommended to upgrade to version 1.10 as soon as possible to get protected from this vulnerability.

Please note that a vulnerable function named LuaExec has been completly removed from the plugin’s scripting API and that this release also updates the internal Lua engine to the latest version, both of which changes may cause incompatibilities with existing customly created Lua user scripts.

We’d like to thank RoLex of Team Elite for reporting, sharing proof of concept and recommending fixes for this issue.

First and foremost with this release DC++ is moved to a modern compiler platform that produces an executable that shoud be considered secure and acceptable by modern Windows versions long term, with their default security settings. Since these defaults can change and go stricter at anytime it is highly recommended for users running Windows 11 to upgrade their DC++ to version 0.881.

There’s also a revamp of many icons throughout the user interface which makes DC++ more fit visually to modern Windows themes. An away status indicator overlay is also added to the taskbar icon. The look of the list of users and their details in the Users window has been modernized as well; more of this kind of improvements to come in the next release.

The optimized (64-bit) build is now compiled with use of SSE4.2 CPU instructions making further improvements in performance for those with capable hardware. We still provide a legacy (32-bit) build for users with older computers.

Plenty of supporting libraries that DC++ has built in have also been upgraded to the latest and greatest versions, improving security and stability.

There are also many less important or unlisted improvements; for a complete list of fixes as always please refer to the changelog or the list of commits.

As usual, the availability of this new testing release will be advertised at the start of the program for a small set of the userbase from now. If no bigger problems are reported, DC++ 0.881 will be set as a stable release within a few weeks.

Here are the most important changes, the already announced ones listed first:

• DC++ is being released under GPLv3 from now.
• Binary distributions split to optimized and legacy with according hardware requirements
• Used a new updated compiler version for better performance that allowed optimizations for speed, compatibilty with modern Windows versions and more.
• This version introduces a new stable hublist server.
• Fully restored the use of an up-to-date GeoIP country database service, the one allows you to see what country a DC user is from, determined by their IP address. Country info display was absent or has relied on a pretty outdated static database in the last few years so this goes back to normal from now.
• Hublists caching have changed according to the joint proposal of all hublist server owners: downloaded cached lists are set to expire in 24 hours from now by default. But this simple method alone would break the original purpose of the hublist caching function which has been introduced years ago to help users finding public DC hubs when hublists providers are out of service. So now we implemented a change with the original purpose in mind: cached lists are deleted only if a hublist refresh is successful. When a hublist download attempt fails or the resulting list is invalid the proper cached copy of hublists are being kept (even indefinitely e.g. when the source server is discontinued).
• Added a safeguard to attempt outgoing ADC connections on IPv4 only if there’s no IPv6 connectivity available. So far this decision was based only on information coming from hubs which, in case of improper IP address information supply, could break transfers and searches in DC++. There is at least one ADC hubsoftware that has such a buggy behavior triggering the issue so this change actually fixes existing problems already experienced in the wild.

There’s also a few less important or unlisted fixes improving security, stability and usability; for a complete list of fixes as always please refer to the changelog or the list of commits.

The availability of this new testing release will be advertised for a smaller set of users who are running the latest stable release of DC++. If no severe issues arise, DC++ 0.880 will be marked as stable within a few weeks.

This change is important for the future maintainability of DC++ since some external data sources and (future versions of) libraries (will) require a compatible license. The change should be equally important to projects using code from DC++ for the same reason.

The obvious step forward is to require SSSE3 to gain more advantages but there’s a caveat: while Intel introduced this feature in its client CPUs in 2006, AMD has added it only surprisingly later, in 2011. Aging of PCs are knowlingly slowed down in the recent years so requiring this feature would make the latest versions of DC++ unusable on many old but still working PCs and we’d like to avoid that. At the same time, if we decide to require at most ~10 year old CPUs now then we can go much further with optimizations as there are plenty of other new CPU opcodes are supported by the processors that has been manufactured in this timeframe.

Therefore we decided to make a difference in optimizations between the two available builds of DC++: the 64-bit build, named “Optimized” from now, will require a CPU that is manufactured in the last 10 years going forward whereas we plan to make the 32-bit build (now called “Legacy”) remain usable on pretty old (currently 15+ year old) computers and 32-bit client editions of Windows. We plan to release this build as long as there’s some form of official support of 32-bit Windows editions exist.

As a first step foward the Optimized build of DC++ 0.880 will require an SSSE3-capable 64-bit CPU, which is basically anything newer than Core2 from Intel and FX series (Bulldozer architecture) from AMD. We plan to add more feasible CPU opcode optimizations in the subsequent releases of DC++.

This also means that from version 0.880 and on, users running 64-bit Windows versions on older, non-SSSE3-capable hardware will have to use the 32-bit Legacy build of DC++, even on 64-bit CPUs.

We added an automatic, completely seamless mechanism to the installer of DC++ that decides what build is best for the users’ system and that will be offered by default in the options at install time. Those, however, who like to use the portable releases have to be cautious. We’ll update the informative readme file in the download folders for help the decision of what build to download.

We release these two builds from now as predictably there would be not much demand for 64-bit releases targeting older CPUs, even less for 32-bit ones targeting newer processors. However, if you’re in this unlikey situation for some reason then do speak up in the dev hub and your request won’t be denied.