Greetings. Did you write those utilities from scratch yourself? Seems a bit redundant, considering that a lot of them have equivalents in the FreeDOS project (or possibly FreeDOS).

1WCMD - run host Windows CoMmanDs within DosBox

This is interesting. Does this work in stock DOSBox?

>Greetings. Did you write those utilities from scratch yourself?

Yes, I write most of my stuff from "scratch", or at least starting with
a similar program I'd written before. For DOS stuff I tend to use my own
C compiler which has libraries and an efficiency level which are quite a
bit bettern that others - so I don't oten see a lot of compatible 3rd
party code!

>Seems a bit redundant, considering that a lot of them have equivalents in the
>FreeDOS project (or possibly FreeDOS).

Quite probable, but I rarely look for other stuff when I enjoy creating it
myself and rarely find others nearly as optimal as I'd like (below for more
if you care).

>1 WCMD - run host Windows CoMmanDs within DosBox
>This is interesting. Does this work in stock DOSBox?

It should, I mainly use the old H-A-L 9000 "Megabuild 6" which *I think*
is pretty much the same as standard DosBox with a few extras turned on.

Dave

**More (If you care) - not really related**
I've been in the industry since it's very early days (70's) ... Didn't get
drives till late 70's - whopping 90k SSSD floppies - By that time I did have
a "commercial" system - I eventually upgrade my Altair to 64k RAM... Spending
your formative years in such an environment makes you sensitive to how overly
big and complicated others can make things.

An example: DOSBOX is essentually a 16 bit virtual machine. In my install
it has over 4M of .EXE and .DLLs. Haveing lots of time on my hands last
year I created my own 16 bit VM - DVM is a single 15k .EXE which requires
no other files, does not have to be installed and leaves no "droppings" in
places like "appdata". As it supports pretty much all of my compilers
DOS library, it has pretty decent DOS emulation.

Don't get me wrong, DOSBOX is great and emulates the whole PC hardware and
software well enough to actually run games! - but for simple utilities DVM
gets in the way a lot less, makes host files etc. much more available, and
goes much faster for me.

The simplest decent C developent package I've found for Win32 is LCCwin32.
My install is about 35mb. A fresh install of my Micro-C compiler for DVM is
about 499k of which 412k is documentation.

Obviously not the same thing -- but you don't always need/want "the best"
bloated software you can find... often your requirements can be met nicely
with something much simpler and more straightforward.

So.. for small stuff, I don't usually go looking for something existing, as
I can almost always create something that does exactly what I want in much
less time than finding and dealing with something "else".

FWIW

May I humbly suggest looking into whether some of your contributions might be applicable at the FreeDOS project? Using DOSBox for file management tends to be discouraged and I fear these tools may not get the attention they deserve here.

Seems a bit redundant, considering that a lot of them have equivalents in the FreeDOS project (or possibly FreeDOS).

*I meant "or possibly 4DOS" here.

DaveDDS wrote on 2021-05-12, 03:56:

This is interesting. Does this work in stock DOSBox? […]
Show full quote

Copy code to clipboard

1WCMD - run host Windows CoMmanDs within DosBox

This is interesting. Does this work in stock DOSBox?

It should, I mainly use the old H-A-L 9000 "Megabuild 6" which *I think* is pretty much the same as standard DosBox with a few extras turned on.

I mean, doesn't the ability to run host Windows commands within DOSBox suggest a highly problematic security vulnerability?

Also, please be advised that the use of Megabuild 6 is discouraged. You may enjoy DOSBox-X, which is much more up to date and should include the same extras – assuming in this instance that you do "need/want 'the best' bloated software you can find". 😉

Haveing lots of time on my hands last year I created my own 16 bit VM - DVM is a single 15k .EXE which requires no other files, does not have to be installed and leaves no "droppings" in places like "appdata". As it supports pretty much all of my compilers DOS library, it has pretty decent DOS emulation.

Don't get me wrong, DOSBOX is great and emulates the whole PC hardware and software well enough to actually run games! - but for simple utilities DVM gets in the way a lot less, makes host files etc. much more available, and goes much faster for me.

(I confess I thought this was coming across as some sort of tease at first glance. If anyone else reading this is wondering, it is apparently available at https://dunfield.themindfactory.com/dnld.htm .)

>May I humbly suggest looking into whether some of your contributions
>might be applicable at the FreeDOS project? Using DOSBox for file
>management tends to be discouraged and I fear these tools may not get
>the attention they deserve here.

I think some of my earlier stuff did make it into FreeDOS. I was quite keen
on the project near the beginning, I don't recall the details but there was
some sort of misunderstanding or other reason we didn't do great and I parted
ways from it and haven't really looked back.

>>WCMD
>I mean, doesn't the ability to run host Windows commands within DOSBox
>suggest a highly problematic security vulnerability?

It could certainly be abused, but it won't happen unless you are well aware
that it could go on. WCMD communicates with a Windows program that you not
only have to start, but need to set up a link to run it specifying the location
of the temp file used to communicate with it .. (I put it on my RamDisk but
you can put it anywhere DosBox can also access it). I think highly unlikely
to happen "by accident".

>Also, please be advised that the use of Megabuild 6 is discouraged. You
>may enjoy DOSBox-X, which is much more up to date and should include the
>same extras assuming in this instance that you do "need/want 'the best'
>bloated software you can find". winking face

I've just started looking at DosBox-X and it looks good. I'm hoping they will
finish the Android port - It has one "new" feature I love, which is the
ability to mount a RAMdrive. I know that on a busy system this might get
swapped to physical storage, but that shouldn't happen unless you have a
lot of "stuff" running - and a big advantage of a RAMdisk is temp storage
that always "goes away". And unless you get into "rooting" there isn't a way
to make a normal RAMdrive on a droid (that I know of).

Incidently (again, not really relalated) one motivation for posting the updated
DBUTIL archive and announcing it here was that I just recently did "KEYSUB" and
I find it very useful on Tablet verssions (Turbo DosBox, IDosBox and Magic
are the one's I've used)

KEYSUB differs from most key remappers because It installs a very tiny TSR
which substitutes complete keycodes - not just scancodes.

I tend not to like on-screen tablet keyboards with DosBox because either it
covers hald your DOS screen, or you have to make the DOS screen so small it
is hard to read. So I like to use physical keyboards which take on screen
space. My S5E has a "keyboard" cover and I also have several tiny Bluetooth
keyboards for other tablets. But mapping ScanCodes (like DosBox can) doesn't
easily let you cross Normal/Shift/Ctrl/Alt boundaries. These keyboards don't
have enough "spare" keys to implement F1-F10, Ins/Del/Home/End/PgUp/PgDn etc.

But most of these keyboards send unique keycodes for Alt-1 to Alt-0.
I wanted to make these F1-F10 -- but ran into a problem: I could for
example make Alt-1 send the F1 scancode, but because I had to hold Alt
to enter it, DosBox applications were seeing Alt-F1... A valid but
rarely used DOS key.

I first though about rebuilding all my stuff to accept Alt-1 - Alt-10
for the same functions as F1 - F10 - but then I decided to write KEYSUB
which lets the application see the code for F1 when I press Alt-1. In
addition you can substiture any Alt/Shiift/Ctrl code for any other-state key.

With this I have been able to make DosBox on my tablets very workable.

>>DVM
>(I confess I thought this was coming across as some sort of tease at first
>glance. If anyone else reading this is wondering, it is apparently...

It IS very real, and I use it daily. It's purpose it to make it very simple
and portable to run simple to moderatly complex "stuff" in any environment
where DVM has been ported. Currently I have Win32/Win64, but I'm looking at
doing a Linux port and may eventually do Android as well.

It's not an X86 VM - It implements a CPU I designed a few years back called
"C-FLEA" which is a tiny 16 bit CPU which is a pretty optimal target for my
compiler. The actual CPU implementation is <200 lines of C (with no library
calls etc). The bulk of DVM is emulating enough of DOS to make my DOS
library workable.

Just FYI!

Dave

Hi Dave,

Good to see the new site. Appreciate the update - lots of these tiny utils will be very useful, not only in DOSBox (or DOS-on-Win64) but for my memory-limited XT as well.

And lest I forget, thanks for writing ImageDisk. That just might be your most popular program as of late, but it's a little hard to find on the new site - at least it's there!

>Good to see the new site. Appreciate the update - lots of these tiny utils
>will be very useful, not only in DOSBox (or DOS-on-Win64) but for my
>memory-limited XT as well.

Just curious what you mean by "DOS-on-Win64" -- as far as I know Win64
doesn't support 16 bit code at all (and most DOS stuff is 16 bit). Win32 does
run 16 bit code and has decent DOS emulation for basic utilities, but DOS
stuff won't support long filenames.

I have compiled a lot of my utilities for DVM which does run under
Win64 and Win32 and does provide better long filename support.

>And lest I forget, thanks for writing ImageDisk. That just might be your
>most popular program as of late, but it's a little hard to find on the new
>site - at

Thanks, IMD has gotten pretty good press over the years.
The best place to find it is on my other "Dave's Old Computers" site. It is
fairly prominent there as there's a whole section on disk images for classic
systems.

Regards,
Dave

DOSBox-X does support long file names (LFN), which can be enabled with either ver=7.1 or lfn=true in the config file. With LFN support enabled many newer DOS programs will be able to access long file names too. Look at the following page for a partial list of LFN-compatible DOS programs:

http://cndos.fam.cx/msdos71/doslfns.htm

Also, DOSBox-X has many additional features which may not be enabled by default, such as the TrueType font (TTF) output which is especially suitable for the DOS shell and running text-mode DOS applications (such as file management tools). Enable the output with the setting output=ttf. Take a look at the following page for more information about the TrueType font output:

Guide: Using TrueType font output in DOSBox-X

>(I confess I thought this was coming across as some sort of tease at
>first glance. If anyone else reading this is wondering, it is apparently
>available at https://dunfield.themindfactory.com/dnld.htm .)

In case anyone is interested...

I've recently posted a Linux version of DVM (Dunfield Virtual Machine)

In case you are not famillier:
DVM is a Virtual Machine I created a little which back which is based
on my own "C-FLEA" a custom CPU design which is a good combination of
quite simple, and a fairly optimal target for my C compiler.

It allows you to build simple to fairly complex tools in C and run them
(without change / recompile etc.) on Windows and now Linux (as well as DOS).

This is quite unlike most other virtual machines:

- Interacts directly with/on the HOST OS. You don't have to run a
virtual environment, simply use "DVM" as a prefix to running .DVM files.
Command line arguments etc. all pass through "as expected".

- Handles differences in file systems as simply and compatibility as
possible. All of the tools I've ported to DVM work on both Windows and
Linux without change.

- Integrates my own Micro-C library, provides most of the capabilities
you might want in tools and utilities.

- Single fairly small executable, does NOT have to be "installed", does
not require "runtime" libraries... You can simply copy the one executable
to whatever system you happen to be using and "just run" it.

ps: (Things not to complain about because I won't listen)
Yes my compiler is "old school". I wrote it back in the 80's.. you
won't see a typical "tons of stuff" modern develoement package with
megs of programs and supporting file all the while with documentation
"on the web". My setup is just about 1/2meg of which 400+k is documents
(Hopefully you can figure out the obscure and unusual format called "text" 😀

pps: to give you an idea of what to expect from DVM/C-FLEA/Micro-C,
here are the sizes of something (my "EDT" text editor) which I have
ported to DOS/Windows/Linux/DVM using different compilers:
DOS Turbo-C 17,138
Win32 LCC 28,584
Linux32 GCC32 28,392
Linux64 GCC64 42,256
DVM Micro-C 8,579

Just FYI! - Dave

"Dave's Old Computers" -----or-> ltrs+1: aA0=bB1 zZ9=aA0, then b=: s=/ z=.
see "personal" at bottom. -----> gssoarrvvvyctmehdkcysgdlhmcezbsnqxybnl

VileR wrote on 2021-05-13, 19:35:

And lest I forget, thanks for writing ImageDisk. That just might be your most popular program as of late, but it's a little hard to find on the new site - at least it's there!

Btw/FYI - I've just posted an update to IMD(119) on "Daves Old Computers".

It's mainly updating contact information, but there is a fix to a minor
bug in BIN2IMD ... it sometimes would swap the format information between
side1 and side2 - almost never noticed, because most diskettes are
formatted the same on both sides - especially when you are making an image
from a binary data file (which is what BIN2IMD does!)

Dave

Hi,

I've been looking at DosBox-X more, and looking to move some of my "DosBox specific" tools over to it.
One thing that has changed quite a bit is the content of the .MAP file.. I like to be able to quickly and easily change certain aspects of the keyboard on an ongoing basis, and in working through the changes, I've got a question:

In the standard DosBox MAP (ie: no .MAP file) one key seems to be mapped twice within SDL:

"Menu" is mapped to both keycode 101 AND keycode 118

?? Although DosBox doesn't try to use this key, I like to be able to specify any key by name in my command line
MAPs -- I don't know what code should be assigned for "MENU" - Is this a "bug" is SDL - or is there some other
reason I'm not seeing?

Thanks,
Dave

Dave,

Quick question: I'm fascinated by your DVM.exe. Is there any chance you might make it possible to work somewhat the way that msdos-player works (http://takeda-toshiya.my.coocan.jp/msdos/index.html). In other words, could we use a command like:

DVM c:\path\to\16bitapp.exe %1 %2

and run the 16bit app? The msdos-player includes a feature that lets you build a single app that contains msdos.exe and the 16-bit app that you're running. It works well under many situations, but there's plenty of room for a similar program that does more.

I know it's easy for me to ask you do all this work without being paid, and I'm only asking in case you find it the kind of project that may be useful to yourself.

emendelson wrote on 2022-09-22, 13:33:

Dave, […]
Show full quote

Dave,

Quick question: I'm fascinated by your DVM.exe. Is there any chance you might make it possible to work somewhat the way that msdos-player works (http://takeda-toshiya.my.coocan.jp/msdos/index.html). In other words, could we use a command like:

DVM c:\path\to\16bitapp.exe %1 %2

and run the 16bit app? The msdos-player includes a feature that lets you build a single app that contains msdos.exe and the 16-bit app that you're running. It works well under many situations, but there's plenty of room for a similar program that does more.

I know it's easy for me to ask you do all this work without being paid, and I'm only asking in case you find it the kind of project that may be useful to yourself.

That's pretty much the way it works ... except... DVM is NOT an X86 emulator and won't run .EXE's

DVM implements a 16-bit CPU I "invented" a number of years back which is both very simple (<200 lines of C which doesn't call any libraries) and a very optimal target for my Micro-C compiler .

Micro-C has a fairly complete DOS library which is built into the DVM virtual machine - As I write almost all of my tools and utilities with Micro-C, this lets me take most of what I've written in the past 30+ years and simply re-compile it with the DVM version of the compiler to get a .DVM executable.

Executable DVM files are type ".DVM" and run under the DVM virtual machine which I've ported to Win32/64 as well as a couple flavors of Linux, someday when I have more time I'll probably port it to Android and some other platforms)

FWIW, since C-FLEA is fairly efficient, the .DVMs are usually quite a bit smaller than the same program compiled to a .COM or .EXE (often 1/2)
and the code runs very quickly, almost as fast as the native .COM/.EXE under DOS (much faster than under DosBox!)

I've been thinking of making a Win32 executable essentially containing DVM.EXE which you could patch your .DVM code into, which would basically make it "look and feel" like a native Win32 executable! (.DVMs already work as expected under Win except that you need to prefix the command with: DVM )

Dave

Is there a better place to ask fairly technical questions about DosBox?

Infiguring out keymapping for DosBox-X, I've run into a few keys which
are defined within DosBox-Xs default .MAP, however the keymapper shows
them all as "BIND: Key" for that keycode... (not really defined within SDL?)

Not sure if one of them is supposed to be legit:

key_lessthan "key 100"

The remaining I'm assuming are keys on a ?Japanese? keyboard, and I probably
don't have to enter them, however I am trying to come up short names which
can be easily entered in my command line tool ??

key_jp_muhenkan "key 139"
key_jp_henkan "key 138"
key_jp_hiragana "key 136"
key_jp_yen "key 137"
key_jp_bckslash "key 135"

Btw: bug-report: intro special
doesn't work to show the special keys in DosBox-X (although the main
"intro/Information" menu shows it as an option. It did work in MB6!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

In case anyone is interested:

I've just revised my "patched" DosBox posted on my site.
(this has ".conf" changed to .INI to avoid LongFileName issues when
accessing the configuration from within DosBox using SFNs!)

There are two available:
DOSBOX_X new(ish) DOSBOX-X - just starting to get into it.
DOSBOX_M older MegaBuild-6 - the one I've been using for "years".

Also updated some of the little tools I include:

DBSETUP - Easy simple Setup/Modify basic DosBox installation
- can also modify various "system" files to accomodate moving
- DosBox around between multiple computers with a portable drive.
DBKEYS - Much simpler key remapping, can also remap from command line
DBPATCH - Patch DOSBOX.EXE (.INI/.CONF extension, built in commands)

Dave Dunfield - https://dunfield.themindfactory.com

Just in case anyone is interested...

As part of looking at making RamDisk to use in Tablet editions of DosBox
(anyone know if such a thing already exists?)...

I've tossed together a little tool to record INTs (and registers at time of
INT) performed by DOS commands/programs.

This lets me see exactly how various programs are accessing the file system
or doing various other things.

Look for R86I in my site downloads.

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)