DCH++ advantages and disadvantages

DCH++ has been abandoned, this forum serves mainly as an archive

Moderator: Moderators

Locked
TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Re: DCH++ advantages and disadvantages

Post by TheParanoidOne » 2003-07-10 17:08

nErBoS wrote:Well I would like to now what are the advantages and disadvantages of this hub software !!
Disadvantage #1: It's not available. :D
nErBoS wrote:I would like to now all the opinios and if it is possible to me to test it !!
Beta testers...
The world is coming to an end. Please log off.

DC++ Guide | Words
Top
sandos
Posts: 186
Joined: 2003-01-05 10:16
Contact:
Contact sandos

Post by sandos » 2003-07-11 10:31

If someone makes a plugin for that. I doubt that extremely much though. (VBscript on linux, anyone?)
Top
GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-07-20 10:06

nErBoS wrote:It´s sad because the hub software would gain a lot supports if that plugin was made !!
Why? It supports LUA, and can run (as far as I know) all the plugins for the Ptokax software with some modification.

Heck, what you want to do might even be built into the hub. What things do you do with your VBScripts?
Top
GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-07-21 11:37

nErBoS wrote:It supports LUA, great them, I tought that this software would make a new line of plugins but if supports LUA, great then!
Well, the native plugins are C++ modules... However, one of the first ones written was a LUA plugin. If there's a viable VBScript interpreter for linux, you could probably write a plugin for that as well. And do the same thing for windows. That is, if you weren't satisfied with the LUA scripting facilities.

Share and Enjoy.
Top
Neimad
Posts: 8
Joined: 2003-01-09 16:08
Location: Midlands, UK

Post by Neimad » 2003-07-21 14:21

GargoyleMT wrote:Well, the native plugins are C++ modules...
I do hope that C++ (MS VC++, specifically) is not the only thing you can compile plugins for DCH++ in, otherwise that rather defeats the whole point of the plugin architecture in the first place.
Top
Sedulus
Forum Moderator
Posts: 687
Joined: 2003-01-04 09:32
Contact:
Contact Sedulus

Post by Sedulus » 2003-08-06 05:17

hm.. before replying to that,
could you tell me what it is you have problems with:

c++? i.e. you want to compile pascal/delphi/vb/c# plugins?
msvc++? i.e. you don't want to have to pay for software needed to build the plugins?

(and for the quick reply: the linux version needs gcc (which is not msvc++ :P ) or a compatible compiler, and C++ (including C) is the only language you can write in)
http://dc.selwerd.nl/hublist.xml.bz2
http://www.b.ali.btinternet.co.uk/DCPlusPlus/index.html (TheParanoidOne's DC++ Guide)
http://www.dslreports.com/faq/dc (BSOD2600's Direct Connect FAQ)
Top
arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-08-06 06:11

c++ (not c...) is the only language you can do plugins in, msvc++ in windows and gcc under linux...it would be possible to write a <name language/compiler here> adaptor plugin for the interested...
Top
Neimad
Posts: 8
Joined: 2003-01-09 16:08
Location: Midlands, UK

Post by Neimad » 2003-08-06 14:08

Sedulus wrote:hm.. before replying to that,
could you tell me what it is you have problems with:

c++? i.e. you want to compile pascal/delphi/vb/c# plugins?
msvc++? i.e. you don't want to have to pay for software needed to build the plugins?

(and for the quick reply: the linux version needs gcc (which is not msvc++ :P ) or a compatible compiler, and C++ (including C) is the only language you can write in)
The main reason to implement a plugin interface over a scripting interface, as I see it, would be extensibility and speed. Scripting interfaces are tied to a single, or small range of languages, and tend to be slow. A well written plugin architecture would not only be faster, it should permit more posibilities and enable extensions in a range of languages.

I have no problem as such, I simply feel that by tying the plugins to a specific compiler you are reducing the posible user-base of developers -- C, and C++ are not the easiest of languages to pick up, and MSVC++ is not the cheapest of compilers to come by. If you wanted to tie people to a specific language, you might as well have stuck with scripting.

arnetheduck wrote:c++ (not c...) is the only language you can do plugins in, msvc++ in windows and gcc under linux...it would be possible to write a <name language/compiler here> adaptor plugin for the interested...
No comment...
Top
beerdrinker
Posts: 1
Joined: 2003-08-01 16:52
Location: every where

Post by beerdrinker » 2003-08-06 16:41

hey guys i am new here and i need to know where the downloadfiles are thanks
have 2or 3 for the road
Top
TheParanoidOne
Forum Moderator
Posts: 1420
Joined: 2003-04-22 14:37

Post by TheParanoidOne » 2003-08-06 16:43

beerdrinker wrote:hey guys i am new here and i need to know where the downloadfiles are thanks
DCH++ has not been released yet, hence no download files.
The world is coming to an end. Please log off.

DC++ Guide | Words
Top
arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-08-07 07:25

Neimad wrote:The main reason to implement a plugin interface over a scripting interface, as I see it, would be extensibility and speed. Scripting interfaces are tied to a single, or small range of languages, and tend to be slow. A well written plugin architecture would not only be faster, it should permit more posibilities and enable extensions in a range of languages.

I have no problem as such, I simply feel that by tying the plugins to a specific compiler you are reducing the posible user-base of developers -- C, and C++ are not the easiest of languages to pick up, and MSVC++ is not the cheapest of compilers to come by. If you wanted to tie people to a specific language, you might as well have stuck with scripting.
You said it yourself, it's implemented for speed and extensibility, hence C++. A C interface would make it perhaps a bit more portable because it would work with other compilers (as c++ has no standard name mangling scheme preventing linking libs from other compilers) and would be easier to import to other languages, but the whole app is written in c++, so it's more appropriate with a c adaptor plugin for the needy and then a full speed solution in c++ for the pro's...
What do you suggest then? VB? =)
Top
Neimad
Posts: 8
Joined: 2003-01-09 16:08
Location: Midlands, UK

Post by Neimad » 2003-08-07 13:00

arnetheduck wrote:You said it yourself, it's implemented for speed and extensibility, hence C++. A C interface would make it perhaps a bit more portable because it would work with other compilers (as c++ has no standard name mangling scheme preventing linking libs from other compilers) and would be easier to import to other languages, but the whole app is written in c++, so it's more appropriate with a c adaptor plugin for the needy and then a full speed solution in c++ for the pro's...
Using the so called "fastcall" calling convention will buy you some speed, granted, but the overhead of exporting a set of OS-standard stdcall routines would be neglegable IMO. Yes, that means that classes are out, and that you have to resort to callbacks, etc. but again -- they aren't that in-efficient since Windows message loops (which handle thousands of messages a second) use them without grinding your system to a halt.

The other choice would have been interfaces, which would then have allowed you to use classes, albeit at the cost of some speed.

All in all, an MSVC++ specific plugin system wouldn't be that much more efficient than a cross-compiler version, and the latter would certainly benefit DCH++ plugin development more.
arnetheduck wrote:What do you suggest then? VB? =)
Erm... no ;)
Top
Locked

Return to “DCH++ General”