#watcom

2026-02-12

@kaveman

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

tty0.social/@JdeBP/11603085586

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

2026-02-12

@cks

OpenWatcom vi is source available.

mastodonapp.uk/@JdeBP/11605201

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

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.

bbs.archlinux.org/viewtopic.ph

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

forums.debian.net/viewtopic.ph

gist.github.com/cwfoo/01abac5c

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

ftp.netbsd.org/pub/pkgsrc/curr

github.com/openbsd/ports/tree/

#retrocomputing #ComputerHistory #Watcom #OpenWatcom

2026-02-11

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

github.com/illumos/illumos-gat

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:

cgit.freebsd.org/src/tree/cont

FreeBSD has an nvi2 in ports:

freshports.org/editors/nvi2/

OpenBSD has elvis in ports:

github.com/openbsd/ports/blob/

Ritter's Heirloom vi is on SourceForge:

ex-vi.sourceforge.net

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

sources.vsta.org/comp.sources.

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

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:

github.com/open-watcom/owp4v1c

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

2025-11-09

If you are interested in the broad range of vi clones that have existed (and still exist) over the decades, one of the better resources on the subject was published by Sven Guckes:

guckes.net/vi/clones.html

I hope that someone takes up the mantle here, because M. Guckes collected more information than the O'Reilly book had, and there's more to be had from the decade since.

#nvi #elvis #stevie #calvin #vi #vim #neovim #winvi #Watcom #ex #nex #view #nview #BillJoy #BramMoolenaar #KeithBostic #SvenGuckes

2025-10-17

Некрокомпиляция или как собрать OpenWatcom для QNX4 под Debian 12 и прикрутить его к Eclipse

Меня зовут Ярослав Бомбов и я более 30 лет занимаюсь созданием АСУТП. Как вы понимаете жизненные циклы в АСУТП штука длительная и иногда возникают задачи что-то добавить в систему работающую уже лет 20. И именно такой случай произошел - возникла необходимость изменить код в контроллере под управлением QNX4. Можно конечно было поговорить на тему "вы в каком морге этого Франкенштейна получали туда и обращайтесь", но при ближайшем рассмотрении оказалось что код мой собственный ;). Самое простое решение открыть mcedit, что-то поправить и собрать в самом QNX4, но для начала надо вспомнить разобраться как все работает, а это удобней делать в современных IDE. Поиск бинарников OpenWatcom (OW) под линукс дал ровно два архива которые в моей системе не заработали. Поэтому решено действовать по принципу - лучше день потерять, потом за пять минут долететь. Полетели

habr.com/ru/articles/957428/

#QNX_425 #Watcom #Eclipse #makefile

2025-07-21
a young deer checks me out from a field

#deer #nature #antlers #pnw #seattle #bellingham #mountBaker #watcom
A deer with fuzzy antlers in a field of flowers.
Jun Nergahak 🌺🌺🌺nergahak
2025-04-01
Clarissa | making Enigma HeartClarusPlusPlus@gamedev.lgbt
2025-03-17

Developing that game sure was fun, though.

(For differing values of "fun")

#GameDev #DOSgaming #Programming #Watcom

A DOS text screen showing Acronia's startup sequence, followed by a crash dump.A VGA screen filled with white gibberish text mode characters.
Jun Nergahak 🌺🌺🌺nergahak
2025-03-02
The Last Psion | Alexthelastpsion@oldbytes.space
2025-02-07

Mini-rant ahead:

I'm delving into #cmake to try to make it build a compile_commands.json file to work with #retrocomputing C header files, specifically the #Psion SIBO C SDK (from the early 90s).

I don't actually want cmake to do anything but tell clangd what to do, so that I've got a working language server in NeoVim.

I don't need it to build any Makefiles, I don't need it to tell a compiler what to do. I just want clangd to treat my old 16-bit real mode code correctly, and that the header files are in ~/dosbox/sibo-c/SIBOSDK/include/.

Note that I can't point it at the compiler, because the compiler (TopSpeed) runs in DOSBox. There is no modern compiler that will work.

So... Do I have to fake it somehow? For example, do I have to tell cmake that it's actually using a different compiler (e.g. #Watcom) to make it behave correctly? And if I do, will that matter to clangd?

2025-01-03

I liked the simplicity of #QRCode library github.com/ricmoo/QRCode and wanted to use it in my projects too.

But due to my "special" (old) compilers, some changes were required. With the back-port to C90, it builds for #DOS :msdos: via #Watcom.
#CMake adds shared Win/Linux libraries, CTest unit tests and a small `qrgen` command line tool.

One task is still open: Check if the original #Arduino target is still working ...

However, results are now on #Codeberg
codeberg.org/gatelinker/QRCode

The Last Psion | Alexthelastpsion@bitbang.social
2023-09-03

Reading through the first manual in the SDK has reminded me what the "pure small memory model" is.

The ES register is never corrupted (DS=ES=SS).

#TopSpeed C implemented this, which was one of the main reasons why #Psion used it for the SDK.

I've heard that it's possible to implement this with #Borland C (and maybe #Watcom?), but I don't know how.

#16bit #retrocomputing #epoc16 #x86

From the "General Programming Manual":

int86x

iint86x is implemented by exactly the same code as int86, ie the values in the segment registers struct are ignored. This is because in the pure small model DS=ES=SS and hence there is never any need to change the values in the segment registers.A different document:

Why TopSpeed 'C'?

TopSpeed 'C' was developed by Jensen & Partners Int. (JPI) and is now owned by Clarion Inc.    Psion use this less usual 'C' because in does pure small model (the ES register is never corrupted) and because, thanks to its flexible calling conventions, it produces code 10-15% smaller than most 'C' compilers.From "PLIB Reference":

The Clarion TopSpeed C compiler

When writing C for the EPOC operating system you must use the Clarion TopSpeed C compiler.

We chose the TopSpeed C compiler because it supports a pure small model, for which the code
generator totally abstains from manipulating the 8086 segment registers. Other C compilers
occasionally save and restore the segment registers to memory when generating small model code.

As it happens there are other benefits to using the Clarion TopSpeed C compiler:

- in the EPOC environment, we have found that the code generated by the TopSpeed C compiler is
typically 20% more compact than that produced by Turbo C or Microsoft C
- it supports register-based (rather than just stack-based) calling conventions which contribute to
its compact code generation and also reduce execution times
- we have used its capability to define custom calling conventions (via #pragma statements) to
interface3 efficiently with the software interrupts of the system services (in some cases removing
entirely the need for interfacing code)

Because the functions in the PLIB library for TopSpeed C use custom calling conventions, the use of C
prototypes is mandatory.
2023-07-17

🥰 O-M-G! I love #DOSBox.

It helped me to find a stupid bug in my framebuffer code that slowed down clearing images.
Coding and compiling was done with #VSCode and #WATCOM,
and execution in DOSBox showed immediately what failed.

We don't see such bugs on Windows or Linux with our GHz CPUs anymore.
But with good old #DOS on an emulated 386 33 MHz host it made a jump from 2 to 18 FPS after fixing.

That's true optimization nobody cares about today. #gamedev before #Y2K must have been real fun.

2023-05-21

And again: Grandpa knows why.

Compiling with #watcom for #freedos showed me some code-bloat in my hardcoded static C v-tables. The referenced v-table methods cannot be eliminated by the optimizer when those structures are not used.

But shifting the initialization of v-tables into separate functions
gives compilers the option to discard all unnecessary stuff.

This seems to be true for MSVC and GCC too.

However ... smaller executables are more important on DOS than on #windows or #linux.

2022-11-02

I made significant progress in porting Ranish Partition Manager from #Borland #C and #TASM to #Watcom C and #NASM.

All the C files and about half the assembler files are translated. The Watcom built executable is running and a few quick tests revealed no unexpected behaviour. Thoroughly testing has still to be done after the remaining files are translated.

codeberg.org/boeckmann/ranish

2022-11-02

Implementation defined behaviour in #C: Folgendes packt #Borland C einen char, #Watcom in einen int:

unsigned start_sect:6;
unsigned start_cylH:2;

Daher Struktur unter Borland 16 bytes und unter Watcom 18 🤡

Es muss leider ein char sein. Watcom erlaubt folgendes, um es gerade zu biegen:

unsigned char start_sect:6;
unsigned char start_cylH:2;

Nicht erlaubt laut Standard: "A bit-field shall have a type that is a qualified or unqualified version of one of int, unsigned int, or signed int."

2022-11-01

Hier sieht man sehr schön: Unterschiedliche #Compiler, unterschiedliches Laufzeitverhalten des Programmes. Die linke Version ist mit #Borland #C kompiliert, die rechte mit #Watcom C.

Die Daten werden direkt von Platte in eine C Struktur geladen. Dabei sollte man tunlichst auf die Ausrichtung der Strukturelemente achten, sonst kommt Käse wie im rechten Bild raus.

Wen es interessiert: Eric S. Raymond hat eine interessante Abhandlung darüber geschrieben: catb.org/esr/structure-packing

2022-10-25

@profoundlynerdy There is also a #Vi clone included with the #Watcom C/C++ compilers. I Like that most when working under #DOS / #Windows.

Si bien existieron muchos productos capaces de solucionar las limitaciones de memoria de DOS, sobresalen dos compañías en particular, en una mancomunidad ganadora. La unión virtuosa del compilador de C de #Watcom International Corporation y el "Extensor de DOS" #DOS/4GW de Rational Systems permitía correr programas en Modo PROTEGIDO, a la vez que retenían en acceso a las funciones en Modo REAL de 16 bits del DOS. Las aplicaciones se la pasaban conmutando entre modo real y protegido. Esto constituía un problema en las CPUs 286 porque Intel nunca imaginó que un programa podría querer conmutar ida y vuelta entre MODO REAL y MODO PROTEGIDO. Extensor #DOS/4GW Si bien el problema era volver, en los Intel pasar de MODO REAL a MODO PROTEGIDO era simple. Solo tenías que usar 6 instrucciones mnemónicas oara colocar el Registro de Control del bit 0 al 1 y activarlo. La manera normal para realizar una "llamada de sistema" en DOS era usar una instrucción de interrupción de software con el parámetro 21H. En programación C, esto constituía una abstracción del encabezado DOS.H - encargado de llevar a cabo todo el trabajo de bajo nivel del sistema operativo. El extensor permitía hacer esto de manera más simple y transparente para el programa. Ambos mundos tenían que estar "puenteados" para permitir que un programa corriese en uno de los Modos de procesador y el sistema operativo lo hiciera en el otro. Para ello se instituía una capa intermedia denominada "Extensor DOS" - la cual era capaz de correr en ambos modos, biejecutble - y se la insertaba entre el programa y el sistema operativo. Cuando inicializabas el Extensor DOS, este colocaba llamadas en la Tabla de Vector de Interrupción del Sistema Operativo, y allí metía sus propias rutinas. Desde el punto de vista de la aplicación todo resultaba transparente, y no tenías que alterar ningún código. Para disparar las llamadas de sistema que no estaban enlazadas al Extensor (por ejemplo, si querías usar la INT33H para leer el registro del mouse), el Extensor te ofrecía la interfaz especial llamada DPMI, en la cual el interruptor 31H que se encargaba de traducir los pedidos de registros de 32 bits a 16 bits, tal que las rutinas de la Tabla de Vector de Interrupción las entendiesen. Cuando el extensor interceptaba una llamada de sistema operativo, traducía las llamadas, conmutaba la CPU al modo real y reenviaba la llamada al DOS, y recogía el resultado, y pasaba al modo protegido de nuevo, para continuar. Watcom El Extensor DOS era mágico, pero bastante difícil de presentar como producto integrado real. Lo que realmente se necesitaba era disponer de un ambiente integrado en el cual el compilador y en enlazador se encargasen de embutir tanto al extensor y como a la aplicación en sí dentro de un fichero ejecutable. La solución vendría del extremo norte. En 1979 en la Universidad de Waterloo en Ontario, Canadá comenzaron a desarrollar un compilador multiuso llamado #Watcom. Para 1987 integró el primer compilador C de DOS para la 386. Para 1993 habían alcanzado mejoras considerables: el Watcom C/386 daba código al menos el doble de velocidad que los compiladores de Borland o Microsoft, (usualmente mas). El combo Watcom/Extensor tornaba simple la programación y también resultaba en soft veloz, pero lo mas importante fue permitir la portabilidad del #código C extendido. No sólo podía programarse en C en modo real en DOS, sino portar a otras plataformas.

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst