Source code | Direct Connect: Just These Guys, Ya Know?

Cross-compiling DC++ on Linux

August 12, 2007 by cologic Leave a comment

Just some notes:

If you use a binary-based distribution, don’t use the default STLport – that’ll have been compiled for the native platform, not Win32. Compile your own copy from source, however you do it.
Your distribution might have a MinGW cross-compiler already packaged and available. Debian, Ubuntu, and possibly RPM distributions (I don’t use any and thus can’t verify that). The Gentoo site is down, so I didn’t check.
The default MinGW filename prefix in build_util.py is i386-mingw32. You might need to adjust that, either by setting the MINGW_PREFIX variable or just editing build_util.py. For example, the correct prefix on my development system is i586-mingw32msvc.
On at least the versions of the MinGW runtime packaged with the Linux distribution I use, commdlg.h lacks the OPENFILENAME_SIZE_VERSION_400 constant (it’s 76 decimal) and winuser.h XBUTTON1/XBUTTON2 (VK_* and MK_* aren’t the same). Get the corrected header files from the official MinGW download site if necessary; they’re as portable as necessary.
Certain older versions of SCons on MinGW are vulnerable to a bug which DC++’s build system triggers. Either update SCons or apply the patch available if you experience that bug.
Finally, regardless of platform, using SCons’s —implicit-deps-unchanged option can dramatically speed up compiles if not too much has changed.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under Developers, General, Source code, Tutorial

TLS disabled, failed to generate certificate

August 6, 2007 by Fredrik Ullner 2 Comments

“TLS disabled, failed to generate certificate:” followed by “Failed to load certificate file” is probably something you’ve seen. Most people, almost frantically, think that DC++ is somehow broken. Well, it’s not.

The short answer to all this is; Ignore the message. If you don’t know what it means, just ignore it.

The medium length answer to all this is; Ignore the message. The message concern TLS, which is encryption on DC. I’ve in the past written about it (though, I’m not sure how outdated that post is). The TLS will only work on ADC hubs, which there are few of. And you’re most likely not on one of them. (Unfortunately, I might add.) So, you aren’t likely to need this anyway. Just ignore it.

The long answer to all this is; Ignore the message, unless you know what you’re doing. The first message come when DC++ tries to see if you have any certificates file entered in the settings for DC++. If you don’t have entered anything in the “Security Certificates” window, in the box “Private key file” or the “Own certificate file” box. (Or if they aren’t in their default DC++ folder, which they’re likely not when you’ve just installed DC++.) The second message come when you haven’t entered anything in the “Own certificate box”, or when there occur an error when using what’s inputted. (There’s a couple of things that could go wrong – I’m not confident to talk about any of them.) (The different messages are there because they mean different things.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Edit: I feel that I need to edit this post. The message have no effect on your ability to download or search. Consult the FAQ for such inqueries.

Filed under General, Security, Source code

Continue on with your break

August 2, 2007 by Fredrik Ullner Leave a comment

A really nifty feature in DC++ is the ability to change the priority of files in the download queue, with the keyboard. It’s quite simple, you just press ‘+’ or ‘-‘ on the numeric keyboard. When you select multiple files, all of them change priority.

At one point, however, selecting multiple files and changing the priority on them, didn’t really change the priority for some files. This appeared (at first) to happen randomly, but after a couple of minutes, the reason became more clear.

When you selected several files, that had different priorities, and pressed ‘+’ or ‘-‘ until one of the files reached “Highest” or “Paused”, the other files completely seized to update. You could try pressing 4, or 400, times more, but nothing would happen.

The buggy code was similar to what I’ve written below.
1. loop until the entire list of files have been looked at
2. if the selected file is in “highest” or “paused” mode, break to 4 and continue on
3. otherwise, change the priority and jump back to 1 and continue on
4. “do some other stuff that isn’t related to this…”

If you notice, the above “code” show exactly what the bug report said. The solution was quite simple, too; “change the 4 to a 1”.

Now you know what you’ve always (secretly) wanted to know about that priority bug.

(The reason “break” and “continue” is used here, is because the actual fix was to literally replace the code “break” with “continue”.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under General, Source code

UPnP file required for compiling

May 7, 2007 by Fredrik Ullner 1 Comment

At one point in time, DC++ added support for UPnP, which enabled DC++ an automagic configuration for active mode.

For accomplish this, a specific file in the source code was required. This file is called ‘natupnp.h’. I’m sure people have noticed it; the compile information mention this file and if you’ve attempted to compile DC++ without the file, the compiler would complain.

(Visual Studio 2005 have this file built in, but if you used Visual Studio 2003, you need this file in your includes.)

The compile information note that you can get the file in three ways; (1) To download the .NET SDK, (2) get it through our Bugzilla install (which is down, yes) and (3) by contacting someone of us and then we’d give it to you.

Unfortunately, this presents us with a problem. We might actually be in a pickle if we provide it for you directly because we don’t have permission by Microsoft to distribute it.

So to save us all some time and trouble, download the SDK provided by Microsoft and you’re all set.

(I don’t know if this file, or another one, is required for UPnP compilation with other compilers, other than Microsoft’s.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under Documentation, General, Source code

Interface change in upcoming versions

April 3, 2007 by Fredrik Ullner 3 Comments

A very large change in upcoming versions of DC++ is that the interface will change. Hopefully, the interface change will be transparent for users, and only be noticeable for developers.

So, what is changing? Well, the intent is to remove all of the WTL code, the code that handles the interface, and translate it to Smartwin code. The code is similar, but not exactly the same. This translation process will take quite a while, so you need to have patience.

The fact that DC++ is going to use Smartwin, instead of WTL, will mean that we will get rid of the dependancy for Visual Studio. DC++ will still be able to be compiled with VS, but you aren’t required to have it to compile DC++. From now on, one can compile DC++ with mingw. All in all, DC++ will be able to be compiled with completely free (of charge) tools. (Read compile.txt for specific instructions.)

No, Smartwin does not mean that one can natively run DC++ on Linux or Macintosh. Luckily, there’s projects like LinuxDC++ and MultiDC++, for respectively system.

If you are interested in translating the code in DC++, everything in “#ifdef PORT_ME” (and the corresponding “#endif”) is the old code that need to be translated.

If you have no idea what I’m talking about, let me put it this way; Every window in DC++ need to be re-written “from scratch”. (No, this does not mean that entire DC++ need to be re-written.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under General, Source code

Detecting your hub software

March 25, 2007 by Fredrik Ullner Leave a comment

There exist many hubs for NMDC, and for ADC. Although the amount of hubs supporting the former is greater, the latter is increasing.

As hubs get developed, they are intended for an audience, and the hub developer will try to market the software so more people will use the hub.

One of the market tricks hub developers use is that they will broadcast what the hub is called, when your client connect to the hub. You’ve seen it; “This hub is using DCH++” or some other type of message.

Though, the target audience is not just the normal users of the hub. It is also a hub list. The hub list can then, through either a website or the actual hub list file, broadcast what hub is being used. This is great advertisement, as the hub developer don’t need to do any active marketing.

However, the hub list isn’t composed of some guy in a basement manually typing the hub software used. Hub lists use programs to determine the hub software. This mean that the program need to look at a specific pattern to identify a hub.

When a client connects to a hub, the hub will broadcast the software. As we have two different protocols, we have two different methods of doing so. In NMDC, the hub list will check the $Lock the hub send. Respectively in ADC, the hub list will look at the VE parameter in the INF.

To do this effectively, Gadget (one of the people behind Hublist.org) published Visual Basic code to be able to parse the information in the lock, so it’s NMDC. But it shouldn’t be very difficult for you to replace the “$Lock” stuff with “VE” or some such. In the code, regular expressions are used, so you need to find the corresponding function in your language to do the same thing.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under Documentation, General, NMDC, Source code

LockToKey examples

March 14, 2007 by Fredrik Ullner 3 Comments

The DC++ wiki is down, so all you developers out there are out of luck. Until now… Well, at least for one thing;

The LockToKey examples. Since it’s quite a complicating thing to reverse engineer, here’s the examples that could be found through the wiki.

Note that I haven’t written any or have any knowledge about them.

Sorry about .doc, but WordPress didn’t allow .rar. Just rename the file to .rar. (The reason I’m not pointing to the cached Google page is because it might change over night.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under Source code

Time left: 584 million years

March 14, 2007 by Fredrik Ullner Leave a comment

In the upcoming version, there will be a fix for (as noted by the changelog) “time issues with DC++ running for more than 49 days”. This changelog entry mean that if you have your system for running more than 49 days, DC++ will most likely crash. This isn’t a new issue, it has existed for a while, though no one had gotten around to fixing it. (Though, fulDC has had it fixed a couple of versions.)

When the system starts, a specific variable is set that keep track of how long ago it was since your computer had started. When creating the variable, one must set its size as well. If you set the size of it to 100, and you assign the variable 102, the variable will overflow and nasty things will happen. This is also what has happened with DC++.

The size for this specific variable is 32-bit. This mean that the maximum size is 2^32, or 4294967296.

Like I said, this variable keep track of when the system was started, in milli-seconds. So if the variable would read 10000 it would mean that there have been 10 seconds since the start. Let us now convert the maximum amount of milli-seconds to maximum amount of days. This yeild; 4294967296 / 1000 / 3600 / 24 = 49,7102… days. Now look back on the changelog entry. It says 49 days, too.

So, if this is fixed, how is it fixed?

This is fixed by setting a new maximum size for this variable. “But… Then you’ll just end up having to fix that, too!” Well… That’s true. Sort of. If you’re planning on living for a couple of million years, that is.

The new maximum size is 64-bit. This mean that the maximum size is 2^64, or 18446744073709551616 milli-seconds. Let us convert this to days, again. 18446744073709551616 / 1000 / 3600 / 24 = 213503982334,6… days. Seems days aren’t enough. That’s 584942417,3 years. Yikes! OK, this mean that there’s 584 million years until DC++ will crash!

So you see, you don’t need to worry about this issue any more. :)

[If current DC++ crashes, and you restart it, your system will obviously still be running for more than 49.7 days. However, as the variable overflow, it is also reset, so you’ll have another 49.7 days until DC++ crashes again. Repeat ad infinitum.]

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under Documentation, General, Source code

DC++ like Visual Studio with a Service Pack

December 21, 2006 by Fredrik Ullner Leave a comment

When work on 0.699 begun, it was noted that it will require Visual Studio 2005 (or ‘8’) to be able to be compiled. When the DC++ version was complete, service pack one for Visual Studio had been released, and it is now a requirement for DC++’s entire feature set. DC++ will still be able to be compiled without the SP, but you will most likely encounter some warnings and weird crashes if you aren’t.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under General, Source code

We can always hope…

October 21, 2006 by Fredrik Ullner 2 Comments

In my last post, I talked about how you added a feature to the protocol and how you signal that you support it. However, you may have gotten the impression that you have to signal that you support something, but this is not true. Even if you support a particular feature, you don’t actually have to signal it.

Let me take an example. In NMDC, there is a distinction (well, not in the protocol, but by the hubs and clients) between “hub topic” and “hub description”. The hub description is used for when a hublist checks you hub, and then displays that description on their website or something. But “topic” is the name of the hub smashed together with the topic, separated with a “-“. (Yes, this is very ugly.) In ADC, there is also no way of saying “this is the topic”. However, due to ADC’s easily extensible interface, it is possible to have the hub send a parameter that isn’t in the base protocol, and one we don’t actually need to advertise we know (before we send it).

There are two possible things the hub can send, depending on whom should get it. Let us think about who would want a topic vs description. 1) the users in the hub or 2) a hublist bot.

To have 1), one would need to change all clients to accept a new parameter. Eg, “TP” (“ToPic”). The hub will then send NIthisismyname DEthis_description_should_be_used_for_hublists TPthis_is_some_random_topic. And if the clients doesn’t understand TP, then they’ll simply ignore it and use the DE-parameter as a topic. This solution’s main problem is that so many clients “need” to change its behaviour and accept TP. This is where 2) is better.

To have 2), one would “only” need to change all hublist bots. Eg, “HD” (“Hublist description”). The hub will then send, instead of TP as in the previous example, but HDsome_description_for_the_hublist. This solution is somewhat better then 1) because there aren’t that many hublist bots that need to be changed. (Heck, at the time of writing, I only know of one hublist bot for the ADC protocol anyway.)

However, the point here is that the hub/client doesn’t need to advertise it supports TP or HD (or any other command or parameter). The client/hub can just send the information, and hope (yes, hope) the other end understand it.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Filed under ADC, Documentation, General, Source code

← Older posts

Newer posts →