The MASM Forum

Projects => ObjAsm => Topic started by: Biterider on January 27, 2019, 02:32:00 AM

Title: ObjAsm
Post by: Biterider on January 27, 2019, 02:32:00 AM
Hello
I am happy that I have made great progress in the project ObjAsm Fusion.
The main goals of the project were:
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
Title: Re: ObjAsm
Post by: HSE on January 31, 2019, 03:44:46 AM
Hi Biterider!!

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

ObjMem32:
Quote
ErrorMessageBoxA.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"


Title: Re: ObjAsm
Post by: Biterider on January 31, 2019, 04:15:52 AM
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
Title: Re: ObjAsm
Post by: HSE on January 31, 2019, 08:05:24 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)

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!
Title: Re: ObjAsm
Post by: HSE on January 31, 2019, 10:55:10 AM
Now in w7-32!

Some conditionality is required in OA_SET.cmd, example:
Code: [Select]
if [!TARGET_BITNESS!] == [32] (
    set Assembler="%OBJASM_PATH%\Build\Tools\UASM32.EXE"
) else (
  set Assembler="%OBJASM_PATH%\Build\Tools\UASM64.EXE"
)
Title: Re: ObjAsm
Post by: Biterider on January 31, 2019, 06:08:15 PM
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
Title: Re: ObjAsm
Post by: Biterider on January 31, 2019, 06:22:38 PM
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

Code: [Select]
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"
)
Title: Re: ObjAsm
Post by: TimoVJL on January 31, 2019, 06:36:18 PM
Code: [Select]
IF %PROCESSOR_ARCHITECTURE% == AMD64 (
ECHO x64
) ELSE (
ECHO x86
)
PAUSE
Title: Re: ObjAsm
Post by: Biterider on January 31, 2019, 07:27:00 PM
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
Title: Re: ObjAsm
Post by: HSE on January 31, 2019, 11:23:17 PM
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.
Title: Re: ObjAsm
Post by: HSE on February 03, 2019, 04:30:07 AM
Hi Biterider!

There is some problem with SmplMath functions with 2 arguments:
Code: [Select]
fSlv8 = max(10.0,0.0)
Code: [Select]
Error A2209: Syntax error: (0.0)) ? (10.0) : (0.0))>
Title: Re: ObjAsm
Post by: Biterider on February 03, 2019, 05:36:44 AM
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:

Code: [Select]
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



Title: Re: ObjAsm
Post by: HSE on February 03, 2019, 07:06:56 AM
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!
Title: Re: ObjAsm
Post by: Biterider on February 03, 2019, 09:28:51 PM
Hi
Quote
By 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




Title: Re: ObjAsm
Post by: HSE on February 04, 2019, 08:14:52 AM
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:
Code: [Select]
Destroy [esi].LINKED_NODE.pObject                 ;Save dispose of linked Object

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

Code: [Select]
fldReg eax

 RNG.inc(389) : error A2032: invalid use of register
Title: Re: ObjAsm
Post by: HSE on February 04, 2019, 08:54:16 AM
Code: [Select]
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).
Title: Re: ObjAsm
Post by: Biterider on February 04, 2019, 05:55:44 PM
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:
Code: [Select]
  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

Title: Re: ObjAsm
Post by: HSE on February 04, 2019, 11:38:23 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):
Code: [Select]
externdef p1stOMD:POINTER

The Model.inc file contains the SysSetup macro. It automatically includes ObjMem using these lines:
Code: [Select]
  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:
Code: [Select]
% includelib &LibPath&32\ObjMem32.lib

Thanks.
Title: Re: ObjAsm
Post by: Biterider on February 05, 2019, 01:17:42 AM
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
Code: [Select]
LibPath       CatStr    OA_PATH, <Code\Lib\32\>

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

Code: [Select]
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
Title: Re: ObjAsm
Post by: HSE on February 05, 2019, 02:44:54 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:

The LibPath symbol is set in the OA_Setup32.inc file
:icon_redface: I forget that I have:
Code: [Select]
LibPath       textequ <\masm32\lib\>; CatStr    OA_PATH, <Code\Lib\32\>

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:
Code: [Select]
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
Title: Re: ObjAsm
Post by: Biterider on February 05, 2019, 03:32:50 AM
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
Title: Re: ObjAsm
Post by: Biterider on February 05, 2019, 04:21:23 AM
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:

Code: [Select]
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
Title: Re: ObjAsm
Post by: HSE on February 05, 2019, 04:30:10 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

May I ask you to post the source of this line?
Code: [Select]
SetObject esi

New ItemLayout
push eax
Full code is in http://masm32.com/board/index.php?topic=6339.0
Title: Re: ObjAsm
Post by: HSE on February 05, 2019, 04:55:39 AM
Code: [Select]
Destroy [esi].LINKED_NODE.pObject::OA:Primer.Done
Who can imaging that?  :biggrin:  :biggrin: :biggrin: Impressive!

Thanks
Title: Re: ObjAsm
Post by: Biterider on February 05, 2019, 06:00:52 PM
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
Title: Re: ObjAsm
Post by: Obivan on February 12, 2019, 06:49:03 PM
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
Title: Re: ObjAsm
Post by: Biterider on February 13, 2019, 04:02:27 AM
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
Title: Re: ObjAsm
Post by: HSE on February 13, 2019, 08:38:01 AM
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.
Title: Re: ObjAsm
Post by: Obivan on February 15, 2019, 06:12:17 AM
Hi Biterider,

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
Title: Re: ObjAsm
Post by: Obivan on February 15, 2019, 06:17:08 AM
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
Title: Re: ObjAsm
Post by: tempuyax on April 30, 2020, 02:09:24 AM
Hi
I am still using Windows XP ... Does the new version of ObjAsm32 still support ??

salam
tempuyax

NortBorneo
Title: Re: ObjAsm
Post by: Biterider on April 30, 2020, 05:44:02 AM
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
Title: Re: ObjAsm
Post by: jack on September 24, 2021, 08:30:21 PM
hello Biterider
is your site down?
Title: Re: ObjAsm
Post by: Biterider on September 25, 2021, 03:33:14 AM
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
Title: Re: ObjAsm
Post by: Biterider on October 03, 2021, 06:50:42 PM
Hi
The homepage is online again  :cool:

Biterider
Title: Re: ObjAsm
Post by: jack on October 04, 2021, 10:18:52 AM
thank you Biterider :)