I these is low level coding, for me was always more interesting debugging of existing Dos programs.. Is someone here able to thing like Codeview or Insight to analyze some existing games or programs and find out why not working on some machines and even fix it? I saw few people can made some hexa porn.. add some nops etc.. and games started to work..

IMO, IDE choice is 100% personal preference. I like the idea of coding in DOS, for DOS, but in text mode you only have so much real estate, and compiling does take a while on older computers.

I hardly ever write code without having a split window with headers, other source, or even a different location of the same file side-by-side with the part I'm working on. I use Kate in Linux. Not sure it qualifies as an IDE, it's really just a text editor with indentation and syntax highlighting support, but I like how lightweight it is, and how easy it is to jump in via SSH and tweak/recompile something vs. having some huge monolithic environment that kind of takes over that computer. I'm not a professional programmer, so I don't have projects with a million LoC, or have to coordinate development with anyone else, but I do use code I write for my day job as well as stuff I do for fun. I'm sure if my projects were much larger scale, I might feel differently.

One solution I've found for DOS code is to use DOSBox in a window alongside my native coding environment. That way, I can use (e.g.) edit or MASM or whatever, and be able to save it, compile it, run it. This is a little more convenient than editing the files in-place under the host OS, since you then have to tell DOSBox that the files changed -- which just feels a little hacky. Not a huge deal, and if your code modules are large enough that compilation time is a major factor, then it's probably easier just to go ahead and set up a cross-compiler and deal with refreshing the disk to run the new executable.

This workflow is still a work-in-progress, since I'm new to DOS coding. I'm also looking into early Visual C versions (Win3x or 95), though I haven't really found an emulator for 95 that works very well. I often want to chip away at a project while I'm travelling for work so it's nice to have it all on my laptop, but I think practically I'll just end up using real hardware. At least library stuff can be written and tested anywhere I have a C compiler, which helps.

BloodyCactus wrote on 2020-02-18, 15:07:

I spend all day doing java/ee/ui5/sap...

I've heard what SAP is like to work with. Do you come home with the only thing heavier than your soul being your pay cheque?

sap ABAP is nightmare. SAP Java is fine, java is java. Java tooling is awesome (ide/debuggers/profiling/testing/mock data, etc).

The new UI5 toolkit stuff is very nice to work with, OData binding etc. They opensoured it, OpenUI5. I like it.

BloodyCactus wrote on 2020-02-19, 00:18:

sap ABAP is nightmare. SAP Java is fine, java is java. Java tooling is awesome (ide/debuggers/profiling/testing/mock data, etc).

The new UI5 toolkit stuff is very nice to work with, OData binding etc. They opensoured it, OpenUI5. I like it.

Java as a language is fine. Unfortunately, not all Java software is created equal:
https://thedailywtf.com/articles/The-Enterprise-User-Agent

I've never done any implementation work in SAP, although I have witnessed strange debugging errors in German as a user. It gave me a bad feeling of what was hiding around the corner.

ruthan wrote on 2020-02-18, 15:04:

I wonder if there is someone who is part of both worlds. Someone who is coding new apps in modern language like C#,Java, Python, PHP, Ruby on professional level (to exclude some simple webpages) etc.. and still is using low level C on Dos for some other work or hobby? Because such persons ideas would be most valid and interesting.

Like some of the other posters here, I also work on Java (and some Clojure) stuff all day, deploying with Docker/K8S, and all that kind of fun stuff. I used to (years ago) do web dev type stuff in my spare time as well, but over the past decade that has disappeared entirely. I find it excruciatingly difficult to motivate myself to work on web dev for hobby projects. Too similar to my day-to-day work. The only way now that I can motivate myself to code in my spare time is to work on something so totally different from what I'm doing at the day job. "Retro-coding" fits that bill nicely. Unlike others here, I do insist on using era-appropriate hardware, tools and editors during development, but I totally understand why someone would not want to do that (modern IDEs and text editors are quite a bit nicer).

One aspect I really like about retro-coding is the (usually) simpler build tools. No multi-module maven dependencies pulling in shit from various places and some random "DLL hell"-type issues, plugins for generating code from a WSDL (oh dear) or some other XSD, complicated configurations (even coming in from different sources), complicated Jenkins jobs for building and deploying reliably and consistently, difficulty in actually running your project locally because of it needing to be run in a "container" (we still deploy a fair bit of stuff into OSGi containers, for anyone familiar with that...). Yeah, your retro-coding projects can get pretty complicated to build too. But I'd wager most aren't (certainly nothing I work on is anywhere near this level of complexity).

Compared to some of the stuff I do with Watcom on my 486 at home, where I edit code with the Aurora Text Editor, build using wmake and then run an exe directly. It's an apples-to-oranges comparison for sure, but hot damn does it feel so much nicer compared to my day job projects. Or even better, Turbo Pascal, which builds my project and runs almost instantly.

We can do so many cool things today with all our neat programming toys, and yet it still feels like each year we regress...

Ok, I'll take off my rose-tinted glasses now and stop rambling. 😉

One aspect I really like about retro-coding is the (usually) simpler build tools. No multi-module maven dependencies pulling in shit from various places and some random "DLL hell"-type issues, plugins for generating code from a WSDL (oh dear) or some other XSD, complicated configurations (even coming in from different sources), complicated Jenkins jobs for building and deploying reliably and consistently, difficulty in actually running your project locally because of it needing to be run in a "container" (we still deploy a fair bit of stuff into OSGi containers, for anyone familiar with that...). Yeah, your retro-coding projects can get pretty complicated to build too. But I'd wager most aren't (certainly nothing I work on is anywhere near this level of complexity).

Nobody like that maven, ant dependencies hell.. but otherwise i still like it much more than old Linux way hey that you have some files and make file.. and lets make it run on your distro.. we tested it on 1 other distro already.
These sort of problems which you described are for me still much over abstract and quite logical.. and more friendly to debug that trying to decipher some strange C++ lowlevel error and waiting for old slow dos machine reboots, because i forgot on some pointer or i dont know that size of some variable differs because of target OS.

BTW can you really live on DOS with just with C/C++ or for low level errors solving you have to know ASM too, which is even more lowlevel? Again i was able to understand some ASM code, i did with it some things.. but im glad, that i dont use on daily basis. Despite it i always admired people who were able to fix / adjust already compiled binary code with some ASM hacks.. for example thanks to these stuff some people made possible XP booting on newer machines.

It depends entirely what project you are working on. If you're writing some low-level code that is interfacing with hardware, or really trying to eke out every last ounce of performance for older hardware, then you probably will need to fall back to assembly often. The projects that I currently work on (C and Pascal) do use assembly in performance sensitive sections of code, but only as needed because, as you say, it's harder to debug when something goes wrong. But the vast majority of the time in my retro-coding projects, I am debugging high-level code, not assembly.

You've indicated an interest in hacking/fixing existing binaries, which I also think is a cool skill, but it's not something I do at all so I cannot advise you there. 😀

... waiting for old slow dos machine reboots, because i forgot on some pointer or i dont know that size of some variable differs because of target OS

I don't mean any offense by this, so don't take this the wrong way, but this bit made me laugh. My 486 can do a full rebuild of my current C project (Watcom 10) faster then I can do a full rebuild and deployment of some of my current day-job projects at work (damn OSGi containers!!). Even if I have to reboot my 486 because my code crashed, it's still far less of a pain to me in comparison. Again, apples-to-oranges comparison, but this is the kind of thing I'm talking about when I say how it feels like we've progressed so far over the past decades and yet it still feels like we've regressed in a number of ways.

slow old dos reboots...

thats why you test on dosbox initially, then real hardware 😀

few weeks ago, I ran into a bug... code works in dosbox, does not work on real machine (real dos I should say, boot dos disk in dosbox yeilds same result as real machine, so its real-dos vs dosbox-dos).

Looks like DOS 6 and 7 dont obey the documentation. not tested on other versions of dos yet.

or its incorrect api documentation... eitherway I need to test more 😀 but dosbox obeys the documetation in ralf browns interrupt list... real does gives a different result.

BloodyCactus wrote on 2020-02-19, 15:42:

Looks like DOS 6 and 7 dont obey the documentation. not tested on other versions of dos yet.

Sounds interesting. Maybe it's worth testing on Novell DOS 7, DOS Plus, ROMDOS, XDOS, FreeDOS or PC-MOS/386 5.x (has DOS 5 ABI) then. 😀
Edit: You could also try MS-DOS Player, too. It has a synthetic DOS like DOSBox. Other DOS I know is the DOS of Atar Portfolio, "DIP-DOS".
It features an MS-DOS 2.11 ABI level compatibility, which isn't much but still better than that DOS 1.25/2.0 crap which MS has offered to the world. 😉

ruthan wrote on 2020-02-19, 14:39:

These sort of problems which you described are for me still much over abstract and quite logical.. and more friendly to debug that trying to decipher some strange C++ lowlevel error

I know this depends a LOT on what compiler you use, but I find GCC is so helpful with error messages. It even tries to guess what you meant when you make typos, and although it isn't always right, just the "I think you meant XXX?" messages make it very clear what the problem was.

I also like perl's errors. I've tried a touch of Python, and I swear I cannot figure out what its problem is half the time... I'm sure it would be more evident with experience though.

Not that any of this really applies much to DOS, though.

ruthan wrote on 2020-02-19, 14:39:

BTW can you really live on DOS with just with C/C++ or for low level errors solving you have to know ASM too, which is even more lowlevel? Again i was able to understand some ASM code, i did with it some things.. but im glad, that i dont use on daily basis.

I think it depends on what you want to do. There are some drivers and hardware that seem as though you have to interface them on the ASM level, but often there's a library of pre-written ASM interface routines that you can call from C. That isn't so much a performance thing, but that not all features of the hardware are exposed to the higher-level languages. You also need those interface libraries for BASIC and Pascal for example. If you're in the game long enough, I would imagine you will eventually have to write some such routing yourself, so knowing ASM would be a useful investment in your time.

All of this might be colored by my particular interests, and the coding tasks resulting from such. If you're writing accounting software, your experience will be different.

How far could a person realistically go just with DEBUG? Theoretically, I guess you could bootstrap all the way up if you wanted, but that would be insane.

Can't remember if this has already been posted, but has anyone tried this: https://github.com/tkchia/gcc-ia16

ruthan wrote on 2020-02-18, 15:04:

I wonder if there is someone who is part of both worlds. Someone who is coding new apps in modern language like C#,Java, Python, PHP, Ruby on professional level (to exclude some simple webpages) etc.. and still is using low level C on Dos for some other work or hobby? Because such persons ideas would be most valid and interesting.

Me. I'm a software architect that writes lots of Python code (and the occasional bit of C++ here and there), but my language(s) of choice for retro development are C and Turbo/Object Pascal. I've also started messing around with Delphi to make some basic Windows 9x applications as well.

I asked on DosJS github, if is possible to create standalone exe with it.. and i got response that it is possible, but its not really my thing, ca someone with more knowledge check it?
https://github.com/SuperIlu/DOjS/issues/9#iss … mment-675460760

keenmaster486 wrote on 2020-02-20, 18:11:

Can't remember if this has already been posted, but has anyone tried this: https://github.com/tkchia/gcc-ia16

I have played with gcc-ia16. It works quite well, and since it's a GCC toolchain, it integrates well with CLion, my current cross-platform C/C++ IDE of choice, as long as I use CMake as the build system.

I prefer a fully-featured modern IDE for things like code completion, error highlighting, refactoring tools and SCM integration. What can I say? I'm spoiled. 😅

CLion is from JetBrains, the same company that also develops other well-known language-specific IDEs such as IntelliJ IDEA and WebStorm.

Note that unlike IntelliJ IDEA, there is no "Community Edition" of CLion, so you have to pay for a license to use it.

There is a NASM Assembly Language plugin for JetBrains IDEs (not just CLion), which works fairly well for assembly language programming as well, although it currently lacks things like refactoring support and code completion.

If you don't like the JetBrains IDEs, or prefer not to pay for CLion, you might want to take a look at Visual Studio Code, which is free, cross-platform and open source. (Not to be confused with regular Visual Studio or Visual Studio Express. Visual Studio Code is a separate software product.)

I noticed quite a few assembly language extensions for Visual Studio Code at the Visual Studio Code Marketplace, including some dialect-specific ones (MASM, TASM, NASM). The last time I checked, Visual Studio Code was the single most active open source project on GitHub, so it's been undergoing very rapid development and improvements these last few years. Definitely worth checking out for cross-platform DOS programming.

Yeah, I know there are some hard-core folks who insist on programming on the same platform that they are targeting, but good luck finding a good fully-featured DOS IDE that is as powerful, fully featured and convenient as the modern choices we have on Linux, Windows and macOS, let alone any that have integrated support for SCMs such as Git. Also, in DOS you won't have access to modern high resolution display modes. I guess 80 columns might be acceptable to some coders, but it's not for everyone. 😬

The one thing I've yet to explore in further detail is remote debugging of DOS code while it's running in a DOSBox or PCEmu instance (or perhaps even on actual retro hardware through a serial cable?). But I believe that is possible as well. Perhaps others here can shed some more light on the debugging side of things?

For DJGPP there was quite good IDE - RHIDE for DOS looking similar to TurboPascal (Turbovision). It use textmode but also supported VESA text modes so much more than standard 80x25 mode was possible. Unfortunatelly the debugger part became broken as GDB evolved while RHIDE was frozen. It was big advantage over text/command-only GDB. When I'm developing for DOS I often need to interact with real hardware so debugging in Dosbox is not viable so I'm running the toolchain and editor on target. If it is possible I run it under Win98 as it still allows quite good low level access to hardware and I have multitasking and networking so I can search and browse online docs. etc. I don't know about DOS debugging over serial port, GDB has some networking support so it could be possible via packet drivers but I never tested if DOS GDB build have networking enabled...

Hi, guys. I'm looking for some universal language that could make some GUI stuff for both DOS and modern Windows. I found Python for DOS here: http://www.caddit.net/pythond/downloads.php ...anyone have experience with this? Or some other approach? I like modern object oriented or functional approach. My experience is: Java, Python, Arduino (simplified C/C++), MBED platform and Javascript. Running Python or Typescript (Node.js / Angular hybrid HTML5 app) would be the best. All these high level languages gets easily compiled into native C using DJGPP, so performance should not be a big issue. Portability and clean code is more important for me.

I found some resources here: https://github.com/balintkissdev/awesome-dos

I think that DOjS looks the best: https://github.com/SuperIlu/DOjS

My background: 33 years old software developer (Java, Typescript, Python, Blockchain) developing software since 10 years old. Started using SGP Baltazar 5, a MS-DOS software for kids to create games and compile to native exe.

In 14 I win 5th place in programming competition, made a simplified GTA 1 clone with 16 color graphics (english and czech language). You can still download it from their website: http://www.sgp.cz/sgptop/data/137.zip (source with chart: http://www.sgpsys.com/cz/sgptop/programs.asp-sort2=sgp.htm ...you can find 3 apps by Lukas Satin)...and no I would not go back to this style of programming. I tried briefly also Allegro for MS-DOS. Today, we deserve something better.

Well almost nobody tried, when Python or some Javascript would be able to create some standalone *.exe that is point when i would be interested.. GUI - it would probably need port some Dos good SVGA engine - there was 1 at least good used for games, but i forgot the name.. starting write it from scratch seems to be waste of time, in theory some C/C++ wrapper could be used, so it could be even quick and usefull without C/C++ knowledge.

Its same with https://github.com/rxi/lovedos .. when it would be able to create standalone *.exe ..

Update: That graphical engine, what i meant is maybe Allegro.. there are some details, but it need that wrapper layer to be really interesting towards goal of this disscussion.
Are there any open-source game engines for msdos?

If you want to reuse graphical stuff on Dos, Windows, Linux etc, then your only real option is SDL - there are some efforts to get libSDL working on Dos. The main advantage to something like SDL is that you have numerous shims available for most of the common programming languages to interact with it.

Allegro is probably the best developed Dos graphics library, but support is deprecated in later versions and it didn't really seem to get as much cross-platform traction as libSDL. Plus I don't think there's much in the way of glue available to use it from other languages like Python (for example).

In terms of actually writing Python or Javascript for Dos, well, that's probably where you'll have to roll your sleeves up; there used to be a port of (a very early - 1.x?) Python for Dos, but I think it vanished from the web. Anything else you mention is simply too new or too high-level to run on Dos; for Javascript you've need to have a runtime environment - and even then, it's not going to be particularly efficient.

If you want to write modern, performant code for Dos (which, if you're doing stuff with graphics, you'll need to), then really you are looking at x86 assembly, C or C++.

DJGPP is a nice environment, especially if you are used to the typical GNU development toolchain, but I can also reccomend the Open Watcom compiler suite as another modern, up to date alternative to DJGPP if you want to target 386/protected mode as well as retain compatability with 16bit/real mode hardware like the 286 or earlier.

I'd also agree with others in that a Dos-hosted development suite is always going to be way behind a modern IDE/editor on Linux/Mac/Windows accompanied by cross compilers (of which DJGPP and Open Watcom can both be built as).