Crise

Note: this is the last post on here, copied directly from the new thing. Figured I'd use this to let those people know that still care. You may have noticed some intermittent downtime on apexdc.net over the last couple of days. This was due to rebuilding and upgrading the server. However, as a byproduct of this these forums became a major pain point. This has mostly to do with the decline in activity coupled with it no longer being worthwhile to keep paying for the privilege of having a secure installation because of this. So, to address this issue we now have a slim replacement on a more modern and free platform. Where's the old content? The old forums will remain on the server as read only for archival purposes for the time being. How long it will stick around remains to be seen as it was already necessary to manually patch certain bits to keep it working even in its current diminished capacity. This isn't something that can be done long term on a proprietary and complex code base that I already know more about than I'd care to admit. Selection of topics from the old forums has also been manually imported over and brought up to date so that they may be more easily found and as to not have an unknown expiration date on them (mostly topics that are referenced directly by the main website in some fashion). What about content being organized? By default the new platform will display a view of all recent discussions, but the more traditional categories still exist, one can be picked when starting a new discussion. For a more traditional way of viewing the content you can also go over to the categories tab. Going Forward This is mostly here so that if people want or need to reach people they still can and that there still is a place for people to bring up issues or requests if they feel so inclined. As far as future plans for the project are concerned, currently there really aren't any beyond keeping the client somewhat current and potentially fixing a few bugs along the way where possible.

I wonder if anyone expected to see this, ApexDC++ 1.6.5, that is? Notably this version focuses on keeping the client in its current state, well current by updating various dependencies including OpenSSL, the compiler used has also been updated to the latest version. Otherwise some time has been taken to incorporate some changes from DC++, including a high priority fix and a change long overdue to default settings. Update: an obsolete build was accidentally uploaded to SourceForge very briefly, in case you experience any issues with your installation then downloading the 1.6.5 version again should fix it. To find out if you are on the correct release version you may check Help > About > Git commit, it should be the following: 47d5052582fd424d3a54edc33307607d1e87eb2b (if it is listed as something else you are running the outdated 1.6.5 binary) A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.5 as soon as possible. Download: ApexDC++ 1.6.5 Happy Holidays and have a good New Year

I am not sure I follow... do you mean the ADLSearch window shows wrong value in a column? If so I can look into it but this seems like a really old bug

The first one is definitely a bug and I will look into it... as for the second one I am certain the tray icon behavior has not changed, but I can still check it out at some point (I seem to recall that in the olden days a tray icon was a requirement for "balloon" popups on older versions of Windows, which is why I am pretty sure it couldn't have changed).

I am pretty sure there is no DC client out there (with a graphical user interface) that can handle high volume of hubs very well, of course it depends on hub activity and size as well as any ongoing transfers etc., but the UI's at the very least are not generally built to handle high loads. The only advice, short of looking at a command line client, I can give is make sure all logging is disabled, although this will only primarily reduce disk I/O.

Just as an general comment... running ApexDC, or any DC client, with 80 hubs open is not really a typical use case. Or rather it wasn't one when these applications where created. So they really can't deal with volume efficiently, regardless of whether PM's are spam or legitimate messages. The UI is (or rather was originally) designed in such a way that the user is expected to only open a number of hub connections they can manage manually, which is why there is no real degree of automation in many places when it comes to managing any aspect of the UI. To put it in another way, DC really is not a general purpose file sharing application, as it was never designed to reach a large volume of content at once. Rather it was designed to reach a type of content aggregated by getting like-minded users together, you could say quality over quantity I guess (hence why it has chat featured at least equally if not more prominently than file sharing capabilities). As a bit of a history lesson, the original incarnation of DC was intended as an IRC replacement with a more user friendly interface for sharing files, as using IRC for sending files or using file servers is a bit of a mystic art in itself (and certainly mostly a lost one at that these days). Apart from that the original DC client, out of which DC++ and its many variants were initially reverse engineered from, could only connect to one (1) hub at a time. For more on the history of this thing, look here. Not that it is really good for anything but an interesting retrospective in today's context as the DC of today is completely different from that, but some parts of it still show today, in particular in the way the applications remain structured to this day.

There is no difference, except that the slim package only contains the required binary (ie. the .exe file). Mainly I suggested it so that we can see if the issue is specific to the version bundled in the installer. Having said that the binaries in each case should be identical.

Problems connecting to the update check should not be related to connecting to hubs at all, unless ApexDC is being blocked by either a router or a firewall, in which case it can not access the network at all. What is the connection error message you get in the hub windows (ie. after the line "*** Connecting <address>..."

I have actually recently though about this type of feature. However, pattern and IP matching will only result in a never ending game of cat and mouse. As such the only reasonable compromise I can think of (which can not be circumvented by script and bot authors) is to provide an option to ignore all PM's from particular type of hubs that are not from privileged users (ie. operators) or potentially users you have chosen to exclude by adding them as a favorite user. The problem with above though, is that it is quite a binary choice and can not be configured very well (at the same time, I am not interested in adding a feature that matches Nicks and IP's because of things already mentioned here). At the end of the day preventing bots from getting into a hub in the first place is obviously a hubs responsibility and whatever a client can do is only ever a band aid.

Where did you download the version of ApexDC in question, if you are using the installer make sure it is one from this web site. Also try with the binary only slim package instead.

I probably shouldn't say anything here to be honest, but I am going to anyways. Who won, is irrelevant... the whole concept of winning in this context is somewhat absurd it is not a war or a competition with a beginning and an end after all. I find it amusing that the word enemy even came up here at all. Whether I personally agree with or condone some actions of groups or individuals in the past, one way or another, is a different matter entirely, but also irrelevant. However, actions should have consequences and it should work both ways. I never was keyed into all of the drama, nor did I particularly want to be, however, I believe there is rarely if ever a good reason to hack (or whatever that word actually exactly means/meant here) something or someone. Unless, you have been explicitly asked or commissioned to do so to test for vulnerabilities for example. There is seldom a need to act on something, say a vulnerability, just to make it known. The situations where throwing your weight around is your only course of action should be few and far between (and if it is done, it should be with the knowledge that doing so will likely in turn invite some kind of response from others involved). This applies to all sides not just one or the other. When it comes to DC related projects, each project is free to manage themselves how they see fit, if that management causes ire with others then handling those situations is each projects individual responsibility as is handling any consequences of any decisions made. However, this also means that everyone involved should be able to respect these projects' right to make these decisions and at the very least agree to disagree on amicable terms. Just because you can do something doesn't mean you necessarily should, sometimes that means pushing aside your personal feelings so that you can look at a situation objectively and make the necessary decisions. Either way looking for trouble or making choices that you know are going to perpetuate a cycle can hardly be called productive use of time and resources. To address the matter of hublists, the whole concept while necessary at this time is, from infrastructure point of view, the weakest point in the DC network a linchpin if you will and obviously not in the positive sense. DC has a network structure that doesn't strictly require a centralized entity (above hubs) that has a lot of control in the first place so in the long run there should be an alternative for hublists that can ideally work autonomously. This is the direction that DC should have headed in the first place and it is purely based on the simple fact that a system that is self-managing is legally the most sound option (If you have little to no control over a system you can not be held responsible for exercising control, over said system, which you do not have).

I don't speak german (I think that is german anyway), but those kind of errors are propagated from the file system... my guess is that says the syntax for the file name or path is incorrect or invalid. Which means it is not that the file can not be found but that ApexDC can not save the file on your system. There can be number of reasons for this, however, it should not stop other files from being downloaded. Unless, said errors are so common that they take up all the spaces for active downloads (see Settings > Downloads, under the limits section). If the errors are so common that it is making it difficult for you to use ApexDC, I would suggest looking at the files that this error keeps happening with and seeing what they have in common (such as if they are all from the same hub or same users, or if their names seem strange in some way). Off the top of my head I would also recommend checking that your incoming downloads directory is set in a location that is always reachable. With very long path names the archaic limitations on Windows file path length might also be what is causing this... if you need to have your files in such folders or if you routinely work with files that have long names I would recommend reading up on the matter because ApexDC will not be the only software with issues on those kind of paths (the linked StackOverflow question has some proposed solutions).

Please clarify what you mean by file cannot be found? As far as I know, if the error encountered is "File not available" it will proceed to download files just fine (same should be the case if file has no sources). If there is an issue with these two transfer states it might be due to other features setting the priority of the file or preventig removal of invalid sources. However, initially I am thinking that what you mean with file not being found is not what I am talking about above but rather something else, because I don't ever recall hearing of this issue before (and as far as download queue management is concerned, that hasn't been touched in years).

It has been quite a while again. We are pleased to announce the immediate availability of 1.6.3 a maintenance update continuing in the same vein as the two before it. This time the focus is on updating third party dependencies and build tools with the latest security updates and patches. Notably the binaries distributed for the Windows XP operating system had a configuration issue for the previous version and this has now been addressed for our friends still in the past. A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.3 as soon as possible, regardless of which version of Windows you happen to be running. For the people who need the XP compatible binaries, we would like to give this remainder about changes introduced in release packaging with the previous version. Download: ApexDC++ 1.6.3 Update: 1.6.3 has an issue with compressed transfers, that affects connectivity, turning off the setting "Enable safe and compressed transfers" should avoid this issue on 1.6.3. Alternatively you can hold off upgrading until a fix is available.

The upgrade notice says it fixes connectivity issues with older versions (of apexdc) ie. the problem with 1.6.3 discussed here. Hubs should discourage the use of 1.6.3. However, if they are doing the same for .4 then they are in the wrong in the sense that 1.6.4 exist to address the problem with 1.6.3. As far as we are aware, there is no connectivity issues with 1.6.4, with any version of ApexDC or any client that we are aware of. You should be able to use version 1.6.4 or 1.6.2 without problems. However, you should not use 1.6.3. That is exactly what it means, as it says in the 1.6.4 announcement.

We are pleased to announce the immediate availability of another maintenance update 1.6.4. This version fixes connectivity issues with compressed transfers caused by recent updates to the zlib library that we use. These connectivity issues randomly affect both downloads and uploads with clients that are running an affected version of zlib without the appropriate fix included. Additionally OpenSSL and zlib dependencies have also been updated once again, in order to keep things current. For the people who still need the XP compatible binaries, we would like to take this chance to once more remind you about recent changes in release packaging for your operating system. A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.4 as soon as possible. Download: ApexDC++ 1.6.4

Now, is that a nice way to ask someone to do something. As for people upgrading to this version, as far as I am concerned there is no reason not to, provided they know how to read [the release announcement]. The update check doesn't direct them directly to the download page and, even if it did, the release announcement is linked on both the page they land on as well as the download and the changelog pages. So they have ample oppertunity to read it. We did our due diligence on the issue after it became known and in the end provided a not one but two working alternative solutions. Whether people make use of those solutions is not something I can enforce in the slightest. Likewise taking 1.6.3 out of circulation, is effectively not possible. Even if I did remove it from the site, the binaries are still out there. Also, having said that there is currently no easy way to roll the website back and then redo the changes when the version with the fix is ready, which is why I will rely on users ability to read and be people who can think for themselves instead. Now, as far as hub admins go, they have two options, either instruct people not to upgrade to 1.6.3 or point them to the workaround provided. Alternatively they of course could enforce a bans on the use of the client, either version specific or for the client as a whole. However, this again is not something we can influence and as such how they deal with the issue is entirely up to them. As far as I am concerned, by providing a fixed version at our earliest convenience (which will likely be this weekend, because people have a lives), is all we have to do.

I have updated the first post with instructions for a workaround for the time being. New version will be made available as soon as there is a verified fix for the problem. Relevant link: https://bugs.launchpad.net/dcplusplus/+bug/1656050

1.6.2 is on sourceforge, the page is linked from the download page. This is an issue with zlib upgrade. It affects all dcpp based clients with the new zlib as far as I know.

Not being affected by an exploit because a client is old isn't the same thing as not needing updates. It is just dumb luck most of the time. But you are right, that is off-topic.Also, being aware and doing something about an issue are two different things.. Why was it unclear... if another client can't decompress a filelist from the latest version of ApexDC yet that version can decompress its own filelists and another randomly picked client can decompress filelists from it then obviously I have to know which clients the issue manifests with. Also, there is always the possibility it is an issue specific to a single user, or multiple users with something in common when it comes to their shared files, (it could be as simple as the filelist that was generated being corrupted while being written to disk by chance), I am looking for information to reproduce the problem which your original post did not give me. Update: I just finished doing connectivity tests, and ApexDC 1.6.3 generated filelists download and open just fine using RSX++ and Zion++. So, it is definitely not a general issue with 1.6.3 (all involved clients in active mode using default settings).

I am not yelling at all. Zion, last updated in 2007, and RSX++, last updated in 2011, to be frank I am surprised this is the first issue you have encountered with newer clients. I will do what I can, however, if I can reproduce this issue with the latest version of DC++ then as far as I am concerned it is something that has to be taken care of upstream. No need to be so hostile all I did was as a simple diagnostic question, because for one your post was unclear on which clients were encountering an issue.

Can you tell me which clients the users people are seeing this from are uaing? (exact versions). Seems to be a backwards compatibility issue with zlib most likely.

I do use it, although only for chatting, and that is enough for me. If I am going to patch in security updates for my personal use I might as well put the builds out there available for everyone. I don't exactly disagree with you entirely on the state of DC, however, there are still plenty of people who do use it. Like I said in an earlier post, it can not compete as a p2p application, but it does offer something that most other p2p applications do not (and it does so, in my opinion, better than f.ex. IRC, personal servers are easier to set up and if you do need to send files it is way more user friendly). Mainstream p2p, if there is or ever was such a thing, I definitely concur with you DC is far past its time in the spotlight. But at the end of the day, that is understandable, the software was developed when terabyte was a large amount of data and most normal people didn't even know what a petabyte was. DC is not dead though, it just so happens it no longer has large scale public appeal (at least in most of Europe and USA, not sure what the situation is out there in Asia etc.). PS: DC++ is a piece of software, DC is the network (technically even that isn't correct DC being originally a shorthand for NMDC, but it now also covers ADC).

The code is technically open source even now, as any DC++ derivative should be, just that it is not being actively distributed just as the builds aren't (anyone who has had access to the builds in the past has been, and still is, able to request the source code for any build they have access to, as per GPL's requirement of equivalent access). It will probably eventually end up out there in the open, however, it is literally years behind at this point. Not that it means all that much, considering the cadence of updates on the windows side has also dropped. I know that opening it up might have some benefits at the same time I'd rather not put something out there, generally available, that is in a state not representative of what ApexDC is on windows (generally when it comes to wxWidgets version of ApexDC, it is like taking one step forward on other platforms but taking two steps back when your point of comparison is the windows version). It was never in a state where I could take it up as my daily driver on windows, which is probably one big contributor as to why I wasn't very motivated to work on its problems. I am not sure if I have previously said this here, but in retrospect if I had to make a cross-platform DC client I would probably take the ApexDC core gut the UI out of it and expand the current very barebones web server that it has to actually be modern and fully usable set of API's to which I could then build web based UI for in relatively short time. I believe at least one other client has done this (AirDC) and, even though hindsight is 20/20, it is really the way we should have approached this aspect as well. If only because building web based user interfaces has come a long way in the past few years and it is comparatively extremely fast to building something more native (and the technologies involved are generally very well supported). To give the above a bit of context, my use of DC today is entirely for discussion, it has basically taken the same role as IRC would for most people, the P2P aspect of it is honestly completely secondary to me at this point (also, the performance the protocols can support just can't compete with other ways of distributing files these days).

Depends, such a feature is in theory possible... having said that it would most likely require either creative use of the protocols as they exist right now or extending the network protocols to add this behavior . So, in short. Even if it was done it would only at best work between two other clients that implement this same feature in the exact same way.