Can anyone offer any advice on why 'tasm32.exe' would crash?  I have been using it for yrs. with no problems.
I added some more code to a .asm file Mon. and when I went to build my executable, it crashed and WinXP
told me the problem was 'tasm32.exe'.  I tried it several times - same thing.  I found my 3 installation diskettes,
dusted them off, and reinstalled the complete pgm.  I had to search, but finally found the v5.0 patch and ran it.
Tried to assemble my pgm again and same error.
Posted on 2005-08-24 10:10:23 by DaveTX47
Hello DaveTX47,

I quit using tasm a few years ago when I switched to masm so I don't have a lot of to say.  Only thing I can suggest is you try to change the compatibility mode.  If that doesn't work get in touch with someone at Borland :(
best regards,

Posted on 2005-08-24 11:10:34 by czDrillard
TASM is faster that other assemblers... but this has a heavy price: less checking for errors.

It happened to me a few times, it is noting you can fix by reinstalling TASM. It is something in your source code :D
SOmething that does not generate an error (although it should) but instead crashes TASM.

I order of relevance (but i bet on structures) I would scan for:

1)Too many .IF .ENDIF .ELSEIF
-because TASM has a limit to its hash tables of approximative 32768 symbols or 9.999 automatic labels. When this is reached you have no option but to break the application into smaller modules.

2)Much to similar and long symbol names
- something like: "my_very_long_label_is_here" and "my_very_long_label_is_here2"

3)Include files
- with too big filenames or with spaces inside or with unicode caharacters
- include filenames too similar (see above)
- include files with manes similat to parent folder

Basically there is a include "hel"l in TASM.
You have to be very defensive about include filenames and parent folders :D and many levels of includes.
Become even paranoical because again there are some bugs in the hash tables for this.

-different structures with the same field names like

my_struc1 STRUC
dwSize dd ?
filename_lp dd ?

my_struc2 STRUC
dwSize dd ?
rva_base dd ?

Notice the two same name "dwSize" fields :D ? ... works for MASM and for TASM in IDEAL mode
but DOES NOT work for TASM in normal MASM "compatible mode".

Funny is that it crashes at a later time when you add some more symbols to the hash tables.
I would bet that this is your problem... maybe some include converted from MASM ?

- use TASM's STRUC and not MASM STRU or STRUCT ...

5) Other misc issues
- do not use names before ending ENDS and neither before ending ENDP
- do not use MASM procedure head:

instead of:

My_Proc PROC x1:DWORD USES eax, ebx
LOCAL dx_tmp:dword
My_Proc ENDP


My_Proc PROC
USES eax, ebx 
LOCAL dx_tmp:dword

USES must be the first line after procedure head not ARG or LOCAL

BTW there is a free clone of TASM  --> LzASM (lazy Assembler) that fixes many of those bugs but it works only in IDEAL mode ...
For a pro ther are workarrounds for those bugs and some advantages to benefit from by using TASM but honestly for a beginner it is probably better to use MASM ...  Otherwise you will have to learn and live with those bugs...

Or you can use MASM or FASM or GoASM or ... whatever you like to ... :)

Posted on 2005-08-24 14:53:43 by BogdanOntanu
Why use TASM if it is *that* bugged?

Christ, I knew about the semi-hard hash table limits (and commandline switches), but this sounds like TASM has some pretty severe bugs :|
Posted on 2005-08-24 15:40:49 by f0dder
i have one masm crash to share, try to put this somwhere in your code:

x struct z
x ends

its hardly anything significant since it first echoes the error but still it raises unhadled dbz exception...
Posted on 2005-08-24 19:44:18 by drizz
I appreciate the comments and advice. ?I went to the Borland website and I now have the problem resolved. ?Since I've been programming with TASM for a number of years, I'd rather continue using it even though I have written one pgm using MASM.
Thanx again,
Posted on 2005-08-24 19:46:43 by DaveTX47