[정보] MS의 차기 OS는 호환성이 전혀 없다?

 

 

 

 

In the face of the mass-media criticism of Windows Vista, mainly with regards to the performance issues present when compared to Windows XP on hardware with similar specifications, very little information has been presented with regards to the performance of Windows 7. This article, however, shall change that.

비스타가 특히 XP와 비교된 성능차이 때문에 미디어에서 비판을 받는 이세상에서 차기작 차기작 운영체제인 Windows 7의 정보는 조금밖에 흘러나오지 않았다.  하지만 이 기사가 그 개념을 바꿀것이다.

For Windows Vista, Microsoft had to change their design and development strategy in order to comply with the DoJ and EU regulations regarding the anti-trust issues present in previous versions of Windows; specifically, the integration of assistive applications such as Internet Explorer and Windows Media Player into the core operating system. Competitors complained that offering internet and media solutions with the operating system harmed competition in the marketplace (despite other operating systems such as Mac OS X and Linux apparently being immune from such criticism).

마이크로소프트는 독점방지법에 관해 윈도우즈 비스타에 관한 디자인과 개발계획을 바꿀수밖에 없었다(특히 인터넷 익스플로러와 윈도우즈미디어플레이어).  마이크로소프트사의 경쟁자들은 요즘의 운영체제가 인터넷과 미디어 환경에 마켓 경쟁에 치명적인 피해를 준다고 하소연했다(맥과 리눅스는 이런 비판을 받지는 않았지만..)
   
In response to this, Microsoft made fundamental changes to the way Windows Vista was linked together; shifting more towards modular designs rather than the monolithic processes used in previous versions of Windows. This increased amount of componentization, while satisfying the DoJ and EU, also led to performance issues due to the increased number of libraries which comprise the operating system. On traditional hard drives, the more separate files which the operating system has to load, the more seeking across the hard drive is required, and therefore overall performance takes a hit.

마이크로소프트는 이와 반응해 많은 비스타와 관련된 많은 변환을 주었다. 그 한가지는 예전보다는 더 플렉서블한 디자인이다.  이것은 독점방지법을 충족해 주었지만, 운영체제의 라이브러리를 뭉치는 과정에서 성능적 문제가 형성되었다. 예전의 하드드라이브에서는 많은 파일이 불러올때는 더 많은 찾기성능이 필요로 하였다.  그러므로 성능에 큰 피해가 있었다.

Another reason for Windows Vista's performance issues is the way in which Microsoft approached backwards compatibility in Vista. The operating system stores multiple copies of core system libraries, as each revision of a library typically adds/removes functions, and applications compiled with dynamic links to a specific version of a DLL file may call on functions not present in the currently installed library. Vista aims to solve this issue through the WinSxS collection; essentially a massive store of every differing version of libraries present on the system. That way, when an application makes a call for a dynamically linked library, Vista queries the WinSxS cache for the correct version, which is then loaded into memory. On the average system, this directory can be several gigabytes in size, with much of the code duplicated between the separate versions many times.

또 비스타의 성능에 피해를 미친 문제가 있었다면 호환성이다. 비스타는 코어시스템 라이브러리를 수 번 저장한다.  비스타는 이 문제를 풀려고 WinSxS를 도입했다. 이는 다른 버젼의 라이브러리를 한곳에 저장할수있도록 해준다. 이러므로 애플릭케이션이 라이브러리에서 불러올때 메모리에서부터 불러온다.  보통 시스템에서는 이 다렉토리는 수 번 저장을 하기때문에 기가바이트이상이 넘는 정도의 용량이다.

Windows 7 takes a different approach to the componentization and backwards compatibility issues; in short, it doesn't think about them at all. Windows 7 will be a from-the-ground-up packaging of the Windows codebase; partially source, but not binary compatible with previous versions of Windows. Making the break from backwards compatibility is a dangerous proposal but a dream for software developers. Performance of native applications can be increased, distribution sizes can be cut down, functionality can be added without the worry of breaking old applications, and the overall end-user experience can be significantly improved.

하지만 윈도우즈 7은 전혀 다른 길을 선택했다- 한마디로 말하자면 호환성이 전혀없다.  윈도우즈 7은 처음부터 다시 시작되는 윈도우즈 코드베이스 운영체제다. 미미한 소스지만 전 운영체제와 호환성은 전혀없다.  호환성에서 벗어나는것은 아주 위험한 재시작이지만 소프트웨어 메이커들에게는 꿈이다. 프로그램은 더 성능이 좋아지고, 그에 필요한 용량을 줄어지고, 새로운 업데이트는 전의 프로그램에 치명타를 입히는 염려없이 업데이트가 가능하고 모든 유저들에게는 전혀 다른 경험을 하기 도와준다.

However, Windows' lure has always been that applications from older versions of Windows are almost guaranteed to work post-upgrade; this is in contrast to older UNIX solutions where upgrading the system could render old applications useless without access to the source code. On an operating system which uses a binary distribution model, this is an unreasonable expectation. However, there is one company which made a success out of breaking backwards compatibility, using a method which Microsoft are seeking to emulate with the launch of Windows 7. The company in question is Apple.

하지만 윈도우즈는 Unix 솔루션과는 옛 프로그램들은 언젠가는 차기작으로 업그레이드 된다고 본다. 이것은 과연 기상한 현상이다. 하지만 지금의 윈도우즈7의 도전과 같이 이 호환성을 깨고 성공한 회사는 하나있다. 그것이 바로 Apple사.

During Apple's death throes back at the start of the decade, Steve Jobs made a bold decision; to replace the old, proven Mac OS lineage with a UNIX-based platform running a custom GUI. The purpose of this was to offer potential customers a significant reason to switch to Apple's hardware and software solutions. Mac OS X was such a success - despite breaking backwards compatibility - that many customers were willing to put up with Apple's hardware, which ranked far below Wintel solutions in terms of performance, in order to obtain the hardware-locked user experience of their new flagship operating system.

Apple took an unorthodox approach in order to offer Mac OS 9 users the ability to retain their existing software while still upgrading to the improved Mac OS X experience; the virtual machine. Essentially, Mac OS X contained 3 separate application environments; Cocoa, Carbon, and Classic.

Cocoa was the name for the native, Objective-C environment which allowed code to execute directly on Mac OS X without any interpretation or legacy libraries. Carbon was a mid-point solution which allowed older, Mac OS 9 code to be recompiled and then executed in the Mac OS X environment, without providing access to the newer, native UI elements. Classic, the most interesting of the three environments, is the approach that Microsoft will be taking with Windows 7. Essentially, Classic provided a complete API and binary abstraction layer which allows Mac OS 9 code to run within a "virtual machine" inside Mac OS X. Applications retain the appearance and behaviour that they have on the older Mac OS platform, yet still having access to the Mac OS X system resources.

In Windows 7, Microsoft will break from the Windows' norm by breaking previous API compatibility, offering new API frameworks as a native solution, and providing support for legacy frameworks (COM, ATL, .NET Framework, etc) through monolithic libraries designed to provide the functionality of all previous revisions of the modules in question. This extends/replaces the WinSxS philosophy, providing every single function, past and present, in fully comprehensive libraries. This should allow the majority of legacy applications to run perfectly, while still retaining native performance for applications compiled specifically with the Windows 7 platform in mind. It should also be possible for applications produced with previous versions of Visual Studio to be directly recompiled into native code using the new API frameworks.

This also allows Microsoft to neatly sidestep the DoJ and EU anti-trust rulings, as including the MSHTML library (Internet Explorer's rendering engine) in the monolithic libraries would provide support for the old rendering functions of Explorer to legacy applications while still remaining hidden from the end-user, the primary complaint in the antitrust cases. On the Windows 7 side of things, Internet Explorer can be abstracted from the Windows 7 codebase making removal/inclusion as simple as installing a normal application.

While the anti-Microsoft naysayers out there will claim that this is unethical business practice, however, technical users will appreciate that this is an excellent way of providing new features while maintaining backwards compatibility with legacy applications.

 

 

 

 

해석되있는건 여기까지네요.

 

대략 능력자분이 나와주시길 빌며, 아무튼 정보글.