Sol_Asm new release on 2007_12_25

[Vortex]

The Digital Mars linker can link SolAsm OMF object modules. I tested the OMF Alink demo to build the executable.

Bogdan, the assembler sets the entry point as _main not _App_Init :

Code Select Expand


PUBDEF - Public Names Definition = 1A0
Base Group = FLAT
Base Segment = code
#1 = _main OFFSET = 2

The free DM tools are available from :

http://www.digitalmars.com/download/freecompiler.html

[attachment deleted by admin]

[BogdanOntanu]

Hi Vortex,

Thank you for the samples, tests and suggestions ...  ;)

Bogdan, the assembler sets the entry point as _main not _App_Init :

Yes that is true.

I guess it is a left over from some of my tests... one of the linkers i have testes apparently wanted that symbol name to be defined  along with FLAT. I will check again if that hardcoded symbol name is in fact needed.

What you did there with StdOut is quite "a hack"; patching SOl_ASM's jump table to get imports from a static lib working :)
I guess it can only work for the first function imported from a LIB and for the last entry in the jump table.

But I see your point ;)
I will add static imports (extern) and static exports (export/public/global) to Sol_Asm.

Maybe I should rename the current "export" keyword to "export_func" to make it clear that it is an DLL kind of export an use the "export" keyword for the OBJ static kind of export.

[Vortex]

Hi Bogdan,

Many thanks for your decision to support static libraries.

Bogdan, yes my method is a kind of trick but it's not limited with the first and last items. I added other functions to the test library and this didn't break anything.

A question, will it be possible to remove the import_dll statement targetting object file output? This statement has no any effect in object modules in my opinion.

[attachment deleted by admin]

[BogdanOntanu]

Bogdan, yes my method is a kind of trick but it's not limited with the first and last items. I added other functions to the test library and this didn't break anything.

Yes I see that now, your method is general. "Mea culpa" ... please excuse my error.

A question, will it be possible to remove the import_dll statement targetting object file output? This statement has no any effect in object modules in my opinion.

Yes, that would be a possibility. Now I am thinking to a few options for static libs and OBJ output:

1) IMPORT_LIB

Code Select Expand


import_dll kernel32.dll
import_func ExitProcess alias __imp__ExitProcess@4

import_lib test.lib
import_func StdOut alias _StdOut@4


This will mark ExitProcess as an function imported from an DLL and StdOut as an function imported from an static LIB.
Additionally it could also paly the role of MASM includelib keyword.

2) EXTERN

Code Select Expand


extern StdOut alias _StdOut@4
extern ExitProcess alias _ExitProcess@4


This way you will not need a import_lib statement and will mark StdOut and ExitProcess as external symbols that are to be resolved by the linker in whatever way is possible (DLL or static lib).

I will probably implement both :D