DOS ain't dead

> >
> http://www.vogons.org/viewtopic.php?f=41&t=40610&sid=2f1079648ffa4dd4866ca8fa6fc92cf6),
> > and that vDOS is a fork of DOSBox, it may not be very difficult to port
> > LFN-related code from DOSBox to vDOS, so that vDOS would support LFN as
> > well, similar to a real DOS environment with DOSLFN loaded.
>
> (note that lfn mode also allows e.g. forward slashes, the use of * instead
> of *.* and several other relaxations of path rules etc)

I used to do that under MSDOS. I ran the MKS Toolkit, a package of DOS versions of pretty much all the Unix utilities that made sense in the single tasking DOS environment. The selling point for me was a remarkably complete version of the Korn shell, with everything asynchronous background processes. The Toolkit came with a SWITCH utility that let you change the DOS option delimiter char from / to - to use Unix style options. A side effect was letting you use either \ or / in path names.

Not all DOS apps could deal with it, so when I used the Korn shell, I had some wrapper functions that reset things to DOS style before running a non-conforming app, and put things back to Unix style when the app exited.

I encountered similar issues running Cygwin under Windows, as the Cygwin environment imposed *nix semantics when you were in it.

IIRC, Wang Laboratories once had an OEM version of DOS for their PCs that did things the *nix way, but I never got a chance to play with it.
______
Dennis

> I haven't looked at the DOSBOX or vDOS code yet, but it sounds like your patch might be applicable. If you do it, please let me know.

I have examined the source code a bit. Indeed, my LFN patch for DOSBox is applicable to vDOS to some degree. But there are also differences between the source code of current versions of DOSBox and vDOS. One reason for the difference is that vDOS was probably not forked from the (SVN) version of DOSBox that my patch was based on, and the other reason is that the vDOS author had changed the structure of the source code a bit since the fork. Yet, it should be considered doable. To show this, I have uploaded a demo of vDOS build with some LFN support, which I added earlier today. It should however only be considered as a proof-of-concept build rather than a full-featured release with LFN support. Now DIR should list long file names, but other commands probably won't work with LFN yet. LFN support can also be turned off by setting LFN=OFF in CONFIG.TXT (it is turned on by default). I will only work on it further when I have time. Thanks for your understanding.

Download link for this demo (EXE + required DLLs, zipped):

http://sourceforge.net/p/vdos/discussion/general/thread/44116b8c/19e5/167e/attachment/vdos.zip

EDIT:

Latest version with all required DLLs, zipped:

http://sourceforge.net/p/vdos/discussion/general/thread/44116b8c/92ec/attachment/vdos.zip

> > However, given that I have actually added long file name
> > support to DOSBox myself last month (see post at:
> >
> http://www.vogons.org/viewtopic.php?f=41&t=40610&sid=2f1079648ffa4dd4866ca8fa6fc92cf6),
>
> Nice! :) An optional LFN support for Dosbox would be really great. At least
> it would allow runing files with LFN (often found in Freedos ftp
> directories) without the name change. I usually set up a right click menu
> option to run dosbox on a specific file, but that doesn't work on files
> with LFNs.

Thanks for your comment. I have added LFN listing capability to vDOS's DIR command today, and this (i.e. LFN support) can be turned off in CONFIG.TXT too. I will add similar functionality (i.e. the option to turn LFN on/off) to DOSBox as well.

> > However, given that I have actually added long file name
> > support to DOSBox myself last month (see post at:
> >
> http://www.vogons.org/viewtopic.php?f=41&t=40610&sid=2f1079648ffa4dd4866ca8fa6fc92cf6),
>
> Nice! :) An optional LFN support for Dosbox would be really great. At least
> it would allow runing files with LFN (often found in Freedos ftp
> directories) without the name change. I usually set up a right click menu
> option to run dosbox on a specific file, but that doesn't work on files
> with LFNs.

Now I have added the ability to turn LFN on and off to the DOSBox LFN version. There is now a directive or command called "lfn" in dosbox.conf (see the [dos] section), which can be set to either true, false, or auto. When setting to "auto", LFN support will be enabled if and only if the major DOS version is set to at least 7 in the configuration file. It will now also use the actual Windows SFNs instead of generating random SFNs by itself on Windows platforms (the latter approach is used by the original or official version of DOSBox).

Download link for the binary (along with all required DLLs, zipped):

http://sourceforge.net/p/vdos/discussion/general/t...4116b8c/9be1/db1e/18e0/attachment/dosboxlfn.zip

Enjoy it!

> Any indication of why it crashed? (Offhand, I'd guess memory allocation
> issues.)


Hi Dennis! I have checked its source code. No, it is not because of memory allocation issues which led to its crash, but because that vDOS has removed some codes that originally existed in the source code of DOSBox (remember that vDOS is a fork of DOSBox), so that the code that handles this part of the JMP instruction no long exists in vDOS (that is why it works in DOSBox but not in vDOS). To fix it, we need to restore that piece of code in DOSBox back to vDOS.

> > The license should be included with the sources too. Including maybe the
> > other docs.
>
> Not _should be_, but rather _must be_.
>

Sorry, not a native speaker, so the difference was not clear with me. But, that was what I meant to say. Thanx.

> It's a real crying shame when folks don't "get it".
>

I got a bit angry over it in my last post. But not only because of the license. He also didn't credit the original authors. That's not only illegal (if the license can be held on court - and it did in several occasions), but also totaly disrespectful.

Hey, the project even looks like a good idea. Just follow the license and be respectful to the authors. I guess he didn't mean to do that intentionally, but still. The text of the license is pretty clear.

Anyway, sorry for the rant. But, I think it's not out of place.

> > And I've encountered a weird vDOS quirk.
> >
> > One of the DOS apps I still have and use on occasion is an editor called
> G,
> > by Jeremy Hall in the UK, dating from 1995.
>
> Yes, I've seen it before but only tried it once or twice. Despite lacking
> some (irrelevant) features, I still stick to TDE.

I'm mostly fascinated by the design. One of the questions in implementing an editor is how you store text to be edited in memory. Current practice seems to be variants on the "buffer gap" technique. Hall uses a different method he outlined on on comp,editors: https://groups.google.com/forum/?fromgroups#!searc...my$20hall/comp.editors/Br_yX8QXwgE/cNJa2Ltuyc0J

> > It uses the WordStar command set, and has an interesting design
> > where it can be used as a full screen editor, or used as a filter
> > in a pipe.
>
> You mean like "uname -a | vile" or "echo hello | tde"?

Something like that. The editor core can be called as a program and used non-interactively, a bit like Unix sed.

> > G is portable, with C source available, and Hall mentions it working on
> > Solaris. The only executable I've found is a DOS version.
>
> Back in 1995, Linux wasn't even using ELF yet! Plus presumably they were
> stuck with GCC 2.7.2 (or even older like 2.6.3). DJGPP 2.0 wasn't finalized
> yet either, nor was Quake. GCC didn't even get 586 support until 1998.
>
> I only mention that because you mention (below) about failing to compile on
> Linux, which shows similar (two) errors here (Lucid Puppy circa 2010, GCC
> 4.4.3). The source says he tested on "Linux 1.2.8" [sic].

I didn't try hard. It was mostly a "try it, and see where it dies horribly". exercise.

> > I like an 80 column screen with 50 lines, so my vDOS config.txt file has
> > COLS = 80 and LINS = 50. I installed the FreeDOS mode command, and it
> > reports I have an 80 column, 50 line screen in mode 3.
> >
> > G invokes as though the screen was 25 lines regardless of what I do, so
> > I get a 50 line screen where the top 25 lines are G and the rest is
> > unused.
> >
> > There's no place in G to set the screen size - it relies on what the OS
> > tells it. It works as desired in an NTVDM window under WinXP, and uses
> > the full defined 50 lines of the screen. I doesn't work under vDOS, and I
> > haven't been able to get it to work as desired in DOSBOX either.
>
> So ... just use NTVDM? Don't use DOSBox or vDOS? Just use real FreeDOS
> (native or under VirtualBox or QEMU)?

NTVDM doesn't exist in 64 bit Win 7. It's far more trouble than it's worth to use Virtual Box or Qemu just for this. (Or MS's own VM with an XP image, for that matter.)

I can run it as expected on the netbook under XP Home. It runs under vDOS on Win7, but only in an 80x25 screen.

> > This is hardly a pressing issue, and if it doesn't work, it doesn't
> > work, but I'd love to know what's going on and why it's failing in vDOS.
>
> It's failing because vDOS isn't a "real" DOS. Obviously.

vDOS successfully runs things like VDE, WS7, and Word for DOS 5 in a 50 line screen. G is the only problem child.

> BTW, it seems to work fine for me under DOSEMU + FreeDOS.

Right now that's more trouble than I feel like taking.

> > I took a quick try at building the C source under Linux and failed.
> > Have to take a shot under Windows and see what happens.)
>
> There's only three files: README, G.C, and (optional) CRT0.ASM , so
> (famous last words) it shouldn't be that hard to recompile.

"that hard" is relative...

> Problem #1: G471SRC.ZIP is using an old compression method ("Implode"),
> although Info-Zip still supports it. More crucial is the fact that he
> probably used PKZIP, which (at least DOS version) always capitalizes the
> filenames (bad!). So "G.C" [sic] is the source, which GCC thinks is C++ !!
> (Actually, you have to first not use "-m486" because that was removed a
> while ago, 4.3.0, IIRC.)

Extracts fine here using 7-Zip.

<...>

> So you can either "unzip -L" first or manually rename or just add "-x c" to
> tell it to use plain C89. I also added "-w" (no warnings) to shut up some
> irrelevant stuff. The problem seems to be exclusively inside the
> "Disk_to_mem()" function (lines 4019-93).

Okay.

> BTW, I'm not *nix savvy at all (in case that wasn't obvious). So I have no
> clue what "caddr_t" is or how to use "mmap()" correctly. I did hack at it
> to compile, and it seemed to work okay, but I might've done it wrong. It's
> a bit weird to read because of the various #ifdef stuff in there (DOS,
> UNIX). Honestly, I would email somebody who knows this stuff, probably
> Ncurses maintainer (Thomas Dickey), to see what is going on. Though keep in
> mind he'll probably just tell you to use VILE instead (which does helpfully
> hop around #ifdef with '%' key).

I have Vile here.

I'd *like* to drop a note to Hall, but the email address he posted is no longer valid, and while Google searching returns an assortment of Jeremy Halls, none of them appear to be the G author.

<...>

> Patch follows (but beware, you need hard tabs in the makefile).

I'll look at it at some other point. But if you were able to produce a binary that appears to work on Linux, can you zip it and send it to me? dennis dot mccunney at gmail dot com reaches me. I'll see what it does under Ubuntu.
______
Dennis

> There's only three files: README, G.C, and (optional) CRT0.ASM , so
> (famous last words) it shouldn't be that hard to recompile.
>
> Problem #1: G471SRC.ZIP is using an old compression method ("Implode"),
> although Info-Zip still supports it. More crucial is the fact that he
> probably used PKZIP, which (at least DOS version) always capitalizes the
> filenames (bad!). So "G.C" [sic] is the source, which GCC thinks is C++ !!

or you can do (bash specific, can be done portably with tr):
for file in *;do mv $file ${file,,};done

This will renam everythinge to lowercase.

> BTW, I'm not *nix savvy at all (in case that wasn't obvious). So I have no
> clue what "caddr_t" is or how to use "mmap()" correctly. I did hack at it
> to compile, and it seemed to work okay, but I might've done it wrong. It's
> a bit weird to read because of the various #ifdef stuff in there (DOS,
> UNIX). Honestly, I would email somebody who knows this stuff, probably
> Ncurses maintainer (Thomas Dickey), to see what is going on. Though keep in
> mind he'll probably just tell you to use VILE instead (which does helpfully
> hop around #ifdef with '%' key).
>
> So I'm assuming he used mmap() for speed. I'm also assuming that the DOS
> version is a fallback of a simpler way of doing things. So I assume that
> will still work on Linux. So, inside Disk_to_mem(), I changed "#if DOS" to
> "#if 1" and "#if UNIX" to "#if 0". Then the only problem is that O_BINARY
> is undeclared, but they don't need or use that on *nix, so comment that
> out.
>
> Then, it compiles okay for me. "echo $LINES" under ROXTerm here says "34"
> (although I don't remember how, when, why, or if I set that manually). So
> that's more than 25, right? So my limited testing should be acceptable
> here. Okay, it runs, everything is green on black, and typing "4030" jumps
> to that line. Down arrow brings me to the main text, and it seems to show
> lines 4030 through 4060. So I guess it works.
>
> Patch follows (but beware, you need hard tabs in the makefile).
>
>
> diff -waNBU0 old/G.C new/G.C
> --- old/G.C       2015-01-07 14:21:32.000000000 -0600
> +++ new/G.C        2015-01-07 14:23:25.000000000 -0600
> @@ -4023 +4023 @@
> -#if DOS
> +#if 1 //DOS
> @@ -4028 +4028 @@
> -#if UNIX
> +#if 0 //UNIX
> @@ -4043,2 +4043,2 @@
> -#if DOS
> -    setmode( fd, O_BINARY );
> +#if 1 //DOS
> +    //setmode( fd, O_BINARY );
> @@ -4070 +4070 @@
> -#if UNIX
> +#if 0 //UNIX
> diff -waNBU0 old/GNUmakefile new/GNUmakefile
> --- old/GNUmakefile      1969-12-31 18:00:00.000000000 -0600
> +++ new/GNUmakefile        2015-01-07 14:24:33.000000000 -0600
> @@ -0,0 +1,7 @@
> +CC     = gcc
> +CFLAGS = -O2 -s -lncurses -w -x c
> +
> +g: G.C
> +  $(CC) $(CFLAGS) $< -o $@
> +  ls -l $@
> +     ldd $@
>

Or you can just do this:
#ifndef caddr_t
#define caddr_t char*
#endif


Credits to: http://computer-programming-forum.com/47-c-language/556a90938d01f023.htm