내가 이해하는 한, 에뮬레이터는 (간단한 방법으로) 시스템 X의 함수를 사용하는 프로그램의 함수 호출을 프로그램이 실행 중인 시스템 Y에서 사용하는 함수로 변환하거나 대체합니다.와인프로젝트에서는 다음과 같은 이유로 Wine이 에뮬레이터가 아니라고 주장합니다.
가상 머신이나 에뮬레이터와 같은 내부 Windows 로직을 시뮬레이션하는 대신 Wine은 Windows API 호출을 POSIX 호출로 즉시 변환하여 다른 방법의 성능 및 메모리 패널티를 제거하고 Windows 애플리케이션을 데스크톱에 깔끔하게 통합할 수 있도록 합니다.
그렇다면 에뮬레이터와 가상 머신은 Windows가 아닌 호스트 시스템에서 내부 Windows 논리를 어떻게 에뮬레이션합니까? Windows 시스템 호출을 호스트 자체 호출로 변환하는 것이 아닌가요? 에뮬레이터와 비에뮬레이터(예: Wine)의 차이점은 에뮬레이터가 전체 운영 체제를 에뮬레이트한 다음 애플리케이션이 에뮬레이터와 통신하고 있다는 사실을 모른 채 해당 시스템 API를 사용하는 반면, 비에뮬레이터는 애플리케이션의 호출을 지시한다는 것입니다. 호스트(애플리케이션도 이에 대해 알지 못할 수 있음)? 추가 간접 수준이 에뮬레이터와 Wine 간의 유일한 차이점입니까?
답변1
그렇다면 에뮬레이터와 가상 머신은 Windows가 아닌 호스트 시스템에서 내부 Windows 논리를 어떻게 에뮬레이션합니까? Windows 시스템 호출을 호스트 자체 호출로 변환하는 것이 아닌가요?
아니요, 또는 적어도 WINE과는 다릅니다. 사용자 공간에서 시스템 호출을 그대로 변환합니다. 에뮬레이터는 시스템 호출을 직접 변환하지 않고 보다 우회적인 경로를 통해 이 작업을 추상적으로 수행합니다.
진짜에뮬레이터가상 만들기기계(예: x86-64), 가상이 아님운영 체제. 이론적으로는 이러한 유형의 시스템용으로 설계된 모든 운영 체제를 실행할 수 있습니다. 일반적으로 "에뮬레이터"에는 운영 체제가 포함되어 있지만 실제로 에뮬레이션하는 것은 실제 시스템에서 실행되는 것과 동일한 운영 체제를 포함합니다.
에뮬레이터는 때때로 호스트 컴퓨터와 다른 하드웨어를 에뮬레이트하는 데 사용되지만, 하나의 운영 체제를 다른 운영 체제에서 실행하기 위해 정확히 동일한 하드웨어를 에뮬레이트하는 데에도 사용됩니다.
이와 달리 WINE은 실제로 Windows가 아닙니다. Windows의 실제 복사본이 포함된 x86-64 에뮬레이터를 실행할 수 있지만 WINE은 아닙니다. 그들은 실제로 에뮬레이터보다 더 효율적이라고 주장하는데, 이는 일리가 있습니다. 단지 시스템 호출을 변환하는 오버헤드는 아마도 가상 머신을 실행하는 것보다 적을 것입니다. 단점은 WINE이 Windows 전용이라는 점입니다. 다른 운영 체제처럼 사용할 수 없습니다.일반 가상 머신.
답변2
Java Virtual Machine을 고려해보세요. 어떤 JVM도 다른 JVM을 모방하지 않으며 모두 사양을 구현합니다. Wine은 win32 API를 시뮬레이션하지 않지만 이를 구현한 것입니다. 사양과 현실이 반드시 일치할 필요는 없으며 Microsoft의 구현과 Wine의 구현 모두 결함이 있는 코드가 작동하도록 하는 해결 방법을 가지고 있으며 특정 프로젝트에 대해 어떤 구현이 더 나은 목표인지 반드시 분명하지는 않습니다.
답변3
Wine은 Windows API 호출을 가로채서 즉시 해당 Linux API 호출로 변환하는 심입니다. 에뮬레이터 또는 가상 머신은 실제 머신을 시뮬레이션합니다. 분명히 스페이서가 더 효과적이지만 원하는 기능을 완전히 모방하지 못할 수도 있습니다.
답변4
와인은 Python, Java 또는 기타 런타임과 같습니다. Wine은 Linux/Unix에서 실행되는 Darling과 같은 Windows 실행 파일 및 라이브러리(Linux에서 실행되는 MacOs 앱 및 동적 라이브러리)에서 실행 가능하며 단순한 런타임용 에뮬레이터 그 이상입니다.