5 ms·

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 m

by 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.

by rpeden 5y ago

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.