DOS ain't dead

One of the things I've done under Linux is to use DOSBOX to run DOS apps. DOSBOX is intended for running old DOS games, but my usage is character mode apps. (And there's a DOSBOX port to Android. It's a tickle to get some old DOS apps running on my 7" Android 4.2 Jellybean tablet.)

vDOS is a fork of DOSBOX intended to run DOS business applications. (The author explicitly says that if you want to run games, use DOSBOX.) It's not cross-platform, and specific to current 64 bit Windows platforms. It comes with a demo app based on WPCorp's old DataPerfect DB program for DOS. I found out about it on a WordStar mailing list as a way to get classic WordStar to run on a current machine.

Usage is simple enough. Install it where you like. (In my case, that's D:\MSDOS\vDOS.) Create a desktop shortcut. Right-click the icon and select Properties. In Properties, make Start In: the directory where the DOS app you want to run is located.

vDOS uses the files AUTOEXEC.TXT and CONFIG.TXT to control configuration. Copy them to the directory where the DOS app is, and edit appropriately. The same files contain possible options, REMmed out, with comments on what they do. UnREM the ones you want active.

The main new command in vDOS is USE. It's the equivalent of SUBST under DOS. You use it to associate drive letters in vDOS to directories on your hard drive. The default action is to map C: to the directory vDOS starts in. That means vDOS can only see that directory, so you may wish to change it.

The main limitation is that vDOS only understands and shows DOS 8+3 filenames. Long file names will not appear in a vDOS directory and operations on them aren't possible.

I use the following to run Eric Meyer's VDE WordStar clone (https://sites.google.com/site/vdeeditor/Home):

CONFIG.TXT

rem Config.txt for VDE
rem vDOS can convert XMS to EMS. I don't, here.
rem EMS = ON
rem Default conventional memory is 575KB. This adds another 64KB.
rem Not strictly needed for VDE.
LOW = ON
rem vDOS can use a TrueType font in the app directory as default font.
rem I use Lucida Console.
FONT = LUCON
rem By default, vDOS runs in a borderless window. I want the borders.
FRAME = ON
rem By default, the vDOS window is 75% of the physical screen.
re On my 23" monitor in 1920x180 resolution, 20% is a better size
WINDOW = 20
rem I want a 50 line and 80 column screen
LINS = 50
COLS = 80
rem config.txt ends

AUTOEXEC.TXT

@ECHO ON
rem autoexec.txt for VDE
USE C: C:\
USE D: D:\
rem Various DOS utils live in D:MSDOS\bin
set PATH=d:\msdos\bin
D:
cd \MSDOS\VDE
vde.exe
rem EXIT
rem autoexec.txt ends

And these run 4DOS 8.0:

rem config.txt for 4DOS
LOW = ON
MOUSE = ON
FRAME = ON
WINDOW = 20
LINS = 50
COLS = 80
rem config.txt ends

AUTOEXEC.TXT

@ECHO ON
rem AUTOEXEC for 4DOS
use c: c:\
use d: d:\
rem vDOS creates a virtual drive Z:, containing a 0 byte entry for COMMAND.COM
rem I have an actual drive Z: (a ramdisk) so I map it to X:
use x: z:\
PATH D:\msdos\4DOS;D:\msdos\bin
set COMSPEC=d:\4dos\4dos.com
rem ctload is an old Creative Labs utility to load device drivers from the
rem command line. vDOS doesn't support DEVICE=<driver> so this is a possible
rem work-around. Still experimenting with what will work.
rem ctload
rem 704K maps 64K of DOS video RAM to conventional memory. It appears to work.
704k.com
rem vDOS does support loadhigh, so I load an ANSI driver
loadhigh nnansi.com
D:
cd \msdos\4dos
4dos
rem EXIT

So far, vDOS has run everything I've tried. The big issue is that it needs to be better documented, and a fair amount of "Does this work?" "Crap. No. Let's try this..." fiddling is required. I'd also love to see long file name support. (I haven't been able to get an LFN driver to load.)

A plus for vDOS is print support. It comes with a shareware app called DOSprint that runs in Windows and lets DOS apps print via Windows. But it also supports virtual COM ports 1-9 and LPT 1-4. You can specify them, and state what action is taken when the port is opened. For an old character mode DOS game that can print a game map, I use LPT1 = notepad2 #lpt1.asc to generate the map as the file #lpt1.asc, and view it in notepad2.

Fun, for suitable values of the term.
______
Dennis

...

> I'd also love to see long file name support. (I haven't been able to get an LFN driver to load.)

Thanks for your post. Regarding long file name (LFN) support, it is for sure that LFN drivers like DOSLFN won't load in DOSBox or vDOS, since they are not real DOS environments and also prevent direct disk access. Sadly, it also seems that the vDOS author (josschaars) is not willing to add LFN support at all. 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), 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.

> 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 tried to run gcc/djgpp under vdos (just gcc -v) and it crashed an closed the emulator. Under dosbox it works (I tried some months before).

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

> I tried to run gcc/djgpp under vdos (just gcc -v) and it crashed an closed
> the emulator. Under dosbox it works (I tried some months before).

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

I'm not sure I'd care. Under 64 bit Win 7 Pro (which is where vDOS is installed on my machine,) I'd just run the MinGW flavor of GCC "native". I have no particular reason to use the DJGPP port. It's working fine here to run existing DOS apps, which is my reason for having it.

It's curious that it does work under DOSBOX. I also wonder what might happen if the DJGPP port of gcc was used in an NTVDM emulation under 32 bit Windows.
______
Dennis

> 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.

Yes, there was some message about JMP...

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

> ...
>
> > I'd also love to see long file name support. (I haven't been able to get
> an LFN driver to load.)
>
> Thanks for your post. Regarding long file name (LFN) support, it is for
> sure that LFN drivers like DOSLFN won't load in DOSBox or vDOS, since they
> are not real DOS environments and also prevent direct disk access.

DOSBOX and vDOS do support TSRs. I was looking for an LFN driver that could be loaded that way, since CONFIG.SYS DEVICE=foo operations aren't supported.

> Sadly,
> it also seems that the vDOS author (josschaars) is not willing to add LFN
> support at all. 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),
> 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.

I'd be delighted to get a version of vDOS that did have LFN support. Josschaars seems to feel that if it wasn't present in real DOS, he won't add it to vDOS. Given that vDOS is intended to allow use of DOS apps on 64 bit Windows platforms, a little more support for the underlying platform like ability use use LFNs would be a boon.

One of the things I have installed in Windows is Schinagl's freeware Link File Extension. NTFS5 supports Unix hard links and symlinks, though the functionality isn't exposed by default. LFE adds context menu support in Windows Explorer for choosing a link source, and creating a hard link or symlink to it. I could probably create symlinks in DOS 8+3 file name format to desired files with long names, but that's more trouble than I want to go through unless I have no other choice.

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.
______
Dennis

> >
> 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

> > 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.

I'd call that a vDOS bug. If you remove code that handles something, you should fail gracefully with an "unsupported operation" message if something tries to do that. You shouldn't crash and terminate the emulator.
______
Dennis

> 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.

This sounds interesting.

> vDOS is a fork of
> DOSBOX intended to run DOS business applications. (The author explicitly
> says that if you want to run games, use DOSBOX.) It's not cross-platform,
> and specific to current 64 bit Windows platforms.
>

I looked into the sources. He stripped all the licensing info which is against the license that Dosbox uses (GPL v2 I think). Comment headers are necessary for abiding the original license. Also, a copy of license HAS to go with the software. This way he stripped the names of all the people that worked on Dosbox before.

On the other side, sources seem to be well organized and really readable. So, that's the plus point if he fixes the licensing issues.

Anyway I didn't see much of Windows specific stuff. Messagebox here and there. Even the printing code uses external programs like ghostscript. It might be still portable with a few changes.

Edit

The binary distribution seems to have the license file. But still, that's not enough to abide the license itself:

> To do so, attach the following notices to the program. It is safest to attach them to the start of
> each source file to most effectively convey the exclusion of warranty; and each file should
> have at least the "copyright" line and a pointer to where the full notice is found.
> one line to give the program's name and

So, the sources have to have at least the "copyright line" included.

The readme file contains something like:

> vDos is provided 'as-is', without any express or implied warranty. In no event can the author be held
> liable for any damages arising from the use of this software.
> Permission is granted to anyone to use this software for any purpose, including commercial
> applications.
> To alter it and redistribute your own version is subject to the following restrictions:
> ? The origin of this software (DOSBox/vDos) must not be misrepresented; you must not claim that
> you wrote the original software.
> ? You must make available all files needed to compile it into your version.

That actually is a GPL retold in a few sentences, but that's not enough by itself. He should've point the reader to license.pdf too.

Also he omittes the names of the original authors. Who made DOSBox? The names?

The license should be included with the sources too. Including maybe the other docs.

> The license should be included with the sources too. Including maybe the
> other docs.

Not _should be_, but rather _must be_.

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

---
--
http://glennmcc.org/

> 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.

> > 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.

> > 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.

My guess was that the area your patch might apply to would be be largely the same in DOSBOX and vDOS, and not one of the places vDOS diverged significantly.

> 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.

Okay. No surprise.

> 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.

Thank you. I've copied it over vDOS.exe and I'm playing with it. Seems to work. Understood on time. If you get the chance to do more that's wonderful, but real life takes precedence.
______
Dennis

I just had to back off on a new vDOS release. vDOS released Version 2014.10.17 yesterday. Changes are detailed in http://goo.gl/04W0Hq

One of the things I run with vDOS is an ancient DOS port of Unix Larn, a D&D style game similar to Nethack. It draws a map using ASCII characters. By default, movement commands use vi style hjkl keystrokes, but keypad arrow keys are optionally supported. It needs an ANSI driver, and requires a TERMCAP entry.

I had to change the TERMCAP file for the earlier release. I load Tom Almy's nnansi.com as the ANSI driver. Like Dan Kegel's NANSI.SYS on which it's based, nnansi adds support for VT-102 add line and delete line sequences which aren't in DOS ANSI.SYS. I had to remove those entries from TERMCAP because vDOS wasn't correctly handling them, and messages weren't properly appearing on the status line.

The new version hoses cursor movement. The cursor stays on the bottom line of the screen and cannot move up and down. It doesn't matter whether vi movement commands or cursor keys are used. It worked correctly in the previous version and neither nnansi nor TERMCAP were changed.

The change log talks about simplifying video routines a bit, but I suspect they've been simplified too much.
______
Dennis

> > (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.
I was not talking about the shell, I was talking aboutu the INT 7xh API vs the old versions

> > 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!

> > > (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.
> I was not talking about the shell, I was talking aboutu the INT 7xh API vs
> the old versions

I will take care of this part later. Now I think it would be very useful to add the mouse copy/paste capability to DOSBox at the moment, after a discussion with another user.

Hey, thanx. But I don't use Windows (or very rarely). Is the code crossplatform and could you upload the source or the patch somewhere?

> Hey, thanx. But I don't use Windows (or very rarely). Is the code
> crossplatform and could you upload the source or the patch somewhere?

You can download the patches from the DOSBox Patches forum (see my threads with titles "Long File Name support" and "Mouse copy/paste support"):

http://www.vogons.org/viewforum.php?f=41

> Hey, thanx. But I don't use Windows (or very rarely). Is the code
> crossplatform and could you upload the source or the patch somewhere?

Just to mention that it is indeed cross-platform after confirming it by myself. I have already tested it in Windows, Linux, and MacOS X by myself, and have confirmed that it works on all of these systems (for mouse copy/paste feature, the pdcurses library will be required for cross-platform clipboard support).

> Just to mention that it is indeed cross-platform after confirming it by
> myself. I have already tested it in Windows, Linux, and MacOS X by myself,
> and have confirmed that it works on all of these systems (for mouse
> copy/paste feature, the pdcurses library will be required for
> cross-platform clipboard support).

Thanx! Haven't had time to check it out yet, though.

> > Hey, thanx. But I don't use Windows (or very rarely). Is the code
> > crossplatform and could you upload the source or the patch somewhere?
>
> Just to mention that it is indeed cross-platform after confirming it by
> myself. I have already tested it in Windows, Linux, and MacOS X by myself,
> and have confirmed that it works on all of these systems (for mouse
> copy/paste feature, the pdcurses library will be required for
> cross-platform clipboard support).

Haven't had luck with this. GNU patch didn't like your patch. Haven't yet tried manually changing the files. Or trying to figure out why gpatch doesn't work.

What diff utility are you using?

Btw, thanx for the great work. I've been aware of your Dosbox patches for years.

> > > Hey, thanx. But I don't use Windows (or very rarely). Is the code
> > > crossplatform and could you upload the source or the patch somewhere?
> >
> > Just to mention that it is indeed cross-platform after confirming it by
> > myself. I have already tested it in Windows, Linux, and MacOS X by
> myself,
> > and have confirmed that it works on all of these systems (for mouse
> > copy/paste feature, the pdcurses library will be required for
> > cross-platform clipboard support).
>
> Haven't had luck with this. GNU patch didn't like your patch. Haven't yet
> tried manually changing the files. Or trying to figure out why gpatch
> doesn't work.
>
> What diff utility are you using?
>
> Btw, thanx for the great work. I've been aware of your Dosbox patches for
> years.

How about try this zip package containing all C++ source files that have been changed from the latest official DOSBox SVN version (r3871):

http://bit.ly/1umlc4J

> > > > Hey, thanx. But I don't use Windows (or very rarely). Is the
> code
> > > > crossplatform and could you upload the source or the patch
> somewhere?
> > >
> > > Just to mention that it is indeed cross-platform after confirming it
> by
> > > myself. I have already tested it in Windows, Linux, and MacOS X by
> > myself,
> > > and have confirmed that it works on all of these systems (for mouse
> > > copy/paste feature, the pdcurses library will be required for
> > > cross-platform clipboard support).
> >
> > Haven't had luck with this. GNU patch didn't like your patch. Haven't
> yet
> > tried manually changing the files. Or trying to figure out why gpatch
> > doesn't work.
> >
> > What diff utility are you using?
> >
> > Btw, thanx for the great work. I've been aware of your Dosbox patches
> for
> > years.
>
> How about try this zip package containing all C++ source files that have
> been changed from the latest official DOSBox SVN version (r3871):
>
> http://bit.ly/1umlc4J

It compiles but it's buggy. Right click mouse select works, but the text doesn't get transfered to the clipboard. Also, DosBox's "dir" command shows lfns, but file names seem to be case sensitive when using cd. Doszip commander crashes after trying to navigate out of the directory where it was started.

I linked it with SDL port of PDCurses as I supposed that what you did (had to edit a makefile or two to add the appropriate LDFLAGS).

Have you tried compiling it on any Linux? Did you have any success?

> It compiles but it's buggy. Right click mouse select works, but the text
> doesn't get transfered to the clipboard. Also, DosBox's "dir" command shows
> lfns, but file names seem to be case sensitive when using cd. Doszip
> commander crashes after trying to navigate out of the directory where it
> was started.
>
> I linked it with SDL port of PDCurses as I supposed that what you did (had
> to edit a makefile or two to add the appropriate LDFLAGS).
>
> Have you tried compiling it on any Linux? Did you have any success?

I did compile and run it in Fedora 20 within VMware Workstation 10. The only problem I found so far is that with SDL port of PDCurses the copy/paste only works inside DOSBox, but not outside DOSBox, since the "clipboard" it uses is independent of the Linux or X11 clipboard. The Windows port of PDCurses does not have this problem however (I also found a solution for MacOS X system too). Have you tried the X11 port of PDCurses?

Apart from the above known issue, I have not been able to reproduce the other problems that you described. I have confirmed during my testing that DOSBox's CD command is case insensitive even running in Linux. Also Doszip commander (3.31) did not crash after trying to navigate out of the directory where it started in my testing. Maybe some source files used in your compilation are incorrect?

>
> How about try this zip package containing all C++ source files that have
> been changed from the latest official DOSBox SVN version (r3871):
>
> http://bit.ly/1umlc4J

srcchanges.zip

This is an interesting .ZIP file
May I ask how you made it?

The reason I ask is because the central directory uses backslashes

src\dos\drives.cpp
the norm would be
src/dos/drives.cpp

Doszip versions up to 2.24 handle this but not later versions

> >
> > How about try this zip package containing all C++ source files that have
> > been changed from the latest official DOSBox SVN version (r3871):
> >
> > http://bit.ly/1umlc4J
>
> srcchanges.zip
>
> This is an interesting .ZIP file
> May I ask how you made it?
>
> The reason I ask is because the central directory uses backslashes
>
> src\dos\drives.cpp
> the norm would be
> src/dos/drives.cpp
>
> Doszip versions up to 2.24 handle this but not later versions

I created it with Info-Zip's Zip 3.0 in Windows. It is the latest version of its Zip tool I think. Utilities like WinRAR have no problem extracting the files, so I had not even noticed this before you mentioned it.

> I did compile and run it in Fedora 20 within VMware Workstation 10. The
> only problem I found so far is that with SDL port of PDCurses the
> copy/paste only works inside DOSBox, but not outside DOSBox, since the
> "clipboard" it uses is independent of the Linux or X11 clipboard. The
> Windows port of PDCurses does not have this problem however (I also found a
> solution for MacOS X system too). Have you tried the X11 port of PDCurses?
>

I tried that first. It didn't work.

> Apart from the above known issue, I have not been able to reproduce the
> other problems that you described. I have confirmed during my testing that
> DOSBox's CD command is case insensitive even running in Linux. Also Doszip
> commander (3.31) did not crash after trying to navigate out of the
> directory where it started in my testing. Maybe some source files used in
> your compilation are incorrect?

I used the files from the srcchanges.zip archive... I recreated it at least twice. So I would think not.

Sorry, I forgot to mention I was building on 64-bit Linux. I can try building on 32-bit Linux.

Or maybe I could take a look at Fedora srpm .spec file to see if they apply any patches to their pdcurses build.

> I created it with Info-Zip's Zip 3.0 in Windows.

Since using backslashes is in violation of PKWARE's appnote I find this to be a bit strange. However, it appears that there is a bug in older versions of WinZip:

http://www.info-zip.org/FAQ.html#backslashes

older versions of WinZip (and, no doubt, some other clone zippers) stored filenames using backslashes as directory separators in violation of PKWARE's appnote, which specifies that forward slashes ('/') should be used. Newer versions of WinZip correct that bug, so if you created the archive in question, you should upgrade. If someone else did, you should ask them to upgrade.

Giving this be the case Doszip should (again) be able to handle these files.

Haven't had time to look into it again. Just to let you know it's still on my todo list. :)

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. 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.

G is portable, with C source available, and Hall mentions it working on Solaris. The only executable I've found is a DOS version.

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.

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.

G for DOS is here http://cdn.simtel.net/pub/simtel/00/04/46/18/g471exe.zip and C source is here http://cdn.simtel.net/pub/simtel/00/04/46/19/g471src.zip if someone else wants to poke at it. The G manual is online here http://texteditors.org/cgi-bin/wiki.pl?G_Manual

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.)
______
Dennis

> 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.

> 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"?

> 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 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)?

> 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.

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

> G for DOS is here http://cdn.simtel.net/pub/simtel/00/04/46/18/g471exe.zip
> and C source is here
> http://cdn.simtel.net/pub/simtel/00/04/46/19/g471src.zip if someone else
> wants to poke at it. The G manual is online here
> http://texteditors.org/cgi-bin/wiki.pl?G_Manual
>
> 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.

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.)


(Wed Jan 07, 02:17 PM) /tmp/doydoy/g # gcc -O2 -m486 -s G.C -o g -lncurses -w
cc1plus: error: unrecognized command line option "-m486"
(Wed Jan 07, 02:17 PM) /tmp/doydoy/g # gcc -O2 -s G.C -o g -lncurses -w 2>&1 | wc
    151    1347   10401
(Wed Jan 07, 02:17 PM) /tmp/doydoy/g # gcc -O2 -s -x c G.C -o g -lncurses -w   
G.C: In function 'Disk_to_mem':
G.C:4030: error: 'caddr_t' undeclared (first use in this function)
G.C:4030: error: (Each undeclared identifier is reported only once
G.C:4030: error: for each function it appears in.)
G.C:4030: error: expected ';' before 'f_p'
G.C:4072: error: 'f_p' undeclared (first use in this function)


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).

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 $@


> > 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

Just for edification, it's not DOS that controls the size of the screen, it's the video BIOS. vDOS apparently has a "funky" virtual BIOS that isn't as compatible as it should be.

> Just for edification, it's not DOS that controls the size of the screen,
> it's the video BIOS. vDOS apparently has a "funky" virtual BIOS that isn't
> as compatible as it should be.

I'm aware of that. The weirdness is that vDOS will let me specify it in config.txt and DOS utilities like FreeDOS mode report I have an 80 column x 50 row screen, and everything *else* I run in DOS that can use a 50 column screen does. G is the only problem child. I'm not sure what it's not seeing that has it confused. The DOS version (built with Watcom C) may be using a BIOS call vDOS doesn't support. I haven't scrutinized the source to see what it's doing.
______
Dennis

> The DOS version (built with Watcom C) may be
> using a BIOS call vDOS doesn't support.

I think there's not much ways how to call videobios for setting the mode. So if other programs can set this 80x50 mode properly then I rather guess that G is not calling videobios at all.

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

> > The DOS version (built with Watcom C) may be
> > using a BIOS call vDOS doesn't support.
>
> I think there's not much ways how to call videobios for setting the mode.
> So if other programs can set this 80x50 mode properly then I rather guess
> that G is not calling videobios at all.

Entirely possible. The DOS executable is built with Watcom C, and there's what appears to be a Watcom specific ASM module included in the source for DOS builds. It's the CRT unit, so I assume it's where DOS screen size is set. I have to look at it and see what it does.

As mentioned upthread, G behaves as desired in an NTVDM session under XP, so NTVDFM is doing something vDOS isn't.
______
Dennis

> 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.)

Admittedly, they're Linux-oriented, but you can still download Windows binaries of QEMU from http://qemu.weilnetz.de/ . I've used it lately, it works pretty good, and it can share host/guest files easily.

> > BTW, it seems to work fine for me under DOSEMU + FreeDOS.
>
> Right now that's more trouble than I feel like taking.

DOSEMU is not hard to install, even if your distro doesn't officially support it. You can even grab precompiled binaries from http://www.dosemu.org/stable/ .

> > 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 XPimage, for that matter.)
>
> Admittedly, they're Linux-oriented, but you can still download Windows
> binaries of QEMU from http://qemu.weilnetz.de/ . I've used it lately, it
> works pretty good, and it can share host/guest files easily.

What part of "more trouble than it's worth" wasn't clear?

A single ancient DOS program that is mostly investigated out of curiosity is not justification for that level of effort. I have too many ways to waste time as it is.

> > > BTW, it seems to work fine for me under DOSEMU + FreeDOS.
> >
> > Right now that's more trouble than I feel like taking.
>
> DOSEMU is not hard to install, even if your distro doesn't officially
> support it. You can even grab precompiled binaries from
> http://www.dosemu.org/stable/ .

I have DOSBox under Linux, but not DOSEmu at the moment. I may look at it later.

Incidentally, the Linux binary of G you sent along seems to work, with quirks. (Thank you.) The first quirk was local - it wasn't running because it couldn't find a terminal description for XTerm. That was easy enough to fix. It was just a matter of putting a description file where it would be found by the system. The oddity is that it was necessary. A friend running a similar Linux install (Ubuntu 14.04 LTS)did not need to do it.

Now it works, but cursor keys aren't recognized, and escape sequences insert into edited text. That's likely a description file issue.
______
Dennis

> Btw, thanx for the great work. I've been aware of your Dosbox patches for
> years.

I just recently realized I mixed you up with ykhwong. Sorry. :) But I knew the name sounded familiar from a long time ago. And then I remember I saw your name at stuff and site of China DOS Union.

> 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

If you are still interested in LFN support in vDos -- just let you know that my current vDos-lfn (version 2015.11.01) has much better LFN support now than the one posted earlier in this thread. The vDos-lfn 2015.11.01 binary is available from the URL: http://bit.ly/1PtW6uC

You can read the vDos-lfn.txt file included in the package for more information.

Wengier

> > > 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.
>
> My guess was that the area your patch might apply to would be be largely
> the same in DOSBOX and vDOS, and not one of the places vDOS diverged
> significantly.
>
> > 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.
>
> Okay. No surprise.
>
> > 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.
>
> Thank you. I've copied it over vDOS.exe and I'm playing with it. Seems to
> work. Understood on time. If you get the chance to do more that's
> wonderful, but real life takes precedence.
> ______
> Dennis