home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hacks & Cracks
/
Hacks_and_Cracks.iso
/
hackersclub
/
km
/
library
/
cracking
/
fravia-taskman1.txt
< prev
next >
Wrap
Text File
|
1998-03-25
|
32KB
|
647 lines
How To Disassemble A Windows Program
I think this small exercise (shamelessly abducted from Schulman's book
-> see here) could be very helpful for all the future crackers trying
to get some bearings during their difficult disassembly of Windows
programs.
One of the problems in reverse engineering, is that nobody teaches you
how to do it, and you have mostly to learn alone the relevant
techniques, loosing an enormous amount of time.
Disassembling Windows with a reverse engineering approach is *very*
useful for actual cracking purposes, and it's time to form a new
generation of Windows crackers, since the ghastly Microsoft domination
will not easily be crushed without many more good crackers to help us.
What +ORC writes and teaches in his lessons is fundamental, but
unfortunately he does not teach the "elementary" side of cracking
Windows (for DOS cracking, on the contrary, the Crackbook of Uncle Joe
is a good primer for beginners and intermediate alike), so I'll try to
help here to form a strong generation of little strong crackers... as
+ORC wrote to me: "we are all throwing seeds in the air, some of them
will land astray, but some of them will grow".
Remember that cracking Windows is *very* different, in approach and in
techniques, from cracking DOS. The older ones (that I unconditionally
respect) do not seem to grab it totally... they are probably so
experienced that they can use more or less the same techniques in
cracking all OSs... but in my (humble) opinion, that's not necessarily
the best approach... you see, cracking Windows is "puzzle solving",
cracking DOS is "playing chess"... you'll understand what I mean if
you read what follows.
Please do excuse my shortcomings both in the techniques I teach (I am
an autodidact) and in the language I use.
If at any time you feel you should need more references, check the
Windows 3.1. SDK Programmer's Reference, Volume 1: Overview, Chapter
22, Windows Application Startup.
A little knowledge of the C language is required in order to
understand a part of the following (you better understand it right
now: the only existing programming language is C, most applications
are written in C, "real" programmers use C... you may dislike it, but
that's the reality, so you better get a little knowledge of C
programming as soon as you can, if you want to crack more
effectively... you'll find enough C tutorials on the net). This said,
most of the following can be used even if you do not know C.
Disassembling Taskman
As example for this introduction, I have chosen Taskman.exe, the small
program you'll find inside your C:\WINDOWS directory... you can invoke
it anytime typing CTRL+ESC in Windows 3.1.
I have done it because Schulman has already (very well) worked on it,
and therefore he spares me a lot of work, and also because I agree
totally with him in his choice: Taskman it's a very good example for
all newbys to Windows cracking. Actually it's a pity that you cannot
(yet) find Schulman's books on the net... I believe they should be
indisputably there! (Anybody with a good scanner reading this?).
Let's start from the beginning... by looking at TASKMAN's startup
code. Taskman is a very small win 3.1 program, but it's rich in
surprises, as you'll see. After you disassembly taskman.exe with WCB
(see below) and *after* you have printed the listing, you may use the
"Loader" utility to pop out inside winice at the beginning of Taskman:
start:
1FBF:4B9 33ED XOR BP,BP ;begins
1FBF:4BB 55 PUSH BP ;save BP
1FBF:4BC 9A8D262701 CALL KERNEL!INITTASK
...
So we are set for snooping around "live", but first (and that's very
important for Windows programs) we have to prepare a good disassembled
listing of our target. You see, in DOS such a work does not make much
sense, because the disassembled listing would not differ much from
what you get on screen through softice, but in Windows, on the
contrary, we can get quite a lot more out of all the information that
is already present inside our target. The following explains this
point:
You can use any good disassembler (like Winsourcer, from V
communication, a good version, cracked by the ubiquitous Marquis de
Soiree, is available on the web) but i'll use the disassembled listing
of WCB (Windows CodeBack -> download version 1.5. from my "tools"
page: here).
WCB is a very good Win 3.1. disassembler, created by the ungarian
codemaster Leslie Pusztai (pusztail@tigris.klte.hu), and, in my modest
opinion, it's far better than sourcer. If you use it, remember that it
works from DOS: the main rule is to create first of all the *.EXL
files for the necessary "mysterious" *.dll with the command:
wcb -x [mysterious.dll]and you'll be able, afterwards, to disassemble
the *.exe that called them.
But all this is not necessary for humble Taskman.exe, where we get
following header information: Filename: TASKMAN.EXE Type: Segmented
executable Module description: Windows Task Manager 3.1 Module name:
TASKMAN Imported modules:
Filename: TASKMAN.EXE
Type: Segmented executable
Module description: Windows Task Manager 3.1
Module name: TASKMAN
Imported modules:
1: KERNEL
2: USER
Exported names by location:
1:007B 1 TASKMANDLGPROC
Program entry point: 1:04B9
WinMain: 1:03AE
and we can get straight the entry point code:
1.04B9 ; Program_entry_point
1.04B9 >33ED xor bp, bp
1.04BB 55 push bp
1.04BC 9AFFFF0000 call KERNEL.INITTASK
1.04C1 0BC0 or ax, ax
1.04C3 744E je 0513
1.04C5 81C10001 add cx, 0100
1.04C9 7248 jb 0513
1.04CB 890E3000 mov [0030], cx
1.04CF 89363200 mov [0032], si
1.04D3 893E3400 mov [0034], di
1.04D7 891E3600 mov [0036], bx
1.04DB 8C063800 mov [0038], es
1.04DF 89163A00 mov [003A], dx
1.04E3 33C0 xor ax, ax
1.04E5 50 push ax
1.04E6 9AFFFF0000 call KERNEL.WAITEVENT
1.04EB FF363400 push word ptr [0034]
1.04EF 9AFFFF0000 call USER.INITAPP
1.04F4 0BC0 or ax, ax
1.04F6 741B je 0513
1.04F8 FF363400 push word ptr [0034]
1.04FC FF363200 push word ptr [0032]
1.0500 FF363800 push word ptr [0038]
1.0504 FF363600 push word ptr [0036]
1.0508 FF363A00 push word ptr [003A]
1.050C E89FFE call WinMain
1.050F 50 push ax
1.0510 E890FF call 04A3
This is similar to the standard startup code that you'll find in
nearly *every* Windows program. It calls three functions: InitTask(),
WaitEvent(), and InitApp().
We know jolly well about InitTask(), but let's imagine that we would
have here a more mysterious routine than these, and that we would like
to know what for items are hold in the CX, SI etc. register on return
from InitTask() without disassembling everything everywhere... how
should we proceed?
First of all let's see if the locations [0030] - [003A] are used
elsewhere in our program... this is typical when you work with
disassembled listings: to find out what one block of code means, you
need most of the time to look first at some other block of code. Let's
see.. well, yes! Most of the locations are used again a few lines down
(1.04F8 to 1.0508).
Five words are being pushed on the stack as parameters to WinMain().
If only we knew what those enigmatic parameter were... but wait: we do
actually know what those parameters are! WinMain(), the function being
called from this code, always looks like:
int PASCAL WinMain(WORD hInstance, WORD hPrevInstance,
LPSTR lpCmdLine, int nCmdShow);
And we (should) know that in the Pascal calling convention, which is
used extensively in Windows because it produces smaller code than the
cdecl calling convention, arguments are pushed on the stack in the
same order as they appear inside the function declaration. That's a
good news for all little crackers!
Thus, in our example, [0034] must be hInstance, [0032] must be
hPrevinstance, [0038]:[0036] are segment and offset of lpcmdline and
[003A] must be nCmdshow.
What makes this important is that we can now go and replace *every*
occurrence of [0034] by a more useful name such as hInstance, every
occurrence of [0032] by hPrevInstance and so on. This clarify not just
this section of the listing, but every section of the listing that
refers to these variables. Such global substitutions of useful names
for placeholder names or addresses is indispensable when working with
a disassembled listing. After applying these changes to the fragment
shown earlier, we end up with something more understandable:
1.04CB 890E3000 mov [0030], cx
1.04CF 89363200 mov hPrevInstance, si
1.04D3 893E3400 mov hInstance, di
1.04D7 891E3600 mov lpCmdLine+2, bx
1.04DB 8C063800 mov lpCmdLine, es
1.04DF 89163A00 mov nCmdShow, dx
1.04E3 33C0 xor ax, ax
1.04E5 50 push ax
1.04E6 9AFFFF0000 call KERNEL.WAITEVENT
1.04EB FF363400 push word ptr hInstance
1.04EF 9AFFFF0000 call USER.INITAPP
1.04F4 0BC0 or ax, ax
1.04F6 741B je 0513
1.04F8 FF363400 push word ptr hInstance
1.04FC FF363200 push word ptr hPrevInstance
1.0500 FF363800 push word ptr lpCmdLine
1.0504 FF363600 push word ptr lpCmdLine+2
1.0508 FF363A00 push word ptr nCmdShow
1.050C E89FFE call WinMain
Thus if we didn't already know what InitTask() returns in various
register (our Taskman here is only an example for your later work on
much more mysterious target programs), we could find it out right now,
by working backwards from the parameters to WinMain(). Windows
disassembling (and cracking) is like puzzle solving: the more little
pieces fall into place, the more you get the global picture. Trying to
disassemble Windows programs without this aid would be unhealthy: you
would soon delve inside *hundreds* of irrelevant calls, only because
you did not do your disassemble homework in the first place.
It was useful to look at the startup code because it illustrated the
general principle of trying to substitute useful names such as
hPrevInstance for useless labels such as [0034]. But, generally, the
first place we'll look examining a Windows program is WinMain(). Here
the code from WCB:
1.03AE ; WinMain
1.03AE >55 push bp
1.03AF 8BEC mov bp, sp
1.03B1 83EC12 sub sp, 0012
1.03B4 57 push di
1.03B5 56 push si
1.03B6 2BFF sub di, di
1.03B8 397E0A cmp [bp+0A], di
1.03BB 7405 je 03C2
1.03BD 2BC0 sub ax, ax
1.03BF E9CC00 jmp 048E
1.03C2 >C47606 les si, [bp+06]
1.03C5 26803C00 cmp byte ptr es:[si], 00
1.03C9 7453 je 041E
1.03CB 897EF2 mov [bp-0E], di
1.03CE EB1E jmp 03EE
1.03D0 >26803C20 cmp byte ptr es:[si], 20
1.03D4 741E je 03F4
1.03D6 B80A00 mov ax, 000A
1.03D9 F72E1000 imul word ptr [0010]
1.03DD A31000 mov [0010], ax
1.03E0 8BDE mov bx, si
1.03E2 46 inc si
1.03E3 268A07 mov al, byte ptr es:[bx]
1.03E6 98 cbw
1.03E7 2D3000 sub ax, 0030
1.03EA 01061000 add [0010], ax
1.03EE >26803C00 cmp byte ptr es:[si], 00
1.03F2 75DC jne 03D0
1.03F4 >26803C00 cmp byte ptr es:[si], 00
1.03F8 741B je 0415
1.03FA 46 inc si
1.03FB EB18 jmp 0415
1.03FD >B80A00 mov ax, 000A
1.0400 F72E1200 imul word ptr [0012]
1.0404 A31200 mov [0012], ax
1.0407 8BDE mov bx, si
1.0409 46 inc si
1.040A 268A07 mov al, byte ptr es:[bx]
1.040D 98 cbw
1.040E 2D3000 sub ax, 0030
1.0411 01061200 add [0012], ax
1.0415 >26803C00 cmp byte ptr es:[si], 00
1.0419 75E2 jne 03FD
1.041B 8B7EF2 mov di, [bp-0E]
1.041E >6A29 push 0029
1.0420 9AF9000000 call USER.GETSYSTEMMETRICS
1.0425 50 push ax
1.0426 1E push ds
1.0427 681600 push 0016
1.042A 9AFFFF0000 call KERNEL.GETPROCADDRESS
1.042F 8946F4 mov [bp-0C], ax
1.0432 8956F6 mov [bp-0A], dx
1.0435 0BD0 or dx, ax
1.0437 7407 je 0440
1.0439 6A01 push 0001
1.043B 6A01 push 0001
1.043D FF5EF4 call far ptr [bp-0C]
1.0440 >68FFFF push selector 1:0000
1.0443 687B00 push 007B
1.0446 FF760C push word ptr [bp+0C]
1.0449 9AFFFF0000 call KERNEL.MAKEPROCINSTANCE
1.044E 8BF0 mov si, ax
1.0450 8956FA mov [bp-06], dx
1.0453 0BD0 or dx, ax
1.0455 7426 je 047D
1.0457 FF760C push word ptr [bp+0C]
1.045A 6A00 push 0000
1.045C 6A0A push 000A
1.045E 6A00 push 0000
1.0460 8B46FA mov ax, [bp-06]
1.0463 50 push ax
1.0464 56 push si
1.0465 8976EE mov [bp-12], si
1.0468 8946F0 mov [bp-10], ax
1.046B 9AFFFF0000 call USER.DIALOGBOX
1.0470 8BF8 mov di, ax
1.0472 FF76F0 push word ptr [bp-10]
1.0475 FF76EE push word ptr [bp-12]
1.0478 9AFFFF0000 call KERNEL.FREEPROCINSTANCE
1.047D >8B46F6 mov ax, [bp-0A]
1.0480 0B46F4 or ax, [bp-0C]
1.0483 7407 je 048C
1.0485 6A01 push 0001
1.0487 6A00 push 0000
1.0489 FF5EF4 call far ptr [bp-0C]
1.048C >8BC7 mov ax, di
1.048E >5E pop si
1.048F 5F pop di
1.0490 8BE5 mov sp, bp
1.0492 5D pop bp
1.0493 C20A00 ret 000A
Let's begin from the last line: ret 000A. In the Pascal calling
convention, the callee is responsible for clearing its arguments off
the stack; this explains the RET A return. In this particular case,
WinMain() is being invoked with a NEAR call. As we saw in the startup
code, with the Pascal calling convention, arguments are pushed in
"forward" order. Thus, from the prospective of the called function,
the last argument always has the *lowest* positive offset from BP
(BP+6 in a FAR call and BP+4 in a NEAR call, assuming the standard
PUSH BP -> MOV BP,SP function prologue, like at the beginning of this
WinMain().
Now write the following in your cracking notes (the ones you really
keep on your desk when you work... close to your cocktail glass):
function parameters have *positive* offsets from BP, local variables
have *negative* offsets from BP.
What does all this mean... I hear some among you screaming... well, in
the case of WinMain(), and in a small-model program like Taskman,
which starts from BP+4, you'll have:
int PASCAL WinMain(HANDLE hInstance, HANDLE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow);
nCmdShow = word ptr [bp+4]
lpCmdLine = dword ptr [bp+6]
hPrevInstance = word ptr [bp+0Ah]
hInstance = word ptr [bp+0Ch]
Yeah... let's rewrite it:
1.03B6 2BFF sub di, di
1.03B8 397E0A cmp hPrevInstance, di
1.03BB 7405 je 03C2
1.03BD 2BC0 sub ax, ax
1.03BF E9CC00 jmp 048E
1.03C2 >C47606 les si, dword ptr lpCmdLine
1.03C5 26803C00 cmp byte ptr es:[si], 00
We can now see, for example, that WinMain() checks if hPrevInstance is
zero (sub di,di); if it isn't, it immediately jump to the pops and
exits (jmp 048E).
Look at the code of WinMain() once more... notice that our good
Taskman appears to be inspecting its command line... funny: the
Windows documentation says nothing about command line arguments to
Taskman... Look around location 1.03D0 above, you'll see that Taskman
appears to be looking for a space (20h), getting a character from the
command line, multiplying it by 10 (0Ah), subtracting the character
zero (30h) and doing other things that seem to indicate that it's
looking for one or more *numbers*. The code line 1.03E7 SUB ax,30h
it's a typical code line inside many routines checking for numbers.
The hex ascii code for numbers is 30 for 0 to 39 for 9, therefore the
transmutation of an ascii code in hex *number* is pretty easy: mov al,
your_number and sub ax,30... you'll find it very often.
Rather than delve further into the code, it next makes sense to *run*
taskman, feeding it different numbers on the command line, and seeing
what it does (it's surprising how few crackers think of actually going
in and *running* a program before spending much time looking at its
code).
Normally Taskman runs when you type CTRL+ESC in Windows, but its just
a regular program, that can be run with a command line, like any other
program.
Indeed, running "TASKMAN 1" behaves differently from just running
"TASKMAN": it positions the Task List in the upper-left corner of the
screen, instead of in the middle. "TASKMAN 666 666" (the number of the
beast?) seems to position it in the lower right corner.
Basically, the command line numeric arguments seem to represent an
(x,y) position for our target, to override its default position in the
middle of the screen.
So you see, there are hidden 'goodies' and hidden 'secrets' even
behind really trivial little programs like Taskman (and believe me:
being able to identify this command line checking will be very useful
;-) when you'll crack applications and/or games that *always* have
backdoors and hidden goodies).
Back to the code (sip your favourite cocktail during your
scrutinies... may I suggest a Traitor? -> see the legendary FraVia's
cocktail page here) you can see that the variables [0010] and [0012]
are being manipulated. What are these for?
The answer is *not* to stare good and hard at this code until it makes
sense, but to leave this area and see how the variables are used
elsewhere in the program... maybe the code elsewhere will be easier to
understand (for bigger applications you could in this case use a
Winice breakpoint on memory range, but we'll remain with our WCB
disassembly listing).
In fact, if we search for data [0010] and [0012] we find them used as
arguments to a Windows API function:
1.018B >A31200 mov [0012], ax
1.018E FF760E push word ptr [bp+0E]
1.0191 FF361000 push word ptr [0010]
1.0195 50 push ax
1.0196 56 push si
1.0197 57 push di
1.0198 6A00 push 0000
1.019A 9AFFFF0000 call USER.MOVEWINDOW
This shows us *immediately* what [0010] and [0012] are. MoveWindows()
is a documented function, whose prototype is:
void FAR PASCAL MoveWindow(HWND hwnd, int nLeft, int nTop,
int nWidth, int nHeight, BOOL fRepaint);
1.018B >A31200 mov [0012], ax
1.018E FF760E push word ptr [bp+0E] ;hwnd
1.0191 FF361000 push word ptr [0010] ;nLeft
1.0195 50 push ax ;nTop
1.0196 56 push si ;nWidth
1.0197 57 push di ;nHeight
1.0198 6A00 push 0000 ;fRepaint
1.019A 9AFFFF0000 call USER.MOVEWINDOW
In other words, [0010] has to be nLeft and [0012] (whose contents have
been set from AX) has to be nTop.
Now you'll do another global "search and replace" on your WCB
disassembly, changing every [0010] in the program (not just the one
here) to nLeft, and every [0012] to nTop.
A lot of Windows cracking is this easy: all Windows programs seem to
do is call API functions, most of these functions are documented and
you can use the documentation to label all arguments to the function.
You then transfer these labels upward to other, possibly quite distant
parts of the program.
In the case of nLeft [0010] and nTop [0012], suddenly the code in
WinMain() makes much more sense:
1.03C2 >C47606 les si, dword ptr lpCmdLine
1.03C5 26803C00 cmp byte ptr es:[si], 00 ; no cmd line?
1.03C9 7453 je 041E ; go elsewhere
1.03CB 897EF2 mov [bp-0E], di
1.03CE EB1E jmp 03EE
1.03D0 >26803C20 cmp byte ptr es:[si], 20 ; if space
1.03D4 741E je 03F4 ; go elsewhere
1.03D6 B80A00 mov ax, 000A
1.03D9 F72E1000 imul nLeft ; nleft *= 10
1.03DD A31000 mov nLeft, ax
1.03E0 8BDE mov bx, si
1.03E2 46 inc si
1.03E3 268A07 mov al, es:[bx]
1.03E6 98 cbw ; ax = char
1.03E7 2D3000 sub ax, 0030 ; ax='0' (char-> number)
1.03EA 01061000 add nLeft, ax ; nleft += number
1.03EE >26803C00 cmp byte ptr es:[si], 00 ; NotEndOfString
1.03F2 75DC jne 03D0 ; next char
...
In essence, Taskman is performing the following operation here:
static int nLeft, nTop;
//...
if (*lpCmdLine !=0)
sscanf(lpCmdLine, "%u %u, &nLeft, &nTop);
Should you want 3.1. Taskman to appear in the upper left of your
screen, you could place the following line in the [boot] section of
SYSTEM.INI:
taskman.exe=taskman.exe 1 1
In addition, doubleclicking anywhere on the Windows desktop will bring
up Taskman with the (x,y) coordinates for the double click passed to
Taskman on its command line.
The USER!WM_SYSCOMMAND handler is responsible for invoking Taskman,
via WinExec() whenever you press CTRL+ESC or double click the desktop.
What else is going on in WinMain()? Let's look at the following block
of code:
1.041E >6A29 push 0029
1.0420 9AF9000000 call USER.GETSYSTEMMETRICS
1.0425 50 push ax
1.0426 1E push ds
1.0427 681600 push 0016
1.042A 9AFFFF0000 call KERNEL.GETPROCADDRESS
1.042F 8946F4 mov [bp-0C], ax
1.0432 8956F6 mov [bp-0A], dx
1.0435 0BD0 or dx, ax
1.0437 7407 je 0440
1.0439 6A01 push 0001
1.043B 6A01 push 0001
1.043D FF5EF4 call far ptr [bp-0C] ; *1 entry
The lines push 29h & CALL GETSYSTEMMETRICS are simply the assembly
language form of GetSystemMetrics(0x29). 0x29 turns out to be
SM_PENWINDOWS (look in WINDOWS.H for SM_).
Thus, we now have GetSystemMetrics(SM_PENWINDOWS). If we read the
documentation, it says that this returns a handle to the Pen Windows
DLL if Pen Windows is installed. Remember that 16-bit return values
*always* appear in the AX register.
Next we can see that AX, which must be either 0 or a Pen Window module
handle, is pushed on the stack, along with ds:16h.
Let's immediately look at the data segment, offset 16h:
2.0010 0000000000005265 db 00,00,00,00,00,00,52,65 ; ......Re
2.0018 6769737465725065 db 67,69,73,74,65,72,50,65 ; gisterPe
2.0020 6E41707000000000 db 6E,41,70,70,00,00,00,00 ; nApp....
Therefore:
2.0016 db 'RegisterPenApp',0
Thus, here is what we have so far:
GetProcAddress(
GetSystemMetrics(SM_PENWINDOWS),
"RegisterPenApp")
GetProcAddress() returns a 4 bytes far function pointer (or NULL) in
DX:AX. In the code from WinMain() we can see this being moved into the
DWORD at [bp+0Ch] (this is 16-bit code, so moving a 32-bit value
requires two operations).
It would be nice to know what the DWORD at [bp-0Ch] is. But, hey! We
*do* know it already: it's a copy of the return value from
GetProcAddress(GetSystemMetrics(SM_PENWINDOWS), "RegisterPenApp)! In
other words, is a far pointer to the RegisterPenApp() function, or
NULL if Pen Windows is not installed. We can now replace all
references to [bp-0Ch] with references to something like
fpRegisterPenApp.
Remember another advantage of this "dead" Windows disassembling
vis-a-vis of the Winice approach "on live": here you can choose,
picking *meaningful* references for your search and replace
operations, like "mingling_bastard_value" or "hidden_and_-
forbidden_door". The final disassembled code may become a work of art
and inspiration if the cracker is good! (My disassemblies are
beautiful works of poetry and irony). Besides, *written*
investigations will remain documented for your next cracking session,
whereby with winice, if you do not write everything down immediately,
you loose lots of your past work (it's incredible how much place and
importance retains paper in our informatic lives).
After our search and replaces, this is what we get for this last block
of code:
FARPROC fpRegisterPenAPP;
fpRegisterPenApp = GetProcAddress(
GetSystemMetrics(SM_PENWINDOWS),
"RegisterPenApp");
Next we see [or dx, ax] being used to test the GetProcAddress() return
value for NULL. If non-NULL, the code twice pushes 1 on the stack
(note the PUSH IMMEDIATE here... Windows applications only run on
80386 or higher processors... there is no need to place the value in a
register first and then push that register) and then calls through the
fpRegisterPenApp function pointer: 1.0435 0BD0 or dx, ax 1.0437 7407
je 0440 1.0439 6A01 push 0001 1.043B 6A01 push 0001 1.043D FF5EF4 call
dword ptr fpRegisterPenApp
1.0435 0BD0 or dx, ax
1.0437 7407 je 0440
1.0439 6A01 push 0001
1.043B 6A01 push 0001
1.043D FF5EF4 call dword ptr fpRegisterPenApp
Let's have a look at the Pen Windows SDK doucmentation (and PENWIN.H):
#define RPA_DEFAULT
void FAR PASCAL RegisterPenApp(UINT wFlags, BOOL fRegister);
We can continue in this way with all of WinMain(). When we are done,
the 100 lines of assembly language for WinMain() boild own to the
following 35 lines of C code:
// nLeft, nTop used in calls to MoveWindow() in TaskManDlgProc()
static WORD nLeft=0, nTop=0;
BOOL FAR PASCAL TaskManDlgProc(HWND hWndDlg, UINT msg, WPARAM
wParam, LPARAM lParam);
int PASCAL WinMain(HANDLE hInstance, HANDLE hPrevInstance,
LPSTR lpCmdLine, int nCmdShow)
{
void (FAR PASCAL *RegisterPenApp) (UINT,BOOL);
FARPROC fpDlgProc;
if (hPrevhInstance != 0)
return 0;
if (*lpCmdLine !=0 )
_fsscanf(lpCmdLine, "%u %u, &nLeft, &nTop); // pseudocode
RegisterPenApp = GetProcAddress(GetSystemMetrics(SM_PENWINDOWS),
"RegisterPenApp");
if (RegisterPenApp != 0)
(*RegisterPenApp) (RPA_DEFAULT, TRUE);
if (fpDlgProc = MakeProchInstance(TaskManDlgProc, hInstance))
{
DialogBox(hInstance, MAKEINTRESOURCE(10), 0, fpDlgProc);
FreeProcHInstance(fpDlgProc);
}
if (RegisterPenApp != 0)
(*RegisterPenApp) (RPA_DEFAULT, FALSE);
return 0;
}
In this lesson we had a look at WinMain()... pretty interesting, isn't
it? We are not done with TASKMAN yet, though... we'll see in the next
lesson wich windows and dialog procedures TASKMAN calls. (-> lesson 2)
FraVia
