Crise

ZPK: First of all your link was wrong and second, you can't download those files without a password anyways. Also there is a reason why these builds are not generally available. Past experience has shown us that once a build is sent out there it stays out there. Because these versions are early and have a considerable amount of issues, some more severe than others. We would rather not find them hanging out in the open year down the line. Another reason is that it is more practical, because our version control is not public currently and we are not prepared to keep a full source archive of every uploaded build (for multitude of reasons server resources being one of them) it is currently more manageable to handle GPL on per request basis (ie. make a source archive available when someone with access to said binary requests it, see the GPL, version 2, FAQ or license text for more details). For the record, currently for non-windows systems access is generally given for anyone requesting it... just that it might take some time .

  http://www.apexdc.net/customise/   That page has not been updated in a while though. There is no real proper central place for themes, because there is no well defined format for them (meaning most clients change things around, so that one clients themes do not work, or only partially work for other clients).

We do, for now, we have some plans to collect some data on the matter (opt-in, of course) and make the final decision on it based on that. Windows XP EOL is coming fast (Q1 of 2014), which means that beyond Visual C++ 2013 it is extremely unlikely XP will be supported in any capacity by the compiler (even with 2012 and 2013 it is a major inconvenience) and as such eventually XP will be dropped. How soon would be determined based on any statistics we have or are able to get before the XP EOL by Microsoft.

For all the recent replies: this topic has not been updated in ages, until now.   I attached a simple text file to the first post of the topic which outlines the current process someone besides us can use to compile ApexDC.

How to compile ApexDC++ Download the attached text file and follow instructions.   Compile.txt   How reproduce a release version For this manually creating the appropriate version file (second approach in the attached file) is recommended. The necessary build id is the fourth version digit that can be seen in the about box or update check dialogs.   Creating redistributable binaries (with modifications) To get a redistributable binary out of the source code distribution we recommend that you set up an svn repository with services such as http://code.google.com/ and use that. Additionally you must change the version check url in the version-template.h (as your assigned build id will be 1 initially which is much lower than ours) and then proceed to digitally sign a new version file with a private key (generated by a toolset such as openssl). There is a small tool built into ApexDC itself that will do the signing for you, a windows batch file similar to the one below may be used to generate the necessary signature file (version.xml.sign).   @echo off ..ApexDC-x64.exe /sign "%CD%version.xml" "%CD%private.key" ..ApexDC-x64.exe /sign "%CD%beta.xml" "%CD%private.key" There is also an additional switch you will need to specify the first time signing version file with a new key which is -pubout. When this switch is present ApexDC will generate a pubkey.h file corresponding to your private key which should then be used to replace our pubkey.h so that verification will work against your version file pair. After you have a signed xml, the trick is to make it discoverable by your compiled version of ApexDC by uploading both the .xml and .sign files side by side to the location you specified inside version-template.h (remember to recompile with the correct pubkey.h file).   Recompiling ApexDC as a replacement for the release versions on ApexDC.net (for personal use) is not recommended or otherwise supported.

If you are having problems with hashing... try to disable "Fast hashing" there is an option for it in Advanced settings... also for larger shares it might help to add parts of the files in share first and wait for them to hash and then add the rest gradually.   DC client programs in general are poor at handling extremely large shares (in the terabytes range) consisting of numerous of small files in more ways than one, mostly because at the time when these programs where originally created such shares were extremely rare (since at the time to have that kind of storage space was expensive, when DC was firs conceived it was a big thing for the entire DC to have more than a terabyte of shared data).

As long as you backup your settings nothing will be lost, however, when restoring from said backup (ie. basically a copy of the Settings folder or alternatively the ApexDC folder under AppData with bunch of xml files depending how you installed ApexDC to begin with) you should be careful that any drive letters and or paths match the ones on your old installation.   If you intend to re-organize your share or drives you will have to delete the HashData and HashIndex files as well as manually go into DCPlusPlus.xml and remove any lines with paths that are invalid (for share as large as yours that seems unlikely, so just take care with the drive letters and paths, otherwise you will have to rehash the files).

  That is not possible... without installing a plugin on Foobars side to facilitate it. Because of this, it makes no sense to create another plugin for it when foo_winamp_spam is already a thing.

There is no way to get that information outside of being on a same hub with them, and even then only if the hub happens to be set to broadcast this information to all users. This is typically not done, usually only operators have this information provided to them by the hub. Regular users typically only see the IP address of a user after a successful connection attempt between the users is made. In other words the only way to reach favorite users is by being on a same hub with them. The system is little more than an online notification system sadly, and that is really the most it can be because there was is no central user database.

ADCGET is technically an ADC command, so it should be parsed with same rules as an ADC command even if used in the context of NMDC.   http://www.dcbase.org/forums/viewtopic.php?f=55&t=860   As for how ADC commands are expected to be treated by a client, generally named fields you do not recognize should be ignored... but as long as the command is otherwise valid the client (or bot) should not choke. It is easy to think of ADC commands as a map of keys and values, the first part of the commands arguments being positional and the second being by a named keys where each key is restricted to two characters. Duplicate keys are typically not a good a idea and thus not usually a thing.   Typically you won't run into any issues if you treat the named fields of an ADC commad as an equivalent of STL map, and the positional ones as an equivalent of an STL vector. Needless to say the guaranteed two character field names do permit some creative implementations of parsing and storing this. ADC as a protocol is designed to not choke when an addition like this is made, of course hubs and clients are responsible for exercising good judgement as to when a client is behaving maliciously, but typically if you can not parse something the protocol expects you to ignore it and let it bleed through in most cases.   Some real world implementations of hubs employ white listing when it comes to unknown commands sent to the hub (but the specification expects them to be dispatched according to their type), field names rarely get this treatment. Clients are expected to ignore unknown commands but not unknown fields within known commands.   http://adc.sourceforge.net/ADC.html#_general

The problem with that way of thinking is that it includes things that would probably be easier to do as direct modifications to the application than as a plugin currently. Something like this, however, is something that a minority of people would use and because of that if done it should be a plugin in my opinion. So yes, just as an idea and a concept it is perfect fit for a plugin. On a basic level your definition of plugin is fine, but it is a little too permissive. The way I (as someone who has the ability to choose between two approaches) would define a plugin is a piece of reusable programming/work, because this API is shared between several applications, that can be distributed separately of the original application. In an ideal scenario this means that the work can be divided because the ones maintaining the parent applications don't have to develop everything. But of course it doesn't make sense to create a plugin if it is more work than developing something as a permanent part of an application, however, not everything is a good fit for that either.   It could in theory be done through lua script (which is in essence just a different kind of plugin, that happens to be realized as a plugin itself) but even then the way to do it would be complicated, which doesn't really add up with the idea that plugins should make development easier not harder. The reason why plugins are supposed to make development easier is because what they can do is usually more limited than what you can do if modifying the parent (host) application directly and they come with well defined "rules" if you will.   So it is not so much what either side is and isn't capable of doing but who is capable of doing it and how, as well as how much knowledge is needed. The sharing of plugins between applications is an added bonus. Example: it is easier for someone not familiar with DC++ code to develop a plugin than to create a feature as part of DC++ because you only need to learn one API to interact with the application as opposed to the potentially dozens of classes and interfaces that make the API you are using tick, however, for someone familiar with the code it makes no sense to develop a plugin that we know is probably easier to do otherwise.

There is has been no mandatory update without reason, by default no upgrade is mandatory, 1.5.8 is not and won't be mandatory for foreseeable future. Regardless, if you have already decided to switch clients why even post about it, topics like these have no value to anybody least of all to you. Regarding: "This obtrusive policy of ApexDC++ developers is inacceptable for an open source project." Open Source by definition gives us the freedom to employ exactly the kind of policies we see fit, this is a free product with no associated warranty whatsoever. We invest our own time and money into it so at the end of the day, who are you (or anyone for that matter) to say what is and isn't acceptable. We've never taken a course of action simply out of spite or malice towards our users, every single decision has a reason behind it. Whether you agree or are even aware of all those reasons is irrelevant. You have the freedom of choice, which by the looks of it you have decided to exercise, no-one is forcing you to use ApexDC, never has and never will.

For one, that way of doing it would involve a lot of heavy lifting on the plugins part, and does not really describe a plugin anymore... and even then plugins have no way of reacting to filelist updates naturally as it stands (ie. they will not know when your share has been updated, outside of completed downloads, beyond monitoring the filesystem on OS level). If you want to think of it differently, the work required to make this happen is substantial enough that at that point going the extra mile to make a fully fledged bot wouldn't be that much of an undertaking. In other words it is not impossible but it is impractical, because the plugin system couldn't really help the plugin in any significant way. The bottom line: there are very few things that are truly impossible, when it comes to programming, but a lot more that are not possible with reasonable effort. The method you described may seem simple, but in truth it is anything but that, in comparison to limiting this hypothetical plugin to only downloaded files. Now, if API changes were made the situation might change, significantly even, but typically doing API changes for a single plugin is a bad idea (any API changes made should have more than one potential use case). Regardless, as it stands creating such a plugin at present is in fact not possible.

It would be possible to do for files downloaded using ApexDC itself, for files simply added to share, however, it would not be possible.

I can't reproduce the described behavior at all... granted I don't have winamp installed atm, could you try with some other plugin that makes use of chat commands.

Glad to hear that... I was thinking you had abandoned the thing entirely.

For future reference:   You will need WTL from http://sourceforge.net/projects/wtl/ in ./windows/wtl   Additionally you will either need to do what SubWCRev.exe is doing by hand which is generate ./client/version.h from ./client/version-template.h  or download and install TortoiseSVN and setup a local working copy for yourself as we do not currently provide public svn repository for ApexDC.   More info on SubWCRev: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html

Separate installers is always an option, however, I doubt we will be making several different slim packages... as more possible choices only means more room for mistakenly using the wrong binaries.   The difference here being obviously that the installer can tell you if you downloaded the wrong one a file archive can not.

MediaPlayers as maintained by us is currently in limbo, because most of the player supports it has have been made obsolete by the advance of time.   I will most likely put together a newer version with the still functioning player supports (which at the time of this writing include just Windows Media Player, for most operating systems and player versions) unless better alternatives are made available.   No plugins from the linked archive will function with 1.5.7. Besides the media player plugin, alternatives do exist in the repository linked by Lee, as well as few new cool plugins made by the DC++ guys. For the people that missed the memo, the plugins originally introduced in ApexDC 1.0 were always iterated on with the intention of contributing a plugin system to the DC++ project and a while back this happened. Thanks in large part to poy, and the other guys over at DC++, the plugin system is now way more refined and easy to use than it was. For anyone interested in plugin development I suggest checking out the following links.   https://launchpad.net/dcpp-plugin-sdk-cpp ( C++ ) https://launchpad.net/dcpp-plugin-sdk-c ( C )

    Did you upgrade using the binary or the installer, if it was using the installer, could you try using the binary and copying the exe & pdb in the XP folder manually... and see if it runs, just to see whether the issue is with the installer or the actual binaries.

The only way to feasibly do that is to share the directories where you do not want this to happen with ApexDC, in which case it happens depending on a setting. There is no way to do it outside of the directories you share though.

The client does not share that information with the hub or with other clients, so it is impossible at present, also even if it were to be made possible it would not have any retroactive effects. Also this as far as information goes is in the category that constantly updates, most hubs would not appreciate it, so at best it would be on a fairly long interval. To be fair, if it were up to me, I would prefer users ratio to carry more weight than the total share size, but like you said it is not reliable enough information to make that viable (spoofing share is slightly more complicated than editing an xml file after all). Also DC as an network is not entirely suited for it but hey one can dream.

That is not possible, unless the plugin tracks it themselves   What kind of use case would you have in mind for something like this... please note that getting information about the ratio of a remote user is not possible plugin or otherwise since it is not a statistic tracked by the protocol at present time.

The issue I am talking about was another one (and it was fixed, as far as I know), but the potential of theses issues appearing and not getting fixed, and more importantly hub owners and users not updating their software even if there is an update, then these issues become something worth to mitigate preemptively.   Like I implied above, I don't normally support defensive programming on client side (because it has the potential to hide issues, preventing them from being fixed). After all the server is ultimately responsible on how it handles unexpected behavior, (while the client is expected to behave in a responsible manner, it is  not something a server can rely on... if web servers did that the internet would not be what it is f.ex.). In this instance, however, considering the mentality of the user base (on both sides of the fence) and the general state of development for NMDC it seems warranted.   Regarding your suggestion it sounds reasonable and I will think about it.

Original NMDC client limited description (and probably nick too) to 35 chars, then DC++ removed these limits (in a semi-recent, by their release cycle, version) and it opened up issues with certain hubsofts. With NMDC development mostly the way of the dodo, as long as NMDC protocol is in ApexDC some hard limit will exist. In order to avoid any future instance of sleeping issues emerging from hub software that are still used but no longer developed (Since it's proven that most hubowners still on NMDC are either unable or unwilling to do anything about the situation). I'll check why the limits are inconsistent though, and will also try and find some documentation on it, but unfortunately most resources dealing comprehensively with NMDC are also hard to come by these days. From technical standpoint I do not believe it is not really the responsibility of the client to impose these limits, but as things are with NMDC, it is the responsible thing to do. If you ask me, DC++ removed these limits out of spite more than anything else, and I understand it... I am all for their pro-ADC attitude, but factually we are not in a place yet where it can happen. When the end users and server hosts are mostly living in blissful ignorance.