Crise

There is always an option not to install, select the "Advanced Installation" option and then uncheck the checkbox that appears. The text at the bottom will then reflect that no changes will be made.   That said I agree that this is convoluted and will see if we can remove that offer. Usually when we come to know about things like these we will remove these kind of offers. Unfortunately due to how things work we can not pre-emptively filter these kind of offers but have to exclude them after the fact.

I would need some kind of Wine diagnostics to see what the problematic code is, and if it can be rewritten within reason without problems for the Windows build. Basically I already know that it isn't doing what it should be doing, but I need some idea as to why before I can even consider looking into it. I am not familiar with Wine's implementation of WinAPI so to go in blind would be a fools errand.

It seems to be a Wine bug, unfortunately fixing it without breaking the build for actual Windows is probably not viable. Also we would need to know more than simply that it doesn't hash. The changes to hashing in 1.5.10 are substantial enough to make playing a guessing game an unattractive proposition.

SSL can be disabled through a setting, the exact name of it escapes me right now though, but you can find it on the same settings page as all the other options related to it.

I will look into this... most likely something we inherited from DC++. Edit: confirmed and reported upstream, https://bugs.launchpad.net/dcplusplus/+bug/1307313

He is running XP, that is not SP3. Because that function is present on all versions of windows we support. What I am curious is whether he can run 1.5.9 without getting that error message. Edit: that said, after some investigation unfortunately it seems likely that Microsoft has updated their SDK's in a way that basically disregards compatibility with versions of XP prior to SP3.

Not a bug... a feature.

The first message seems to be an an installer issue, will attempt to replicate this on my end. As for the second one that is an issue caused by a code change that seems to have been left in accidentally looks like there will be yet another .11 build sadly (because unfortunately it's not just a visual problem).

  Going to need a little bit more than that.   Also,  the total share size is not the only factor. It is in theory faster to share 10GiB's consisting of 4-5 large files than the same size made up by several thousand small files. Anything from where (network drive, slow USB drive) the data is to what condition the drive is in (physically or in terms of fragmentation) can be a factor.

  If I could choose as I like I would drop XP support the exact moment Microsoft does, because retaining XP compatibility is a pain. The people who use our binary/slim release know why, because we have to make separate binaries for XP (thanks Microsoft), our installer obfuscates this fact from majority of the users. So that is four binaries per release.   Whatever we will decide to do, I can say with some confidence that 64bit binaries for XP will cease to exist, mostly because 64bit XP is rare, and has always been rare.   The actual action plan regarding XP is to deploy an opt in system for gathering certain anonymous configuration data from users such as their operating system version and a make and model of their CPU. This will allow us to make informed decision on where to go with things like what operating systems to support or what compiler options we can use when deploying builds for future releases. Eventually this might extend to certain configuration options such as whether users use some features or not. Because quite frankly ApexDC has a severe case of "option shock" when it comes to new users. So when it comes to some options we would either like to cut them or make then the default behavior without an associated option (this later part is something that will happen earliest for 2.0).   If it weren't for the fact that we "need" (XP binaries can run on newer windows versions) separate binaries for XP already then we would probably keep supporting XP unofficially, but as it stands even if we do not intentionally break support for XP in terms of used API's the compiler is already making dropping it an appealing option and most likely subsequent releases of the compiler will do it for us because I don't see the next version of msvc supporting XP at all when the last two are already doing it through a separate toolset resulting in the need for specifically targeted binaries (which was added by Microsoft reluctantly to begin with, so I don't see it sticking around in msvc 2014).

I am not familiar with said hub or the software it is running, however, ApexDC is not aware of a concept such as chat only mode. So however the hub decides that you are in such mode is external to ApexDC.

What version? 1.5.9 currently has a known issue starting up on some machines. Please try 1.5.8, while this issue will be fixed for next version. If you have a particularly old CPU you may need to use the binaries intended for Windows XP regardless of your version of windows. You can do this by downloading the "slim" binary distribution. If you are on XP already our installer will use the correct binaries automatically. If you do not have the latest Visual C++ redistributable installed (2013) the installer will also install that for you. Alternatively you may download and install it from Microsoft directly.

This issue has been fixed for the next version, use 1.5.8 in the mean time.

Prefixing nicks with supposed connection type/speed has been going on in DC for as long as I can remember.   As for why their nicks otherwise are of similar I can not say, the first thing I would do as a hub owner if I saw multiples of the kind of users you describe is check whether they share obvious viruses (such as small exe files with names that would fit other file types better, or the same thing but zipped). Because those nicks smell randomly generated.

  Try tweaking your settings under Downloads > Queue (particularly priority settings, and make sure "automatically search for TTH alternatives" is set to a sane value, ie. not too low, hubs get annoyed when you do that and start ignoring TTH searches). You might also want to try enabling/disabling auto priority and see what that does.   If something you changes resolves it, please let me know... I might need to work on the defaults in this area because this is not the first I have heard of similar problems.

For 1) the option is no longer there but the behavior should be same as when that option was enabled on older versions (ie. the option has been removed the persistent search history is still there)   For 2) check your settings under Downloads > Limits (I assume your bandwidth limiting is off, if it isn't then, even if you set the limit higher than your maximum connection speed your speeds will be affected to an extent because of how the limiter is implemented).   Edit: looks like persistent search history was unintentionally deactivated, will be resolved for next version.

If you get "No slots available" then the users have no free upload slots for you to use.   If you get "All download slots taken" check your settings for maximum simultaneous downloads (Downloads > Limits).

  For XP, please make sure the binaries you are using are correct (if you used the installer this should already be the case, if not the correct binaries are under the XP directory in the archive).   With the info I have from this topic it is difficult to pinpoint the cause. Does the splash screen get shown at all? if it does, does it show any messages at the bottom of the splash screen before hanging if it does, what was the last message.

Older versions: https://sourceforge.net/projects/apexdc/files/ApexDC%2B%2B/

Is this a new clean install? Or are you migrating something over from another client. Did the installer install Visual C++ dependancies on your machine? As for different versions you should be able to try with 1.5.7 or newer. Although I can not think of a particular cause for this.

Try holding down shift and then launching it while holding it down. Then open your hubs manually from favorites.   How many hubs do you have in your client set to auto connect at start up?   Also does the hanging ApexDC leave behind an exceptioninfo.txt file in its directory, if so please upload it here.

That is an understatement, it keeps trying until it succeeds, which is excessive, because the time stamp for an update check is only updated on successful check (a slight oversight on my part). But using the phrase phone home for a 3 KiB static file download (2 KiB for the xml, 1 KiB for the signature) is hardly appropriate either. There is no data being collected. Well not anymore than you have being collected when you browse this site I'd imagine (which is standard, non-verbose, nginx access logs that are deleted automatically after a few days), the only instance where I ever look at access logs is if php fails without producing a stack trace. ApexDC does support http proxy as well, although a rather simplistic one but it does work. If we were interested in user data (without users consent), there would be about a dozen more effective ways do it that couldn't be bypassed as easily as the update check. So the claim that we would obfuscate the update server to achieve this is ridiculous. The most we might ever be interested in data wise is stuff like what operating system most of our users use, which leads into when we drop XP support for example because keeping it around is a major pain. But really if we had the time and interest to go looking for user information unannounced don't you think we would at least be smart with it and not spam the users system log about it. Common sense is golden. If we ever decide to collect usage statistics it will be entirely opt in and public (it couldn't be any other way anyways since we are open source).

Let me give out a little known fact, searching files through a hub has a protocol level hard limit of 10 or 5 (passive) results per each unique user. So in that sense you should always search for undesired files through ADL search because that goes through the entire share.

After looking into it a bit, this apparently used to be a thing, however, it has some pretty bad potential problems (see link)   http://www.dcbase.org/forum/viewtopic.php?f=55&t=695&p=2486

While making this happen is possible, it would very much be an ineffective feature addition. Because it would only work between supporting clients and while most existing clients have regex in some capacity in them they would need to support this very specific feature for that to be of any use. Edit: if you want to push for this to happen I would make the request over at DC++, because one it would need to be drafted and created as an extension to ADC and by DC+ supporting it would also mean wide support in clients. However, even with all this, it would only be functional within ADC hubs not on your run of them mill NMDC hubs because NMDC protocol development has essentially ceased in favor of ADC.