@kaveman

Yes. I was mentioning this to @cks the other day.

https://tty0.social/@JdeBP/116030855863806427

I think that it came out in the early 1990s. The copyright dates in the source uniformly say 1983, which would make OpenWatcom vi the earliest vi clone on record (pre-dating #STEVIE by 4 years).

However, they say this uniformly, even for its OS/2 and Windows NT parts, which couldn't have existed in 1983. And 1983 pre-dates even Waterloo C. So I suspect some Sybase lawyer has lied in these copyright declarations.

Watcom had a non-vi multi-window and menus TUI editor for DOS named wbed.exe at one point.

#Watcom #OpenWatcom #vi #retrocomputing #ComputerHistory

@cks

OpenWatcom vi is source available.

https://mastodonapp.uk/@JdeBP/116052015020764901

Ritter's Heirloom #vi is in #FreeBSD ports today, coming from the same place that it has for a long time.

https://freshports.org/editors/2bsd-vi/

It was dropped from #ArchLinux because it did not compile and hadn't changed in 20 years. Ironically, this is because the (GNU) C language had changed, and it has to nowadays be compiled forcing an older GNU C language version.

https://bbs.archlinux.org/viewtopic.php?pid=2285124#p2285124

Several people have independently discovered the Makefile patch that gets it to build on #Debian and the like.

https://forums.debian.net/viewtopic.php?p=629775

https://gist.github.com/cwfoo/01abac5c39f398b7e7b16a2b87aa518b

#elvis, the precursor to #nvi, is packaged for both #NetBSD/ #pkgsrc and #OpenBSD.

https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/editors/elvis/index.html

https://github.com/openbsd/ports/tree/master/editors/elvis

#retrocomputing #ComputerHistory #Watcom #OpenWatcom

On #Illumos, Joy vi is in /usr/src/cmd/vi:

https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/vi

On #OpenBSD, Bostic #nvi is in /usr/src/usr.bin/vi/vi; #NetBSD having it in /usr/src/external/bsd/nvi; and #FreeBSD in /usr/src/contrib/nvi:

https://cgit.freebsd.org/src/tree/contrib/nvi/

FreeBSD has an nvi2 in ports:

https://freshports.org/editors/nvi2/

OpenBSD has elvis in ports:

https://github.com/openbsd/ports/blob/master/editors/elvis/pkg/DESCR

Ritter's Heirloom vi is on SourceForge:

https://ex-vi.sourceforge.net

STEVIE was posted to comp.sources.unix in 1988:

https://sources.vsta.org/comp.sources.unix/volume15/stevie/

Unfortunately, Sven Guckes's vi Clones WWW site was never completed with some of this, notably lacking Heirloom vi, for example.

https://guckes.net/vi/clones.html

But it does mention oft-overlooked commercial clones such as Watcom's vi, a from-scratch implementation started in 1983 that is also now source-available:

https://github.com/open-watcom/owp4v1copy/tree/master/bld/vi

#vi #retrocomputing #ComputerHistory #STEVIE #elvis #VIM #NeoVIM #Watcom #OpenWatcom

@cks

It's not even a hot take. It's actual history.

STEVIE came from the days when people were re-inventing Joy vi for other platforms and systems with (gasp!) arrow keys and console-paradigm I/O.

It was less than a decade until people were thinking that Joy vi could be improved and were actively trying to make things that were better.

Watcom vi, for another example, came out in the early 1990s and that had windows, and uses for function keys.

#vi #STEVIE #vim #OpenWatcom

@pesco I interpret the standard the same way you do, yielding a result of 910.

If you are #OpenWatcom, though, the answer is divide overflow!

x86 div instructions take a dividend that is twice as wide as the quotient or remainder. In 16 bit mode the relevant ones are,

• DIV: u32 / u16 -> u16
• IDIV: i32 / i16 -> i16

What OpenWatcom does is:

• sign extend -32768 (0x8000) to 0xffff8000
• DIV 0xffff8000 / 36
• die horribly on divide overflow

If it wanted a signed result it should have used IDIV. If it wanted an unsigned result it should have zero padded the operand instead of sign extending. Seems like a codegen bug.

I should probably check if the latest version of OpenWatcom still does this, and if so, see about reporting it. It isn't the only weird result I noticed in OpenWatcom's math, either.

On the plus side I seem to have corrected lots of #DesmetC mul/div/mod bugs in one fell swoop by rewriting the relevant part of its codegen, lmao. So many type hacks, gone.

On the minus side, I think now I might be finding some bugs in #OpenWatcom C, which was supposed to be my infallible test oracle, dammit ;D