Borland Turbo Assembler Version 5 User's Guide (1996) [pdf](bitsavers.informatik.uni-stuttgart.de)
bitsavers.informatik.uni-stuttgart.de
Borland Turbo Assembler Version 5 User's Guide (1996) [pdf]
http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_assembler/Turbo_Assembler_Version_5_Users_Guide.pdf
59 comments
I was 14 years old, only ever programmed in Commodore Basic by typing in programs from the manual (in German) without understanding them, didn't understood English much.
I got pirated Turbo Pascal 7 and Turbo Basic with included manuals and I've learned programming from them (in a foreign language, with no internet).
That's how good they were.
I got pirated Turbo Pascal 7 and Turbo Basic with included manuals and I've learned programming from them (in a foreign language, with no internet).
That's how good they were.
Similar story but I bought the original box of TP7 in 1993. The manuals structured in an exemplary way with so many technical details and even with part of the Turbo Vision source code. It made me a better programmer for sure. I even sent them a registration card. I still have the confirmation letter from my product registration giving me access to the support hotline and BBS.
I remember being maybe 13 years old or so and asking my parents for Turbo Pascal for Christmas haha. I think it was Turbo Pascal 3? I eventually upgraded to the nicer one with the windowed system. Good times!
I don't understand why the TUI of old text-mode IDE's (from Microsoft as well as Borland) has yet to be replicated in modern terminal environments. You can kinda get a menubar in Emacs but it's quite clunky, and grabbing mouse input in the terminal requires a separate incantation. And even Emacs doesn't allow for floating windows/dialogs, nor does it show text-mode scrollbars or windowing widgets.
You'd think that many devs would want something like this, to code via SSH while logged on a remote dev system, or perhaps from a mobile device app. Is it really that hard?
You'd think that many devs would want something like this, to code via SSH while logged on a remote dev system, or perhaps from a mobile device app. Is it really that hard?
There are some. One of my favourites is Terminal.Gui[0], but you have to be in the .NET world in order to use it.
[0] https://github.com/gui-cs/Terminal.Gui
[0] https://github.com/gui-cs/Terminal.Gui
Interestingly, menues and scrollbars are the first things I turn off on new Emacs installs.
The IBM PC text mode buffer was mapped into memory, so you could quickly update any part of the screen and easily do things like double-buffering (for rock-solid screen updates), composing the screen out of floating windows held in separate memory buffers, etc.
The Unix terminal is derived from line printers (teletype), a fundamentally different kind of TUI.
I don’t know how much this realistically affects today’s terminals since we have extremely fast connections. But it’s the original reason why those DOS text UIs had such a distinct snappy feel.
The Unix terminal is derived from line printers (teletype), a fundamentally different kind of TUI.
I don’t know how much this realistically affects today’s terminals since we have extremely fast connections. But it’s the original reason why those DOS text UIs had such a distinct snappy feel.
There are some *nix programs with complex TUI's, where a "snappy feel" is sought after (e.g. the `aptitude` TUI for package management in Debian and its derivatives) and they're just as snappy as any old DOS app. The overhead from using a terminal-based API is just too low to matter.
As it ought to be since the lowliest Raspberry Pi is tens of thousands of times faster than the IBM PC. Filling a screen shouldn’t be an issue regardless of the protocol in the middle.
But design decisions made in the 1980s still linger in a lot of Unix software.
But design decisions made in the 1980s still linger in a lot of Unix software.
Still, back on the Slackware 2.0 days there were plenty of TUI applications.
Here for the younger generations, https://en.wikipedia.org/wiki/Ncurses
Here for the younger generations, https://en.wikipedia.org/wiki/Ncurses
This is exactly correct.
As far as affecting the state of TUI/CLI programs today, it becomes part of the culture as well as part of the overall look and feel of the system.
Yet, there are programs that break from convention: JOE, Dit, irssi, etc.
As far as affecting the state of TUI/CLI programs today, it becomes part of the culture as well as part of the overall look and feel of the system.
Yet, there are programs that break from convention: JOE, Dit, irssi, etc.
I think it is partly fashion (little UI is more "hackerish" after all) and partly lack of exposure (a lot of programmers nowadays who have worked on TUI applications might have little to no exposure to DOS programs of yesteryear).
It is technically possible though, as an example here is Free Pascal's text-mode IDE[0] running inside an xterm window under Linux. The IDE uses Free Vision[1], a TUI framework originally based on Borland's Turbo Vision, that is nowadays part of Free Pascal itself (though the framework uses the TP7-style "object" types for OOP instead of the Delphi-style "class" types).
[0] https://i.imgur.com/QZWt9lC.png
[1] https://wiki.freepascal.org/Free_Vision
It is technically possible though, as an example here is Free Pascal's text-mode IDE[0] running inside an xterm window under Linux. The IDE uses Free Vision[1], a TUI framework originally based on Borland's Turbo Vision, that is nowadays part of Free Pascal itself (though the framework uses the TP7-style "object" types for OOP instead of the Delphi-style "class" types).
[0] https://i.imgur.com/QZWt9lC.png
[1] https://wiki.freepascal.org/Free_Vision
Yeah but FPIDE is the exception that proves the rule. Why can't we have a VSCode work-alike in text mode, with LSP, tree-sitter and DAP support? That stuff is even getting added to Emacs these days, so it has a proper free-software pedigree even though it comes from M$.
> And even Emacs doesn't allow for floating windows/dialogs, nor does it show text-mode scrollbars or windowing widgets.
However, the floating window had its downsides. They hid what was behind the window and modals, so if you started a dialog box and changed your mind about the text behind it, you have to close the dialog box, change the text and restart your dialog box.
Emacs and Vim avoid these problems by turning everything into a buffer. So all of your interactions with the editor are done through buffers which can be opened side by side.
However, the floating window had its downsides. They hid what was behind the window and modals, so if you started a dialog box and changed your mind about the text behind it, you have to close the dialog box, change the text and restart your dialog box.
Emacs and Vim avoid these problems by turning everything into a buffer. So all of your interactions with the editor are done through buffers which can be opened side by side.
There are attempts at similar things - https://www.willmcgugan.com/tag/textual/
Me too, like as it used to be in those days, we could get all kinds of software in Portuguese bazars at the cost of the material being copied.
However when I could afford the student editions of Borland products available to high school students, I bought TPW and Turbo C++ 3.1 for Windows, first TPW, and then TC++ an year later.
However when I could afford the student editions of Borland products available to high school students, I bought TPW and Turbo C++ 3.1 for Windows, first TPW, and then TC++ an year later.
I remember as a 17 year old spending 50 Irish pounds on a copy of Turbo Pascal and being giddy with excitement when the brightly colored box and manuals arrived. I pretty much memorized them, and of all the things from the late 80s its the one I wish I had kept!
>Most people think of assembly language as a low-level language. Turbo Assembler, however, provides many of the features of a high-level language (such as abstract data types, and easy interfacing to other languages). The addition of object-oriented data structures gives Turbo Assembler the power to create object-oriented programs as easily as high-level languages while retaining- the speed and flexibility of assembly language.
Shocking and surprising
Shocking and surprising
I remember coming across that - we mostly used MASM back in the day but when I found the object-oriented TASM stuff I was very tempted. Didn't really make a whole lot of sense since C++ is already pretty low-level, especially back in the 90s.
The other interesting Borland OO thing was the C++ language extension for OWL (Object Windows Library, an early C++ GUI lib for WIndows) to link windows messages to member functions. It was addictively productive, when we switched over to MFC later on it felt like a step back.
The other interesting Borland OO thing was the C++ language extension for OWL (Object Windows Library, an early C++ GUI lib for WIndows) to link windows messages to member functions. It was addictively productive, when we switched over to MFC later on it felt like a step back.
I wrote C code with dispatch tables to implement "virtual functions" for structs with method calls .. those were local to a dot-c file, with corresponding external dot-h interfaces defined.. all of that by my own design, for a framework for graphics programming .. in the early 90s. The techniques were known, just not common. Borland had great products, and was killed by "bloody means", by MSFT, in public view.
I actually found something similar in PIC micro controller assembly at uni. The way library loading worked allowed something very similar to object orientation in a super fast assembly language. My team wrote our 3rd year project in assembly and found that we experienced far fewer WTF moments and unexpected behaviours than all the other teams who chose to use C.
Similar to my uni project to make a concurrent server. Most people struggled to make it work with Java, and there were extra points for implementation of the project in C. So I did. Pthreads, zero deadlocks and zero memory leaks.
Borland C++ 3.1 was the epitome of documentation. The retail packaging was about the width of 7 pieces of big box software and it weighed quite a bit more from the "encyclopedia set" it included. The assembler quick reference guide for TASM was better in 3.1 than in either 4 or 5. It was also spiral bound with a white comb. Although updated with features, 4 and 5 reduced the amount of documentation significantly.
http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/tur...
Turbo C 2.0 user manual from the same site - it is just a gold mine.
Turbo C 2.0 user manual from the same site - it is just a gold mine.
I don't understand - the debugger in Turbo C was such a delight and inspecting structs, linked lists etc was so easy and somehow fit nicely on these old screens.
In VS today everything feels so cumbersome and convoluted I almost never bother witht the debugger, and instead just look at stack traces instead.
In VS today everything feels so cumbersome and convoluted I almost never bother witht the debugger, and instead just look at stack traces instead.
As Borland fanboy that used most of their products until early 2000's, and nowadays lives on VS, I fail to see what is actually missing.
Brings back fond memories. Used to use the "debug" program that came with DOS to play with assembly as a student, because TASM (Borland) and MASM (Microsoft) cost money, but doing that gave one a real feel for assembly. Coding a short JMP instruction, for example, requires a relative address from the current instruction PC, so you had to hand compute that and code it in. And if you added instructions between the JMP and the target, then you had to go back and change it.
Hopefully everyone's noticed there's a ton of Borland manuals at Bitsavers, not just TASM v5. You could probably even pick up the software itself if you wanted maybe off of archive.org?
[edit]..and run it on dosbox-x or 86box, of course.
[edit]..and run it on dosbox-x or 86box, of course.
Ah, I had TASM 5, boxed. Great memories. I actually remember reading the manual for fun. If I remember right there were two manuals in the box, this one and an assembly reference.
Scrolling through it just now, I now also remember "Ideal" mode, and how it was so much better than MASMs weird idiosyncrasies.
Scrolling through it just now, I now also remember "Ideal" mode, and how it was so much better than MASMs weird idiosyncrasies.
As a kid who was left alone with a computer for way too long back in the early 90s, I remember learning English from Civilopedia and playing around with Borland turbo pascal 7. TP manual had an example where they built polynomials using linked lists. That was the first time I realized that you could store pointers to other regions of memory which store pointers. Nobody around me had any clue why I was so happy.
In page 44 onwards, this describes how to do class-based OOP with assembly language extensions to generate vtable calls. I wonder who ever used that…
This helped to understand how OOP was working under the hood (I was a teen at that time)
This post brings me many memories from Turbo Vision, Borland Graphics Interface, a simple assembly language, the flat memory hack, Turbo Pascal with its super fast compile time...
This post brings me many memories from Turbo Vision, Borland Graphics Interface, a simple assembly language, the flat memory hack, Turbo Pascal with its super fast compile time...
We used it for the kicks at the Uni. Never got to try that in prod because frankly the next time it came to using assembler it was 15 years later (and on another arch).
When I was a teen, I used TA precisely because of oop support :) it was a bit cumberstone compared to higher level languages, but worked quite well for the kind of stuff I needed (mostly display-related and IO libraries)
OOP hype was peaking in the mid-90's when TASM 5 came out. Probably some manager's idea to capitalise on that.
Worth pointing out that in the late 80s-early 90s, Turbo C and Turbo Pascal, and maybe others, were also licensed and ported to the (M68K-based) Atari ST as “Pure C” and so forth - and worked just as well there, including some of the best online documentation of anything ever written for the platform
Erratum on the off chance anyone relevant is reading here: page i and ii (first two pages of the table of contents) are in the wrong order (swapped).
From the era when software development still had documentation, and technical writers.
Borland's manuals were fantastic in so many ways, from the typesetting to the organization of the chapters/books. They were, in comparison to many other manuals, both friendly and pragmatic. Look at the "Getting started" part of this manual. The marketing copy is top notch (referencing "hackers and wizards", "blindingly fast programs"), and then just one page later you're running your first program.
One of the formative experiences of my childhood was getting my hands on the Turbo Pascal 5.5 "Object-Oriented Programming Guide" (1989) [1] just before going on a ferry holiday to Germany. It was a relatively slim volume that was separate from the other manuals that came with TP. On that ferry trip I read the book cover to cover, and even started writing programs on paper, since I didn't have a computer with me.
I had learned procedural programming before then, and Pascal's OOP extensions just blew my mind at the time. Looking at the manual now, it's just really well written and laid out.
[1] http://www.bitsavers.org/pdf/borland/turbo_pascal/Turbo_Pasc...
One of the formative experiences of my childhood was getting my hands on the Turbo Pascal 5.5 "Object-Oriented Programming Guide" (1989) [1] just before going on a ferry holiday to Germany. It was a relatively slim volume that was separate from the other manuals that came with TP. On that ferry trip I read the book cover to cover, and even started writing programs on paper, since I didn't have a computer with me.
I had learned procedural programming before then, and Pascal's OOP extensions just blew my mind at the time. Looking at the manual now, it's just really well written and laid out.
[1] http://www.bitsavers.org/pdf/borland/turbo_pascal/Turbo_Pasc...
Sad to see how crappy today’s assembler documentation is in comparison (especially Apple)
My favourite Assembler, in those days I would imagine Assembly would be the way to keep coding going forward, how wrong I was.
A friend of mine used to be a big proponent of this. His theory being that sure, you need someone special to be very productive in assembly. But there's a billion of Chinese where the market is just opening up…
(So I guess it was a few assembly geniuses for your OS and productivity software and the rest of us mortals filling in with the less performant rest written in C++ or E or Blitz Basic something)
I discovered Randall Hyde's HLA (High Level Assembly) while in the university around 2005/2006:
https://www.plantation-productions.com/Webster/HighLevelAsm/...
and thought it would be awesome to use that for work. Imagine the power of assembly combined with readability/productivity like Pascal.
Well, I never use assembly professionally, and HLA itself isn't maintained anymore.
https://www.plantation-productions.com/Webster/HighLevelAsm/...
and thought it would be awesome to use that for work. Imagine the power of assembly combined with readability/productivity like Pascal.
Well, I never use assembly professionally, and HLA itself isn't maintained anymore.
MASM is still maintained, which is even more high level than TASM was.
But yeah, other than some weekend hacks not worth the trouble.
But yeah, other than some weekend hacks not worth the trouble.
I learned programming by reading Borland's manuals. I owe their writers a debt of gratitude.
My school teaches C++ on TC++ 3.1,
The syllabus for CS hasn't changed since about 20 years.
80586 Pentium is still cutting edge in there.
Is it in India?
I was buffled when I found a lot of recent Youtube videos teaching Turbo C. Then realized all of them were Indian and for Indian students.
Yeah, on one side we are trying to preach modern practices how to program in C++, and then we get these schools teaching pre-standard C++ for a dead OS.
I encountered this about 10 years ago here in the US. The course seemed to have become a kind of Kobayashi Maru - nobody else in my group ever even managed to get a working installation of the compiler, which we had to do in a Windows XP VM (there was some way of getting a license for a copy of XP but almost nobody in the class seemed to get it to work for some reason).
Personally I don't believe in the no-win situation
I still have the Turbo Debugger 2.0 manual in my bookshelf...
I still use Turbo Basic.
as was the speed of Turbo Pascal compilation and the elegance of their text mode windowing object system.
I remember scouring all the possible BBS dialup file servers to find a compiler for my first 8086 machine .. I knew there had to be something better than GW Basic .. I could not find a compiler for free, but did happen up on A86 assembler, so got an intro to how the machine really worked.
Was so happy when I could afford Turbo Pascal back in the day. best product ever.