ObjAsm

[HSE]

Code Select Expand

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 Expand

  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 Expand

externdef p1stOMD:POINTER

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:

Code Select Expand

% 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 Expand

LibPath       CatStr    OA_PATH, <Code\Lib\32\>


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

Code Select Expand

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 Expand


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 Expand


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 Expand

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 Expand


SetObject esi

New ItemLayout
push eax

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

[HSE]

Code Select Expand

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