창에 있는 유산 겸용성의 미래로 엿봄

창 3.1 창의 가장 새로운 방출에 십년간 오래된 신청을 달리는 기능은 거의 통행의 종교 의식이 되었다. 대부분의 사람들에 의하여 창에 소프트웨어 이전 버전 호환이 쉽게 그것의 성공을 위한 중요한 요인의 한개다는 것을 동의할 것입니다. 소프트웨어의 폭 그리고 깊이가 지수로 성장하는 때 각 방출로, 마이크로소프트가 지원의 이 구덩이로 더 깊고 더 깊은 판다 그러나. 순전히 이렇게 어떤은 이미 없는 경우에 예언한다 최후에 창을 파괴할 것이라는 점을.

최근에 간행된 특허 신청, "천연 운영 체계에 유산 신청 수행을 위한 환경" 당신의 그들을 위해 집에서 노는 것은, 마이크로소프트 Hoi의 Vo와 Samer Arafeh (에 의해 2007년의 4월에서 신청해 작동하는지 누구가 창 알갱이에) 몇몇 세부사항을 어떻게의 그들 계시한다 세력 (강조는 위에 특허가 종이 장에 정당한 낱말이기 때문에) 창의 미래 방출에 있는 소프트웨어 호환성을 수용하고 극적으로 개량하십시오.

특허에서 묘사된대로, 유산 신청 지원의 문제는 쌍성에서 속인다 (DLLs와 EXEs). 운영 체계가 개정하는 때, 체계 쌍성은 변화한다. 더 오래된 시스템 호출, 되부름 및 예외는 새로운 운영 체계에서 전혀 존재하지 않을지도 모르고다, 어떤 정도에 존재할지도 모르고다 또는 교체 응답을 생성할지도 모른다. 이 쌍성에 달려있는 유산 신청에 havok를 난파하게 할 것 같은 무엇이든.

현재 문제에 2개의 평범한 해결책이 있다. 그들의 각각 이점 및 불리에 각각.

끼움쇠

첫번째 "끼움쇠"의 사용을 채택한다. 은유적으로 말해서, 것이 빠지지 않는다는 것을 확인할 것이다 가장자리의 주위에 기본적으로 끈끈한 테이프 이다. 유산 신청이 적재될 때 기술적으로, 몰래 적용되고 유산 신청 및 천연 체계 쌍성의 중간 앉을 custom-written 헝겊 조각이다. 소문에 의하면 마이크로소프트는 썼다 창 비스타를 위한 끼움쇠의 수천, 이거든 아직도 쓰기. 위쪽은 끼움쇠는 실행하기 관계되 쉽다 이고, 그러나 에 의하여 전혀 잘 오르지 않는 신청 에 의하여 신청 기초 방법 당 a에 끼움쇠를 생성하는 것을 한.

두번째 해결책은 이점 virtualization 기술을 가지고 간다. 유산 OS 가상 기계를 접대해서, 유산 신청은 무엇이든 나아지기 위하여 무엇이든 모를 것이다. Virtualization 제안 무거운 성과 비용에 가득 차있는 신청 지원 그러나. 기계설비 지원은 또한 예를 들면 3D 도표 같이 자원을 공유한 것도 곤란한 하는 원시인 이다. 그것은 또한 사용자가 유산 운영 체계의 각 버전을 설치할 수 있을 것을 것입니다 요구한다.

신청 겸용성 단위

제시한 해결책은 여러가지로 둘 다의 제일 조금을 가지고 간다. It works first by detecting if the application was written for the native operating system. If not, it will load the application with its respective legacy system binaries. The accommodate the difference in system calls between the legacy binaries and native kernel, an Application Compatibility Module is placed in between to act as a translator for these calls. In certain cases where a comparative native system calls may not exist at all, the ACM could also be smart enough to provide the same functionality as the missing system call.

Hypothetically speaking, if the system detected an XP application it would load the XP system binaries (ex. system32_xp) and then a XP-to-WinNext compatibility module.

The benefit of this solution is it offers much broader application compatibility with relatively low investment on Microsoft’s behalf on the scale of per-application - they will only have to write a ACM for each legacy system they wish to support. Legacy applications will also be able to take full advantage of the system resources as a native application, because there is no emulation involved.

Notable Windows on Windows - the compatibility system used to provide 16-bit on 32-bit systems support and 32-bit on 64-bit systems support uses a similar concept.

One of the biggest gripes from most Windows enthusiasts has been the bloat legacy compatibility forces into Windows. Whilst this patent doesn’t specifically mention so, I presume such ACMs are modular and can be installed and removed on demand. For example, if you need to run Windows Vista applications in future versions of Windows, you will only download and install the Vista ACM Pack (with Vista binaries) for that operating system. Those who do not require legacy support will then be not required to install any ACMs.

Thinking about it, it could become a business model to sell ACMs separately to Windows - reducing the overall cost of Windows and charging a tiered price for legacy support. A cheaper and less bloated Windows, wouldn’t that be nice.