While doing this i have WinDbg open and look at the pointer location for Input, lets say its x00500, you can see all 5 characters in Hello and their hex codes in Byte view.
Swapbits reverses the hi 4 bits for the low 4 bits in each UINT8 byte put in. It does this through a lot of bit manipulation, i dont have the code available now but it doesnt matter its not pertinent really. So instead of having a Hex of 0x25 fed in, it outputs 0x52. Sort of a ghetto encryption method.
All good so far.
Now call this again...
if you look at the pointer it uses it does NOT create a new char* pointer. Instead it points to the one it made the first time at 0x500(still encrypted). Obviously passing in the bit swapped value just bit swaps it back. So swapbits outputs 0x25, from the previous example.
Every time you call Send("Hello", 0) it will point to 0x500 not knowing its been manipulated. It has to be some compiler thing trying to optimize these strings used multiple times only delcaring them in memory once, but its breaking everything.
Ok, I think the problem you're having is how the compiler handles string literals by default. Every sting constant such as your "Hello!" has to be stored in your .exe file. By default, I think, VC++ combines indentical string literals into one instance to save space. Most of the time, these are put into programs to be treated as constants. In your case, you're saying it's ok to modify the memory locations that hold "Hello!". Since the compiler combines all instances of "Hello!" into one, all pointers to it will point to the same block of memory. Change that memory and it's changed for all instances.
I think there's a compiler or linker flag to force code generation to not combine string literals but I couldn't find it when I looked. Maybe they did away with it since the last version I saw that had it and now you're stuck with what you're seeing.
One way around it would be to define "Hello!" once and copy it to a separate buffer each time you want to play with it.
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
Firstly, it's far from clear what you mean by "loaded into a memory table". It sounds like your want to re-implement the loader. In general I'm not sure if this is possible from user mode. There's a lot more to getting a module into memory in a executable state then simply having the module in memory: relocating, recursively loading all dependent modules, resolving imports (building the Import Address Table, for example), etc... Even if you did do all these things (and more that I've forgotten) it's far from clear that "unusual" things, for example code that enumerated all loaded modules, would work.
I have my project set as a release, but of course when I run it through the IDE it runs in Debug mode.
If I run the program outside of VS2010 the app crashes when it is trying to get a COM for Common Item Dialog.