I'm trying to convert big masm project to tasm. The main reason is to statically link it to the delphi project. Every other way I'm try will not work - if obj file is greater than 1 kb the only message I see from delphi is "Bad object format" :( So I have to convert it to tasm.

I'm not so familiar with tasm syntax, maybe I do something wrong but how to force tasm to not complain about this:
abcd struc

...
some_field dd ?
...
abcd ends

abcd_1 struc
...
some_field dd ?
...
abcd_1 ends

I.e. tasm don't like if the same name used in the different structures? The same thing happen with local labels inside the different procs but with the same name like @@error:

Next problem is jcc @F/@B. Is there any workaround? I have a couple of thousands of such jumps

P.S. I hate borland and everything they do after this :mad:
Posted on 2004-03-11 02:57:04 by masquer
Have you tried using a coff2omf tool instead?
I think such a tool might be included with the digitalmars compiler, at least googling for "coff2omf" digitalmars was the first hit - http://www.digitalmars.com/ .
Posted on 2004-03-11 03:38:55 by f0dder
Yes, I'm tried - no luck.
I'm also try to use /omf option with ml.exe shipped with NET Studio (actually it gives the best result so far). As I were saying - obj under 1kb is working fine (couple of proc, API's and data), but my obj should be about 50-70 kb (about 200 proc, less than 10 API's, some data).
Posted on 2004-03-11 03:51:08 by masquer
Below options should take care of some problems:



OPTION SCOPED

LOCALS
nosmart
nojumps

;=======================
; activates a lots of gadgets
; like @@: temp labels
;=======================
quirks
masm51


Unfortunately i do not think that there is a solution for structure members names
you will HAVE to find distinct names for them... i suggest adding:

ab1_some_field dd ?
ab2_some_field dd ?

I guess you hate Borland because you have learned MASM first :P
I am doing just fine with TASM, but yeah MASM has its advantages also :D

If the project is big/huge ... maybe you can find another solution?
dynamic linking or an COFF to OBJ converter...

Because TASM is old and needs quite a lot of patience and knowledge to use... esp if you are not used with its "quirks"

Perheaps you should try the new versions TASM v5.3 in BCB maybe it's a little more permisive?
Posted on 2004-03-11 04:09:03 by BogdanOntanu
tasm can't handle structure fields with the same names in different structures? Oh gawd how lame.
Posted on 2004-03-11 04:11:32 by f0dder
Oh YES is can but only in IDEAL mode :P
Unfortunately IDEAL mode is much to different from MASM for a fast/easy conversion
So the code is there and can do it but they have choosen not to :D

And i am happy because it saves me a LOT of typing assumes or full structure_names.structure_field

And most of the time i am used not to use duplicated names in structures... for my style it was a perfect match ;)

There should be a switch/option to enable it even in MASM emulation mode ... but i am uncertain.. honestly i was so happy that it does not allow duplicated names that i did not searched .
Posted on 2004-03-11 04:19:05 by BogdanOntanu
Thank you very much Bogdan!

@F/@B and local labels is working now!

If the project is big/huge ... maybe you can find another solution?
dynamic linking or an COFF to OBJ converter...

Dll is not acceptabe - that's the point :( COFF to OBJ is not working too

Because TASM is old and needs quite a lot of patience and knowledge to use... esp if you are not used with its "quirks"

You mean in stack frames and instead of ebp?

Perheaps you should try the new versions TASM v5.3 in BCB maybe it's a little more permisive?

I'm using 5.0r. You think it is worth to try 5.3?

I have another annoing thing
...

local SomeLocalVariable :dword
...
call BlaBla, edx, edi, offset SomeLocalVariable ; here is warning CALLPROC(1) Argument needs type override
...
ret

BlaBla PROC uses edi esi, arg1, arg2, arg3
...

As I understand something wrong with first argument but I dont get what exactly :confused:

f0dder
tasm can't handle structure fields with the same names in different structures? Oh gawd how lame.

For sure :)
Posted on 2004-03-11 04:27:51 by masquer
Ah no, esp=esspecially not the ESP register

TASM uses a "slightly" diffrent PROC definition

My_Proc PROC
USES esi,edi
ARG arg1:dword,arg2:dword
LOCAL lvar1:dword,lvar2:dword

....

ret
ENDP

But i thought it will also accept MASM style IF you setup MASM51 option ... eh i am to tired to check the manuals now...maybe after i have a sleep...

Have you setup a .MODEL FLAT,STDCALL directive i guess ?

Also a LOCAL variable inside a procedure CAN NOT be used as a parameter for an extended call syntax with the OFFSET operator... OFFSET is calculated at compile time while that address is only known at runtime (beeing on stack)

For this MASM has ADDR macro that is basically a LEA eax,local_variable ...

In TASM i guess you have to either use the LEA instruction yourseld or define/use ADDR also..

I also use TASM 5.0r... i have no ideea IF TASM v5.3 would be better or worst... it was just a hint...

I am only sure that TASM v5.3 cand accept a greater hash table sizes on command line...
and hash table space can be a problem with TASM on huge projects :D
Posted on 2004-03-11 04:56:17 by BogdanOntanu
Posted on 2004-03-11 04:57:59 by Vortex
Thanks again, Bogdan

"lea" instead of "offset" removes this warning.
Posted on 2004-03-11 05:26:56 by masquer
masquer,

Have you tried using MASM to produce OMF modules instead of COFF types. If you code can be done that way, it may work when linked into Delphi.
Posted on 2004-03-11 06:41:02 by hutch--
It seems really odd that it works when smaller that 1K. I don't know anything about Delphi, but I wonder if there's a "switch" or some sort of option that may solve the problem. Maybe something like filealign...:confused:
Posted on 2004-03-11 09:11:06 by S/390
hutch--

Yes, of course, this is the first things I did. Seems there is a difference between omf obj from masm and tasm.

As far as I noticed (using tdump.exe) tasm's output contain PUBDEF (flag?) near _every_ public proc and masm's have this record only near the first one. Even if I put EXPORT keyword to every proc in my source Delphi just says "Bad object format".

I think the only way to statically link big masm project with delphi/cbuilder is to convert it to tasm. I'l be more than happy if I'm wrong.

S/390
File align did not have anything related here. The only swich that could possibly help is /omf. But it doesn't :(
Posted on 2004-03-11 09:25:24 by masquer

masquer,

Have you tried using MASM to produce OMF modules instead of COFF types. If you code can be done that way, it may work when linked into Delphi.


Delphi requires a specialized OMF file format. The *only* reason I ever created TASM output for HLA, for example, was specifically to allow you to link HLA code with Delphi. Fortunately, Kylix doesn't have this problem (of course, it links in ELF rather than OMF). Too bad Borland doesn't extend the ability to link NASM (or other assembler's) code into the Windows product. Particularly as they've dropped support for TASM.
Cheers,
Randy Hyde
Posted on 2004-03-11 09:49:49 by rhyde

I think the only way to statically link big masm project with delphi/cbuilder is to convert it to tasm. I'l be more than happy if I'm wrong.

Tried using MS link to link masm + delphi .obj? Iirc ms link supports OMF object files, so it might be worth trying it this way around? (Then again, might not be an option, considering those 'package' thingamajigs delphi and bcb uses.)
Posted on 2004-03-11 10:58:55 by f0dder
Too bad Borland doesn't extend the ability to link NASM (or other assembler's) code into the Windows product. Particularly as they've dropped support for TASM.

You can use NASM to produce object files that are compatible with Delphi, you just need to make sure the section names and flags match those of Borland OMF files. But yes, it would be very nice if their linker was a bit more flexible :)
Posted on 2004-03-11 13:25:06 by Jibz

The only swich that could possibly help is /omf. But it doesn't


Maybe this tool can help you:

http://www.anticracking.sk/EliCZ/export/OMF2D.zip


OMF2D can help in static linking given object file with main (object) file(s)
by converting given object file to main-linker-compatible object file:
Main + Functions.obj = Module
(here Functions.obj must be converted to be linkable with Main)

Why is the conversion neccessary?
OMF should be standard. However some linkers are too simple to support all OMF
features. They are not able to work with object files created by "other" compilers.
Second problem are the names of used / exported functions and variables. Different
name decoration tactics exist.
OMF2D tries to convert given object file in 32bit relocatable object module format
(32bit = containing Offset32 fixups for relevant segments only).

Where it may help:
*) Programmer's code needs to call functions contained within Functions.obj.
(Main00 ..MainXX written in Delphi; Functions.obj written in VC).
Posted on 2004-03-11 13:42:58 by n u M I T_o r
You may try this Coff2omf also. Unfortunately, couldnt find the doc with executable in my HD. So, only executable. I used to use successfully with masm obj files from libraries.
Posted on 2004-03-11 16:46:31 by cakmak
Cakmak,

Here is the documentation:

http://www.digitalmars.com/ctg/implib.html#coff2omf
Posted on 2004-03-12 01:08:25 by Vortex
n u M I T_o r

The only thing I'd like to say is Delphi eat my obj, converted with this tool, and don't even choke :)
I wish I knew it before, but the flipside is I learnt tasm a little :)

Thank you and, sure, ElicZ too!
Posted on 2004-03-12 03:57:48 by masquer