Nice! Out of curiosity what compiler are you using? I think I may have tried that back on VS8 but with errors.

Waldermort

ahmed zahmed wrote:

You're accessing a memory location.

LOL, That thought hit me right after posting the message. Compiler still complains when assigning to a const. I've decided to go with my first method but instead to use _makeTag('c','m','a','p') directly in the switch. Thanks again.

Waldermort

Chuck O'Toole wrote:

Theory goes that the EndPaint() call will take care of the ValidateRect() on the .rcPaint member of the PAINTSTRUCT you received in BeginPaint(). Is that the same thing you are using in your manual ValidateRect() call? Is there a possibility that it is being clobbered during your paint processing? If .rcPaint changed between Begin and End that would explain what you see. You say you use that member to do your re-drawing, read-only?

BeginPaint() actually. Like you said though, if it were a bug... which makes me think there must be a problem in my code somewhere. Anyway, found it! Deep in there was a legacy debug routine to update the entire screen. Now to find out who made it and then... Thanks for the suggestions though.

Waldermort

To make my code more readable I'm trying to use a set of defined values in a switch statement. Basically I have a 4 CHAR tag I want to convert to a DWORD.

//#define _makeTag(a,b,c,d) ((#@a << 24) | (#@b << 16) | (#@c << 8) | #@d)
//#define tag_cmap _makeTag(c,m,a,p)
#define _makeTag(x) ((#x[0] << 24) | (#x[1] << 16) | (#x[2] << 8) | #x[3])
#define tag_cmap _makeTag(cmap)

In the above I have a 4 CHAR string "cmap" which in DWORD form should be 0x636d6170. However when using in a switch statement the compiler complains that it's not constant. The commented line works, however I believe it to be unreadable. Any suggestions? My previous method was to use a union but that required a loop over all the values, hence slow code.

Waldermort

It's too much code to simply paste here. You'll have to take my word for it that there is no way for the rect to be invalidated other than when I explicitly call for it. My code works like this. bitmap A is updated from a thread. Thread calls InvalidateRect when done updating a frame. bitmap B contains the window background and doesn't change. bitmap C is a double buffer. When WM_PAINT arrives, call BeginPaint, alpha blend bitmap A with B onto C and BitBlt bitmap C to the screen. When done call EndPaint. Like I said this is GDI 101, and I have never had a problem like this with previous versions of windows or Visual Studio. As it stands now, calling ValidateRect from anywhere in the WM_PAINT handler solves the problem. I currently have it after the call to EndPaint. Without this call, WM_PAINT is being sent from window creation and always with the full client area. Even though at that time my drawing routines have not yet begun. And yes I do call Begin End on EVERY WM_PAINT. On another note, passing the message onto DefWindowProc, after those two calls, also results in undesired behaviour. rectangles are being validated but not those that are in the paint struct. I'm really beginning to think this is a bug.

Waldermort

Chuck O'Toole wrote:

Well, if the documentation says you have to do it and the experimentation shows that you have to do it, seems like it's working as designed. Not a bug, the rules.

But the documentation doesn't say that, infact it says that since I am calling BeginPaint there is no need to call ValidateRect. http://msdn.microsoft.com/en-us/library/dd145194(VS.85).aspx[^]

Waldermort

The BeginPaint function automatically validates the entire client area.[^] So having to manually add a ValidateRect is not the correct way because BeginPaint should have done it for me.

Waldermort

I've created a custom control, using the low level win32 api, which displays an animation. Using a thread I render a frame, or rather update the parts need it, and call InvalidateRect passing the area that was changed. In the main thread I handle WM_PAINT with the BeginPaint EndPaint pair AND use the paintstruct's rect to repaint only the area required. The rendering is backed by a TimerQueue, an event and a thread that waits on the event. I couldn't work out why my CPU usage was hovering around 80%. Each frame involves a lot of alpha blending hence the need to only update the changed parts. After 2 days I've narrowed the problem to BeginPaint. MSDN states, and this is GDI 101, when handling a WM_PAINT message BeginPaint and EndPaint should be called to validate the invalid rect, otherwise windows will continue to post the message. Well, it's just not happening. The window has not been validated and my code has been rendering the full client area (lot's of work) on each call. If I add a ValidateRect in my handler the problem goes away and CPU down to 0-1%. My question is why? Is this a bug or am I missing something?

Waldermort

I'm guessing that only about 1/5th of this code actual does anything. I would love to just plug it into a debugger and find out exactly what is going on but I gave up on that idea. The only thing I can do now is extract the base algorithms and rewrite the remaining code myself. At this point I'm thinking that even if I had the original code at hand (uncommented), I would probably still have a headache.

Waldermort

Thanks for the confirmation, I thought I was missing something. After posting the message a came across a few other oddities like double xor'ing values and over complicated method calls that return the same data as passed in. Went from 4pm to 8am, manually reversing about 2000 lines of bytecode only to end up with a 9 line C++ method. I can only guess that the coder, an ex-coworker, coded it in such a way to make reverse engineering very difficult. By the way, it was initially a web app that was later converted to a standalone binary.

Waldermort

Decompiled a .class (translating to C++) using third party tools (namely Java Decompiler by Emmanuel Dupuy and DJ Java) and also from the bytecode output from javap; all result in the following:

StringBuffer stringbuffer = new StringBuffer();
for(int i = 0; i < stringbuffer.length(); i++)
{
byte byte0 = (byte)stringbuffer.charAt(i);
stringbuffer.append((char)byte0);
}

I've been scratching my head for hours trying to figure it out. From what I can see it creates an empty buffer, tests the length (which would be 0) against 0 and skips the loop. Please, somebody, explain it to me. For completeness sake here is the javap output:

0: getstatic #5; //Field a:Z
3: ifeq 47
6: new #4; //class java/lang/StringBuffer
9: dup
10: invokespecial #9; //Method java/lang/StringBuffer."<init>":()V
13: astore_1
14: iconst_0
15: istore_2
16: goto 36
19: aload_1
20: iload_2
21: invokevirtual #13; //Method java/lang/StringBuffer.charAt:(I)C
24: i2b
25: istore_3
26: aload_1
27: iload_3
28: i2c
29: invokevirtual #11; //Method java/lang/StringBuffer.append:(C)Ljava/lang/StringBuffer;
32: pop
33: iinc 2, 1
36: iload_2
37: aload_1
38: invokevirtual #15; //Method java/lang/StringBuffer.length:()I
41: if_icmplt 19
44: invokestatic #12; //Method b:()V
47: getstatic #6; //Field b:Z
50: ifeq 57
53: iconst_0
54: putstatic #6; //Field b:Z
57: iconst_0
58: putstatic #5; //Field a:Z
61: return

Waldermort

No. When dealing with string buffers you only need to set the first char/wchar/tchar to 0. char myString[100]; // Is a buffer of 100 chars the a string may be copied into. strcat( myString, "Hello World!" ); // will fail because the buffer is full of junk. // but strcpy( myString, "World!" ); // will work because it doesn't care what is in the buffer myString[0] = 0; // copies an empty string to the buffer strcat( myString, "Hello World!" ); // appends the string to the empty string ( also sets the character after '!' to \0 or NULL. The new string is actually 13 chars because there is a 0 at the end. On another note. You shouldn't be using those string functions. There are safer versions available: strcpy_s( myString, 100, "Hello World!" ); These check to make sure the buffer is large enough for the string Also, you might want to read up on TCHAR and the unicode/ansi string functions TCHAR myString[100]; _tcscpy_s( myString, 100, _T("Hello World!");

Waldermort

Since you are dealing with strings there isn't a need to clear the whole buffer. char x[100] = { 0 }; internally calls memset. In your case it's a waste of (7 or so not including the loop inside memset) CPU cycles. char x[100]; x[0] = 0; initially creates an empty string. Just 1 CPU cycle. But then, calling functions like strcpy and sprintf don't require the buffer to be empty whereas strcat NEEDS a string (empty or otherwise) to append to.

Waldermort

On most 32 bit systems bit 1 and 2 are not used in an address. This allows the CAS algorithm to test an address and also test a flag (very useful for non blocking linked lists). However on a 64 bit system those 2 bit are in use. After doing some googling I have found that AMD64 and IA64 use 48 bits. AMD plans to extend that 52 bits. So my question is, Am I safe to use bit 1 of a 64 bit address, if so will it be portable?

Waldermort

You could try using Visual Assist from www.wholetomato.com

Waldermort

john john mackey wrote:

I have used message boxes/print statements in place of breaks to see if code reached

It could be possible that message boxes are unable to be created. Why don't you instead try using OutputDebugString()? Are you sure this is not a problem with Debug/Release builds?

Waldermort

Under windows Vista I have set up a few non-admin users. On the Same PC I have several volumes which contain sensitive files. I have been playing around with the volumes permissions but so far have not been able to achieve the desired result. I want the other users to be able to see the volume in "My Computer" but be unable to access them without the administrators password. i.e. double clicking on the volume a UAC box should appear prompting for the password. Does anybody know how this can be done?

Waldermort

It really depends on what you are doing in the threads. Take your example, you have 100 log files to retrieve and process. Perhaps the time to retrieve a single log file would be about 0.5 seconds, then you do some processing, perhaps search a database, which may take anywhere between 0.1 and 10 seconds, then yes, using several threads would increase the speed. In this case, while one thread does a ten second search, another thread may complete 10 1 second searches. But, if the time is pretty much standard for each log file, then as David Crow said, the constant switching between threads will take away any performance gain.

Waldermort

I will have to install the 3790 DDK again, but I'm sure I had the same problem last time I used it. I hoped the issue would have been fixed in the 6000 release. I'll re-install it now and see how it goes.

Waldermort

For some reason or another PREfast always crashes my script host. Has anybody come across this problem and know of a way to get it working? My development env is Vista x64 ( with script host 5.7 ), VS2005 ( not that it matters ) and the latest WDK 6001.18000 Opening any build environment and typing "prefast /?" crashes, as does trying to run prefast.exe from a command line. According to the docs PREfast is supported on all OS's starting with winXP and I am unable to find anything about this problem on MSDN or google.

Waldermort