The MASM Forum
Projects => ObjAsm => Topic started 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:
- 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: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"
-
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
-
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!
-
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
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
-
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
-
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
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.
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
-
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:
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: 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
-
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?
SetObject esi
New ItemLayout
push eax
Full code is in http://masm32.com/board/index.php?topic=6339.0
-
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
-
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,
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.
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
-
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 :)