Running VDE under 64 bit Windows

[dmccunney]

SF writer Robert Sawyer is an old time WordStar user, and has a paean
of praise to it on his website: http://sfwriter.com/wordstar.htm

Rob still uses WordStar, and popped up on the WordStar list with a
pointer to a new way to run WS on current 64 bit machines, using a
product called vDOS.

vDOS is a fork of an open source product called DOSBOX. DOSBOX is
intended to let users run old DOS games, with support for graphics and
sound. (I've successfully used DOSBOX to run VDE under Linux.) vDOS
is being developed to run character mode business applications, and
comes with a test app using a version of the old DataPerfect DB
offered by the folks who created WordPerfect. It works just fine with
VDE. Unlike DOSBOX, vDOS is not currently cross-platform. It is
intended to run DOS apps under 64 bit Windows.

To use it, you install it where you like, since it's self contained
and doesn't need an installer. In my case, it's in D:\vDOS. To use
it, you create shortcuts for it for the DOS apps you want to run. For
each shortcut, you modify the Properties to Start In the directory
where you have the DOS app.

vDOS comes with sample AUTOEXEC.TXT and CONFIG.TXT files. These serve
the same purpose as AUTOEXEC.BAT and CONFIG.SYS under DOS. Copy them
to the directory where the DOS app you want to run with vDOS lives,
and edit them as required. vDOS will read them on start and configure
itself. You can have multiple instances of vDOS active running
different DOS apps, and each will have its own custom configuration.
vDOS comes with sample AUTOEXEC and CONFIG files with documentation of
the various options in them you can set.

I keep the DOS apps I'm doing this with in D:\MSDOS, so the vDOS
shortcut for VDE has Start In: D:\MSDOS\VDE

AUTOEXEC.TXT looks like this:

@ECHO OFF
rem Assign app directory as drive, similar to MSDOS SUBST command
USE D:\MSDOS\VDE
D:
vde.exe
EXIT

CONFIG.TXT looks like this:

REM Configuration for VDE

rem vDOS can use a TTF font copied from Windows the the app directory
rem I'm playing with Lucida Console
rem FONT = LUCON

rem By default, v DOS creates a borderless window. I prefer the
border to be present
FRAME = ON

rem By default, vDOS creates a window 75% the size of the device screen.
rem On my 23" moinitor in 1920x180 resolution, 20% is a better size.
WINDOW = 20

rem Use a 50 line screen with 80 columns.
LINS = 50
COLS = 80

vDOS includes and uses by default a shareware program to handle
printing called DOSprinter. DOSprinter has a variety of options,
including generating a PDF. You don't have to use it. vDOS supports
configuring a COM or LPT port as the default printer, and assigning an
action to that port. For a game I play under vDOS that can generate a
map, I use "LPT1 = notepad2 #lpt1.asc" as the command issued when I
tell it to print. The map is generated in the program directory as
lpt1.asc, and notepad2 is invoked to display it.

This process isn't documented as well as it might be, and I had to
experiment a little, but it should be possible to use a printer
without requiring DOSprint by an appropriate configuration of a COM or
LPT port.

The attached screenshot is VDE 1.96a editing the vde196a.new file, in
a Window on my 64 bit machine running Windows 7 Pro.

There are limits - I've been unable to use VDE to edit the VDE.TXT
documentation file, because VDE under vDOS fails to load it with an
out of memory error. (I see the same issue trying it under DOSBOX.)

But it's nice to be able to run a few old favorite DOS apps like VDE
in 64 bit Windows, and vDOS is a keeper.

See https://sourceforge.net/projects/vdos/ for information and downloads.

______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Wes Medlin]

Dennis,

I use VDOS for running VDE at work on Windows 7, 64 bit. It works like a charm, and I like that I can mount my thumb drive and work on the files directly, not in a drive image.

The one peculiarity of VDOS that I've noticed is that if a file or directory does not conform to the DOS 8.3 filename, it simply does not show up. Takes a little getting used to, but I do love this program.

Wes

--
---Get VDE and related files at http://sites.google.com/site/vdeeditor/
---
You received this message because you are subscribed to the Google Groups "VDE_Editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vde_editor+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dmccunney]

On Thu, Oct 9, 2014 at 6:56 PM, Wes Medlin <wesm...@gmail.com> wrote:

> I use VDOS for running VDE at work on Windows 7, 64 bit.

What do your AUTOEXEC and CONFIG files look like?

> It works like a charm, and I like that I can mount my thumb drive and work
> on the files directly, not in a drive image.

Yep. It's essentially a specialized virtual machine, providing enough
of DOS and 16 bit support to let DOS apps run, but the result is
running as a Windows program.

> The one peculiarity of VDOS that I've noticed is that if a file or directory
> does not conform to the DOS 8.3 filename, it simply does not show up. Takes
> a little getting used to, but I do love this program.

I saw that too, but hadn't gotten to the point of tracking down what
the issue was. Thanks! Easy enough to work around now that I know.
(The simple solution here will be to symlink stuff with long file
names to an 8+3 short name and see what happens.)

> Wes
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Gary Welles]

On Thu, 09 Oct 2014 18:56:50 -0400, Wes Medlin <wesm...@gmail.com> wrote:

> The one peculiarity of VDOS that I've noticed is that if a file or
> directory does not conform to the DOS 8.3 filename, it simply does not
> show up.

Not a problem with dbDOS PRO 3 <http://dbdos.com/>, my default "DOSBOX".

Despite it's impressive printing setup options, I've yet to be able to
print from Managing Your Money for DOS and have relied on Mark Fishman's
earlier advice to use vDOS. Lacking a proper local printer I rarely print
anything. When necessary I print to .pdf and print those on the local
library's laser printers.

Initially vDOS gave me fits, because it didn't offer enough memory to load
4DOS and leave enough memory to run a DOS application. That appears to be
fixed with the current release.

I look forward to sorting through Dennis's configuration recommendations.

If you are considering dbDOS PRO 3, subscribe to the mailing list and wait
their frequent sales. Also you may want to take advantage of the "upgrade"
price as I'm not sure they check.

-- Gary

[dmccunney]

On Thu, Oct 9, 2014 at 8:33 PM, Gary Welles <ga...@wellesway.com> wrote:
> On Thu, 09 Oct 2014 18:56:50 -0400, Wes Medlin <wesm...@gmail.com> wrote:
>
> Despite it's impressive printing setup options, I've yet to be able to print
> from Managing Your Money for DOS and have relied on Mark Fishman's earlier
> advice to use vDOS. Lacking a proper local printer I rarely print anything.
> When necessary I print to .pdf and print those on the local library's laser
> printers.

I have a local printer - an older HP "All-in-One"
copier/scanner/inkjet printer. It connects by USB, and we plug it
into whichever machine we need to print from. That's usually my SO's
Win7 laptop. I seldom need to print anything.

The game I mentioned (a DOS port of VMS Empire) is run from an
enhancer program which among other things can redirect print output to
the screen when you tell it to generate a map. That doesn't work on
the 64 bit desktop, so my config redirects the output to a file and
displays it in an editor.

> Initially vDOS gave me fits, because it didn't offer enough memory to load
> 4DOS and leave enough memory to run a DOS application. That appears to be
> fixed with the current release.

What I don't understand is why you need to load 4DOS first.

The issue you'll run into is that 4DOS takes more memory than
COMMAND.COM does. All is well until you try to shell out from your
DOS app. There isn't enough free conventional memory to load the 4DOS
transient portion, and shelling out fails. (This can happen under
real DOS, too. I ran 4DOS in place of COMMAND.COM under MSDOS, but had
the odd batch file that reset COMSPEC to COMMAND.COM before running
the app precisely because the app didn't leave room for 4DOS in a
shell.)

But in the context of running under Windows, you really don't *care*
If you run VDE in a console under NTVDM in 32 but Windows, when you
shell out, you aren't *in* the DOS environment. You are in 32 bit
Windows land, and the command interpreter active is CMD.EXE. The same
holds true in 64 bit Windows using vDOS or DOSBOX. If what you want is
the various 4DOS features, most of those are available in the freeware
TCC-LE package from JP Software. When WindowsNT came out, JP Software
moved to the 32 bit world with the console 4NT, and a later GUI app
called Take Command. Take Command is JP's payware app these days, but
they offer console-only TCC-LE as freeware (and there's a 64 bit
version.)

See http://jpsoft.com/tccle-cmd-replacement.html

> I look forward to sorting through Dennis's configuration recommendations.

I'm still experimenting. Feel free to ask questions.

> -- Gary
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Gary Welles]

On Thu, 09 Oct 2014 21:09:59 -0400, dmccunney <dennis....@gmail.com>
wrote:

> What I don't understand is why you need to load 4DOS first.

When I first moved from CP/M 3 to DR-DOS, Jay Sage of M.I.T. advised me to
"Get 4DOS" and also recommended DESQview. I've used 4DOS as a primary
command processor and DESQview/X ever since.

Having now moved to Windows the contents of C: drive from my DR-DOS
machine is now in a directory on the Win7 machine which is mapped as C:\
in the DOSboxes. As long as 4DOS is loaded as a secondary command
processor everything works as before and I don't have to fumble about with
or configure out COMMAND.COM.

> All is well until you try to shell out from your DOS app.

True, but I've long been in the habit of opening a separate process in
DESQview/X. As that's no longer possible with DOSBoxes and the same files,
so it's now exit and reload the DOS application.

While I've "upgraded" to JPSoft's Take Command Console, it's features are
of no help in a DOSbox. Likewise TCC's ability access files with long
names won't help us in vDOS.

As Jay Sage explained when switching from CP/M 3 to DR-DOS, and once again
apparent in moving from DR-DOS and DESQview/X to Windows 7, it's
applications, not operating environments that are important.

-- Gary

[Wes Medlin]

Dennis,

You asked about my autoexec and config files. The config file in the VDOS directory I just left as it was. The autoexec.txt file I modified to suit my own needs. And yes, that is a .txt file.

Here it is:
@echo off
use c: \
path=c:\bin
c:
c:\bin\vde.com

The main thing to note is the line that says use c: \. This sets the root directory of the current drive, my thumb drive, as drive c:. Then it sets the path and runs VDE for me. I double click on a  shortcut to the VDOS.exe file, and I'm instantly in VDE.

I know that there are several writers out there still using WordStar, but I've always prefered VDE. I've been using it since version 1.3, and have never found anything I prefer. And believe me, I've looked at hundreds of them, in DOS, Windows, Linux, and Mac.

Wes

[dmccunney]

On Fri, Oct 10, 2014 at 9:02 AM, Gary Welles <ga...@wellesway.com> wrote:
> On Thu, 09 Oct 2014 21:09:59 -0400, dmccunney <dennis....@gmail.com>
> wrote:
>
>> What I don't understand is why you need to load 4DOS first.
>
> When I first moved from CP/M 3 to DR-DOS, Jay Sage of M.I.T. advised me to
> "Get 4DOS" and also recommended DESQview. I've used 4DOS as a primary
> command processor and DESQview/X ever since.

I used 4DOS and DesqView for a long time. Windows replaced DesqView.
I finally stopped using 4DOS when trying to use a 16 bit command
processor in a 32 bit environment became too much bother, and there
was a 32 bit equivalent of 4DOS called TCC-LE available. (I also had
Win32 ports of bash, tcsh, and zsh I sometimes used.)

> Having now moved to Windows the contents of C: drive from my DR-DOS machine
> is now in a directory on the Win7 machine which is mapped as C:\ in the
> DOSboxes. As long as 4DOS is loaded as a secondary command processor
> everything works as before and I don't have to fumble about with or
> configure out COMMAND.COM.

Assuming you are running an app that leaves enough conventional memory
to run 4DOS beneath it.

DOS is a character mode OS where you run things from the command line,
and a command processor interprets what you type, which is usually the
name of the thing you want to run. COMMAND.COM and 4DOS work the same
way: when loaded, they relocate themselves to the top of conventional
memory, in a resident and a transient portion. When you enter a
program to run, the program loads over the transient portion. When
you exit the program, the transient portion is reloaded.

When you shell out of a program, the transient portion is reloaded
into the conventional memory remaining after the program is in memory,
and the question is is whether enough conventional memory remains to
hold it. Since the 4DOS transient portion is much larger than that of
COMMAND.COM, there may not be. This can be an issue with VDE under
pure MSDOS, let alone in DOS emulation.

>> All is well until you try to shell out from your DOS app.
>
> True, but I've long been in the habit of opening a separate process in
> DESQview/X. As that's no longer possible with DOSBoxes and the same files,
> so it's now exit and reload the DOS application.

How often must you shell out from a DOS app? What do you do when
shelled out? Since you are using a multi-tasking OS and can simply
start another process in a new window (which could be a command
processor)

In the Windows GUI world, "shelling out" is meaningless. It was
meaningful under DOS because it was single-tasking, and there were
occasions you needed to get to a command line, but didn't want to exit
your program to get to it, and restart it after.

> While I've "upgraded" to JPSoft's Take Command Console, it's features are of
> no help in a DOSbox. Likewise TCC's ability access files with long names
> won't help us in vDOS.

The question is what you need to do in a DOS box that would require
such features.

> As Jay Sage explained when switching from CP/M 3 to DR-DOS, and once again
> apparent in moving from DR-DOS and DESQview/X to Windows 7, it's
> applications, not operating environments that are important.

Sure. But I still don't understand why you have to load 4DOS.

[dmccunney]

On Fri, Oct 10, 2014 at 11:47 AM, Wes Medlin <wesm...@gmail.com> wrote:
>
> You asked about my autoexec and config files. The config file in the VDOS
> directory I just left as it was. The autoexec.txt file I modified to suit my
> own needs. And yes, that is a .txt file.

I put a custom copy of CONFIG.TXT in the VDE directory along with a
customized AUTOEXEC.TXT. That's because I want the app border, want
to run in a 50 line screen, and want a window smaller than the default
75% of screen size. As mentioned, I have a 23" monitor in 1920x1080
resolution, and the default window is simply too big.

> Here it is:
> @echo off
> use c: \
> path=c:\bin
> c:
> c:\bin\vde.com
>
> The main thing to note is the line that says use c: \. This sets the root
> directory of the current drive, my thumb drive, as drive c:. Then it sets
> the path and runs VDE for me. I double click on a shortcut to the VDOS.exe
> file, and I'm instantly in VDE.

Okay. I'm playing here with approaches like that, as the USE
statement makes whatever the target is appear to be the entire drive.
If I want to access something not in the target directory, I can't.
Setting the target directory to a higher level, setting the PATH, and
expl,icity running the app with a fuill path name is a partial work
around.

> I know that there are several writers out there still using WordStar, but
> I've always prefered VDE. I've been using it since version 1.3, and have
> never found anything I prefer. And believe me, I've looked at hundreds of
> them, in DOS, Windows, Linux, and Mac.

I'm principal maintainer of the TextEditors wiki at
http://texteditors.org, and I've looked at hundreds of editors too.

The folks on the WordStar list are all jumping through hoops to run
WS, but the main reason is that they are accustomed to the WordStar
command set. A few have experimented with other editors that use WS
commands or can be told to.

I've mentioned VDE there as a solution. One of them has been trying
to use vDOS to run WS7 under Win 7, and his current issue is that WS7
dies after being unable to find it's overlay file. I don't have or
use WS, so I can't reproduce his problem, but it sounds like a PATH
issue. Another meber of the list is successfully running WS7 in Win 7
with vDOS, so hopefully he can sort it out.

[Wes Medlin]

Dennis,

Out of curiosity, I just ran vdos, and then ran WordStar 7, and then WordStar 5. Both ran without a hitch. I'm on Windows 7 Pro 64 bit.

By the way, I love the texteditors.org site. I've been there many, many times over the years.

I've spent a lot of time looking for a Windows text editor that I like as well as VDE, and in more than 20 years I've not found one.

Wes

[dmccunney]

On Fri, Oct 10, 2014 at 12:50 PM, Wes Medlin <wesm...@gmail.com> wrote:
> Dennis,
>
> Out of curiosity, I just ran vdos, and then ran WordStar 7, and then
> WordStar 5. Both ran without a hitch. I'm on Windows 7 Pro 64 bit.

I'm on Win 7 Pro 64 bit, too, but don't have WS to play with.

I'm not sure that the WordStar list poster's problem is, but it's
hardly the first one he's had, and I've had to bite back "Can you
*read*? Can you comprehend English? I already answered this question
in a prior post..." responses.

> By the way, I love the texteditors.org site. I've been there many, many
> times over the years.

I'm pleased. I don't assume all that many people actually read it,
but I get the odd email from folks who do and find it useful, and I'm
content.

> I've spent a lot of time looking for a Windows text editor that I like as
> well as VDE, and in more than 20 years I've not found one.

A chap named Gerald Brandt is writing an editor called WordTsar
intended to fill that role: http://wordtsar.ca/ It's cross-platform,
and available for 32 bit Windows and 32 and 64 bit Linux.

Still a work in progress, but worth keeping an eye one.

[Wes Medlin]

I remember trying WordTsar at one time, but I don't remember much else. Maybe I'll try it again.

Running WordStar earlier made me think maybe I should give it another try. I've done so many times over the year, and somehow it just never quite clicks. Or maybe I'll just got back to XyWrite III. A great editor, but it takes a bit of getting used to.

Wes

[dmccunney]

On Fri, Oct 10, 2014 at 1:15 PM, Wes Medlin <wesm...@gmail.com> wrote:
> I remember trying WordTsar at one time, but I don't remember much else.
> Maybe I'll try it again.

Like I said, work in progress. I like it being available under
Windows and Linux.

> Running WordStar earlier made me think maybe I should give it another try.
> I've done so many times over the year, and somehow it just never quite
> clicks.

I doubt it would for me, either.

>Or maybe I'll just got back to XyWrite III. A great editor, but it
> takes a bit of getting used to.

I ran it, back in the day. I described it as a programming language
for dealing with text, wrapped in a clever word processor disguise.
If you were fluent in XBL, you could get XyWrite to do just about
anything. It reminded me a bit of emacs in that respect.

XyWrite lives on in Windows as Nota Bene, which began as a custom OEM
version of XyWrite under DOS. XyWrite's former lead developer is an
investor in NotaBene and contributing code.

[Wes Medlin]

Yeah, I came at it from the other end. I was working at a newspaper that used the Atex system that XyWrite was based on. I was never very good at the programming, but it was a nice editor. On the XT's we were using then, it was much faster than Word Perfect or Word.

[dmccunney]

On Fri, Oct 10, 2014 at 1:38 PM, Wes Medlin <wesm...@gmail.com> wrote:
> Yeah, I came at it from the other end. I was working at a newspaper that
> used the Atex system that XyWrite was based on. I was never very good at the
> programming, but it was a nice editor. On the XT's we were using then, it
> was much faster than Word Perfect or Word.

I remember Atex, and that XyWrite was intended to look and act like it.

XyWrite's speed was no surprise. XyWrite's lead developer coded in
assembler on an original 4.77 mhz 8088 based IBM-PC, and the intent
was to make it perform acceptably there. If it ran acceptably on an
original IBM PC, it would fly elsewhere.

A chap I met back then worked for a brokerage house that used XyWrite.
The analysts got real time stock data from a Tandem mainframe, which
was imported into Lotus 1,2,3 to do analysis on which they wrote their
comments. The guy in question used the XyWrite Help facility to
create a Lotus style menu bar interface to encapsulate the process, so
the analysts saw a seamless environment, and could switch between the
spreadsheet with the analysis and the commentary they were writing in
XyWrite.

Another guy I met back when was an applications engineer for a major
law firm that used XyWrite. He was trying to fend off a senior
partner who thought the firm should jump on the WordPerfect bandwagon.
Alas, "We can't *do* half of what we're currently doing in XyWrite
with WordPerfect, because WP doesn't support it!" tends not to be
sufficient when talking to a senior manager who doesn't actually use
the tools himself.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Mark P. Fishman]

On Fri, Oct 10, 2014 at 1:15 PM, Wes Medlin <wesm...@gmail.com> wrote:

Running WordStar earlier made me think maybe I should give it another try. I've done so many times over the year, and somehow it just never quite clicks.

I've usually found myself thinking that WordStar 3.3 "feels" better under my fingers than any of the NewWord derivatives (WordStar 4 and up). The problem there is that WS3 really needs FCB support, which means it doesn't work right on any filesystem past FAT16. (I think dosemu and DR-DOS masked that wellenough that it worked on ext2 under Linux, but it simply fails in unexpected ways on FAT32 under a 16- or 32-bit Windows).

-- m.

[Wes Medlin]

Hmmm. I dug out WordStar 3.3 and fired it up with vdos, since that was the topic that started all of this. My copy runs, but can't find the overlay file which is right there in the same directory. I haven't messed with this in a long time, but it might well be a FAT16 related issue.

--

[Moy Wong]

Gaah--FCBs? WordStar 3.3 is really showing its CP/M heritage. I once
saw a WordStar 3.3 installation on a floppy--which itself was a DOS 1.1
boot disk. It sure was a funny feeling seeing a COMMAND.COM file only a
few KB big (IO.SYS and MSDOS.SYS were similarly small).

Hey, that nasty habit of every DOS program install adding its folder
into %PATH% (via AUTOEXEC.BAT) was just a workaround for DOS 2.xx
relying on FCBs.

-moy

]
]--

[dmccunney]

On Fri, Oct 10, 2014 at 3:07 PM, Wes Medlin <wesm...@gmail.com> wrote:

> Hmmm. I dug out WordStar 3.3 and fired it up with vdos, since that was the
> topic that started all of this. My copy runs, but can't find the overlay
> file which is right there in the same directory. I haven't messed with this
> in a long time, but it might well be a FAT16 related issue.

I don't think so.

The question is where WS looks for its overlay file. We've grown
accustomed to programs looking first in the directory they are in, but
it doesn't have to be that way. What happens if you add a PATH
statement including the WS 3.3 directory in the AUTOEXEC.TXT file? WS
may be trying to search the PATH for the overlay, and if the PATH is
empty it will come up dry.

(One of the things I grew accustomed to when I learned Unix is that
*nix *doesn't* look in the current directory unless explicitly told
to. If I'm as a *nix command line, I must run foo as ./foo, even if
I'm in the directory where it lives, if that directory isn't in $PATH.
And one thing I do as a convenience under *nix is add . and .. to the
end of my PATH statement so I needn't worry about the ./* usage.)
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Wes Medlin]

Yeah, I actually did think of that. I included the current directory in the path, and it didn't make any difference.

Without the overlay file, all of the menu choices come up as @@@@@. And it's been so long since I used actual WordStar that I couldn't figure out how to make it do anything.

If I get the time later, I might mess with it some more.

Wes

[dmccunney]

On Fri, Oct 10, 2014 at 6:12 PM, Wes Medlin <wesm...@gmail.com> wrote:

> Yeah, I actually did think of that. I included the current directory in the
> path, and it didn't make any difference.

I thought you might have, but it doesn't hurt to check.

> Without the overlay file, all of the menu choices come up as @@@@@. And it's
> been so long since I used actual WordStar that I couldn't figure out how to
> make it do anything.

And it's a reason why VDE is a pleasure - self-contained and no overlay file.

> If I get the time later, I might mess with it some more.

See http://www.wordstar.org/index.php/wsdos-support/121-wordstar-3-message

It appears that FAT16 and FCBs *are* involved.

The solution for the chap on the WordStar list trying to run WS7 looks
to be PATH related.

[Gary Welles]

On Fri, 10 Oct 2014 12:22:40 -0400, dmccunney <dennis....@gmail.com>
wrote:

> How often must you shell out from a DOS app? What do you do when
> shelled out? Since you are using a multi-tasking OS and can simply
> start another process in a new window (which could be a command
> processor)

Never.

The DOS command processors are configured for 80 columns, whereas in
DESQview/X VDE's column width was variable, while WordStar, and dBase were
set wider than 80 columns. The command processor display in other than an
80 column window was disastrously wrapped. Managing Your Money was stuck
at 80x25, but did not allow for shelling out.

Aside from passing the odd command to the DESQview/X environment, I
invariably used 4DOS as separate process. So much so that when working at
the prompt outside DV/X I'd be in and out of VDE, never thinking of Alt-R.

I'm not sure if working on files from more than one process is practical
with dosboxes. If I create a new filename in one process, it doesn't
appear in the open dos box.

> But I still don't understand why you have to load 4DOS.

4DOS (now named Take Command Console) has been my primary command
processor for more than two decades. I'm just not familiar with the MS
command processors.

-- Gary

[dmccunney]

On Sat, Oct 11, 2014 at 9:23 AM, Gary Welles <ga...@wellesway.com> wrote:
> On Fri, 10 Oct 2014 12:22:40 -0400, dmccunney <dennis....@gmail.com>
> wrote:
>
>> How often must you shell out from a DOS app? What do you do when
>> shelled out? Since you are using a multi-tasking OS and can simply
>> start another process in a new window (which could be a command
>> processor)
>
> Never.

That was what I thought.

> The DOS command processors are configured for 80 columns, whereas in
> DESQview/X VDE's column width was variable, while WordStar, and dBase were
> set wider than 80 columns. The command processor display in other than an 80
> column window was disastrously wrapped. Managing Your Money was stuck at
> 80x25, but did not allow for shelling out.
>
> Aside from passing the odd command to the DESQview/X environment, I
> invariably used 4DOS as separate process. So much so that when working at
> the prompt outside DV/X I'd be in and out of VDE, never thinking of Alt-R.
>
> I'm not sure if working on files from more than one process is practical
> with dosboxes. If I create a new filename in one process, it doesn't appear
> in the open dos box.

The DOS box is specific to the DOS app you are running in it. You
*can* have more than one DOS box active simultaneously.

>> But I still don't understand why you have to load 4DOS.

> 4DOS (now named Take Command Console) has been my primary command processor
> for more than two decades. I'm just not familiar with the MS command
> processors.

The MS command processor is CMD.EXE. It's an improvement over
COMMAND.COM, and had command line recall and editing built in, as well
as extensions to the batch language. Current Windows versions also
include Power Shell, which is a dramatically different animal, but not
generally applicable to the sort of things we're discussing. (You can
get Power Shell as an optional addon for XP. It's included in
Vista/7/8.)

The next questions become "What do you do in a console window at a
command line?" "How much do the differences between 4DOS and CMD
matter?"

If you are jumping through these hoops because you are simply used to
4DOS, the simple solution is to download and install TCC-LE, the
freeware console mode version of Take Command. It has what you are
used to in 4DOS, being based on their old 4NT console mode command
processor. (It's also available in the 64 bit version.)

As a quicky experiment here, this runs VDE in a vDOS window, and
TCC-LE in a seperate window

@echo off
: vde.cmd - Run VDE in a vDOS dos box and tcc-le in a separate window.
d:
cd \msdos\vde
start "c:\Program Files\JPSoft\TCCLE13x64\tcc.exe"
start d:\vdos\vdos
exit

[Eric Meyer]

dmccunney wrote:
> There are limits - I've been unable to use VDE to edit the VDE.TXT
> documentation file, because VDE under vDOS fails to load it with an
> out of memory error. (I see the same issue trying it under DOSBOX.)

How much conventional memory does an app get under vDOS/DOSBOX? (pmap /s or
whatever.) VDE.TXT isn't that huge. If you can't load something that size,
VDE's usefulness is significantly impaired.

And then there's dbDOS... which one works best all around?

-- Eric (still running XP)

[Moy Wong]

Possibly unrelated, but I've come across certain environments (can't
remember clearly which) when an application would complain "out of
memory" when the environment was providing *more* than 640K.

-moy

]
]--

]

[dmccunney]

On Sat, Oct 11, 2014 at 1:55 PM, Eric Meyer <xor...@gmail.com> wrote:
> dmccunney wrote:
>>
>> There are limits - I've been unable to use VDE to edit the VDE.TXT
>> documentation file, because VDE under vDOS fails to load it with an
>> out of memory error. (I see the same issue trying it under DOSBOX.)
>
> How much conventional memory does an app get under vDOS/DOSBOX? (pmap /s or
> whatever.) VDE.TXT isn't that huge. If you can't load something that size,
> VDE's usefulness is significantly impaired.

MEM in a stock vDOS process reports 575KB conventional memory, 160KB
Upper memory, and 64,448KB XMS. (Pmap does not exist.)

By default, vDOS excludes the first 64KB of lower memory. There is a
LOW keyword in the config.txt file you can use to include it, and
vDOS's reported conventional memory increases to 633KB.

I need to fiddle a bit more. I see the same out-of-memory error in
VDE trying to load VDE.TXT with LOW = on. I have no idea what's
happening.

> And then there's dbDOS... which one works best all around?

I don't have dbDOS here to play with. Someone else may be able to comment.

> -- Eric (still running XP)

______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Wes Medlin]

Okay, just to be silly, I ran vdos, and then MyZ80. Voila! VDE 2.66
for CP/M running under Windows 7. How's that for backward
compatibility?

[Gary Welles]

On Sat, 11 Oct 2014 13:55:05 -0400, Eric Meyer <xor...@gmail.com> wrote:

> And then there's dbDOS... which one works best all around?

I've found that VDE loads and prints VDE.TXT with either dbDOS or vDOS.

I prefer dbDOS, but then I configured it out first and later tried vDOS
when I was unable to print from Managing Your Money for DOS. Also I've a
monthly dBASE report that would be considered critical, so dbDOS was a
natural choice.

My vDOS configuration sometimes doesn't work, but I've yet to spend a lot
of time with it. This would be consistent with VDE VDE.TXT working for me
today and then:

dmccunney wrote:
> There are limits - I've been unable to use VDE to edit the VDE.TXT
> documentation file, because VDE under vDOS fails to load it with an
> out of memory error. (I see the same issue trying it under DOSBOX.)

Also vDOS not mapping LFNs to 8.3 could be a problem.

In my DOS box tinkering I discovered that, as long as I'd dealing with
exiting files, I can edit code in VDE in one dos box and execute in
another. Edit, ^KS and try it out in the other dos box, repeat until it's
right.

-- Gary

[dmccunney]

On Sat, Oct 11, 2014 at 4:45 PM, Gary Welles <ga...@wellesway.com> wrote:
> On Sat, 11 Oct 2014 13:55:05 -0400, Eric Meyer <xor...@gmail.com> wrote:
>
>> And then there's dbDOS... which one works best all around?
>
> I've found that VDE loads and prints VDE.TXT with either dbDOS or vDOS.

I haven't been able to do so here in vDOS or DOSBOX. I have vDOS on a
2.4ghz quad-core Xeon box with 8GB RAM under Win 7 Pro. I've been
fiddling with vDOS autoexec and config files, but no setup I've tried
thus far lets me load VDE.TXT in VDE. It bombs with a VDE Out of
Memory error trying to load it.

> I prefer dbDOS, but then I configured it out first and later tried vDOS when
> I was unable to print from Managing Your Money for DOS. Also I've a monthly
> dBASE report that would be considered critical, so dbDOS was a natural
> choice.
>
> My vDOS configuration sometimes doesn't work, but I've yet to spend a lot of
> time with it. This would be consistent with VDE VDE.TXT working for me today
> and then:

Care to post your config? I'm *really* curious that it works for you

>dmccunney wrote:
>
>> There are limits - I've been unable to use VDE to edit the VDE.TXT
>> documentation file, because VDE under vDOS fails to load it with an
>> out of memory error. (I see the same issue trying it under DOSBOX.)

> Also vDOS not mapping LFNs to 8.3 could be a problem.

Certainly an annoyance, though I don't think it bears on being able to
load VDE.TXT in VDE.

> In my DOS box tinkering I discovered that, as long as I'd dealing with exiting files, I can edit code in VDE in one dos box and execute in another. Edit, ^KS and try it out in the other dos box, repeat until it's right.

No surprise. Each DOS box is a separate process. They are unaware of
each other. As long as the code you are executing in one isn't open
for editing in the other, I'd expect your results.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[dmccunney]

I'm boggled. That's wonderful.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Gary Welles]

On Sat, 11 Oct 2014 19:54:26 -0400, dmccunney <dennis....@gmail.com>
wrote:

> Care to post your config? I'm *really* curious that it works for you.

I trust Dennis is using the latest build:

7/18/2014 12:01p 287,744 vDos.exe

The early version wouldn't load applications after 4DOS was loaded.

Now, here is the DRDOS MEM.exe report from 4DOS:

┌ Memory Type ──────┬── Total Bytes ( Kbytes ) ─┬─── Available For
Programs ─┐
│ │
│ │
│ Conventional │ 655,360 ( 640K ) │ 583,312 ( 570K
) │
│ Upper │ 163,840 ( 160K ) │ 163,840 ( 160K
) │
│ High │ 65,520 ( 64K ) │ 0 ( 0K
) │
│ Extended │ 66,060,288 ( 64,512K ) │ 0 ( 0K
) │
│ Extended via XMS │ -------- │ 65,994,752 ( 64,448K
) │
├───────────────────┴────────────────────────────┴────────────────────────────┤
│ Largest executable program: 583,296 ( 570K
) │
│ Total Free DOS memory: 747,152 ( 730K
) │
└─────────────────────────────────────────────────────────────────────────────┘

Here MEM vDOS without 4DOS:

┌ Memory Type ──────┬── Total Bytes ( Kbytes ) ─┬─── Available For
Programs ─┐
│ │
│ │
│ Conventional │ 655,360 ( 640K ) │ 589,808 ( 576K
) │
│ Upper │ 163,840 ( 160K ) │ 163,840 ( 160K
) │
│ High │ 65,520 ( 64K ) │ 0 ( 0K
) │
│ Extended │ 66,060,288 ( 64,512K ) │ 0 ( 0K
) │
│ Extended via XMS │ -------- │ 65,994,752 ( 64,448K
) │
├───────────────────┴────────────────────────────┴────────────────────────────┤
│ Largest executable program: 589,792 ( 576K
) │
│ Total Free DOS memory: 753,648 ( 736K
) │
└─────────────────────────────────────────────────────────────────────────────┘

4DOS is configured to use conventional memory, and is swapping to a disk
file when an application (i.e. mem.exe) is executing leaving a <5K stub.

vDOS AUTOEXEC.TXT modifications:

rem To just use the vDos working folder as C:
rem USE C: .\
USE c:\OAK

rem Switch from Z: to C:
C:
c:\sys\4dos\4DOS.com

The vDOS CONFIG.TXT is out of the box rem statements only.

I'm having trouble setting a new PATH variable from 4DOS and the DRDOS
MEM.EXE doesn't always work without 4DOS. I expect it can be sorted out,
but it's easier for me to just return to dbDOS.

-- Gary

[Mark P. Fishman]

On Sun, Oct 12, 2014 at 9:38 AM, Gary Welles <ga...@wellesway.com> wrote:

I'm having trouble setting a new PATH variable from 4DOS and the DRDOS MEM.EXE doesn't always work without 4DOS. I expect it can be sorted out, but it's easier for me to just return to dbDOS.

As far as I can tell, dbDOS is now available only as a PRO version (PRO 3), and it costs $149 for a single-user license. Is that the only way to get it? Presumably if I had a business need to run dBase/DOS, it would make sense, but if I just want to try it out and compare it to vDOS or DOSbox for running VDE or WS, it seems bit much.

-- Mark F.

--
It is hard to believe a man is telling you the truth when you know you would lie if you were in his place.
   -- H.L. Mencken

[dmccunney]

On Sun, Oct 12, 2014 at 9:38 AM, Gary Welles <ga...@wellesway.com> wrote:

> On Sat, 11 Oct 2014 19:54:26 -0400, dmccunney <dennis....@gmail.com>
> wrote:
>
>> Care to post your config? I'm *really* curious that it works for you.
>
> I trust Dennis is using the latest build:
>
> 7/18/2014 12:01p 287,744 vDos.exe

I am.

> The early version wouldn't load applications after 4DOS was loaded.

Why are you even trying to load 4DOS first? That's the part I still
don't understand.

Under pure MSDOS, 4DOS substitutes for COMMAND.COM, and is the command
processor where you specify the program you want to run.

In an emulator like vDOS, it isn't needed. You specify the DOS app
you want to run in the vDOS autoexec file, and vDOS loads and runs it
for you. The only advantage to running a program from 4DOS is to have
the 4DOS environment available in a sub-shell from the program. But
since "shelling out" is fairly meaningless under something like
Windows, and you open a whole new window in DVX or Windows if you want
a command line, there's no point in loading 4DOS and then your desired
application.

If you like, you can open that whole other window with 4DOS loaded in
it, and you can load it in the same directory with the same
environment as your application. But as mentioned, you are better
served to use TCC-LE, which has the 4DOS features and is a proper 32
bit (or 64 bit) program.

> Now, here is the DRDOS MEM.exe report from 4DOS:

<...>

> Here MEM vDOS without 4DOS:

<...>

Sure. The difference is the 4DOS resident stub.

> 4DOS is configured to use conventional memory, and is swapping to a disk
> file when an application (i.e. mem.exe) is executing leaving a <5K stub.

It swaps to vDOS XMS here.

> vDOS AUTOEXEC.TXT modifications:
>
> rem To just use the vDos working folder as C:
> rem USE C: .\
> USE c:\OAK
>
> rem Switch from Z: to C:
> C:
> c:\sys\4dos\4DOS.com

And what actually runs the program?

> The vDOS CONFIG.TXT is out of the box rem statements only.

Which means there's not much point in having it, since it doesn't do anything.

> I'm having trouble setting a new PATH variable from 4DOS and the DRDOS
> MEM.EXE doesn't always work without 4DOS. I expect it can be sorted out, but
> it's easier for me to just return to dbDOS.

I'm not sure what you mean by "setting a new PATH variable from 4DOS"

I set the desired PATH in the vDOS autoexec.txt file. The VDE config
I'm testing at the moment does this:

@ECHO OFF
USE C: C:\
USE D: D:\
path d:\msdos\bin
rem LOADHIGH works, and loads an ANSI driver
loadhigh d:\msdos\bin\nnansi.com
rem Use 4DOS as the command processor in a subshell
set COMSPEC=d:\MSDOS\4DOS\4dos.com
D:
cd \MSDOS\VDE
vde.exe
rem EXIT

If I open a subshell from VDE, I get 4DOS as the shell, but I am *not*
loading 4DOS *before* VDE.

[Gary Welles]

On Sun, 12 Oct 2014 10:27:41 -0400, Mark P. Fishman
<mfis...@alum.mit.edu> wrote:

> As far as I can tell, dbDOS is now available only as a PRO version (PRO
> 3), and it costs $149 for a single-user license. Is that the only way to
> get
> it?

They offer holiday sales prices to their their mailing list subscribers.
Usually 30% off. Also their upgrade prices ($99 for dbDOS) seem to be
available with no questions asked. If interested, get on the list, wait
for the sale and try ordering at the upgrade price. I'd at least get on
the list before trying for the upgrade price.

> Presumably if I had a business need to run dBase/DOS, it would make
> sense, but if I just want to try it out and compare it to vDOS or DOSbox
> for running VDE or WS, it seems bit much.

I have a dBase/DOS application for a 3-family rental property, so a tax
deductible risk that it might have an edge over DOSbox. Plus I had dBase
reports that needed to go last fall.

Months later on Thursday, February 13, 2014 2:59:07 PM Mark Fishman wrote:

> There is a program called vDos available from
> "http://schaars.nl/vDos.7z" . Download it and use 7zip > to unzip it. My
> virus checker said it was clean, but as always, best to check for
> yourself.

Just in time to print reports from Managing Your Money for the tax
accountant. I suppose I should try to resolve MYM once a year print job in
dbDOS, but it's easier to work around it with vDOS or have MYM print to
disk file which can be otherwise printed.

-- Gary

[Gary Welles]

On Sun, 12 Oct 2014 10:35:59 -0400, dmccunney <dennis....@gmail.com>
wrote:

> Why are you even trying to load 4DOS first? That's the part I still
> don't understand.

I'm not running just one DOS application.

The last time I used WordStar, I printed PostScript output to a file and
then used PS2PDF.bat to convert it to .PDF.

:: PostScript to PDF.
iff exist %1 then
setlocal
alias gs = c:\gs\gs816\gs386.exe
set gs_lib=.;%gs_lib%;c:\gs\gs816\gs8.16\lib;c:\gs\gs816\fonts
set gs_device=pdfwrite
if %# eq 1 set 2=%@name[%1].pdf
iff %@word[1,%@line[%1,1]] ne WordStar then
GS -q -dBATCH -dNOPAUSE -sOutputFile=%2 %1
else
DOS2UNIX < %1 | GS -q -dBATCH -dNOPAUSE -sOutputFile=%2 -
endiff
endlocal
else
echo Usage: ps2pdf input.ps [output.pdf]
endiff

That batch file won't run from COMMAND.COM. It will only work from Take
Command Console if I replace the DOS with Windows executables. A lot of
work for something that isn't broken.

That's just two applications in a dos box. Yesterday I updated two
Managing Your Money accounts, requiring running CSV2QIF.rex, MYM, and
MYMDONE.rex, each twice. It gets more involved if I need to use VDE to
modify/test REXX code and data files.

I could run some DOS applications directly on opening a DOS box, ala
Windows, it's more flexible and probably easier to run them from a DOS
command prompt. For me that's the familiar 4DOS.

-- Gary

[dmccunney]

On Sun, Oct 12, 2014 at 1:02 PM, Gary Welles <ga...@wellesway.com> wrote:
> On Sun, 12 Oct 2014 10:35:59 -0400, dmccunney <dennis....@gmail.com>
> wrote:
>
>> Why are you even trying to load 4DOS first? That's the part I still
>> don't understand.
>
> I'm not running just one DOS application.

Understood.

> The last time I used WordStar, I printed PostScript output to a file and
> then used PS2PDF.bat to convert it to .PDF.

<...>

> That batch file won't run from COMMAND.COM. It will only work from Take
> Command Console if I replace the DOS with Windows executables. A lot of work
> for something that isn't broken.

It will run from a tcc-le command line, and you might not have to have
to replace things with Windows executables. (But you might be better
off if you *did*, if console mode Windows versions exist.)

> That's just two applications in a dos box. Yesterday I updated two Managing
> Your Money accounts, requiring running CSV2QIF.rex, MYM, and MYMDONE.rex,
> each twice. It gets more involved if I need to use VDE to modify/test REXX
> code and data files.
>
> I could run some DOS applications directly on opening a DOS box, ala
> Windows, it's more flexible and probably easier to run them from a DOS
> command prompt. For me that's the familiar 4DOS.

Translation: you are trying to shoehorn your existing workflow into a
completely different environment where it's a poor fit, because you
don't want to *change* your workflow for the new environment. If
something requires you to jump through hoops to get it to work in a
new environment, it arguably *is* broken *in* the new environment, and
the question is whether you are better served to spend your time
jumping through those hoops, or altering the workflow to properly use
the new environment it's in.

My choice is the latter. If I get a new environment, I look for ways
to to take advantage of the abilities the new environment provides to
*improve* my workflow .

An awful lot of the habits acquired working under MSDOS were
work-arounds for DOS limitations. DOS was single-user and
single-tasking, with heavy memory constraints. We used all sorts of
tricks to maximize available conventional memory, and resigned
ourselves to doing one thing at a time. We learned to use the PRINT
command to spool print jobs as background processes so at least we
weren't twiddling our thumbs waits for a print job to finish before we
could perform the next task. And the PRINT command demonstrated that
is was possible to do time slicing and foreground and background tasks
under DOS, and add a resident extension to DOS, leading directly to
things like TSRs and DesqView. When applications like Desqview became
available, we got a limited form of multitasking, as DV served as a
multi-tasking time slicing shell on top of DOS, and we could sort of
do more than one thing at a time.

Things like Linux and Windows are full multiuser, multi-tasking
environments, *without* the memory constraints imposed by real-mode
DOS.

I don't offhand see a reason why you can't use the abilities 64 bit
Windows brings to the table to refine your workflow, and make it
faster and likely simpler, but first you have to stop thinking of it
as a faster DesqView/X doing things in DOS. The applications you use
- like dBase and VDE - may be DOS apps, but the environment is a very
different one.

There probably are 32 bit or 64 bit console versions of the 16 bit DOS
console mode utilities you use that might be substitutable one for one
in existing batch files. There are certainly several different REXX
ports. I have Regina REXX installled here, but IBM Object REXX is
available, and both are built to run in the Win environment.

So far, I'm not aware of anything you're doing that couldn't be fairly
easily adapted to the new environment, and wouldn't require you the
throw out the baby with the bathwater to do it. .

[Gary Welles]

Thanks to your persistent questioning/nagging I've resolved my Managing
Your Money printing problem in dbDOS and no longer have to qualify my
endorsement of dbDOS.

I decided to do it the Windows way of launching MYM directly from a dbDOS
shortcut with this default configuration:

Z:
mount C "c:\oak\finance\MYM12\"
set path=%path%;C:\
C:\
cls
cd
cls
MYM.EXE Gary
exit

The printing problems with MYM and not with other DOS applications stemmed
from this 4DOS batch file with its "cls" and "popd" commands lurking when
MYM accessed the dbDOS print functions.

MYM.BAT:
pushd \finance\mym12\
MYM %1
cls
popd

No print problem when I don't use the above batch file, so it may be only
a matter of not have 4DOS store/restore the current directory with
pushd/popd.

Launching MYM from 4DOS and MYM.BAT with pushd/popd does not cause
printing problems in
vDOS.

-- Gary

[dmccunney]

On Sat, Oct 11, 2014 at 1:55 PM, Eric Meyer <xor...@gmail.com> wrote:

> dmccunney wrote:
>>
>> There are limits - I've been unable to use VDE to edit the VDE.TXT
>> documentation file, because VDE under vDOS fails to load it with an
>> out of memory error. (I see the same issue trying it under DOSBOX.)
>
> How much conventional memory does an app get under vDOS/DOSBOX? (pmap /s or
> whatever.) VDE.TXT isn't that huge. If you can't load something that size,
> VDE's usefulness is significantly impaired.

There are days when I suspect I'm stupid, and days I get confirmation.
I've been away from the WordStar environment too long and forgot
basics.

VDE.TXT loads just fine using Alt-L. I was attempting to use ^KR to
load it, and *that* bombs with Out of Memory.

If VDE is run using 4DOS as COMSPEC, I can't shell from it. VDE with
VDE.TXT loaded leaves too little memory below VDE to load the 4DOS
transient portion.

But recalling the experiments we carried out under XP, I used a
different tack. One of the things I have installed here is JP
Software's TCC-LE. TCC-LE is a freeware console mode version of their
shareware Take Command GUI command line utility. It's effectively a
32/64 bit Windows console version of 4DOS.

I'm keeping the MSDOS apps under D:\MSDOS, and one of the directories
beneath is a bin directory where I've been placing DOS utilities.
D:\MSDOS\BIN is set as the DOS PATH in the autoexec file that runs
VDE.

A third party utility I've been using for a while is Link Shell
Extension. NTFS5 adds support for Unix style hard links and symbolic
links, but Windows doesn't expose facility by default. Link Shell
Extension is a freeware Windows Explorer extension that adds the
ability to create and remove hard links and symlinks from the Explorer
right-click menu. I used LSE to create symlinks from the Windows
Program Files directory where TCC-LE installs to the DOS bin directory
for TCC.EXE itself and the various DLLs it calls. (See
http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html to
get LSE.)

With it in the DOS PATH, I can do Alt-R tcc in VDE and spawn a new
console window with a 64 bit tcc instance running in it.

> -- Eric (still running XP)

______
Dennis
https://plus.google.com/u/0/105128793974319004519

[dmccunney]

A few vDOS application notes:

I've been digging around in vDOS to see precisely what is supported,
including trying some resident software and drivers.

For instance, I run old DOS versions of VMS Empire and Unix Larn.
Both make use of ANSI escape sequences.

Under DOS I used to use Dan Kegel's NANSI.SYS, which was much faster
than the DOS driver, and added support for the VT100 Add Line and
Delete Line instructions. Under Win32, I used Tom Almy's NNANSI.COM,
an ehhanced version of NANSI.SYS assembled as a COM file and loadable
from the command line. vDOS supports LOADHIGH, and "loadhigh
d:\msdos\bin\nnansi.com" works as desired in the AUTOEXEC.TXT files
for the games.

Another utility that appears to work is 704K. Under MSDOS on my old
XT clone, I used a freeware utility that increased DOS memory, by
mapping memory normally allocated to video RAM to DOS. If you used a
CGA card, you could get 96K of additional memory. If you used a
Hercules card (and I did) you could get 64K. My machine booted a
704K base system. I found a copy of 704K.com on a SIMTEL mirror and
tried it. It loads and appears to work.

In the 4DOS vDOS instance, the autoexec.txt looks like this:

@ECHO ON
rem AUTOEXEC for 4DOS

use c: c:\
use d: d:\
use x: z:\

PATH D:\msdos\4DOS;D:\msdos\bin
set COMSPEC=d:\4dos\4dos.com

rem ctload is a Creative Labs (Soundblaster) utility designed to load
drivers from the command line
rem Since vDOS does not support DEVICE=<driver> in config.txt, im
experimenting to see what it can load
rem ctload

rem Allocate 64K of additional conventional memory to DOS
704k.com

rem Load an ANSI drive high.
loadhigh nnansi.com

D:
cd \msdos\4dos
4dos
rem EXIT


Various memory utilities produce the following:

D:\MSDOS\4DOS>mapmem
MAPMEM 3.0, Copyright 1991 TurboPower Software

Psp Cnt Size Name Command Line Hooked Vectors
---- --- ------ ---------- ------------------- --------------------------------
1 5,888 DOS
0040 1 256 (---free--
01A4 3 4,576 4DOS 22 23 24 2F
02C5 2 644,512 ---free---
655,344 ---total--

D:\MSDOS\4DOS>pmap
pmap 2.10 Copyright (C) 1986-1991 by The Cove Software Group/C.J.Dunford

Addr Program Parent Parameters Han Blks Size Vectors
---- ------- -------- --------------- --- ---- ------- -------
01A4 4dos 4dos 0 3 4576 22 23 24 2F
Other allocated blocks 2 272
Total conventional free memory 1 644528
Largest conventional free block 644528
Next program will load at 02C5

Extended memory summary:

INT 15 ext mem available 0
XMS version 2.00 (vendor 2.01)
HMA not enabled
Free XMS 65717248
Largest free block 65717248

XMS handles in use:
Handle Size Address LkCt
1 277504 00110000 --

Expanded memory manager no present

D:\MSDOS\4DOS>ms
720896 bytes total memory
644528 bytes free
644528 bytes in largest free block

______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Eric Meyer]

dmccunney wrote:
> There are days when I suspect I'm stupid, and days I get confirmation...

> VDE.TXT loads just fine using Alt-L. I was attempting to use ^KR to
> load it, and *that* bombs with Out of Memory.

I wouldn't use the S-word. In principle ^KR should work too; in fact, it's
still limited to a single 64k segment. ^KL/AltL has a workaround for that,
which seemed too messy to implement for ^KR. And the fact that VDE never
quite got free of such limitations is my fault.

-- Eric.

[Gary Welles]

On Mon, 13 Oct 2014 14:53:22 -0400, dmccunney <dennis....@gmail.com>
wrote:

> There are days when I suspect I'm stupid, and days I get confirmation.

Doh! Likewise. It finally occurred to me that the DOS applications I ran
from DESQview/X were run in DOS emulations. Separate DV/X Windows were
configured for each application and aside from batch and Rexx little if
anything was run from a 4DOS window C:\> prompt. I was never very good at
working ex DESQview/X at the real DOS prompt.

I've abandoned my initial "throw a brick at it" approach of trying to run
everything on contents of my former DOS C: drive from a DOSbox, dbDOS, or
vDOS C:\> prompt.

The dbDOS PRO 3 - Configuration Manager is most useful for managing
multiple configurations. dbDOS has four print options, one including a
print preview, and I've found one or two that work with MYM.

Moving along, I see "MS-DOS 6.22 and Windows 3.1x" on VMWare's very long
list of "Windows, Linux, Unix, Macintosh, and other operating systems." So
there may be hope of reviving DV/X on Win7.

Supported Guest Operating Systems
<http://partnerweb.vmware.com/GOSIG/home.html>

Given a machine with plenty of resources there should be no problem here:

> -- Eric (still running XP)

-- Gary

[dmccunney]

Nice to know that ^KR *should* work, but still a brain fart on my end
for not recalling Alt-L.

In practice, a 64K limitation actually won't bite that bad. I had a
conversation elsewhere with a developer about an editor with a 64K
file size limit. My feeling was that if you were editing source code,
and the file of code you were editing was over 64K, you were probably
doing something wrong and needed to refactor. Most code these days is
modularized, and you edit and change one module at any particular
time. Your build system will compile each module and link them
together to form the completed executable.

There are things you might wish to look at that will be larger than
64K, like log files, but you want to *look* at them, not edit them,
and you use a different tool.

I don't recall ever having cause to use VDE to edit a file larger than
64K. (The biggest thing I load into VDE is VDE.TXT, and that's to
view it.)

> -- Eric.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[dmccunney]

On Tue, Oct 14, 2014 at 8:27 AM, Gary Welles <ga...@wellesway.com> wrote:
> On Mon, 13 Oct 2014 14:53:22 -0400, dmccunney <dennis....@gmail.com>
> wrote:
>
>> There are days when I suspect I'm stupid, and days I get confirmation.
>
> Doh! Likewise. It finally occurred to me that the DOS applications I ran
> from DESQview/X were run in DOS emulations.

Well, yes. What did you think they were running in?

> Separate DV/X Windows were configured for each application and aside from
> batch and Rexx little if anything was run from a 4DOS window C:\> prompt. I
> was never very good at working ex DESQview/X at the real DOS prompt.

> I've abandoned my initial "throw a brick at it" approach of trying to run
> everything on contents of my former DOS C: drive from a DOSbox, dbDOS, or
> vDOS C:\> prompt.

Good.

> The dbDOS PRO 3 - Configuration Manager is most useful for managing multiple
> configurations. dbDOS has four print options, one including a print preview,
> and I've found one or two that work with MYM.
>
> Moving along, I see "MS-DOS 6.22 and Windows 3.1x" on VMWare's very long
> list of "Windows, Linux, Unix, Macintosh, and other operating systems." So
> there may be hope of reviving DV/X on Win7.
>
> Supported Guest Operating Systems
> <http://partnerweb.vmware.com/GOSIG/home.html>
>
> Given a machine with plenty of resources there should be no problem here:

VMWare supports just about everything. You might also be able to do
it with the open source Virtual Box.

But running DV/X under VMWare is another "Why bother?" case for me.
If I'm running a current version of Windows, I already *have* a
windowing GUI on top of a multi-tasking OS. I don't need to run
another one in a virtual machine. I'm better served to adapt the
stuff I was running in DV/X windows to run in a native window instead
and use the native OS features.

DesqView, DV/X, and for that matter Win 3.X were all fundamentally
kludges, implementing a multi-window, multi-tasking shell on top of a
single-tasking OS. Win95 began the migration away from that. Win98
was a further step, where DOS was a real mode loader for a protected
mode OS, and once it was active, DOS was out of the loop. WinNT
mostly completed the migration, with Win2K the first fully migrated
version commonly available for end users. Win Vista/7/8 are the
migration steps to move from 32 bit to 64 bit architectures.

The issue they present to us is that they removed the ability to run
16 bit applications, and you need some sort of VM to do so. That's
essentially what vDOS is for DOS apps, and those seem to the the 16
bit apps people still want to run. (There may very well be people who
still want to run Win 3.1 apps, but I haven't encountered any.)

[Mark P. Fishman]

I suspect that somewhere someone still wants to run WordStar for Windows, which is a 16-bit app.

On Tue, Oct 14, 2014 at 11:49 AM, dmccunney <dennis....@gmail.com> wrote:

The issue they present to us is that they removed the ability to run
16 bit applications, and you need some sort of VM to do so.  That's
essentially what vDOS is for DOS apps, and those seem to the the 16
bit apps people still want to run.  (There may very well be people who
still want to run Win 3.1 apps, but I haven't encountered any.)

--

[dmccunney]

On Tue, Oct 14, 2014 at 2:22 PM, Mark P. Fishman <mfis...@alum.mit.edu> wrote:
> On Tue, Oct 14, 2014 at 11:49 AM, dmccunney <dennis....@gmail.com>
> wrote:
>>
>> The issue they present to us is that they removed the ability to run
>> 16 bit applications, and you need some sort of VM to do so. That's
>> essentially what vDOS is for DOS apps, and those seem to the the 16
>> bit apps people still want to run. (There may very well be people who
>> still want to run Win 3.1 apps, but I haven't encountered any.)
>
> I suspect that somewhere someone still wants to run WordStar for Windows,
> which is a 16-bit app.

Possible. I have yet to see anyone on the WordStar list trying to do
so. They are all running flavors of the DOS version.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[dmccunney]

On Fri, Oct 10, 2014 at 6:06 PM, dmccunney <dennis....@gmail.com> wrote:
> On Fri, Oct 10, 2014 at 3:07 PM, Wes Medlin <wesm...@gmail.com> wrote:
>
>> Hmmm. I dug out WordStar 3.3 and fired it up with vdos, since that was the
>> topic that started all of this. My copy runs, but can't find the overlay
>> file which is right there in the same directory. I haven't messed with this
>> in a long time, but it might well be a FAT16 related issue.
>
> I don't think so.
>
> The question is where WS looks for its overlay file. We've grown
> accustomed to programs looking first in the directory they are in, but
> it doesn't have to be that way. What happens if you add a PATH
> statement including the WS 3.3 directory in the AUTOEXEC.TXT file? WS
> may be trying to search the PATH for the overlay, and if the PATH is
> empty it will come up dry.

And I found a copy of WS7 and installed it. Turns out it doesn't look
in the current directory *or* the PATH. You need to install it using
WSCHANGE, and plug in the PATHs where various things like it's overlay
files live. Until you do so, I believe it defaults to looking for
them on A:

The last DOS version still needs to be installed like that, and
doesn't default to looking in the program directory.

I never used Wordstar for Windows. I'd like to think it was an
improvement, but I doubt it...

It's no wonder WordStar bit the dust,.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Wes Medlin]

That would explain why WS 3.3 again failed to find it's overlays when I tried it all again from a FAT16 formated 8 mb CF card. But then, I can't swear that my copy of WS 3.3 actually works. It has been many years since I ran it.

______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Gary Welles]

On Tue, 14 Oct 2014 14:22:54 -0400, Mark P. Fishman
<mfis...@alum.mit.edu> wrote:

> I suspect that somewhere someone still wants to run WordStar for
> Windows, which is a 16-bit app.

That _once_ would have been me.

MCI Mail offered to print and deliver PostScript hard copy. Thinking PS
fonts and graphics I got the Windows application only to discover graphics
had to be converted to a format (.pix?) WS for Windows would display and
the Windows PS print driver was black and white only.

Did a quick retreat to WS for DOS, where file insert (.FI) .ps images did
the trick and GhostScript did the WYSWYG previews.

After MCI Mail shut down, I switch to using GhostScript to create .PDF
files from WS .PS print files and replaced the WS file insert (.FI)
instructions with more efficient custom printer instructions which were
PostSript RUN file commands (i.e. <(c:/bin/ws/garysig.ps) run>).

Thanks to Mark's recommendation of the Adobe "Red Book" PostScript
Language Reference, I could do things with VDE that I suspect I'd have a
hard time clicking out with a Windows word processor.

Note in the excerpt of the VDE created .PS below the "0 -15 rmoveto" which
causes the "imagemask" (stencil) of my signature to overprint part of any
"Sincerely Yours," as if signed after the letter were printed. And, XV
does not produce a PostScript "imagemask". An edit or two with VDE
converted it's negative PostScript "image" to "imagemask".

%%BeginDocument: GARYSIG.PS
%!PS-Adobe-2.0
%%Title: GARYSIG.PS
%%Creator: VDE version 1.95 (29 Aug 2007)
%%CreationDate: June 11, 2008
%%Pages: 1
%%EndComments
%%EndProlog

% remember original state
/origstate save def

.3174 .0952 .8095 setrgbcolor

% lower left corner
0 -15 rmoveto
currentpoint translate

%%BeginDocument: GARYBW.EPS
%!PS-Adobe-2.0 EPSF-2.0
%%Title: GARYBW.EPS
%%Creator: XV Version 3.00 Rev: 3/30/93 - by John Bradley
%%BoundingBox: 277 366 334 426
%%Pages: 1
%%DocumentFonts:
%%EndComments
%%EndProlog

%%Page: 1 1

% remember original state
%/origstate save def

% build a temporary dictionary
20 dict begin

% define string to hold a scanline's worth of data
/pix 72 string def

% lower left corner
%277 366 translate

% size of image (on paper, in 1/72inch coords)
57.02400 59.97600 scale

% dimensions of data
570 600 true

% mapping matrix
[570 0 0 -600 0 600]

{currentfile pix readhexstring pop}
imagemask
00000000000000000000000000000000000000000000000000000000019ffff000000000

-- Gary

[Mark P. Fishman]

On Wed, Oct 15, 2014 at 9:26 AM, Gary Welles <ga...@wellesway.com> wrote:

Thanks to Mark's recommendation of the Adobe "Red Book" PostScript Language Reference, I could do things with VDE that I suspect I'd have a hard time clicking out with a Windows word processor.

It strikes me as funny that many people have, over the years, described doing things with VDE (and with WordStar) that I can't begin to figure out how to do, or in some cases even understand the detailed explanations. I can see that these things are possible, and the truly amusing part is that occasionally I suggested the outlines of how to do them, or the tools to do them with.

I am glad that anything I might have said has been of use to people, and I am grateful for the acknowledgement, but the real work was just about always done by others. It's good to be part of this community.

-- Mark F.

[Gary Welles]

On Tue, 14 Oct 2014 11:49:15 -0400, dmccunney <dennis....@gmail.com>
wrote:

> Well, yes. What did you think they were running in?

Well, I'd forgotten, then I remembered.

> DesqView, DV/X, and for that matter Win 3.X were all fundamentally
> kludges, implementing a multi-window, multi-tasking shell on top of a
> single-tasking OS.

A bit unfair to DESQview/X which aside from offering a multi-tasking,
multi-threading environment offered a flat 32-bit memory model via a
proprietary interface with QEMM allowing it to run 16-bit DOS applications
alongside 32-bit X-Window applications. For example the Motif Rolodex
application, MROLO.EXE, is 766KB. Single tasking DOS only comes into play
with some DOS calls such as disk i/o which DV/X has to pass to DOS.

Thanks to our friends at Toasty Tech we can see the DV/X boot screen for
the version 2.1 update which for the first time bundled with a basic
TCP/IP stack. It shipped in February 1994, the very same month Microsoft
claimed it got the idea to include TCP/IP with Windows 95. Note also in the
screen shot below Microsoft's next big idea, the Windows 8 tile interface,
in the form of DV/X's _optional_ Application Manager window manger.

DESQview/X
Version 2.1 screen shots
http://toastytech.com/guis/dvx.html

When I had occasion to run Win3.1 and Win98 on my DV/X machine, I
found them a bit logy. Now Win7 is plenty speedy, but then with
a 20x faster CPU I'd expect DV/X to pick up its pace as well.

> Win95 began the migration away from that. Win98 was a further step,
> where DOS was a real mode loader for a protected mode OS, and once itwas
> active, DOS was out of the loop. WinNT mostly completed themigration,
> with Win2K the first fully migrated version commonly available for end

> users. WinVista/7/8 are the migration steps to move from 32 bit to 64
> bit architectures.

True, but we've been here all along and heard many times: "Nobody uses
Win-nn any more, you should migrate to Win-nn because it . . .". It's
always been about the applications, not the OS. If you want up to date
versions of most applications, they're available for recent versions of
Windows.

-- Gary

[dmccunney]

On Thu, Oct 16, 2014 at 12:49 PM, Gary Welles <ga...@wellesway.com> wrote:
> On Tue, 14 Oct 2014 11:49:15 -0400, dmccunney <dennis....@gmail.com>
> wrote:

>> DesqView, DV/X, and for that matter Win 3.X were all fundamentally
>> kludges, implementing a multi-window, multi-tasking shell on top of a
>> single-tasking OS.
>
> A bit unfair to DESQview/X which aside from offering a multi-tasking,
> multi-threading environment offered a flat 32-bit memory model via a
> proprietary interface with QEMM allowing it to run 16-bit DOS applications
> alongside 32-bit X-Window applications. For example the Motif Rolodex
> application, MROLO.EXE, is 766KB. Single tasking DOS only comes into play
> with some DOS calls such as disk i/o which DV/X has to pass to DOS.

It was still a shell on top of a single-tasking OS.

DOS apps had been moving in that direction for about as long as DOS
existed, with the best examples being apps that bypassed the BIOS and
wrote directly to video memory to get performance. They made the
implicit assumption that they were the only thing running and owned
the machine. Under DOS, that was a reasonable assumption. Under a
multitasking OS, it isn't.

Those apps (primarily games) were the driver in development of things
like DOSBOX, because you can't do that in a proper multitasking
environment. Things like DOSBOX implement a layer between the app
and the hardware, and convert attempts to dorectly address the
hardware into things that call the underlying OS service to do it.

Disk I/O was the part that couldn't be bypassed, and things like DV,
DX/X, and Win 3.1 essentially served as dispatchers serializing I/O
requests to DOS. Win9X migrated away from that, and in Win98, DOS was
a real-mode loader for a protected mode OS. Once Win98 was up, it
took over and DOS was out of the loop.

> When I had occasion to run Win3.1 and Win98 on my DV/X machine, I
> found them a bit logy. Now Win7 is plenty speedy, but then with
> a 20x faster CPU I'd expect DV/X to pick up its pace as well.

I have no doubt it would. What I don't see is any good reason to do it.

> True, but we've been here all along and heard many times: "Nobody uses
> Win-nn any more, you should migrate to Win-nn because it . . .". It's
> always been about the applications, not the OS. If you want up to date
> versions of most applications, they're available for recent versions of
> Windows.

It's always about the applications. Most folks get a new version of
Windows when they get a whole new machine with it pre-installed.
There's still an awful lot of WinXP out there, despite MS's best
efforts to end-of-life it.

But increasingly, apps have to be updated, too. I have a few things
here whose latest versions won't run on XP and require Vista or
better.

The question for the user is the point at which continuing to use the
preferred app is simply more trouble than switching to something else.

[dmccunney]

An update on vDOS, for those following this:

As mentioned earlier, vDOS doesn't handle long file names, and the
author refuses to add LFN support.

Wengier Wu had previously patched DOSBOX, from which vDOS derives, to
add some LFN support. He looked, and discovered that his patch could
be applied to vDOS too after a few changes. His current version is
here: http://sourceforge.net/p/vdos/discussion/general/thread/44116b8c/?limit=25&page=2#92ec

Playing with it a bit, it seems to work fine in place of the one
linked to earlier.
______
Dennis
https://plus.google.com/u/0/105128793974319004519

[Gary Welles]

On Sun, 12 Oct 2014 10:27:41 -0400, Mark P. Fishman
<mfis...@alum.mit.edu> wrote:

> As far as I can tell, dbDOS is now available only as a PRO version (PRO
> 3), and it costs $149 for a single-user license. Is that the only way to
> get it?

They just announced the released of dbDOS PRO 4 <http://dbdos.com/>:

"LIMITED TIME UPGRADE! Until May 31st 2015*, upgrades from any previous
version of dbDOS™ to dbDOS™ PRO 4 are available for the special upgrade
price is just $99 (USD)!
. . .
*Upgrade pricing for dbDOS PRO 4 only is available from today, May 6th,
2015 at 3:00 PM EDT until 11:59 PM EDT on May 31st, 2015."

In my experience it appears their "upgrade" pricing is available with no
questions asked.

-- Gary