overhead
Make
One thing you may be starting to appreciate is that Windows adds an incredible processing overhead even a simple key press has to go through so many steps before it reaches the destination. Then we go and make things even worse by using 00 techniques, that add yet another layer of processing. If you want code that rockets along, for a video game for example, you will want to know mechanisms for speeding things up. OOP may make the coding easier, but it may be going against a fundamental reason why we are using assembly language. Let me post this as a thought for now.
Oh yes, file has a couple of minor
changes from before, so here is the listing:
# NOTE this Make file has been modified for Borland C++, # to be used with TASM and TLINK, however I’m still using # Microsoft’s NMAKE, as Borland’s MAKE has some strange # quirks though the version supplied with TASM # claims to have improved compatibility with NMAKE . . . # t h i s I h a v e n ’t y e t t r i e d .
# To r u n t h i s f i l e : NMAKE
lpath = #path for libraries #path for Include files. epath =\borlandc\bin #path for
SW = #switches for tlink.
# Windows exe,
# path, =debug-on. tasm
-r =dont append to exe, =dont look in INCLUDE # envir-variable for incl-files, -i in this path # instead.... rc -r # cOws=start-up-lib, cws=Windows-runtime-lib, # import=access-builtin-libs tlink rc
# Note that Borland C++ names the Windows library # CWINS.LIB, while names it CWS.LIB. I used the # latter above. The C library is CS.LIB, which # could be placed immediately after CWS, if you need it. # Note that the postfix designates the small model.
Program So, that’s WINASMOO.MAK much the same as before. The
custom icon .RC and .DEF tiles can be the same as for previous skeletons, though of course if you want to try experimenting with OOP you might like to try adding on to the .RC tile.
Most Windows programs will want to have their own icon, rather than one of the defaults, and I have done this with the extended program example (the one with the child control button). Icon images have to be created with a special paint program I used Borland’s Resource Workshop a lovely product to design my icon, which I then saved as WINASMOO.ICO.
Resource Resource Workshop then automatically added an extra line into
script my WINASMOO.RC tile:
( a r b i t r a r y ) e q u a t e s c o u l d h a v e b e e n i n a n i n c l u d e QUIT 200 #define 201 winasmoo MENU BEGIN BEGIN
END END
ICON 1 ICON winasmoo.ico
The icon resource is arbitrarily named “icon so when I
created in my program, I put the override
sziconname icon-l”.
Definition There is a useful note that I can make about the .DEF tile, so here
file it is:
NAME WINASMOO
DESCRIPTION 'Demo 00 asm program' EXETYPE WINDOWS
STUB
CODE PRELOAD
DATA PRELOAD MULTIPLE
1024 STACKSIZE 8192
EXPORTS exportwndproc
Multiple What I would like to point out in particular here are the
instances specifications for the data segment. PRELOAD means that it
loads when the program is first loaded. means that it can be moved by WINDOWS. MULTIPLE means that every instance will have its own copy of the data segment. The latter point is important if you want the program to support multiple instances. I have designed the code to support multiple instances with the same ease that it supports multiple windows within the same instance, but this only works if each instance has its own complete copy of the data/stack/heap. Note that all instances will use the same code segment, which is no problem at all.
This works because code cannot be changed. Even though you can keep data in the code segment, and I have done so in the skeleton program, you cannot change it. Windows sets the attribute of code segments such that they cannot be written to, and your program will crash if you try. Most interestingly, though, there is a way around this, because Windows has a function that gives you a DS selector for a code segment (see Chapters 10, 11 and 12).
SMALL Note that my OOP code is designed for the SMALL model. The
model major limiting factor is the pervasive use of NEAR pointers. It
would probably be easier to design a completely different Include file for other memory models. It should be easy to upgrade to 32-bit code though.
TASM encourages the classical implementation of objects, in
not stored physically with the data of each object instance, but somewhere else (which is why they invented the TABLE that I have misused). There are arguments for and against this. Any one class can have one VMT, and instances could all access a single instance of the VMT. This would be efficient in terms of memory but would not allow individual overrides by each object instance. As mentioned earlier, I decided on an approach that allows easy conversion to non-OOP assemblers, is conceptually simple, and offers some flexibility advantages that the doesn’t.
Improving has been presented in this chapter in a simple, uncluttered form, as has the rest of the code. The tile can be massaged in various ways to do more. For example, can be made to handle normal child windows with only minor modifications. Thus the same WINDOW class could be used for parent and child windows. The alternative would be to create another class, called, say, CHILD, just like I did for CONTROL. The product is evolving all the time, and you may find some interesting new stuff on the Companion Disk or my Web site.
Postamble
You can have a lot of fun playing with these tools. You may think of improvements let me know.