Big Muscle

This is not a problem of any protocol. When someone writes hubsoft with condition "if VE<>++", it will write you "Turn on your tag" (or similar message) in ADC too and you will be forced to use emulation too. OK, but one thing should have been done - rename "emulation" to "Send real core version to hub".

Also, I don't agree with this opinion. It's true then nowadays there's small amount of ADC hubs. These are run by clever people which accept all clients. But in the future, when ADC extends more (if it ever happens), some ADC hubs will ban clients too. This has nothing to do with used protocol but with OPs/admins intelligence.

No, it's not. It depends on kind of emulation. Since ApexDC++ isn't anything more than DC++ with added features, it still has the right to identify itself as DC++.

It will be there only if you select the address with space. Just copy it without space and it won't be there.

There's no reason to do it. But there's a reason not to do it -> when you delete item from Finished items, this file will be removed from PFS feature.

as I see, the last DC++ source code still uses HKEY_CLASSES_ROOT to store this information, so it need admin rights.

Your smileyPack doesn't use correct format. It MUST be fixed in SmileyPack, not in application. If you aren't able to run Linux app on Windows, will you complain that fixing application isn't a solution?

Is this really fixed in DC++? I don't think so ;-)

Smartwin is really stupid thing. The more clever way would be using wxWidgets framework. I would rewrite it, but I don't have time to do it.

There's simple solution for you. Just do that such user doesn't exist :D

This is surely bug in smiley pack. When we implemented emoticon feature, we had specified what packs must realize not to replace normal text. If pack's author isn't able to respect it, it's not our problem.

I don't use it so much. Only one hub.

Current NMDC protocol is almost dead, so no other modification to it. There is modification which sends hub url in the latest dc++/strongdc++, but it isn't still what it needs to work properly. And also, there are another reason not to implement this feature, not only protocol limitation.

ah true I haven't notice a year :crying:

How does it ensure that incoming connection from IP 12.34.56.789 belongs to hub X and therefore it should provide filelist #2 ?

I can't do, because as I already said it's impossible to do it for NMDC protocol (and with current implementation it's impossible also for ADC)

I have to check it :-) EDIT: yes, it was wrong, it should be getHubUrl()

Nice to have a feature which doesn't work? It works partially in NMDC, but doesn't work in ADC at all... just look at the source, if you are in more ADC hubs, it will always take the first one and not the correct one where the connection belongs to. bool getSharingHub(const UserPtr& p) { Lock l(cs); OnlineIterC i = onlineUsers.find(const_cast<CID*>(&p->getCID())); if(i != onlineUsers.end()) { return (!i->second->getClient().getHideShare()); } return true; } but "onlineUsers" is multimap, so it can contain more records to one CID. The stated code always select the first record. But what if I share for this record and have hidden share for the other ones? And what will happen when I want to download something from user with hidden share and I disconnect from the hub at the time when connection has been established but file hasn't been requested yet? I will be able to download normally although share should be hidden ;-)

Then this feature is unnecessary, because you needn't share at all.

And where's the bug?

CIDs for NMDC don't do anything, because they aren't transferred during connection, so it can't still identify which hub the connection belongs to.

Maybe bug, maybe not. Everyone should realize that Hide share feature available in some clients is one of the "fake" feature. Current (NMDC) protocol has no way to detect which hub the connection comes from. So it is impossible to really hide share for any hub. It "works" only by "oh, I don't the hub, but I will select random one and maybe it will work"

but, what is "RS" ?

I have never had such problems. It always update my share size immediately.

I think that emulation shouldn't be there at all. Hubs shouldn't restrict users by their client. So if they don't allow any client, they will have only few users. It's their problem.