ObjAsm32 1.3d released!

[Biterider]

Hi,
I've just uploaded a new version of ObjAsm32. This release covers some new points and a lot of optimizations. Some of them are:

• New dual method tables.
• New project organization grouped in the Model.inc file.
• New NOFRAME method option.
• Debugging synchronization with DebugCenter.
• Collection objects speed improvements.
• ObjMem32.lib procedures revised to speed them up.
• ObjMem32.lib can be build now for 386 or Pentium III targets.
• DirectX 9c C inline procedure additions.
• ObjAsm32 AddIn for RadASM with full source code.
• ObjAsm32.chm updated.

One of the most important OOP model improvements is the introduction of Dual Method Tables (DMT). They are build from two method tables, the interface method table (IMT) used for COM interfacing, and the static method table (SMT) for regular object usage. Until now, both tables needed a separate pointer to access them. Now, using a DMT only one pointer placeholder is needed in the object instance. To keep the OOP inheritance and polymorphism, the SMT were build in reverse order and put before the IMT. By this way, both tables can grow, one in the positive and the other in the negative memory direction.

The programming model was reorganized and the whole housekeeping was placed in the Model.inc file. 3 new macros perform the tedious and repetitive but necessary work: SysSetup, SysInit and SysDone. The first macro is responsible for loading all files that are needed for the specified OOP level and debugging requirement. The last 2 macros perform the runtime initialization and finalization of the system.

NOFRAME is a new method option that was introduced to allow writing of faster short-methods. It is the equivalent to switch off the prologue and epilogue generation. A few methods of objects at the top of the inheritance tree were enhanced with this option, i.e. Collection and its variations.

Some changes in the debugging system were introduced to communicate synchronously with the DebugCenter. This allows using the debug macros and procedures in any user mode situation.

The ObjMem32 library was revised and some important speed improvements were made. It is now also possible to recompile the library for 386 and Pentium III targets.

DirectX was completed with the equivalents of the C inline code.

To facilitate the work with the OOP framework, a new version of the ObjAsm32 AddIn for the popular RadASM editor was released with its source code.

Finally, the ObjAsm32 help file was updated to reflect the last changes described above.

Thanks to the contributions of many users, the package was completed with new objects like DwordCollections, LinkedLists, etc. to facilitate even more the daily coding work in ASM.

You can find the new download at the ObjAsm32 homepage: http://objasm32.tripod.com   :8)

Regards,

Biterider

[Biterider]

Object placement and lifecycle using ObjAsm32

Objects are entities that can be located in different places as they are needed. Usually they are instantiated as standalone entities and their lifecycle are determined by the "New" and "Destroy" Keywords.
Less obvious are objects placed in resources, better said as part of i.e. a resource dialog. In this case, ObjAsm32 limits the lifecycle between the WM_NCCREATE and WM_NCDESTROY messages sent to those objects.
Objects can also be created as local entities like variables that are created with the "Local" keyword within a method or procedure. The difference to a standalone object is that the instance is not automatically initialized. It is required to use the "$LNew" or "LNew" macros to copy the object template to the local instance. Since the instance is automatically freed when the procedure or method is finished, it is not necessary to call the "Destroy" macro but the "Done" destructor to free allocated resources!
An object instance can be nested into another object using the "Embed" macro. This case is different from a local object since the nested object remains alive with the hosting object that controls its initialization and finalization. Like a local object, a nested object should never be disposed using the "Destroy" macro.
Finally, you can find an object instance in a more hidden place which is in an object that uses multiple inheritance. This topic will be explained in detail in the next ObjAsm32 version.
For a more flexible use of the method invoking, the OCall macro was enhanced to allow not only an instance pointer as first parameter, but also a symbol to the nested or local object. Internally, the instance pointer is computed in the most effective way avoiding any overhead.

Summarizing, objects can be found in many places where they are required:

• standalone (heap or any segment)
• in resources
• embedded into other objects
• embedded into methods or procedures
• in the base structure of multiple inheriting objects (next version)

In the next days I'll post a short update to show all this possibilities using the Demos and Projects of the current ObjAsm32 package.   :8)

Regards,

Biterider