Hacker News Reader

Comment by Stratoscope | Hacker News Reader

Having worked with both CP/M and DOS back in the day, I'm pretty sure you are correct.

This does bring back fond memories. In the early days of Windows 1.x, the way to get debug/log output was with the OutputDebugString() function. This wrote the output to the AUX device, which would be a serial terminal or printer. I didn't have one of those, but did have the IBM Monochrome display sitting idle while Windows ran on the CGA or EGA display.

So I wrote a little DOS driver called AUX.SYS (with source code in AUX.ASM) to redirect AUX output to the Monochrome display.

That did not work very well! I couldn't even edit my source file.

After a while I figured out the problem and renamed the driver to OX.SYS and OX.ASM for the source. Homophones to the rescue!

View on HN

I found the source code! For your retrocomputing pleasure:

https://github.com/geary/OX.SYS

And as usual, Raymond Chen has some insights on why these special filenames "worked" regardless of file extension or directory location:

https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42...

hey, this is super cool. do you suppose it works in modern freedos as well

You are very kind to say that, thanks!

I have no idea whether it works in FreeDOS, and I don't have a monochrome display to test it on. But if you try it, I would be very curious to know if it works! (You can reply to this message and I will get notified.)

For what it's worth, OutputDebugString() still exists and works in Windows 10. It just displays the text in the Visual Studio output window, but it's neat how much Windows 1.0 code will work without too much modification on Win10.

Microsoft go to great lengths to do everything possible to make that backwards compatibility happen.

only after the last 32-bit version of Windows 10 goes out of support will some of these things begin to get fixed. and even then it will not be a priority.

This isn't just for backwards compatibility, OutputDebugString is a crucial function and hasn't been replaced with anything afaik. We use it all the time. Why fix something that isn't broken I guess?

Indeed, that is the very definition of backward compatibility.

This is closer to forward compatibility: your program written for Windows 10 will work as expected on Windows 1.0! Well, at least the OutputDebugString parts.

No. It’s not. If it was superseded, and still kept in, that’s backward compatible.

You can also view it using Sysinternals DbgView or a debugger. This comes in really handy when you want some output from something that doesn't have stdout available, like a DLL.

I have about a dozen horror stories about being sent on-site to assist a customer who was having a massive production outage, only to discover that they were "smothering" all exceptions in a global handler... (because the hosting platform their components ran in was notorious for generating thousands of useless exceptions)

With no logging... But invariably, they would not want log files created in their production environment...

So, we would add at least an OutputDebugString() to the catch... prepare a build - then in the production environment we would use the Sysinternals "DebugView" to find out why things were breaking... (And typically - it was a missing dependency or DLL version miss-match from dev to production)

Fun times.

https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.

Reply on news.ycombinator.com