Crise

It should be out by the end of this week.

Well even if you are on LAN that doesn't stop you from being exploited by someone from the same LAN. As for choosing time and place for update checks that might be some thought for future... but certainly not for any minor version. (like 1.3.1 which is due next)

hmm, it used to work for me... but that was some years ago... I needed their "DUC" though

You can add support for them (That's what I was considering)

I haven't considered it at all to be completely honest with you. It might be a nice feature addition though. Maybe for next bigger version (ie. 1.4 or 2.0 which ever we decide it will be), but it won't be in for any of the smaller (ie. 1.3.x) versions.

This is probably caused by a hard limit in the new xml parser in 1.3.0. This will be fixed in 1.3.1 which will be out any day now. Regarding this update message, I don't see why people are so displeased with upgrading their clients in the first place, it's not like you'll loose anything ion the process if you do it correctly. (this comes from someone who updates his client multiple times a day at best times). Especially when the reason for blocking old versions was clearly stated in more than one place. Or would you prefer your client to be exploitable over the internet.

People, you should know that you can put a dns there as well... that is what I used to do long before I found out that DC++ had mods. That option might be useful I won't deny that... but it's not like it is essential. Since you can put a dns in that box as well (no-ip and dyndns ftw ) So disable all features that allow auto fill that settings field for you and put a dns pointed to your ip into the box and you are all set.

If you read that message then you should know why you need to update your ApexDC to the latest version... Edit: please see here: for how to upgrade your client without loosing any data or settings. Edit2: just to reiterate the point of that message, it means that anyone using version earlier than 1.3.0 can have their client crashed by malicious user over the internet.

I can't replicate this issue with windows 7, will check under XP later but it looks as if this could be windows issue, however, I'll still look at the documentation for those two dialogs (since they come straight from windows).

This is probably caused by the limit.... and it's a limit in the new xml parser from dc++, and yes it will be increased,

5.1: There is an option in queue settings, "Automatically match queue for search hits" turn that off to disabled the stream of filelist requests on searches. 5.2: It is true that option could certainly use some improvement but it's an option that can also be found in other clients so that's why it's there to begin with (and yes at one time it was enabled by default, however, that is not the case anymore but of course that will not change the setting with existing installations). 5.3: Right now there is no way to do this in the client itself... perhaps with lua scripts.

Background images are not allowed at present...

I am running windows 7 as well and I have had no issues with taskbar icon. Is this a repetive problem for you? (ie. does it happen every time ypu start Apex).

I don't think that is a bug, because no connection has been made at that point so there is nothing to close... well the menuitem itself could be grayed though.

Probably because it is more popular... ie. the probability of all nodes in the file being dead is lower, as for this DHT though I would consider the probability to have the file die much higher.... and while I do not know better I would think that emules kad is not only using the nodes.dat to get the nodes, like your DHT is at present, or is it?

It seems this was caused by another stupid mistake on my side... oh well 1.3.1 will resolve it.

I haven't forgotten anything... but you seem to have, where does that special xml with 1500 nodes come from. DHT is not like ed2k where servers stay up for long time (if that was the situation your suggestion would work), the nodes in DHT come and go way too fast for this "special" file to work efficiently.

Well although, it is not correct of you to say that everyone can create such a script, because that is certainly not always the case... you do have a good point. However, while I do understand your point and situation... I have to say that I disagree with the "bonus for users using client x" mentality. Because I believe every node in DHT should be equal but right now that is hardly the case. Because the whole point of DHT is decentralization unless I have misunderstood something, but if each client will end up having to rely on their own "nexus point", the bootstrap, that point is defeated. And yes I did have your bootstrap script but I lost it some time ago in a PC switch but that's irrelevant. I could ask though, why have you not made your bootstrap script GPL like all the rest of the code. Because if you had I at least would not be participating in this discussion at all (the reason behind this question should be very clear, because right now web based bootstrap is vital for any client wishing to implement your DHT). Edit: I guess I should say this though the user-agent string is in no way a reliable detection mechanism... after all there are several firewalls that alert user-agent and other http request headers. Also it is extremely easy to compromise such a check anyways. Edit: Also one thing to do regarding the bootstrap to improve performance is to use some form of caching if possible to lessen the load. Because the thing that "costs" in the bootstrap script is db access. (After all it has to create a new connection on every bootstrap access).

Check the XML files for markup errors... the XML parsing in 1.3.0 is notably stricter than it was in 1.2.2

It doesn't work at all, or triggers an error?

Then why did you create your DHT in such a way that it so heavily relies on one nexus point (ie. in this case strongdc website). You could have also allowed it to request routing table from DHT node it finds online in a hub (how you can implement this is a good and secure way is another thing, but it is definitely possible).

I looked at tthe source code, so I am pretty sure I am correct about this. It does create such backup from queue bit not favorites.

This first issue depends on the hub software actually... so it isn't possible for us to really fix it for everyone. I'll look into these... although in this case the specific idiot in question would be me There is no restrictions about sharing whole drives as far as I know but there is some restrictions about sharing windows directories... but if that restriction applies you should get a message in your status bar about it.

Then enable it . The option most probably won't return as it was, purely due to cosmetic reasons (in other words the page is full as it is, and to add yet another checkbox would make it only a mess).

I'll tell you a little secret, most of the changes in StrongDC 2.40 are already in 1.3.0, however, we decided it would be best to use a version number that was already out in the changelog, with the merge entry, rather than say an svn revision. In any case 1.3.1, with the missing changes from 2.40 and some other minor changes, will be release if not today, then early next week.