DOS ain't dead

Well, the subject says it all - I am just wondering?

...and what happend to Jason G Burgon? I still like his GDos unit (replacement for the Dos/WinDos unit) a lot!

> Well, the subject says it all - I am just wondering?

I changed to FPC in 1997

> > Well, the subject says it all - I am just wondering?
>
> I changed to FPC in 1997

I changed to DJGPP in 2000 :)

---
DOS gives me freedom to unlimited HW access.

> > > Well, the subject says it all - I am just wondering?
> >
> > I changed to FPC in 1997
>
> I changed to DJGPP in 2000 :)

FreeDOS KEYB is written in TP7, similarly for older (deprecated) XKEYB. Galactic Conquest was TP7 (few months ago), same as Paku Paku (month or two ago). rr's UPXDUMP was at least compatible with TP55, but I think he calls TP7/BP7 the "best ever" (or was it TP6? Meh, close enough).

People like it because it's so small and fast. The only downside is (of course) it's old and (only) 16-bit. Well, and DOS-based, but that's to be expected (and no other 16-bit OS lived as long or as well.)

There's probably many still using it, but I doubt many public projects still do (esp. with 64-bit incompatibility) except for niche uses ("gotta be small, fast, for DOS").

> > Well, the subject says it all - I am just wondering?
>
> I changed to FPC in 1997

What is FPC? Just kidding marco, just kidding!

> People like it because it's so small and fast. The only downside is (of
> course) it's old and (only) 16-bit. Well, and DOS-based, but that's to be
> expected (and no other 16-bit OS lived as long or as well.)

For a living I'm a lot in factories, and often not the most hightech kind.

While most use Delphi now, I occasionally see TP apps still in departments in charge of electronic wiring and equipment, and even rarer in the (quality assurance) labs.

Often I can't be sure though, since I see a TV app, and it might be TC++ as well.

It's rare nowadays though. Since most software in such department is tied to certain equipment, I think that even the most decrepit stuff from the early nineties has been replaced mostly nowadays.

> There's probably many still using it, but I doubt many public projects
> still do (esp. with 64-bit incompatibility) except for niche uses ("gotta
> be small, fast, for DOS").

The departments I'm talking about above, probably won't encounter 64-bit till the 2020's

> The only downside is (of course) it's old and (only) 16-bit.

Well, that is what I like so much about it among other things.

Yes, I still code in BP 7.0.
I use it mainly for realmode programming. For protected mode I prefer Freepascal, although BP has some nice features which DOS version of FP does not have - mainly DLL creating. (I know, FP can use DXE modules but it has painful limitations)

---
DOS-u-akbar!

> Yes, I still code in BP 7.0.
> I use it mainly for realmode programming. For protected mode I prefer
> Freepascal, although BP has some nice features which DOS version of FP does
> not have - mainly DLL creating. (I know, FP can use DXE modules but it has
> painful limitations)

DXEs were never hugely used, not even in DJGPP. But DXE3 (2.04 beta only??) is better anyways (but not yet imported into FPC??). Otherwise, I don't know of a solution outside of maybe trying to use FPC/Win32 + HX instead or reviving the FPC/Win32 + WDOSX runtime support.

> Well, the subject says it all - I am just wondering?
Yes, for 3 main reasons: 1) My interest in software preservation. 2) I've often used Borland's various tools for no other reason than I had old code to hand. 3) I like pushing old tools in new ways for no reason other than fun, e.g. TP5_2COM and similar trickery.

Trixter still codes in Turbo Pascal, I'd highly recommend reading the following recent Trixter blog entry which I feel puts into words what a lot of people feel when it comes to why we mess around with "old" stuff: When you reach the top, keep climbing.

> ...and what happend to Jason G Burgon?
He's probably busy with work. His website is up: http://homepage.ntlworld.com/gvision/

> Yes, I still code in BP 7.0.
> I use it mainly for realmode programming. For protected mode I prefer
> Freepascal, although BP has some nice features which DOS version of FP does
> not have - mainly DLL creating. (I know, FP can use DXE modules but it has
> painful limitations)

Does DJGPP support some form of Dos DLLs? Since if DJGPP doesn't support it, there is a chance you'll have to write a linker that supports it first.

> Does DJGPP support some form of Dos DLLs? Since if DJGPP doesn't support
> it, there is a chance you'll have to write a linker that supports it first.

DJGPP also supports DXE but as I have seen dynamic linking is used very rare for DOS apps.

---
DOS gives me freedom to unlimited HW access.

> > Does DJGPP support some form of Dos DLLs? Since if DJGPP doesn't support
> > it, there is a chance you'll have to write a linker that supports it
> first.
>
> DJGPP also supports DXE but as I have seen dynamic linking is used very
> rare for DOS apps.

Clearly the OP is using Pascal, so that would moreso mean does GPC/DJGPP support DLLs. The prebuilt binaries of GPC for DJGPP are based upon GCC 3.4.4 (stable) and GCC 4.1.2 (some bugs). IIRC, both use DJGPP lib 2.03p2, which means only old (weaker) DXE1, not DXE3 from lib 2.04.

You can also try the DJELF third-party port, but I haven't messed with it barely at all. It's got true ELF .so loading (a la Linux). But it's pretty much C or C++ only (DJGPP 2.04, GCC 4.0.0, and BinUtils 2.16).

ftp://ftp.delorie.com/pub/djgpp/djelf
http://djgpp.cybermirror.org/djelf/

In particular, see readme.txt and readme2.txt if curious.

> FreeDOS KEYB is written in TP7, similarly for older (deprecated) XKEYB.
> Galactic Conquest was TP7 (few months ago), same as Paku Paku (month or two
> ago). rr's UPXDUMP was at least compatible with TP55, but I think he calls
> TP7/BP7 the "best ever" (or was it TP6? Meh, close enough).

It was (and still is) TP6.

But maybe I'm a little biased, because that's the version I started with in the 1990s. And I couldn't afford TP7 from my apprenticeship salary.

---
Forum admin

> > rr's UPXDUMP was at least compatible with TP55, but I think he calls
> > TP7/BP7 the "best ever" (or was it TP6? Meh, close enough).
>
> It was (and still is) TP6.
>
> But maybe I'm a little biased, because that's the version I started with in
> the 1990s. And I couldn't afford TP7 from my apprenticeship salary.

It's very confusing. There are too many competing versions. I assume you mean TP 6.0 Professional. How much was TP7, comparatively? You mean TP 7.01 or "Borland Pascal 7 with Objects" (DOS and Windows)? (Some old versions are still around for sale on EMSPS or eBay.)

I stumbled upon the release announcement blurb online recently but can't find it now. TP 5.5 freeware lacks Turbo Debugger 1.5 and Turbo Assembler 1.0 (one-pass only?) that were in Professional. Apparently, in 1989 dollars, that was $150 (or $250 for Pro), which is worth twice that now, due to inflation. I know TP6 added BASM for inline, so maybe that means lacking TASM 2.0 for hobby users wasn't as crucial. (Heck, just use DEBUG and Inline(...) for 5.5. Or NASM or A86, which both claim to somehow work.)

Back in 2007 or so, due to my minimal hacking on PAQ8o8, I actually downloaded Turbo C++ Explorer (not Delphi, sadly) for free. It never installed properly (some .NET mixup), plus that old laptop died, so I never properly learned C++. (C++11 and later heavily changed everything anyways.) It did come with TASM32 5.3 (Win32), which I still have. I still want to convert a few external projects to rely on Free/libre assemblers. (I wouldn't consider PSR Invaders very important, but it's still fun to think about.)

Even Delphi (celebrating 25 years) has a Community freeware edition nowadays, for up to five developers earning less than $5000/year. But FreePascal is so much better, thus I never bothered. (Yeah, you can probably use both, but I haven't. Then again, I don't know Delphi dialect(s).)

Haven't you tried FPC's i8086-msdos (ppcross8086)? I don't really understand their recent snapshot versioning (anything past 3.1.1, stuck in April 2018). I don't know what their plans are. Are they stuck migrating to Git? (GCC just finished their own migration.) Anyways, the output isn't nearly as small as TP, but it's a better compiler. The proper 3.0.x release versions are still using slow NASM + WLINK, which is still quite good but a bit slow for smartlinking (unlike newer snapshots). I can't think of any other obvious, major reason to exclusively stick to TP other than familiarity, strict compatibility, 16-bit hosting, etc. I tend to test my own wimpy code out on a variety of TP-compatible compilers, just to iron out any hidden bugs.

> > > rr's UPXDUMP was at least compatible with TP55, but I think he calls
> > > TP7/BP7 the "best ever" (or was it TP6? Meh, close enough).
> >
> > It was (and still is) TP6.
> >
> > But maybe I'm a little biased, because that's the version I started with
> in
> > the 1990s. And I couldn't afford TP7 from my apprenticeship salary.
>
> It's very confusing. There are too many competing versions. I assume you
> mean TP 6.0 Professional. How much was TP7, comparatively? You mean TP 7.01
> or "Borland Pascal 7 with Objects" (DOS and Windows)? (Some old versions
> are still around for sale on EMSPS or eBay.)

I mean TP 6.01 BHV edition: https://m.ebay.de/itm/Software-Turbo-Pascal-6-0-auf-3-Disketten-mit-Handbuch-bhv/352881771160
IIRC, it was available for either 49 or 69 DEM at that time.
(I bought full TP6 Prof. much later at eBay for only a few bucks, but never used it. I just wanted to save it from the dump.)

And I didn't want to pay another 139 (?) DEM only for syntax highlighting in TP7.

> I stumbled upon the release announcement blurb online recently but can't
> find it now. TP 5.5 freeware lacks Turbo Debugger 1.5 and Turbo Assembler
> 1.0 (one-pass only?) that were in Professional. Apparently, in 1989
> dollars, that was $150 (or $250 for Pro), which is worth twice that now,
> due to inflation. I know TP6 added BASM for inline, so maybe that means
> lacking TASM 2.0 for hobby users wasn't as crucial. (Heck, just use DEBUG
> and Inline(...) for 5.5. Or NASM or A86, which both claim to somehow
> work.)

TP6 and TP7 both didn't have TD and TASM.
At that time (around 1995?) I just made my first steps in Internet (CompuServe). I had no idea about x86 assembly, inline() or A86.

> Haven't you tried FPC's i8086-msdos (ppcross8086)?

No. I don't code very much and only very small things. Don't need an X-megabyte-large compiler. No offense, marcov.

> I can't think of any
> other obvious, major reason to exclusively stick to TP other than
> familiarity, strict compatibility, 16-bit hosting, etc.

You forgot nostalgia.

---
Forum admin

> I can't think of any
> other obvious, major reason to exclusively stick to TP other than
> familiarity, strict compatibility, 16-bit hosting, etc. I tend to test my
> own wimpy code out on a variety of TP-compatible compilers, just to iron
> out any hidden bugs.

For smaller projects is TP7 perfect. It is really ultrafast compiler and has ultrafast and stable IDE with nice debugger.

FPC is slower - the compiler itself and the IDE too. Also don't forget that we don't have any decent sound library for FPC-GO32V2.
And we don't have the crosscompilling FPC-GO32V2 host -> FPC-DOS16 target.
However I could agree that there is no reason to prefer 16-bit protected mode from BP7 over 32-bit PM from FPC.

---
DOS-u-akbar!

> For smaller projects is TP7 perfect.

But (mostly) only if you target DOS or compatibles (not Win64!), which is rare these days (no native DOS installs, usually, Win9x is long dead [2006]).

"Small" [sic] is debatable since "Large" model and 640k limit on .EXE size isn't what I'd call trivial (not to mention overlays). The cmdline compiler itself is "small" compared to many things, but I wouldn't call it trivial.

> It is really ultrafast compiler and has ultrafast and stable IDE with nice debugger.

It does less optimizations. It's also a single Pascal dialect for a single host/target architecture. It's also one-pass with a built-in linker. It can easily fit in your cpu's L1 (or maybe L2 or L3) cache.

> FPC is slower - the compiler itself and the IDE too.

PPCROSS8086.EXE (3.0.4 2017/10/07) is "only" 2 MB.

Compiling a simple (nine-file, 597 line) program on Win7 64-bit takes 4.3 secs. ("ppcross8086 inv") because it's smartlinking the "old" way. (Newer snapshots not using NASM or WLINK are faster.) Trying again takes 4.0 secs. Using "-CX-" takes only 0.5 secs. (Apparently FPC.CFG has both "-CX" and "-XX" enabled by default. Maybe only the latter is truly forcibly needed??)

What's your build environment? What's the biggest bottleneck? Memory? Disk? CPU?

Don't smartlink (-CX-) or strip (-Xs) or optimize (beyond -O1) when doing everyday, mundane development and testing. Save that for final releases.

The main (naive) suggestion would also be to run atop RAM disk and with software cache loaded.

> Also don't forget that we don't have any decent sound library for FPC-GO32V2.

Like what? Old stuff like DUMB or Allegro?? There's bound to be wrappers somewhere, but modern hardware is anathema to DOS sound, mostly.

Lacking proper sound support or documentation (or developers!) hurts more. Sound is easily one of modern DOS's weakest link. Then again, I'd say it's less crucial than almost all other things.

> And we don't have the crosscompilling FPC-GO32V2 host -> FPC-DOS16 target.

The Win32 binaries can run under Japheth's HX, so that's better than nothing, obviously.

> However I could agree that there is no reason to prefer 16-bit protected
> mode from BP7 over 32-bit PM from FPC.

Popular target architectures and target OSes lean more heavily against 286 than they did back in 1993. Even 32-bit is somewhat "long in the tooth" and ignored.

> > For smaller projects is TP7 perfect.
>
> But (mostly) only if you target DOS or compatibles (not Win64!), which is
> rare these days (no native DOS installs, usually, Win9x is long dead
> [2006]).

WTF?
We are in the forum about DOS and about DOS programming. When I will want to discuss about Win64 I will go elsewhere.
Win9x is also not dead because I have it as main OS on my desktop PC and run it few times in a week. (Warcraft3, planescape torment, hammer&sickle...)

> > Also don't forget that we don't have any decent sound library for
> FPC-GO32V2.
>
> Like what? Old stuff like DUMB or Allegro?? There's bound to be wrappers
> somewhere, but modern hardware is anathema to DOS sound, mostly.
>

Again. We are speaking about DOS. If you use it you have a proper hardware or you have a adequate emulation. So we want a support for DOS soundcards (compatible with SB/GUS/PAS on hardware or driver layer).
Support for everything else (PCI soundcards, AC97, HD audio) is amazing but it is rather a bonus - not a necessarity.

For FPC-GO32V2 we have almost nothing. The only working libraries are my ports of Miles (extremaly basic port, however used in my old project Jupir 2 and my port of "Sound System" by Crew-242

> Sound is easily one of modern DOS's weakest link. Then again, I'd say it's
> less crucial than almost all other things.

It is crucial. Because without sound you virtualy can't make any games. And DOS is rather retrogaming platform than platform for productive work.

---
DOS-u-akbar!

> Again. We are speaking about DOS. If you use it you have a proper hardware
> or you have a adequate emulation. So we want a support for DOS soundcards
> (compatible with SB/GUS/PAS on hardware or driver layer).
> Support for everything else (PCI soundcards, AC97, HD audio) is amazing but
> it is rather a bonus - not a necessarity.



> > Sound is easily one of modern DOS's weakest link. Then again, I'd say
> it's
> > less crucial than almost all other things.
>
> It is crucial. Because without sound you virtualy can't make any games. And
> DOS is rather retrogaming platform than platform for productive work.

---
Forum admin

> WTF?
> We are in the forum about DOS and about DOS programming. When I will want
> to discuss about Win64 I will go elsewhere.

Obviously. I just meant that Win64 is way more common than DOS or Win9x. You have to write for what OSes you run (and your customers/users). Setting up a FreeDOS VM isn't hard, but anything more than that is a burden to end users. Portability of code is usually more important than nostalgia or personal comfort.

> Win9x is also not dead because I have it as main OS on my desktop PC and
> run it few times in a week. (Warcraft3, planescape torment,
> hammer&sickle...)

It's no longer updated nor sold directly by MS, so it's unsupported and not directly recommended. Non-enthusiasts don't have native DOS installs anymore.

My Dell laptop from 2010, that I keep mentioning, has a diagnostics partition using DRMK (Dell Real Mode Kernel, aka barely-modified DR-DOS). But they intentionally limited that and kept it hidden and very, VERY! minimal. (probably limited for "security", ugh, God forbid they make it minimally useful for system tasks or reinstalling or analyzing anything). Without a traditional BIOS or CSM, you can't even do that anymore.

> Again. We are speaking about DOS. If you use it you have a proper hardware
> or you have a adequate emulation.

Or just don't use it for gaming. Or ignore sound.

> So we want a support for DOS soundcards
> (compatible with SB/GUS/PAS on hardware or driver layer).
> Support for everything else (PCI soundcards, AC97, HD audio) is amazing but
> it is rather a bonus - not a necessarity.

Paku Paku, Wolfenstein 3D, Doom, and Retro City Rampage DX:486 all support PC speaker. (Better than nothing, IMHO.)

> It is crucial. Because without sound you virtualy can't make any games. And
> DOS is rather retrogaming platform than platform for productive work.

DOS can do some productive work, in the right hands. Use the right tool for the job. Even OberonOS probably has a niche, for those who know what they're doing, even if only under VM.

Games are fun on generic machines sometimes, but we probably need a Raspberry Pi clone of a 586/SB16/VGA (or handheld? Chromebook/DOSbook??). Modern PCs just don't care, and VMs are better than nothing (but usually for non-gaming). I guess RPi + DOSBox works for some people?? Dunno.