C / C++ / MFC

Re: Windows date change event

13-Apr-10 2:56

You might look into the WM_TIMECHANGE message.

Another option would be to set up a timer to fire every minute. Keep track of the date each time the timer fires.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

KarstenK13-Apr-10 4:34

KarstenK

13-Apr-10 4:34

check for changed date...

Press F1 for help or google it.
Greetings from Germany

C - Application reusing memory locations that have been altered

Member 259847812-Apr-10 13:35

Member 2598478

12-Apr-10 13:35

Long story, this isnt the exact use case but its a representation of the problem im having.

Lets say i then call a function that takes a Char*, i pass into this function "Hello!", upon arriving at this function the pointer lets say points to 0x55 containing "Hello!", this function then does bit manipulation on the Char*, so it now says "!olleH" at location 0x55

Now I again pass "Hello!" into the same function that takes a Char*, it goes directly to 0x55 and does the exact same bit manipulation, UNDOING the "encoding" and bringing the text back to "Hello!" rather than actually passing in a new instance of "Hello!" that i passed into it and encoding it to "!olleH" as it should.

Its as if the compiler is optimizing and any time it see's "Hello!" being passed through this function to just go straight to that memory location not knowing ive done bitwise things too it.

How do i stop this from happening or how can i trick the compiler into stopping this?

If i sprintf "Hello!" into a temporary buffer, and then print that, it works fine. But thats not a solution I can use unfortunately as there are hundreds if not thousands of lines that print "Hello!".

During my bitwise manipulation i've tried to create a new char, copy my text over to it, bit manipulate the new char, and then copy it back. But no luck, it just seems to point to that same location when i call the function.

Re: C - Application reusing memory locations that have been altered

Garth J Lancaster12-Apr-10 15:09

Garth J Lancaster

12-Apr-10 15:09

how about you post the smallest fragment(s)/part(s) of code that demonstrate the issue - its a bit hard without seeing the function def, how you're calling it etc etc - please use the [code block] pre & /pre xml around your code as well

'g'

Re: C - Application reusing memory locations that have been altered

Member 259847812-Apr-10 17:06

Member 2598478

12-Apr-10 17:06

So i have two functions

void Send(Char* Input, UINT32 DisplayType)
UINT8 SwapBits(UINT8 b)

I then call

Send("Hello", 0);

Which gets the length of Input and then

for(int i=0;i < len;i++)
{
     Input[i] = SwapBits(Input[i]);
}

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...

Send("Hello", 0);

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.

Re: C - Application reusing memory locations that have been altered

Tim Craig12-Apr-10 17:42

Tim Craig

12-Apr-10 17:42

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.

Re: C - Application reusing memory locations that have been altered

enhzflep13-Apr-10 2:03

enhzflep

13-Apr-10 2:03

No, no, no, no! no.

In your example, you are sending the text as a constant - the compiler can do whatever it chooses to store/optimize constant usage. In my case something like that crashes...

What you should be doing is along the lines of:

#include <stdio.h>
#include <stdlib.h>

char *manip(char *manipMe)
{
    return strrev(manipMe);
}

int main()
{
    char *manipMe;

    manipMe = (char*)malloc(strlen("Hello world!\n")+1);
    strcpy(manipMe, "Hello world!\n");

    printf("%s","Hello world!\n");
//    printf("%s",manip("Hello world!\n"));     // crashes nuder mingw 3.4.5
//    printf("%s",manip("Hello world!\n"));     // crashes nuder mingw 3.4.5

    printf("%s",manip(manipMe));
    printf("%s",manip(manipMe));
    return 0;
}

Output:

Hello world!

!dlrow olleHHello world!

Process returned 0 (0x0)   execution time : 0.031 s
Press any key to continue.

Re: C - Application reusing memory locations that have been altered

Eugen Podsypalnikov12-Apr-10 20:34

Eugen Podsypalnikov

12-Apr-10 20:34

A dirty trick, that I would not use Blush | :O

:
all characters will be placed temporary on stack:

typedef struct {
  char theSequence[256]; // possible length risk...
} SSEQUENCE;

void Modify(SSEQUENCE sSequence)
{
  sSequence.theSequence[0] = 'a';
}

void Test()
{
  Modify(*((SSEQUENCE*) "Hello"));
  Modify(*((SSEQUENCE*) "Hello"));
  Modify(*((SSEQUENCE*) "Hello"));
}

virtual void BeHappy() = 0;

DLL in memory

RomTibi12-Apr-10 8:53

12-Apr-10 8:53

Can a DLL loaded into a memory table be used like a DLL into a file with LoadLibrary()?

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

David Crow12-Apr-10 10:11

12-Apr-10 10:11

Are you wanting to know the difference between implicit and explicit linking?

RomTibi13-Apr-10 6:35

13-Apr-10 6:35

I think I don't understand. The problem is that I want to avoid LoadLibrary().

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

David Crow13-Apr-10 6:40

13-Apr-10 6:40

RomTibi wrote:
The problem is that I want to avoid LoadLibrary().

Then you must link implicitly.

RomTibi13-Apr-10 6:55

13-Apr-10 6:55

I think I don't know the difference between implicit and explicit. I think I need an example.

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

David Crow13-Apr-10 6:57

13-Apr-10 6:57

RomTibi wrote:
I think I need an example.

Google is your friend. See here.

RomTibi13-Apr-10 6:59

13-Apr-10 6:59

Thanks! I've a lot to learn! ...yet... Smile | :)

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

«_Superman_»12-Apr-10 10:30

«_Superman_»

12-Apr-10 10:30

LoadLibrary requires the DLL to be on the disk.
So you will need to write the contents of the memory to a disk file and then call LoadLibrary on it.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

RomTibi13-Apr-10 6:37

13-Apr-10 6:37

See the reply to David Crow

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War

@Intersect☺™12-Apr-10 19:39

@Intersect☺™

12-Apr-10 19:39

Yes. you can load one DLL into System Memory.

RomTibi13-Apr-10 6:38

13-Apr-10 6:38

How?

36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.

SUN-TZU - Art of War