Hi,

On Mon, Mar 23, 2020 at 2:50 PM Eric Auer <e.a...@jpberlin.de> wrote:
>
> In FreeDOS, you have to load a LFN driver TSR to use it, but I think
> most of command.com already is LFN-aware.

IIRC, it depends on the version. Some people (you?) still stuck with
older ("stable"?) 0.82pl3, which didn't support it. But the newer
0.84-pre2 (thanks to Blair) supports LFNs (though you can't have
DESCRIPT.ION shown on screen at the same time).

> You may have to set some shell options
> in your startup files (config, autoexec).

* http://help.fdos.org/en/hhstndrd/command/lfnfor.htm

> The question is which other apps need LFN support: As mentioned
> earlier, it would be possible to create a TSR (similar to SETVER
> in MS DOS) which knows which apps are LFN-aware and replaced LFN
> file and directory names in command line options by their short
> counterparts in the background for everything else. See that
> bunnyhop "c:\forest level\" fictional old game example :-)

Back in 2014, someone complained about EDIT not supporting LFNs. This
was the workaround I suggested:

=================================
@echo off
REM ... L.EXE is from DOSLFN ...
set /e EDITFILE=l.exe shortname %1
edit.exe %EDITFILE%
set EDITFILE=
=================================

> Regarding your other question: The standard answer is ReactOS
> which originally was meant to be a Windows NT alternative and
> actually did get updates in 2019

Since 2014, ReactOS does have its own (very incomplete but still
impressive) NTVDM. Their example showed them playing Duke Nukem 3D
(albeit without sound). But no DJGPP stuff would run, sadly.

> Parts of the code co-evolve with Wine, but to be honest, if you want to use
> Windows software on a modern PC, Wine in Linux will often be
> sufficient anyway.

WINE just minimally uses DOSBox, last I heard, but I haven't tried lately.

> Another way to run Windows software in DOS is Japeth's HX RT,
> which you could compare to an extremely extended DPMI extender
> including implementations of many popular Windows API calls:
>
> > https://www.japheth.de/HX.html
> > https://www.japheth.de/dwnload4.html

I'm surprised that old link (now) works again! But it's old versions.
His Github has been updated in the last month (2.18-pre or whatever),
so check there:

* https://github.com/Baron-von-Riedesel/HX

> This lets you run non-fancy Windows programs directly from the
> DOS prompt, for example compilers (non-graphical)

OBC (Oxford Oberon) works. So does native XDS (now open source,
Apache-licensed). Though you have to install them elsewhere first (not
just plain .ZIPs). IIRC, I had to do some fiddling (set HDPMI=32, set
DPMILDR=136, use ReactOS 0.3.14 [sic] MSVCRT.DLL).

7-Zip's 7za920.zip (non-graphical / cmdline: 7za.exe) from years ago
also worked fine.

* https://spivey.oriel.ox.ac.uk/corner/Installing_OBC_release_3.1
* https://github.com/excelsior-oss/xds
* https://www.7-zip.org/a/7za920.zip

> or graphical apps which only use SDL or similar very compatible frameworks,

Mateusz's port of Atomiks?

* http://atomiks.sourceforge.net/

> Note that only half a dozen of the most basic Windows DLL are
> emulated, so do not expect to run Chrome on DOS with HX GUI.

There used to be a compatibility list (or two), but they're outdated.
Obviously a lot of stuff doesn't work, but it's surprisingly good when
something does.

* https://www.japheth.de/HX/COMPAT.html
* http://www.xaver.me/drdoswiki/index.php?n=Main.HXDOScomplists


_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to