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.
@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,
What OpenWatcom does is:
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
"I spent last weekend getting Windows 95 running on my Mac. I wanted to write C programs for it. I don't have a good reason why." #Windows95 #OpenWatcom
https://tlxdev.hashnode.dev/writing-windows-95-software-in-2025
I fell in another rabbit hole and now I'm migrating my DOS program from DOS4/GW to PMODE/W :) #openwatcom
I've pushed myself a bit and tossed a rough tutorial on cross-compiling for #Windows3, #WindowsNT, #Windows95, and #MSDOS with #OpenWatcom up on the web zone: https://indigoparadox.zone/tutorials/watcom.html
It's late, so I don't trust my proofreading, but I've been asked about this enough where a quick and dirty tutorial has become a practical consideration. Hopefully it's useful!
This week on the blog: finishing up my tour of OpenWatcom by finding places its codegen struggles in the Tiny memory model. A bunch of my old DOS programs intended to ship as .COM no longer built or ran properly except as .EXE, and fixing this lets me dig much deeper into how both Borland and Watcom build their programs to conform with 16-bit DOS norms.
After some delay I did an update of #lib16 (a tiny helper library for #OpenWatcom 16-bit DOS programs).
https://github.com/SuperIlu/lib16
This time I added #Lua to the mix (example prj04). You can now write graphical scripts using Lua on #MSDOS. I also included the regular lua.exe and luac.exe binaries. This is compiled for i386/387 upwards...
![require "prj04/func"
FG_COL_IDX = 32
BG_COL_IDX = 0
X_SPACING = 8
MAX_WAVES = 4
Theta = 0.0;
Amplitude = {}
Dx = {}
YValues = 0;
function Setup()
local w = width + 16; -- Width of entire wave
for i = 0, MAX_WAVES do
Amplitude[i] = (math.random(10, 30))
local period = math.random(100, 300)
Dx[i] = ((math.pi * 2 / period) * X_SPACING);
end
YValues = {}
NumYValues = math.floor(w / X_SPACING)
for i = 1, NumYValues do
YValues[i] = 0
end
end
function Draw()
CalcWave();
vga_wait_for_retrace()
vga_filled_rect(0, 0, width, height, BG_COL_IDX)
vga_wait_for_retrace()
RenderWave();
end
function CalcWave()
Theta = Theta + 0.02
for i = 0, NumYValues do
YValues[i] = 0;
end
for j = 0, MAX_WAVES do
local x = Theta;
for i = 0, NumYValues do
-- Every other wave is cosine instead of sine
if j % 2 == 0 then
YValues[i] = YValues[i] + math.sin(x) * Amplitude[j];
else
YValues[i] = YValues[i] + math.cos(x) * Amplitude[j];
end
x = x + Dx[j];
end
end
end
function RenderWave()
for x = 0, NumYValues do
vga_circle(x * X_SPACING, height / 2 + YValues[x], X_SPACING, FG_COL_IDX)
end
end
vga_init()
vga_grayscale_palette()
Setup()
while true do
local k = getkey();
if k == KEY_ESC then
break
end
Draw()
end
vga_exit()](https://files.mastodon.social/media_attachments/files/114/376/840/897/430/522/original/a58d8ee7ec60181d.png)
Open Watcom 2.0 - 2025-04-01 Build
https://github.com/open-watcom/open-watcom-v2/releases/tag/2025-04-01-Build
Open Watcom 2.0 2025-03-01 Build
https://github.com/open-watcom/open-watcom-v2/releases/tag/2025-03-01-Build
🚀 NEW on We ❤️ Open Source 🚀
Jim Hall takes us on a journey through C compilers! Explore the unique quirks of TurboC and Open Watcom, and see why “not everything is GNU C.”
Read now:
https://buff.ly/3E4vhib
@fozztexx My memory sucks, but I know I didn't compile my own OpenWatcom.
Still, I had weird issues compiling some C89-ified code for DOS. I have a fairly-simple app and I tried to compile for the tiny or small memory models, because a 48 KB binary on DOS sounds sacrilegious. Letting the compiler pick a memory model was the correct answer for me. Maybe you should try forcing it to large or huge.
I don't have an explanation, but that's happened to me.
One other thing I noticed, I couldn't pull a .c file from a sub-subdirectory. I had to change into that and pull files from a "cousin once removed" directory. That also makes no sense, but you're free to check my MAKE.BAT file for clues. https://github.com/rhymeswithmogul/aprs-weather-submit/blob/main/make.bat
Spending some of my #christmas #vacation #geeking around with #vintagecomputing and getting reacquainted with developing software for #msdos. Last time I did that must have been in the early #90s before I discovered #Linux.
So far I've given the #djgpp C compiler a go, but it seems a little messy and keep throwing internal errors. #OpenWatcom v2 seems promising, but has a horrible way of doing interrupt calls. The #borland suites seems outdated, but does come with a lot of libraries that the others don't have. I don't believe it can generate protected mode executables though.
Im actually only looking to do a couple of simple tools, and perhaps some sort of menu/launcher that can scan recursively for configuration files. For the ladder, word around the campfire is that #pdcurses is pretty good at drawing menus and other components in text mode. I'll investigate! Would be a new experience NOT starting by writing my own library for addressing the text mode screen directly.. AGAIN.. 😜
@nulleric well, I just had a quick google search and I found #Adaptec documentation for #ASPI.
So I'm wondering if I could interface that using #OpenWatcom and a simple text UI...
I've never done low level #SCSI programming, but I should have an Adaptec card somewhere and I could rip out my #BlueSCSI out of my mac...
Should be an interesting little project,, but I don't know when I might find some time for that...
Today I have received my #book8088, an IBM XT clone like laptop, with a #8088 compatible CPU.
Everything worked out of the box with #msdos 6.22 and some software from 35+ years ago.
Pure #retrocomputing 🥰!
I cloned the 512 MB CF card to have a backup and added my own #DOS sample apps.
They started as expected ... very very slow (4.7 MHz), but it worked.
So now I have proof that all I did create with #openwatcom and #dosbox is really running on 40 year old x86 machines.
Open Watcom V2 - This is the v2 fork of the Open Watcom suite of compilers and tools.
https://github.com/open-watcom/open-watcom-v2
Since years I use
`struct s value = {0};` in C to zero-initialize struct variables on the stack.
But when I analyzed #openwatcom map files that show code and data consumption, I saw some unexpected peaks.
Looks like C compilers are allowed to generate static zero-data-blobs to copy them over the target for this kind of initialization.
So a 1KB struct generates a 1KB zero-init shadow.
Another #dos and #retro dev-lesson learned: `memset()` is our friend :)
15 KB of useless overhead eliminated.
After several failed attempts to perform a switch to a separate stack on the #DOS platform inside #DOSBox, I realized the problem was coming from the compiler.
#OpenWatcom requires the `-zu` option to allow external stack segments, otherwise access to local and global data is messed up.
This knowledge opens up features like cooperative multitasking.
It's fun to explore these historic areas the #DIY way with C code.
I wish I had worked in dev business 30 years ago, when that stuff was new.
I use #DJGPP in #WSL2/#Ubuntu on Win10 for compiling, #VSCode as editor and DOSBox-X and @DOSBox_Staging for testing.
I have also #OpenWatcom installed for 16bit DOS.
I have a networked AMD K6-2 500MHz with #FreeDOS/#Win98 under my desk (connected to a capture card so I don't need an extra monitor).
This setup works for me for all my #MSDOS projects...
Thanks to #OpenWatcom my time machine can now reach the early 90s: the #16bit #Windows #retro world.
It needed to write a lot of patches and stubs to integrate those antique APIs until one build process completed.
I totally underestimated how different Win16 is compared to Win32.
Now I face the problems of this era: crashes.
Who was responsible for an "Ignore" button on an error dialog showing "illegal instruction"?
If you press it you see the message again with the following mem-address.
