Solutions that require a time machine: Making applications which require compatibility behaviors crash so the developers will fix their bug before they ship


A while ago, I mentioned that there are many applications that rely on WM_PAINT messages being delivered even if there is nothing to paint because they put business logic inside their WM_PAINT handler. As a result, Windows sends them dummy WM_PAINT messages.

Jerry Pisk opines,

Thanks to the Windows team going out of their way not to break poorly written applications developers once again have no incentive to clean up their act and actually write working applications. If an application requires a dummy WM_PAINT not to crash it should be made to crash as soon as possible so the developers go in and fix it before releasing their "code".

In other words, Jerry recommends that Microsoft use the time machine that Microsoft Research has been secretly perfecting for the past few years. (They will sometimes take it out for a spin and fail to cover their tracks.)

In 1993, Company X writes a program that relies on WM_PAINT messages arriving in a particular order relative to other messages. (And just to make things more interesting, in 1994, Company X goes out of business, or they discontinue the program in question, or the only person who understands the code leaves the company or dies in a plane crash.)

In 1995, changes to Windows alter the order of messages, and in particular, WM_PAINT messages are no longer sent under certain circumstances. I suspect that the reason for this is the introduction of the taskbar. Before the taskbar, minimized windows appeared as icons on your desktop and therefore received WM_PAINT messages while minimized. But now that applications minimize to the taskbar, minimized windows are sent off screen and never actually paint. The taskbar button does the job of representing the program on the screen.

Okay, now let's put Jerry in charge of solving this compatibility problem. He recommends that instead of sending a dummy WM_PAINT message to these programs to keep them happy, these programs should instead be made to crash as soon as possible, so that the developers can go in and fix the problem before they release the program.

In other words, he wants to take the Microsoft Research time machine back to 1993 with a beta copy of Windows 95 and give it to the programmers at Company X and tell them, "Your program crashes on this future version of Windows that doesn't exist yet in your time. Fix the problem before you release your code. (Oh, and by the way, the Blue Jays are going to repeat.)"

Or maybe I misunderstood his recommendation.

Comments (76)
  1. Anonymous says:

    No, you got it about right.  Some people don't think things through or have the experience of shipping operating systems for decades.

  2. Anonymous says:

    GO JAYS! :^D

  3. Anonymous says:

    @Sunil: sounds right, better hope that Microsoft Research are solving the halting problem in their tea breaks between building the time machine. :-)

  4. Anonymous says:

    I think a more sensible variation of this suggestion (and perhaps what Jerry meant in the first place) is to have all NEW applications crash (or better, simply not receive dummy WM_PAINT messages), while maintaining compatibility with old versions. This could be done with a "whitelist" (e.g. apps with a manifest get the new behaviour) or "blacklist" (the application compatibility database).

    [What about plug-ins? A new app loads a plug-in which requires the old behavior. -Raymond]
  5. Dan Bugglin says:

    He makes the assumption that the developers of the application can and will update it for the latest and greatest Windows.  Which doesn't always happen.

    He also makes the assumption that making random programs crash that worked just fine on the old Windows will NOT negatively affect sales of the new Windows.

  6. Anonymous says:

    Sunil Joshi: here lies the whole problem, how can you distinguish between drawing and business code ?

    Even if it was possible, what would be the result ? Your Very Important Business Application developed, several years ago by some contractors, with no source code (it disappeared in the Big NAS Collapse of '01), breaks because that version of Windows got pedantic on what code can go in WM_PAINT message handlers, for some bizarre reason only understood by Microsoft and some geeks that read The Old New Thing. Good way to give new customers to the competition !

  7. Anonymous says:

    > What about plug-ins? A new app loads a plug-in which requires the old behavior. -Raymond

    Can you give me an actual example where this was/is happening? Your argument reads like an thought up excuse not like a real issue.

    [Example 1: Explorer (shell extensions are plug-ins). Example 2: Office (plug-ins are, um, Office plug-ins). Example 3: Common dialog box (which is itself a plug-in inside a host application which may have compatibility shims applied). Explorer and common dialogs struggle with this issue a lot. I suspect Office does too. I found it interesting that you consider something we struggle with constantly to be a made-up excuse. Every COM object is a plug-in. There are a lot of COM objects. -Raymond]
  8. Anonymous says:

    Why would you want to try to install Windows 95 in 1993, you can easily install Windows 3.11 in 2011…

    What i'm saying is that for one poorly written program, the user can always install (on a seperate box, or virtual machine) an OS that will run that program.

    Maybe as a bonus, another company/developer will see that as an opportunity to create a good solution. Or maybe there is already another better program available, but the user is too 'lazy' to search… because it already works!

  9. Anonymous says:

    @Mathieu Garstecki

    Quite – to make it clear I was not suggesting that Windows perform such detection; I was attempting (and clearly failing) to be ironic although I think Bob G got my drift.

  10. Anonymous says:

    The point is that if windows keep doing that, it will become unmanageable eventually.

    What is the point to maintain the OS backward compatible with an application even if the original author had no incentive to maintain it?

    [Because it takes only one program to foul an upgrade. The original author may not care, but the original customer does! -Raymond]
  11. Anonymous says:

    @Simon: Consider an application that loads a plugin DLL which subclasses your main window and modifies its WM_PAINT handler.  Now suddenly you're doing business logic in WM_PAINT when you weren't before.

    @Sunil Joshi: I picked up the irony (or is it sarcasm?) if your post, though I admit it was subtle.

  12. MarcBernard says:

    Looking forward (or is it backward?) to Microsoft Chronology System for Windows 2011 Enterprise Studio Version.

  13. Anonymous says:

    @Adam: Yeah, I do see the point. But I was asking for an actual case where this would become a problem. (And where white-/blacklisting the parent application wouldn't help)

    [You're going to white-/blacklist Explorer? What if the bad plug-in is a shell extension, injected into every process via the File.Open dialog box. Now you have to blacklist your entire computer. You've gained nothing. -Raymond]
  14. Anonymous says:

    I need to add, because nothing is obvious on the Internet, that I named a specific program and plugin for example purposes only, to make said example easier to understand instead of saying "a program" and "a plugin" all the time.  It isn't meant to imply bad behavior on the part of the fictitious plugin authors, nor the real program.

  15. Anonymous says:

    "@Adam: Yeah, I do see the point."

    If you hadn't said that Simon, you'd be an idiot.

  16. Anonymous says:

    As a somewhat related note: It has actually been encouraged to put the business logic into a paint handler. The reasoning was, "You don't want to confuse your users by not displaying your app until you have finished some startup calculations. They will think your program failed to start, and will try to launch it again, potentially causing problems. Instead, put your business logic into WM_PAINT handler, so that your calculation begins after the non-client area (that is, border of your window) has appeared, this will tell the user the application has started, and they will happily wait."

    I personally never did this, but I clearly remember the recommendation, and the source was quite credible.

  17. Anonymous says:

    Skyborne: if MS prevented foobar2000 from running […]

    We're not talking about blocking an application. We're talking about enabling the WM_PAINT-fix only for a selected set of applications much like many other compatibility shims. No harm done if your application gets too many WM_PAINT messages yet future applications will be written properly.

  18. Anonymous says:

    While you can't change the past, there ARE things you can do to help the future. Nobody[1] intentionally does silly things like put business logic in the WM_PAINT handler, and most would happily remove it if the bug is found during testing. The trick is to have a "persnickety" mode in Windows that looks for all kind of unusual things, that rearranges messages that usually arrive in a fixed order, runs heap consistency checkers often, and so forth.

    Actually, there is such a mode: it's call AppVerifier. If you're not using it during development and test, you're doing your users a disservice. (And it would do the world good for Microsoft to extend AppVerifier every time it creates a new API set.)

    — jimbo

    [1] Well, almost nobody.   (-:

    [Hey wait, if your business logic is entirely visual, then it is quite common to put business logic in the WM_PAINT handler. -Raymond]
  19. Anonymous says:

    The real problem here is that in companies this problem will surface during a windows upgrade project, causing the cost to be incurred due to a "windows upgrade", not due to bad programming. Even worse, consultants may suggest that the real fix is to rewrite those applications in latest whatever or do a full market survey before replacing the application.

    At the end of the day you could end up statying at the old windows, or even worse for Microsoft hitting a price point where they may just as well migrate to another platform like Mac OS X with wine….

    That's the kind of power buisness applications have compared to off the shelf applications.

  20. Anonymous says:

    @Jim: AppVerifier should be enabled by default in Visual Studio for example. You need intelligent defaults for stupid developers (me included).

  21. This problem is not unique to Windows, it's generic to all platforms.

    One solution is to have a "strict mode" switch on the platform which pops up assertions whenever questionable behavior is detected.  Developers develop in "strict mode"; customers run in "normal mode"; testers test both ways.

    [We already have a "strict mode" (chk builds). But people don't run them because "it asserts too much." -Raymond]
  22. Anonymous says:

    Astonishing. Apple must have a Time machine (and not the backup software kind), because they do this with every major release of OS-X. That should also explain why their stocks are worth so much right now.

    A bit of Apple's philosophy wouldn't hurt MS, and the opposite is also true (not breaking every single piece of code with 10.4 -> 10.5).

  23. jader3rd says:

    I think what Jerry was complaining about is the fact that Windows does have a history of finding a bug, fixing it, doing QA and discovering it breaks some applications, and then leaves the bug around. While I wouldn't want a fix like that come out in an Service Pack, I would like them to get fixed for new OS releases.

    This then bring up the business argument of "No will use new versions of Windows if their applications don't run on it." But if every application ever written for windows will run on any version of Windows it does beg the question of "Why would I get a new version of Windows if nothing has changed." If the application can be changed such that it will work on the original version of Windows, and on a fixed version, I think that the Windows team should fix the bug.

    I hope to see more of these types of changes, because that will (hopefully) free up the Windows team to make these improvments, because anyone needing an old application can run it in a virtual instance of the old version of Windows.

    [It's not true that every application ever written for Windows will run on any version of Windows. Your application designed for Windows XP won't run on Windows 95, for example. Compatibility typically only moves in one direction. (And virtual machines have their own problems.) -Raymond]
  24. Anonymous says:

    >>> What about plug-ins? A new app loads a plug-in which requires the old behavior. -Raymond

    >> Can you give me an actual example where this was/is happening? […]

    >Example 1: Explorer (shell extensions are plug-ins).

    >Example 2: Office (plug-ins are, um, Office plug-ins).

    >Example 3: Common dialog box (which is itself a plug-in inside a host application which may have compatibility shims applied).

    Raymond, tell me then how many of these applications/plugins/COM objects rely on the old WM_PAINT behaviour. What plugin would break? Give me names, numbers please. I can't come up with any cases where the WM_PAINT order would make a difference.

    And yes, you could blacklist Explorer and/or Office. Or not list them and let them opt-in whenever a popular, listed plugin is loaded.

    The reality is this: As you pointed out, just fixing the bug is a bad idea. Not fixing the bug is also a bad idea. Another reality is that lot's of old applications don't work correctly on current windows releases. 256-color fullscreen games for example (because Windows nowadays sometimes changes the color palette behind the games back). So why not do the right thing (the MIT approach) and force future applications to work correctly?

    [I didn't realize you were talking about WM_PAINT specifically; I thought you were talking about compatibility in general. I do not know off the top of my head the names of any programs why rely on the dummy WM_PAINT, but I know they exist because I've seen the bug reports. The one I remember is some app that encountered a divide-by-zero bug if it didn't get its dummy paint. I thought I mentioned that in the original article. Oh yes, I did. (And imagine the huge list of opt-ins applications would have to include. "No, don't send me dummy paints (but I promise I won't crash if I get them anyway)." "No, don't invalidate the screen if I pass NULL to InvalidateWindow." "No, you don't need to return exactly TRUE from IsWindow; I can handle other nonzero values." And so on. And then you'd have to add tests all through the OS for every single one of these tiny little things. IsWindow would change from "if itnernal_algorithm(hwnd)) { if (ApplicationCompatibilityFlag(ISWINDOW_MUST_RETURN_EXACTLY_TRUE)) return TRUE; else return 42; } else return FALSE;" Congratulations, you just bloated the IsWindow function. -Raymond]
  25. Anonymous says:

    I think this is really a question of philosophy.  You have two choices:

    1. Provide backward compatibility hacks that keep bad old programs running at the expense of people writing new bad programs.
    2. Break backward compatibility so that new programs will have to be written correctly at the expense of old bad programs breaking.

    Obviously choice 1 makes the most sense from a business perspective, so that's what Microsoft went with.  The upside is that Lotus Notes 1.0 will work in Windows 2038.  The downside is that Microsoft has to go out of their way to ensure that backward compatibility is maintained.  At some point in the future, the cost of maintaining that compatibility is going to be outweighed by the benefit.

  26. Anonymous says:

    @jader3rd: Not breaking backwards compatibility doesn't mean nothing changes.

  27. Anonymous says:

    @Simon – Are you expecting him to have a list of every single plug in, application, and extension, and ALSO what rules they "break"?

  28. Anonymous says:

    @Dennis:  "What i'm saying is that for one poorly written program, the user can always install (on a seperate box, or virtual machine) an OS that will run that program."

    Virtualization can be a solution, but you run into problems when you no longer want the old app to be isolated.  Perhaps you want to parse its output, or automate it, or invoke it from a brand new C# utility that your company created.

  29. Anonymous says:

    @Dennis: "Why would you want to try to install Windows 95 in 1993, you can easily install Windows 3.11 in 2011…"

    It's not always so easy. Pat solutions like this sound great in a blog comment, but implementing them for actual customers is another matter.

    "…[F]or one poorly written program, the user can always install (on a seperate box, or virtual machine) an OS that will run that program."

    What if that program needs to be part of each employee's day-to-day work, on each employee's workstation? I have a few of those on my office machine right now.

    "Maybe as a bonus, another company/developer will see that as an opportunity to create a good solution. Or maybe there is already another better program available, but the user is too 'lazy' to search… because it already works!"

    You may be confusing laziness with frugality, or a lack of interest in the latest buzzwordology, or a resistance to paying someone to write something that already exists, and works. Most people aren't interested in the explanations for why their software stopped working in Windows 7. They just want it to work, and if they have to choose between upgrading to a new OS or having their software continue to work, they'll usually choose whichever is cheaper and less disruptive. Sadly, I'm writing this from an XP machine because the "new OS" option was more expensive for this particular company.

  30. Anonymous says:

    @Simon: I'll need your definitions of 'whitelist' and 'blacklist' to understand what you're trying to tell me, because mine are not related to compatibility shims in any way.  If I blacklist a program, then it doesn't run.

  31. Leo Davidson says:

    What about plug-ins?

    Could you tie the shim to the module that registered the window, rather than the one which started the process?

    I guess subclassed windows may cause problems, so maybe the module where the window-proc or dialog-proc resides.

    Of course, this may be more complex than it's worth, even if it does work. If there isn't a big downside to the dummy WM_PAINT messages then I'm not sure why anyone cares. I mean, if the only complaint is the complexity of the Windows code-base then adding elaborate ways to break new apps without breaking old ones would surely add to the complexity, not reduce it.

    We already have a "strict mode" (chk builds). But people don't run them because "it asserts too much."

    The checked builds are useful but I think it's fairly obvious why they are not more widely used.

    It's not just that they assert too much. They assert for too many things (I only want to debug my own code, not everyone else's). More importantly, turning the "mode" on and off requires you to re-install the whole OS (or have a (real, virtual or dual-boot) machine dedicated to it).

    So you have to really want/need to use a checked build before it seems worth the time and money cost. It doesn't seem like something you'd want on machines people use day-to-day and thus isn't something you'd get good test coverage out of unless you have fully automated build, deployment and test scripts that you can fling at a dedicated test machine. Some people do have that but it reduces the potential users even further.

    There are simpler tools/modes/flags like PageHeap and the compatibility/verification tools which can be really (and realistically) useful for testing, yet which are relatively unknown. Even then, though, people rarely turn them on unless they suspect there is a problem.

  32. Anonymous says:

    @John Here's some marketing hooks:

    Windows – Full of bugs because we we're afraid of alienating a couple insurance agencies in Topeka.

    Windows – The most bloated code base in the industry so that every app you'll never use will work forever.

    Windows – We could change the world, but we'd rather make up excuses.

    [It's not just "a couple of insurance agencies in Topeka." It's "your company". And major worldwide corporations. These are apps you use. (And the challenge of Windows is changing the world without breaking the world.) -Raymond]
  33. Anonymous says:

    @Mike

    Windows – So that in house app that was written in 1993 that STILL runs your Fortune 500 company can still run.

  34. Anonymous says:

    K: Apple doesn't have a time machine; they just don't care when they break old programs. No Fortune 500 company has a mission-critical MacOS app, so who cares when old stuff breaks? Since Apple is the only company that can make hardware that runs MacOS, they can just stop making hardware that runs old versions of their OS and eventually everybody will be forced to upgrade.

    Contrast that to Windows, where anybody can make hardware that still runs WinXP, so MS doesn't have the leverage to force upgrades that Mike seems to assume. Vista was released 4 years ago, yet — if you're willing to believe Wikipedia (en.wikipedia.org/…/index.php) — XP is still the most popular OS in the world! While XP has as much market share as the following two versions combined, the latest MacOS has nearly double the market share of the previous two versions combined.

  35. Anonymous says:

    @Bob G:

    But that's easy because the Halting Problem can be reduced to having a time machine.

    (Time machine -> unbounded CPU time available in a fixed time slice -> decide HP)

  36. Anonymous says:

    Doc…. you built a time machine… out of a Delorean?

  37. Anonymous says:

    @Joshua: That's ridiculous; just don't have your dev machine connected to the internet/network.

  38. Anonymous says:

    What he is implicitly suggesting is that applications should not make any assumptions about WM_PAINT messages (i.e. put no business logic in the handlers) and that Windows should *some how* detect that an application has being doing something other than painting in response to such messages. Once Windows has detected this, the application should be terminated immediately. How Windows is supposed to detect this is an entirely different question….

  39. > But people don't run them

    I do.  And I find a lot of bugs that way.

    Do chk builds still send dummy WM_PAINT messages?

    [Imagine if they didn't. -Raymond]
  40. Anonymous says:

    "A few people would be mad and wouldn't be able to run an old app anymore.  What do you think they're going to do?  Move their whole organization to Linux or Mac just because of one app?  Even if that app is critical to their business?  What exactly is their other option?  Their critical app only works on Windows!"

    What really happens is BigCorp finds their stock control application, or whatever, doesn't work properly under Windows Vista when it did under Windows XP – so, they stay with XP. Their intranet doesn't work with IE 7 – so they ban Firefox and mandate that all new web development has to be IE 6 compatible. They use their purchasing power to demand that Dell and Sony keep making machines that run Windows XP for them, they insist their antivirus and word processing software stay Windows XP compatible – and before you know it, Microsoft's upgrade revenue has crashed, and we are all stuck developing and testing for a decade-old version of Windows, unable to use all the nice new features.

    Perhaps one day checked build will be a boot time option, and later we will reach the point where rebooting in checked mode is the first reaction to a machine misbehaving – but for now, big businesses seem to apply logic amounting to 'if it worked under version X and doesn't work under version Y, then version Y is faulty and we aren't upgrading' … and I have to admit, they do actually have a point, even if it is a case of version Y having fixed a bug that this other product relied on.

  41. Anonymous says:

    @Simon: if MS prevented foobar2000 from running because foo_obscure MAY be loaded, then they're over-blocking: everyone who is NOT running foo_obscure is unnecessarily punished for its failure.  What could foobar2000 do (assuming foo_obscure is closed-source) to allow it to run when it doesn't have foo_obscure, that would also *requires* foo_obscure to fix their problem instead of just adapting it to the new version and causing trouble again?

  42. Anonymous says:

    [We already have a "strict mode" (chk builds). But people don't run them because "it asserts too much." -Raymond]

    I'll gladly run it myself if all hotfixes are available for it. Last I checked hotfixes for checked builds cannot be downloaded. My dev box is *not* going to have swiss-cheese security.

  43. Imagine if they didn't

    Exactly… fre/chk does not suffice for a Win32 "strict mode".  chk + AppVerifier + static code analysis goes a little further down the path but there is still opportunity for further opt-in enforcement of the Win32 app contract.

  44. Anonymous says:

    [Hey wait, if your business logic is entirely visual, then it is quite common to put business logic in the WM_PAINT handler. -Raymond]

    I agree.

    I've seen one application that, instead of relying on built-in Now() function, reads formatted time string from the "clock" control (which internally also use Now()…) and passes it to corresponding business logic components. The control updates it's time on WM_PAINT (which is fine because afterall, for the control, even if Windows don't pass WM_PAINT to minimized window, it doesn't really matter if the displayed time is not updated when the time is not to be displayed), so if windows don't receive WM_PAINT when minimized, that application will break.

  45. Anonymous says:

    Each new version of Windows seems to include some "compatibility" mode for the older versions, including things like a DOS emulator, in order to keep the old apps working.  Except it seems that it's an afterthought every time.  How about rejecting the idea that each new Windows version is just an "upgrade", but a totally different system?  Running code meant to run on previous versions of Windows simply doesn't run in a native fashion.  It would run under some compatibility mode.  Misbehaving apps that people actually care about are fairly rare and the users involved are generally willing to do a little work to make them work right.

    Why is it that Microsoft, with its leverage on the market, never uses that leverage to force the customers/users to do things differently?  If you just fixed the "bug", what would happen?  A few people would be mad and wouldn't be able to run an old app anymore.  What do you think they're going to do?  Move their whole organization to Linux or Mac just because of one app?  Even if that app is critical to their business?  What exactly is their other option?  Their critical app only works on Windows!  Forget the "the customer is always right" nonsense occasionally and just *do the right thing*.  Turns out it won't hurt as much as you seem to think.

  46. Anonymous says:

    @Mike:  Yeah, that's a good marketing hook.

    Windows – Because you don't have any other options.

    Windows – Because we've got you by the balls.

    Windows – What are you gonna do about it, ***?

  47. Anonymous says:

    No, if the application is using the API incorrectly it should break.  If you want to run an application from 1993 that worked in 1993 use a virtual machine with Windows 3.11/95 on it.  Microsoft should remove all the cruft, legacy functions and rubbish that is floating around in the Win32 api, it is a total mess.  Deprecate and remove over multiple releases.  At the moment Microsoft just does the deprecate part and never removes the function "just in case" some application might break.  This legacy rubbish is holding Microsoft back.

  48. Anonymous says:

    @Steve, Mike, et al.

    Maybe you haven't been paying attention, but that solution is not really the panacea you describe.  Raymond has addressed the virtual machine argument in several posts.  He has even addressed the argument that the backwards compatibility is somehow a form of bloat.  The vast majority of these things are completely miniscule in terms of speed/code size.  Finally, the API certain evolves over time, it grows and is pruned version to version.  I would challenge you — if things are so old and full of "cruft", you should have no problem naming 100 functions that should be removed.  Like, truly bad, not "it looks old so I do not like it" (the sort of petulance you are displaying right now).  I can name four off the top of my head, but that is it, and I have been doing Windows development for a long time.  Deliberately breaking backwards compatibility is not worth doing, as the downsides outweigh the upsides by a huge factor.  I think you are making a huge fallacy: "Because I do not use it, no one else does, because I am the clearly the most special person ever."

  49. Anonymous says:

    @K: Microsoft and Apple are basically on the opposite sides of this particular continuum. From my experience with System 7.0 breaking *virtually every app I used*, then OS X 10.2 breaking *virtually every app I used* all over again– well, I switched to Windows.

    If you're happy with the way Apple does business, good for you. I use it on my home laptop. But I'd personally never recommend a corporation invest in an Apple solution which could, at any time, break all of their critical business software.

  50. Anonymous says:

    Could it be that for a lot of posters this is their first time on this blog? 

    I'm having a very strong déjà vu here, not only with some of the suggestions (treat it as a new system, virtual machines… wow, brand new ideas! genius!) but also with the discussion in general.

  51. Anonymous says:

    You know, I find all of this talk about why you can't have a whitelist rather baffling, considering that as of Windows 7, such a whitelist to disable compatibility shims does in fact exist: msdn.microsoft.com/…/dd371711(VS.85).aspx

    So why wasn't the plugin scenario an issue for this?

    [The plugin issue is still an issue. If an application specifies any of those behaviors, the application vendor has accepted responsibility for the plug-in problem. If your application hosts plug-ins outside your control, then you probably can't request the new behaviors because you don't know if the plug-ins are compatible with them. -Raymond]
  52. Anonymous says:

    Each version of Windows should be cludge-free (i.e. no special-case handling of apps) and should some with the ability to run N previous versions of Windows in a VM so that old apps continue to function.  The VM should be totally seamless – like 'Seamless Mode' in VMWare (or is it Parallels – can't remember!).

    Virtualisation and CPU horsepower are good enough these days for no apparent performance degradation.  Each version of Windows comes out without special-case hacks for specific applications & all apps 'just work'.  (it's conceivable that Windows would come supplied with a database of known apps associated with the version of Windows that they should be run under)

    [I can see the news article. "Windows N requires 512MB of memory per application because it runs everything not specifically marked as Version N-compatible in a virtual machine. Congratulations, your 4GB machine can run eight apps." -Raymond]
  53. Anonymous says:

    Shouldn't the default, though, be to disable those dummy WM_PAINTs unless a compatibility flag is set?  (Which general users could set via the "previous OS compatibility" tab and site admins could set more fine-grained using the compatibility resource kit.)  That way, "live" apps should eventually get fixed, if they're relying on undesirable behaviour; while the "dead" apps can continue to run by enabling the flag.

    Granted, this does lead to bloating of the code to handle these compatibility hacks, but that's already necessary anyway; it doesn't seem like a big addition.

    I wouldn't think too many users would have a problem with "hey, this worked on my old OS, and it doesn't work on this one, so maybe I need to set the compatibility mode to my previous OS to make it work again"…

    [You're assuming it's as simple as finding the GenerateDummyPaint() function and commenting it out. In reality, it's something distributed throughout the window manager as a side effect of other behavior, like RDW_INTERNALPAINT. (And suppose you're a corporate with 9000 internal applications. Do you really want to sit down and test each and every one to decide which compatibility modes to use for each one? And now suppose you're a non-technical end user. A program doesn't work. You don't know about these "compatibility modes". All you know is that your program doesn't work.) -Raymond]
  54. Anonymous says:

    Why do some want to break backward compatibility so badly. No, really, why?

    Because it leads to cleaner code? That's something developers care about, not users. Few people like to analyze such situations, analyze such code, it's not an "interesting problem" in the curriculum of comp sci. News flash: most code is boring, code that pays money doubly so.

    Because it stops developers making the same mistakes? It does not: they will continue to get their education from the current implementation, instead of reading the documents. They'll just come up with new ones. "No problem, minimized windows never get a WM_PAINT, we don't need to handle that as a special case!"

    Because developers could fix other bugs? Yes they could, but they first need to rewrite that 1993 Win16 app as a 64 bit unicode WxF fest with Silverlight frontend. In an extreme driven agile way. Because that's what that insurance company in Topeka pays for.

    Because it reduces sizeof(WindowsInstall)? Yes, but by what? Five percent? If you don't change the order of magnitude, most users will be unaffected.

    Punishing wrongdoers? Go for it, but keep the civilians out of this.

  55. Anonymous says:

    Why do some want to break backward compatibility so badly. No, really, why?

    Because it leads to cleaner code? That's something developers care about, not users. Few people like to analyze such situations, analyze such code, it's not an "interesting problem" in the curriculum of comp sci. News flash: most code is boring, code that pays money doubly so.

    Because it stops developers making the same mistakes? It does not: they will continue to get their education from the current implementation, instead of reading the documents. They'll just come up with new ones. "No problem, minimized windows never get a WM_PAINT, we don't need to handle that as a special case!"

    Because developers could fix other bugs? Yes they could, but they first need to rewrite that 1993 Win16 app as a 64 bit unicode WxF fest with Silverlight frontend. In an extreme driven agile way. Because that's what that insurance company in Topeka pays for.

    Because it reduces sizeof(WindowsInstall)? Yes, but by what? Five percent? If you don't change the order of magnitude, most users will be unaffected.

    Punishing wrongdoers? Go for it, but keep the civilians out of this.

  56. Anonymous says:

    "If your application hosts plug-ins outside your control, then you probably can't request the new behaviors because you don't know if the plug-ins are compatible with them."

    Okay, then the question becomes: since shell extensions are loaded by the common file dialogs, doesn't that mean that every single application using those dialogs cannot safely request the new behaviours? Doesn't that essentially mean nearly every single application? So what's the point of that manifest option at all, if no one can really use it?

  57. Anonymous says:

    "If your application hosts plug-ins outside your control, then you probably can't request the new behaviors because you don't know if the plug-ins are compatible with them."

    Okay, then the question becomes: since shell extensions are loaded by the common file dialogs, doesn't that mean that every single application using those dialogs cannot safely request the new behaviours? Doesn't that essentially mean nearly every single application? So what's the point of that manifest option at all, if no one can really use it?

    [There are many applications that don't load common file dialogs. They're things like services or apps with no real UI; they just sit there and churn through data. But your typical GUI app is probably of luck. -Raymond]
  58. Anonymous says:

    Here's a suggestion which might be extremely stupid, but here it comes anyway:

    Could there be a (Simple for MS) way to bring out a developer edition for windows WITHOUT all the backwards compatibility shims so that developers who were willing could develop in (what is at this moment) only the correct way?

    Might be too difficult to do, I only do .Net on Windows so the suggestion might be silly.

    [You're assuming it's easy to identify all the compatibility behaviors and simply ifdef them out and assume you don't need to re-test anything. A lot of compatibility behaviors are more than just an ifdef; they are baked into the design. -Raymond]
  59. Anonymous says:

    How about a third option. Windows works just the way it is. However, when an app is run in debug mode, the compatibility hacks are turned off. This way, no blacklist is needed – plugins inherit whatever mode their hosting process is (retail, normally) even if it was a debug DLL. But a process running a debug EXE automatically tells Windows "don't be special for me". It's debug mode, things are allowed to crash so you can catch it in the debugger.

    As for Windows vs. MacOS – Apple's policy has been extremely clear – use only the documented APIs that aren't deprecated. Use private APIs, or hacks that aren't supported, and they will not care if it breaks. The most common causes for things to break is use of private APIs because Apple has a very nasty tendency to do a ton of stuff to private APIs. (And various OS enhancements that dig deep into the OS do break, often enough to render a system unbootable).

    [This means that there would be a runtime switch for every single compatiblity hack, even the ones that are zero lines of code. Congratulations, you changed "return Helper() != 0" to "return ApplicationCompatibilityHacksDisabled() ? Helper() : Helper() != 0;" Yay, you added an extra function call to every compatibility hack, even the zero-line ones. And that doesn't even address the design changes that were made for compatibility. Should there be two designs for each feature, one that takes compatibility into account and another that doesn't? -Raymond]
  60. Anonymous says:

    @Drak: I don't think that will help.

    For one thing, those applications behaves correctly as they were written. Just fail if the rule change in Windows N+1 version or above. But when there's apparently a need to change, the origional writter may not exist anymore, so noone is going to test and fix the application in your new developer versions without compatibility shims.

    For the others, I doubt any company will allocate resources (time, money, etc.) to fix the bugs that only show up in such "developer version". This edition may end up being "something nobody who uses the feature actually wants".

    Also, people who're willing to do things correctly will try to do things correctly, instead of abusing events in ways that doesn't intend to be used.

  61. Anonymous says:

    Why not provide grades of Windows logo?

    Bronze (normal): Asserts in a checked build

    Silver: Uses 3rd party libraries that assert

    Gold: Does not assert

    P.S. I still remember WM_PAINTICON.

  62. Anonymous says:

    [I don't see how you think the argument has no precedent. Vista broke a lot of stuff. Nobody bought it. -Raymond]

    Well this argument will always be lost by the side without the hard data. Unless we know the ratio of bugs fixed in the OS itself vs compatibility related bugs nobody can say either way.

  63. Anonymous says:

    I want to thank everyone like Raymond who does the work of keeping this compatible and who just does their job to fix or advance Windows or every other program instead of enforcing strnage rules about great designs and how everyone must be forced to change working programms.

    Windows will be successful exactly as long as the old ways of doing it stay in place. I hope never ever a bunch of kids is let loose to manage Windows development like it happened with Windows.

    I hope the "Raymond Chen Camp" will win in the future to spare us things like Windows Home Server's removing of its best part or a Windows Mobile which is incompatible with its predecessor.

    Everytime some kid decides to remove a feature or compatibility, I suffer.

  64. Anonymous says:

    I do sw development for a living and do work for a large corporation. Around here the mantra for the software is "it HAS to work". That's it.

    For a customer it doesn't really matter, where the error is – in your application, in the spec, in the library you use from a third-party component, in windows, in your compiler.

    My job as a sw developer is to figure these things out and just make it work. From reading Raymond's articles, this seems to be his/microsoft's mindset as well and for me this is definately the right thing to do, bcause if you try to think outside the technical mindset, then why should the world at large, care about the shim or whatever windows uses to make the application you need to use, work?

    As a customer, I just want it to work, and why shouldn't I? It isn't my fault that some deeply technical things somewhere have gone wrong ten years ago.

    I say, good work for both MS and Raymond for trying to educate people in the way the real world works.

  65. Anonymous says:

    [… And then you'd have to add tests all through the OS for every single one of these

    tiny little things. IsWindow would change from "if itnernal_algorithm(hwnd)) { if

    (ApplicationCompatibilityFlag(ISWINDOW_MUST_RETURN_EXACTLY_TRUE)) return TRUE;

    else return 42; } else return FALSE;" Congratulations, you just bloated the

    IsWindow function. -Raymond]

    Thanks for pointing this out, Raymond! Point taken.

    +1 vote to enable AppVerifier by default in Visual Studio.

  66. Anonymous says:

    People have been missing my point:

    Of course Apple does not have a time machine. And they break stuff quite a bit more often than strictly necessary, not for bug fixing, but just because. MS on the other hand doesn't even fix bugs. The philosophies are so far apart, it's not even funny, and I can see the advantages and disadvantages of both sides.

    But one thing is just not true: Raymond complains that fixing the bug would impair business badly. It would not. MS has such a domination on the market that dropping backwards compatibility would not do much. Corporations could not switch to Linux or Mac over night if they are unhappy with that new windows that breaks one of their applications. And even if: Apple does not suffer bad business when they break things. Why should MS? It's an argument that doesn't have a precedence, just a fear of "OMG, they *might* not buy windows", but who are you kidding?

    One could argue that it might be hard to sell them "Vista 2" which not only is not an improvement, but also breaks an important app. Yes, that is true. But on the other hand: Do you really think it is necessary to sell them a product of which you know they don't need? Aren't we engineers who try to write good software? If you fix all the bugs and break 1% of all apps that have been written 5 years ago, that seems a decent trade off. Imagine how fast and stable such a system could be without so much legacy code, and what a joy it would be to use an elegant system API.

    [I don't see how you think the argument has no precedent. Vista broke a lot of stuff. Nobody bought it. -Raymond]
  67. Anonymous says:

    "However, when an app is run in debug mode, the compatibility hacks are turned off."

    In addition to what Raymond said, this method is a whole lot of effort for roughly zero gain.  It's opt-in for people who want a way to verify that they aren't relying on compatibility hacks.  But the compatibility hacks in Windows would still have to exist because there are people who aren't willing to opt in, and those people may very well write popular or important applications that must not break between Windows versions.

    I know I can't be the only person here who's worked with people that compiled only in release mode because the app doesn't work in debug mode.

  68. I suppose, JJJ, you would advocate removing speed limit signs… because they take a lot of effort to put up, and people speed anyway?

  69. Anonymous says:

    @K.  Sure, Apple breaks stuff with new releases that Microsoft would keep compatible.  Which is probably one of the reasons why OSX languishes with around 7% of market share (or probably lower — these figures are based on web client stats, and it's been suggested that most machines that aren't accessing the web are probably running Windows).  And why – at least until the iPhone launched – Apple's value sat at somewhere in the region of a tenth Microsoft's.

    (Current Apple share prices are buoyed by the success of the iPhone and iPad.  I'm betting that we'll see brand fatigue set in on those at some point in the next couple of years and Apple shares will slide downwards.)

  70. Anonymous says:

    @Maurits:  I don't get your analogy.  Are the compatibility hacks the speed limit signs and people speeding are bad programmers?  So you're asking me if I think we should remove compatibility hacks because people program bad anyway?

    No… I don't think that at all.  That's not even remotely close to what I said.

    And are we supposed to be pretending that putting up a speed limit sign is a gargantuan effort?  I didn't get that part either.  It takes one person less than an hour to put up a sign.

  71. Rules of Win32 programming = rules of the road

    People who run only the release build because the debug build doesn't work = people who speed because they're late

    Assertions + appverifier + other "strict mode" checks = speed limit signs (reading a speed limit sign is opt-in)

    Crashes + other broken behavior = traffic cop giving out tickets (not following the speed limit has consequences)

    Popular apps that get shimmed even though they break the rules = Steve Jobs parking in handicapped spots without a license plate

  72. Anonymous says:

    "There are many applications that don't load common file dialogs. They're things like services or apps with no real UI; they just sit there and churn through data. But your typical GUI app is probably of luck."

    And the bonus question: why isn't this information listed anywhere (that I could find)? It seems to me that the fact that the setting could be dangerous for any application that shows a file dialog would be rather important.

    [Because the kernel guys follow the classical model of process design, where a process has full control over what code runs in it. It is therefore obvious (to them) that if you choose to load code into your process, you are responsible for ensuring that it conforms to your settings. -Raymond]
  73. Anonymous says:

    Please excuse me for sounding ignorant if I do, I am a Massage therapist and some how found myself reading through this blog. I can appriciate the do it right mentality. Oh and how do I get in on that time machine ride? I knew geeks were super cool!

  74. Anonymous says:

    I cannot believe the insanity I am seeing here.  The very people who are shoving the idea that bad apps should just be broken are hypocrites.  They'll take the "Holier Than Thou" road on this blog to make themselves feel superior to Raymond, but as soon as they install Windows 8 and some little rinky-dink app they need quits working it'll all be: "STUPID MICROSOFT!!  My little hextris game worked under Windows 7 but as soon as I upgraded to Windows 8, it crashes!"  Nevermind the fact that hextris exploits a bug in Windows 7 to allow it to redraw itself faster that was fixed in Windows 8.  When they are inconvenienced, it's all MS's fault.

    JamesNT

  75. Anonymous says:

    I actually think that the time machine idea is fantastic. Combine it with an idea of a multiverse, and here is what you gotta do:

    Make a version of Windows that would for every operation where something is undefined excercise a random possible behavior. WM_PAINT is not guaranteed to be sent? Then sometimes send it, sometimes not. Sometimes send it every millisecond. Then don't send it for an entire day.

    You test your software on this multiverse version of Windows. Since the future will only narrow the undefined behaviors down (otherwise Microsoft would be maliciously breaking things, and that's not what they do), you should be perfectly future-proof. How's that?

  76. Anonymous says:

    Apple broke backwards compatibility. They arguably have better consumer desktop and mobile products now then MSFT.

Comments are closed.