Project: Dictionary

[ic2]

Wouldn't this be a security risk for any app that put all of that information in the easy RW .data and .data? section.

What parts are really safe in those areas and what measures could be used to enhance security if that prove to be a problem.  Anyway it probably don't matter.  It is exciting.  I never seen nothing like that before.

[CoR]

Zooba, U are the man!

To rephrase code mentioned above. As far as I know there are three ways to allocate structure:

Code Select Expand

.DATA
wc1 dd sizeof WNDCLASSEX
   dd CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW
   dd offset WndProc, 0, 0, 400000h, 0, 0
   dd COLOR_WINDOW +1, 0
   dd offset  ClassName, 0 This works because ML will put those bytes in sequence! But to access structure made like that U need to tell ML what structure U intended to used like this:
mov wc.WNDCLASSEX.hCursor,eax
Because that string of bytes could mean almost anything you want!

Code Select Expand

.DATA
wc2 WNDCLASSEX { sizeof WNDCLASSEX, \
  CS_HREDRAW or CS_VREDRAW or CS_BYTEALIGNWINDOW,
  offset WndProc, 0, 0,0, 0, 0,
  COLOR_WINDOW, 0, offset  ClassName, 0 }
This is almost the same as above with difference that now we use full structure notation. And ML knows what wc.hCursor is so this is possible:
mov wc.hCursor,eax
In both examples wc is partially filled with data.

Code Select Expand

.DATA?
wc3 WNDCLASSEX <?>
or on stack:
LOCAL wc4:WNDCLASSEXHere, the only way to fill wc structure is dynamicly in application.
OFFSET wc1,wc2,wc3 will produce push [12345678]  but
OFFSET wc4 had to be calculated with lea eax, wc4
Is this right?

I made mistake in SIZEOF! 

sizeof WNDCLASSEX - is 12*4 after all. Because there are 12 elements in structure and 4 bytes are allocated for each element. Personally I do not think anyone will change wc:WNDCLASSEX soon, but If U are messing up with structures SIZEOF is really neath.

I see what U mean by proper way of calculating hInstance. If for some weird reason MS decides to change virtual handle position prg will continue to  work normally.
I always remember one article about old apple mac. Some programmers used little hack to avoid calling some "memory allocating function". They were writing/reading directly to mem. And their applications worked 10-30% faster! But Apple made new faster CPU and rearranged mem positions. And those applications lost their 'edge'. It didn't work at all  :green

[CoR]

I have peace of code that does not process Ctrl buttons and can not contain cursor shape

Code Select Expand


@@:
cmp uMsg,WM_KEYDOWN
jne @F
   
    cmp wParam,VK_F12 ;VK_RCONTROL does not work
        je PressedCtrlIF
    cmp wParam,VK_F12  ;VL_RCONTROL same not working
      jne NotPressedCtrlIF
PressedCtrlIF:
  mov CtrlIF,1
mov wc1.hCursor,0  ;set class to NULL?!?
invoke LoadCursor, hInstance, GrabbingHandCursor
  invoke SetCursor, eax


"If your application must set the cursor while it is in a window, make sure the class cursor for the specified window's class is set to NULL. If the class cursor is not NULL, the system restores the class cursor each time the mouse is moved. "

How should I set windows class to NULL and avoid reshaping my grabbing hand cursor to arrow?