Linux에서 Windows NT 애플리케이션을 지원하는 것을 방해하는 요인은 무엇입니까? [폐쇄]

어떤 의미에서는 노력해왔거나 노력하고 있습니다. 이것반응 OSWin 95 운영 체제를 복제하려는 시도였으며 그들이 직면한 문제는 NT 복제 시도를 대표하는 것이었습니다.

1. Microsoft는 프로그래머가 엔지니어 복제본을 존중할 수 있는 것보다 더 빠르게 업데이트와 변경 사항을 의도적으로 개발합니다. Microsoft는 항상 현재 운영 체제가 출시되기 전에 차세대 운영 체제 개발을 시작하여 기능과 코드를 독점적으로 유지합니다. 그들은 Win 7이 출시되기 전에 Win 10을 시작했고, Win 10이 출시되기 전에 Win 11을 시작했습니다. (예, 그들은 Win 10이 마지막 운영 체제라고 거짓말을 했습니다!) 우리가 말하는 것처럼 그들은 차세대 운영 체제를 개발하고 있습니다.

2. 일반적으로 Microsoft 제품은 복제에 시간을 투자할 만큼 많은 청중을 끌어들일 만큼 매력적이지 않습니다. 대신, 대부분의 사람들은 "더 나은" 것 또는 다른 것을 원합니다.

3. 위에서 언급한 REACT OS는 20년이 넘는 개발 기간이 지났지만 여전히 상당히 불안정합니다. 또한 하드웨어가 너무 빨리 변경되므로 5~10년 전에 안정적인 버전을 사용했더라도 새로운 하드웨어 요구 사항이 팀의 성과에 부담을 줄 수 있습니다.

모든 새로운 사운드 카드, 비디오 카드 및 칩과의 호환성을 유지하려는 노력을 상상해 보십시오! 이것은 끝없는 감사할 일이 될 것입니다 :(

Linux 커널과 Windows NT 시스템 호출을 모두 지원하는 단일 커널을 개발하는 데 방해가 되는 문제는 무엇입니까?

1. 사용 가능한 개발자 시간.
2. Windows와 Linux는 여러 면에서 다릅니다. 한 API에 대해 "파일에 대한 동시 쓰기 액세스가 항상 모든 판독기 순서로 발생"하도록 보장하고 다른 API에 대해 "쓰기 액세스가 절대 발생하지 않을 수 있음"을 보장하는 경우 다른 API에 의해 차단되지 않습니다. 쓰다"라고 입력하면 논리적 충돌이 발생합니다(논리적 충돌이라고 생각하지 않습니다). 그런데 이 예제가 두 운영 체제 모두에서 작동하는지 알 수 없습니다. ). 하나를 다른 것으로부터 추상화할 수 있지만 일반적으로 그 과정에서 일부 기능이 손실됩니다.

가장 기본적인 수준에서 Windows 스타일 시스템 호출도 지원하는 수정된 버전의 Linux 커널을 만들 수 있기를 바랍니다(시간이 많이 걸리긴 하지만).

Windows NT에는 UNIX 스타일 API(NT4로 시작!)인 POSIX API가 있으며 Linux(거의)도 마찬가지입니다. 따라서 이 운영 체제는 어느 정도 존재하며 Windows입니다.

나는 WINE에 대해 잘 모르지만 Windows 호출을 Linux에 해당하는 호출로 변환하는 일종의 호환성 레이어 역할을 하는 비슷한 작업을 수행한다고 상상합니다.

예! 일부 시스템 호출을 번역하고 Windows와 함께 제공되는 사용자 모드 라이브러리(일부)를 제공합니다.

Microsoft의 저작권 문제인가요?

아마도 그렇지 않을 것입니다. Java API를 둘러싼 Oracle 대 Google API에 저작권을 부여할 수 없다는 것이 법정에서 입증되었습니다(미국). 하지만 저는 변호사가 아니며 이것이 Windows API로 얼마나 확장될지는 알기 어렵습니다. 그러나 WINE은 아직 문제가 발생하지 않았으므로 지금부터 이를 시행하기는 어려울 수 있습니다.

앞서 언급한 Frankenstein 커널을 만들고 Microsoft의 ".exe" 실행 파일 형식을 해석하는 방법을 알려준다면 Windows 기반 및 UNIX 기반 실행 파일을 실행할 수 있습니까?

"커널"이라는 단어는 무시하십시오. WINE 및 Linux 커널을 사용하면 binfmt_misc현재 이 작업을 수행할 수 있습니다(대부분의 Windows 소프트웨어의 경우). 이것은 매우 일반적인 관행입니다!