Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Fun with vDOS (Emulation)

posted by Dennis, 07.01.2015, 22:15

> > And I've encountered a weird vDOS quirk.
> >
> > One of the DOS apps I still have and use on occasion is an editor called
> G,
> > by Jeremy Hall in the UK, dating from 1995.
>
> Yes, I've seen it before but only tried it once or twice. Despite lacking
> some (irrelevant) features, I still stick to TDE.
I'm mostly fascinated by the design. One of the questions in implementing an editor is how you store text to be edited in memory. Current practice seems to be variants on the "buffer gap" technique. Hall uses a different method he outlined on on comp,editors: https://groups.google.com/forum/?fromgroups#!searc...my$20hall/comp.editors/Br_yX8QXwgE/cNJa2Ltuyc0J

> > It uses the WordStar command set, and has an interesting design
> > where it can be used as a full screen editor, or used as a filter
> > in a pipe.
>
> You mean like "uname -a | vile" or "echo hello | tde"?
Something like that. The editor core can be called as a program and used non-interactively, a bit like Unix sed.

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

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

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

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

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

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

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

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

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

<...>

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

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

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

<...>

> Patch follows (but beware, you need hard tabs in the makefile).
I'll look at it at some other point. But if you were able to produce a binary that appears to work on Linux, can you zip it and send it to me? dennis dot mccunney at gmail dot com reaches me. I'll see what it does under Ubuntu.
______
Dennis

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 150 users online (0 registered, 150 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum