Randy is the designer of numerous hardware and software projects, including assemblers for a variety of systems. In addition to consulting, he is currently an instructor in computer science at California Polytechnic University in Pomona and at UC Riverside.

One of the promises of the object-oriented paradigm is that it will reduce program complexity and implementation effort for many different types of programs. Object-oriented programming, however, is no panacea. It is a technique, like recursion, that you can apply in certain cases to reduce programming effort. While there are certain types of programs whose object-oriented implementation is better, examples abound where object-oriented programming systems (OOPS) buy you nothing. Nonetheless, object-oriented programming techniques are a valuable tool to have in one's war chest.

OOPS are nothing new. They have been around since the late 1960s. Yet the object-oriented paradigm was languishing until Object Pascal and C++ began generating mainstream interest. The success of these languages demonstrates that OOP is not the domain of a few esoteric programming languages. Rather, object-oriented programming is applicable to almost any programming language.

Still, assembly language may not seem like the place to apply the object-oriented programming paradigm. But keep in mind that people were saying the same thing about Pascal and C five years ago.

What does an object-oriented assembly-language program look Like? A better question to ask is, "What is the essence of an object-oriented program, and how does one capture it within an assembly language program?" Once you strip away the gloss and notation convenience provided by languages such as C++, you'll find that the two main features of an object-oriented program are polymorphism and inheritance.

Polymorphism takes two basic forms in most programming languages: static and dynamic. The general idea, however, is the same. You call different subroutines by the same name. Static polymorphism provides notational convenience in the form of operator/ function overloading in languages such as C++. Static polymorphism uses the parameter list, along with the routine's name (together they form the routine's signature), to determine which routine to call. For example, consider the C routines:

CmplxAddCC(C1, C2, C3); /*C1=C2+C3;*/ CmplxAddCR(C1, C2, R1); /*C1=C2+ToCmplx(R1);*/ CmplxAddRC(C1, R1, C2); /*C1=ToCmplx(R1)+C2;*/

In C++ you could write:

CmplxAdd(C1, C2, C3); CmplxAdd(C1, C2, R1); CmplxAdd(C1, R1, C2);

and the C++ compiler would figure out whether to call CmplxAddCC, CmplxAddCR, or CmplxAddRC. (Actually, you could overload C++'s "+" operator and use the three forms C1=C2+C3;, C1=C2+R1;, or C1=R1+C2;, but the example above would be still valid).

Static overloading, while convenient, does not add any power to the language. The calls to CmplxAdd call three different routines. CmplxAdd-(C1,C2,C3) calls CmplxAddCC, CmplxAdd(C1,C2,R) calls CmplxAddCR, and CmplxAdd-(C1,R,C2) calls CmplxAddRC. The C++ compiler determines which routine this code will call at compile time. Static polymorphism is a mechanism that lets the compiler choose one of several different routines to call depending upon the calling signature.

Sometimes you may want to use the same signature to call different routines. For example, suppose you have a class shape in which there are three graphical objects: circles, rectangles, and triangles. If you have an arbitrary object of type shape, the compiler cannot determine which DRAW routine to call. The program determines this at run time. This allows a single call to draw circles, rectangles, triangles at run time with the same machine instructions. This is dynamic polymorphism -- determining at run time which routine to call. C++ uses virtual functions and Object Pascal uses override procedures and functions to implement dynamic polymorphism.

Inheritance lets you build up data structures as supersets of existing data structures. This provides a mechanism whereby you can generalize data types, allowing you to handle various objects regardless of their actual type. This lets you define such diverse shapes as circles, rectangles, and triangles and treat them as compatible structures.

Implementing Classes and Inheritance

Because structures and classes are closely related, it may be instructive to look at the implementation of structures before looking at classes. Consider S, a variable of the type in Example 1. Somewhere in memory the compiler needs to generate storage for the fields of S. Traditionally, compilers allocate these fields contiguously (see Figure 1). Indeed, Microsoft's assembler (MASM) allows you to declare structures in a similar fashion, as shown in Example 2. If S provides the base address of this structure, S+0 is the address of S.i, S+2 is the address of S.j, and S+4 is the address of S.c.

Example 1: The variable S

struct { int i; int j; char *c; } S;

Example 2: Declaring structures in MASM

SType struc i dw ? j dw ? c dd ? SType ends

Now consider the case of a pair of C++ classes (Sc and Tc) in Example 3. Pointers to objects (pS and pT) may point at an object of the prescribed type or to an object that is a descendant of the pointer's base class. For example, pS can point at an object of type Sc or at an object of type Tc. Remember, accessing *pS.j is equivalent to (int) *(pS+2), so if pS points at an object of type Tc, the j field must also appear at offset two within the structure. For inheritance to work properly, the common fields must appear at the same offset within the structure (see Figure 2).

Example 3: C++ classes

class Sc { int i; int j; char *c; }; Sc *pS; Tc *pT; ------------------------ Tclass Tc:Sc { int k; char *d; };

Additional fields in the subclass often appear after the fields in the parent class, so most compilers implement class Tc as in Example 4. Note that the offsets to i, j, and c are the same for both Sc and Tc.

Example 4: The way most compilers implement a class like Tc

struct Tc Tc struc { i dw ? int i; j dw ? int j; c dw ? char *c; k dw ? int k; d dd ? char *d Tc ends ? };

When I first began exploring how to implement inheritance in assembly, I got the bright idea of using macros inside structure definitions to handle the problem of inheritance. Briefly, I wanted to implement Sc and Tc as in Example 5. Unfortunately, MASM doesn't allow you to expand macros or strucs inside a structure. Disappointed, I tried the brute force way to implement Sc and Tc, as illustrated in Example 6.

Example 5: One approach to implementing Sc and Tc

ScItems macro i dw ? j dw ? c dd ? endm ; TcItems macro ScItems k dw ? d dd ? endm ; Sc struc ScItems Sc ends ; Tc struc TcItems Tc ends

Example 6: The brute force method of implementing Sc and Tc

Sc struc i dw ? j dw ? c dd ? Sc ends Tc struc i dw ? j dw ? c dd ? k dw ? d dd ? Tc ends

Unfortunately, I'd forgotten that MASM doesn't treat these symbols as part of the structure. Names such as i, j, c, and so on must be unique in the program. As you can plainly see in Example 6, I declared i twice, and the assembler gave me a "redefinition of symbol" error. Almost ready to give up, I tried the method in Example 7.

Example 7: Yet another attempt at implementing Sc and Tc

Sc struc i dw ? j dw ? c dd ? Sc ends Tc struc dw ? dw ? dd ? k dw ? d dd ? Tc ends S Sc T Tc

MASM simply equates the field names to the offsets within the structure. So it equates i to zero, j to two, and so on. MASM does not associate i with labels of type Sc. You can use the symbols T.j and S.j in your program. Because the "." operator behaves like the "+" operator, T.j is just like T+2.

For Tc to inherit the fields of Sc, all we have to do is reserve enough space at the beginning of the Tc structure for each of the fields of Sc. Above, I stuck in the two DW and the DD pseudoopcodes to reserve space for the i, j, and c fields. This technique might get inconvenient if the number of inherited fields is large. The code in Example 8 solves this problem.

Example 8: The solution to implementing Sc and Tc

Sc struc i dw ? j dw ? c dd ? Sc ends Tc struc db (size Sc) dup (?) k dw ? d dd ? Tc ends Uc struc db (size Tc) dup (?) e dw ? Uc ends S Sc T Tc U Uc

The first DB pseudoopcode in Tc reserves the necessary space for the fields Tc inherits from Sc. Likewise, Uc (which is a subclass of Tc) reserves space at the beginning of the structure for the fields inherited from Tc and Sc. The code in Example 8 works great if you don't need to initialize any of the fields inherited from Sc; if you need to initialize some fields, you'll have to use the brute force method and redeclare space for each field.

Methods

The earlier paragraphs discuss how to implement objects whose fields are all variables. What happens when you introduce methods? If you're not overloading a method, you can treat it in the same manner as any other assembly language procedure and call it directly. If you are overloading a method, you must call it indirectly via a pointer within the object.

Consider the C++ class declaration in Example 9. The assembly code implementing this class is shown in Example 10. To call S.geti, you would use the 8086 instruction: CALL S.geti.

Example 9: A C++ class declaration

class Sc { int i, j; char *c; public: int geti() {return i}; /* Ignore the fact that C++ */ int getj() {return j}; /* would implement these */ void seti (x) int X; {i = x;}; /* methods in-line. */ void setj (x) int X; {j = x;}; };

Example 10: Assembly code for implementing the code in Example 9

Sc struc i dw ? j dw ? c dd ? geti dd Sc_geti getj dd Sc_getj seti dd Sc_seti setj dd Sc_setj Sc ends S Sc

Because S.geti is a double word memory variable, the CALL instruction will call the procedure S.geti, which points at Sc_geti. The fact that we're calling the methods indirectly will be useful when we look at overloading a little later.

THIS

Suppose we have three instances of class Sc, say S1, S2, and S3 declared in assembly language as follows:

S1 Sc S2 Sc S3 Sc

S1.geti, S2.geti, and S3.geti all call the same procedure (call it Sc_geti). How does Sc_geti differentiate between S1.i, S2.i, and S3.i? In object-oriented languages such as Object Pascal and C++, the compiler automatically passes a special parameter named this to the method. this always points at the object through which you've invoked the method. When you execute S1.geti, the compiler passes the address of S1 in this to geti. Likewise, the compiler passes the address of S2 in this when you call S2.geti.

You can pass this to a method just as any other parameter. Because the most efficient way of passing parameters is in the 8086's registers, I've adopted the convention of passing this in the ES:BX registers. The Sc_geti method would look something like Example 11 (assuming we're returning i in the AX register). This example demonstrates a major problem with object-oriented programming -- it is very inefficient. To load S1.i into AX, see Example 12. This requires six instructions where, logically, you should only need one (mov ax, S1.i). Welcome to the wonderful world of object-oriented programming! Yet circumventing all this overhead by loading S1.i directly into AX will eliminate the benefits of object-oriented programming.

Actually, this isn't as bad as it looks. A good part of the time ES:BX will already be pointing at the object you want to access. Nevertheless, the call and return are considerable overhead just to load the AX register with a word value. Stroustrup anticipated this problem when designing C++ and he solved it by providing inline functions (a.k.a. macros). We can use this same technique in assembly language to improve efficiency as Example 13 illustrates. This code snippet demonstrates another convention I adhere to: I make macros for all method calls, even those that are actual calls. This lets me use a consistent calling format for all methods, whether they are actual subroutines or are expanded in-line.

Example 11: The Sc_geti method

_THIS equ es:[bx] Sc_geti proc far mov ax, _THIS.i ret Sc_geti endp

Example 12: Loading S1.i into AX

mov bx, seg S1 mov es, bx mov bx, offset S1 call S1.geti ;Assuming S1 is in the data seg.

Example 13: Improving efficiency

; ; Inline expansion of geti to improve efficiency: ; _Geti macro mov ax, _THIS.i endm ; ; Perform actual call to routines which are too big to ; expand in-line in our code: ; _Printi macro call _THIS.Printi endm * * * _Geti ;Get i into AX. * * * _Printi ;Call Printi routine.

There is one major drawback to expanding a procedure inline; you cannot overload procedures (C++'s inline functions suffer from this as well. You cannot have an inline virtual function). Therefore, you should only use this technique for those particular methods that you will never need to overload. Fortunately, the macro implementation makes it easy to switch to a call later if you need to overload the procedure. Just substitute a call for the inline code inside the macro.

Polymorphism and Overloading

Overloaded procedures allow the "same" method to perform different operations, depending upon the object passed to the method. Consider the class definitions in Example 14. Rect and Circle are types derived from Shape. If ES:BX points at a generic shape (that is, ES:BX points at an object of type Shape, Rect, or Circle) then CALL_THIS.Draw will call Shape_Draw, Rect_Draw, or Circle_Draw, depending upon where ES:BX points. This lets you write generic code that needn't know the particular details of the shape it's drawing. The object itself knows how to draw itself via the pointer to the specific draw routine.

Example 14: Typical class definitions

Shape struc ulx dw ? ;Upper left X coordinate uly dw ? ;Upper left Y coordinate lrx dw ? ;Lower right X coordinate lry dw ? ;Lower right Y coordinate Draw dd Shape_Draw ;Default (overridden) DRAW routine Shape ends ; Rect struc dw 4 dup (?) ;Reserve space for coordinates dd Rect_Draw ;Draw a rectangle Rect ends ; Circle struc dw 4 dup (?) ;Reserve space for coordinates dd Circle_Draw ;Draw a circle Circle ends

Allocation of Objects

High-level object-oriented languages such as Object Pascal and C++ tend to hide many of the allocation details from you. In assembly language, naturally, the programmer has to handle all of the allocation details. Although a complete discussion of dynamic allocation of objects is beyond the scope of this article, the subject is so pervasive that it warrants a brief mention.

Static allocation of an object in assembly language is quite simple. If you have the shape class definitions (shape, rect, and circle) mentioned earlier, you can easily declare variables of these types using declarations of the form:

MyRect rect MyCircle circle MyShape shape

This automatically fills in the DRAW field for these variables (the linker/loader fills in such addresses when it loads the program into memory). What happens if you are dynamically allocating storage for an object? Assume we have a routine, alloc, to which we pass a byte count in CX, and it returns a pointer to a block of memory that size in ES:BX. Now suppose we allocate a rectangle with the code in Example 15. Alloc will not be smart enough to fill in the pointer to the rect.DRAW routine. This is something we'll have to do ourselves. This requires the four instructions in Example 16.

Example 15: Code to allocate a rectangle

mov cx, size rect call alloc mov word ptr MyRectPtr, bx mov word ptr MyRectPtr+2, es

Example 16: Filling in the pointer to the rect.DRAW routine

mov ax, offset rectDRAW mov _this.DRAW, ax mov ax, seg rectDRAW mov _this.DRAW+2, ax

Eight instructions may not seem like a lot to create a simple object. Keep in mind, however, that our simple shape object only has one overridden method. If there were a dozen methods, you would need 52 instructions. Clearly, a CREATE procedure begins to make a lot of sense. Each subclass (shape, rect, and circle) will need its own CREATE method. CREATE is not a method you normally overload, because during the creation process you know exactly the type of object you're creating. By convention, the CREATE methods I write always allocate the appropriate amount of storage, initialize any important fields, and then return a pointer to the new object in ES:BX. The code in Example 17 provides an example, using the rect and circle types. To manipulate these objects, we need only load the appropriate pointer into ES:BX and access the appropriate fields or call the appropriate methods via this.

Example 17: Code for example using the rect and circle types

mov cx, size circle call CreateCircle mov word ptr CircVarPtr, bx mov word ptr CircVarPtr+2, es ; mov cx, size rect call CreateRect mov word ptr RectVarPtr, bx mov word ptr RectVarPtr+2, es

Other Conventions

While writing object-oriented programs in assembly language, I've found certain guidelines helpful in the initial design phases (that is, before having to take efficiency into consideration). Most of these guidelines are widely accepted object-oriented practices; others pertain mainly to assembly language. Here are the major ones I'm using:

Try to use dynamic allocation for objects wherever possible. In the best object-oriented programs, instances of an object appear and disappear throughout the program. Rarely will a single instance exist throughout the execution of a program. Because an object's methods always reference fields of an object indirectly, there is little benefit to statically allocated objects. Converting a statically allocated object to a dynamically allocated one later on is messy. Get it right the first time!

Avoid accessing the individual variables (fields) within an object. Write methods that store values into these fields and retrieve values from them. This information-hiding technique is well proven in OOP and isn't particularly worthy of further discussion.

Overload as many methods as possible. CREATE is probably the only method you shouldn't overload. Access methods, which provide access to the fields of the outermost class, might be another candidate for direct access. But the loss of generality for a small increase in efficiency is rarely worth it.

Always use macros to call methods, especially those you're not calling indirectly. This provides a consistent calling mechanism for methods and lets you easily overload methods you choose to implement inline or without overloading. This applies equally well to accessing fields in an object.

As a bare minimum, each class should have the following methods: CREATE, DISPOSE, COPY, and a set of access methods for each of the fields. COPY should copy the contents of one instance variable's fields to another variable.

Naturally, these are just guidelines, not rules etched in stone. But a certain amount of discipline early in a project helps prevent considerable kludging later on.

An Example

The example in Listing One is a program that adds, subtracts, and compares signed binary integers, unsigned binary integers, and BCD values. While not a complete example (it's missing several important methods such as CREATE, PRINT, DISPOSE, and so on) it demonstrates the flavor of object-oriented programming in assembly language.

Listing One

page 62, 132 ; ;*************************************************************************** ; OBJECTS.ASM -- This program demonstrates object-oriented programming ; techniques in 8086 assembly language. ; dseg segment byte public 'data' ; ; Unsigned Data Type: Unsigned struc Value dw 0 _Get_ dd ? ;AX = This _Put_ dd ? ;This = AX _Add_ dd ? ;AX = AX + This _Sub_ dd ? ;AX = AX - This _Eq_ dd ? ;Zero flag = AX == This _Lt_ dd ? ;Zero flag = AX < This Unsigned ends ; ; UVar lets you (easily) declare an unsigned variable. UVar macro var var Unsigned <,uGet,uPut,uAdd,uSub,uEq,uLt> endm ; ; Signed Data Type: Signed struc dw 0 dd ? ;Get method dd ? ;Put method dd ? ;Add method dd ? ;Sub method dd ? ;Eq method dd ? ;Lt method Signed ends ; ; SVar lets you easily declare a signed variable. SVar macro var var Signed <,sGet, sPut, sAdd, sSub, sEq, sLt> endm ; ; BCD Data Type: BCD struc dw 0 ;Value dd ? ;Get method dd ? ;Put method dd ? ;Add method dd ? ;Subtract method dd ? ;Eq method dd ? ;Lt method BCD ends ; ; BCDVar lets you (easily) declare a BCD variable. BCDVar macro var var BCD <,bGet, bPut, bAdd, bSub, bEq, bLt> endm ; ; Declare variables of the appropriate types (For the sample pgm below): ; Also declare a set of DWORD values which point at each of the variables. ; This provides a simple mechanism for obtaining the address of an object. UVar u1 U1Adr dd U1 ;Provide convenient address for U1. ; UVar u2 U2Adr dd U2 ;Ditto for other variables. ; SVar s1 S1Adr dd s1 ; SVar s2 S2Adr dd s2 ; BCDVar b1 B1Adr dd b1 ; BCDVar b2 B2Adr dd b2 ; ; Generic Pointer Variables: Generic1 dd ? Generic2 dd ? ; dseg ends ; cseg segment byte public 'CODE' assume cs:cseg, ds:dseg, es:dseg, ss:sseg ; _This equ es:[bx] ;Provide a mnemonic name for THIS. ; ; Macros to simplify calling the various methods _Get macro call _This._Get_ endm ; _Put macro call _This._Put_ endm ; _Add macro call _This._Add_ endm ; _Sub macro call _This._Sub_ endm ; _Eq macro call _This._Eq_ endm ; _Lt macro call _This._Lt_ endm ; ;*************************************************************************** ; Methods for the unsigned data type: uGet proc far mov ax, _This ret uGet endp ; uPut proc far mov _This,ax ret uPut endp ; uAdd proc far add ax, _This ret uAdd endp ; uSub proc far sub ax, _This ret uSub endp ; uEq proc far cmp ax, _This ret uEq endp ; uLt proc far cmp ax, _This jb uIsLt cmp ax, 0 ;Force Z flag to zero. jne uLtRtn cmp ax, 1 uLtRtn: ret ; uIsLt: cmp ax, ax ;Force Z flag to one. ret uLt endp ; ;*************************************************************************** ; Methods for the unsigned data type. sPut equ uPut ;Same code, why duplicate it? sGet equ uGet sAdd equ uAdd sSub equ uSub sEq equ uEq ; sLt proc far cmp ax, _This jl sIsLt cmp ax, 0 ;Force Z flag to zero. jne sLtRtn cmp ax, 1 sLtRtn: ret ; sIsLt: cmp ax, ax ;Force Z flag to one. ret sLt endp ; ;*************************************************************************** ; Methods for the BCD data type bGet equ uGet ;Same code, don't duplicate it. bPut equ uPut bEq equ uEq bLt equ uLt ; bAdd proc far add ax, _This daa ret bAdd endp ; bSub proc far sub ax, _This das ret bSub endp ; ;*************************************************************************** ; Test code for this program: TestSample proc near push ax push bx push es ; ; Compute "Generic1 = Generic1 + Generic2;" les bx, Generic1 _Get les bx, Generic2 _Add les bx, Generic1 _Put ; pop es pop bx pop ax ret TestSample endp ; ; Main driver program MainPgm proc far mov ax, dseg mov ds, ax ; ; Initialize the objects: ; u1 = 39876. Also initialize Generic1 to point at u1 for later use. les bx, U1Adr mov ax, 39876 _Put mov word ptr Generic1, bx mov word ptr Generic1+2, es ; ; u2 = 45677. Also point Generic2 at u2 for later use. les bx, U2Adr mov ax, 45677 _Put mov word ptr Generic2, bx mov word ptr Generic2+2, es ; ; s1 = -5. les bx, S1Adr mov ax, -5 _Put ; ; s2 = 12345. les bx, S2Adr mov ax, 12345 _Put ; ; b1 = 2899. les bx, B1Adr mov ax, 2899h _Put ; ; b2 = 195. les bx, B2Adr mov ax, 195h _Put ; ; Call TestSample to add u1 & u2. call TestSample ; ; Call TestSample to add s1 & s2. les bx, S1Adr mov word ptr Generic1, bx mov word ptr Generic1+2, es les bx, S2Adr mov word ptr Generic2, bx mov word ptr Generic2+2, es call TestSample ; ; Call TestSample to add b1 & b2. les bx, B1Adr mov word ptr Generic1, bx mov word ptr Generic1+2, es les bx, B2Adr mov word ptr Generic2, bx mov word ptr Generic2+2, es call TestSample ; mov ah, 4ch ;Terminate process DOS cmd. int 21h ; ; MainPgm endp cseg ends ; sseg segment byte stack 'stack' stk dw 0f0h dup (?) endstk dw ? sseg ends ; end MainPgm

[Example 1]

struct { int i; int j; char *c; } S;

[Example 2]

SType struc i dw ? j dw ? c dd ? SType ends

class Sc { int i; int j; char *c; }; Sc *pS; Tc *pT; Tclass Tc:Sc { int k; char *d; };

[Example 4]

struct Tc Tc struc { i dw ? int i; j dw ? int j; c dd ? char *c; k dw ? int k; d dd ? char *d Tc ends };

[Example 5]

ScItems macro i dw ? j dw ? c dd ? endm ; TcItems macro ScItems k dw ? d dd ? endm ; Sc struc ScItems Sc ends ; Tc struc TcItems Tc ends

[Example 6]

Sc struc i dw ? j dw ? c dd ? Sc ends Tc struc i dw ? j dw ? c dd ? k dw ? d dd ? Tc ends

[Example 7]

Sc struc i dw ? j dw ? c dd ? Sc ends Tc struc dw ? dw ? dd ? k dw ? d dd ? Tc ends S Sc T Tc

[Example 8]

Sc struc i dw ? j dw ? c dd ? Sc ends Tc struc db (size Sc) dup (?) k dw ? d dd ? Tc ends Uc struc db (size Tc) dup (?) e dw ? Uc ends S Sc T Tc U Uc

class Sc { int i,j; char *c; public: int geti() {return i}; /* Ignore the fact that C++ */ int getj() {return j}; /* would implement these */ void seti(x) int x; {i = x;}; /* methods in-line. */ void setj(x) int x; {j = x;}; };

Sc struc i dw ? j dw ? c dd ? geti dd Sc_geti getj dd Sc_getj seti dd Sc_seti setj dd Sc_setj Sc ends S Sc

_THIS equ es:[bx] Sc_geti proc far mov ax, _THIS.i ret Sc_geti endp

mov bx, seg S1 mov es, bx mov bx, offset S1 call S1.geti ;Assuming S1 is in the data seg.

; ; Inline expansion of geti to improve efficiency: ; _Geti macro mov ax, _THIS.i endm ; ; Perform actual call to routines which are too big to ; expand in-line in our code: ; _Printi macro call _THIS.Printi endm . . . _Geti ;Get i into AX. . . . _Printi ;Call Printi routine.

Shape struc ulx dw ? ;Upper left X coordinate uly dw ? ;Upper left Y coordinate lrx dw ? ;Lower right X coordinate lry dw ? ;Lower right Y coordinate Draw dd Shape_Draw ;Default (overridden) DRAW routine Shape ends ; Rect struc dw 4 dup (?) ;Reserve space for coordinates dd Rect_Draw ;Draw a rectangle Rect ends ; Circle struc dw 4 dup (?) ;Reserve space for coordinates dd Circle_Draw ;Draw a circle Circle ends

mov cx, size rect call alloc mov word ptr MyRectPtr, bx mov word ptr MyRectPtr+2, es

mov ax, offset rectDRAW mov _this.DRAW, ax mov ax, seg rectDRAW mov _this.DRAW+2, ax

mov cx, size circle call CreateCircle mov word ptr CircVarPtr, bx mov word ptr CircVarPtr+2, es ; mov cx, size rect call CreateRect mov word ptr RectVarPtr, bx mov word ptr RectVarPtr+2, es