4 ms·

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, th

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!

rpeden 5y ago
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.
- naikrovek 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - ptr 5y ago
    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?
    - Stratoscope 5y ago
      Indeed, that is the very definition of backward compatibility.
      - dmurray 5y ago
        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.
      - megablast 5y ago
        No. It’s not. If it was superseded, and still kept in, that’s backward compatible.
- ssklash 5y ago
  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.
- jjkaczor 5y ago
  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.
- dbremner 5y ago
  https://github.com/dbremner/cake 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.
Stratoscope 5y ago
I found the source code! For your retrocomputing pleasure: https://github.com/geary/OX.SYS 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=42073 https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42...
- kragen 5y ago
  hey, this is super cool. do you suppose it works in modern freedos as well
  - Stratoscope 5y ago
    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.)

rpeden 5y ago

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.

naikrovek 5y ago
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.
- deleted 5y ago
  [deleted]
- ptr 5y ago
  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?
  - Stratoscope 5y ago
    Indeed, that is the very definition of backward compatibility.
    - dmurray 5y ago
      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.
    - megablast 5y ago
      No. It’s not. If it was superseded, and still kept in, that’s backward compatible.
ssklash 5y ago
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.
jjkaczor 5y ago
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.
dbremner 5y ago
https://github.com/dbremner/cake 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.

Stratoscope 5y ago

I found the source code! For your retrocomputing pleasure: https://github.com/geary/OX.SYS 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=42073 https://devblogs.microsoft.com/oldnewthing/20031022-00/?p=42...

kragen 5y ago
hey, this is super cool. do you suppose it works in modern freedos as well
- Stratoscope 5y ago
  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.)