A blog describing computer internals and electronics, from a student's viewpoint

"Paperbacks"

Monday, May 25, 2009

The Microsoft Visual C Runtimes and Wine

Through the years, the Wine development team has been striving to ensure full compatibility of Windows programs in Linux. It is known to them that kernel-mode software, and software that does direct hardware accesses, will not be supported ever, across different operating systems due to fundamental differences in the kernel architecture between OS'es.

But there's one aspect of many high-end Windows programs that makes cross-platform execution harder to attain. This has something to do with the versioning of the Microsoft Visual C runtime libraries, especially the MSVC++ 2005 CRT's (e.g. msvcr80.dll) and later (due to the use of the side-by-side architecture of Windows XP and later.) To complicate matters further, many high-end apps also make use of MFC, either directly or indirectly (e.g. using a skinning component.) MFC is a well-known bloater in the size of software distributions, so many companies hate products using the library, be it their own apps or some skinning component.

Examining the C runtime libraries reveals something surprising: much of the core routines ( e.g. sprintf() ) haven't changed over the years, yet each succeeding version of Visual C++ requires an entirely different set of runtimes (even MFC's no exception.) To make matters worse, msvcr80.dll and later force all applications to have a manifest or not load at all - this info can be dissected by a hacker with the proper resources, and he can tell what compiler was used in making the program. I wonder what Microsoft's up to in terms of code redundancy, given the fact that the core C library exists with all Windows versions since Win98 and hasn't changed (this file is named Msvcrt.dll in the system32 directory, typically C:\Windows\System32 .) Folks there could just release the differences in exception handling with a separate DLL, and all others will forward to the system's C library.

I'm still writing a DLL that does what I've said above: just have the differences in exception handling included, and the rest is forwarded to the system C library.

If Microsoft keeps tying software vendors into their Windows operating system, there will come one day that the big software company will terribly suffer for all of what they've done, given the disturbing fact (from leaked internal docs) that it plans to dominate the computer world (in effect, control our everyday businesses, often against our will). Windows may be the mainstream OS, but it's nothing if it's from the hands of the company which can be considered the computing world's "Adolf Hitler."

P.S. Many thanks to the folks at the Wine project; I'd try donate and help one day.

No comments:

Post a Comment