You have supplied very little to go on, so in addition to suggesting you provide more information I'll ask a question: are you allocating memory in one module and freeing it in another (a module is a dll or exe)?
I am sorry for adding incomplete info.
I have allocated memory to object of structure myStruct in one dll and passed this struct object as a reference to another dll. This crash happens only while assinging value to
variable. Finally I was able to assign value inside CString variable using
method. I was able to resolve this crash with following code , but I am sure this is not the correct way to do it.
Unless you configure things properly each module (dll or exe or other executable module) has it's own heap. In this environment you can't allocate memory in one module and free it another. Given that CString manages a buffer using an instance in multiple modules could result in this happening. Forget wcscpy, it's ugly and isn't a fix for the root problem, whatever it is. If it's heap corruption, which is my guess, it's going to blow up sooner or later and "fixing" one problem with an ugly hack will just result in it popping up somewhere else.
Finally I have solved this issue.
The CString when used with GCC was Used as LinuxCString which is internally std::string. Capacity of std::string when calculated was every time 0. so when I tried to assign const char* to LinuxCString ( i.e. CString in MSVC ) it was crashing.
I have used std::string.reserve (200) method to specify the capacity first while initialization. This solves my issue.
I am still evaluating whether my fix is perfect or not.
First off... for something like this, I wouldn't use UDP, I would use TCP/IP. There's really no reason to use UDP, which sends datagrams with no built-in error checking, TCP/IP already handles the error checking/handling (i.e. it'll automatically retransmit packets that didn't arrive at their destination correctly). Usually you only want to use UDP when you have something that doesn't require reliability like voice or video (i.e. if you lose a packet here and there it won't really matter, you'll still be able to hear/see the other person).
As far as sending the data, if you're making for the server and client, it's easy, you define the data messages/structures that are being passed between both completely yourself (via what is typically referred to as an API). Usually the packets are made up of binary buffers, within that buffer, you can either have fixed length or variable length data buffers (or packets), the structure of which is completely up to you.
For example, you can specify:
0. first 4-bytes of the buffer define the message type
1. next 4-bytes define a message specification
2. next 4-bytes define the message size
3. so on...
In this scenario, when you receive a packet, first thing you'll do is cast it onto a data structure that is defined by your API. The first portion of the structure would be an int type (picked it because it's 4-bytes in a 32bit system) and it can specify the type of message that is contained in that data packet. The next portion can be a subset of that message and so on.
Search google and CodeProject for client/server examples and see how they defined their messages.
Unless you know the format of the file contents there is not really any way to do it. You can try some guesswork and logical tests (I have done similar in the past) but it is really down to looking at the content, and figuring out what each byte or set of bytes is supposed to represent.
One of these days I'm going to think of a really clever signature.
What do you mean with getting the format? If it's a binary file and you don't know how to interpret its contents, I don't think you can get a format.
Regarding the reversion, thats quite easy, although I don't see the point in doing it. You could use the functions fread(), frwite() and the like to read it into a large enough char array, loop through it from back to front and write it byte by byte into a new file (assuming is is small enough to fit into memory).