4 ms·

Very brave author. I have contributed a few patches to WINDRES to fix some bugs and it's a strange tool / concept. I'm going to guess that Microsoft won't wis

by rwmj 2y ago

Very brave author. I have contributed a few patches to WINDRES to fix some bugs and it's a strange tool / concept. I'm going to guess that Microsoft won't wish to fix any bugs in RC.EXE, since that would break some existing resource scripts, and at this point backwards compatibility is much more important than dealing with quirks. Edit: Reminds me a bit of my adventures with the Registry, another ill-conceived part of Windows: https://rwmj.wordpress.com/2010/02/18/why-the-windows-registry-sucks-technically/ https://rwmj.wordpress.com/2010/02/18/why-the-windows-regist...

squeek502 2y ago
I think everything labeled 'miscompilation' could be fixed without breaking backwards compatibility, since triggering them always leads to an unusable/broken .res file. No clue how likely it is they'll be fixed, though.
- o11c 2y ago
  You're assuming that anything will notice if the .res file is broken, though. It might add a .res because "that's what Windows programs are supposed to do", or "only old versions of the program actually used that", or "everybody knows it crashes if you use that menu option, so don't use it." But the build still depends on the compilation of resources succeeding.
  - squeek502 2y ago
    For the miscompilations, the fix wouldn't add a new compile error. Instead, rc.exe would just start doing the right thing in certain scenarios, so previously broken things would start working. For example, padding bytes that were previously missing would get properly added. It's always theoretically possible that someone, somewhere is somehow relying on such a miscompilation, but for many of the ones detailed in the article, it seems extraordinarily unlikely.
    - sigseg1v 2y ago
      [dead]
layer8 2y ago
The concept is actually great, having declarative GUI components compiled into efficient binary representations, and allowing named values to be shared in a single-point-of-definition style with the code that will be handling those components at runtime.

by rwmj 2y ago

squeek502 2y ago

I think everything labeled 'miscompilation' could be fixed without breaking backwards compatibility, since triggering them always leads to an unusable/broken .res file. No clue how likely it is they'll be fixed, though.

o11c 2y ago
You're assuming that anything will notice if the .res file is broken, though. It might add a .res because "that's what Windows programs are supposed to do", or "only old versions of the program actually used that", or "everybody knows it crashes if you use that menu option, so don't use it." But the build still depends on the compilation of resources succeeding.
- squeek502 2y ago
  For the miscompilations, the fix wouldn't add a new compile error. Instead, rc.exe would just start doing the right thing in certain scenarios, so previously broken things would start working. For example, padding bytes that were previously missing would get properly added. It's always theoretically possible that someone, somewhere is somehow relying on such a miscompilation, but for many of the ones detailed in the article, it seems extraordinarily unlikely.
  - sigseg1v 2y ago
    [dead]

layer8 2y ago

The concept is actually great, having declarative GUI components compiled into efficient binary representations, and allowing named values to be shared in a single-point-of-definition style with the code that will be handling those components at runtime.