C, nothing else.

Grab a copy of openwatcom 1.9

How boring.

Not sure if this fits the requirements of this thread, but.. Locomotive BASIC 2 for GEM/DOS is also interesting.
It shipped with one of the most popular DOS (DOS Plus) PCs in Europe, the PC-1512. It kind of reminds me of QuickBasic for Mac.
Minus the Compiler, of course. 😉

>ruthan
I didn't tell that low level programming cannot be done in modern OS or with modern lang. But you need libraries that will do it for you and when not exist you need to write own kernel mode driver - which is not fun now because you need to sign the driver to make Win10 happy to load it and for signing you need some NDA with MS or so. Also writing a kernel driver takes much more coding overhead than simple write to IO port or write to a memory location that can be simply done in DOS. Also timing critical stuff is problem in preemptive multitasking OS - again you need a kernel mode code.

I just still didn't get why when you want all the comfort of modern OS and languages why you bother with DOS at all just code it for linux/windows/mac and no problem. You cannot expect such comfort on DOS that was mostly abandoned many years ago and when still running in some embedded apps it runs old good working code that is just maintained but probably not newly developed.

Jo22 wrote on 2020-01-09, 09:48:

Not sure if this fits the requirements of this thread, but.. Locomotive BASIC 2 for GEM/DOS is also interesting.
It shipped with one of the most popular DOS (DOS Plus) PCs in Europe, the PC-1512. It kind of reminds me of QuickBasic for Mac.
Minus the Compiler, of course. 😉

Wow, that looks pretty cool. Sad that GEM never stood a chance against Windows.
Well, keeping on track with the original topic: I stick with Turbo C 2.01 for my dev purposes! Might switch to Turbo C++ or Borland C++ at some point though. But I still like Turbo C pretty much.

RayeR wrote on 2020-01-29, 18:51:

I just still didn't get why when you want all the comfort of modern OS and languages why you bother with DOS at all just code it for linux/windows/mac and no problem. You cannot expect such comfort on DOS that was mostly abandoned many years ago and when still running in some embedded apps it runs old good working code that is just maintained but probably not newly developed.

Depending on what you want, there's a large number of embedded operating systems that get you even closer to the hardware with only the minimum supporting functions you require. Some even play well with legacy systems. Fancy running recent software on a VIC20 or C64?
https://en.wikipedia.org/wiki/Contiki

gdjacobs wrote on 2020-01-30, 05:51:

Depending on what you want, there's a large number of embedded operating systems that get you even closer to the hardware with only the minimum supporting functions you require. Some even play well with legacy systems. Fancy running recent software on a VIC20 or C64?
https://en.wikipedia.org/wiki/Contiki

Yes, there are a lot of newer embedded OSes for tiny systems (x86 or non-x86 MCUs - a small Atmega also can run e.g. a HTTP server) but they have not much similar with DOS.

A relevant and entertaining read, regarding C# and old Microsoft platforms.

https://www.hanselman.com/blog/NETEverywhereA … s311AndDOS.aspx

Probably doesn't help with your objective, but thought it might be of interest! 😀

RayeR wrote on 2020-01-30, 13:09:

but they have not much similar with DOS.

I love DOS and everything, but this is absolutely a benefit. Most of the embedded RTOSes out there allow you to dive in close to the hardware while still having the kinds of features that make modern system architectures viable. DOS isn't going away anytime soon, but I think other options strike a better balance of accessibility and power.

RayeR wrote on 2020-01-29, 18:51:

I just still didn't get why when you want all the comfort of modern OS and languages why you bother with DOS at all just code it for linux/windows/mac and no problem. You cannot expect such comfort on DOS that was mostly abandoned many years ago and when still running in some embedded apps it runs old good working code that is just maintained but probably not newly developed.

This thread about coding for Dos, so i only looking for most user friendly way how to do it, if there is some progress from lets say old good Dark Ages.. If not i will probably let is to other which are ok with old coding hell, today i saw PCem emulator source, its not DOS, but its low level C and is coding for some special type of people.. i dont like it at all.

Simply say no, there was no significant progress since old good Dark Ages. I tried to explain why.
All you can use is some outdated, very limited, dead port of python, JS, some perl, AWK and BASH for shellscripting.
There are still living project but relative low-level to you - some BASIC, DJGPP with MGRX, GCC-IA16, FreePascal, OWC, NASM, FASM, JWASM and other assemblers and C compilers.
The modern high level languages simply relies on rich API support from host OS. DOS didn't developed for 25 years or so cannot give needed support that makes porting them to DOS very hard (you would need to write missing support by your own) and there's not enough demand and interest. (Yes, there are e.g. some micropython or how it's called for MCUs but with very limited functions and libraries compared to full featured pyton on linux/windows...)

Div2 games studio

Simple, powerful, and since the source code was uploaded, same game can run in DOS, Windows, Linux, OSX with new DX port

I made some nice games, and run great in a 386DX, but is not 286 compagtible

theelf wrote on 2020-02-04, 16:40:

Div2 games studio

Simple, powerful, and since the source code was uploaded, same game can run in DOS, Windows, Linux, OSX with new DX port

I made some nice games, and run great in a 386DX, but is not 286 compagtible

Well that is an interesting thing I didn't know yet. Thanks for the hint. Seems to be open source as well. When targeting PCs, XTs and ATs I guess handcrafting is still best. But for 386 and up this might be worthwhile.

http://div-arena.co.uk/

RayeR wrote on 2020-02-04, 14:48:

There are still living project but relative low-level to you - some BASIC, DJGPP with MGRX, GCC-IA16, FreePascal, OWC, NASM, FASM, JWASM and other assemblers and C compilers.
The modern high level languages simply relies on rich API support from host OS.

I understand, but i dont really want too much ( rich API etc), i just want these features:
- automatic memory management - no pointers.. or care about variable size in memory etc..
- support for big memory models to use lots of ram (32 MB or 64 MB should be enough)
- compile code which is running fast enough
- optimal, possibility to develop and run such code on modern OS somehow (even inside virtual machine, if it would be quick enough process)

If some programming language cant give me that, maybe is there or some can make some framework, engine etc.. high would be more highlevel abstract to work like that.

You're barking up the wrong tree, buddy. DOS wasn't easy, it wasn't fast, it wasn't powerful. It survived merely because computers were disposable platforms up until IBM released the XT, and consumers were sick and tired of throwing out all their old software every two years when a new computer came out that couldn't run anything the old one did. IBM's x86 platform, and DOS, both shoe-horned compatibility into the product, working around short-sighted decisions and self-imposed limitations. It gained inertia. Before you knew it, you couldn't compete with the installed base, and so it survived when all its (mostly better) competitors failed.

When it comes to programming, you're stuck in the ways of modern development -- where you can afford to throw away performance in the name of convenience. That's not the case with DOS. You can't rely on a garbage collector to come along and clean up the dangling pointers you left behind without giving up memory and processor time -- and neither of those were in abundance back then.

If you want to code for DOS, you have to work within DOS's limits. That means: Memory is limited. I/O is direct. Creature comforts are few, often because of the first two points. The 8086 was not a terribly well-designed processor, and when it became necessary to extend it, it wasn't always graceful. The x86 platform itself suffered the same fate. Extensions were the prerogative of whoever thought of it first and managed to sell enough product that it became the de-facto standard. Merit, elegance, and foresight were not required to succeed.

So, that's the cold bucket of water. Now, the good news is this:

C is not hard. It's a small langauge, and once your learn the basics, you're all set. Everything else builds on that. The learning curve is almost entirely around memory management, which is really and truly no big deal.

Basically, all you need to know is this: The number of "ptr = malloc()"s must equal the number of "free(ptr)"s. That's it. All the fancy modern memory management and VMs stem from the fact that a lot of code is written by people to bad at coding, or too lazy, or in too much of a hurry, to make sure those two statements remain in equal abundance. It isn't for YOUR convenience that managed platforms exist, it's to protect the rest of us from your errors. 😉

Before you worry about network capability, graphics libraries, how to allocate multiple MB of RAM, maybe focus on getting a program to output "Hello world" to the console. Don't sweat the big stuff, focus on the small stuff. You'll get there. And when you do, you'll know what you want, and why, rather than being faced with a gazillion options -- none of which are what you know now.

Just my 2c: I've spent a decade or so learning C and getting accustomed to "real" coding, after having been stuck scripting and using... *shudder* BASIC *shudder*... since I was a kid. VB was fun to quickly throw together a CD autorun project or something, but it holds you back something fierce. The way out was to learn C, since that's what ALLL of the APIs were written in anyway. You can fight it, but you have to dip your toe in that world to comprehend the examples and the interface anyway, so you might as well just use the language itself. It's just easier that way.

For me, the natural progression was to start programming in C, in Linux. Windows can be a bit convoluted, and Linux gave me the closest to bare metal (but with amenities) that I could get. Also lots of well-traveled free tools. I am now at the point where I'm ready to cross over into DOS, and that knowledge has helped tremendously. So has learning to develop on an Arduino, which I quickly shed and went bare AVR. A microcontroller is in many ways very similar to DOS -- the capabilities are pretty similar. You also learn to live in a very tight spaces.

So, to sum up, you need to drop these terms from your vocabulary: VM, memory management, framework, engine. The languages du jour of the platform are BASIC, Pascal, C, and ASM. That's also in order of learning curve, probably, but in exactly reverse order of capability. If you ever plan to do anything worthwhile in DOS, you will eventually pretty much have to learn ASM and be comfortable twiddling bits in a register. It's not hard, it's just tedious. Grab an Arduino and practice.

I disagree a lot..

I used C in Dos first time 22 years ago, so i know something about it. From time to time i used C on Windows too for years for some easy stuff. In last few months i had time to read whole low level console programming C/C++ book. That low level stuff, wasnt some like small thing to suffer, but it was main theme.

I like to solve real problems, not stuck in some low level details, its waste of time to prove that i can to do thing on lowlevel with blindfold.. Its something like play normal games, versus play something with Dark Souls difficulty for forever. I dont like that whole not low level enough = bad code talk .. more high level code, abstract code, enable to solve complex problems in general, or at least solve them faster and you still can optimize block of code, where it is really needed.

There are coders, which are not so creative in translate ideas into programs, but love to adjust and make faster code written by someone else.. im right opposite of that. I thing that there is room for both of these types of coders.

Once i got away from that awful lowlevel stuff, i dont want go back, its like bad relationship. I have nothing to prove myself, im able to work with that, but i simply never liked it. If can avoid it, i can write something again for Dos, otherwise i will probably pass, unless i will really very motivated.. I understand that someone like low level control, micro manage stuff, feel that he really understand what code is doing, but its not me.. for me such low level stuff is more like mine field walk, that something what would help me.

Garbage collection is not only way how avoid that memory management stuff.

I like possibility of choice, that is best thing in the human life.

root42 wrote on 2020-02-04, 18:31:

theelf wrote on 2020-02-04, 16:40:

Div2 games studio

Simple, powerful, and since the source code was uploaded, same game can run in DOS, Windows, Linux, OSX with new DX port

I made some nice games, and run great in a 386DX, but is not 286 compagtible

Well that is an interesting thing I didn't know yet. Thanks for the hint. Seems to be open source as well. When targeting PCs, XTs and ATs I guess handcrafting is still best. But for 386 and up this might be worthwhile.

http://div-arena.co.uk/

DIV is amazing, I use since first version, mid 90s maybe

If target is 386+ is a great option, the code is very easy, similar to Pascal

I code in the new DX build in windows, and compile in the old dos version when i need DOS executables

ruthan wrote on 2020-02-05, 10:25:

I like to solve real problems, not stuck in some low level details, its waste of time to prove that i can to do thing on lowlevel with blindfold.. Its something like play normal games, versus play something with Dark Souls difficulty for forever. I dont like that whole not low level enough = bad code talk .. more high level code, abstract code, enable to solve complex problems in general, or at least solve them faster and you still can optimize block of code, where it is really needed.

That's fine when you're running on 2GHz+ processors with 4GB RAM. It isn't going to cut it on Pentium and older hosts. The overhead of all the programming guard rails is just too high. Especially in DOS, where you get (what's left of) what an 8086 could address.

I'm not saying everything ever written needs to be in hand-tuned ASM. Heck, I love using perl. Flexible typing, reference-counting, no concern for bounds... wonderful when you're just trying to express an idea or solve a problem with the minimum of effort. I'm sure not going to try and code a TCP stack for DOS in perl though. (Or worse yet, try to reuse one from a library written for full-featured hosts in an environment that would run out memory trying to accommodate the out-of-order packet delivery queue.)

Good luck though.

SirNickity wrote on 2020-02-05, 20:32:

That's fine when you're running on 2GHz+ processors with 4GB RAM. It isn't going to cut it on Pentium and older hosts. The overhead of all the programming guard rails is just too high. Especially in DOS, where you get (what's left of) what an 8086 could address.

Not necessarily true. Powerful language design is not the same as crufty training wheels bolted on to older programming paradigms. ML can approach the computing efficiency of well tuned C while abstracting away a lot of the low level functionality. Forth allows writing very low level code which rapidly builds up into high level semantic structures, all in a very space and compute efficient runtime.

ruthan wrote on 2020-02-05, 10:25:

There are coders, which are not so creative in translate ideas into programs, but love to adjust and make faster code written by someone else.. im right opposite of that. I thing that there is room for both of these types of coders.

Sorry to wake you up. I believe the biggest motivation for innovation known to mankind is M.O.N.E.Y. Without it, you cannot simply put the blame for not bringing one.

I don't know about you, but I don't smell anything in DOS. If I was wrong, Advanced Gravis should have resurrected from their death long before, remaking their cards.

gdjacobs wrote on 2020-02-05, 20:47:

SirNickity wrote on 2020-02-05, 20:32:

That's fine when you're running on 2GHz+ processors with 4GB RAM. It isn't going to cut it on Pentium and older hosts. The overhead of all the programming guard rails is just too high. Especially in DOS, where you get (what's left of) what an 8086 could address.

Not necessarily true. Powerful language design is not the same as crufty training wheels bolted on to older programming paradigms. ML can approach the computing efficiency of well tuned C while abstracting away a lot of the low level functionality. Forth allows writing very low level code which rapidly builds up into high level semantic structures, all in a very space and compute efficient runtime.

I tend to agree with SirNickity here.

If you're to deal with "modern-ish" CPUs, then you are forgiven to ditch low-level stuffs and to put your head above the cloud. ("Modern-ish" is a blurry word, I admit. Let's just say P4-and-after stuffs.) I mean, those architectures are pretty much small computers of their own with their own will. They pick instructions and data of their liking at any given moment, and compilers are essentially there to be as enforces of such tastes on instructions you write in forms of programing language. Well, in these days, even compilers are multi-staged in a way that, regardless of your language choice, outcome is pretty much the same. Minding low-level details with low-level languages in such scenario is a guaranteed waste of time.

Otherwise, I'd say it's safe to assume that we'd be in "embedded cpu" area, and all the gory low-level details would be likely puddling on us.