• No results found

pointer

If you refer back to the program listing in the section Binding”, on page 142, you will see the creation of an instance and the use of a pointer to implement late binding.

Recapitulating:

WINDOW *ptr; ptr =

ptr

So that you are absolutely clear on what this compiles down to, here is the actual assembly language generated:

mov si,OFFSET window1

mov the order of pushing. push ax

mov push ax

push si that THIS pushed last. mov is the offset of the pointer to call , in object

Looking back again at the code from Binding" on page 142, you will see the definition of But if is to be the assembly language module, you would leave it in the C program for now, as a stub. You would put in the skeleton code, as follows:

void WINDOW :: (int int int x;

draw //member of another object. this dosomething //hypothetical function. x = active; //data of current object.

Calling a This code shows various ways of getting at data. is

member, an example of calling a function-member belonging to the current

object, though I haven’t actually defined such a function.

object "active" is a data-member and I have accessed it

in the stack. Notice also how I can access functions of other objects.

is some other object belonging to a different class, say

different "BOX". The choice here is arbitrary. It has an arbitrary function

object called

Compile and Assemble Steps

If we use Borland’s BCC compiler, the command line to compile to assembly is as follows:

BCC -S filename. C P P

Where suppresses linking and generates .ASM output. Note that case is important with the switches.

Mangled file that you get will not have any high-level

names assembly language features in it, so you have to look through it

and extract the useful information. Then you can put together your own assembly module. It will look something like this:

SMALL match C++ module. PUBLIC EXTRN EXTRN EXTRN _boxl x DWO data. PROC C

to get at the passed parameters . . .

mov at Addr of

mov at

mov at

access another function, another object . . . . . .

call C early binding. access a function, current object . . .

this dosomething 0 . . .

call C si

binding. no other to pass. at data-member of current object . . .

active . . .

mov ax, . O is 0, since field is first in mov x,ax object.

ret

ENDP END

The skeleton program gives you the mangled names and how to

access the dataandfunctionmembers. Thenyoucango flesh out the assembly module.

Your next step would be to remove the stub from the C++ module and compile as follows:

BCC filenamel. CPP filename2. ASM

if the fancy takes you, it can be done in steps:

BCC filenamel. CPP

TASM /ml filename2 file)

TLINK filename1 filename2

Note that Borland C++ does have a mechanism to suppress name-mangling for linking with Standard C modules, but I found it too limited for assembly work. It doesn’t work for data and function members.

Coding development over

previous

chapters A skeleton

Note also that C++ does have an EXTERN declaration, so that any function that is referenced in the C++ module but is defined in the assembly module can be declared as EXTERN. However, this also has limitations and is optional anyway.

The Amazing

Program

So you think assembly language programming for Windows is difficult think again!

The “high-level” assembly language program of Chapter 5 is not much longer than one written in C or any other conventional high-level language. In the first half of this chapter, I introduced objects and some details about the inner working of C++ and how to interface to it now, applying 00 techniques brings an assembly language skeleton program down to just nine lines! OOP and assembly language go together in a most natural way, with the result that coding becomes a breeze. Here is an 00 skeleton program:

;WINASMOO.ASM WINASMOO.EXE INCLUDEWINASMOO.INC

kickstart:

lea of window object. call the window.

ret END

There are eleven lines there, but take off the comment line and put the code-label on the same line as the following instruction, and it becomes nine lines.

Kickstat:

This program is the most basic skeleton, putting only a window on the screen and nothing else. In a moment show you how simple it is to add the menu-bar and message box, as per skeletons from previous chapters. But first have a look at the above.

In the data segment I created an instance of a WINDOW structure called "windowl". In the code routine called "kickstart I set THIS to window1 and then called which, as its name suggests, creates the window and puts it on the screen.

You may have noticed that the syntax for creating the instance of WINDOW doesn’t look much like that for structures (see page but don’t worry about that for now.

Hiding There is a tick here: I have taken all the “red tape”, the “red tape” complexity, of the Windows program and hidden it away in the

Include file This hiding of the unnecessary complexity and exposing only what is needed can only be done by using 00 techniques.

My object oriented Include file is a world’s first. Nobody has done this before. No Microsoft or Borland documentation will tell you how to do this. The Microsoft documentation is appalling from the assembly language programmer’s viewpoint. The Borland manuals keep getting thinner too. Mind you, the simple program you see above didn’t just materialize in my mind. I just about tore my hair out at times.

I came across a very interesting article by John Dimm titled “A classes for Tiny Windows Class Library” in Programmer’s Journal, USA, Windows Dec. 1991. I also studied Norton and Yao’s Borland C++ Programming for Windows, Borland/Bantam, USA, 1992. A few ideas come from these and other sources, but I ended up doing my own thing, and what is presented in this chapter is quite simple and elegant.

It is written in Borland TASM version 3.0, for the simple reason that this assembler is specifically designed for OOP. However, I must emphasize that the code is very general and with some modification will work with earlier versions of TASM and with MASM. I have pointed out the divergence non-OOP assemblers within this chapter. The disadvantage of the non-OOP version is that it is awkward, cumbersome, and verbose. The OOP version is easier to use, conceptually simpler, and requires fewer lines of code.

Look on the Companion Disk for various example 00 programs.