Borland turbo assembler download windows 10

Borland Turbo Assembler (TASM) Unofficial Changelist

The Rise of Turbo Assembler
Turbo Assembler, abbreviated TASM, was made by Borland International in 1988 to compete with Microsoft's Macro Assembler (MASM). TASM 1.0 was released 1 year after the highly successful introduction of their Turbo C compiler and associated integrated development environment (IDE) and about 6 months after Microsoft released MASM 5.1. One of the reasons TASM became popular was because it was bundled with Turbo C and later Borland C/C++ products.

Borland's compilers were more popular than Microsoft's equivalent compilers in the late 80s and early 90s, especially to the hobbyist developers that could not afford Microsoft's hefty price tag. Borland products quickly received a reputation for development tools that were cheaper, faster and more efficient than Microsoft's as well as other competitors. However, their success was driven largely due to Borland's products being bundled with an IDE: something the world was ready for and computers at the time were just becoming powerful enough to run. The IDE allowed editing of source code, compiling, linking, debugging and well as organizing the project/build settings (command line options), all without leaving the program's environment. Microsoft's compilers, like most of the compilers of the day, consisted of diverse command line tools. Editing source code, building and debugging was left to different tools that had to be invoked separately. To have one program house all the tools (or at least automatically invoke the appropriate tool when needed) proved to be an instant success.

Although Turbo Assembler never had its own IDE (nor did MASM), TASM 1.0 dealt a large blow to MASM with the introduction of "IDEAL" Mode. IDEAL mode was designed to compensate for the shortcomings of MASM, specifically the syntax used in MASM 5.x. If you didn't need or want the alternative IDEAL mode syntax, and had only MASM code, TASM was guaranteed to assemble the past 3 versions of MASM's code (4.0, 5.0, 5.1) without any (or few) modifications. MASM was described as a "complicated beast" to deal with due to the problems with data type handling and its numerous ad-hoc assembler directives. In comparison with MASM, TASM's IDEAL mode simplified the source code, had stricter type-checking and introduced better structured data handling. By version 3.0, the VERSION directive was introduced to make TASM even more compatible with specific versions of MASM as well as older versions of Turbo Assembler. It was with this feature that TASM was well known for being "more MASM-compatible than MASM itself". TASM's emergence onto the market was likely the single most-important motivation for Microsoft to fix their outdated MASM syntax.

One other feature-set unique to TASM is its object-oriented capabilities added in version 3.0. MASM never added object-oriented capabilities. My guess is that Microsoft might not have believed there were enough assembly-language programmers that cared about an object-oriented assembler.

The Decline of Turbo Assembler
Despite early success, popularity for TASM waned in the mid to late 90s largely because developers had begun to shift away from assembler programming in general, utilizing easier and quicker programming languages that hid the sometimes "ugly" details of coding directly to specific processors. However, it is my opinion that popularity specifically for TASM (over MASM) declined for two reasons:

1. TASM never fully supported the MASM 6.x Syntax:
   
   TASM entered the market supporting all of MASM's syntaxes and strange behaviors (known by TASM as "QUIRKS"). To offer developers the no-risk option to switch to a cheaper and faster assembler without having to change their source code was huge. Prior to MASM 6.0, TASM was clearly superior not only in speed, but in syntax and affordability. Borland included some rather humorous remarks in the TASM User's Guides regarding MASM, especially in the explanation for features such as "QUIRKS mode" and the "NOSMART" directive to enable building questionable MASM source files:
   
   
   If you are having trouble assembling a program with Turbo Assembler, you might try using the QUIRKS directive (which enables potentially troublesome features of MASM)
   ...
   For maximum compatibility with MASM, you should use the NOSMART directive along with QUIRKS mode.
   
   With all of MASM's problems, Microsoft eventually did deliver a better assembler in version 6.0. This was about 2 months after the release of TASM version 2.5. In reality, the combined MASM 6.0 and 6.1 releases finally brought MASM up to the level TASM has been at for years as it addressed all the problems that TASM's IDEAL mode had "fixed". Many people had the opinion that MASM was finally equivalent to TASM, give or take some modifications to the to syntaxes. And, 4 years later with the release of 6.11d (MASM's last DOS assembler), the MASM 6.x series had stabilized into a rock-solid assembler that was faster with a more elegant syntax. TASM still did not support any of its new syntax.
   
   Borland may have felt that because their assembler had been superior in the past, there was nothing left for them to prove; or perhaps they wanted to stop trying to be like MASM? Whatever they were thinking, something changed their mind. Nearly 5 years later with the release of TASM 5.0, the MASM 6.x syntax was finally supported. But, because TASM's implementation of the syntax never approached the near-100% compatibility they had become famous for in the past, this feature may have been too little, too late. MASM compatibility remained for the pre-6.x syntaxes, but those were becoming obsolete.
   
   MASM compatibility was important for TASM because Microsoft had an advantage over its competitors. Microsoft made the operating systems everyone was developing applications for. Anything Microsoft released (whether copied from competitors, or bought from them) would be considered "standard" by a large portion of the market. People would want to learn and develop in Microsoft's standard syntax simply because it came from Microsoft. To underestimate the importance of supporting MASM syntax to its fullest was a mistake on Borland's part.
2. Borland's Employee Mass-Exodus:
   Within months after releasing the TASM 5.0r patch, Borland filed a lawsuit against Microsoft for "systematically recruiting Borland developers in an attempt to eliminate the company as a competitor" as quoted from the May 12, 1997 Network World article (below). According to the complaint, Microsoft's recruiting efforts began back in 1994. A ComputerWorld article (below) quoted Borland CEO, Delbert Yocam as saying, "...Microsoft lured away Borland employees with hefty signing bonuses, and recruited them by sending limousines to Borland headquarters and taking them out to lunch." This was likely the fatal blow from which Borland would never recover. You could almost speculate that Borland lost the developer(s) who maintained TASM to Microsoft, just as Borland's Chief Engineer, Anders_Hejlsberg (inventor of Turbo Pascal and chief architect for Delphi) also defected to Microsoft in 1996.
   
   

   Article: Borland fights big brain suck NetworkWorld - May 12, 1997

   Article: Borland says Microsoft raided staff ComputerWorld - May 12, 1997

   
   In all fairness, I'll mention that prior to Microsoft hiring all of Borland's employees, Borland did indeed hire an ex-Microsoft Languages manager, Rob Dickerson, in 1988. Microsoft attempted, but failed to enforce their non-complete policy in court and both sides settled out of court with Dickerson ultimately being able to work for Borland. The article goes on to say, "As part of the settlement, both companies agreed they will not hire an employee from each other for the next six months." Microsoft gave Borland about 6 years before it began hiring its employees away.
   
   

   Article: Microsoft-Borland scuffle could open exit door ComputerWorld - Jan 11, 1988

   
   Although Borland may have drawn first-blood by hiring a manager that quit Microsoft, it is quite a different thing to have Microsoft systematically "gut" all of Borland's employees. This is one example of many anti-competitive practices Microsoft was involved with, eventually catching the attention of the US Department of Justice.
   
   

   Article: Justice Department versus Microsoft NetworkWorld - May 25, 1998

Although TASM 5.0 now supported some of the high-level language features present in the MASM 6.1 syntax, the changes needed to assemble a MASM 6.x source file with TASM 5.0 were slightly more involved than people were interested in performing. That didn't mean TASM 5.0 was necessarily a "dud", but many expressed disappointment. Tomcat's Win32Asm Document said the following:


Also around this time, Borland seemed to be going through an identity crisis. It decided to move away from low-level development tools (including TASM and Borland C++), shifting focus to what it referred to as "Enterprise" applications. This seemed to translate to database technology combined with rapid application development (WYSIWYG) tools. This was around the time C++Builder was born from Delphi. At least the database focus would seem to place Borland in a good position to aid the larger businesses that were forced to upgrade their "ancient" database technology in response to imminent Y2K problems. Perhaps even more importantly, "Enterprise" level databases were not already a market dominated by Microsoft.

As part of the new company focus, Borland changed its name to Inprise on April 29, 1998. As the company's CEO Delbert Yocam explained, the new name meant “invoking the enterprise”. Apparently the enterprise had not been “invoked” enough, as the name was changed back to Borland less than 3 years later in January of 2001.

About one year earlier (approximately February 2000), things may have started looking up to the Borland/Inprise employees as C++Builder 5 was released with some embedded anti-Microsoft easter-eggs. One might gather from looking at the images that they were not only fighting a war with Microsoft, but they were also winning thanks to a creature known as "Borzilla" representing Borland/Inprise. The employees were obviously fans of the vintage arcade classic "Rampage" where you control Godzilla-looking creatures to destroy cities. The most notable images are the Linux & Borzilla vs. Seattle (where Microsoft is located) and Borzilla eating Bill Gates. The remainder of the images and easter-egg details can be found in the TASM 5.3 section.


After years of obvious struggling, Borland's development tools division (named CodeGear at the time) was sold off to Embarcadero Technologies on May 7, 2008 shortly before Borland was acquired by Micro Focus on May 6, 2009.

As for the future of TASM, 5.0 was the last version distributed as a stand-alone retail product. Shortly after, the 5.0r patch was released to make TASM compatible with C++Builder. The future for TASM32.EXE would be to stick it in a "bin" directory with a plethora of other command line tools bundled in the C++Builder Professional (and greater) editions. TASM 5.2b was bundled with C++Builder 3 just before Borland changed its name to Inprise. 5.2b finalized the the MMX instruction set, added some Pentium Pro support and fixed some bugs. TASM 5.2 would be released 1 year later with C++Builder 4, adding the remainder of the Pentium Pro instructions and marking the last version of TASM with new features. TASM 5.3 was bundled with C++Builder 5 and fixed a few more bugs likely marking the last version of TASM with any changes. Beyond this, Turbo Assembler was essentially a defunct product. In 2006, C++Builder and Delphi were merged into the same development environment called Borland Developer Studio (later renamed to RAD Studio around the time Borland sold its CodeGear tools division to Embarcadero). All of these development environments, including the free trial versions, bundle a copy of TASM 5.4 which seemed to only have name and version number changes.

The lack of keeping TASM current sent a clear message to the developer community that TASM was no longer a product being actively maintained and developed. Despite this, many stuck with TASM well into the turn of the century. But, with Microsoft supplying MASM for free with every version of Visual C++ released starting with the 6.0 Processor Pack, there became little reason not to use the actively developed and supported MASM with the latest processor support. If you don't require support for Ideal Mode, the assembler development community seems to recommend MASM the most as it supports all current instruction sets and its still being maintained by Microsoft. Even the most die hard TASM developers eventually switched to MASM or another assembler that was being actively maintained.

Despite TASM not keeping up with the times, there does appear to be a maintained list list of open/closed bugs that can be viewed on Embarcadero's QualityCentral site. Unfortunately, (as of 2015) these only include two SSE feature requests, one for SSE (released by Intel for the Pentium III in 1999) and SSE3 (released by Intel in 2004) which have yet to be implemented. The other open bug is in regards to a nested structure's member names clashing with the names of the structures themselves. As you can tell, not a whole lot of activity going on here.

Other Compatible Assemblers
It appears that there is only one true Turbo Assembler clone - a free product named Lazy Assembler (LZASM). Lazy Assembler also supports instruction sets never available with TASM: SSE, SSE2, SSE3 (PNI), SSE4 (MNI), and 3DNow! Pro. The last version came out in 2007 and the original website is gone. The project appears to be dead.

In 1999 Paradigm Systems released Paradigm Assembler (PASM), known by many as a Turbo Assembler clone based upon Borland's version 5.0. According to a 2010 blog on MASM Forum, Paradigm Systems licensed Turbo Assembler 5.0 from Borland/Inprise and bundled it with the Paradigm C++ product. PASM was reverse-engineered just enough to reveal it was nothing more than a loader with TASM32.EXE embedded. Upon execution, it was claimed that it would extract TASM32.EXE to a temporary directory and execute it to perform the actual assembler work.

I have been able to verify this claim: PASM32.EXE first calls a function within their own ADMIN.DLL (as all of their utilities do) to ensure Paradigm's proprietary dongle exists; upon success a file named PASM32.DLL is extracted (with system and hidden attributes applied); PASM32.DLL, not really a DLL but internally an EXE, is then launched to do the assembler work, and then the file is deleted. This PASM32.DLL is actually the TASM32.EXE claimed (albeit modified). At the very least, the string literals have been changed to "Paradigm Assembler", however like TASM32, the TURBOASSEMBLER constant continues to exist in the module's DATA segment. The file weighs in at 178k which is less than TASM 5.0 and 5.0r (at 180k and 184k respectively), so Paradigm likely received from Borland a full build environment from which to fully tailor the TASM codebase to suit their purpose. Had Paradigm actually authored the assembler, it is likely the dongle protection would have been built directly into the EXE rather than the roundabout method they employed to extract the real tool.

It should come as no surprise that the Paradigm Assembler manual is close to an exact copy of the Borland Turbo Assembler 5.0 User's Guide, literally word-for-word with minor modifications. The only differences appear to be that they replaced all occurrences of "Turbo Assembler" with "Paradigm Assembler", "Borland C++" with "Paradigm C++", swapped out the sample in chapter #1 with their own and removed the introduction at the front of the book. Because no good quality digital reproduction of the official Turbo Assembler 5.0 User's Guide was available at the time, the Paradigm Assembler PDF manual, known for its small size and searchability became distributed among the Internet for TASM developers and can still be found on various sites today. The easiest place to find it is on the Phat Code website; either from their Lazy Assembler page or embedded within the TASM 5.0 download on its Turbo Assembler 5 page. A "clone" in the context of computer software generally means a different program that acts like or emulates the behavior of another to a high degree. Paradigm Assembler is not a TASM clone because it internally uses TASM and is therefore not a different program. All of this might lead one to believe Paradigm C++ might also be a licensed copy/modification of Borland's C++.

As a side-note, a complete and fully searchable PDF copy of the official Turbo Assembler 5.0 User's Guide is now available on archive.org (about 14MB), courtesy of the bitsavers.org scan collection.

Although not a clone, the free and actively maintained Netwide Assembler (NASM) for 16/32/64-bit development supporting Windows, Unix/Linux, and even DOS and OS/2 has the -t command-line option for "TASM Compatibility Mode". It is described in the NASM Documentation as:

• local labels may be prefixed with @@ instead of .
• size override is supported within brackets. In TASM compatible mode, a size override inside square brackets changes the size of the operand, and not the address type of the operand as it does in NASM syntax. E.g. mov eax,[DWORD val] is valid syntax in TASM compatibility mode. Note that you lose the ability to override the default address type for the instruction.
• unprefixed forms of some directives supported (arg, elif, else, endif, if, ifdef, ifdifi, ifndef, include, local)

Turbo Assembler Printed Manuals
With each new version, the Turbo Assembler official documentation provided less and less information. This trend was similar with MASM. It was almost as if as the product matured, the new features were added on an ad-hoc basis known to the large companies in the industry (such as low level hardware, chip and BIOS manufacturers) that may have requested the "features", but time and resources in properly documenting this information to the public was not devoted. It is likely that an assembler being such a low-level "backend" tool just didn't have the public visibility to justify the means. Observe the declining number of pages in the TASM printed manuals throughout the years, even as each new version had more features than the previous one:


Therefore, the purpose of this page is to document what changed between each version even as official information became more and more limited. Before changes stopped being documented altogether in the post-Borland years, the Turbo Assembler manuals usually just added a chapter or section explaining the new features but didn't mention that the feature(s) were "new". Starting with the 3.0 User's Guide, an appendix was added at the end with keywords new to each version up to the current manual's version. As I leveraged this information as part of building the changelist information, I found that Borland was extremely sloppy in preparing these lists. If you have access to one of these manuals and you compare it to the changelist information compiled on this site, you'll find the information in the manuals grossly underestimated what was actually added to each version! Not only were the lists incomplete with every version, many keywords were incorrectly placed and some of the keywords were flat out wrong, either because no such keyword actually existed or a couple instances where multiple keywords were "glued" together as one keyword! No only that, but many "new" keywords in these lists were never described in the manual! It was also sad to note that the last User's Guide (version 5.0) was missing updated information for 32-bit Windows application development.

An Official Yet Unofficial IDE
Many may be surprised to learn that the version 7 Turbo Pascal and Borland Pascal IDE's, possibly the Borland C++ IDE too, had such a surprising level of TASM integration, some may have considered them the unofficial IDE for TASM. Unofficial because a program's entry point still required a language other than assembly. Beyond simply spawning TASM during the build process, these IDE's included some valuable source and debugging features. For example, when TASM reports build errors, the IDE positions the cursor at the first error line in the source code, with the option to visit all lines containing errors. When single-step debugging finds its way into a linked TASM module, the corresponding .ASM source appears and current assembly line hilighted. Assembly-level debugging features included tracing, setting breakpoints (both absolute and conditional), variable watch, register inspection, and even spawning TASM to re-assemble during debugging (if the source was changed).

Courtesy Jim from oldskool.org for this section's information and screenshots below:

Pascal program loading external OBJ (note the $L directive)

In-line assembler, single-stepping up to external object call

During Trace, IDE loads TASM source

Turbo Assembler books
Besides the official Borland manuals, there were not as many books dedicated to TASM. Books dedicated to MASM however were more plentiful. Most of the these TASM books were written pre-version 3.0 and even then there were only a handful. The Turbo Assembler Bible was one of them, designed for TASM 2.0. Because a lot has changed since TASM 2.0 (and other assemblers since the TASM 2.0 release in 1990) it is considered primitive even for 16-bit programming. This combined with the fact that the bulk of the book is reference material that can be found elsewhere, this book's primary significance is historical (and it has a neat pirate picture on the cover!).

Although these pre-version 3.0 books may delve a bit into TASM's IDEAL mode syntax, they didn't cover the object-oriented features unique to TASM that were added in version 3.0. But, there was one book that came out in 1989 followed by a second (and final) edition published 1995 that will forever be known as the definitive guide to TASM. Although it only covers through version 4.0, the book, "Mastering Turbo Assembler" delves into just about every TASM detail known. This book was written by Tom Swan, one of the best computer book authors of the 80s-early 90s computer era (also the author of the widely successful and definitive "Masting Turbo Pascal x.x" series). The assembler code shown in the book was almost exclusively in IDEAL mode and it is one of the only books that covers the object oriented features of TASM. In fact, this tome of 908 pages is a better reference than the official Borland manuals themselves, especially since Swan leveraged the assistance of Borland employees to write the book! Although the 2nd edition only covered TASM through version 4.0, the TASM 5.x changes that came after it was published only made TASM more MASM-compatible which wouldn't have been covered by this book anyway. Therefore, this book continues to be relevant to the TASM distributed by Embarcadero today.


The only other book I know of that deals with the features of modern (post-3.0) TASM is "Windows Assembly Language and Systems Programming" 2nd edition by Barry Kauler. While this book goes into details about the differences between MASM and TASM, Kauler prefers TASM over MASM and therefore most of the code in the book follows suit. Kauler also devotes an entire chapter (about 42 pages) delving into the object-oriented nature of programming in assembly language which you really won't find in any other book. Most books (typically in the field of reverse engineering) will discuss how certain snippets of object-oriented C++ code disassembles into corresponding assembly language, but Kauler illustrates a unique view. He shows how one might use an object oriented assembler like TASM to implement objects in a pure assembly language without any constraints that would be placed upon a compiler (such where the VTABLE might go: common to the class or per object instance). Although he does use TASM-specific keywords such as the TABLE directive, his code for the most part is fairly generic assembler that could be easily ported to MASM or other assemblers. Besides the TASM specifics, I highly recommend this book despite the large focus on 16-bit Windows 3.1 and Windows 95 programming. There is little doubt that 16-bit programming is dead in the world, but I think it would do any serious assembly language programmer some good to have general knowledge of the convoluted nature of 16-bit hardware implementation. 16-bit x86 programming, a scheme born out of limited resources and backwards compatibility is harder than 32-bit programming and takes some serious skill to master. 16-bit code is not completely gone as it is still used in BIOS and low level processes such as bootloaders. This is true even on PCs that will ultimately boot a 32-bit or even 64-bit protected mode operating system. In my opinion, this book gave the clearest and most detailed explanation of what is really going on with the processor and memory from when you hit the power switch, to when DOS loads (Pre Windows 2000/XP that is), to when Windows loads, the different processor modes (real mode, virtual 86 mode, protected mode), what descriptors are and their layouts, as well as how segments address memory with 20-bits, etc. For those that use the 32-bit FLAT model for assembly language programs, there are 16-bit artifacts in that architecture and its good to know these roots! Additionally, this is also one of the only books I know of that explains the inner workings of how you can drop from user mode (ring 3) in a protected mode program down to kernel mode (ring 0) using call-gates.

Windows Assembly Language and Systems Programming 16- and 32-Bit Low-Level Programming for the PC and Windows (2nd Edition) © 1997, Barry Kauler / 419 Pages

The books described above (as well as the Turbo Assembler software itself) are unofficially classified by the world as obsolete software for obsolete operating systems with no economic value. Soon, they may be sought-after vintage collectibles, but not while there are such large numbers remaining in circulation. I say grab them while you can off of Amazon or eBay for pennies on the dollar because these books are generally cheaper than the cost to ship them. If you don't mind paying a little more, you can usually get them in near-mint condition!

Turbo Assembler Versioning
It is interesting to note that embedded within the binary executable of each version of TASM is the following string: ??version equ xx*256+yy This appears to be the internal definition for TASM's ??version macro, utilizing internal major and minor version numbers xx and yy respectively. This formula stores the major version in the upper byte and the minor version in the lower byte of what was likely intended as a 16-bit version number. This explains why the reported ??version numbers (shown in the table below) are generally large powers of two.

I have attempted obtain the most complete version information for Borland's TASM throughout its history using official information where available and falling back to bits and pieces from other sources when information is limited. This includes printed manuals, readme's and other information shipping with the product, or official websites. When appropriate, opinions and hearsay are also included (and noted as such), as this helps develop a clearer picture of how the product impacted those who used it.

Changelist for this document

Jump to TASM Version Info / 20 Versions Listed

Jump to Keyword Version Info