How To Disassemble A Windows Program

     After we've found and analyzed WinMain() (-> lesson 1), the next
     places to inspect when you crack a program are the windows procedures
     and dialog procedures (this is true only for Windows *programs*; for
     DLL, on the countrary, the cracking procedures are different and the
     relvant techniques will be discussed in another lesson).

     These WndProcs and DialogProcs are "callback" procedures: they are
     *exported* from Windows executables, almost as the program were a DLL,
     so that Windows can call them.

     And -hear, hear!- beacuse they are exported these crucial procedures
     have *names* (almost always useful) that are accessible to any decent
     Windows disassembler. In Taskman.lst, for example, WCB clearly
     identifies TASKMANDLGPROC:

     Exported names by location:
       1:007B     1 TASKMANDLGPROC      <- It's a DialogProc !

     It works out well that the WndProcs and DialogProcs show up so nicely
     in the disassembled listings, because, as we know from Windows
     programming, these subroutines are "where the action is" in event
     driven Windows applications... or at least where the action begins.

     Furthermore we know that these subroutines will be most likely little
     more than (possibly very large) message handling switch/case
     statements. These usually look something like this: long FAR PASCAL
     _export WndProc(HWND hWnd, WORD message, WORD wParam, LONG lPAram)

     long FAR PASCAL _export WndProc(HWND hWnd, WORD message, WORD
     wParam, LONG lPAram)
      { ...
          switch (message)
           {
               case WM_CREATE:
                 //... handle WM_CREATE message
                 break;

               case WM_COMMAND:
                 //... handle WM_COMMAND message
                 break;
               default:
                 return DefWindowProc(hwnd, message, wParam, lParam);
           }
       }

     Wow! Yes! As you already guessed this means that... that we get
     immediately 4 parameters for EACH exported WndProc or DlgProc!

     Actually there's no rule that states that a Windows WndProc or DlgProc
     has to look like this... it's just that they almost always do!

     Here is how the parameters to the WndProc or DialogProc will appear in
     the assembly language listing (after the function prologue):

     long FAR PASCAL _export WndOrDialogProc(HWND hwnd, WORD
          message, WORD wParam, LONG lParam);

        lParam          = dword ptr [bp+6]
        wParam          = word ptr [bp+0Ah]
        message         = word ptr [bp+0Ch]
        hWnd or hWndDlg = word ptr [bp+0Eh]

     With this knowledge, we can replace an otherwise meaningless [bp+0Ch]
     with a label such as "message", a [bp+0Eh] with a "hwnd" or "hwndDlg",
     and so on in *ANY* DialogProc and WndProc in *ANY* Windows program.

     The boilerplate nature of Windows programming greatly simplifies
     cracking. For example, here is part of our Taskman exported:

     The problem here, of course, is what to make of all these magic
     numbers: 0064, OO1C, 00F4 and so on... how are we going to figure out
     what these mean?

     DialogProc: TASKMANDLGPROC:

       1.007B                           ;  TASKMANDLGPROC
       ... (function prologue)
       1.008A  8B760E           mov     si,  hWndDlg        ;[bp+0E]
       1.008D  56               push    si
       1.008E  6A64             push    0064

       1.0090  9AFFFF0000       call    USER.GETDLGITEM
       1.0095  8BF8             mov     di, ax
       1.0097  8B460C           mov     ax, message         ;[bp+0C]
       1.009A  2D1C00           sub     ax, 001C
       1.009D  7416             je      00B5
       1.009F  2DF400           sub     ax, 00F4
       1.00A2  7436             je      00DA
       1.00A4  48               dec     ax
       1.00A5  7503             jne     00AA
       1.00A7  E98301           jmp     022D

       1.00AA >2D5303           sub     ax, 0353
       1.00AD  7503             jne     00B2
       1.00AF  E9D602           jmp     0388

       1.00B2 >E9C801           jmp     027D

       1.00B5 >837E0A00         cmp     word ptr wParam, 0  ;[bp+0A]
       1.00B9  7403             je      00BE
       1.00BB  E9BF01           jmp     027D
       ...

     When examined via disassembled listings, Windows programs tend to
     contain a lot of "magic numbers". Of course the actual source code
     would be :

     *    #include '<'windows.h'>'          and
     *    #define numeric constants for the various resources (menus,
          strings, dialog controls, etc.) that it uses.

     Given a disassembled listing, it should be possible to turn a lot of
     these seemingly senseless numbers back into something understandable.

     Let's start with the number 001C in TaskManDlgProc():

       1.0097  8B460C           mov     ax, message    ;[bp+0C]
       1.009A  2D1C00           sub     ax, 001C
       1.009D  7416             je      00B5

     If AX holds the *message* parameter to TaskManDlgProc() (line
     1.0097)... then the value 001C must be a Windows WM_ message number
     (one of those you can breakpoint to with WINICE's BMSG command, by the
     way). Looking in WINDOWS.H, we find that 0x1C is WM_ACTIVATEAPP.

     TaskManDlgProc() is subtracting this value from AX and then jumping
     somewhere (let's call it ON_ACTIVATEAPP) if the result is zero... i.e.
     if it is WM_ACTIVATEAPP.

     This is an odd way to test whether (message == WM_ACTIVATEAPP): if the
     test fails, and we do not take the jump to ON_ACTIVATEAPP, the message
     number has 1C subtracted from it... and this value must be taken
     account of by the next switch statement:

       1.009F  2DF400    sub    ax, 00F4 ; (+1C=110=WM_INITDIALOG)
       1.00A2  7436      je     00DA     ; jump to ON_INITDIALOG
       1.00A4  48        dec    ax       ; (110+1=111=WM_COMMAND)
       1.00A5  7503      jne    00AA     ; no, go elsewhere
       1.00A7  E98301    jmp    022D     ; yes, jump to ON_COMMAND

     Other WndProcs & DialogProcs will contain straightforward tests,
     rather than testing via subtraction... is a matter of compiler choice.
     In any case, a WndProc or DialogProc generally contains a collection
     of handlers for different messages.

     In the case of TaskManDlgProc(), we can see that's handling
     WM_ACTIVATEAPP, WM_INITDIALOG and WM_COMMAND. By itself, this
     information is rather boring... however, it tells us what is happening
     *elsewhere* in the function: 1.00B5 must be handling WM_ACTIVATEAPP
     messages (therefore let's call it ON_ACTIVATEAPP), 1.00DA must be
     handling WM_INITDIALOG, and 1.022D must be handling WM_COMMAND
     messages.

     Write it down! This same basic technique -find where the [bp+0Ch]
     "message" parameter to the WndProc or DialogProc is being rested, and
     from that identify the locations that handle various messages- can be
     used in *ANY* Windows program.

     Because handling messages is mostly what Windows applications do, once
     we know where the message handling is, we pretty much can have our way
     with the disassembled listing.

     Let's look now at TaskManDlgProc():

     TASKMANDLGPROC proc far
       ...
      DISPATCH_ON_MSG:
       1.0097  8B460C    mov  ax, message        ;[bp+0C]
       1.009A  2D1C00    sub  ax, WM_ACTIVATEAPP ;001C
       1.009D  7416      je   ON_ACTIVATEAPP
       1.009F  2DF400    sub  ax, 00F4 ; (+1C=110=WM_INITDIALOG)
       1.00A2  7436      je   ON_INITDIALOG
       1.00A4  48        dec  ax       ;(110+1=111=WM_COMMAND)
       1.00A5  7503      jne  DEFAULT
       1.00A7  E98301    jmp  ON_COMMAND
      DEFAULT:
       1.00AA >2D5303    sub  ax, 0353 ;(111+353=464=WM_USER+64
       1.00AD  7503      jne ON_PRIVATEMSG ;00B2= some private msg
       1.00AF  E9D602    jmp  0388
      ON_PRIVATEMSG:
       1.00B2 >E9C801    jmp  027D
      ON_ACTIVATEAPP:
       1.00B5 >837E0A00  cmp     word ptr wParam, 0  ;[bp+0A]
       ...               ; code to handle WM_ACTIVATEAPP
      ON_INITDIALOG:
       ...               ; code to handle WM_INITDIALOG
      ON_COMMAND:
       ...               ; code to handle WM_COMMAND
       1.022D >8B460A        mov   ax, wParam  ;[bp+0A]
       1.0230  3D6800        cmp   ax, 0068    ; ? What's this ?
       1.0233  7503          jne   0238
       1.0235  E93301        jmp   036B
       ...

     This is starting to look pretty reasonable. In particular, once we
     know where WM_COMMAND is being handled, we are well on the way to
     understand what the application does.

     WM_COMMAND is *very* important for understanding an application
     behavior because the handler for WM_COMMAND is where it deals with
     user commands such as Menu selections and dialog push button clicks...
     a lot of what makes an application unique.

     If you click on "Cascade" in Task manager, for instance, it comes as a
     WM_COMMAND, the same occurs if you click on "Tile" or "Switch To" or
     "End Task".

     An application can tell which command a user has given it by looking
     in the wParam parameter to the WM_COMMAND message.

     This is what we started to see at the ned of the TaskManDlgProc()
     exerpt:

       ; We are handling WM_COMMAND, therefore wParam is here idItem,
       ; i.e. a control or menu item identifier
       1.022D >8B460A  mov  ax, wParam ;[bp+0A]
       1.0230  3D6800  cmp  ax, 0068   ;ID number for a dialog control
       1.0233  7503    jne   0238
       1.0235  E93301  jmp   036B

       1.0238 >7603    jbe   023D
       1.023A  E96001  jmp   039D

       1.023D >FEC8    dec   al        ;1
       1.023F  7420    je    0261      ;if wParam==1 goto 1.0261
       1.0241  FEC8    dec   al        ;1+1=2
       1.0243  7503    jne   0248
       1.0245  E94701  jmp   038F      ;if wParam==2 goto 1.038F

       1.0248 >2C62    sub   al, 62    ;2+62=64
       1.024A  742A    je    0276
       1.024C  FEC8    dec   al        ;64+1=65
       1.024E  7432    je    0282
       1.0250  2C01    sub   al, 01    ;65+1=66
       1.0252  7303    jnb   0257
       1.0254  E94601  jmp   039D

       1.0257 >2C01    sub   al, 01    ;66+1=67
       1.0259  7703    ja    025E
       1.025B  E9D200  jmp   0330

     It's clear that wParam is being compared (in an odd subtraction way)
     to valus 1,2,65,66 and 67. What's going on?

     The values 1 and 2 are standard dialog button IDs:

     #define IDOK            1
     #define IDCANCEL        2

     Therefore we have here the two "classical" push buttons:

       1.023D >FEC8    dec   al        ; 1 = OK
       1.023F  7420    je    ON_OK     ; If 1 goto 1.0261= ON_OK
       1.0241  FEC8    dec   al        ; 1+1=2= CANCEL
       1.0243  7503    jne   NOPE      ; goto neither OK nor CANCEL
       1.0245  E94701  jmp   ON_CANCEL ; if 2 goto 1.038F= ON_CANCEL

     The numbers 65, 66 etc are specific to TaskManager however, we will
     not find them inside WINDOWS.H... so there is no home to find the
     names of the commands to which these magic number correspond, unless
     we happen to have a debug version of the program true? NO! FALSE!

     One of the notable things about Windows is that remarkably little
     information is lost or thrown away compiling the source code. These
     magic numbers seem to correspond in some way to the different Task
     Manager push buttons... it's pretty obvious that there must be a way
     of having applications tell Windows what wParam they want sent when
     one of their buttons is clicked or when one of their menu items is
     selected.

     Applications almost always provide Windows with this information in
     their resources (they could actually define menus and controls
     dynamycally, on the fly, but few applications take advantage of this).
     These resources are part of the NE executable and are available for
     our merry snooping around.

     This inspections of the resources in an EXE file is carried out by
     means of special utilities, like RESDUMP, included with Windows source
     (-> in my tool page). For example (I am using "-verbose" mode):

     DIALOG              10   (0Ah), "Task List"       [ 30, 22,160,107]
     FONT "Helv"
         LISTBOX         100  (64h), ""                [  3,  3,154, 63]
         DEFPUSHBUTTON   1    (01h), "&Switch To"      [  1, 70, 45, 14]
         PUSHBUTTON      101  (65h), "&End Task"       [ 52, 70, 45, 14]
         PUSHBUTTON      2    (02h), "Cancel"          [103, 70, 55, 14]
         STATIC          99   (63h), ""                [  0, 87,160,  1]
         PUSHBUTTON      102  (66h), "&Cascade"        [  1, 90, 45, 14]
         PUSHBUTTON      103  (67h), "&Tile"           [ 52, 90, 45, 14]
         PUSHBUTTON      104  (68h), "&Arrange Icons"  [103, 90, 55, 14]

     YEAH! It's now apparent what the numbers 64h, 65h etc. mean. Imagine
     you would write Taskmanager yourself... you would write something on
     these lines:

          #define   IDD_SWITCHTO        IDOK
          #define   IDD_TASKLIST        0x64
          #define   IDD_ENDTASK         0x65
          #define   IDD_CASCADE         0x66
          #define   IDD_TILE            0x67
          #define   IDD_ARRANGEICONS    0x68

     Let's look back at the last block of code... it makes now a lot more
     sense:

     ON_COMMAND:
       ; We are handling WM_COMMAND, therefore wParam is here idItem,
       ; i.e. a control or menu item identifier
      1.022D >8B460A  mov  ax, wParam   ;[bp+0A]
      1.0230  3D6800  cmp  ax, 0068     ;is it the ID 68h?
      ...
      1.023D >FEC8    dec   al              ;1=IDOK=IDD_SWITCHTO
      1.023F  7420    je    ON_SWITCHTO ;0261
      1.0241  FEC8    dec   al          ;1+1=2=ID_CANCEL
      1.0243  7503    jne   neither_OK_nor_CANCEL          ;0248
      1.0245  E94701  jmp   ON_CANCEL   ;038F
     neither_OK_nor_CANCEL:
      1.0248 >2C62    sub   al, 62      ;2+62=64= IDD_TASKLIST
      1.024A  742A    je    ON_TASKLIST ;0276
      1.024C  FEC8    dec   al          ;64+1=65= IDD_ENDTASK
      1.024E  7432    je    ON_ENDTASK  ;0282
      1.0250  2C01    sub   al, 01      ;65+1=66= IDD_CASCADE
      1.0252  7303    jnb   check_for_TILE             ;0257
      1.0254  E94601  jmp   039D        ;something different
     check_for_TILE:
      1.0257 >2C01    sub   al, 01      ;66+1=67= IDD_TILE
      1.0259  7703    ja    025E        ;it's something else
      1.025B  E9D200  jmp   ON_TILE_or_CASCADE         ;0330

     In this way we have identified location 0330 as the place where
     Taskman's "Cascade" and "Tile" buttons are handled... we have renaimed
     it ON_TILE_or_CASCADE... let's examine its code and ensure it makes
     sense:

     ON_TILE_or_CASCADE:
      1.0330 >56             push  hwndDlg          ;si
      1.0331  6A00           push  0000
      1.0333  9A6F030000     call  USER.SHOWWINDOW

      1.0338  9A74030000     call  USER.GETDESKTOPWINDOW
      1.033D  8BF8           mov   di, ax           ;hDesktopWnd
      1.033F  837E0A66       cmp   word ptr wParam, 0066 ;IDD_CASCADE
      1.0343  750A           jne   ON_TILE          ;034F
      1.0345  57             push  di               ;hDesktopWnd
      1.0346  6A00           push  0000
      1.0348  9AFFFF0000     call  USER.CASCADECHILDWINDOWS
      1.034D  EB2F           jmp   037E
     ON_TILE:
      1.034F >57             push  di
      1.0350  6A10           push  0010
      1.0352  9AFFFF0000     call  USER.GETKEYSTATE
      1.0357  3D0080         cmp   ax, 8000
      1.035A  7205           jb    0361
      1.035C  B80100         mov   ax, 0001 ;1= MDITILE_HORIZONTAL
      1.035F  EB02           jmp   0363

      1.0361 >2BC0           sub   ax, ax   ;0= MDITILE_VERTICAL

      1.0363 >50             push  ax
      1.0364  9AFFFF0000     call  USER.TILECHILDWINDOWS
      1.0369  EB13           jmp   037E

     Yes, it makes a lot of sense: We have found that the "Cascade" option
     in Tile manager, after switching through the usual bunch of
     switch/case loops, finally ends up calling an undocumented Windows API
     function: CascadeChildWindows()... similarly, the "Tile" routine ends
     up calling TileChildWindow().

     One thing screams for attention in the disassembled listing of
     ON_TILE: the call to GetKeyState().

     As an example of the kind of information you should be able to gather
     for each of these functions, if you are serious about cracking, I'll
     give you now here, in extenso, the definition from H. Schildt's
     "General purpose API functions", Osborne's Windows Programming Series,
     Vol. 2, 1994 edition (I found both this valuable book and its
     companion: volume 3: "Special purpose API functions", in a second hand
     shop, in february 1996, costing the equivalent of a pizza and a
     beer!). Besides this function is also at times important for our
     cracking purposes, and represents therefore a good choice. Here the
     description from pag.385:

          void GetKeyState(int iVirKey)

          Use GetKeyState() to determine the up, down or toggled status of
          the specified virtual key. iVirKey identifies the virtual key. To
          return the status of a standard alphanumeric character in the
          range A-Z, a-z or 0-9, iVirKey must be set equal to its ANSI
          ASCII value. All other key must use their related virtual key
          codes. The function returns a value indicating the status of the
          selected key. If the high-order bit of the byte entry is 1, the
          virtual key is pressed (down); otherwise it is up. If you examine
          a byte emlement's low-order bit and find it to be 1, the virtual
          key has been toggled. A low-order bit of 0 indicates that the key
          is untoggled.

          Under Windows NT/Win32, this function returns type SHORT.

          Usage:

          If your application needs to distinguish wich ALT, CTRL, or SHIFT
          key (left or right) has been pressed, iVirKey can be set equal to
          one of the following:

              VK_LMENU       VK_RMENU
              VK_LCONTROL    VK_RCONTROL
              VK_LSHIFT      VK_RSHIFT

          Setting iVirKey equal to VK_MENU, VK_CONTROL or VK_SHIFT
          instructs GetKeyState() to ignore left and right, and only to
          report back the status of teh virtual key category. This ability
          to distinguish among virtual-key states is only available with
          GetKeyState() and the related functions listed below.

          The following fragment obtains the state of the SHIFT key:

               if(GetKeyState(VK_SHIFT) {
                                        ...
                                        }

          Related Functions:

          GetAsyncKeyState(), GetKeyboardState(), MapVirtualKey(),
          SetKeyboardState()

     Ok, let's go on... so we have in our code a "funny" call to
     GetKeyState(). Because the Windows USer's Guide says nothing about
     holding down a "state" (shift/ctrl/alt) key while selecting a button,
     this sounds like another undocumented "goodie" hidden inside TASKMAN.

     Indeed, if you try it out on the 3.1 Taskman, you'll see that clicking
     on the Tile button arranges all the windows on the desktop side by
     side, but if you hold down the SHIFT key while clicking on the Tile
     button, the windows are arranged in a stacked formation.

     To summarize, when the 3.1. Taskman Tile button is selected, the code
     that runs in response looks like this:

     Tile:
          ShowWindow(hWndDlg, SW_HIDE);      // hide TASKMAN
          hDesktopWnd = GetDesktopWindow();
          if (GetKeyState(VK_SHIFT) == 0x8000)
               TileChildWindows(hDesktopWnd, MDITILE_HORIZONTAL);
          else
               TileChildWindows(hDesktopWnd, MDITILE_VERTICAL);

     Similarly, the CASCADE option in 3.1. TASKMAN runs the following code:

     Cascade:
          ShowWindow(hWndDlg, SW_HIDE);      // hide TASKMAN
          CAscadeChildWindows(GetDesktopWindow(), 0);

     We can then proceed through each TASKMAN option like this, rendering
     the assembly language listing into more concise C.

     The first field to examine in TASKMAN is the Task List itself: how is
     the "Task List" Listbox filled with the names of each running
     application?

     What the List box clearly shows is a title bar for each visible top
     level window, and the title bar is undoubtedly supplied with a call to
     GetWindowText()... a function that obtains a copy of the specified
     window handle's title.

     But how does TASKMAN enumerate all the top-level Windows? Taskman
     exports TASKMANDLGPROC, but does not export any enumeration procedure.

     Most of the time Windows programs iterate through all existing windows
     by calling EnumWindows(). Usually they pass to this function a pointer
     to an application-supplied enumeration function, which therefore MUST
     be exported. This callback function must have following prototype:

     BOOL CALLBACK EnumThreadCB(HWND hWnd, LPARAM lParam)

     Of course, the name a programmer chooses for such an exported function
     is arbitrary. hWnd will receive the handle of each thread-associated
     window.lParam receives lAppData, a 32-bit user- defined value. This
     exported function must return non-zero to receive the next enumerated
     thread-based window, or zero to stop the process.

     But here we DO NOT have something like TASKMANENUMPROC in the list of
     exported functions... what's going on? Well... for a start TASKMAN IS
     NOT calling EnumWindows()... Taskman uses a GetWindow() loop to fill
     the "Task List" list box, study following C muster, sipping a good
     cocktail and comparing it with the disassembled code you have printed:

     Task List:
          listbox = GetDlgItem(hWndDlg, IDD_TASKLIST);
          hwnd = GetWindow(hwndDlg, GW_HWNDFIRST);
          while (hwnd)
           {   if ((hwnd != hwndDlg) &&    //excludes self from list
                  IsWindowVisible(hwnd) &&

                  GetWindow(hwnd, GW_OWNER))
               {    char buf[0x50];
                    GetWindowText(hwnd, buf, 0x50); // get titlebar
                    SendMessage(listbox, LB_SETITEMDATA,
                         SendMessage(listbox, LB_ADDSTRING, 0, buf),
                         hwnd);         // store hwnd as data to go
               }                        // with the titlebar string
               hwnd = GetWindow(hwnd, GW_HWNDNEXT);
          }
          SendMessage(lb, LB_SETCURSEL, 0, 0); // select first item

     The "End Task" opton in Taskman just sends a WM_CLOSE message to the
     selected window, but only if it's not a DOS box. TASKMAN uses the
     undocumented IsWinOldApTask() function, in combination with the
     documented GetWindowTask() function, to determine if a given HWND
     corresponds to a DOS box:

     End Task:
       ...          // boring details omitted
       if(IsWinOldApTask(GetWindowTask(hwndTarget)))
         MaybeSwitchToSelecetedWindow(hwndTarget);

       if(IsWindow(hwndTarget) &&
         (! (GetWindowLong(hwndTarget, GWL   5STYLE) & WS_DISABLED))
       {
          PostMessage(hwndTarget, WM_CLOSE, 0, 0);
       }

     The "Arrange Icons" option simply runs the documented
     ARrangeIconicWindows() function:

     Arrange Icons:
       Showwindow(hWndDlg, SW_HIDE);
       ArrangeIconiCWindows(GetDesktopWindow());

     The "Switch To" option in TASKMAN is also interesting. Like "Tile" and
     "Cascade", this too it's just a user-interface covering an
     undocupented Windows API function, in this case SwitchToThisWindow().

     Let's walk through the process of deciphering a COMPLETELY unlabelled
     Windows disassembly listing, that will be most of the time your
     starting situation when you crack, and let's turn it into a labelled C
     code.

     By the way, there does exist an interesting school of research, that
     attempts to produce an "EXE_TO_C" automatical converter. The only
     cracked version of this program I am aware of is called E2C.EXE, is
     198500 bytes long, has been developed in 1991 by "The Austin Code
     Works and Polyglot International" in Jerusalem (Scott Guthery:
     guthery@acw.com), and has been boldly brought to the cracking world by
     Mithrandir/AlPhA/MeRCeNarY. Try to get a copy of this tool... it can
     be rather interesting for our purposes ;-)

     Here is the raw WCB disassembled code for a subroutine within TASKMAN,
     called from the IDD_SWITCHTO handling code in TaskManDlgProc():

      1.0010 >55             push    bp
      1.0011  8BEC           mov     bp, sp
      1.0013  57             push    di
      1.0014  56             push    si
      1.0015  FF7604         push    word ptr [bp+04]
      1.0018  681A04         push    041A
      1.001B  FF7604         push    word ptr [bp+04]
      1.001E  680904         push    0409
      1.0021  6A00           push    0000
      1.0023  6A00           push    0000
      1.0025  6A00           push    0000
      1.0027  9A32000000     call    USER.SENDMESSAGE
      1.002C  50             push    ax
      1.002D  6A00           push    0000
      1.002F  6A00           push    0000
      1.0031  9AEF010000     call    USER.SENDMESSAGE
      1.0036  8BF8           mov     di, ax
      1.0038  57             push    di
      1.0039  9A4C000000     call    USER.ISWINDOW
      1.003E  0BC0           or      ax, ax
      1.0040  742A           je      006C
      1.0042  57             push    di
      1.0043  9AFFFF0000     call    USER.GETLASTACTIVEPOPUP
      1.0048  8BF0           mov     si, ax
      1.004A  56             push    si
      1.004B  9AA4020000     call    USER.ISWINDOW
      1.0050  0BC0           or      ax, ax
      1.0052  7418           je      006C
      1.0054  56             push    si
      1.0055  6AF0           push    FFF0
      1.0057  9ACD020000     call    USER.GETWINDOWLONG
      1.005C  F7C20008       test    dx, 0800
      1.0060  750A           jne     006C
      1.0062  56             push    si
      1.0063  6A01           push    0001
      1.0065  9AFFFF0000     call    USER.SWITCHTOTHISWINDOW
      1.006A  EB07           jmp     0073

      1.006C >6A00           push    0000
      1.006E  9ABC020000     call    USER.MESSAGEBEEP

      1.0073 >5E             pop     si
      1.0074  5F             pop     di
      1.0075  8BE5           mov     sp, bp
      1.0077  5D             pop     bp
      1.0078  C20200         ret     0002

     The RET 0002 at the end tells us that this is a near Pascal function
     that expects one WORD parameter, which appears as [bp+4] at the top of
     the code.

     Because [bp+4] is being used as the first parameter to SendMessage(),
     it must be an HWND of some sort.

     Here is the muster for SendMessage(): LRESULT SendMessage(HWND hWnd,
     UINT uMsg, WPARAM wMsgParam1, LPARAM lMsgParam2), where hWnd
     identifies the Window receiving the message, uMsg identifies the
     message being sent, wMsgParam1 & lMsgParam2 contain 16 bits and 32
     bits of message-specific information.

     Finally, we don't see anything being moved into AX or DX near the end
     of the function, so it looks as if this function has no return value:

     void near pascal some_func(HWND hwnd)

     Let's look once more at it... the function starts off with two nested
     calls to SendMessage (using the message numbers 41Ah and 409h). These
     numbers are greater than 400h, they must therefore be WM_USER+XX
     values. Windows controls such as edit, list and combo boxes all use
     WM_USER+XX notification codes.

     The only appropriate control in TASKMAN is the list box, so we can
     just look at the list of LB_XXX codes in WINDOWS.H. 1Ah is 26 decimal,
     therefore 41Ah is WM_USER+26, or LB_GETITEMDATA. Let's see what
     Osborne's "Special Purpose API functions" says about it (pag.752):

     LB_GETITEMDATA
      When sent: To return the value associated with a list-box item.
      wParam:    Contains the index to the item in question
      lParam:    Not used, must be 0
      Returns:   The 32-bit value associated with the item

     Similarly, 409h is WM_USER+9, which in the case of a list box means
     LB_GETCURSEL. We saw earlier that TASKMAN uses LB_SETITEMDATA to store
     each window title's associated HWND. LB_GETITEMDATA will now retrive
     this hwnd:

       hwnd = SendMessage(listbox, LB_GETITEMDATA,
          SendMessage(listbox, LB_GETCURSEL, 0, 0), 0);

     Notice that now we are caling the parameter to some_func() a listbox,
     and that the return value from LB_GETITEMDATA is an HWND.

     How would we know it's an hwnd without our references? We can see the
     LB_GETITEMDATA return value (in DI) immediatly being passed to
     IsWindow() at line 1.0039:

      ; IsWindow(hwnd = SendMessage(...));
     1.0031 9AEF010000   call far ptr SENDMESSAGE
     1.0036 8BF8         mov  di, ax
     1.0038 57           push di
     1.0039 9A4C000000   call far ptr ISWINDOW

     Next, the hwnd is passed to GetLastActivePopup(), and the HWND that
     GetLastActivePopup() returns is then checked with IsWindow()...
     IsWindow() returns non-zero if the specified hWnd is valid, and zero
     if it is invalid:

      ; IsWindow(hwndPopup = GetLastActivePopup(hwnd));
     1.0042  57          push    di
     1.0043  9AFFFF0000  call    USER.GETLASTACTIVEPOPUP
     1.0048  8BF0        mov     si, ax      ; save hwndPopup in SI
     1.004A  56          push    si
     1.004B  9AA4020000  call    USER.ISWINDOW

     Next, hwndPopup (in SI) is passed to GetWindowLong(), to get
     informations about this window. Here is time to look at WINDOWS.H to
     figure out what 0FFF0h at line 1.055 and 800h at line 1.005C are
     supposed to mean:

      ; GetWindowLong(hwndPopup, GWL_STYLE) & WS_DISABLED
     1.0054  56          push  si             ;hwndPopup
     1.0055  6AF0        push  GWL   5STYLE   ;0FFF0h = -16
     1.0057  9ACD020000  call  USER.GETWINDOWLONG
     1.005C  F7C20008    test  dx, 0800       ;DX:AX= 800:0= WS_DISABLED

     Finally, as the whole point of this exercise, assuming this checked
     window passes all its tests, its last active popup is switched to:

      ; SwitchToRhisWindow(hwndPopup, TRUE)
     1.0062  56         push  si             ;hwndPopup

     1.0063  6A01       push  0001
     1.0065  9AFFFF0000 call  USER.SWITCHTOTHISWINDOW

     It's here that all possible questions START: SwitchToThisWindow is not
     documented... therefore we do not know the purpose of its second
     parameter, apparently a BOOL. We cannot even tell why
     SwitchToThisWindow() is being used... when SetActiveWindow(),
     SetFocus() or BringWindowToTop() might do the trick. And why is the
     last active popup and not the window switched to?

     But let's resume for now our unearthed mysterious function, that will
     switch to the window selected in the Task List if the window meets all
     the function's many preconditions:

     void MaybeSwitchToSelectedWindow(HWND listbox)
     {
       HWND hwnd, hwndPopup;
       // first figure out wich window was selected in the Task List
       if (IsWindow(hwnd = SendMessage(listbox, LB_GETITEMDATA,
           SendMessage(listbox, LB_GETCURSEL, 0, 0), 0)))
        {
         if (IsWindow(hwndPopup = GetLastActivePopup(hwnd)))
         {
          if (! (GetWindowLong(hwndPopup, GWL_STYLE) & WS_DISABLED))
          {
             SwitchToThisWindow(hwndPopup, TRUE);
             return;
          }
         }
       MessageBeep(0);        //Still here... error!
     }

     Now we have a good idea of what TASKMAN does (it sure took a long time
     to understand those 3K bytes of code!). In the next lessons we'll use
     what we have learned to crack together some common Windows programs.
     (->lesson 3)

                                                                     FraVia


