Author Topic: ObjAsm64  (Read 192 times)


  • Moderator
  • Member
  • *****
  • Posts: 137
  • ObjAsm32
    • ObjAsm32
« on: January 01, 2018, 05:39:01 AM »
The last weeks I started to work on the ObjAsm framework to support x64 using UASM.
It is a work in progress, since not all features are implemented yet. I choose using UASM, because it offers at least the same flexibility we are used to from ML 6.15 for x86.
The currently supported features are:
·        Object Oriented Programming (single inheritance)
·        Dual method tables:  simultaneous support of virtual method tables for “open interfaces” like COM and “not exposed” methods.
·        Native COM support (x64 virtual method table call and Dispatch)
·        Some prebuild objects like Collections, Linked Lists, Streams, Controls, Applications, etc.
·        Precompiled objects
·        Object templates, sub- and  super-classing capabilities
·        Virtual, dynamic, static, private methods
·        VARARG support
·        ANSI and UNICODE support
·        ObjMem64 library that covers most of the daily coding needs
·        Examples and projects
·        Automated compilation and build control
·        Etc.
Since ObjAsm64 is in beta stage, I want to ask if somebody is interested in testing it. I don’t have an installer or a help file yet, but people coming from ObjAsm32 know how to use this model or you can read the old documentation. Since x64 import libraries and include files are spread around, there will be some path adjustments to do. Like ObjAsm32, ObjAsm64 has a single file that must be modified to specify your local configuration. I also added 2 new Environment Variables (OA64_PATH, MSVS_PATH) to allow the tool chain to work smoothly.
In addition to the last UASM version, you will need a proper linker and maybe some debug facilities. My choose fall on Visual Studio -Community Edition-, which comes with all necessary tools. As development editor I’m still using RadAsm (2), but you can use whatever you prefer. Each project comes with batch files to compile for release or debug targets (RLS, DBG).
Send me a PM if you are interested to participate!
Attached is one of the new translated projects.

Best regards, Biterider


  • Moderator
  • Member
  • *****
  • Posts: 137
  • ObjAsm32
    • ObjAsm32
Re: ObjAsm64
« Reply #1 on: January 07, 2018, 02:34:56 AM »
I finished the rework and migration of the OCX Container project to x64.
It proofs how well the new ObjAsm64 framework works and interacts with the x64 COM world.

At the moment, the application supports the following interfaces:
  • IConnectionPoint / IConnectionPointContainer
  • IEnumConnections / IEnumConnectionsPoints
  • IDispatch, IPersistStorage, IAdviseSink, IErrorInfo, IFontDisp
  • IOleObject, IOleContainer, IOleInPlaceObject, IOleWindow. IOleClientSite, IOleInPlaceSite, IOleInPlaceSite, IOleInPlaceSiteEx, IOleInPlaceActiveObject, IOleControlSite. IOleControl, IOleInPlaceSiteWindowless, IOleInPlaceFrame
  • IDataObject, IViewObject2, IProvideClassInfo, ISpecifyPropertyPages
  • ISimpleFrameSite, IPropertyNotifySink
  • IClassFactory2, IServiceProvider
All these interfaces work with several tested OCX controls. The supplied example uses a Flash Player OCX Component, which is almost present in every Windows system. The Container was tested on Win7-64 bit and Win10-64 bit systems.
Other OCX-Components like GUI-Controls (Checkbox, Combobox, etc.) work seamlessly together with the container. Also a Web-Browser Component and the Windows media Player react correctly when they are embedded.
Attached to this post are Flash Player Container and a test swf-file.

Best regards, Biterider


  • Moderator
  • Member
  • *****
  • Posts: 137
  • ObjAsm32
    • ObjAsm32
Re: ObjAsm64
« Reply #2 on: January 13, 2018, 11:46:31 PM »

I want to present one of the most used and ancient objects implemented in assembler, called “Collection”.
Collections are, in first instance, repositories for any type of objects, including other collections. Mixing different type of objects in this repository is also allowed.

Collections are designed for administrative use, where very high performance is not required but a high degree of flexibility and processing capabilities. In this regard, Collections provide forward and backward searching, forward and backward iterators, stream serialization, insertion, deletion, positioning, etc. supported in the background by an automatic memory management.

Multithread synchronization is ensured, like OA32, due to the use of the low level build in synchronization call mechanism (xOCall).

There are specialized descendants of “Collection” like sorted collections, string collections, data collections, and many others for different management tasks. You can derive your own descendant, redefining the methods you want to change.

The interface of a Collection object class looks like:
Code: [Select]
Object Collection, CollectionID, Streamable

VirtualMethod    Delete,          POINTER
VirtualMethod    DeleteAt,        DWORD
VirtualMethod    DeleteAll
RedefineMethod   Deserialize,     PDESER_INFO
DynamicMethod    DeserializeItem, POINTER, PDESER_INFO
DynamicMethod    DestroyItem,     POINTER
VirtualMethod    Dispose,         POINTER
VirtualMethod    DisposeAt,       DWORD
VirtualMethod    DisposeAll
RedefineMethod   Done
VirtualMethod    FirstThat,       POINTER, QWORD, QWORD
VirtualMethod    FirstThatNot,    POINTER, QWORD, QWORD
VirtualMethod    ForEach,         POINTER, QWORD, QWORD
VirtualMethod    ForEachRev,      POINTER, QWORD, QWORD
DynamicMethod    GetItem,         POB_Stream, PDESER_INFO
VirtualMethod    IndexOf,         POINTER
RedefineMethod   Init,            POINTER, DWORD, DWORD, DWORD
VirtualMethod    Insert,          POINTER
VirtualMethod    InsertAt,        DWORD, POINTER
VirtualMethod    ItemAt,          DWORD
VirtualMethod    LastThat,        POINTER, QWORD, QWORD
VirtualMethod    LastThatNot,     POINTER, QWORD, QWORD
RedefineMethod   Load,            POB_Stream, PDESER_INFO
VirtualMethod    PutAt,           DWORD, POINTER
DynamicMethod    PutItem,         POB_Stream, POINTER
RedefineMethod   Serialize
DynamicMethod    SerializeItem,   POINTER
RedefineMethod   Store,           POB_Stream
StaticMethod     SetLimit,        DWORD

DefineVariable   pItems,          POINTER,      NULL
DefineVariable   dCount,          DWORD,        0
DefineVariable   dLimit,          DWORD,        0
DefineVariable   dDelta,          DWORD,        0
DefineVariable   dMaxCapacity,    DWORD,        0
DefineVariable   ObjLock,         ObjectLock,   {}


It can be observed on the first line, started by the keyword “Object”, 3 elements, the name of the object class (Collection), its unique ID and finally its ancestor. Deriving “Collection” from “Streamable” means, that it inherits all capabilities of a “Streamable” object. This way, we can store the whole content of the “Collection” on an arbitray “Stream”. In most cases this is a disk file (DiskStream) but it can be a memory chunk or whatever is desired.

After the first definition line follow the methods. These define the procedural capabilities of this object. I’ll not comment each one, since the names are self-explanatory. You’ll notice the different method types supported by the ObjAsm64 framework.

Finally, after the method definitions follow the internal variables that are managed by “Collection” and their initial values when created.
If very high performance is an issue, other objects should be used like Linked-Lists or Red-Black-Trees.

I hope this post give you a brief insight to this important OO assembler element.

Best regards, Biterider


  • Member
  • ****
  • Posts: 589
  • <AMD>< 7-32>
Re: ObjAsm64
« Reply #3 on: January 14, 2018, 01:45:57 AM »
Fantastic Biterider!!

You are publishing the ObjAsm`s book by parts!  :t

I will expect  the part of "Red-Black-Trees" :biggrin: