Open Watcom C/C++ came to mind right away. It includes an IDE and a relatively recent C compiler that can still target 16-bit DOS.

GemCookie wrote on 2025-02-14, 17:12:

Open Watcom C/C++ came to mind right away. It includes an IDE and a relatively recent C compiler that can still target 16-bit DOS.

Yes, but I don't have time to learn how to use Turbo Vision (which I think is compatible with Open Watcom C/C++), as already I found a solution on how to generate useful Turbo C/C++ code from the original DOS Turbo Vision 2.o. Also, some very old open source DOS apps written for Borland's Turbo C/C++ compiler are mostly not compatible with Open Watcom C++ compiler.

I already noted, that I don't want to discuss now why I prefer to use Borland's C/C++ DOS compiler over Open Watcom C/C++ 😉

analog_programmer wrote on 2025-02-14, 15:11:

But the more complex the code for the projects become, the less productive it becomes to use this ancient DOS IDE. In DOS times I was into learning/experimenting with BASIC and Pascal, so in therms of usage this Borland Turbo C++ package is something new to me, that's why I have no idea what newer, compatible and working to replace it with.

There have certainly been a few decades of progress between Turbo C++ 3 and today's IDEs. Are there particular things you are missing?

For me, unless I'm in the mood for a retro environment, I don't really like being stuck with 80 columns, and I prefer to use GNU Emacs as my editor.

Modern source navigation tools would be nice, but I can often settle for grep in smaller, older projects.

Are there any options for more modern TC/C++ compatible DOS cross-compiler dev. environment (IDE+compiler+linker... etc) under Linux or for ones that will work under Windows (in Wine) or DOS (in DOSBox)?

I've done various things, and never settled on any particular scheme as the best:

I think one option I've used in the past is to run GNU Emacs on my Linux desktop, then have a dosbox.conf set up so that when I start DOSBox, it mounts the source directory, builds, and then if the build succeeded (IF ERRORLEVEL ...) it runs the program just built so I can test it. You could enhance this scheme a bit perhaps by having separate dosbox.conf files, or passing "-c" to DOSBox so you can tell it what command to run, so that build and run are separate steps. Perhaps you can get your IDE to bind those build and run steps to separate keys.

A big drawback of this scheme is you don't get compile errors appearing in your IDE where you could potentially jump directly to the problematic source line. A workaround for that might be to get your compiler to output a log file, or redirect its output, then "cat" that file after DOSBox exits. I never get around to trying to do these things to make my environment nicer though, because every time I have to Alt-Tab and search for the correct line number, it doesn't really take long enough to annoy me much.

A different scheme I've used is to use a Windows XP virtual machine and do all my work in that. It can run reasonable versions of GNU Emacs and other tools, and can also run DOS compilers, etc. in a window with no problems. If the program you're developing doesn't do any sort of hardware access, you can run that directly in the DOS prompt window, otherwise I suppose you need a Windows XP build of DOSBox.

Another option is running Borland C++ 4.0 or 4.5 in an XP virtual machine. Those versions no longer have DOS-based IDEs, but instead have 16-bit Windows ones that work okay in XP. Version 4.5 can still build for DOS; I think it might be the last version that could (the box for 5.0 says it targets DOS, but I think it's only because it includes a copy of 4.5?). They're still pretty ancient IDEs by modern standards though. I've been working on embedding XLISP-PLUS into Borland C++ 4.5 via is open plugin interface, and making it Emacs-like. I'm not sure if I'll ever get it to a point where it's all that nice though!

And then going back to older solutions, there are some newer DOS-based IDEs than Turbo C++ 3's:
- RHIDE and SET's Editor, two competing (related?) options which I think are both based on DJGPP; I assume that they could be configured to use Turbo C++'s compiler. I assume they shouldn't be too hard to find, but let me know if you can't find them.
- Aurora, which I think I used a little back in the mid '90s and I thought looked pretty cool, and I've started using again (and also trying to make Emacs-like!), but the biggest compliment it can be given is that Trixter - who was involved in e.g. the 8088 MPH demo - says it's "VERY Fast, configurable, functional. A winner in every single need and category."

Thank you very much for all the info and your suggestions, doshea! They may be useful to others too.

doshea wrote on 2025-02-16, 01:29:

There have certainly been a few decades of progress between Turbo C++ 3 and today's IDEs. Are there particular things you are missing?

For me, unless I'm in the mood for a retro environment, I don't really like being stuck with 80 columns, and I prefer to use GNU Emacs as my editor.

Modern source navigation tools would be nice, but I can often settle for grep in smaller, older projects.

For the last decade I use mostly Jetbrains IDE products, even though for me to write some code is only a hobby on a non-pro level. These modern all-in-one IDE solutions packed out-of-the-box with a bunch of extras seem to have spoiled me quite a bit.

What I miss most about this ancient Тurbo С++ 3 IDE is the quick shortcuts for switching between files in projects on mouse click, the quick hints when hovering over keywords, and the mouse scrolling. The text display mode is also inconvenient, but somehow acceptable for DOS. Manually starting a new COMMAND.COM DOS-shell every time, so I can execute the freshly compiled and linked code, thus not allowing the run-command-window to auto-close itself after the DOS app stops, is also very anti-productive.

At least Turbo C++ 3 IDE has right-click on a keyword as a quick reference to so-called "online help" (of course it's OFFline), but the navigation there (in this "online help") is terrible.

The closest thing to this primitive Turbo C++ IDE I also use is Code::Blocks IDE and still it's light years ahead of ancient Borland's DOS IDE 😀 Actually I like it for it's simplicity, but there's no way (or I don't know how) to set a cross-compiler for 16-bit DOS apps under Linux in it (I have settings for 32-bit Windows apps cross-compiling).

doshea wrote on 2025-02-16, 01:29:

I've done various things, and never settled on any particular scheme as the best:

I think one option I've used in the past is to run GNU Emacs on my Linux desktop, then have a dosbox.conf set up so that when I start DOSBox, it mounts the source directory, builds, and then if the build succeeded (IF ERRORLEVEL ...) it runs the program just built so I can test it. You could enhance this scheme a bit perhaps by having separate dosbox.conf files, or passing "-c" to DOSBox so you can tell it what command to run, so that build and run are separate steps. Perhaps you can get your IDE to bind those build and run steps to separate keys.

A big drawback of this scheme is you don't get compile errors appearing in your IDE where you could potentially jump directly to the problematic source line. A workaround for that might be to get your compiler to output a log file, or redirect its output, then "cat" that file after DOSBox exits. I never get around to trying to do these things to make my environment nicer though, because every time I have to Alt-Tab and search for the correct line number, it doesn't really take long enough to annoy me much.

Well, this surely is working approach, but I think, this scheme will help me only to use my preferred Linux code-editor, wile creating a different set of inconvenience (you've mentioned this). Still an option, tho' 😀

doshea wrote on 2025-02-16, 01:29:

A different scheme I've used is to use a Windows XP virtual machine and do all my work in that. It can run reasonable versions of GNU Emacs and other tools, and can also run DOS compilers, etc. in a window with no problems. If the program you're developing doesn't do any sort of hardware access, you can run that directly in the DOS prompt window, otherwise I suppose you need a Windows XP build of DOSBox.

This is also an option, good to know.

doshea wrote on 2025-02-16, 01:29:

Another option is running Borland C++ 4.0 or 4.5 in an XP virtual machine. Those versions no longer have DOS-based IDEs, but instead have 16-bit Windows ones that work okay in XP. Version 4.5 can still build for DOS; I think it might be the last version that could (the box for 5.0 says it targets DOS, but I think it's only because it includes a copy of 4.5?). They're still pretty ancient IDEs by modern standards though. I've been working on embedding XLISP-PLUS into Borland C++ 4.5 via is open plugin interface, and making it Emacs-like. I'm not sure if I'll ever get it to a point where it's all that nice though!

Thanks for pointing me to the last windows version of Borland C++ which can produce 16-bit DOS executable code, I didn't knew which version would be of use to me. I'll try Borland C++ 4.5 in 32-bit Wine.

doshea wrote on 2025-02-16, 01:29:

And then going back to older solutions, there are some newer DOS-based IDEs than Turbo C++ 3's:
- RHIDE and SET's Editor, two competing (related?) options which I think are both based on DJGPP; I assume that they could be configured to use Turbo C++'s compiler. I assume they shouldn't be too hard to find, but let me know if you can't find them.
- Aurora, which I think I used a little back in the mid '90s and I thought looked pretty cool, and I've started using again (and also trying to make Emacs-like!), but the biggest compliment it can be given is that Trixter - who was involved in e.g. the 8088 MPH demo - says it's "VERY Fast, configurable, functional. A winner in every single need and category."

This "RHIDE" name is somehow familiar to me, but I can't remember on what occasion I've met it. I found this link to SF, but don't know if this is exactly the same tool you've written for. And how to use DJGPP in Linux...?

Also found a SF link for SET's Editor, which is totally unknown to me.

It seems like this Aurora Editor is now given for free from it's creator, so I'll try it. Thank you for these DOS tools!

I'll start from this last suggestion, and if can not figure out something like more convenient dev. env., I'll go for the windows version of Borland C++ with some virtualization - Wine, QEMU or Virtual Box...

Once again, thanks for all the info and suggestions!

analog_programmer wrote on 2025-02-16, 22:50:

Thank you very much for all the info and your suggestions, doshea! They may be useful to others too.

No worries, I hope this information helps someone to be much more successful at completing a project than I am 😁

What I miss most about this ancient Тurbo С++ 3 IDE is the quick shortcuts for switching between files in projects on mouse click

I thought that Turbo C++'s project window would do this, but I see that it will always open a new editor window, even if you have one open for the file already 🙁 I guess that back in the day I was used to hitting F6 to cycle through windows and Alt-0 to get a list of windows and was never really bothered by this. Once you're used to some way of working, though, you certainly hope to get every other editor to work that way, hence my trying to turn everything into Emacs 😁

the quick hints when hovering over keywords

Yeah, I think that is definitely a more modern feature!

and the mouse scrolling.

Perhaps this can be achieved in DOS via some alternate drivers or add-on TSRs, although presumably they'd just turn mouse wheel actions into up and down arrow key presses, so it wouldn't be exactly the same.

Manually starting a new COMMAND.COM DOS-shell every time, so I can execute the freshly compiled and linked code, thus not allowing the run-command-window to auto-close itself after the DOS app stops, is also very anti-productive.

What about the Run menu - Ctrl-F9, etc. - and the Output window?

At least Turbo C++ 3 IDE has right-click on a keyword as a quick reference to so-called "online help" (of course it's OFFline), but the navigation there (in this "online help") is terrible.

Ahh yes, the navigation isn't very nice 🙁 It's more "online" than having to refer to a printed manual though, which I think you'd still need to do for some information like compiler options or information about memory models, and which was the only option available for some older compilers 😁

In case you're interested and not aware, here are some ways you can get access to relevant help outside the IDE:
- Turbo C++ 3 comes with a THELP.COM TSR you can run to get access to that help within any DOS program
- I'm pretty sure that there were third-party tools to decompile those help files. I can't remember what you could convert the decompiled source into other than recompiling it, but perhaps someone eventually made a way to turn it into something readable via some other software. If not perhaps I'll do it one day!
- Borland C++ 4.5 - which obviously has an expanded library and more compiler options - has standard Windows help files which can be decompiled to RTF, and also has the full manuals available in DynaText format, which I am able to convert into HTML using some work-in-progress tools. I hope one day to be able to generate that HTML in such a way that it works with a modern documentation browser like Zeal.

The closest thing to this primitive Turbo C++ IDE I also use is Code::Blocks IDE and still it's light years ahead of ancient Borland's DOS IDE 😀 Actually I like it for it's simplicity, but there's no way (or I don't know how) to set a cross-compiler for 16-bit DOS apps under Linux in it (I have settings for 32-bit Windows apps cross-compiling).

If you can tell it to run any command you want to do the compile - which I assume you can - then you should be able to tell it your compile command is something like:

dosbox -conf ~/Turbo_CPP_301/dosbox.conf -c "mount d $SOURCE_DIR$" -c c:\\tc\\bin\\make -c pause -c exit

assuming it has some way to specify a template where it will substitute in $SOURCE_DIR$, or if it will always run it with the current working directory set to the source directory, there would be some way to deal with that too. In this case ~/Turbo_CPP_301/dosbox.conf must have a "mount c ~/Turbo_CPP_301/drive_c" in its [autoexec] section or something.

There might be nicer options than using DOSBox for this, e.g. DOSemu and QEMU have ways to get console output to be written to standard output. Another option is having DOSBox run by a script which 'cat's some log file as I mentioned before.

This "RHIDE" name is somehow familiar to me, but I can't remember on what occasion I've met it. I found this link to SF, but don't know if this is exactly the same tool you've written for. And how to use DJGPP in Linux...?

Also found a SF link for SET's Editor, which is totally unknown to me.

I was just suggesting the DOS versions of those as probably a bit more advanced than the Turbo C++ IDE, so running those things under DOSBox or something. I think there could be a DJGPP cross-compiler for Linux, but that's definitely not what you want if you want to use the Turbo C++ compiler.

I don't remember the URLs I used to use for these, but https://setedit.sourceforge.net/ looks like an authentically old site, and spends time talking about the relationship to RHIDE, which I certainly remember reading about on the site previously. Sorry, I guess I got the name wrong - just SETEdit, not SET's Editor. That page says RHIDE adds "make facilities and interface to the debugger (gdb integrated inside)", so you probably want RHIDE, but it also says SETEdit has some extra features you could compile into RHIDE with some effort. It seems like RHIDE's site is down but you can view it here: https://web.archive.org/web/20220328223638/ht … /www.rhide.com/ Some RHIDE packages are available for download from the official DJGPP site: https://www.delorie.com/pub/djgpp/current/v2apps/

doshea wrote on 2025-02-17, 04:39:

No worries, I hope this information helps someone to be much more successful at completing a project than I am 😁

And now you're giving even more hints 😀 Thanks!

doshea wrote on 2025-02-17, 04:39:

I thought that Turbo C++'s project window would do this, but I see that it will always open a new editor window, even if you have one open for the file already 🙁 I guess that back in the day I was used to hitting F6 to cycle through windows and Alt-0 to get a list of windows and was never really bothered by this. Once you're used to some way of working, though, you certainly hope to get every other editor to work that way, hence my trying to turn everything into Emacs 😁

For example in M$-DOS 7.1 (not sure about 6.22) EDIT the "standard" keyboard shortcuts like Ctrl+C, Ctrl+X and Ctrl+V are usable, but in TC++ 3 the corresponding shortcut combinations are different: Ctrl+Ins, Shift+Del, Shift+Ins... and I still can't bring myself to use them.

doshea wrote on 2025-02-17, 04:39:

Perhaps this can be achieved in DOS via some alternate drivers or add-on TSRs, although presumably they'd just turn mouse wheel actions into up and down arrow key presses, so it wouldn't be exactly the same.

I don't know any stable DOS mouse driver with scroll-wheel support. The scroll-wheel was not a common part of the mice since the end of the '90s when the DOS was not already "a thing". Maybe CTMOUSE (CuteMouse) driver, but it sometimes causes problems. I think that the particular DOS application also have to support mouse scrolling and I have doubts that TC++ has it.

doshea wrote on 2025-02-17, 04:39:

What about the Run menu - Ctrl-F9, etc. - and the Output window?

Actually Ctrl+F9 is the problem (Menu "Run" - Run) 😀 That's why I use Menu "File" - DOS shell... type the executable name in command prompt.

doshea wrote on 2025-02-17, 04:39:

In case you're interested and not aware, here are some ways you can get access to relevant help outside the IDE: - Turbo C++ 3 c […]
Show full quote

In case you're interested and not aware, here are some ways you can get access to relevant help outside the IDE:
- Turbo C++ 3 comes with a THELP.COM TSR you can run to get access to that help within any DOS program
- I'm pretty sure that there were third-party tools to decompile those help files. I can't remember what you could convert the decompiled source into other than recompiling it, but perhaps someone eventually made a way to turn it into something readable via some other software. If not perhaps I'll do it one day!
- Borland C++ 4.5 - which obviously has an expanded library and more compiler options - has standard Windows help files which can be decompiled to RTF, and also has the full manuals available in DynaText format, which I am able to convert into HTML using some work-in-progress tools. I hope one day to be able to generate that HTML in such a way that it works with a modern documentation browser like Zeal.

Thank you, I didn't knew all that.

doshea wrote on 2025-02-17, 04:39:

If you can tell it to run any command you want to do the compile - which I assume you can - then you should be able to tell it y […]
Show full quote

If you can tell it to run any command you want to do the compile - which I assume you can - then you should be able to tell it your compile command is something like:

dosbox -conf ~/Turbo_CPP_301/dosbox.conf -c "mount d $SOURCE_DIR$" -c c:\\tc\\bin\\make -c pause -c exit

assuming it has some way to specify a template where it will substitute in $SOURCE_DIR$, or if it will always run it with the current working directory set to the source directory, there would be some way to deal with that too. In this case ~/Turbo_CPP_301/dosbox.conf must have a "mount c ~/Turbo_CPP_301/drive_c" in its [autoexec] section or something.

There might be nicer options than using DOSBox for this, e.g. DOSemu and QEMU have ways to get console output to be written to standard output. Another option is having DOSBox run by a script which 'cat's some log file as I mentioned before.

Yep, this will be useful in a case when Linux editor is used for writing the code and DOSBox - for DOS compiler. Nice hints.

doshea wrote on 2025-02-17, 04:39:

I was just suggesting the DOS versions of those as probably a bit more advanced than the Turbo C++ IDE, so running those things under DOSBox or something. I think there could be a DJGPP cross-compiler for Linux, but that's definitely not what you want if you want to use the Turbo C++ compiler.

I can set Code::Blocks IDE to use Open Watcom C/C++ compiler in Linux, but this will be useless for old Borland's Turbo Vision code. I just found a pre-build DJGPP executable for 64-bit Linux on github and I'll try it with C::B just for the experiment.

doshea wrote on 2025-02-17, 04:39:

I don't remember the URLs I used to use for these, but https://setedit.sourceforge.net/ looks like an authentically old site, and spends time talking about the relationship to RHIDE, which I certainly remember reading about on the site previously. Sorry, I guess I got the name wrong - just SETEdit, not SET's Editor. That page says RHIDE adds "make facilities and interface to the debugger (gdb integrated inside)", so you probably want RHIDE, but it also says SETEdit has some extra features you could compile into RHIDE with some effort. It seems like RHIDE's site is down but you can view it here: https://web.archive.org/web/20220328223638/ht … /www.rhide.com/ Some RHIDE packages are available for download from the official DJGPP site: https://www.delorie.com/pub/djgpp/current/v2apps/

I think I'll start here, replacing DOS TC++ editor. And I'll have to read and learn about TC++ compiler flags.

P.S. You've noted DOS memory models. It's a different huge topic. But for DOS-programming starters, I think this is a good brief explanation (I was also not familiar with DOS memory models differences): https://blogsystem5.substack.com/p/dos-memory-models

In TC++ 3 IDE I tried to build some small 16-bit DOS apps using "tiny" memory model with the idea to convert the EXE-executables to COM-executables, thus reducing a bit their size (it's funny nowadays - a matter of a few kilobytes spared) and no matter what other compiler and linker settings I changed, I always got a linker warning "No stack"... That's why I searched for different DOS memory models information. And finally I also found an explanation in TC++ 3 "online help" - it's a standard linker warning when "tiny" DOS memory model is set in "code generation" TC++ compiler settings.

analog_programmer wrote on 2025-02-17, 14:56:

For example in M$-DOS 7.1 (not sure about 6.22) EDIT the "standard" keyboard shortcuts like Ctrl+C, Ctrl+X and Ctrl+V are usable, but in TC++ 3 the corresponding shortcut combinations are different: Ctrl+Ins, Shift+Del, Shift+Ins... and I still can't bring myself to use them.

I guess I learned those shortcuts first, from QuickBASIC 4.5, and last I checked they still work in Windows, so I probably still use them sometimes, and Ctrl-C and Ctrl-X have the problem for me that they're the start of many Emacs key sequences 😁

This particular problem should be fixable for you in TC++ 3. From DOC\DOSEDIT.TEM, which is unfortunately not actually what you want:

1         MS-DOS 5.0 Editor emulation for the Borland C++ IDE.
2
3	This file contains a Turbo Editor Macro Language (TEML)
4script which emulates the MS-DOS Editor in the Borland C++ IDE.
5A complete description of the TEML language and the Turbo
6Editor Macro Compiler (TEMC) can be found in the file "UTIL.DOC".

If you look further through the file though, it appears to not support copy and paste at all! Since the MS-DOS 5 Editor is based on QBasic, it actually has the shortcuts I'm used to (Ctrl-Ins, etc.), but not the ones you are, and yet this .TEM file doesn't seem to support them.

Some of the other *.TEM files in that directory support copy and paste though, so obviously that key binding language supports it, and if you wanted, you could make your own key bindings and install them. You'd need to read UTIL.DOC to understand how to do that. I've done something similar with Borland C++ 4.5's Windows IDE. Probably the language for defining the key bindings was similar but they were installed differently I think.

I think that the particular DOS application also have to support mouse scrolling and I have doubts that TC++ has it.

That's why I was hoping something like MOUSKEYS from https://bretjohnson.us/, which lets you convert button presses into keys, might help, but that specific TSR doesn't have any scroll wheel handling it appears.

doshea wrote on 2025-02-17, 04:39:

What about the Run menu - Ctrl-F9, etc. - and the Output window?

Actually Ctrl+F9 is the problem (Menu "Run" - Run) 😀 That's why I use Menu "File" - DOS shell... type the executable name in command prompt.

Just curious, why doesn't it work for your case?

doshea wrote on 2025-02-18, 08:02:

This particular problem should be fixable for you in TC++ 3. From DOC\DOSEDIT.TEM, which is unfortunately not actually what you […]
Show full quote

This particular problem should be fixable for you in TC++ 3. From DOC\DOSEDIT.TEM, which is unfortunately not actually what you want:

Copy code to clipboard

1         MS-DOS 5.0 Editor emulation for the Borland C++ IDE.
2
3	This file contains a Turbo Editor Macro Language (TEML)
4script which emulates the MS-DOS Editor in the Borland C++ IDE.
5A complete description of the TEML language and the Turbo
6Editor Macro Compiler (TEMC) can be found in the file "UTIL.DOC".

If you look further through the file though, it appears to not support copy and paste at all! Since the MS-DOS 5 Editor is based on QBasic, it actually has the shortcuts I'm used to (Ctrl-Ins, etc.), but not the ones you are, and yet this .TEM file doesn't seem to support them.

Some of the other *.TEM files in that directory support copy and paste though, so obviously that key binding language supports it, and if you wanted, you could make your own key bindings and install them. You'd need to read UTIL.DOC to understand how to do that. I've done something similar with Borland C++ 4.5's Windows IDE. Probably the language for defining the key bindings was similar but they were installed differently I think.

I found three (EDIT: my miss(take)) four .TEM files (and UTIL.DOC text file) in TC++ 3 "DOC" folder, but I don't see any key bindings for "copy", "cut" or "paste" which can be redefined in them.

doshea wrote on 2025-02-18, 08:02:

analog_programmer wrote on 2025-02-17, 14:56:

doshea wrote on 2025-02-17, 04:39:

What about the Run menu - Ctrl-F9, etc. - and the Output window?

Actually Ctrl+F9 is the problem (Menu "Run" - Run) 😀 That's why I use Menu "File" - DOS shell... type the executable name in command prompt.

Just curious, why doesn't it work for your case?

It works. But not in the way I like 😀 After the successful execution of the tested executable the command shell "window" auto-closes immediately.

I wrote one self-deleting app in addition to some lame DOS-installer creator software (recently I've tested more than 20 different DOS-installer creator solutions and all of them are lame, so maybe I have to write a new descent one from scratch), which can execute some console command upon finish, but lacks the ability to modify configuration AUTOEXEC.BAT file. My self-deleting additional console app is for a specific custom DOS driver install pack (created with this lame DOS-installer software) and throws some messages at console while adding new lines to AUTOEXEC.BAT file. It was not convenient for me to use self-closing command "window" (Menu "Run" - Run or Ctrl+F9 shotcut) while I tested it in TC++ IDE. For example in Code::Blocks IDE the console window always stays "on pause" when execution of tested console app is completed.

analog_programmer wrote on 2025-02-18, 08:57:

I found three .TEM files (and UTIL.DOC text file) in TC++ 3 "DOC" folder, but I don't see any key bindings for "copy", "cut" or "paste" which can be redefined in them.

It looks like I have version 3.00, perhaps they *removed* some files in 3.01? I have 5, although CMACROS.TEM is for extra key bindings like inserting function skeletons,

BRIEF.TEM
CMACROS.TEM
DEFAULTS.TEM
DOSEDIT.TEM
EPSILON.TEM

The last of those files is for an Emacs-like editor. Emacs's paste-like operation is called "yank", and EPSILON.TEM includes:

1macro   yank
2    HideBlock;
3    ClipPaste;
4end;

and later:

1Ctrl-Y          :yank;

so you could perhaps make your own .TEM file based on some of those examples, but using the key combinations you want, if you think you could live with the Turbo C++ IDE. UTIL.DOC seems to have a list of all those commands like "ClipPaste".

After the successful execution of the tested executable the command shell "window" auto-closes immediately.

Did you try using the Output window, to see what was on the output screen before it switched back to the IDE screen? I tried running EXAMPLES\EX1.CPP which just outputs a few lines to the screen, and since it exits right away you barely even know it ran when running under DOSBox with max cycles, but the Output window shows its output (and what was on the screen before you even started the IDE!).

Don't get me wrong, I know there's still a lot missing from this IDE 😁

Speaking of output, in case you're not aware, in Turbo Debugger - which is available separately or in the more "professional" product Borland C++ 3 - if you have both VGA and MDA adapters, you can get the debugger to appear on the monochrome display and your program's output to appear on the VGA one, so you don't have to deal with the switching back and forth or an output window. I don't think DOSBox can emulate both at once, but I'm pretty sure some emulators can. I'm pretty sure I've done it in MAME.

I wrote one self-deleting app in addition to some lame DOS-installer creator software (recently I've tested more than 20 different DOS-installer creator solutions and all of them are lame, so maybe I have to write a new descent one from scratch), which can execute some console command upon finish, but lacks the ability to modify configuration AUTOEXEC.BAT file. My self-deleting additional console app is for a specific custom DOS driver install pack (created with this lame DOS-installer software) and throws some messages at console while adding new lines to AUTOEXEC.BAT file.

Sounds like a nice project!

Something that modifies AUTOEXEC.BAT is the kind of thing I could see you actually wanting to run in a completely separate instance of DOSBox or something, but on the other hand, DOS developers back in the day had to live with the risk of making their machine unbootable so it's just part of the experience 😁

doshea wrote on 2025-02-18, 10:40:

It looks like I have version 3.00, perhaps they *removed* some files in 3.01? I have 5, although CMACROS.TEM is for extra key b […]
Show full quote

It looks like I have version 3.00, perhaps they *removed* some files in 3.01? I have 5, although CMACROS.TEM is for extra key bindings like inserting function skeletons,

BRIEF.TEM
CMACROS.TEM
DEFAULTS.TEM
DOSEDIT.TEM
EPSILON.TEM

The last of those files is for an Emacs-like editor. Emacs's paste-like operation is called "yank", and EPSILON.TEM includes:

Copy code to clipboard

1macro   yank
2    HideBlock;
3    ClipPaste;
4end;

and later:

Copy code to clipboard

1Ctrl-Y          :yank;

so you could perhaps make your own .TEM file based on some of those examples, but using the key combinations you want, if you think you could live with the Turbo C++ IDE. UTIL.DOC seems to have a list of all those commands like "ClipPaste".

Sorry, my mistake - there are four .TEM files in TC++ 3.01 and the missing one from ver. 3.00 is EPSILON.TEM. I'll check in UTIL.DOC how to add new key bindings through .TEM file, if possible.

doshea wrote on 2025-02-18, 10:40:

Did you try using the Output window, to see what was on the output screen before it switched back to the IDE screen? I tried running EXAMPLES\EX1.CPP which just outputs a few lines to the screen, and since it exits right away you barely even know it ran when running under DOSBox with max cycles, but the Output window shows its output (and what was on the screen before you even started the IDE!).

Don't get me wrong, I know there's still a lot missing from this IDE 😁

Speaking of output, in case you're not aware, in Turbo Debugger - which is available separately or in the more "professional" product Borland C++ 3 - if you have both VGA and MDA adapters, you can get the debugger to appear on the monochrome display and your program's output to appear on the VGA one, so you don't have to deal with the switching back and forth or an output window. I don't think DOSBox can emulate both at once, but I'm pretty sure some emulators can. I'm pretty sure I've done it in MAME.

I didn't knew that "Output" window from menu "Window" can bring back the buffer with the already closed command prompt console output. Thanks for pointing it! Now this solves some inconvenience 😀

I don't have Turbo Debugger installed. You may laugh at me, but I do my "debugging" in TC++ IDE through some temporary "print" lines for variable values, pointers, etc. in console output - imagine even more ancient times, when no debugger softwares/add-ons were available 🤣 Actually I remove all the debug info "ballast" from the object files to save some bytes in produced executable files size.

doshea wrote on 2025-02-18, 10:40:

Sounds like a nice project!

Yep, this idea for DOS-installer creator software is now a full project. And needs Turbo Vision libraries to look more "fancy" and user friendly. And this leads me to use TC++ compiler. I still don't know how to use TV libraries, but I found a DOS software that generates C++ or Pascal code for text "windows", "button" choice pop-ups, menus, etc. This TV-software-generated code is claimed to be compatible with Borland C++ compiler (probably it will be compatible with TC++ compiler) and also with Turbo Pascal compiler. The name of the software is Dialog Design.

doshea wrote on 2025-02-18, 10:40:

Something that modifies AUTOEXEC.BAT is the kind of thing I could see you actually wanting to run in a completely separate instance of DOSBox or something, but on the other hand, DOS developers back in the day had to live with the risk of making their machine unbootable so it's just part of the experience 😁

No worries, in my DOS-installer creator project those changes in DOS config-files will be optional after an user confirmation 😉

well, i enjoyed the thread 😀 i would have suggested the same - choosing one of open watcom, borland 4.5/5 or rhide/djgpp as providing DOS target compilation in 16bit (or 32 where possible)

for fun there are options like microsoft c (ver 7 i think last one dor dos) and i think digital mars had a dos targetting c/c++ compiler, i also recall names zortech and symantec as having c++ compilers for DOS of various versions and i'm sure there are more

gerry wrote on 2025-02-18, 16:27:

well, i enjoyed the thread 😀 i would have suggested the same - choosing one of open watcom, borland 4.5/5 or rhide/djgpp as providing DOS target compilation in 16bit (or 32 where possible)

for fun there are options like microsoft c (ver 7 i think last one dor dos) and i think digital mars had a dos targetting c/c++ compiler, i also recall names zortech and symantec as having c++ compilers for DOS of various versions and i'm sure there are more

Thanks for your comment, gerry! I think for me it will be enough to set Code::Blocks for cross-compiling with Open Watcom C/C++ (or maybe DJGPP compiler) for non-Turbo-Vision 16-bit DOS apps. But this is not for my current DOS projects 😀

Some of the options you mentioned I came across here (at the end of the article).

i use jetbrains clion with a makefile project that uses openwatcom v2 linux build to crossbuild its output as dos, it then just run the exe in dosbox for testing.

BloodyCactus wrote on 2025-02-18, 17:33:

i use jetbrains clion with a makefile project that uses openwatcom v2 linux build to crossbuild its output as dos, it then just run the exe in dosbox for testing.

I have CLion too. But will it compile Turbo Vision (the original DOS library, not the FOSS more recent version) C++ code with Open Watcom C/C++ compiler? I doubt it will.

analog_programmer wrote on 2025-02-18, 17:40:

BloodyCactus wrote on 2025-02-18, 17:33:

i use jetbrains clion with a makefile project that uses openwatcom v2 linux build to crossbuild its output as dos, it then just run the exe in dosbox for testing.

I have CLion too. But will it compile Turbo Vision (the original DOS library, not the FOSS more recent version) C++ code with Open Watcom C/C++ compiler? I doubt it will.

depends, watcom has a lot of calling conventions, if you build things with the same calling convention that turbo vision was built (assuming your linking against the tv obj's)... if its just all source, probably compile with little fudging. if its inline asm you'd have to change that to pragma aux's. if you have a lib, watcom wlink probably wont understand that format (i dont know, i abandoned borland back when it was turbo-c 1.0).

so much this answer "depends".

you can always just use clion, and with dosbox open, run a "rescan" then run borlands build/make utility on the project. edit with clion, build with borland!

The last time I've tried Open Watcom C/C++ compiler with a very old FOSS C++ code for building some kind of DOS software-trace-rendering app in Linux it was a total disaster. So, I think I'll pass such a complicated experiments for now.

I can always write my code In CLion, but I can also write it in C::B or even it KWrite 😀 And the problem with finding more compatible cross-compiler than OWC/C++ remains.

analog_programmer wrote on 2025-02-18, 18:07:

I can always write my code In CLion, but I can also write it in C::B or even it KWrite 😀 And the problem with finding more compatible cross-compiler than OWC/C++ remains.

so use borland turbo c/c++ to build project. whats the problem? edit with clion or whatever, build with borland in dosbox. just keep your filenames in 8.3 format. problem solved.

BloodyCactus wrote on 2025-02-18, 18:22:

so use borland turbo c/c++ to build project. whats the problem? edit with clion or whatever, build with borland in dosbox. just keep your filenames in 8.3 format. problem solved.

The problem is this switching forth and back between these totally different environments. I doubt I can write more than one function in C without multiple editing, multiple builds and multiple tests for errors. And this is anti-productive, if you get what I mean.

analog_programmer wrote on 2025-02-18, 12:52:

I don't have Turbo Debugger installed. You may laugh at me, but I do my "debugging" in TC++ IDE through some temporary "print" lines for variable values, pointers, etc. in console output - imagine even more ancient times, when no debugger softwares/add-ons were available 🤣 Actually I remove all the debug info "ballast" from the object files to save some bytes in produced executable files size.

Stripping the debug info from software you release is definitely a good idea! I like using debuggers - when they work properly, at least - so I don't have to figure out where to put the temporary print statements, but I have worked with and still do work with many professional developers who still prefer to add print (or equivalent) statements, so you're in good company 😁

This TV-software-generated code is claimed to be compatible with Borland C++ compiler (probably it will be compatible with TC++ compiler) and also with Turbo Pascal compiler. The name of the software is Dialog Design.

The one by David Baldwin? Oops, I was meant to open source that, which might enable it to be updated to work with newer TV libraries. I had trouble getting it to build, then moved and changed jobs and never came back to that project 🙁

analog_programmer wrote on 2025-02-18, 18:37:

The problem is this switching forth and back between these totally different environments. I doubt I can write more than one function in C without multiple editing, multiple builds and multiple tests for errors. And this is anti-productive, if you get what I mean.

I suppose that you should be able to get any modern development environment to run some old compilers via DOSBox, given enough scripting.

Good luck with however you proceed! I'll be interested to hear what progress you make with making your development environment nicer, since I might do something similar one day.