ObjAsm

[HSE]

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 
Remain a problem with objmem library ( and it's not automatically included like in ObjAsm32).

[Biterider]

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

[HSE]

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.

[Biterider]

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

[HSE]

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


[Biterider]

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

[Biterider]

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. 

Biterider

[HSE]

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

[HSE]

Code: [Select]

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

Who can imaging that?    Impressive!

Thanks

[Biterider]

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

[Obivan]

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

[Biterider]

Hi Obivan
I'm happy to hear about you 
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

[HSE]

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.

[Obivan]

Hi Biterider,

I'm happy to hear about you 
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

[Obivan]

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