On 11 Mar 2005 at 10:20, Robert Patterson wrote: > I don't think I'm being dishonest. I never qualified "eventually". The > whole point about forever is that it is, well, forever. If your > software doesn't quit working in 15 years, then it will quit during > the next 15 years, and if not then, then in the next, or the next, or > the next, or the next. 4 billion years is just a facetious way of > bringing home the point. It WILL happen.
But we aren't talking about the end of the universe. We aren't talking about forever. We're talking about the interval of a few years after the failure of MakeMusic, when Finale users would need some capability to use their files. During that interval, with a key escrow setup, they'd have a choice to take their time moving away from Finale, but would not be interrupted in their work (and that applies only to people in the position of needing to install on a new computer, thus requiring an authentication key). Assuming that Coda continues to release a new version of Finale every year, and that Microsoft (why we're limiting this discussion to MS, I don't know) continues to release a new version of Windows every 3-5 years, these things would be true: 1a. the last 3 or 4 versions of Finale are likely to run just fine on the most recent version of Windows. 1b. Earlier versions may have a few features that don't work exactly perfectly, but most likely (if history is any guide), editing and printing will remain usable. My bet is that WinFin versions back to 3.x will still run just fine on WinXP (that's about 10 years ago, right?). 2. Microsoft tends to release a new major version of Windows every 3- 5 years or so, versions that change major parts of the underpinnings of Windows (Windows 1, 1987, Win3, 1990 (while Win3.1 was a huge big deal in terms of usability because of the introduction of TrueType fonts, it was otherwise pretty much exactly the same as 3.0), Win95, 1995, and on the NT side, NT3.1 (i.e., version 1), 1991, NT 4, 1996, Win2K, 1999 (WinXP is an upgrade to Win2K, not a major rewriting of Windows)). But in none of those major upgrades was backwards compatibility broken. Sure, a few apps had problems, but there were virtually no apps that won't run at all or whose main functions are disabled or fundamentally broken. If one assumes that MakeMusic goes under, it will happen when most Finale users are: 1. using the latest version or one of the last 2 or 3 versions, AND 2. those on Windows will be using the last two *minor* versions of Windows, with a handful still on the previous *major* version of Windows (translated: today, it's roughly something like 50% WinXP, 40% Win2K and the remainder using mostly Win98 or NT 4; Win2K would be higher if it had been marketed properly, rather than just to businesses), but the exact mix depends on when MM fails in relation to the Windows release cycle. Should MM fail just before the release of Longhorn, the last version of Finale will be more likely to have very minor problems than if it were designed after the release of the next major version of Windows. Nonetheless, IF HISTORY IS ANY GUIDE, even in the case of a pre- Longhorn version of Finale, the software is likely to still be perfectly usable on Longhorn for basic editing and printing, though there may be certain cosmetic and non-essential elements that don't work 100%. Now, that could change if Longhorn included major changes to these subsystems: 1. printing and rendering 2. MIDI 3. file system while also purposely yanking support for legacy behavior in regard to these major subsystems. In the case of Win16 programs (which was different in all of these aspects), Microsoft has included full support to this day (they carefully designed the Win32 APIs and the altered subsystems to make it work), even though there are now no longer any significant 16-bit applications out there anywhere. And DOS doesn't exist any more, but the command prompt is DOS compatible (highly compatible, in fact) and runs a large number of DOS programs from the beginning of DOS, even going so far as to providing substantial control of parameters that can be tweaked to allow misbehaving legacy DOS programs to run (check out the properties for a DOS prompt to see how much can be adjusted). Now, so far, the only areas of those three that Longhorn is changing is the screen rendering (Avalon) and the file system (WinFS, delayed until after the original release of Longhorn), and both are scheduled to be ported to other versions of Windows, which suggests neither is going to break legacy apps. The last time Microsoft changed the file system (long file names), they implemented some very clever hacks to allow older apps to still work. Yes, you end up seeing ugly file names, but you can still use the files (i.e., the problem was purely cosmetic, rather than functional). So far as I know they've not made major changes to the rendering subsystem. This is an issue for printing, because the video subsystem and printer drivers are tightly interwoven in order to insure WYSIWYG display (video drivers user components from the printer subsystem for onscreen pixel rendering; this is why buggy video drivers can cause your application to crash on printing). Should Avalon completely re- engineer this relationship between printer drivers and onscreen display, there could be problems. But my understanding of what Avalon really does is to provide fancy Quartz-like rendering features (transparency and improved 3D rendering), rather than changing the way standard 2D rendering works. So, absent a decision by MS to make Avalon without any compatibility layer for older apps, I see no reason to worry about printing problems. Indeed, my bet is that if Avalon makes major changes to 2D rendering interactions with printer drivers, they are more likely to be implemented the way 16-bit support was implemented -- by having a completely separate subsystem for the legacy apps, almost 100% independent of the new version. With Win16 apps, this meant that the UI looked completely different for a 16-bit app than for a Win32 app. A parallel with Avalon would be that a legacy app would simply look like old Windows, instead of like Avalon. The easiest way to implement that is to simply include the old subsystem and insure that it can run in the new environment. That means that it's unlikely that any backwardly compatible implementation of Avalon would break WYSIWYG in legacy applications. > I think our basic disagreement is over how long MS will continue to > provide backward compatibility. . . . The only evidence we have is MS's past history, which has been exemplary. No other OS vendor has done better. I know of no applications other than games (which often accessed video memory directly) that are completely unable to run under Windows. Every mainstream application I've ever seen has continued to run under newer versions of Windows. > . . . "Backward compatibility" is a weasel > concept anyway. Binary executables have a life-span like everything > else in this world. Some work longer than others. For any given OS, > each new OS version causes some old programs to quit working until > gradually there is near-complete turnover. . . . That has not yet happened with any version of Windows. That is, there is no version of DOS or Windows that has yet reached anything like "near-complete turnover." We're talking nearly 25 years of history here. > . . . It is undeniable that in > general the lifespan for Windows programs has been longer than Mac OS. > (The whole tenor of this conversation seems to be a Mac-bashing one--a > topic that utterly bores me.) . . . Not in any of my posts! I've given no thought whatsoever to the Mac, except at the root post of this thread, which seems to me to have claimed the Mac experience with broken compatibility to be universal. It's clearly not. > . . . But you yourself admitted that some > Windows programs (e.g., WordPerfect) have fallen by the wayside. . . No, I said that when Win95 came out, WP had certain problems (because they hadn't followed Win16 API practices that had been recommended by Microsoft for nearly 5 years previous to the release of Win95), but the software still worked. Yes, it had cosmetic problems, and the native WP printer drivers (as opposed to the Windows printer drivers) caused problems, but you could still print. WP did, indeed, fall by the wayside (for all practical purposes) eventually, but it had nothing to do with compatibility problems in Windows and everything to do with WP's inability to grasp the fundamentals of the transition to Windows (I'd also argue that they were hampered by their sequential file format, but that's a much more technical discussion). > . . . By > contrast, I still have a few MacOS binaries I purchased in the 1980s > that still work just fine in Panther OSX. In particular MS Word 5.1 > and MS Works 3. WordPerfect 6.0 STILL WORKS on any version of Windows. That doesn't mean 100% of the features work completely or exactly the same as they did on Win3.x, but you can still edit documents and print. So, you're again misdirecting the discussion, this time by misconstruing my words. I don't know own any software that doesn't still run on my current version of Windows (Win2K). > Personally, I believe that there will be a change in the Windows > environment over the next 5 years that will rival the magnitude of the > transition from DOS. . . . Maybe so, but large numbers of DOS programs (maybe even the majority) still run just fine on current versions of Windows. > . . . I think a large number of older programs could be > killed by it. . . . IF HISTORY IS ANY GUIDE, you'll be wrong. > . . . Microsoft has a great deal of selfish incentive to kill > off their pre-authenticated versions of Office, and if they do it, > they will take a lot of other programs with them. But only time will > tell. Well, authentication is a new wrinkle. One thing that is a disincentive for using pre-Office 2K is the completely proper tightening of security settings implemented in Win2K. Certain functions in Office 97 don't work completely properly (spell check, thesaurus in Word; some wizards in Access) without tweaks to the security settings of certain registry keys. Again, this is typical of MS's backward compatibility: basic functionality of these apps is not broken by the newer version of Windows, but certain functions are curtailed (requiring tweaks to the system to get them back). If MS does use authentication as a tool to make old programs obsolete, or rewrite its OS's to make non-authenticated apps obsolete, that would make big news, and my bet is that, given the enhanced scrutiny MS is under by virtue of having been declared a monopoly, they would have a hard time pushing it through. There have been a number of licensing initiatives that MS has put forward that have been withdrawn. One involved testing of subscription software (MS tested it in Australia just before the release of Office XP), the other has been huge changes to Enterprise licensing. In both cases, customers complained bitterly and MS backed off from its original announced plans (in the case of subscription software, it dropped it entirely, the case of the Open License program, it opened it up considerably from what was originally proposed). But that is all about MS's *own* products. I'm not sure that this kind of thing would also break non-MS products. Indeed, I have a hard time figuring out how MS could break Office 97 and non-authenticated Office 2K (the first 18 months of its sale was non-authenticated) without also breaking all later versions of Office. So, I think you have to be terribly paranoid to believe there's any chance that MS would be able to do something like this. Indeed, MS has a history of *improving* its support for backwards compatibility, at least in my narrow world. MS's Access database used to like Finale, with a new file format every version, and no ability to create files in any previous version (though it could always read/write data from previous versions; it just couldn't open the non- data parts of the files). With the release of Access 2K, MS implemented for the first time the ability to save as the previous version. With Access 2K2, they kept the Access 2K file format as the default (while also implementing extensions to the file format that would work only in A2K2). This policy was continued in A2K3, with the A2K file format remaining as the default. Part of this is due to the ending of active development and enhancement of the Jet database engine, which hasn't changed in any major way since the introduction of Jet 4 in A2K, but MS used that stability of db engine to introduce backward compatibility that had never existed before. > I will say that, except for games, which probably have the shortest > lifespan of any program, the older 1980s versions seem to have the > longest lifespans on either platform. They had simple installation > procedures, did not generally depend on complex middleware libraries, > and used vanilla OS-level API calls. A great example is MS Works for > MacOS. Works 3 still works on Panther, but Works 4 (a later version) > died years ago. This is because Works 4 depended on a discontinued OLE > library for MacOS that quit working (I believe) in OS9. > > So, I think my little DOS utility collection, . . . Er, utilities are a different animal, because they are highly specific to technical specifications of file systems and the like. And they are broken by almost every minor release of any OS. > . . . written in the 1980s, > will probably continue to work long after the stuff I'm writing this > year has ceased to function. (The stuff I'm writing this year depends > on the .NET framework and the vagaries of ASP.NET and IE 6, and it > could plausibly die with Longhorn.) Well, MS abandons a lot of their hot technologies shortly after introducing them, but I've never seen them yank support for their older technologies just because they decided to put their promotional budget behind something else (ADO vs. ADO.NET is an example of this). So, I think it extremely unlikely that your .NET apps will be broken. Yes, you may have to recompile your runtime under the most recent .NET version, but that seems to me to be more a problem with the basic .NET concept/implementation than with anything the OS. As to IE6, writing anything specific to IE6 is blazingly stupid under any circumstances. It's non-standard, it's insecure, it's unreliable. What more do you need to know to avoid it? > I think we agree on one thing, and that is that copy protection is > abusive. One of the reasons that it is abusive is that it shortens the > lifespan of binaries. I doubt very many if any copy-protected binaries > from the 1980s still work, on either platform. In many such cases, the > sole reason they don't work is that the copy-protection scheme no > longer works. My personal attitude, though, is that I have acquiesced > to it as a battle not worth fighting, since even non copy-protected > versions eventually die. I don't understand why people who understand the issues would simply acquiesce to the situation. With a small company like MakeMusic, it shouldn't take a large number of users to make a difference. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
