The MASM Forum

Hello
I am happy that I have made great progress in the project ObjAsm Fusion.
The main goals of the project were:

   
• Merging the project ObjAsm32 and ObjAsm64 in one
• Develop an assembler code that can be assembled as x86 and x64 regardless of the target bitness
• Integrate the latest translated C header files generated from the h2incX project
• Introduction of Namespaces
• Introduction of Annotations
• Revised and modernized tool chain
• Support library for 32 and 64 bit
• New documentation

The reason for merging both projects is maintainability. I'll freeze ObjAsm32 like it is today and ObjAsm64 will not pass the beta phase. Instead, ObjAsm will cover both projects with a common code platform. Much work has been done to support this idea from proof-of-concept up to the included project. The aim of the fusion project was to ensure the best compatibility with the previous projects.

The second pillar of the project is the translated C/C++ header files. They are far from finished, but after the translation tool has been developed, missing files or new versions can be translated ad-hoc. The benefit of having the latest files is clear, but there are some challenges that needed to be addressed. One of them was naming conflicts.
The best solution was the introduction of the namespace concept. At the implementation level, the names of objects and members are mangled. COM members are also mangled, but not interface names. Doing so we avoid naming conflicts with the declared API names or other symbols. Now you have full freedom to use the name you want and reuse the names even in different namespaces.

Another improvement is the use of annotations. They are intended primarily for code analysis tools that will be released on a later stage.
The previous assembly tool chain has been completely revised using .cmd files. Sharing information with the RC compiler is implemented by pre-processing some files and automatically generating a file that is passed on. This strategy avoids synchronization issues but requires the use of the provided tools.

What will come next? The presented code base is not as complete as ObjAsm32. The code analysis tools need to be completed. For the h2incX project, a GUID extraction tool should be coded to complete the sGUID.inc file.

Nevertheless, it is a good start point and for the moment, I uploaded a "teaser", where the functionality can be checked.

As always, constructive comments are welcome!  :t

Biterider

Hi Biterider!!

Instructions say install uasm in the "...\ObjAsm\bin\tools" folder, but is searched in "...build\tools".

ObjMem32:

QuoteErrorMessageBoxA.asm(25) : Error A2137: Conflicting parameter definition: dLangID
ErrorMessageBoxA.asm : 0 warnings, 1 errors
ErrorMessageBoxW.asm(25) : Error A2137: Conflicting parameter definition: dLangID
ErrorMessageBoxW.asm : 0 warnings, 1 errors

sdword2decA.asm(31) : Error A2137: Conflicting parameter definition: sdValue
sdword2decA.asm : 0 warnings, 1 errors
sdword2decW.asm(31) : Error A2137: Conflicting parameter definition: sdValue
sdword2decW.asm : 0 warnings, 1 errors

There is no "...\ObjAsm\Code\Objects\MakeObjects.cmd"

Hi HSE
You are right, it should say "ObjAsm\Build\Tools". I will ask if I'm permitted to distribute if the future UASM together with ObjAsm.

The 2 bugs in ObjMem32 are there. I have corrected them.

The path configuration is located here "ObjAsm\Code\OA_Setup32.inc" or here "ObjAsm\Code\OA_Setup64.inc"
If wanted, I can upload the lib files to facilitate the installation.

I intentionally removed "...\ObjAsm\Code\Objects\MakeObjects.cmd" and the .asm files in the objects folder. For the moment include your objects using "MakeObjects".

Thanks!  :t

Biterider

Quote from: Biterider on January 31, 2019, 04:15:52 AM
The path configuration is located here "ObjAsm\Code\OA_Setup32.inc" or here "ObjAsm\Code\OA_Setup64.inc"
If wanted, I can upload the lib files to facilitate the installation.

I found the location just a minute after posting. I just change LibPath to were are already installed: \masm32\lib and \masm32\lib64\ (this machine is w7-64)

Quote from: Biterider on January 31, 2019, 04:15:52 AM
I intentionally removed "...\ObjAsm\Code\Objects\MakeObjects.cmd" and the .asm files in the objects folder. For the moment include your objects using "MakeObjects".

Most of the time I use MakeObjects because objects are builded with option Unicode and I using ANSI  :biggrin:.
I left in that mode because DednDave say always we have to make Unicode applications  :icon14: but I only know how to parse ANSI strings  :icon13:

Thanks!

Now in w7-32!

Some conditionality is required in OA_SET.cmd, example:if [!TARGET_BITNESS!] == [32] (
    set Assembler="%OBJASM_PATH%\Build\Tools\UASM32.EXE"
) else (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM64.EXE"
)


Hello HSE
I'm glad that you are looking so deep.  :icon14:

TARGET_BITNESS refers to the code being assembled.
UASM32 or USAM64 are a 32 and 64 bit application which can run on appropriate CPUs. Both are capable of generating 32 or 64 bit code.

The ObjAsm toolchain uses OA_BUILD.cmd that parses the .asm file in the main folder to determine how to set the TARGET_BITNESS variable. This way, the other tools can be configured automatically. This is done using the files in the "ObjAsm\Build\Options" folder.

Biterider

Hello HSE
After I re-read your post, I believe that you want to automatically use the right tool.
I found this here https://support.microsoft.com/en-ch/help/556009. With this help we could choose UASM32 or UASM64 accordingly.
I'll take a look at it.

Biterider

PS:
Maybe something like this


reg Query "HKLM\Hardware\Description\System\CentralProcessor\0" | find /i "x86" > NUL && set SYSTEM_BITNESS=32 || set SYSTEM_BITNESS=64


if %SYSTEM_BITNESS%==32 (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM32.EXE"
) else (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM64.EXE"
)

IF %PROCESSOR_ARCHITECTURE% == AMD64 (
ECHO x64
) ELSE (
ECHO x86
)
PAUSE

Hi
Cool  :t
According to this ms official documentation https://docs.microsoft.com/de-ch/windows/desktop/WinProg64/wow64-implementation-details, would it not be safer to check for PROCESSOR_ARCHITECTURE=x86?

Biterider

Sounds good to use SYSTEM_BITNESS for tool selection  :t

How you set SYSTEM_BITNESS is a diferent question. Could be register, environment or manually method, not very important because you know what system you have and you have to modify this only once time.

Hi Biterider!

There is some problem with SmplMath functions with 2 arguments:
fSlv8 = max(10.0,0.0)
Error A2209: Syntax error: (0.0)) ? (10.0) : (0.0))>

Hi HSE
That's great! You are using the translated header files   :t
Looking at the macro extension of max, I quickly found the name collision. MS defines max and min as macros in minwindef.inc and stdlib.inc.

To solve it, rename simplemaths operator or undefine min and max before including Simplemath (only UASM).
Something like:


SysSetup OOP, NUI32, ANSI_STRING, DEBUG(WND)

undef max
undef min

include D:\MASM32\SmplMath\macros\SmplMath\math.inc
include D:\MASM32\SmplMath\macros\macros.inc

Biterider

You are using some header files by default  :biggrin:

By the way msvcrt.inc is missing in package.

You can redefine macros and SmplMath's max macro is last one, my mistake stdlib was last one. (Just in case, with option NOMINMAX there is no definition of min and max macros in minwindef.inc, and I maked same thing in your stdlib.inc) <- that solve the problem.

Now I have to make a new hjwasm with more macrolevels!!

Thanks!

Hi

QuoteBy the way msvcrt.inc is missing in package.

As far as I know, there is no such thing like msvcrt.h. There are a bunch of header files to support the C++ runtimes.
Check this link https://support.microsoft.com/en-us/help/154753/description-of-the-default-c-and-c-libraries-that-a-program-will-link

Maybe someone who knows more about C ++ can give a better answer.  ::)

Biterider

Quote from: Biterider on February 03, 2019, 09:28:51 PM
Maybe someone who knows more about C ++ can give a better answer.  ::)

No problem. There is solid msvcrt.inc for Masm32 and Masm64, but are not automatics, and nobody can guarantee compatibility.

Apparently I lost my hjwasm13 source, but I build an AsmC with more macro levels and nestings.

Little problems in 32bit system:
Destroy [esi].LINKED_NODE.pObject                 ;Save dispose of linked Object

LinkedList.inc(130) : error A2052: forced error : MethodInvoke - unknown method: OA_LinkedList._pObject


fldReg eax

RNG.inc(389) : error A2032: invalid use of register

And a little more:
ObjMem32.lib(GetObjectTemplate.obj) : error LNK2001: unresolved external symbol _pFirstObject
Integ01.exe : fatal error LNK1120: 1 unresolved externals


Incompatibilities includes-libraries, I think. An error in path  :biggrin:
Remain a problem with objmem library ( and it's not automatically included like in ObjAsm32).

Hello HSE
Many Thanks!  ;)
I searched the entire directory for "pFirstObject" and found no occurrence. I also checked "...\ObjMem\X\GetObjectTemplate.asm" and nothing. Maybe are you including an old version of the library?

The Model.inc file contains the SysSetup macro. It automatically includes ObjMem using these lines:
  if TARGET_BITNESS eq 32
    % includelib &LibPath&ObjMem32.lib
  else
    % includelib &LibPath&ObjMem64.lib
  endif

There must be something wrong.

I'll look into the other issues a bit later...

Biterider

Quote from: Biterider on February 04, 2019, 05:55:44 PM
I searched the entire directory for "pFirstObject" and found no occurrence. I also checked "...\ObjMem\X\GetObjectTemplate.asm" and nothing. Maybe are you including an old version of the library?

There was no problem in 64bits. I think problem is (in ...\ObjMem\X\GetObjectTemplate.asm):externdef p1stOMD:POINTER

Quote from: Biterider on February 04, 2019, 05:55:44 PM
The Model.inc file contains the SysSetup macro. It automatically includes ObjMem using these lines:

Code Select Expand

  if TARGET_BITNESS eq 32
    % includelib &LibPath&ObjMem32.lib
  else
    % includelib &LibPath&ObjMem64.lib
  endif

There must be something wrong.

Yes in 32bits the path is:
% includelib &LibPath&32\ObjMem32.lib


Thanks.

Hello HSE
In regard of the "pFirstObject" thing, please check if the file \ObjMem\X\GetObjectTemplate.asm ist the same as the one I attached.

The LibPath symbol is set in the OA_Setup32.inc file
LibPath       CatStr    OA_PATH, <Code\Lib\32\>


The corresponding setup file is taken from the SysSetup macro
Example:

SysSetup OOP, WIN32, WIDE_STRING, DEBUG(WND)


Using WIN32 we instruct to use a Windows interface in 32 bit mode. Possible options are
WIN32, WIN64, NUI32 and NUI64 (No User Interface)

Biterider

Quote from: Biterider on February 05, 2019, 01:17:42 AM
In regard of the "pFirstObject" thing, please check if the file

Apparently is an artifact of wrong and wright ObjMem32.lib path at same time :icon_eek:

Quote from: Biterider on February 05, 2019, 01:17:42 AM
The LibPath symbol is set in the OA_Setup32.inc file

:icon_redface: I forget that I have:

LibPath       textequ <\masm32\lib\>; CatStr    OA_PATH, <Code\Lib\32\>


Quote from: Biterider on February 05, 2019, 01:17:42 AM
Possible options are
WIN32, WIN64, NUI32 and NUI64 (No User Interface)

I was having WINDOWS.

Now I have a little problem with binary. For sure is my AsmC, was relatively easy to build but itsn't last version.

I don't know if Uasm also make duplicated "mov edi, eax" in New:
Address   Hex dump          Command                                  Comments
00412940  |> \8BF8          MOV EDI,EAX
00412942  |.  BE C87E4300   MOV ESI,OFFSET _TPL_OA_ItemLayout
00412947  |.  B9 09000000   MOV ECX,9
0041294C  |.  8BF8          MOV EDI,EAX
0041294E  |.  F3:A5         REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS


Hello HSE
I think you are using an older version of ObjMem that uses this symbol. If you recheck the paths and rebuild the library, the problem may be resolved.
If you miss an updated file, please let me know.

The code sequence you have posted looks like a "new" macro. I have checked the code and it seems possible that "mov edi, eax" is emitted twice. May I ask you to post the source of this line?

Thank you!

Biterder

Hello
I looked at the problem of the Destroy macro. The new ObjAsm contains some new syntax extensions. One of these is the ability to specify an alternative destructor for Destroy.
In that case, Destroy expected something else. The correct syntax is:

Destroy [esi].LINKED_NODE.pObject::OA:Primer.Done

Since I've seen that you're using the LinkedList object, I've translated it so it can be used with 64 bits as well.  :biggrin:

Biterider

Quote from: Biterider on February 05, 2019, 03:32:50 AM
I think you are using an older version of ObjMem that uses this symbol.

It's that. With a wrong path, the oldlibrary is also located (because default path):t

Quote from: Biterider on February 05, 2019, 03:32:50 AM
May I ask you to post the source of this line?


SetObject esi

New ItemLayout
push eax

Full code is in http://masm32.com/board/index.php?topic=6339.0

Quote from: Biterider on February 05, 2019, 04:21:23 AM

Code Select Expand

Destroy [esi].LINKED_NODE.pObject::OA:Primer.Done

Who can imaging that?  :biggrin:  :biggrin: :biggrin: Impressive!

Thanks

Hi
I confirm that the code duplication issue is a bug, but without consequences.
I fixed it and attached the new file.

Thanks to HSE.  :t

Biterider

Moin Biterider,

nice work.  :t But can you change the TARGET_BITNES to TARGET_PLATTFORM and from 32/64 into x86, X64 (or AMD64), IA64 or more? This make the Framework more flexible for Crossassembling for other Plattforms. In the theory you can make assembling for any ARM SOC with the correct assembler for that plattform.

Obi

Hi Obivan
I'm happy to hear about you  :biggrin:
I hope you can join us again!

I can modify the names of those symbols to TARGET_PLATFORM = x86 or x64, but is this really equivalent to application bitness?

Biterider

Quote from: Obivan on February 12, 2019, 06:49:03 PM
In the theory you can make assembling for any ARM SOC with the correct assembler for that plattform.

You need an ARM assembler that understand same macros. Then you can begin to think in  TARGET_PLATFORM = x86 , x64, ARM32 or ARM64.

Hi Biterider,

Quote from: Biterider on February 13, 2019, 04:02:27 AM
I'm happy to hear about you  :biggrin:
I hope you can join us again!

yes i'm will try it. I hope i have enough time.

Quote
I can modify the names of those symbols to TARGET_PLATFORM = x86 or x64, but is this really equivalent to application bitness?

Sure, an X64 platform is a 64 Bit CPU with an 64 Bit OS. You can execute an x86 compiled Windows code on an X64 platform with 64 Bit Windows.
My idea is, that you can esaly extend the target platform, when you don't use 32 or 64 as symbol. We will define a feature, that you can use in the future. When ever you will.

Obi

Quote from: HSE on February 13, 2019, 08:38:01 AM

Quote from: Obivan on February 12, 2019, 06:49:03 PM
In the theory you can make assembling for any ARM SOC with the correct assembler for that plattform.

You need an ARM assembler that understand same macros. Then you can begin to think in  TARGET_PLATFORM = x86 , x64, ARM32 or ARM64.

No i don't need this, but you can when you will. I think this chance let the framework open for the future. ;-)

Obi

Hi
I am still using Windows XP ... Does the new version of ObjAsm32 still support ??

salam
tempuyax

NortBorneo

Hi
The OOP model is completely independent of the operating system version.

Over time, some new features have been added to the libraries that require more modern APIs.
In general, however, you shouldn't have any problem.

Processors have also changed since the XP era.
ObjAsm has some built-in switches that can be used to fall back to these older instruction sets.

Biterider

hello Biterider
is your site down?

Hi jack
Thanks for reporting it. It seems that the provider has some service issues.
Let's see if he can solve it in the next few hours.

Biterider

Hi
The homepage is online again  :cool:

Biterider

thank you Biterider :)

Hi Biterider!

Quote from: Biterider on April 30, 2020, 05:44:02 AMThe OOP model is completely independent of the operating system version.

Have somebody ever reported success running ObjAsm programs for WinXP?

Thanks, HSE.

Hi HSE
Maybe it's splitting hairs, but the OOP model has nothing to do with the operating system. 
However, the APIs used for implementation behave differently. Here you have to pay attention to the target OS version. 
For example, the object implementation of "MovingThrobber" only works from Win8 onwards.

Biterider

Quote from: Biterider on November 07, 2023, 05:15:58 AMHowever, the APIs used for implementation behave differently.

Yes. In theory, APIs are selects with switches. But perhaps some switch don't work like expected (M$ no longer support for example), or I just missing one :biggrin:

Apparently the problem is in non-OOP code, mostly plain asm but using some APIs. 

I will have to make more simple tests then  :eusa_boohoo:

Thanks.

Note: progran run perfectly in WOW64, but that is a very complex machine even capable to correct things. :smiley: