DOS ain't dead

In SBMIX, written in Turbo Pascal 6+, there are IN/OUT instructions via inline BASM assembly.

Obviously, TP 5.5 can do the same in different ways (vaguely similar to Modula-2; bah, one guy just used inline asm anyways!). FPC and GPC (among others??) support such TP "port" usage. (Here's a small tutorial.)

But even that is somewhat limited and "ad hoc". While native compilation is fine for some things (smaller, faster), maybe it could also be avoided? Would an interpreter work better (ease maintenance of such low-level tasks)? Presumably, many people have done this before for DOS, but I don't know of many obvious implementations.

The 16-bit DOS version of BRexx 2.1.0 (from 2003) has support for some low-level things (INTR and PORT). (Here's an old review. And here's Howard Fosdick's freeware REXX book as PDF.)

Here's a tutorial for QBASIC for various memory management routines and accessing I/O ports.

Probably a lot of old DOS demos and games (X2FTP?) used such low-level stuff, but I haven't studied closely yet.

> In SBMIX, written in
> Turbo Pascal 6+, there are IN/OUT instructions via inline BASM assembly.

(Afaik this works in FPC/Dos too, and in other OSes if the relevant permissions are arranged (e.g. inoutport32.dll on windows or ioperm on *nix),

peek en poke alike functionality also exists with the mem[] pseudo array, but on 32-bit dos that access the dos 1MB, not the protect mode memory)

> Obviously, TP 5.5 can do the same in different ways (vaguely similar to
> Modula-2; bah, one guy just used
> inline
> asm anyways!).
> FPC
> and GPC (among
> others??) support such TP "port" usage. (Here's a small
> tutorial.)
>
> But even that is somewhat limited and "ad hoc".

They should generate the same instructions. How is this limited and adhoc?

What is really the problem you need to solve? What is it that these can't do?

The urls all have their own x86 primitives in various dos styles (but e.g. not Linux x86_intr.h style)

Besides these there are often also copro instructions (load/store copro cw for rounding purposes, emms etc)

> How is this limited and adhoc?
> What is really the problem you need to solve?
> What is it that these can't do?

I was mainly just thinking out loud to myself about various things (portability, extensibility, maintainability).

Native binary compilation is smaller and faster when you know exactly what you want. But it's also an unmodifiable black box, too specific, not generic enough. You know, the advice "Just rebuild the entire app!" is quite naive and not always easy. (For reasonably small DOS programs, maybe. But you know what I mean. It's not extensible.) So I was mostly wondering about a scripting tool to do the same, where only the script text needs changing.

Using inline asm is like a cheat. You can do anything. At that point you might as well almost use (only) raw assembly and not a HLL. (Mild exaggeration, obviously wrong, but you know what I mean: it's very vendor/OEM/machine specific, maybe OS specific, maybe even compiler specific. Not good. Wirth suggests separating all non-portable SYSTEM stuff into separate modules.)

I forgot that you could just write a simple DEBUG script or maybe a small (turnkey?) Forth app. That has some interactivity that I was wanting without being completely closed and hidden, without being huge and requiring megabytes of non-standard compiler bloat just to fix, extend, or rebuild.

P.S. This is not a complaint against TP versus other languages or implementations or an argument of compilers versus interpreters. If anything, I wonder about writing such an interpreter in TP! I'm just comparing various ways of doing low-level stuff for DOS. If possible, one should use already-available scripting languages pre-installed with the OS for optimal deployment, no? QBASIC at least used to be pre-installed, same with (DOS) DEBUG. Not sure if PC-DOS' REXX could handle such low-level stuff, though.

> > How is this limited and adhoc?
> > What is really the problem you need to solve?
> > What is it that these can't do?
>
> I was mainly just thinking out loud to myself about various things
> (portability, extensibility, maintainability).
>
> Native binary compilation is smaller and faster when you know
> exactly what you want. But it's also an unmodifiable black box, too
> specific, not generic enough. You know, the advice "Just rebuild the entire
> app!" is quite naive and not always easy. (For reasonably small DOS
> programs, maybe. But you know what I mean. It's not extensible.) So I was
> mostly wondering about a scripting tool to do the same, where only the
> script text needs changing.

Scripting vs precompiling is always a battle of freedom vs control.

Compiled binaries usually have much lower dependencies. Scripting languages are in theory portable, but platform details, interpreter versioning often also take their toll.

I've always leaned more towards compiling, with sometimes a small interpreter integrated for some minor application internal scripting.

But I'm a software developer, if you are more a systems administrator/maintainer or DBA, the tradeoffs are probably different

As a software developer and I start out with deep compiled language knowledge and installed compilers. So I do a lot in Delphi/FPC what other people would do in scripting, just to avoid having to keep up with another language for relative minor stuff. I do still use scripting, but it is fairly basic stuff in whatever the systems preinstalled interpreter is (batch or shell script). More sequencing steps than really solving problems/programming.

When I was more a sysadmin in the early 2000s, I did a lot more in scripting languages (kix and vbs mostly and a bit of shell script on Linux and Solaris).
Most were fairly small (2000 lines) system startup scripts to map drives etc.

But every time I let scripts grow too big has been a disappointment to me, usually interpreter difficulties (script X only works with Perl 5.000028 but not with 5.000030 etc), slow improvements, increasing deployment sizes of the interpreters, major version transitions that change the language quite deeply (Python 2->3, perl5->6) being the core problems. Also some scripting languages are horribly Unix centric, and real good Windows scripting languages often don't even exist for *nix.

My absolute worst programming experience ever keeping a (admittedly huge) Perl script running.

> Using inline asm is like a cheat. You can do anything. At that point you
> might as well almost use (only) raw assembly and not a HLL.

One counterpoint doesn't invalidate the argument. Why? Because on average you still mostly work in HLL and not raw assembler, so overall productivity and bugrates are more HLL than ASM.

Moreover, any direct hardware access is dangerous anyway, so doing that in assembler is not necessarily less safe or more portable than doing it in HLL. Just because it in HLL doesn't make something unsafe safe.

>(Mild
> exaggeration, obviously wrong, but you know what I mean: it's very
> vendor/OEM/machine specific, maybe OS specific, maybe even compiler
> specific. Not good. Wirth suggests separating all non-portable SYSTEM stuff
> into separate modules.)

Yes. That is related to the point above. Isolate the code with different tradeoffs from the generic code, so you have less code to review if there are problems. Or to rewrite if you change OS.

It doesn't mean that that makes porting guaranteed easy, but it is better than not having any care at all.

>
> I forgot that you could just write a simple DEBUG script or maybe a small
> (turnkey?)

One could argue that is not a script but a compiled language with debug being an assembler that merely executes.

A bit like instantfpc that allows you to run Pascal source files as script under *nix. The unix shell calls instantfpc as interpreter which simply compiles and then executes the binary from some temp dir.

> Forth
> app. That has some interactivity that I was wanting without being
> completely closed and hidden, without being huge and requiring megabytes of
> non-standard compiler bloat just to fix, extend, or rebuild.

So where are the huge Forth codebases? Afaik Forth emerged as a kind of "tighter than asm" scripting language for e.g. BIOS/firmwares (particularly Open Firmware), but with rising flash sizes than went the way of the dodo.

> P.S. This is not a complaint against TP versus other languages or
> implementations or an argument of compilers versus interpreters. If
> anything, I wonder about writing such an interpreter in TP! I'm just
> comparing various ways of doing low-level stuff for DOS. If possible, one
> should use already-available scripting languages pre-installed with the OS
> for optimal deployment, no? QBASIC at least used to be pre-installed, same
> with (DOS) DEBUG. Not sure if PC-DOS' REXX could handle such low-level
> stuff, though.

Well besides compilers vs interpreters this hits much more "general languages" vs "domain specific languages". The latter are often scripting languages for one specific purpose.

You can e.g. imagine port I/O in a scripting language that is mainly used for hardware detection on Dos. Then you can just share the detection routines as text.

But e.g. a game interpreter that requires it for vertical refresh sync, it makes much more sense to not make port I/O part of the language, but just "wait for vertical refresh".

> But every time I let scripts grow too big has been a disappointment to me,
> usually interpreter difficulties (script X only works with Perl 5.000028
> but not with 5.000030 etc), slow improvements, increasing deployment sizes
> of the interpreters, major version transitions that change the language
> quite deeply (Python 2->3, perl5->6) being the core problems. Also some
> scripting languages are horribly Unix centric, and real good Windows
> scripting languages often don't even exist for *nix.
>
> My absolute worst programming experience ever keeping a (admittedly huge)
> Perl script running.

Perl 6 has been renamed the Raku language (with Larry Wall's permission). Perl 7 has been announced as the future, aka Perl 5.32 with "modern defaults" and (shrinking?) backwards compatibility.

Just to reiterate, Perl 5.8.8 (2007) is the last DJGPP build we have available, so quite ancient. (Perl 5 was originally from 1994.)

I don't know, it's a mess (the world). It's not that I personally can afford to care about every niche platform either, but ... you know, the (forced? unavoidable?) narrowing of support and ever-increasing niche goals for ultra-modern, high-end systems is somewhat annoying. (64-bit Linux or Windows or die. Oh, don't forget SMP, AVX, GPU, etc.)

Then again, hardware is throwaway, and software lasts less than hardware these days. So who cares. Still makes everything feel like a waste of time (almost). Change change change, gotta keep up, ugh.

P.S. Apple is switching (again) exclusively to ARM in the next two years.