DOS ain't dead

Mini-sed is a smaller, cheaper, faster SED implementation. Minix uses it. GNU used to use it, until they built their own sed around an extended (some would say over-extended) regexp package.

minised.com for DOS built with dev86 BCC.

https://archive.org/details/minised-1.16-for-dos

gopher://tilde.pink/1/~bencollver/files/dos/util/minised/

> Mini-sed is a smaller, cheaper, faster SED implementation. Minix uses it.
> GNU used to use it, until they built their own sed around an extended (some
> would say over-extended) regexp package.
>
> minised.com for DOS built with dev86 BCC.
>
> https://archive.org/details/minised-1.16-for-dos
>
> gopher://tilde.pink/1/~bencollver/files/dos/util/minised/

Is there a reason to build with dev86 vs OpenWatcom or gcc-ia16?

> Is there a reason to build with dev86 vs OpenWatcom or gcc-ia16?

Minised is small enough that i don't think it makes much of a difference which of those compilers is used.

> > Is there a reason to build with dev86 vs OpenWatcom or gcc-ia16?
>
> Minised is small enough that i don't think it makes much of a difference
> which of those compilers is used.

Sed is my favorite tool. (I wrote about 20 scripts for PSR Invaders.)

But I find bcc/dev86 is pretty buggy, especially the older DOS-hosted one.

Nevertheless, I find MiniSed pretty useful. Years ago, I rebuilt it with DJGPP and TurboC++. I use it a lot, actually. Mostly useful in comparison to other Seds, which had supported some non-standard things: \< \> {m,n}

Portability and compatibility for Sed is harder than it sounds. Don't be naive, test every version you can find. (I always tested my scripts with like 15 Sed implementations because there'd always be a few hidden problems otherwise.)

It's based upon Eric Raymond's old code, so it shares a lot with hhsed, sedmod, and csed.

> > > Is there a reason to build with dev86 vs OpenWatcom or gcc-ia16?
> >
> > Minised is small enough that i don't think it makes much of a difference
> > which of those compilers is used.
>
> Sed is my favorite tool. (I wrote about 20 scripts for PSR Invaders.)
>
> But I find bcc/dev86 is pretty buggy, especially the older DOS-hosted one.

Actually, your build is quite buggy and fails all of my scripts. I would recommend TurboC++ or OpenWatcom instead.

> Actually, your build is quite buggy and fails all of my scripts. I would
> recommend TurboC++ or OpenWatcom instead.

Would you be willing to share those scripts?

I checked my OpenWatcom build versus the dev86 BCC build using the tests under minised-1.16/tests/. I had to convert the lfn to short file names, and convert minised's output from DOS to Unix format. After that, both builds give identical results. The tests that they both fail are:

s-+.sed
s-+2.sed
test-e.sed
w2.sed

> > Actually, your build is quite buggy and fails all of my scripts. I would
> > recommend TurboC++ or OpenWatcom instead.
>
> Would you be willing to share those scripts?

* https://drive.google.com/file/d/1-zUVo1UTPg6eBAC7n7WioBLcvBSqYccP/view?usp=sharing

> I checked my OpenWatcom build versus the dev86 BCC build using the tests
> under minised-1.16/tests/. I had to convert the lfn to short file names,
> and convert minised's output from DOS to Unix format. After that, both
> builds give identical results. The tests that they both fail are:
>
> s-+.sed
> s-+2.sed
> test-e.sed
> w2.sed

Well, something was definitely not working for me. But I didn't try to look too closely why. I'll try again.

> > Actually, your build is quite buggy and fails all of my scripts. I would
> > recommend TurboC++ or OpenWatcom instead.
>
> Would you be willing to share those scripts?

From testing about five different scripts, I notice two obvious problems (but it otherwise seems to work fine):

1. scripts (*.sed) and data files (e.g. *.asm) must be in *nix LF-only format
2. secondary output files via 'w' command are truncated improperly near the end, implying that the file is not flushed (or possibly an explicit fclose() is not used somewhere)

> From testing about five different scripts, I notice two obvious problems
> (but it otherwise seems to work fine):
>
> 1. scripts (*.sed) and data files (e.g. *.asm) must be in *nix LF-only
> format
> 2. secondary output files via 'w' command are truncated improperly near the
> end, implying that the file is not flushed (or possibly an explicit
> fclose() is not used somewhere)

Thanks for those details! I plan to:

1. Survey how other DOS versions of sed handle CRLF and report back with some statistics.

2. Reproduce and troubleshoot this problem when i find the time.

I posted msed116b.zip, which updates the dev86 BCC build to accept any text format and output only DOS CRLF format. It also includes minisedw.com built with OpenWatcom.

> 1. scripts (*.sed) and data files (e.g. *.asm) must be in *nix LF-only
> format

I tested all of the DOS sed implementations on the FreeDOS site. All but one accept any text format, and output only to DOS CRLF format. The exception is hsedgcc.zip, which outputs only to Unix LF format.

> 2. secondary output files via 'w' command are truncated improperly near the
> end, implying that the file is not flushed (or possibly an explicit
> fclose() is not used somewhere)

I was not able to reproduce this problem. Would you be willing to post a simple example to demonstrate it?

> I posted msed116b.zip, which updates the dev86 BCC build to accept any text
> format and output only DOS CRLF format. It also includes minisedw.com
> built with OpenWatcom.

It accepts data files (e.g. *.ASM) in CRLF format but not *.SED scripts.

> > 1. scripts (*.sed) and data files (e.g. *.asm) must be in *nix LF-only
> > format
>
> I tested all of the DOS sed implementations on the FreeDOS site. All but
> one accept any text format, and output only to DOS CRLF format. The
> exception is hsedgcc.zip, which outputs only to Unix LF format.

The old 2004 TC 2.01 default DOS build of Csed had buffering issues (i.e. slow!), so I rebuilt it with TC++ 1.01 (in 2016?).

HHsedGCC was SED15.ZIP, also rebuilt by me (2020), with GCC IA16 (since it was the only Sed which that particular compiler would rebuild). The LF-only problem was a library issue.

> > 2. secondary output files via 'w' command are truncated improperly near
> the
> > end, implying that the file is not flushed (or possibly an explicit
> > fclose() is not used somewhere)
>
> I was not able to reproduce this problem. Would you be willing to post a
> simple example to demonstrate it?


g:\watsed>minisedw -f fixnasm.sed invaders.asm >inv-nasm.asm
g:\watsed>REM ... also creates INV-NASM.INC ...
g:\watsed>nasm16 -O3 inv-nasm.asm -o inv-nasm.com
g:\watsed>crc32 inv-nasm.com

FFF22EF9 *G:\TONY\OLD\INV-NASM.COM

g:\watsed>cd..
g:\bccsed>minised -f fixnasm.sed invaders.asm >inv-nasm.asm
sed: no such command as %idefine offset\

g:\bccsed>an fixnasm.sed
Analyzer v1.36 by Boogie   Copyright (C) 1997 ESP Team
Files: G:\TONY\FIXNASM.SED
--------------------------------------------------------------------
FIXNASM.SED  Text file - DOS/Win
--------------------------------------------------------------------

g:\bccsed>dos2unix -k -q *.sed
g:\bccsed>minised -f fixnasm.sed invaders.asm >inv-nasm.asm

g:\bccsed>nasm16 -O3 inv-nasm.asm -o inv-nasm.com
inv-nasm.asm:48: error: comma or end of line expected
inv-nasm.asm:56: error: comma or end of line expected
inv-nasm.asm:61: error: comma or end of line expected
inv-nasm.asm:69: error: comma or end of line expected

g:\bccsed>diff -q old .
Files old/inv-nasm.inc and ./inv-nasm.inc differ
Only in old: inv-nasm.com
Only in old: minisedw.com
Only in .: minised.com
Only in .: old

g:\bccsed>diff old\*.inc .
141,147c141
< %define s_PlayKeys B
< %define s_Distribution B
< %define s_GameOverMsg B
< %define s_GetReady B
< %define s_TempStore W
< %define s_Palette B
< %define s_VideoBuffer B
---
> %define s_Pl
\ No newline at end of file


invadr11.zip (24 kb)

fixnasm.sed (p.d. / MIT / whatever)

# minisedw -f fixnasm.sed invaders.asm >inv-nasm.asm
# nasm -O3 -o inv-nasm.com inv-nasm.asm
#
# (crc32)
# DEC4AF7B  INV-NASM.ASM
# 8983C5D9  INV-NASM.INC
# FFF22EF9  INV-NASM.COM
1i\
%idefine offset\
%define LEA MOV\
%define B byte\
%define W word\
%include "inv-nasm.inc"
/ DD /s// DW 0,/
/ D[BW] /{
h
s/^\([A-Z][^ ]*\) *D\(.\) .*/%define s_\1 \2/w inv-nasm.inc
g
b
}
/^;/b
/LEA /b
/CODE_SEG/d
/END/d
/ PROC /s/ *PROC .*/:/
/ES:\[/s//[ES:/
/40:/s///
/\[0\]/s///
/,O/b
/Word Ptr /s///
/[+]BX/s/\[\(.*\)[+]BX/s_\1&/
/\[[1-9]\]/s/\([A-Z][a-zA-Z][a-zA-Z][^ ]*\)\[\([1-9]\]\)/s_\1[\1+\2/
/,/s/\([A-Z][a-zA-Z][a-zA-Z][a-zA-Z0-9]*\),/s_\1[\1],/
/,/s/,\([A-Z][a-zA-Z][a-zA-Z][a-zA-Z0-9]*\)/,s_\1[\1]/
/[ID][NE]C/s/\([ID][NE]C\) *\([A-Z][^ ][^ ][^ ]*\)/\1 s_\2[\2]/
/^RemoveNewInt9:/,/CLC$/s/\[\([^0]\)/[cs:\1/
# EOF


> It accepts data files (e.g. *.ASM) in CRLF format but not *.SED scripts.

Ah, i forgot to handle line continuations in DOS CRLF format *.SED scripts.

Thanks for the example, that helped!

I posted minised116c.zip which should fix these issues in the dev86 BCC build.

You're right, the dev86 C library is buggy. Yet BCC is small and cute, and i like it better than my shareware copy of Desmet-C.

> You're right, the dev86 C library is buggy. Yet BCC is small and cute, and
> i like it better than my shareware copy of Desmet-C.

Someone did find DeSmet C and GPL'd the sources, but there was no official release.

> Someone did find DeSmet C and GPL'd the
> sources, but there was no official release.

I think it's cool that they did so and i have looked through the sources. The last time i did, i was troubleshooting some misbehavior in a BCC-compiled program. I compared BCC's C library to Desmet-C, and that helped me figure out what was going wrong.

> > You're right, the dev86 C library is buggy. Yet BCC is small and cute,
> and
> > i like it better than my shareware copy of Desmet-C.
>
> Someone did find DeSmet C and GPL'd the
> sources, but there was no official release.

I already knew this site, but did some research about the author now.

This "someone" also hosts http://www.picemulator.com/

He used "wacoutu" as a nick at hex2asm and signed his post with "Bill".

From 2008 to 2010 he had a blog at
https://personallyinteresting.blogspot.com/2008/10/welcome.html

https://personallyinteresting.blogspot.com/2009/10/personal-computing-history-part-1.html leads to http://www.datapackrat.com/source/vim.html, which looks similar to the other sites. VIM ("VIM stands for VIrtual Machine.") docs and source read William Couture.

Bill is also on LinkedIn: https://www.linkedin.com/in/bill-c-8953868/

---
Forum admin

> I posted minised116c.zip which should fix these issues in the dev86 BCC
> build.

There's also a bug in the BCC build (minised.com) that is not in the OpenWatcom build (minisedw.com):


minised -n -e "$=" file.txt
sed: no such command as "$="


This seems to apply to most commands via -e (e.g. -e "1p" or -e "6q").