Crise

Actually it is not missing... it might be missing in some translations but it is listed in the original english strings.

Core here means dcpplib, which is already compiling on linux in its unmodified form, only things that need porting are any differences to it that originate from us and StrongDC that may not compile on linux. So stuff like basic networking and threading code as well as third party libraries should very much be platform independent already. Regarding compiler extensions I am not aware of the code relying on any of those. The scope of points one and two isn't anything overwhelming I would think because of the reasons stated above and the fact that while there are plenty of modifications they are mostly adding functionality and thus using the existing code that is already linux friendly where possible. The third point is what's the overwhelming part... however, without the first two steps done we won't be able to work on that at all.

This is the main point which I like about wxWidgets.

They aren't you need Windows 7 SDK for the time being to compile ApexDC++. Anyone still having issue generating version.h, just put your code in an svn repository and you are all set... and there are countless of ways to get one.

To be able to compile on linux we need the core to compile with GCC, and thus MinGW, after the core compiles under MinGW for windows it is easier to fix any remaining win32 vs linux issues. As for dropping VS yes we are trying to do that... but that is just a small part of what we are trying to do, ideally the ends result of all of this will be side by side releases for windows and linux. Edit: regarding ranges... use common sense, what we make off our ads and the OpenCandy will fund this. Anybody can donate and help us out, This is also why there are no timelines listed for any of the projects on the jobs page.

Actually the webserver code has some win32 dependant bits, see WebServerSocket::accept and the use of ServerSocket::incoming (also it has some unused members like a HWND that is never used anywhere that are win32 specific). There is also at least one win32 specific bit in DHT code in UDPSocket::run(). The there are for example PopupManager. the initialization of this can just be moved to MainFrame without any consequences afaik though. Then there is Util::fileExists. These I can name at the top of my head.

The integrity won't be compromised since TTH is there... and as far as we know collisions really do not happen with it. To answer you question however the number of simultaneous segments is configurable from settings... under Downloads and Queue.

For starters... the downloads are supposed to go there, if they are incomplete they are moved to the downloads folder once complete provided that ApexDC++ can write to that directory and that there is enough free space on the drive where that directory is.

Just change it in settings: Advanced > Logs

You need the version.h file... which SubWCRev.exe would normally do for you, but you can get one out of version-template.h easily enough.

Sorry if my last reply came off as rude or blunt that was not my intention at all :)

Well still ADCH++ is booting you because you provide an IP that does not match the real one... as simple as that.

You aren't really doing anything wrong... I suppose this can be seen as a mess up on my part, it would generate the version.h if your source was an svn working copy and since I removed version.h from version control it didn't get copied to the exported version of the source.

You are trying to connect to localhost and you have your external ip in settings, or vice versa...

Well although from that I can only guess, it could have been hash data had gotten corrupted... or alternatively turning off fast hashing might have solved it. I don't know about large size being the problem, although this is the first time I hear of something as large as 16TB, it could be an indirect cause for a problem but not really the problem itself. Btw. a bit curious how does ApexDC++ perform in terms of memory with that much data shared?

They might, but if they are using NMDC why should that matter to them (I don't know if they are but if they aren't they probably know how to avoid what you said).

The links you provided are .NET Apex is not, so short answer no... Slightly longer answer, even if Apex was .NET app, that would be off the mark because that is for forms... once again an api call is an api call.

If it is just pre-configured then installing Apex using the installer on top of the existing installation can't mess anything up as the installer does not do anything to config files.

I checked 1.2.2 when I was looking for differences from older sources, but will check 1.2.1 though don't think that'll change anything. As for possible causes, well since it's windows api call only thing that could change how it behaves is windows updates I guess... or the fact that the recent ApexDC++ is compiled with newer (win7) SDK opposed to earlier ones. Though since the api function comes from a windows dll unless that or one of it's dependancies has been updated nothing should change.

And I am asking what kind of problems you are having with it?

Rather than just saying it's not working... if you have crashes report them.

I thought I did, but I was wrong, but I tell you we didn't change a single thing regarding that behavior (I even checked older sources to be sure, besides what we can change is limited anyways since it's a stock windows dialog).

While I understand your request, this will not happen... what you should do is compile ApexDC++ yourself if you want to distribute a modified version.

If you installed with dcppboot.xml previously look in AppData for your favorites... delete anything else and do a clean install (I don't think the uninstaller deletes settings if they are stored in AppData you see, so your clean install won't have been a clean install). Another thing you can try is hold the shift key before/while starting apexdc which prevents it from auto-connecting to favorite hubs on startup among other minor things.

Sure they have the skills... they are most adept in violating the GPL license...