Crise

Sorry, you aren't I was... :whistling: been a bit too hot as of late.

Well for starters at least in my opinion %[PERSONAL] and %[APPDATA] are same as %TEMP% and %USERPROFILE%\Desktop\ would be UAC wise.

I'll double check all of this the change that results in the change of display received a last minute fix... the goal of the change being to unify connection display between ADC and NMDC when possible and also to fix connection sorting. Had a quick look, looks like overlooked NMDC a bit (read: people should just move to ADC) will make sure it works as intended in NMDC with next version. Also considering that there was no definite plans for another 1.3.x release before 2.0 so you can expect it to be released as soon as I verify the fix. To answer Meks question it just coverts the x.yyy connection type coming from hub tgo KiB/s

what opearting system?

Disable fast hashing... that being said if that does not help and if Microsoft says it is a device driver error I find it unlikely to be caused by ApexDC alone. Also this is just a quick reply I do not have time to hunt down the specifics about that bsod right now.

C++ based? what's wrong with C++? I mean if you were using ynhub then it can not be a matter of the source code because ynhub is not open source.

ADC has GFI (Get File Info) I believe, how useful that command is I have no idea though.

Not really, because there is nothing lost when ApexDC crashes (well nothing that could be recovered with reasonable effort anyways) that at least I can think of right now.

Tbh, I had forgotten that topic existed.

By changing the log file name for all items....

I have answered this same question multiple time... all ApexDC has changed is the default log settings, so you can simply go and change them under Advance > Logs.

Not really that helpful...

What do you mean by this?

About time, I was waiting for one of you to bring that up :stuart:

Then how come you can browse this website? You know, behind every website there is a for-profit corporation if you dig deep enough. And as generally with websites you (the users) are not bound by any contracts to these companies and/or organisations... we are the ones that are bound by contracts and agreements in using their services (and paying a fair bit for it too in case of www.apexdc.net) to serve content to users, not you. Sure logs are kept but the logs that are made are the same ones that get if you point your web browser over to those locations. I am aware that web browsers can use proxies, but ApexDC++ can do this too. The option is in settings, although I admit it is not very sophisticated and that it is named in a bit misleading way as while it speaks only about public hublists that proxy affects al htttp connections made by ApexDC. Using the term "phones home" in this case is pretty harsh because, as you can see from the source code, the intent of downloading the xml file is not to distribute information about users or usage of ApexDC but to deliver notifications about software updates. Feature which can be found in countless applications and most likely works by using similar principle in all cases. Also if you download your executables from SourceForge then in doing so you already leave a trace in their logs, how come you can do this? Now that is a fancy way to describe the automatic updates feature, which is turned off for now and there is no immediate plans to turn it on, which is another feature that is common to many applications and this feature is completely optional even if it was turned on. Regarding our server getting "owned" we are naturally not planning to let this happen easily but just as those two features above are shared among countless of applications the risk of something like this happening is equally shared among all of them. Also the cases where our server (or control over of our SF project facilities) could get compromised are limited and as a matter of fact you, as a user, can assist in one of those cases never coming reality by making sure you do not infringe anyones copyrights while using ApexDC++.

This has never been done... the connection that is made is made to web space that is under our control and all that happens is that an xml file, for the update check, is downloaded and parsed by the application... the file itself is never even saved on your hard drive. If you or someone else has been using a version that connects to some for-profit third party, then I suggest that you check where you get your executables from. Also I would be more than a bit interested in what this for-profit corporation is?

True it is possible to see the website (or to be more precise some pages of it) from 28th February, through archive.org but even if you initially select that record not all of the archived data is from that exact date (since archive.org attempts to show you a copy that is most complete). Also there is no record of the B2 version (CzDC-0699[b2]-src.7z) of the source in the archive. And the source you linked to that you claim is forgery just happens to be a B2 source, so you can not use web archive which has no record of CzDC-0699[b2]-src.7z from anything close to 28th February to prove that the source you linked to is counterfeit made by BM. Edit: also renaming a file does not change the actual data in the file... so a file name being different does not prove anything regarding the file itself.

You know... this topic makes me think about this (hypothetical) situation... if I have written code to open windows message box that looks exactly like message box X in application Y in the past can I go and claim that the author for application Y has stolen my copyright by writing the same function call to produce that message box in his application that was released a month later than mine. Of course I can't because anyone can write such line of code. Some of the examples given above are exactly like this and they will never hold... because even if some line of code is same as in some other application there is no way to prove whether it was copied from that application or not. The terms copy and paste fly out frequently in this topic... but can you actually prove that such simple lines were copy pasted and not accidentally written as identical, same as my hypothetical example above. But seeing as you are probably only going to ignore this post I'll just sit back and keep enjoying the show.

The country list is not in its unedited form (and I don't speak about whether it has one or two extra countries in it or not, but the actual code that uses it and/or makes it usable) so technically whatever changes were made to incorporate it to DC++ and use it in the public hublist frame are copyright by whoever did those changes. However, it really strikes me as amusing how you two are debating about copyright in regards to software where majority of the code is not even written by you. Also what adds to that is that you really have nothing to gain from going on about this (well nothing of real value anyways). Since having project removed from SF doesn't mean that the project ceases to exists... sure will have an impact but it doesn't eliminate the software. And anything other than by taking legal action you have no hope of achieving anything like that. Edit: please have a look at this regarding European Union and ISO: http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm#EU

As much as I enjoy following this discussion, I have moved some of the off-topic posts to Lounge, please feel free to continue whatever it was that you were doing over there thank you :whistling:

You might have ticked always on top in view menu.

Yeah but the difference to wxwidgets is this: That comes straight from wxwidgets wiki so it might be that the info is bit dated but I believe still valid.

Ok, EiskaltDC++ and it's licensing is not the topic of discussion here... but I have to say that I too am under the impression that (even if it may be copy paste from FSF) the mention about later GPL versions in file headers is valid for anyone wanting to use the code. Regarding EiskaltDC++ sure it is a nice project but I have addressed the topic of project merges earlier in the topic about this over at news forum (also in the specific case of EiskaltDC++ there could be some language barriers, since I see lot of the stuff regarding it are in russian). I have nothing particularly against Qt but my reasons for favoring wxWidgets is that it can look 100% native on windows (which until proven otherwise is the majority of our userbase). While easily being able to change appearance (one point mentioned for Qt) might be a point of interest for us regarding future even so I appreciate that my apps can look like native applications if I so wish.

Toast, while I agree with you regarding the hubsoft situation in ADC I do not appreciate you belittling all derivatives like that while putting so much faith on a patch that originates from one such derivative. Also if you have been able to read into this topic you'd see that it is not our intention to create "another fucking mod", to put it in your words, but to work on an existing one. The jobs are also not useless nor are the things we are trying to accomplish with them, which would hopefully have become clear to you had you actually been able to read this topic with some thought instead of just making assumptions. We are not reinventing the wheel here, we are simply trying to create one that more people can use. Instead of having different wheels for people on different platforms we want to have a single wheel that is exactly same (ie. side by side releases from the same codebase) on many platforms. Which we believe to be a worthwhile goal.

Since I'm doing this from a mobile phone I'll keep it short. Merging with another project is a major decision to make and it isn't an easy one either. Also linuxdcpp as a project has different goals from us and also seniority... so it really is not in our place to go suggesting such thing.