The Cellar - View Single Post

mbpark · 12-05-2006, 10:20 PM

Tom,

Developers, like everyone else, look for the best way to do things.

Unfortunately, the Win16 API (which is not part of 64-bit Windows, so 16-bit programs won't run on it- unfortunately this includes many Installshield installers!) and early Win32 API (pre XP Service Pack 2) was designed poorly in many spots. Many of the API calls which older applications use, such as Access 97 (which I have personally seen with a vertical market app) and others rely on functions which are either deprecated or no longer exist. In the case of Access 97, the Buffer Overflow protection introduced in Windows Server 2003 Service Pack 1 gets tripped when you try and execute the runtime. Vista is based on Windows Server 2003 SP1, which is a superset of Windows XP Service Pack 2.

Microsoft has even gone on record as saying that the older Microsoft Access runtime (based on Office 97) and MSDE (versions based on SQL Server 7.0 and 2000) will not be supported in Windows Vista, and will not work correctly.

Microsoft, due to their emphasis on security which was several years late IMHO, had to cut out Service Pack 5 for Windows 2000 because they would have had to deliver a whole new OS, literally, as a service pack. Many organizations would have balked at this. In fact, many organizations treated XP SP2 like a new OS and had to requalify and retest their deployed applications.

At one of my customer sites, which is a large healthcare organization, many of the third-party vendor applications had to have portions rewritten for Windows XP Service Pack 2, not to mention IE7. Thankfully, I help manage the internal development team and client deployments, and we had no major issues transferring our client/server apps to XP SP2

.

Microsoft made really bad design decisions IRT the Win32 API. Part of their security cleanup was cleaning up the APIs and code that they consisted of. Due to the major changes in the OS infrastructure, many applications that were written according to the API rules of a few years back will no longer work because either the parameters or return values from functions are different.

I've seen way too many applications require patches and updates for XP Service Pack 2 and beyond to ever believe that Microsoft can keep the APIs consistent across OS versions and preserve backward compatibility.

These aren't mom and pop software shops, either. The list includes Microsoft themselves, Symantec, GE Health Systems, and Oracle.

Change is necessary, and I don't disagree with you on that. However, I am just noting that the backward compatibility which Windows was once famous for is no longer there in Vista. Whether or not this is a good thing for vendors other than Citrix has yet to be decided.

12-05-2006, 10:20 PM	#23
mbpark Lecturer Join Date: Jan 2001 Location: Carmel, Indiana Posts: 761	The problem is... Tom, Developers, like everyone else, look for the best way to do things. Unfortunately, the Win16 API (which is not part of 64-bit Windows, so 16-bit programs won't run on it- unfortunately this includes many Installshield installers!) and early Win32 API (pre XP Service Pack 2) was designed poorly in many spots. Many of the API calls which older applications use, such as Access 97 (which I have personally seen with a vertical market app) and others rely on functions which are either deprecated or no longer exist. In the case of Access 97, the Buffer Overflow protection introduced in Windows Server 2003 Service Pack 1 gets tripped when you try and execute the runtime. Vista is based on Windows Server 2003 SP1, which is a superset of Windows XP Service Pack 2. Microsoft has even gone on record as saying that the older Microsoft Access runtime (based on Office 97) and MSDE (versions based on SQL Server 7.0 and 2000) will not be supported in Windows Vista, and will not work correctly. Microsoft, due to their emphasis on security which was several years late IMHO, had to cut out Service Pack 5 for Windows 2000 because they would have had to deliver a whole new OS, literally, as a service pack. Many organizations would have balked at this. In fact, many organizations treated XP SP2 like a new OS and had to requalify and retest their deployed applications. At one of my customer sites, which is a large healthcare organization, many of the third-party vendor applications had to have portions rewritten for Windows XP Service Pack 2, not to mention IE7. Thankfully, I help manage the internal development team and client deployments, and we had no major issues transferring our client/server apps to XP SP2 . Microsoft made really bad design decisions IRT the Win32 API. Part of their security cleanup was cleaning up the APIs and code that they consisted of. Due to the major changes in the OS infrastructure, many applications that were written according to the API rules of a few years back will no longer work because either the parameters or return values from functions are different. I've seen way too many applications require patches and updates for XP Service Pack 2 and beyond to ever believe that Microsoft can keep the APIs consistent across OS versions and preserve backward compatibility. These aren't mom and pop software shops, either. The list includes Microsoft themselves, Symantec, GE Health Systems, and Oracle. Change is necessary, and I don't disagree with you on that. However, I am just noting that the backward compatibility which Windows was once famous for is no longer there in Vista. Whether or not this is a good thing for vendors other than Citrix has yet to be decided.