DC++ Linux port

[paskharen]

(sorry if this is off topic or something, but it's at least more on topic here that in that old and abuse "Compiling fails under Linux" thread )

Ive started a project at BerliOS to port DC++ to Linux. I've uploaded a new version of the code I posted here some time ago that actually can download files. Only people's file lists at the moment but it shouldn't be so hard to make it download actual files. It's also full of bugs but hopefully these will become fewer as time goes by.

I was thinking of posting this much sooner, but there was a quite serious issue with the program since gtk+ is not thread safe. This has been taken care of now, so hopefully it will be plain coding from now on and no more architectural problems.

So, check it out at http://linuxdcpp.berlios.de. And if you want to compile it and try it out please remember to read the README - the build process sucks at the moment and you will most likely have to edit the makefile.

[GargoyleMT]

I see you're using 0.4032. Did you take note of the 0.4033 and 0.4034 releases?

Code: Select all

-- 0.4033 2004-09-27 --
* Added rudimentary automake and autoconf support for the client part, perhaps this will encourage someone to finish a nice linux port

[paskharen]

Did you take note of the 0.4033 and 0.4034 releases?

Nope, did now . I will update as soon as possible. Also, I'll try to make the Linux gui part build with autoconf as well, but I have never used autoconf before so I'm not sure how soon this will happend.

[arnetheduck]

but I have never used autoconf before

neither have I - consider that a first attempt =)

[ijwyn]

And if you want to compile it and try it out please remember to read the README - the build process sucks at the moment and you will most likely have to edit the makefile.

I had to edit the g++ and gcc command line in the makefiles, but other than that everything worked fine, up until the last make. I got the following errors:

../client/BZUtils.h:46: error: 'bz_stream' is used as a type, but is not defined as a type.
../client/BZUtils.h:63: error: 'bz_stream' is used as a type, but is not defined as a type.
../client/BZUtils.cpp: In constructor `BZFilter::BZFilter()':

This was followed by a bunch more of BZUtils-related erros, but those were the tree first lines. How can I fix this?

[TheParanoidOne]

#ifdef _WIN32
#include "../bzip2/bzlib.h"
#else

#include <bzlib.h>
#endif

Do you have the bzip header files? If you are developing on a non-win32 platform (eg Linux) you will need these files. bzlib.h in this particular instance. If you are running a package based system, you should probably install a package called something like bzip2-devel.

[ijwyn]

Doh, should have thought of that, lol.Thanks. That fixed that part. However, I now get the following error:

------------------------------------------------------------------------------
g++ -g -c ../client/SettingsManager.cpp -o ../client/SettingsManager.o
../client/SettingsManager.cpp: In member function `void SettingsManager::save(const std::string&)':
../client/SettingsManager.cpp:299: internal compiler error: in find_function_data, at function.c:329
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:https://qa.mandrakesoft.com/> for instructions.
make: *** [../client/SettingsManager.o] Error 1
------------------------------------------------------------------------------

This seems like something a bit more serious... Any thoughts?
Should I report the bug like it says, or am I just missing something?

[paskharen]

This seems like something a bit more serious... Any thoughts?

I think this is the gcc bug arne has been talking about, read the files in the source distributions or search the forum for details (i'm to lazy to look it up right now) I've had this problem myself before, don't remember what version of gcc but it went away when I switched versions. A late 3.3 or any 3.4 should do it, i'm using 3.3.4 and it works.

Code: Select all

g++-3.3 --version
g++-3.3 (GCC) 3.3.4 (Debian 1:3.3.4-13)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[ullner]

paskharen: could you please provide a screenshot of LinuxDC++?

[paskharen]

I've uploaded some screenshots at the BerliOS project page. Just go to the linuxdcpp page and click screenshots.

[timo]

Like other people i have gone someway to porting dc++ to gtk. Specifically using gtkmm and glade.

I have done most of the ground work:
Handles messages from client threads to gui thread (eg to update searches etc).
The GUI is pretty much done, mdi windows, flat tabs, settings window, dc++ icons... a few more utility functions for lists (intergating with gnome for mime-types etc...) need to be done.
I have ported the client backend apart from large file support(problem is thats it's from dcpp 0.251)

Things that it doesn't do:
do anything useful (basically i didnt want to start acually adding the main functions until i had completed the groundwork). eg downloadlist /search window/ hubwindow.

If anyone is intrested i can post the source code somewhere under the GPL.

screenshots:





BTW before you ask i know there is meant to only be one public hub window.

[TheParanoidOne]

Perhaps a code combination effort might be worthwhile?

[PseudonympH]

Seems like we should use the first one's backend and the second one's frontend.

[paskharen]

I've just updated the linuxdcpp build process to use autoconf/automake, so it should be a bit easier to compile now. (./comfigure && make) Plus, hopefully it'll tell you what's missing if something is wrong. It would be great if people could try building it an tell me if it worked or not and on what system.

timo: Are you intending to keep working on this port of yours? Or are you offering the code because you got tired of it and hope somebody else will continue?

[timo]

I probably will continue my port sometime. But in the mean time if anyone wants to look at the code, you can get it here:
http://mplinuxman.sf.net/dcpp/dcppgtk.tar.bz2

I just tar/gzipped up the directory so there is all sorts of stuff there.
The win dcpp version used is 0.251 ... but the last time i checked the files i ported haven't changed in the later versions.

needs gtk / gtkmm / glademm

have fun

[psofa]

please make it dl and upl files cant wait.IMO when u have finished it (hopefully) u should try to make it look exactly like dc++
edit : ill try to compile it now

[psofa]

Doesnt compile

In file included from ADLSearch.cpp:24:
stdinc.h:88:20: hash_map: No such file or directory
In file included from ADLSearch.cpp:24:
stdinc.h:89: error: expected namespace-name before ';' token
stdinc.h:89: error: `<type error>' is not a namespace
In file included from ADLSearch.cpp:25:
DCPlusPlus.h:90: error: expected init-declarator before '<' token
DCPlusPlus.h:90: error: expected `,' or `;' before '<' token
DCPlusPlus.h:91: error: `StringMap' has not been declared
DCPlusPlus.h:91: error: expected init-declarator before "StringMapIter"
DCPlusPlus.h:91: error: expected `,' or `;' before "StringMapIter"
In file included from ADLSearch.h:31,
from ADLSearch.cpp:27:
Util.h:298: error: `StringMap' has not been declared
Util.h:298: error: ISO C++ forbids declaration of `params' with no type
In file included from ADLSearch.h:34,
from ADLSearch.cpp:27:
ResourceManager.h:39: error: ISO C++ forbids declaration of `hash_map' with no type
ResourceManager.h:39: error: expected `;' before '<' token
ResourceManager.h:40: error: `NameMap' has not been declared
ResourceManager.h:40: error: ISO C++ forbids declaration of `iterator' with no type
ResourceManager.h:40: error: expected `;' before "NameIter"
In file included from ADLSearch.cpp:27:
ADLSearch.h:54: error: variable or field `Prepare' declared void
ADLSearch.h:54: error: expected `;' before '(' token
ADLSearch.h:72: error: expected `;' before "string"
In file included from DirectoryListing.h:26,
from ADLSearch.h:228,
from ADLSearch.cpp:27:
User.h:65: error: ISO C++ forbids declaration of `hash_map' with no type
User.h:65: error: expected `;' before '<' token
User.h:66: error: `NickMap' has not been declared
User.h:66: error: ISO C++ forbids declaration of `iterator' with no type
User.h:66: error: expected `;' before "NickIter"
User.h:67: error: ISO C++ forbids declaration of `hash_map' with no type
User.h:67: error: expected `;' before '<' token
User.h:68: error: `CIDMap' has not been declared
User.h:68: error: ISO C++ forbids declaration of `iterator' with no type
User.h:68: error: expected `;' before "CIDIter"
User.h:107: error: variable or field `getParams' declared void
User.h:107: error: expected `;' before '(' token
In file included from ADLSearch.cpp:27:
ADLSearch.h:275: error: `StringMap' has not been declared
ADLSearch.h:275: error: ISO C++ forbids declaration of `params' with no type
In file included from QueueManager.h:32,
from ADLSearch.cpp:28:
QueueItem.h:42: error: ISO C++ forbids declaration of `hash_map' with no type
QueueItem.h:42: error: expected `;' before '<' token
QueueItem.h:43: error: `UserMap' has not been declared
QueueItem.h:43: error: ISO C++ forbids declaration of `iterator' with no type
QueueItem.h:43: error: expected `;' before "UserIter"
QueueItem.h:44: error: ISO C++ forbids declaration of `hash_map' with no type
QueueItem.h:44: error: expected `;' before '<' token
QueueItem.h:45: error: `UserListMap' has not been declared
QueueItem.h:45: error: ISO C++ forbids declaration of `iterator' with no type
QueueItem.h:45: error: expected `;' before "UserListIter"
In file included from ADLSearch.cpp:28:
QueueManager.h:48: error: ISO C++ forbids declaration of `hash_multimap' with no type
QueueManager.h:48: error: expected `;' before '<' token
QueueManager.h:49: error: `DirectoryMap' has not been declared
QueueManager.h:49: error: ISO C++ forbids declaration of `iterator' with no typeQueueManager.h:49: error: expected `;' before "DirectoryIter"
QueueManager.h:50: error: `DirectoryIter' was not declared in this scope
QueueManager.h:50: error: `DirectoryIter' was not declared in this scope
QueueManager.h:50: error: template argument 1 is invalid
QueueManager.h:50: error: template argument 2 is invalid
QueueManager.h:50: error: ISO C++ forbids declaration of `DirectoryPair' with no type
QueueManager.h:186: error: expected `;' before '&' token
QueueManager.h:190: error: expected `;' before '&' token
QueueManager.h:196: error: expected `;' before "userQueue"
QueueManager.h:198: error: expected `;' before "running"
QueueManager.h:214: error: expected `;' before "directories"
QueueManager.h: In member function `bool QueueManager::UserQueue::isRunning(const Pointer<User>&) const':
QueueManager.h:192: error: `running' undeclared (first use this function)
QueueManager.h:192: error: (Each undeclared identifier is reported only once for each function it appears in.)
ADLSearch.cpp: At global scope:
ADLSearch.cpp:246: error: `StringMap' has not been declared
ADLSearch.cpp:246: error: ISO C++ forbids declaration of `params' with no type
ADLSearch.cpp: In member function `void ADLSearchManager::PrepareDestinationDirectories(std::vector<ADLSearchManager::DestDir, std::allocator<ADLSearchManager::DestDir> >&, DirectoryListing::Directory*, int&)':
ADLSearch.cpp:284: error: 'class ADLSearch' has no member named 'Prepare'
make[1]: *** [ADLSearch.o] Error 1
make[1]: Leaving directory `/home/psofa/client'
make: *** [all-recursive] Error 1

[paskharen]

In file included from ADLSearch.cpp:24:
stdinc.h:88:20: hash_map: No such file or directory

Something seems to be broken with your standard library. What compiler/compiler version/distro are you using?

timo: I've downloaded your code, I'll take a look and see if there's something I can steal for my project If you're not working any more on it atm then other than that I'll just go on as if nothing happened. If you're interested, we should perhaps talk about merging when/if you decide to continue.

[psofa]

gcc-3.4.2 on gentoo

slocate hash_map

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2/include/g++-v3/ext/hash_map
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2/include/g++-v3/debug/hash_map
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2/include/g++-v3/debug/hash_map.h
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.4.2/include/g++-v3/backward/hash_map.h


also if i had gcc probs it would stop at line 67 (this is just what a noob thinks ) wouldnt it

[paskharen]

It doesn't fail on line 66 because HAS_STLPORT is not set. This is only for windows users who use the stlport library.
What's happening is that __GLIBCPP__ is not defined, it seems to be called __GLIBCXX__ somtimes. This is fixed in the 0.4034 release, but if you can't wait for me to update you could just replace __GLIBCPP__ with __GLIBCXX__.

And yes, I could update today, it builds without problems but now I've got this new situation with the timo code I have to look at. It's just so ironic that there are so many porting projects. (four that I'm 100% certain exists, plus lot's of rumor projects)

[uyu]

Hi,

Great that it's finally being ported!

Here are some bugs that i noticed (current CVS of today)


* Connection type is not saved to the config from the dialog
* No warning is issued if you try to share your download dir (didn't know this was prohibited)
* Pressing enter in the manual connect field does not work
* Segfault if you press the main search button twice directly after each other in MainWindow::searchClicked
* When i connect to a large hub the program just "locks up" waiting for some I/O
like this:

Code: Select all

(gdb) info threads
  9 Thread 1141316528 (LWP 2097)  0x407ef451 in __write_nocancel ()
   from /lib/tls/libpthread.so.0
  7 Thread 1132534704 (LWP 2089)  0x407ef266 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
  6 Thread 1123871664 (LWP 2088)  0x407ed115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
  5 Thread 1115483056 (LWP 2087)  0x407ef83e in recvfrom ()
   from /lib/tls/libpthread.so.0
  4 Thread 1106656176 (LWP 2086)  0x407ef6ee in accept ()
   from /lib/tls/libpthread.so.0
  2 Thread 1097198512 (LWP 2084)  0x407ed115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
* 1 Thread 1086342432 (LWP 2083)  0x407ef266 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0

[ivulfusbar]

I don't see what the accept() call has with anything todo. ;)) (for example).. Unless many users connects to you? When you logged in? ;)) Did you use a random-nickname or your usual? ;)) ooops.. or was that maybe only the state that one of the threads was in? ;))

I have forgotton my gdb-skills. ;))

[paskharen]

ivilfusbar:
I'm not sure I compleatly understand you question but I'll rant a bit about accept and hope that solves it The call to accept is needed in order for peple to be able to connect to you. Thus, it is not needed when loading the hublist or connecting to a hub (since in those case you connect to them) When downloading files however, you connect to the user and say "hey, give me your filelist" and the connect back to you and tranfer it. The whole thing is complicated futher by the fact that accept blocks, and thus needs to run in a separate thread, and that the standard client uses a windows specific feature in order to avoid the blocking and threading and all that.

uyu:
Ok, some of those are already fixed by another guy but not integrated yet (we thought we'd wait until I've updated to 0.4034) I'll look at the others after the update. The problem is that unicode is really confusing to me. I mean, I know what ascii is, and I know what UTF-8 is, but wtf is "wide character format"? If someone could explain this, or knows a good page about it I would really appreciate it.

[ivulfusbar]

paskharen: i was answering/commenting on the thread above. I.e. the output from gdb which could have todo with the below;

Code: Select all

uyu
* When i connect to a large hub the program just "locks up" waiting for some I/O
like this: 

(gdb) info threads
  9 Thread 1141316528 (LWP 2097)  0x407ef451 in __write_nocancel ()
   from /lib/tls/libpthread.so.0
  7 Thread 1132534704 (LWP 2089)  0x407ef266 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
  6 Thread 1123871664 (LWP 2088)  0x407ed115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
  5 Thread 1115483056 (LWP 2087)  0x407ef83e in recvfrom ()
   from /lib/tls/libpthread.so.0
  4 Thread 1106656176 (LWP 2086)  0x407ef6ee in accept ()
   from /lib/tls/libpthread.so.0
  2 Thread 1097198512 (LWP 2084)  0x407ed115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0
* 1 Thread 1086342432 (LWP 2083)  0x407ef266 in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0

i know perfectly well how accept() works. And btw, accept() doesn't have to block. You can use none-blocking if you want. ;)). I was more in my mind thinking about if he connected to a hub where many clients was triggered by the event that he has joined the hub, and thereby triggers their queues to check if they have him as a possible source and thereby triggering alot of connecttome/revconnectome during the entering (after handshake, userlist, myinfos..). The revconnecttome would trigger ctm which would trigger accept() calls later. ;)).

the recvfrom in his gdb output is only the udp-incomming-sr-thing aswell.. so? Do you use blocking here aswell btw?

[paskharen]

the recvfrom in his gdb output is only the udp-incomming-sr-thing aswell.. so? Do you use blocking here aswell btw?

eh, no idea really... I haven't touched any of the communication stuff except replacing the call to WSAAsyncSelect with creating a thread that calls accept...

[psofa]

do we have sth we can use yet?

[psofa]

omg just tested it and its more aplha than i thought it would be.I get segfaults when i select directories in the options, invalid pointer warnings!the gui is good though

lol @ do u want to exit this fine application ?

i have also a question: (dont laugh with me im a noob)
if i have understood ok what a thread does, why do u need threads for accept(), isnt select() appropriate?
if i understand correct WSAAsyncSelect is just a more informative select isnt it?

[paskharen]

I get segfaults when i select directories in the options, invalid pointer warnings!

Yeah, well things used to be a lot more stable before all the client updates. I haven't really had the time to look through all the gui code and update the interaction with the backend.

if i have understood ok what a thread does, why do u need threads for accept(), isnt select() appropriate?
if i understand correct WSAAsyncSelect is just a more informative select isnt it?

Unix select is just a function you can call to ask if input is ready on a group of filedescs. WSAAsyncSelect lets you register a callback that the system calls when input is ready. Thus, select needs to be called now and then to check for data but you don't need this with WSAAsyncSelect. I'm probably going to emulate WSAAsyncSelect using select + a thread in the future tho, this is a much better solution that the current uglyness.

[psofa]

ok thanks for the clarification
EDIT:
just a nooby's idea: is it possible to use wine just to emulate the client and only write the native gui?The problem people are having with wine is probably more a gui than a client one.Isnt it possible to use winelib to compile mixed things? i mean window and unix libs.This way it will be a piece of cake to cope with dc++ updates

[tajisen]

Nice work!

The CVS compiled without problems for me (slackware 10.0).
With a GUI more like original DC++ (like timo's) and this might become somthing useful. A good DC client is something missing in the unix world. We want to p2p the latest kernel to

I want to se something like this being merged into the main DC++ project so that DC++ is the first choice for users on all major operation systems.

[greebo]

.... so that DC++ is the first choice for users on all major operation systems.

Valknut aka. dcgui-qt already did that (Linux,OS X, BSD and Windows version)

[PseudonympH]

I don't think you got the correct meaning out of that sentence. Read it again.

[Kiesus]

Hi. Sorry for my noobines in advance... I have compiled several different versions of this client from the CVS under Gentoo. Each time when i try to start the program, it just says Aborted and exits after saying "Loading Download gueue" and hashtable etc. (it loads 3 things and then says Aborted). I have compiled it under two different Gentoo installations, same thing. Yesterday i compiled it under Ubuntu and it worked, but my main distro is Gentoo so i wonder why it doesn't start under it :/

But it's really nice someone is finally porting DC++ for Linux. Soon i only need Windows for DVD rips and stuff

[TheParanoidOne]

That's the exact same thing that I see. Again, with Gentoo.

(Woohoo! I get to make a "Me Too!!!11" post. )

Having said that though, that was two weeks ago and the situation may have changed since then.

Are you currently in a position to provide support/feedback either to end users or potential developers? If so, in what form and where?

[paskharen]

is it possible to use wine just to emulate the client and only write the native gui?

I think this is entirely possible. I'm not sure it's something I want to do though, you have to put a lot of trust in wine not to be buggy for this. The more I think about it the more I realize this is actually quite a sensible option, and the reason I don't like it is mainly idealism.

Each time when i try to start the program, it just says Aborted and exits after saying "Loading Download gueue" and hashtable

I'm not 100% sure it's the same problem, but my co-developer is also running gentoo and he also had problems with the program aborting. I can't remember if it was on startup or not though. He got it working by playing with his locale settings, export LANG="en_US" for example. I'm quite sure there's something wrong in the prog wrt locale awareness and such because if this.
If you've used pre 0.4034 versions it might also help to delete the .dc++ dir in your home, since 0.4034 goes crazy if files there are not in utf-8.

Are you currently in a position to provide support/feedback either to end users or potential developers? If so, in what form and where?

Well, since the program is pretty useless currently I don't think we have any end users . For more developement related stuff (bug reports, compilation problems etc.) we are in the process of setting up a mailing list. Atm the only thing you can do is to email me though.

Update: mailing list at http://developer.berlios.de/mail/?group_id=2230

[timo]

I've been interested in doing some work on dcpp now i have some time. I had a look at http://linuxdcpp.berlios.de . Unfortunately i can't get it to compile (from CVS), make exits with an a g++:internal compiler error.. maybe i need to upgade gcc.

A couple of things about a port:
Maybe it should stick to plain gtk C libraries, I don't think gtkmm is much of an advantage, and it adds lots of dependancies. (The port i started used gtkmm aswell).

Not use STL port, but use std provided by gcc, I tried to use it also and had to use ugly hacks to convert Strings between the client code and gtkmm.

The Linux code in the /client part of dcpp has not been tesed and some of it is wrong (0434). Eg. in File.h it uses ftruncate to replace SetEndOfFile, they don't do the same thing.

[TheParanoidOne]

an a g++:internal compiler error.. maybe i need to upgade gcc.

Yes, you do. Read earlier on in the thread.

[tajisen]

How is the work going on on this project?

As I have mentioned before, I would like to see this (or something similar) being accepted as an official port and imported into main DC++ sourcecode. That way I belive the community will support both ports and more people working on patches (and so on). And a OSX port should be next (like the unofficial)...

Anyway, I just downloaded the CVS version and tested it. Still not usable, but I belive there is some more GUI work done. The only thing I don't like right now is the use of gtkmm, only because of all the extra library dependies. I am no expert, but I belive the regular GTK+ doesn't need those.


(click on image for bigger version)

Keep up the work, Linux/Unix needs a worthy DC client!

[joakim_tosteberg]

On that image I see that one character resolves t oa strange image, I've seeing that happen in my own client which I'm making for some characters like â„¢ is this because that they don't exists in the unix/linux os?

[paskharen]

one character resolves t oa strange image, is this because that they don't exists in the unix/linux os?

First of all, the image is dead so I might be compleatly wrong at this. But in my experience there can be two unicode issues:

Sometimes your font doesn't support the character that is to be displayed. (if it's a chinese char for example, and you don't have chinese fonts) Then you'll get a char that looks like a square with four little symbols in it. Or sometimes you'll get question marks, I'm not sure if they mean exactly the same or if there is some difference.

Sometimes you also get two weird chars instead of one normal, it looks something like ä. I'm not sure about this one, and it's a problem in our client... I think I've read a long time ago something about microsoft using a different utf8 than everybody else, but I'm not going to make any accusations without more proof. It could just be locale issues on our part as well.

Edit: Although ms were promoting a strange unicode version called UTC or something a few years ago there's nothing wrong with their current support for UTF8. We were just doing some stupid things in our app. I guess i should do my homework before posting but that goes against all tradition in internet forums

[tajisen]

First of all, the image is dead [...]

Sorry about that, I have installed a new server and did copy all users data exept my own to the new server
How many are doing developing work on this project now?

[paskharen]

How many are doing developing work on this project now?

Two main developers plus one who's about to join.

[Naga]

If you make any changes to the client part of DC++ do you send those changes back to Arne? Imho this would be a good thing since the client will be upp to date on linux too.

[paskharen]

We have sent some stuff to arne and will keep doing so in the future. The problem is that some of our fixes are a bit ugly at the moment so we haven't sent in everyting. Stuff we throw in just to get things working have no place in the main cvs, I don't think arne would accept them anyway so we would just make ourselves look stupid.

[tajisen]

Are your goals to try make such a qualityport of DC++ that it could be accepted as a official unix port in the feature when the project is mature?

[Twink]

We have sent some stuff to arne and will keep doing so in the future. The problem is that some of our fixes are a bit ugly at the moment so we haven't sent in everyting. Stuff we throw in just to get things working have no place in the main cvs, I don't think arne would accept them anyway so we would just make ourselves look stupid.

as long as the code is nice and compiles on both windows and linux i'm sure arne will accept it, he made the backend separate from the gui for just such a purpose.

[paskharen]

Are your goals to try make such a qualityport of DC++ that it could be accepted as a official unix port in the feature when the project is mature?

Our current plan is to implement enough features for a descent DC client, fix all the bugs and then make a release. (we're currently at the "fix all the bugs" stage ) After that we'll probably add more features but if we'll ever be feature complete with the windows client is very uncertain. But our goal is certainly to have the same quality as the windows version in the features we do implement.

[schmidt]

Im really interested in this port.
I've got the CVS just a day ago so I haven't really had time to test it fully.

Are there any kind of help needed ?

[paskharen]

Are there any kind of help needed ?

Apart from help writing code not really. We don't need that much code written at the moment either since we're trying to make some decisions about the future of the program (I'm thinking of dropping gtkmm and using plain gtk for example, although I'm not sure how much support that has with the others)

[schmidt]

Heh well C++ isnt my strong side (yet).