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.
#OpenWatcom
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.
#OpenWatcom ships also #Linux binaries to generate #DOS, Win3x or OS/2 #CPP stuff there.
But it comes with an installer that requires keyboard input, which makes it unusable in docker.
Fortunately, we can take the contents of `/usr/bin/watcom` after a regular setup and copy it into a docker image. #CMake + WMake just work after running `/usr/bin/watcom/owsetenv.sh`
Now I have a Linux docker container to build my sources for DOS targets.
I need to tell my younger self in the 90s. π
Got sine text with some fake transparent effect.
Only got 3 glyphs at the moment ;)
486DX2/66Mhz/4MB RAM
Started thinking like a demoscener.
Created buffer and now just memcopy to the VGA memory.
Way faster!
Simple crazy bars.
Changed to C++ and OpenWatcom for a moment.
@niconiconi Retro-Porting to OS/2 1.0
βA few weeks ago I embarked on a somewhat crazy side project: Make the Open Watcom debugger work on #OS2 1.0. This project was not entirely successful, but I learned a couple of things along the way. [β¦]
Building the 16-bit components again was not particularly difficult. And they even mostly worked on OS/2 1.2 and 1.1. But I wanted to get the code working on OS/2 1.0 as well. Because why not.β
#OpenWatcom #16bit
https://www.os2museum.com/wp/retro-porting-to-os-2-1-0/
I've decided to let my domain lightningpython.org lapse. It was the home of my ill-fated project that allowed building stock #python using the #openwatcom compiler for Linux and Windows.
That project turned out to be a colossal waste of my time and extremely poorly received. I received exactly one piece of feedback ever: a trademark violation warning from the #python foundation.
The only positive to come out of it was that I learned to avoid ever trying to work with #python core devs.
That project turned out to be a colossal waste of my time and extremely poorly received. I received exactly one piece of feedback ever: a trademark violation warning from the #python foundation.
The only positive to come out of it was that I learned to avoid ever trying to work with #python core devs.
So, yeah, something is fishy with the OpenWatcom DOS output π
Maybe valgrind the Linux binary and check if i accidentally created some memory leak... on the other hand, it looks alright under Linux. π³
Any ideas by the other retro game devs?
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst