NASM OOP - Work In Progress

[Bryant Keller]

I'm not really trying for anything 1 to 1. But since it's the most used assembly/OOP implementation, it's good to try to pair up with it whenever possible to make things easier for users. Being realistic, however, I don't expect objects.inc to ever be anything as grand as OA32 nor would I even try.

[c051n3]

OK.  What are your thoughts on the following?

Code: [Select]

;all classes inherit from CRootObject
;a defined class without a specified parent class
;automatically inherits from CRootObject
;thus the following two lines are effectively identical
;   class CMyClass
;   class CMyClass, CRootObject
;
class CAppMutex
; scope is default public until private keyword encountered
     static qword, m_tid
private
; variables and methods from this point are private to the class
     static lptr, m_mutex
     static qword, m_refcount
public
; variables and methods from this point are publicly accessible
     static method, lock
; multiple method signatures
     static method, lock, qword:timeout
     static method, lock, qword:timeout, qword:tid
     static method, unlock
     static method, isLocked
endclass

I'm assuming that macro pair method/endmethod, when invoked in the user source, will automatically handle the 32/64 bit differences, name mangling, and calling convention issues based upon __OUTPUT_FORMAT__ correct?

[Bryant Keller]

Sure, I have quite a few thoughts on the above code.

First, the CRootObject (or CPrimer as it's probably going to be called if I decide to implement it) has already been put into the discussion by Homer. I'm not a fan on this method, I like how things work internally already but he also has suggested that the base object that everything inherits from is more popular. I'll leave that as a suggestion under consideration but I'm still not convinced that it won't just be a whole lot of redesigning for very little (if any) benefit.

As far as private/public, I still don't really see the point. Keep in mind that our class is just being allocated on the heap. Other than our VMT/VDT, everything else exists within that heap space. So it's not like we can actually block anything from having access to that memory, this isn't a compiler where I can do syntactical checks to make sure someone doesn't access the variables, it's just a macro set.

Multiple method signatures will not be implemented, nor will any method/endmethod macros. At least not by me. I did my HL stuff when I worked on NASMX, I might see if Keith wants to extend NASMX to support methods and objects.inc which would then probably support these features fairly easily, but I have no intention of doing it. Multiple method signatures can be implemented using the "Win32-ish" style of naming methods where you have the <MethodName>@<StackSize>. If you want to extend objects.inc to support this feature, you are more than welcome to. But I see no reason to.

Remember, my goal is "raw". I want objects.inc to be efficient and stable. I'm not really concerned about creating a feature rich OOP framework, I don't use OOP that much. But when I do use it, I would like it to be reliable. That's really what I'm aiming for. That's why I still haven't implemented icall (Interface Call [for COM]) and acall (Ancestor Call), because these are things which target a more specific need.

I have, however, made use of your import macro (renamed it to "use" to avoid conflicts with the IMPORT directive -- and "use" kinda reminds me of PERL). This does make things a great deal better under multi-file builds, however single file builds wouldn't work. To correct this, I set it so now users must %define SINGLE_FILE_BUILD before they include if they wish to use the class in a single file build environment. I don't see this as a problem since classes by design are meant to be used in multiple files. I'll update the mft.tar.gz on the server after I update the objects.inc here on the forum.

[c051n3]

Ok. Hopefully Keith will decide to extend it. Not sure if he would design in cross-platform support as that is not nasmx's raison d'etre. But it would be nice if the core itself were modified to enable a framework to be built that would compile on both Windows and Linux 32 and 64 bit systems. Having the core kept separate from nasmx would allow this.

If not, then I will be extending it in order to provide the necessary foundation to truly support a portable oop framework ( which has been my own personal goal all along ) and you probably wouldn't recognize it when I'm done with it.

[Bryant Keller]

Ok. Hopefully Keith will decide to extend it. Not sure if he would design in cross-platform support as that is not nasmx's raison d'etre. But it would be nice if the core itself were modified to enable a framework to be built that would compile on both Windows and Linux 32 and 64 bit systems. Having the core kept separate from nasmx would allow this.

You're kidding right? Have you actually used NASMX? Cross platform support was always taken into consideration, and with great pains, since it's earliest versions. Currently it supports Windows, Linux, XBox, and technically MacOSX support is finished but it's not been published as I didn't ever sit down and integrate the update into the nasmx.inc header. And thanks to Keith's insanely hard work it had 64-bit support for both Windows and Linux before NASM officially did. :p

Sorry for sounding like I was advertising, but it seems like the only things I ever hear people complain about what NASMX can't do, are the things that it was designed to do (same can be said for NASM actually). I think you've gotten a hold of some bad information.

If not, then I will be extending it in order to provide the necessary foundation to truly support a portable oop framework ( which has been my own personal goal all along ) and you probably wouldn't recognize it when I'm done with it.

Yea, have at it man! I've always supported people extending/forking from my work. And truthfully, you seem more enthusiastic about it than I am, as I'm doing this mostly targeting as a lower-end project and, as you mentioned, you are looking for a framework.

[c051n3]

I hope that didn't come across as a complaint as that was not my intention. I think what you guys have done is great stuff and I admire your work. You are correct in that I was under a false impression about nasmx. I need to revisit the package and examine it more thoroughly.

[Frank Kotler]

"I think you've gotten a hold of some bad information."

Or not enough information, perhaps. I see no indication anywhere how NASMX would be used to create a cross-platform app. Where should we be looking?

Best,
Frank

[Bryant Keller]

"I think you've gotten a hold of some bad information."

Or not enough information, perhaps. I see no indication anywhere how NASMX would be used to create a cross-platform app. Where should we be looking?

Best,
Frank

I think your right... both of you actually. Somewhere along the line the project was divided amongst Linux and Windows based explicitly on the archive file it's stored in (this was probably one of the many times the directory structure changed due to us having to change linkers on the Windows branch for various reasons, cause the Linux branch looks about the same). During this time it seems the cross platform demo appears to have vanished... It's still totally possible to do cross platform development however. It's just not totally apparent, or documented since we never bothered to write any documentation.   Just make use of libc or another cross platform library when requesting any system dependant service (I/O, Mem, etc). To be honest, it wouldn't be that hard to change objects.inc to use NASMX, just change this:

Code: [Select]

%ifidni __OUTPUT_FORMAT__,win32
EXTERN GetProcessHeap
EXTERN HeapAlloc
EXTERN HeapFree
%else
EXTERN malloc
EXTERN free
%endif
to read this instead:

Code: [Select]

%include "nasmx.inc"
IMPORT malloc
IMPORT free
Then change the nasm_alloc and nasm_free macros to:

Code: [Select]

%macro nasm_alloc 1
invoke malloc, %{1}
%endm

%macro nasm_free 1
invoke free, %{1}
%endm
And the core is now powered by NASMX. You could go one step further by changing the internal constructor to use the proc/endproc and you're half-way to full 64-bit support since both invoke and proc/endproc handle 64-bit.

But yeah... by design, it can do cross platform development. In fact that's about the only thing I use NASMX for (which is why I wasn't up to speed on the windows branch).

[Frank Kotler]

Okay. After posting that, I realized that "nasmx.inc" *will* work cross-platform. Pretty good trick in itself! I was thrown off by the two different distributions. If you'll recall, you had to tar up the Windows version for me, 'cause I couldn't find an archiver that would decompress the .exe (probably possible, but I don't know how). The two versions overlay each other nicely, without apparent conflict.

In the Linux branch of the "inc" directory, you've got a fairly limited "libc.inc"... which includes some constants which apply even if you're not using C. And "syscall.inc" appears to be just 32-bit... but could be expanded, I guess.

There's going to be a slight "issue" with that, in that "-f elf" and "-f elf32" are the same thing, but result in different "__OUTPUT_FORMAT__"s which don't match. Make 'em use "-f elf32" is probably the easiest workaround to that...

The Linux "demo1" uses sys_calls, so wouldn't be portable, but a "printf" version probably would...

I guess I've actually done a cross-platform example, in a way... Nathan sent me some "experiments" he's doing, using the nasmx include files for the Windows version, and using some of the "socket" APIs. I wrote a "fakeapi.asm", which includes routines of the same name, same parameters, which do "something roughly similar", using syscalls. To my astonishment, it works! I didn't use your "syscall.inc", but I could probably alter it so it did... This is only going to work for a very limited subset of APIs - I don't have much hope for portable GUI apps - but it shows some promise for "console" and "socket" stuff.

So yeah... you should maybe "advertise" more. There's more to NASMX than I realized!

Best,
Frank

[Bryant Keller]

Okay. After posting that, I realized that "nasmx.inc" *will* work cross-platform. Pretty good trick in itself! I was thrown off by the two different distributions. If you'll recall, you had to tar up the Windows version for me, 'cause I couldn't find an archiver that would decompress the .exe (probably possible, but I don't know how). The two versions overlay each other nicely, without apparent conflict.

The NASMX windows executable file will expand in WINE if you have that installed. The reason that archive readers like file-roller can't open the windows executable is because it's a custom installer, not a compressed .exe file. The file sets up various windows specific environment variables and then extracts everything into the system. I remember when Keith made the installer, it was a wise decision because we were repeatedly bombarded with questions about how to configure NASM and NASMX to work properly under windows, even to the point that many users were claiming that NASMX didn't work on various systems.

In the Linux branch of the "inc" directory, you've got a fairly limited "libc.inc"... which includes some constants which apply even if you're not using C. And "syscall.inc" appears to be just 32-bit... but could be expanded, I guess.

The system dependant syscall.inc was an idea I had back when I was running things that I don't think ever really continued. I was going to make the NASM32 project support two modes; Portable and Platform Dependant. Portable mode was reliant heavily on C based libraries which could be imported as needed. The Platform dependant mode however would have individual include files which extended NASM32 to support each platform's specific features (like system calls), this was more for the asm purists. I got about as far as getting Windows and Linux done but never got around to doing BSD before Keith took over and I don't think he was ever really interested in that aspect of the project, of course most people weren't.

There's going to be a slight "issue" with that, in that "-f elf" and "-f elf32" are the same thing, but result in different "__OUTPUT_FORMAT__"s which don't match. Make 'em use "-f elf32" is probably the easiest workaround to that...

The first thing in NASMX is:

Code: [Select]

%ifidn __OUTPUT_FORMAT__,elf
%elifidn __OUTPUT_FORMAT__,elf32
%elifidn __OUTPUT_FORMAT__,elf64
%elifidn __OUTPUT_FORMAT__,win32
%define __UNDERSCORE__
%elifidn __OUTPUT_FORMAT__,win64
%define __UNDERSCORE__
%else
%define __CDECL_UNDERSCORE__
%define __UNDERSCORE__
%endif
He could do the same thing in the top of his objects.inc modification but have it make things more specific for him:

Code: [Select]

%ifidn __OUTPUT_FORMAT__,elf
%define __BASE_FORMAT__ elf
%elifidn __OUTPUT_FORMAT__,elf32
%define __BASE_FORMAT__ elf
%elifidn __OUTPUT_FORMAT__,elf64
%define __BASE_FORMAT__ elf
%elifidn __OUTPUT_FORMAT__,win
%define __BASE_FORMAT__ win
%elifidn __OUTPUT_FORMAT__,win32
%define __BASE_FORMAT__ win
%elifidn __OUTPUT_FORMAT__,win64
%define __BASE_FORMAT__ win
%elifidn __OUTPUT_FORMAT__,macho
%define __BASE_FORMAT__ macho
%elifidn __OUTPUT_FORMAT__,macho32
%define __BASE_FORMAT__ macho
%elifidn __OUTPUT_FORMAT__,macho64
%define __BASE_FORMAT__ macho
%else
%error "unsupported output format."
%endif
This would probably be a good idea anyway as you really don't need to know the difference between 32bit and 64bit OUTPUT_FORMAT in most instances since you can determine your current bit-mode via %[__BITS__] which is more important than the object bit-mode when doing headers.

The Linux "demo1" uses sys_calls, so wouldn't be portable, but a "printf" version probably would...

Heh, yea. There were tons of complains about the demos, but they do what they were designed for. I just tried to show the syntax the best I could since there was no documentation. Also, speaking of the demos, it looks like Keith has been doing some work on the windows demos, there are some new ones I've not seen.

I guess I've actually done a cross-platform example, in a way... Nathan sent me some "experiments" he's doing, using the nasmx include files for the Windows version, and using some of the "socket" APIs. I wrote a "fakeapi.asm", which includes routines of the same name, same parameters, which do "something roughly similar", using syscalls. To my astonishment, it works! I didn't use your "syscall.inc", but I could probably alter it so it did... This is only going to work for a very limited subset of APIs - I don't have much hope for portable GUI apps - but it shows some promise for "console" and "socket" stuff.

Remember, just use a cross platform C library for the system dependant stuff. Things like GTK, Allegro, NCurses, OpenGL, OpenAL, and other cross platform libraries allow you to write code that will build across multiple system without changes to the source.

So yeah... you should maybe "advertise" more. There's more to NASMX than I realized!

Best,
Frank

And here I thought most of these features were pretty well known, like I said, it's the only reason I use it. Other than for cross platform development, I tend to just code using straight NASM.

[c051n3]

And the core is now powered by NASMX. You could go one step further by changing the internal constructor to use the proc/endproc and you're half-way to full 64-bit support since both invoke and proc/endproc handle 64-bit.

But yeah... by design, it can do cross platform development. In fact that's about the only thing I use NASMX for (which is why I wasn't up to speed on the windows branch).

Digging deeper into NASMX uncovered a slew of issues regarding handles, pointers, and structure size changes from win32 to win64 as currently defined in the NASMX windows include files (dated 2009-01-12). Many of these have been promoted from dwords to qwords. This is the main reason why Microsoft recommends using INT_PTR macro for C/C++ coders. Are there any plans to update NASMX's support of 64-bit Windows? Or am I misinformed yet again

[Bryant Keller]

Well, I've not really looked into the changes between Win32 and Win64, like I said - Keith was the magic man who got 64-bit Windows working. I wouldn't hold my breath for any updates, I believe we both agreed to take a break from working on NASMX with our personal lives becoming more demanding (him with an addition to his family and me with medical issues to deal with). This is the same reason why I'm not looking to turn the objects.inc into a major project, atm I'm only able to work on it in spurts of about an hour a week which wouldn't really promote a lot of growth.

[Keith Kanios]

I suppose it is time to make an appearance

I've had some time to think about the direction of NASMX, and here are my thoughts/decisions.

I don't have any [active] plans of advancing NASMX in the direction of trying to accommodate all of the different platforms, types, headers and whatnot. Such a direction would require proper high-level typing, and ultimately force NASMX to turn into an ugly/hacked-up version of C... if it is to be done right.

If I am able to, and do, ever pick back up on NASMX, it will be most likely geared toward NASMX as a platform library.

If cosine or someone else wants to contribute and advance the official NASMX, feel free.

[Rob Neff]

Long time lurker, first time poster. 
I am currently in the midst of developing a project that touches upon all topics being discussed in this thread (64bit, nasmx, and oop). I have some code which defines handles,structs, and ptrs to be bitsize relative in nasmx windows.inc file  and make the appropriate 32/64bit selection for using __OUTPUT_FORMAT__ and __BITS__ .

I would be willing to submit mods for "official" nasmx code rather than maintain a nasmx fork if you desire. The code itself is still being developed and is far from full Win SDK emulation but it's a start.

If you are looking for a contributor I am willing pitch in. For an example, the coding can be done two different ways.

Using typedefs:

Code: [Select]

%ifidni __OUTPUT_FORMAT,win32
%define RESHWND RESD
%define RESWPARAM RESD
%define RESLPARAM RESD
%elifidni __OUTPUT_FORMAT,win64
%define RESHWND RESQ
%define RESWPARAM RESQ
%define RESLPARAM RESQ
%endif

STRUC MSG
.hwnd RESHWND 1
.message RESD 1
.wParam RESWPARAM 1
.lParam RESLPARAM 1
.time RESD 1
.pt RESB POINT_size
ENDSTRUC

Or, without adding extra typedefs we can use:

Code: [Select]

%ifidni __OUTPUT_FORMAT,win32
STRUC MSG
.hwnd RESD 1
.message RESD 1
.wParam RESD 1
.lParam RESD 1
.time RESD 1
.pt RESB POINT_size
ENDSTRUC
%elifidni __OUTPUT_FORMAT,win64
STRUC MSG
.hwnd RESQ 1
.message RESD 1
.wParam RESQ 1
.lParam RESQ 1
.time RESD 1
.pt RESB POINT_size
ENDSTRUC
%endif

Note that for pointer type conversions my preference is for typedefs that mimic the MS SDK:

Code: [Select]

%ifidni __OUTPUT_FORMAT,win32
%define INT_PTR RESD
%ifidni __OUTPUT_FORMAT,win64
%define INT_PTR RESQ
%endif

Let me know your preferences and how you wish to receive any mods.

[Bryant Keller]

Personally, I tend to use the typedef method in my code. And I would probably do the same thing in NASMX if I was to do any internal updates. My personal 'base.asm' file (which gets pre-included via NASMENV) contains the following lines.

Code: [Select]

%define sizeof(_x_) _x_ %+ _size
%define reserve(_x_) _x_ %+ _res

%idefine byte_size 1
%idefine word_size (byte_size * 2)
%idefine dword_size (word_size * 2)
%idefine qword_size (dword_sized * 2)
%idefine tword_size 10
%idefine oword_size (qword_size * 2)

%idefine byte_res RESB
%idefine word_res RESW
%idefine dword_res RESD
%idefine qword_res RESQ
%idefine tword_res REST
%idefine oword_res RESO

%define int8_t byte
%define int16_t word
%define int32_t dword
%define int64_t qword
%define int80_t tword
%define int128_t oword

%define int8_t_size 1
%define int16_t_size (int8_t_size * 2)
%define int32_t_size (int16_t_size * 2)
%define int64_t_size (int32_t_size * 2)
%define int80_t_size 10
%define int128_t_size (int64_t_size * 2)

%define int8_t_res RESB
%define int16_t_res RESW
%define int32_t_res RESD
%define int64_t_res RESQ
%define int80_t_res REST
%define int128_t_res RESO

%define iax8 al
%define iax16 ax
%define iax32 eax
%define iax64 rax
%define iax128 xmm0

%define ibx8 bl
%define ibx16 bx
%define ibx32 ebx
%define ibx64 rbx
%define ibx128 xmm1

%define icx8 cl
%define icx16 cx
%define icx32 ecx
%define icx64 rcx
%define icx128 xmm3

%define idx8 dl
%define idx16 dx
%define idx32 edx
%define idx64 rdx
%define idx128 xmm4

%define ibp8 sp
%define ibp16 sp
%define ibp32 esp
%define ibp64 rsp
%define ibp128 rsp

%define isp8 sp
%define isp16 sp
%define isp32 esp
%define isp64 rsp
%define isp128 rsp
This gives me very C-ish style types and allows me to do some really cool stuff like:

Code: [Select]

STRUC MSG
.hwnd reserve( int%[__BITS__]_t ) 1
.message reserve( dword ) 1
.wParam reserve( int%[__BITS__]_t ) 1
.lParam reserve( int%[__BITS__]_t ) 1
.time reserve( dword ) 1
.pt reserve( byte ) POINT_size
ENDSTRUC
Which will change it to the correct RESD/RESQ based on the BITS n definition in your code.

And..

Code: [Select]

push ibp%[__BITS__]
mov ibp%[__BITS__], isp%[__BITS__]
;...
leave
ret
I don't use these register mods a whole lot, but they do come in handy in some projects... the type mods however I use in almost everything.. definitely useful.