On 23 Mar 2005 at 6:13, dhbailey wrote: > As for Dennis' fear of losing access to Finale, I agree, it's not > paranoid. But copy protection isn't what has done Mosaic in, it's the > advancing OS which has left the old code in the dust and the > developper of Mosaic decided to pull the plug on the program. Nothing > will be able to save Finale into the future once either Windows or > MacOS move onto 128-bit programming and the then-current versions > won't run any 16-bit apps anymore. > > That could happen to open-source freeware as easily as to > corporate-developped expensive software.
Well, yes, it *could* happen, but it could only do so if these conditions were made: 1. there was no compiler available that could compile the old code base to run on the new platforms, AND 2. there was no way to recode certain features of the old code base into a version compatible on the OS. Neither of these things has much likelihood in the time frames we're are discussing here. Yes, it's quite likely if you wait 100 years behind the last release of the open source code base and the effort to compile for current computer programs. It's not very likely if it all takes place within the natural evolution of the software ecosystem. As you all my remember, I program Microsoft Access database applications. I started doing that with version 2.0 back in 1995-96 when the current version of Windows was just beginning the migration from Win3.x (16-bit) to Win95. The NT-based version of Windows was not very widely used, so I didn't worry about it. My 16-bit Access applications ran just fine on Win3.x. They ran even better on Win95. They even ran just fine and dandy with a small amount of permission tweaking on NT 3.51. When Access95 came out, Microsoft had replaced Access Basic with Visual Basic for Applications, and VBA was implemented in all the programs in the Microsoft Office Suite. The changes were minor. Here's an example of a common command and its replacement: DoCmd OpenForm "frmMyForm" was replaced by: DoCmd.OpenForm "frmMyForm" Access95 was designed to do those kinds of conversions for you automatically. Indeed, it converted almost everything. Just about the only things that didn't convert were any dependencies on Windows [16- bit] API calls (i.e., outside of Access). I had a couple of existing applications that extensively used 16-bit add-in controls for tabbed dialogs and multiselect listboxes. Access95 implemented both of those natively. Fortunately, one of these applications was being phased out (actually, the companies it was being used by, penny stock trading firms, were just going out of business with the rise of online trading), and the other was used by only a single individual. I never converted either of those apps. But they both still run on every version of Windows that has ever existed since the time they were written. That means Win3.x, Win95, Win98, WinME, NT 3.51, NT 4, Win2K and WinXP (I don't know if it would run on Win2K3 Server, since it has stricter security and might prohibit the installation of 16-bit OCX's; but that's not a workstation OS, though it can be used to host Windows Terminal Server; my bet is that the OCX's could actually be installed and would work). Now, at some point, should MS drop support for 16-bit OCX's (or on a larger scale, for any 16-bit applications), then I'd have to convert. I'd have to keep an older version of Access, since current versions can't convert Access 2 files, and I'd have to remove the OCX's and replace them with the native 32-bit controls. But it's not a big deal. The only reason I never did it for the one remaining user was that it's just easier to install the OCX's on her new PCs than it is to take the time to rip it all out and start over. However, actual conversion is something I can do very, very easily as long as I have the versions of the software that can convert the older files. For right now, this means Access97 (the last to convert from Access 2), as all current versions of Access can convert from Access97. For open-source code, the situation is similar, though at once much simpler and far more complex. One would need a compiler that can deal with the old code, but also would need to convert outside dependencies (like the 16-bit API calls in my old Access apps) on obsolete technologies. It is the fact of having the source code that makes it possible to do the conversion in circumstances where it would otherwise be impossible (absent emulators of the obsolete platforms). -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
