There’s more to workflow than hitting F5 in the IDE


Commenter Stu suggested that instead of having code to auto-correct dialog templates, why not have a program that corrects them at build time? That way, Windows wouldn't have to make all these accommodations for programs that didn't understand the new dialog template requirements for property sheet pages.

For one thing, this model assumes that all dialog templates come from Win32 PE resources and aren't generated at runtime or loaded from other files not in resource format. For those cases, you still need the runtime fixup, so this solution would be a supplement to the existing one rather than a replacement.

Even if you cover your ears and pretend that all dialog templates come from Win32 PE resources, you still have a problem. Certainly such a program could have been written, and people could have added it to their project as a postbuild step (Fix­Property­Sheet­Templates.exe $(Output.Directory)\myapp.exe), and if you really want to, you can write this program yourself and add it to your build process. But you're also assuming that this is the entire workflow.

After the myapp.exe program is built, you have to hand the program off to your translation team for them to translate all the resources, and the translation program they use crashes or otherwise rejects these "corrupted" dialog templates. Now you have to change your workflow so you save the original "broken" version of myapp.exe and give that to your translation team, then have to remember to re-fix it when they return it. If your existing workflow consisted of the translation team handing the translated program directly to your QA team, well now you have to insert another step into the workflow where the binary comes back to the development team so it can have its final touch-up applied before being sent back out.

Sure, you could manage this too, but after you deal with all of these tiny issues, you find yourself with a dozen additional tiny issues to deal with, and then you'd just wish that the fix was made in the operating system to save everybody on the planet all this hassle.

(And then later you discover that when you load myapp.exe into your IDE, it reports that the dialog templates are corrupted and refuses to let you see them. Now you need a Damage­Property­Sheet­Templates.exe program to undo the fix!)

Comments (10)
  1. Dan Bugglin says:

    Not to mention this requires the program to be re-built with the new compiler.  This may never happen due to a number of factors, including "our compiler works fine, we don't need to upgrade" and "we lost the source code years ago, no more changes to the app sorry" and "oh that company went under years ago, no new releases".

  2. Anonymous says:

    I think the big mistake is the assumption that this is some big hack with exception handling. It sounds to me like it's just a single statement — "if (!FlagSet(dlg)) SetFlag(dlg);" — with the exception handling all happening in the kernel because the page is copy-on-write.

    It could hardly be simpler, and having a single statement compiled into the OS that fixes the problem for everyone is much better than having some complicated post-build steps that everybody has to deal with individually.

  3. Mordachai says:

    @Gabe – agreed, plus, looking back at Raymond's original article, I can't even get VS2010 to set those flags on my dialog resource anyway.  And it's very useful, for example, to keep a caption in my dialog resource (even though it's meaningless at runtime) because it helps to clarify what page of the property sheet I'm dealing with.

    If it were important, VS2010 would make it straight-forward to specify a dialog as a property page, and then enforce the correct flags going forward (doesn't change what the OS needs to deal with).  But even as of the current version of VS2010, it still doesn't enforce the correct rules (or even give you a good way to know what they are).  Hence: it can't be very important.

  4. Anonymous says:

    I have to admit if I were on the Windows team circa 1994 my response would have to been to grab the resource compiler's source and add support for the flag, along with whatever dialog box creation tool I was using.

  5. Anonymous says:

    Joshua: Presumably, the resource compiler comes from the Developer Tools division, which is organizationally very far from Windows division, and also have their own release schedule. Yes, it's possible for one team to push for features in another team's product, but it's not trivial. And it's certainly not trivial to make them release a tool out-of-band!

    And yes, the developer experience is often neglected with framework builders. In a former product, we had a small built-in web server, and the devs wanted some weird format for embedded images and scripts, degrading the web dev experience to running scripts to convert normal paths to that weird format. I managed to stop that.

  6. JamesNT says:

    Seriously.  Most of the "ideas" people post on how things should be done seem to always fail to consider that Microsoft's software is literally run by hundreds of millions of people worldwide all with different needs.  They also fail to consider the many different languages that Windows must be translated to.

    Indeed, it seems some (if not many) suggestions circle around just making things easier for the person who made the suggestion – screw Microsoft, other vendors, and all to often, screw the customer, too.

    JamesNT

  7. Anonymous says:

    @JamesNT

    At least, they suffer the consequences of their way of thinking. Seems fair to me :)

  8. Anonymous says:

    Not sure what's going on, but the blog appears to have eaten the comment I just wrote.  Will try again in a minute if this one works…

  9. Anonymous says:

    @Joshua – I take it you weren't a Windows developer in '94.  If you were, you should remember that things were very different then compared to now.  MS's development tools were just one option, and not even the most popular one.  Borland and Watcom's C++ compilers were both, IIRC, more popular than MS's.  And each of them had their own resource generation workflow — I used to use Borland's Resource Workshop, which generated .res files directly rather than producing a .rc file and getting the resource compiler to compile it, so that would have needed updating too.  I guess Watcom had something similar, too.  So MS can't just unilaterally upgrade the format and expect other people to support the new format immediately, because they need to give the other compiler vendors time to update too.  Producing 32-bit executables was enough of a big deal, and that had been available for over a year in the form of NT 3.1.  They can't ask developers to switch development environments, because it was by no means clear that 32-bit Windows was going to be a big success (OS/2 could easily have become more popular), and some percentage of them just wouldn't have thought it was worth it.

  10. alexcohn says:

    What I still don't understand, is why fixing these style bits must be done on the dialog template itself. Could it not be a feature of user32 to create the window with contextually-filtered styles (adding and removing bits as necessary).

    [That would mean that a low-level component (user32) has special knowledge about a high-level component (property sheets). "Why does the HeapAlloc function require me to pass the HEAP_ZERO_MEMORY flag? Could it not be a feature of the heap manager to infer contextually whether the memory needs to be zero-initialized?" -Raymond]

Comments are closed.