Perhaps, but following the standard that they usually do for reverse compatibility, it would probably be very easy. Duplicate the structure and related code, convert the shorts that they are using to 64bit integers everywhere (trivial, how often do you REALLY use a short?) Put an Ex on the end of all the APIs so they don't break anything. Of course recompiling might be interesting. And any MS employee will loyally exclaim, "Oh the cost...and the testing...and the time...and the cost...and the cost...and heaven forbid we might break something..." Ignore the fact that they have money to blow on pattenting boxes of unpatentable garbage. Forget the fact that everything is late anyway. NM the fact that when testers report a bug, it gets the same treatment this one got. Don't bother with the statistics. Vista breaks 8% of XP software products AT IT'S BEST (figures from Microsoft.) What do they care about cost, time, testing, and breaking things? They only care when it's a good excuse to not listen to testers, or leave something broken. Like this. Sorry, I'm in a bad mood tonight.:mad: 3rd party might be an issue, I never thought of that, good point.

Yes, but 32768x1 1bpp is only 4Kb and that isn't supported either. I guess this means no abuse of bitmaps as a replacement for bit arrays right? Really, I could see where this would be a major issue if someone needed a fairly long and narrow bitmap, like a graph with history. The limit is less than 30 screen widths at my resolution (on a laptop.) So a long scrollable bitmap is just plain out for something like this. I don't see what MS big problem is. It would take them like 2 minutes to convert their decade old 16 bit size bytes to the 64 bit numbers of the new millennium. I very much doubt that ANYONE would hit the limits then.

OK, here's the solution. It has to do with an undocumented behavior of the mouse hooks. Although MS doesn't tell us so, a mouse hook is triggered when PeekMessage or GetMessage finds a mouse message on the queue. MS would have us believe that this hook has nothing to do with picking up the message, but it's not true. Normally these mouse messages only hit the queue for a window one at a time, however, if the mouse is CLICKED then TWO end up on the queue for the window. In the code above, the first message, WM_LBUTTONDOWN, gets processed by the hook, which then calls PeekMessage in it's loop. PeekMessage finds WM_LBUTTONUP in the queue, not that we care because we are really just telling windows not to write us off. However, Windows DOES care, since this next message was a mouse message, and queues up another call for the mouse hook to complete as soon as the current one is done. After exiting the current hook function call, Windows calls it again, this time for WM_LBUTTONUP, however, WM_LBUTTONUP was never removed from the message queue, so it is STILL the message that PeekMessage will find, queueing up another call for the current function. This happens infinitely, causing an infinite loop that prevents any other code in the application from running, but without taking up much processor time, or locking the user out, since moving the mouse upsets the delicate balance required to make this work. It creates a great bug though when the user clicks...and waits...and waits...and waits, and when they finally get impatient and move the mouse, the screen comes up. The fix is very simple. We don't care what PeekMessage finds, if anything, so change the two NULL parameters to WM_QUIT. This will make PeekMessage ONLY serve up any WM_QUIT messages that it finds (which it will do anyway no matter what.) Since no mouse messages are served up, the bug goes away.

The infinite loop is the classic bug, the bane of all programmers existence. I had a good one the other day that came down to this. It takes a bit of code to set up so I'll just nail the principles. 1) Set up a system wide mouse hook (I used a system wide hook but it ought to work with any mouse hook.) 2) Do something in the hook callback that requires a loop for a period of time. I don't care what, for me, I wanted some delay control requiring the mouse to hover over a certain point for a defined period. Here is a pseudo code example of what I did. POINT oldpoint = GetMousePoint(); DWORD starttime = TimeInMS(); while (GetMousePoint() == oldpoint && (starttime + DELAY > TimeInMS())) { ...do something... } 3) Since you are running a loop, and you don't want to be a processor hog, you have to yield some control to the processor. MS says to do this: MSG msg; PeekMessage(&msg, hwnd, NULL, NULL, PM_NOREMOVE); so the loop becomes: POINT oldpoint = GetMousePoint(); DWORD starttime = TimeInMS(); while (point == oldpoint && (starttime + DELAY < TimeInMS())) { ...do something... MSG msg; PeekMessage(&msg, hwnd, NULL, NULL, PM_NOREMOVE); } 4) Voila! It works, no 100% processor, hooked mouse, delay, perfect...except, under certain situations after CLICKING the mouse the program stops doing anything until the user MOVES the mouse. I'll let all the bright folks out there chew on this, solution in the next post. -- modified at 12:22 Monday 2nd April, 2007