251 replies to this topic

[sabriath]

**BETA** v0.1.3
http://www.host-a.net/u/sabriath/net39_lic.zip

**BETA** v0.1.4 (not compatible with v0.1.3)
http://www.host-a.net/u/sabriath/net39.zip

Mods: If this is in the wrong place, my apologies. I am currently in the middle of making hopefully the best network library. Although this is in a non-working order, it is a work-in-progress and would like help from the community if they are able. I have asked the mods to move this to the DLL extension forum section, as this has reached a stage where it mostly works, but still needs thorough testing and I am still adding more and more features. Thank you

Written in Code::Blocks targetting vsc++2008

{2011:1-1}
http://www.host-a.net/u/sabriath/net39_lic.zip

A new year, and a new plan for the format of this topic. I will begin striking out old "journal" type updates and deleting them over time, no need looking to the past anymore. I will however keep 3 lists inside spoiler tags, 1 will contain a revision log (with as little description of changes for each build) and the others will contain the full list of functions and constants. There is no point in explaining each function, I will write a tutorial specifically designed for that purpose, I don't want to bog down this topic with it. The package contains the license, revision log, source code, dll (debug build), gex extension file, and an example gmk file. Eventually even this journal log will be absorbed into the new order of things, and only important items will be left....

Please feel free to post comments, suggestions, questions, help, bugs, etc. Thank you!

Last File Push: 2011-01-19
Revision:

Spoiler

2011 01 19 [0.1.4]
2011 01 19 [0.1.3:r25] 'NetTest.gmk' file created, UDP not working as planned
2011 01 18 [0.1.3:r24] .gex file updated
2011 01 18 [0.1.3:r23] Values functionally separated, types removed
2011 01 18 [0.1.3:r22] 'Message' files and relative works removed
2011 01 18 [0.1.3:r21] 'gmexports' reworked
2011 01 18 [0.1.3:r20] 'File' buffer read/write functions done
2011 01 18 [0.1.3:r19] 'File' reworked to look similar to buffer, bit streaming as well
2011 01 18 [0.1.3:r18] 'Buffer' switched members back to private, reworked the functions
2011 01 18 [0.1.3:r17] 'gmcharret' files created for returning strings back to GM
2011 01 15 [0.1.3:r16] 'Buffer' switched all members to public because of export conflicts
2011 01 15 [0.1.3:r15] 'main' files reworked
2011 01 14 [0.1.3:r14] 'gmexports' files started
2011 01 14 [0.1.3:r13] 'Socket' files reworked
2011 01 14 [0.1.3:r12] 'list' resize syntax error fixed (thanks Krisando)
2011 01 13 [0.1.3:r11] 'Message' files reworked
2011 01 13 [0.1.3:r10] 'Buffer' files reworked
2011 01 12 [0.1.3:r9] 'File' files reworked
2011 01 02 [0.1.3:r8] All constants in .gex file have been changed
2011 01 01 [0.1.3]
2011 01 01 [0.1.2:r7] _send split into _send for streams and _sendto for dgrams
2011 01 01 [0.1.2:r6] Added SOCKET_OPT_SIZEWAIT option for TCP streams
2011 01 01 [0.1.2:r5] SOCKET_OPT_MAPPED and SOCKET_NOPT_MAPPED defines populated
2011 12 31 [0.1.2]
2010 12 31 [0.1.1:r4] Added some support for linux, unable to test
2010 12 31 [0.1.1:r3] SOCKET_STATE_UDP_CONNECTING and SOCKET_STATE_UDP_CONNECTED states now properly ignore 0xFF pings
2010 12 31 [0.1.1:r2] 'Socket' class can now be mapped for instance IDs and will queue MSG_RECVMAP for it
2010 12 31 [0.1.1:r1] Created 'Group' feature
2010 12 29 [0.1.1:r0] Beta release

Constants v0.1.4 (note: not all are actually used):

Spoiler

ERR_ADDRESS
ERR_BIND
ERR_BLOCK
ERR_CFAIL
ERR_DNE
ERR_EXISTS
ERR_FAIL
ERR_FCLOSE
ERR_LISTEN
ERR_NOTBUFFER
ERR_NOTFILE
ERR_NOTLISTEN
ERR_NOTSOCKET
ERR_PROTOCOL
ERR_READNEED
ERR_RECV
ERR_SEND
ERR_SOCKET
ERR_TIMEOUT
ERR_WRITENEED
FAIL
pTCP
pUDP
SUCCESS

Constants v0.1.3:

Spoiler

SUCCESS
ERR_BAD_TYPE
BUFFER_ERR_NOTBUFFER
FILE_ERR_NOTFILE
FILE_ERR_FAIL
FILE_ERR_DNE
FILE_ERR_EXISTS
FILE_ERR_READNEED
FILE_ERR_WRITENEED
SOCKET_ERR_NOTSOCKET
SOCKET_ERR_SOCKET
SOCKET_ERR_BIND
SOCKET_ERR_LISTEN
SOCKET_ERR_BADTYPE
SOCKET_ERR_ADDRESS
SOCKET_ERR_BLOCK
SOCKET_ERR_NOTLISTEN
SOCKET_ERR_RECV
SOCKET_ERR_SEND
SOCKET_ERR_TIMEOUT
SOCKET_ERR_CFAIL
SOCKET_ERR_FCLOSE
GROUP_ERR_NOTGROUP

MSG_NONE
MSG_ERR
MSG_ACCEPT
MSG_CONNECT
MSG_RECV
MSG_RECVMAP

SOCKET_TYPE_UDP
SOCKET_TYPE_TCP

VALUE_TYPE_BYTE
VALUE_TYPE_SHORT
VALUE_TYPE_USHORT
VALUE_TYPE_INT
VALUE_TYPE_UINT
VALUE_TYPE_FLOAT
VALUE_TYPE_DOUBLE
VALUE_TYPE_ERR
VALUE_TYPE_IID
VALUE_TYPE_SOCKET

Functions v0.1.4:

Spoiler

net_buffer_create
net_buffer_destroy
net_buffer_clear       (id)
net_buffer_expand      (id, bytes)
net_buffer_grow        (id, bytes)
net_buffer_shrink      (id)
net_buffer_getread     (id)
net_buffer_getwrite    (id)
net_buffer_getleft     (id)
net_buffer_getsize     (id)
net_buffer_setread     (id, pos, rel)
net_buffer_setwrite    (id, pos, rel)
net_buffer_readbits    (id, bits)
net_buffer_readchar    (id)
net_buffer_readbyte    (id)
net_buffer_readushort  (id)
net_buffer_readshort   (id)
net_buffer_readuint    (id)
net_buffer_readint     (id)
net_buffer_readfloat   (id)
net_buffer_readdouble  (id)
net_buffer_readchars   (id, len)
net_buffer_readstring  (id)
net_buffer_readbstring (id)
net_buffer_readwstring (id)
net_buffer_writebit    (id, val, bits)
net_buffer_writechar   (id, val)
net_buffer_writebyte   (id, val)
net_buffer_writeushort (id, val)
net_buffer_writeshort  (id, val)
net_buffer_writeuint   (id, val)
net_buffer_writeint    (id, val)
net_buffer_writefloat  (id, val)
net_buffer_writedouble (id, val)
net_buffer_writechars  (id, string, len)
net_buffer_writestring (id, string, len)
net_buffer_writebstring(id, string, len)
net_buffer_writewstring(id, string, len)
net_buffer_append      (dest id, src id)

net_file_new         (filename, mode)
net_file_open        (filename, mode)
net_file_close       (id)
net_file_getpos      (id)
net_file_getsize     (id)
net_file_getleft     (id)
net_file_setpos      (id, pos, seek)
net_file_readbit     (id, bits)
net_file_readchar    (id)
net_file_readbyte    (id)
net_file_readushort  (id)
net_file_readshort   (id)
net_file_readuint    (id)
net_file_readint     (id)
net_file_readfloat   (id)
net_file_readdouble  (id)
net_file_readchars   (id, len)
net_file_readstring  (id)
net_file_readbstring (id)
net_file_readwstring (id)
net_file_readtobuffer(id, buffer id, len)
net_file_writebit    (id, val, bits)
net_file_writechar   (id, val)
net_file_writebyte   (id, val)
net_file_writeushort (id, val)
net_file_writeshort  (id, val)
net_file_writeuint   (id, val)
net_file_writeint    (id, val)
net_file_writefloat  (id, val)
net_file_writedouble (id, val)
net_file_writechars  (id, string, len)
net_file_writestring (id, string, len)
net_file_writebstring(id, string, len)
net_file_writewstring(id, string, len)
net_file_writebuffer (id, buffer id)

net_socket_listen   (protocol, port)
net_socket_connect  (protocol, address, port)
net_socket_pause    (id)
net_socket_resume   (id)
net_socket_close    (id)
net_socket_accept   (id)
net_socket_nodelay  (id, set)
net_socket_connected(id)
net_socket_send     (id, buffer id)
net_socket_recv     (id, buffer id)

Functions v0.1.3:

Spoiler

File
    ? =   net_file_exists        (filename);
    id =  net_file_new           (filename, mode);
    id =  net_file_open          (filename, mode);
          net_file_close         (id);
    pos = net_file_getpos        (id);
    siz = net_file_getsize       (id);
    cnd = net_file_getleft       (id);
    pos = net_file_setpos        (id, pos, relative?);
          net_file_readtobuffer  (id, buff id, bytes);
          net_file_readtobufferat(id, buff id, bytes, pos, relative?, rewind?);
          net_file_writebuffer   (id, buff id, bytes);
          net_file_writebufferat (id, buff id, bytes, pos, relative?, double rewind?);

Buffers
    id =  net_buffer_create      ();
          net_buffer_destroy     (id);
          net_buffer_clear       (id);
          net_buffer_expand      (id, totalsize, clearit?);
          net_buffer_shrink      (id);
          net_buffer_append      (dest id, src id, src pos, relative?, bytes);
    pos = net_buffer_getread     (id);
    pos = net_buffer_getwrite    (id);
    cnt = net_buffer_getleft     (id);
    siz = net_buffer_getsize     (id);
    pos = net_buffer_setread     (id, pos, relative?);
    pos = net_buffer_setwrite    (id, pos, relative?);
    val = net_buffer_readbits    (id, bits);
    val = net_buffer_readvalue   (id, value type);
    str = net_buffer_readchars   (id, bytes);
    str = net_buffer_readstring  (id);
    str = net_buffer_readsep     (id, sep string);
    str = net_buffer_readbstring (id);
    str = net_buffer_readwstring (id);
          net_buffer_writebits   (id, value, bits);
          net_buffer_writevalue  (id, value type, value);
          net_buffer_writechars  (id, string, bytes);
          net_buffer_writestring (id, string, bytes);
          net_buffer_writebstring(id, string, bytes);
          net_buffer_writewstring(id, string, bytes);

Socket
    id =  net_socket_listen     (type, port, options);
    id =  net_socket_connect    (type, address, port, options);
          net_socket_remap      (id, instance id);
          net_socket_pause      (id);
          net_socket_resume     (id);
          net_socket_close      (id);
          net_socket_update     ();
          net_socket_sendbits   (id, value, bits);
          net_socket_sendvalue  (id, value type, value);
          net_socket_sendchars  (id, string, bytes);
          net_socket_sendstring (id, string, bytes);
          net_socket_sendbstring(id, string, bytes);
          net_socket_sendwstring(id, string, bytes);
          net_socket_sendbuffer (id, buffer id);

Message
    cod = net_message_getnext     ();
    cnt = net_message_getcount    ();
    cnt = net_message_getleft     ();
    val = net_message_readbits    (bits);
    val = net_message_readvalue   (value type);
    str = net_message_readchars   (bytes);
    str = net_message_readstring  ();
    str = net_message_readsep     (sep string);
    str = net_message_readbstring ();
    str = net_message_readwstring ();
          net_message_readtobuffer(buffer id, bytes);

Group
    id  = net_group_create     ();
          net_group_destroy    (id);
          net_group_add        (id, socket id);
    ?   = net_group_isin       (id, socket id);
          net_group_remove     (id, socket id);
          net_group_sendbits   (id, value, bits);
          net_group_sendvalue  (id, value type, value);
          net_group_sendchars  (id, string, bytes);
          net_group_sendstring (id, string, bytes);
          net_group_sendbstring(id, string, bytes);
          net_group_sendwstring(id, string, bytes);
          net_group_sendbuffer (id, buffer id);

Edited by sabriath, 19 January 2011 - 11:12 PM.

[NYS]

Great your taking your time to do this

I would use it, but I have already used many 39dll scripts so renaming isn't so fun, if I want to keep the old scripts too.

[slayer 64]

i'm not sure what all the changes are going to do for me. looks like 39dll is pretty much the same, but more efficient internally i guess?
you must be pretty good at c++.
if you're going to re work 39dll, maybe you should use GMAPI and have objects automatically keep track of themselves on all machines connected to each other a server.

the end user would use scripts like this:
objControl create event

init(0,"www.aGameServer.com")//1=server 0=client

objControl

if lostConnection() game_end()
if machinesConnected()>10 removeLastMachine()

objPlayer create event

keepVariableUpToDate("x")
keepVariableUpToDate("y")
keepVariableUpToDate("z")

the scripts and dll would automatically trade messages to keep variables and objects in sync.
ideally the end user wouldn't need sockets.

obviously there's a lot of details and i'm not an expert on 39dll. lol

[2DLuis]

A quick question,

Did you fix the 39DLL glitch where in C++ if you received more than 1 string in a message, the data turned all screwy? And therefore you had to receive the data in one variable char array, and then pass it on to another normal char* variable. I could not quite determine from your post if you had addressed this.

Looks good,
-Luis

[ash47]

perhaps a different title / description?

otherwise, awesome

[Revel]

Nice, it's about time someone provided a 39dll alternative. I've been using RakNet, and I've noticed on thing that might be good for your DLL. A high resolution timer built into the DLL. It's great for quick timestamping of messages and that way you don't need to use another DLL like Yourself's DLL.

[sabriath]

@NYS: most of the functions will offer the same abilities as 39dll, so renaming would merely be for the scripts themselves. Your main code should not be effected unless you did a lot of extra work (and I may provide other scripts for crossover maintenance).

looks like 39dll is pretty much the same, but more efficient internally i guess?

Well the primary #1 reason for me doing this is because:

a = createbuffer();
b = createbuffer();
c = createbuffer();

freebuffer(b);

'c' now points to a NULL indexed address as far as 39dll is concerned, and whatever you "wrote" in 'c' buffer, will now be in addressed by 'b' even though it was freed.

have objects automatically keep track of themselves on all machines connected to each other a server.

Those are later plans I had in mind, but I want to just get all the direct internals done first. The thought had crossed my mind to make a network dll that did 99% of the work for you (even dead reckoning), but that's going to take me awhile...baby steps.

Did you fix the 39DLL glitch where in C++ if you received more than 1 string in a message, the data turned all screwy? And therefore you had to receive the data in one variable char array, and then pass it on to another normal char* variable. I could not quite determine from your post if you had addressed this.

I did not know this was a problem, can you explain in more detail about this?

If you mean something like:

writestring("this"+ chr(0) + "and this");

That's because c++ "strlen" automatically returns the 'size' of the string ending with the chr(0) command, so instead you would do this:

writestring("this"); //automatically adds '\0'
writestring("and this");

chr(0) is finnicky in C-type languages because they don't store the size of the string as a 2 byte short like other languages do, and as you know, it takes up 1 of the 256 ascii code designations. This sucks, but you cannot do anything about it directly. However, what I can offer is a "size" argument optional (already somewhat implemented), which would allow you to override 'strlen' check (a size=0 will cause a 'strlen' check). So you would do this (as an example):

writestring("this" + chr(0) + "and this" + chr(0), 14);

If this isn't what you mean, let me know so I can see if I can fix whatever it is.

perhaps a different title / description?

Suggestions?

Nice, it's about time someone provided a 39dll alternative. I've been using RakNet, and I've noticed on thing that might be good for your DLL. A high resolution timer built into the DLL. It's great for quick timestamping of messages and that way you don't need to use another DLL like Yourself's DLL.

I will be adding in that ability once I've fleshed out all of the direct access areas first.

Thanks everyone for the support, hopefully I'll have a demo out this week or the following (my anniversary was a couple days ago, so I wasn't able to program). Keep those ideas comin'!!

[csscom]

Cool stuff, I always assumed everything in 39dll was in perfect working order since it was on version 2.5.

I see your upgrading somethings and one sections says 39dll can cause disjointing with gm.
what does this mean? and can you provide and example of how it can causes problems for a GMMMO.

[Revel]

I see your upgrading somethings and one sections says 39dll can cause disjointing with gm.
what does this mean? and can you provide and example of how it can causes problems for a GMMMO.

Well the primary #1 reason for me doing this is because:

a = createbuffer();
b = createbuffer();
c = createbuffer();

freebuffer(;

'c' now points to a NULL indexed address as far as 39dll is concerned, and whatever you "wrote" in 'c' buffer, will now be in addressed by 'b' even though it was freed.

[True Valhalla]

I am glad that you are refining the 39dll, but as a "heavy user" of the 39dll, I can't say I have a sudden urge to change to this DLL. I'll explain why, just don't take any of it negatively. It's constructive criticism only =)

Firstly, the obvious complaint that has already come up, is the new names for the basic functions. Not only does it mean I would have a lot (LOT) of code to search through and change, it also is kind of annoying having to write mp_ every time I want to use a networking function. I've always liked that the 39dll doesn't require this; It just makes using it simpler. Call me lazy or whatnot, but that little tag alone is enough to stop me from upgrading.

Secondly, and somewhat ironically, I would prefer the main parts of a function name to be fully self-explanatory. Prime case is the mp_recv function. It's used only a few times in a networking setup, so would benefit from being mp_receive for the sake of understanding. That alone isn't enough to stop me upgrading, but it's a little detail that the user benefits from.

Finally, I am naturally skeptical that there may be bugs with this DLL. 39dll has some flaws, perhaps, but none that have directly or noticeably caused any problems. It has also been around for many years, and gone through several revisions, and people have released their online games with no troubles (in regard to the DLL itself). This DLL would need time to grow on m. I'm unlikely to upgrade to this DLL until the public has had it's chance to scrutinize any possible flaws, etc.

That said, I still look forward to this DLL, and will be sure to keep my eye on it. I am happy to upgrade to a better DLL as long as the transition is simple and worth the effort. Fix the flaws in the 39dll but maintain the ease of use.

Good luck =)

-Tv

[sabriath]

@TV: thank you for your overview, however I had already thought of doing backward compatibility, so no need to rename/rework any of your game's code (you would just take out 39sters version and plug mine right in). But mine will have added features obviously, if you need/want to use them.

Finally, I am naturally skeptical that there may be bugs with this DLL.

Quite disheartening to see, but that's ok, my c++ is rusty. I'm hoping the community can help squash the bugs when I put this in beta stage.

39dll has some flaws, perhaps, but none that have directly or noticeably caused any problems.

Not many people use the buffer system, they just write/read the default buffer and clear it when done, so they wouldn't notice the problem at all. However, I do use the buffers greatly, so not only is my library broken from it, but some of my personal scripts are as well....and everyone who relies on them are screwed. It's no biggy though, the extensions I have planned alone will hopefully put this at the top

@All: I have updated my original post, as well as the dll. I somewhat finished the socket class, but I have to get to bed. I still hope to have a demo within a week or 2...fingers crossed!

[Marchal_Mig12]

I am glad someone is finally taking over 39ster work . Could you add up some more distinct benefits on top of the features you're adding to 39dll. Also, as someone suggested before, it is no so funny to add mp_ before each script. If you could get rid of those, it would be perfect.

Finally, I believe this topic belongs to the DLL one instead .

Mig

[2DLuis]

I did not know this was a problem, can you explain in more detail about this?

Sure. Say in your GM client, you structure a message like so:

clearbuffer();
writebyte(MSG_ID);
writestring(global.user);
writestring(global.pass);
sendmessage(global._tcpsock);

When you receive said message in a c++ server, you have to do something like below:

                            sbuffer = readstring(0);  
                            strcpy(Players[i].Username, sbuffer);
                            sbuffer = readstring(0); 
                            strcpy(Players[i].Password, sbuffer); 

That is assuming you initialized your variables as follows:

// Though this is not too pertinent to the problem
// Player class
class Player
{
    public:
        double Sock;
        char Username[255];
        char Password[255];
        char* FileName;
        short AccID;
        short PlayerID;
        char* IPAddress;
        bool InUse;
};

And initializing the buffer variable as follows:

//39DLL Fix (global variable)
char* sbuffer;

And if you were to not do this, you would receive the first string just fine, yet the second one would become enmeshed with random data.

That is just cut paste from my c++ engine, so it may be somewhat sloppy,

Edited by 2DLuis, 18 October 2010 - 07:40 PM.

[True Valhalla]

Finally, I am naturally skeptical that there may be bugs with this DLL.

Quite disheartening to see, but that's ok, my c++ is rusty. I'm hoping the community can help squash the bugs when I put this in beta stage.

Haha, I have no doubt you are a very skilled programmer, my point is simply that everyone makes mistakes. 39dll has had years to be refined and has been used in many projects. I'm sure the community will be able to iron out any flaws (if any!)

[sabriath]

When you receive said message in a c++ server, you have to do something like below:

That looks like how it is suppose to be done, so I'm not sure I follow. What have you tried to do and it failed to work?

In my opinion, here is an easier way, but bypasses the buffer class altogether:

char* buff = new char[5000];
int len;

size = recv(s->sockid, buff, 5000, 0);
if (size > 0)
{
  len = strlen(buff) + 1; //get location of second string
  strcpy(Players[i].Username, buff);
  strcpy(Players[i].Password, buff + len);
}
delete(buff);

"buff" can be pre-initialized in a more public manner so that it doesn't have to keep being allocated and freed for each call.

The other issue, but is not a 39dll problem, is that TCP is a stream protocol, which means that you may very well receive the first string but not the second one....so the "strcpy" of the buffer at the second string's position will be garbled RAM data rather than from the buffer.

You can circumvent this by sending a 1 or 2 byte integer denoting the size of the total message being sent (or use 39dll's currently built-in feature using format=0). When you start receiving information, just append it to the buffer until the size of the buffer correlates with this value, then call your function, shift the buffer down, and you're ready to continue with the next message.

As it looks right now, my upgrades to 39dll will help both GM and c++ programmers, while the original was intended primarily for GM use...although it will be nothing like RakNet.

[LoopStan]

Yes 2Dluis, you have to have a buffer variable. I am really to lazy to post the stuff I used on here, but you shouldn't be using 39dll in a c++ app anyway, you should be making it so you can use it on linux and get super fast server speeds and more up time

[Revel]

you should be making it so you can use it on linux and get super fast server speeds and more up time

RakNet *cough*

[lasttea999]

This all sounds great... but only vaguely! I think that there are many GM users who, like myself, are using 39dll with only the bare minimum of required knowledge. I wish I could comprehend all that goes on within the DLL, but, alas, I am as yet unfamiliar with C++... You could argue that this demonstrates some degree of irresponsibility, but on the other hand 39dll seems to have opened up many new possibilities among GM users, and besides, how useful can an extension be if you have to know how to make it to use it?

Would it be possible, then, to provide a tutorial on this upgrade at some point, detailing, in particular, the changes between this and the original and the improvements it has incorporated?

Thank you to all of you diligent programmers for your efforts!

Edited by lasttea999, 19 October 2010 - 01:31 AM.

[Revel]

Would it be possible, then, to provide a tutorial on this upgrade at some point, detailing, in particular, the changes between this and the original and the improvements it has incorporated?

It will be basically identical to 39dll, but more efficient back-end, some bugs fixed, and will have some more features which you don't necessarily have to learn.

Edited by Revel, 19 October 2010 - 03:41 AM.

[sabriath]

Would it be possible, then, to provide a tutorial on this upgrade at some point, detailing, in particular, the changes between this and the original and the improvements it has incorporated?

It will be basically identical to 39dll, but more efficient back-end, some bugs fixed, and will have some more features which you don't necessarily have to learn.

And I will also be writing a new tutorial for all aspects of networking when I'm finished. I only ask for patience while I juggle work/life/hobby.


Edit: Didn't want to double post, although most will probably oversee this considering it's not going to bump the topic, but I figured I'd put it here just in case.

I have updated the file, it now contains the main.h/main.cpp files situated with a backbone structure. I decided to clean up a few things and redid DList class since creating/freeing memory just for an integer seemed a bit overkill, instead it uses a loop to search for a NULL in the list and assigns it (which the original 39dll did the same thing, but mine doesn't push the list down).

After cleaning up as much as I could, I accidentally hit the build key and the error list hit me like a ton of bricks. I knocked all of them out of the park except for 3 (which is actually 1, just done 3 times). I will be asking a few friends, but I'll post it here too just in case someone can help...

sprintf(&Digest + i * 2, "%02X", (char*)(&Ret[i]));

That kicks back an error saying:

"Ret: cannot change 'char (*_w64)[65]' to 'char*'" or something

I have tried every means possible, turning the pointers inside and out and I just cannot get the darn program to understand that I want to pass a UINT32[8] array byte for byte to get the hex digits. The "Ret[i]" code is wrong already because it needs to be casted as a "char*" so that it can go 1 byte increments, but somehow this doesn't work either (which I originally had):

(char*)Ret[i]

I figured since Ret[] was a static member of the class, it didn't have a pointer association, so that's why I switched to &Ret...then I thought:

((char*)&Ret) + i

But that doesn't work either....or did I try that? I'm tired now, I'll hit this up tomorrow after work.

Edited by sabriath, 19 October 2010 - 01:35 PM.