On 28 May 2010 at 22:41, Daniel Wolf wrote: > In general, David is right that the MS operating systems have been > remarkably backward compatible and this has been a real positive > quality with Finale files. However, a year or two ago, I had a font > problem and tried to install to install my old copy of Fontographer > - in its day (frozen in 1998), the standard font design program - > only to discover that it couldn't handle the amount of RAM on my XP > machine. It's a well-known problem but I didn't have the patience > to try the kludges suggested in online fora, so I switched to > FontForge, an open source program that's just fine. This was more of > a Fontographer problem than a Windows problem and Font Lab, who now > owns Fontographer, has promised a fix, but it is still a good > illustration of how tricky backwards compatibility can be.
Yes, actually is the main thing that causes problems, i.e., more memory than old applications new could exist. However, a VM can take care of that, if you adjust the VM properties to match the needs of the old app. Fonts, though, being a system component, are also an area of software (like anti-virus and system utilities) that are often not at all compatible with later versions of Windows, and cannot be made so because they are written with particular expectations about the subsystems they are working with. I'm just now trying to choose a graphics editing app for a client to replace PaintShop Pro 5, which has worked fine (with some hiccups) until Windows 7 64-bit. It works better than I expected, but there are too many things that cause problems (such as apps pinned to the TaskBar starting with the application's program folder as the startup folder; PSP 5 lacks any application-specific setting for that, and can't write the last-chosen folder to the registry because it stores its registry data in a location not writable by applications running with a user-level token, etc.). There may be workarounds for all these problems, but I'd rather update the client to a more modern piece of software than waste time on troubleshooting 10-year-old software. On the other hand, if there weren't plenty of alternatives freely available that offered the functionality they use, it might be a different story. I have one client running a dBase II app compiled in 1982 or 1983 in a WinXP VM under Win7. There's no replacement for this custom app that wouldn't cause difficulties for the users, so we figured out how to do it (which requires some pretty creative things to get printing working). But for the most part, I think it's best to get new software when possible, and muck around with VMs and compatibility only when that particular version of that specific software is truly required. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
