Advantages of using a C++ dll to do things, in a Visual Basic bot

[warz]

I was thinking about rewritting soup bot, due to the fact that my C++ gui version is old, unstable and needs a lot of tweaks. I do not, however, want to spend all the time I spent making my original one again. I accepted the fact that I won't be making another GUI client completely in C++ again, and decided to simply write my GUI in visual basic. I know a lot of bots use dll files written in C++ to do certain tasks, and to avoid being written "completely in visual basic," i guess. I was thinking, though, what would be worthy of being in the dll, instead of being written in vb and included in the bots code? What kind of things 'can' be put in the dll and still work better than just doing it in vb in the first place? I have a feeling if I did this, I'd end up with a pretty much pointless dll file, containing code I could have probably made just as well in vb.

What kind of things make this worth-while? What should be in my dll file?

[Spht]

I was thinking about rewritting soup bot, due to the fact that my C++ gui version is old, unstable and needs a lot of tweaks. I do not, however, want to spend all the time I spent making my original one again. I accepted the fact that I won't be making another GUI client completely in C++ again, and decided to simply write my GUI in visual basic. I know a lot of bots use dll files written in C++ to do certain tasks, and to avoid being written "completely in visual basic," i guess. I was thinking, though, what would be worthy of being in the dll, instead of being written in vb and included in the bots code? What kind of things 'can' be put in the dll and still work better than just doing it in vb in the first place? I have a feeling if I did this, I'd end up with a pretty much pointless dll file, containing code I could have probably made just as well in vb.

What kind of things make this worth-while? What should be in my dll file?

It's mostly a personal preference.  I've been doing a similar thing as what you described for a while now in my applications.  If I know how to write something in C that I don't in VB, or can write it more reliable/efficient, then I'll do it in the DLL.

If you know VB really well and run time isn't important for what you're doing, then it makes sense to do the entire thing in VB...

[warz]

Alright. I can't really think of anything that i'd feel the need to do in C, rather than VB, just yet. Maybe handling my packet data, or something.

[Sorc.Polgara]

Well, it's up to you like Spht said.  I wrote a DLL in C++ which contains functions for constructing the various BNCS packets.

Off the top of my head, an example of a prototype for a function I put in my C++ DLL is:

Code Select Expand


DWORD SidPing(LPSTR &outbuf);


This function constructs BNCS packet SID_PING (0x00), passes by reference the constructed packet and returns the size of the constructed packet.

I haven't tested my DLL to see if it works in VB though since I'm still a newb at writing DLLs and because I'm unfamiliar with how to write VB compatible C++ DLLs.

Anyways, it's up to you.

[MyndFyre]

Well, it's up to you like Spht said.  I wrote a DLL in C++ which contains functions for constructing the various BNCS packets.

Off the top of my head, an example of a prototype for a function I put in my C++ DLL is:

Code Select Expand


DWORD SidPing(LPSTR &outbuf);


This function constructs BNCS packet SID_PING (0x00), passes by reference the constructed packet and returns the size of the constructed packet.

I haven't tested my DLL to see if it works in VB though since I'm still a newb at writing DLLs and because I'm unfamiliar with how to write VB compatible C++ DLLs.

Anyways, it's up to you.

That's a pretty dangerous prototype!   

[Sorc.Polgara]

May I ask why so that I can fix it?

[MyndFyre]

sal.h:

Code Select Expand


    #define __readableTo(extent)
#define __nullterminated                    __readableTo(sentinel(0))


winnt.h:

Code Select Expand


typedef char CHAR;

typedef __nullterminated CHAR *NPSTR, *LPSTR, *PSTR;


The important thing is that LPSTR is typedef'd to char*.  char* expects strings to be null terminated.  Operations on this with Visual C++ 2005 will likely fail with the new security features built into the CRT.

The other thing is that LPSTR has no intrinsic way of ensuring that you're adding information.  A struct would be better, or a specialized class would be even better than that.

We always tell people not to handle their packet data as a string in VB.  Why would you do in C/C++, where you have typedefs, structs, and pointers?

[Sorc.Polgara]

cuz I'm noob


EDIT:  Thanks, will rewrite my whole DLL.