In attention to all DC++ developers!

SKIL · Post by **SKIL** » 2003-11-13 05:11

First of all, congratulations for developing this program, the most used in Romania!

I've noticed on your forum many topics complaining about compiling DC++. Besides "Get VC2003, i couldnt find other answers". Well, this should put you all to thoughts.

DC++ by its "kind" is a simple program. But the 102 .h files, 69 .cpp files in it's package plus the 320 files in stlport and v7, can drive even an expert developer out of his minds.

It gives me the sensation that it's a competition called "Who's writing the program with the maniest files!"

I know you will say that it's iligible, but the often compiling errors, prooves not! Why don't you make your program in a normal manner? Without the two v7 and stlport, and visual c++ 2003 support. What can be done there and cannot be done in visual c++ 6, or even visual c++ 5?

I think you should consider rewriting the program like a normal one, who uses sockets, and less in packages, a program who can be modified and developed easyly.

With Regards
SKIL

joakim_tosteberg · Post by **joakim_tosteberg** » 2003-11-13 05:24

Is it WTL 7.0 Package you mean then you say v 7 or is it vc7?
For now I assue it is wtl 7.0.
Do you really think the program should work if you just removed sstlport and wtl? There is reasons to why they are there.
If they are removed they must be replaced by something else and it would probably also be more work then you can imagine.
And the reason to why there are so many files is that there shuld be some order in the project. How do you want it to look? All code in less then ten files?
And for going back to visula c++ 5 or 6 NO.
Who knows how long time it will take until there will come os there this progs don't run? Will it be better to upgrade the project to a new compiler then, in the last second?

SKIL · Post by **SKIL** » 2003-11-13 07:06

Yes! I forgot it's name. It's WTL 7.0! OK.

I don't say the code it's buggy, it's even bug-free, but it's too extended. The number of files and compilation packeges requiered are suitable if you would have made a Operating System Kernel, not a program which is used for filesharing.

You should port it to VC6.0 and i shall tell you why!
programs compiled with VC2.0 on Windows 95 (1995) work fine now on my Windows 2003, i don't see what evolution should be necesary for you to keep in step with your compiler - with VC7.0. Probably in 2007 - 2008 (earlyest) programs made with VC6.0 won't work any longer! Until then STOP tormenting programmers with your bushy style of programming.

That's the biggest disease of Open Source, a disease that even DC++ suffers. Because it's hard to understand, and sometimes does not compile, some developers start to make from scratch their own versions of DC++, which is not good, because it may come up to many versions of DC++. If you'd arrange the code, remove the useless STLPORT and WTL and write the program as a single package guaranteed to compile on every PC in the world (or almost), I asure you that there will no longer be 50% of the posts on Programmer's Help posts entitled "Compiler Error!"

I hope I made myself understood!
With Regards!
SKIL

Gratch06 · Post by **Gratch06** » 2003-11-13 12:03

Wow...my apologies, but you're an idiot. Porting backwards is simply not going to happen. Wtlport and stlport provide valuable utilites to the program in a packaged form that would otherwise have to be manually written exclusively for DC++, which would be an incredibly stupid waste of developers' time. C++ is built around the concept of modularization, and arne has done well in keeping the program VERY logically organized, using external classes and libraries where they are appropriate. When modding the DC++ program, a developer should only have to touch the files in the actual DC++ project, and nothing in the stlport or wtlport.

SKIL wrote: I asure you that there will no longer be 50% of the posts on Programmer's Help posts entitled "Compiler Error!"

hmm..I think this would be better solved by putting a big bright red circle around the Search button at the top of the forums. I've had a number of compiling issues and errors with DC++. I've been able to solve most of them through the search.

I'm sorry, but go play elsewhere if DC++ is too big and scary. Also, no one with the skill to build a new DC client from scratch is going to be boggled for very long by simple compiler errors.

Post by **GargoyleMT** » 2003-11-13 12:10

SKIL wrote:F've noticed on your forum many topics complaining about compiling DC++. Besides "Get VC2003, i couldnt find other answers". Well, this should put you all to thoughts.

You should have found a few more answers than that:

If you're using VS6, common problems are project files that are missing files added since VS6 support was dropped. Also, a Platform SDK of November '01 or newer is necessary. There are a few cases where variables need to be renamed (due to the C++ compiler in VS6 not properly localizing variables). The latter issue should not be the case with 0.301.

DC++ by its "kind" is a simple program. But the 102 .h files, 69 .cpp files in it's package plus the 320 files in stlport and v7, can drive even an expert developer out of his minds.

It gives me the sensation that it's a competition called "Who's writing the program with the maniest files!"

If you want to understand DC++, you do not have to understand all of the STLPort or WTL 7.0.

Perhaps you'd be better off with eMule, which only has 189 .h, 4 .hpp, and 153 .cpp files.

I know you will say that it's iligible, but the often compiling errors, prooves not! Why don't you make your program in a normal manner? Without the two v7 and stlport, and visual c++ 2003 support. What can be done there and cannot be done in visual c++ 6, or even visual c++ 5?

The existence of compiling errors only means that you have not properly set up stlport and wtl, or that you are using a non-standards compliant C++ compiler. Visual C++ .NET and .NET 2003 are much more compliant with the C++ standard than VC6 or VC5. This means there are less pre-processing kludges to get around compiler specific behaviors.

I think you should consider rewriting the program like a normal one, who uses sockets, and less in packages, a program who can be modified and developed easyly.

I believe that once you're familiar with the source code, you will see that DC++ can be modified and added onto easily, precisely because of its modularity.

I don't say the code it's buggy, it's even bug-free, but it's too extended. The number of files and compilation packeges requiered are suitable if you would have made a Operating System Kernel, not a program which is used for filesharing.

Please see my reference to the eMule source code above.

You seem to be quite mistaken about the size of the project - the DC++ source is 3 megabytes or so uncompressed. The 2.4.21 Linux kernel, on the other hand is:

Code: Select all

linux-2.4.22.tar.gz  	35770 KB  	8/25/2003  	11:44:00 AM

35 megabytes or so, compressed.

You should port it to VC6.0 and i shall tell you why!
programs compiled with VC2.0 on Windows 95 (1995) work fine now on my Windows 2003, i don't see what evolution should be necesary for you to keep in step with your compiler - with VC7.0. Probably in 2007 - 2008 (earlyest) programs made with VC6.0 won't work any longer! Until then STOP tormenting programmers with your bushy style of programming.

VS6 support is on its way out... DC++ is currently compiled with .NET 2003, and this will also mean that standards compliant compilers will be much more happy with the code. If you cannot get the current DC++ 0.301 source code to compile, it's not for lack of help in this forum.

"Bushy" is pretty amusing, but you seem to be ranting here, not arguing coherently.

That's the biggest disease of Open Source, a disease that even DC++ suffers. Because it's hard to understand, and sometimes does not compile, some developers start to make from scratch their own versions of DC++, which is not good, because it may come up to many versions of DC++. If you'd arrange the code, remove the useless STLPORT and WTL and write the program as a single package guaranteed to compile on every PC in the world (or almost), I asure you that there will no longer be 50% of the posts on Programmer's Help posts entitled "Compiler Error!"

The errors here are indeed because DC++ requires STLPort and WTL. WTL is used for the graphical user interface. If you remove it, you have to come up with an alternative. If you port it to MFC (Microsoft Foundation Classes), I believe you would see changes for the worse in speed and code size. STLPort is necessary at the moment because of a discrepancy in how hash_maps are handled in the C++ Standard (ie. they're not in it, AFAIK), STLPort, and the .NET 2003 STL implementation.

There is no problem with DC++ forks. No author I've seen has taken it upon himself to simplify DC++. I think you're mistaken that programmers even believe it it too complicated. All the forks I've seen are to add features DC++ lacks, or that Arne has stated will not be added.

Your posts both seem like you had errors when you tried to compile DC++ with Visual Studio 6, and failed. You then decided to rant, in length, on the source code... This is not cool. Just ask your question, and we'll try to help. The source code is not the problem.

(Edit: spelling)

SKIL · Post by **SKIL** » 2003-11-13 14:08

Yes! You seem to be right, but on the developer side. If I would have been a developer of a software, I would have answered the same thing.

The problem is:
1) What was the problem with MFC? Wasn't it just good enough for you? Was it too hard/buggy to use, so you decided to reinvent the wheel and start creating another interface to help you?
2) Emule compiles excelent. I even started to understand some things about the way it works ...
3) Not the number of files in the project concers me, but the code optimization itself. Why can't it be as simple as normal Windows Socket program?
4) I think that following blindly a new developing software, such as VC7.NET 2003, is a bad thing, a trap in which many developers fall into. I have worked with VC7, but VC6 seems to be like a friend for me now. A friend in which can guarantee me that a 9800 line program (10 files) will compile and run on every pc with VC6 and Windows.
5) VC7 is the future, but not now, and you seem not to understand this. But, your program does not need it. Your program does not need features that are NEW in VC7 and in VC6 they couldn't be developed.
6) Compiling your project to the linux kernel was a kind of comparation, not an equal.

I just want you to think about the direction your developing is going, because "GET VC7" is not the answer. If tomorow Microsoft will develop a new version called VC8, it's no wonder that in two or three days, I will se your sources entitled as ready for VC8.

bux · Post by **bux** » 2003-11-13 14:17

Regarding the stlport thing...
Is it only hash_map that are used in stlport (and ofcourse the other stuff like vector etc)?
I mean if hash_map was in the C++ standard then stlport would not actually be needed?
If so, why not make a hash_map for DC++ and skip stlport?

Post by **GargoyleMT** » 2003-11-13 14:22

Although I'm a DC++ coder, I do not blindly follow Microsoft. .NET and .NET 2003 are more standards compliant, and that's a big reason to use them. If .NET 2004 comes out tomorrow, Arne will not jump on the Microsoft bandwagon.

If you look at the structure of DC++, you will see that it's designed to be portable to other operating systems. This separation causes certain design choices, which you may or may not be railing against.

cologic · Post by **cologic** » 2003-11-13 14:32

1) What was the problem with MFC? Wasn't it just good enough for you? Was it too hard/buggy to use, so you decided to reinvent the wheel and start creating another interface to help you?

MFC is large (look at the size of the binaries it generates), and no easier to use than WTL. Further, WTL isn't a reinvention by the DC++ author, so much as an alternative GUI framework offered by Microsoft.

Since you're concerned about superfluous reinvention of code, I should probably point out that ATL does this far, far less than MFC, as it can rely on C++'s template features to ease its implementation greatly, as well as to create a more typesafe style of programming.

2) Emule compiles excelent. I even started to understand some things about the way it works ...

That's great.

3) Not the number of files in the project concers me, but the code optimization itself. Why can't it be as simple as normal Windows Socket program?

What's a normal Windows socket program?

4) I think that following blindly a new developing software, such as VC7.NET 2003, is a bad thing, a trap in which many developers fall into. I have worked with VC7, but VC6 seems to be like a friend for me now. A friend in which can guarantee me that a 9800 line program (10 files) will compile and run on every pc with VC6 and Windows.

Uh, great. VS6 is your friend. How does this relate to DC++ again?

5) VC7 is the future, but not now, and you seem not to understand this. But, your program does not need it. Your program does not need features that are NEW in VC7 and in VC6 they couldn't be developed.

VC++ 7.1 is significantly more standards-compliant than previous releases of VC++; it allows code to be written portably with fewer ugly hacks, and is a valuable feature to have indeed.

A particularly irritating behaviour of VS6 is its inability to create symbol names longer than 255 characters, for example: if you look at dcplusplus.h, there's a #pragma to disable that warning. Such is the price of using broken compilers.

6) Compiling your project to the linux kernel was a kind of comparation, not an equal

And?

Opera · Post by **Opera** » 2003-11-13 16:35

This gotta be a joke... A bad - really bad - joke.

If not then a few things comes to my mind, such as;

Who do you think you are, SKIL? Telling others how they should structure their work? You don't even seem to be familiar with the code, so the background information required to give such a statement is missing and renders the issue is irrelevant.

And how stl and wtl can be bothering You is more than weird. They are Simple to include in the search path of vs, and they are free to use, and doesn't come with loads of dll's nor a certain increase of size.
Actually microsofts built-in stl-version (which works for sure, I personally use it in my dc++ mod) increases the size of the executable.
Replacing WTL with MFC causes several issues on availability through operating system versions. You might not've run into this, but I have, several times. And that problem, user-side, without the source in most cases are a bigger nightmare than compiling dc++. Also there are the issues cologic stated. WTL even increases the chance of someone succeeding in compiling this on other compilers. I bet porting dc++ to a borland compiler ain't impossible.

But all this is actually reasonless to say, since you should http://www.stfu.se and just enjoy the open source that is givven to you, on a silver plate. Served with silver spoons, yes they are.

bux: About the hash_map.. They are not defined within STL so you could say they are "luckily" included anyway, both in stl-port and in the vs.net-built-in stl. Changing the behaviour to use map instead of hash_map will solve most of it's problems, even though you should consider it a temporary hack.

O

Qbert · Post by **Qbert** » 2003-11-13 19:11

DC++ by its "kind" is a simple program. But the 102 .h files, 69 .cpp files in it's package plus the 320 files in stlport and v7, can drive even an expert developer out of his minds.

I'm assuming by your statement that you are claiming yourself as an expert developer; however your reason is quite contrary. May I ask if you have ever worked on a project outside of a school/college?

It gives me the sensation that it's a competition called "Who's writing the program with the maniest[SP] files!"

With this added statement, I am again to believe that you are not a professional programmer; but I do not mean to insult you. If you tried to create a list, which I think would be hard to prove, I think that DC++ wouldn't even get ranked before you quit.

If you'd arrange the code, remove the useless STLPORT and WTL and write the program as a single package guaranteed to compile on every PC in the world (or almost), I asure you that there will no longer be 50% of the posts on Programmer's Help posts entitled "Compiler Error!"

STLPORT is just a template library, and is a very useful template library when writing C++ code. I think almost all compilers come included with one. Microsoft for its couple lastest versions of Visual C++ have an STL made by some Duwamish[SP] company or similar sounding. (I do not recall the company name.) I also believe that Borland has chosen to use STLPORT as its STL library for its past versions. If you took STLPORT out of Borland, many programs would fail. I personally believe STLPORT is currently a bit better than the implementation that Microsoft chose, and thats why people use it. My point: please realize than your Visual C++ compilers use an STL, and if you take that out, you may have made your work harder for yourself. I think you simply made note of STLPORT because its distributed along with DC++, whereas most programs you may be aware of are not distributed with an STL; they simply use whichever variant you have, which is not following good standards. In either case, any given code would not compiler/run the same on every PC in the world if you used features in an STL that did not have the same behavior in another.

You should port it to VC6.0 and i shall tell you why!
programs compiled with VC2.0 on Windows 95 (1995) work fine now on my Windows 2003, i don't see what evolution should be necesary for you to keep in step with your compiler - with VC7.0. Probably in 2007 - 2008 (earlyest) programs made with VC6.0 won't work any longer!

5) VC7 is the future, but not now, and you seem not to understand this. But, your program does not need it. Your program does not need features that are NEW in VC7 and in VC6 they couldn't be developed.

I recently read a C++ compiler comparison from Dr. Dobb's Journal. VC7.1 is indeed needed if you want to use the correct STLPORT. Only 7.1 has template partial specialization, which is needed. If a new version of compilers comes out, I would definately gear towards it, because I've yet to hear of a compiler that is full 100% compliant with standards. If any, the current GCC would be the best as far as I understand. So if you're not using GCC, then your compiler could and should be upgraded.
To elaborate on features that VC6 does not have as outlined by Dr. Dobb's Journal #255 December 2003 and Novemeber 2003: wchar_t keyword, new for scoping rules, typename (qualifier in template default parameter), template partial specialization and template templates.

SKIL · Post by **SKIL** » 2003-11-14 16:08

Let's say you try to prove the sourcecode ease of understand. OK. You're right. I don't like to argue with people with a closed angle view!

This remids me of the script kiddies, who make vb aplications, add 10 or more OCX, they don't care about the version of OCX, eventualy they let the controls named by default, such as command1

, and they compile it and they claim to be superprograms. That's almost how dc++ started, but as far is it, it's imposible to keep under control. Let's compare it with Nazism and Comunism. You should be proud of this comparation.
Multi system porting? Is dcgui the version for DC++ for Linux? If yes, it SUCKS! A great compilable, and easy to understand is called quickdc 0.7 alpha. I invite all linux users use it, and sooner or later you will realize that this will beat DC++. With the trolltech libraries, it compiled easily on Windows. It's just a pleasure:

1) Compact Code
2) Easy to understand
3) No VC2003.NET component.

I currently use quickdc, which is the best among DC++, oDC, and some other small compiled DC++ CLONES.

cologic · Post by **cologic** » 2003-11-14 17:05

Surely you meant something more like:

Let's say you try to prove the sourcecode ('source code' is two words.) easy to understand. OK. You're right. I don't like to argue with people with a closed angle (I don't think this is quite the expression for which you're looking. Perhaps 'closeminded' accurately conveys your intended idea?) view!

This remids (reminds) me of the script kiddies, who make vb ('VB' is an acronym and as such should be completely capitalized) aplications (applications), add 10 or more OCX (OCX is singular, whilst more than 10 of a non-collective noun implies the usage of its plural form), (right here, you commit a comma splice error; you need a conjunction such as 'and') they don't care about the version of OCX (I believe you're referring to the specific OCXes used by the application, but your phrasing seems to refer to the OCX standard itself), (You commit another comma splice error here, and as such need another conjunction. Note, however, that chaining together too many 'and's, 'or's, and such within a single sentence becomes quickly unwieldy, and one should thus look towards alternative organizations of one's thoughts.) eventualy (eventually) they let the controls (You're missing a verb here, such as 'be' or 'become'. However, even with said verb included, this would likely remain a awkwardly formed sentence.) named by default, such as command1 , and they compile it and they (Surely you mean that the programmers claim their programs to be superprograms, not that they themselves claim to be superprograms.) claim to be superprograms. That's almost how dc++ (This is capitalized: 'DC++') started, but as far is it (As far as I can tell, you're groping blindly for some construction along the lines of 'as far as it's come', 'in its current state', or 'by now'), it's imposible ('impossible') to keep under control. Let's compare it with Nazism and Comunism (Marx and Engels would be disappointed that you misspelled their political philosophy of Communism). You should be proud of this comparation ('comparison').

Multi system ('multi' doesn't stand on its own as a word; either hyphenate this to become 'multi-system' or concatenate them into one word: 'multisystem') porting? Is dcgui the version for DC++ for Linux? If yes, it SUCKS! A great compilable (You're missing a noun (and a comma) here. Do you mean 'program'?), and easy to understand (Again, you're missing a noun, and probably the same one as previously.) is called quickdc (Since you so clearly appreciate the author's work, show this by capitalizing his software's name correctly as 'QuickDC') 0.7 (You're probably referring to version 0.0.7, not 0.7) alpha. I invite all linux ('Linux' is a proper noun, and as such should be capitalized.) users use it, and sooner or later you will realize that this will beat DC++. With the trolltech (Trolltech is another proper noun demanding capitalization.) libraries, it compiled easily on Windows. It's just a pleasure:

1) Compact Code
2) Easy to understand
3) No VC2003.NET component.

I currently use quickdc (I have the same comment here about the capitalization of QuickDC.), which is the best among DC++, oDC, and some other small (There should be a comma here.) compiled DC++ CLONES(Why is 'clones' capitalized?).

joakim_tosteberg · Post by **joakim_tosteberg** » 2003-11-15 01:49

How many grammatic errors was it in that text?

SKIL · Post by **SKIL** » 2003-11-15 15:21

joakim_tosteberg wrote:How many grammatic errors was it in that text?

Not more than DC++ compilation errors!

Qbert · Post by **Qbert** » 2003-11-15 15:57

Not more than DC++ compilation errors!

Thats odd. From the latest released source I don't get any errors.

SKIL · Post by **SKIL** » 2003-11-16 06:08

Qbert wrote:
Not more than DC++ compilation errors!
Thats odd. From the latest released source I don't get any errors.

Of course you didnt! You probably have VC7!

SKIL · Post by **SKIL** » 2003-11-16 08:36

Guess what I have found today. DC++ v. 303. And you know what's great? VC6 is no longer supported. This is unacceptable.

joakim_tosteberg · Post by **joakim_tosteberg** » 2003-11-16 08:57

SKIL wrote:Guess what I have found today. DC++ v. 303. And you know what's great? VC6 is no longer supported. This is unacceptable.

It's not unacceptable and it does probably save arne some work and it does make the download smaller.

Post by **GargoyleMT** » 2003-11-16 10:20

SKIL wrote:Guess what I have found today. DC++ v. 303. And you know what's great? VC6 is no longer supported. This is unacceptable.

Yes, it is no longer supported, the DC++ sources do not come with VS6 project files. If you look at the number of users asking for support on VS6 and compare that to VS7 or VS7.1, there's a big difference. Too many people ask for support in doing exactly the things that compile.txt says you have to do to compile on VS6. These people do not seem to be able to fix their own problems. Because of this, I was one person who suggested dropping VS6 support to Arne (it was before the beginning of this thread).

DC++ can still be made to compile with VS6, but you're on your own.

If you haven't noticed, Microsoft also dropped support for Windows 95 - it still runs, but you won't get any new security patches.

If you want to pay me for a copy of VS6 and a small fee ($50) each time a new DC++ comes out, I'll be happy to provide keep DC++ VS6 compatible. This is something I normally do not care about as I own VC++ .NET 2003 (and as previously mentioned, it is very standards compliant).

Hell-razor · Post by **Hell-razor** » 2003-11-16 11:50

SKIL wrote:Guess what I have found today. DC++ v. 303. And you know what's great? VC6 is no longer supported. This is unacceptable.

Nobody is forcing you to use DC++.
It's not like someone is pointing a gun at your head and ordering you to use DC++.

So why do you still use DC++ ?

HaArD · Post by **HaArD** » 2003-11-16 19:23

SKIL wrote:2) Emule compiles excelent. I even started to understand some things about the way it works ...

You should take your own advice and switch to E-mule. I'm sure you could put your SKILls to good use there.

IamOne · Post by **IamOne** » 2003-12-05 21:01

joakim_tosteberg wrote:Who knows how long time it will take until there will come os there this progs don't run? Will it be better to upgrade the project to a new compiler then, in the last second?

WHAT? Microsoft is not that stupid...
i'm still running 16bit win 3 someting on my XP home

ok, but seriously.. for what reason is VC6 not supported any more? what programming/code problem did you have to solve by using new version?

Twink · Post by **Twink** » 2003-12-05 21:50

yeah microsoft aren't stupid, thats why they improved their visual studio packages alot in the last two releases, so much so that backwards compatibility is a burden as the older compiler doesn't support the nice things in the new ones (and they're way more ansii complient now too

) Dropping support for VC 6.0 was not a bad move, you can always get an older version of the project files and just add the new files to it, probably will take a bit of effort before it compiles thou.

Post by **GargoyleMT** » 2003-12-08 13:57

IamOne wrote:ok, but seriously.. for what reason is VC6 not supported any more? what programming/code problem did you have to solve by using new version?

Was this answer not up to snuff?

GargoyleMT wrote:Yes, it is no longer supported, the DC++ sources do not come with VS6 project files. If you look at the number of users asking for support on VS6 and compare that to VS7 or VS7.1, there's a big difference. Too many people ask for support in doing exactly the things that compile.txt says you have to do to compile on VS6. These people do not seem to be able to fix their own problems. Because of this, I was one person who suggested dropping VS6 support to Arne (it was before the beginning of this thread).

DC++ can still be made to compile with VS6, but you're on your own.

The VS6 project files were out of date and standards compliant C++ code had to be changed to compile on it (not properly respecting the locality of variables used in loops, for sure). (I'm not sure arne even has VS6 installed.) The STL implementation in .NET 2002 and 2003 are finally good enough that they can be used in DC++, the same cannot be truthfully said of VS6's implemenation.

What does continuing VS6 support gain DC++?

IamOne · Post by **IamOne** » 2003-12-08 16:01

GargoyleMT wrote: The VS6 project files were out of date and standards compliant C++ code had to be changed to compile on it (not properly respecting the locality of variables used in loops, for sure). (I'm not sure arne even has VS6 installed.) The STL implementation in .NET 2002 and 2003 are finally good enough that they can be used in DC++, the same cannot be truthfully said of VS6's implemenation.

What does continuing VS6 support gain DC++?

what? you never used VS6 STL, stlport's what u used iirc.

but OK, I respect your decision, BUT.. I won't be compiling this project any time soon

Post by **GargoyleMT** » 2003-12-08 17:12

IamOne wrote:what? you never used VS6 STL, stlport's what u used iirc.
but OK, I respect your decision, BUT.. I won't be compiling this project any time soon

If you can code in C++, one would hope you can figure out how to forward port the project files from an older DC++ version if you need to use VS6.

This hand holding is one of the things I've repeated a couple times now.

IamOne · Post by **IamOne** » 2003-12-09 07:45

GargoyleMT wrote: If you can code in C++, one would hope you can figure out how to forward port the project files from an older DC++ version if you need to use VS6.

yeah, I probably could. But that's not something i'm going to spend my time on right now.

Qbert · Post by **Qbert** » 2003-12-09 22:14

GargoyleMT wrote: If you can code in C++, one would hope you can figure out how to forward port the project files from an older DC++ version if you need to use VS6.

IamOne wrote:yeah, I probably could. But that's not something i'm going to spend my time on right now.

Well considering it would take less than 1/100th of the time to add files and simple configuration steps for you to get it in VS6 than any average ammount of time adding a feature or locating a bug in DC++, then I guess it didn't loose much.

Edit: Fixed your quotes //joakim_tosteberg

In attention to all DC++ developers!

In attention to all DC++ developers!

Re: In attention to all DC++ developers!