>That example isn't due to static linking, it's because they chose a particular style of dialog which is deprecated and cannot be updated without breaking backwards compatibility.
I'm not sure what this means though:
"it's because they chose a particular style of dialog which is deprecated and cannot be updated without breaking backwards compatibility."
So you mean something like the Windows API featured 2-3 different dialog styles and they set some option / flag in their code to use one that was subsequently not updated by MS?
Could be. But at least the dialog style could change, it seems in Windows API all drawing is hardcoded, so the dialog also comes with the old style buttons etc.
MS should have continue to offer the dialog styles they once had as options instead of deprecating them. But even failing that, they should at least made it so that their graphical elements (sub-widgets like buttons, text fields etc) are kept updated. That doesn't involve changing the API or binary compatibility will the calling program.
Also, seeing those dialogs in old shareware/commercial programs when run on modern Windows is one thing. But one also sees them in some very-rarely-updated MS applications that MS ships with Windows. At least you did, until Vista (haven't used Windows since).
Another infuriating thing from Windows dialogs of old --that still appear in apps: when the size of text-entries, icon fields etc is too small, but the dialog is not resizable.
"it seems in Windows API all drawing is hardcoded, so the dialog also comes with the old style buttons etc.
"
IIRC, the particular style allows applications to paint on top of the system dialogs, add controls, etc. The API call cannot know when or where drawing will take place (or whether it will happen at all), so it cannot use any other screen real estate than what it always used. That means controls must stay the same size and exact location. That rules out shadows, font changes, etc, so the control must forever stay as it was in the dark ages.
I'm not sure what this means though:
"it's because they chose a particular style of dialog which is deprecated and cannot be updated without breaking backwards compatibility."
So you mean something like the Windows API featured 2-3 different dialog styles and they set some option / flag in their code to use one that was subsequently not updated by MS?
Could be. But at least the dialog style could change, it seems in Windows API all drawing is hardcoded, so the dialog also comes with the old style buttons etc.
MS should have continue to offer the dialog styles they once had as options instead of deprecating them. But even failing that, they should at least made it so that their graphical elements (sub-widgets like buttons, text fields etc) are kept updated. That doesn't involve changing the API or binary compatibility will the calling program.
Also, seeing those dialogs in old shareware/commercial programs when run on modern Windows is one thing. But one also sees them in some very-rarely-updated MS applications that MS ships with Windows. At least you did, until Vista (haven't used Windows since).
Another infuriating thing from Windows dialogs of old --that still appear in apps: when the size of text-entries, icon fields etc is too small, but the dialog is not resizable.