Win32 에뮬 프로젝트들은 실패? 좌절? 진행?

win32에뮬이 리눅스에서 완벽하게 동작하면 리눅스는 망할 겁니다.

OS/2의 전례에서 알 수 있듯이 독약이죠.

그저 적당히... 동적하는 것은 좋아도 그이상이면......

그리고 윈도우용은 윈도우에서 쓰세요. 미쳤다고 윈도우용을 리눅스에서 들립니까?? 뭐 저도 미친척하고 돌리긴 하지만 차라리 윈도를 켜서 씁니다...

에뮬하니..

갑자기 게임기 에뮬이 생각나버렸습니다 (푸핫;; )

음.

1. 윈도우즈 소스코드 유출, 일부만이라고 봤던 것 같은데.. 아닌가요?;
2. 어느정도 빼앗는게 경쟁해서 잠식아닌가요?;; 현실상 대등하지 못하다는 뜻은 이하의 답글에서 읽고 동의합니다만, "5% 하면 매니아의 잠식이고, 20%하면 경쟁상대다.." 이런식으로 딱 갈라 말하기도 어렵고, 전적으로 리눅스가 이뻐서 -o- 그렇게 믿고싶지 않아요~ ㅎㅎ 즉, 현실을 섣불리 제단해서 아예 가능성을 차단하면 토론이 이루어지기 어려운 것 같습니다. (많은 지식이 있는 분들이 그러면.. 저같은 초짜는 쫍니다 -o-; )

전.. 윈도 에뮬이 오락기 에뮬처럼 되면 좋겠어요 으하하하~ -o- 하드웨어가 받혀주면 속도 문제는 줄어들테고, 안정성과 기능만 확보된다면, 충분히 "사용자"는 있으리라 생각하거든요. 사용자가 있다는 것이 곧 필요성이 있다는 것 아닐까요? :)

물론, 리눅스가 오직 윈도우즈의 견제OS로서의 역할을 위해, swithing을 위한 유인책으로만 윈도우즈 에뮬을 바라보고 싶지는 않습니다. 그런 면에서 마지막 줄은 정말 의미심장하고, 동감합니다.

...하지만 결과로 보면 그렇게 될수는 있겠지요? 그런 희망을 "그건 무가치하다"라고 못밖는 것은.. 슬퍼요 흑 ㅠㅠ

어쨌든, 토론의 원 글에 의거하여 -_-; mogua는 어떻게 되가는지, 그리고 다른 프로젝트가 어떤 상황인지 궁금합니다.

솔직히 wine은 꽤 완성도 있는 편이라고 생각했었습니다. 스타도 되고, 포샵도 되고ㅎㅎㅎ;; 아무 설정 없이, 그냥 윈도우 어플 하나 까는데 실행되서 놀라기도 하고..- finale 2005, 악보 사보 프로그램입니다 - 다른 분들은 어떻게 생각하시나요?

덧. 그러고 보니, 글 제목은 에뮬의 진행상황에 대해서.. 라고 있는데, 글 내용은 정작, 에뮬은 필요하지 않은 것 아닌가! 라고 되어 있어서 살짝 헷갈리네요^^; 하지만, 에뮬이 과연 필요한가! 등등에 대한 위분들의 토론과 비슷한 것을 여러번 본 적이 있는 것 같아서.. 전자쪽으로 한번 끝을 살짝 마무리해봅니다 ㅎㅎ

"다만 짝퉁, 아류작은 절대로 오리지날을 능가할 수 없습니다."
이건 98%쯤은 맞는 말이지만, 2%쯤은 예외도 있기 때문에
반드시 실패한다라는 말보다는 실패할 가능성이 매우 높다라는 말로
수용하겠습니다.

저도 리눅스가 win32 에뮬에 전념하거나 혹은 완벽한 win32 클론을
목표로 한다면, 실패할 확률이 높다고 봅니다.

단지, 리눅스의 부족한 부분을 커버하는 측면에서 이용한다면,
충분하리라 생각합니다.

그리고, 리눅스는 리눅스 자신만의 영역과 색깔을 가지고
시장에 진입해도 어느정도는 승산이 있을 만큼 성장했다고 봅니다.

안녕하세요 유령 키다군 입니다..^^;

유출된 소스 코드를 이용하여 프로그램을 작성할 경우,
추후에 문제가 될 소지가 크므로,
많은 프로젝트들은 제작자들에게 유출된 소스를 보지 말것을 요구하고 있습니다.

글제목도 그렇고 전체 분위기가 좀 오해의 소지가 있기에 잠깐 설명을 드리자면 Mogua는 윈도 에뮬이 아닙니다. 윈도 에뮬이라는 것은 윈도 환경을 윈도가 아닌 환경(리눅스같은)에서 흉내낸다는 것을 의미하는데, Mogua는 윈도 환경을 커널 수준에서부터 그대로 따르고 있습니다. DR-DOS를 MS-DOS 클론이라고 부르기는 해도 MS-DOS 에뮬이라고 부르는 사람은 없듯이, 그것과 마찬가지라고 생각하시면 되겠습니다.

윈도 에뮬이건 윈도 호환 OS건 통칭할 때는 윈도 애플리케이션 실행 환경이 더 적절하지 않을까 싶네요. 줄여서 윈도 실행 환경...

소프트웨어 구입비는 논외입니까?

사실 wine을 사용함의 장점은 추가로 운영체제 비용을 지불할 필요가 없는 것도 있습니다.

EULA를 요기조기 피해가면서, 어떤 부분에서는 매우 느리긴 해도 쓸만한 M$클론으로
바꾸어 주기도 하죠.

밴더풀이나 퍼시피카가 나오면,
음... 그럼 Mogua가 활성화 되겠군요!!

OS 추가구입이 필요하긴 하지만 QEMU란 것도 있지요.

QEMU 그 자체는 Native에 비하여 5배이상 느리니까 실용성은 크지 않지만, 최근에 QEMU Accelerator 라는 것이 나왔는데 이를 이용하면 Native에 비하여 1~2배 느린 정도로 이용할수 있다 합니다.

http://www.qemu.org/qemu-accel.html

버전 0.7.1 이상부터 accelerator를 쓸수 있는 것 같네요. 커널 모듈의 형태로 들어가는 것 같습니다. 아쉬운 점이 있다면 qemu-accelerator는 오픈소스의 형태로 개발되는 것은 아닌 것 같고 host os가 x86 linux에서만 가능합니다.

저는 Debian sid의 0.7.0을 쓰고 있어 아직 QEMU accerator를 경험하지는 못했는데... Native에 비해 1-2배 정도라면 꽤 쓸만하겠지요.

첫번째 스냅샷을 언제쯤으로 계획하고 계신가요?
기대하고 있습니다

지금 mono의 winform은 기존의 win32에서 swt기반으로 전환중입니다.
기다리면 쓸만한게 나올겁니다.

이런 불필요한 논쟁보다 그냥 커널 소스를 훑어보고 직접 확인하는 게 빠를 것 같습니다.

이와 같은 오해는 아마도 커널의 개념 차이에서 온 것 같습니다. 원래 Mach 커널은 커널 안에 스레드 지원, 메시지 전달, 메모리 관리자 같은 필수적인 기능만 들어 있고 파일 시스템이나 특정 OS 구조에 의존하는 시스템콜 같은 기능은 별도의 외부 프로세스(서버)를 통해 구현하는 마이크로커널 방식입니다. 가령 Mach를 가지고 유닉스 호환 OS를 만든 경우(GNU처럼) 유닉스 시스템콜을 서브시스템간 메시지로 변환해주는 레이어가 커널 외부에 따로 있고, UFS같은 파일시스템 서버 프로세스도 커널 밖에 따로 존재합니다(GNU/허드를 써보신 분들은 파일시스템 트랜슬레이터를 기억하실 겁니다). 그런데 이렇게 만들다보니 정작 제일 중요한 성능이 심각하게 떨어지는 바람에 애플이 Mac OS X를 개발하면서(NeXT에서부터 그랬는지도 모르겠습니다만) 마이크로커널과 유저모드 서버들을 도로 모놀리딕 커널로 합쳐버렸거든요. 따라서 현재 구조는 단지 Mach에서 몇몇 코드를 가져왔을 뿐 전체적으로는 BSD 커널과 훨씬 유사합니다.

x86 관련해서는 instruction set 등이 명확하게 드러나 있었지만 winapi 는 다릅니다... 문서화 되지 않은 부분이 상당히 많습니다...

ms-windows 호환 플랫폼을 만든다고 하더라도 위에 다른 분이 얘기하셨듯이... 정상적으로 애플리케이션이 돌지 않을 경우 누가 책임을 져 줄까요 ;)

그리고 그냥 윈도우 클론에다가 오픈소스도 아닌 경우라면 그다지 관심이 가지는 않을 듯 하군요...

Windows를 쓰지 않으면서도 Win32 어플리케이션을 작동하려는 환경으로서 Mogua를 만드는건데 MS로부터 공식지원이나 계약을 왜 해야 하는지 설득력은 부족하다고 봅니다. MS가 해줄리도 없다고 봅니다만.

제가 보기엔 오히려 이런 시나리오가 보이는군요. Mogua가 잘 돌고, 쓸만하다고 입증되면 Mogua를 퇴출시키기 위해 먼저 소송을 걸어보고, 그게 잘 안될거 같으면 모구아를 포기하는 댓가로 방준영님을 연봉 수십억에 고용할 것 같습니다 :twisted:

Windows나 MS-DOS도 MS가 자기 힘으로만 100% 다 만든거 아닙니다. MS-DOS는 CP/M 베낀 OS의 소스코드를 사서 시작한것이고, Windows는 IBM에 파견한 OS/2 개발팀이 복귀해서 만든것입니다.

이제와서 그런 초창기 환경을 말하긴 좀 그렇긴 합니다만, 오리지날이 아니라면 쓰지 않겠다, 또는 쓸 이유가 없다라는식의 언급은 기술과 환경의 개선이나 진보에 대한 노력을 필요 이상으로 폄하한다고 보입니다.

거기서 조금 더 나가면 MS의 기득권 옹호 차원으로까지 비칠수도 있겠습니다. 흔히 그러지 않습니까. MS는 일반 기업이 아니라 세금걷는거고 (윈도우 요금이 PC세~), 인텔과 삼성도 보통 기업이 아니라 조폐창 (CPU와 램을 현금 찍듯 찍어내는~) 거라고요.

모구아로 읽건 모과로 읽건 별 상관은 안하시는 모양입니다만, 방준영님이 모구아로 발음하시는걸 들었습니다. (아니..목우아였던가? :shock: )

불현듯... 정치인들이 생각납니다. '아 국민들 절반 이상만 그분을 지지해주면 그분이 대통령이 될 수 있으니까, 경쟁상대인 그분만 포기하면 된다니까~'

MS은 안그래도 리눅스 안 퍼지게 막는데 혈안인데 리눅스 유저들이 MS에게 MSIE를 리눅스용으로 만들어 달라고 요구하면 호락호락 잘 만들어 줄거라고 생각하시는 사고방식은... 저나 제가 아는 다른 많은 F/OSS 유저들과는 좀 차원이 다르신 것 같다는 생각이 듭니다. 낙관주의라고 하기도 좀 어렵고... 뭐랄까... (아ㅤㅎㅐㅎㅤㅎㅐㅎ하다고 하면 좀 실례일 것 같고)

리눅스를 기본OS로 파는 기업들도 벤처 붐때 꽤 생겨났지만 수익을 창출하는데 실패해서 거의 다 문 닫았습니다. OS없는 PC는 국내라면 용산에서도 많이 팔지만 시장 점유율은 5% 남짓한 것으로 압니다. (그리고 그 5%의 98%는 아마 윈도우를 불법복제본으로 쓸 겁니다)

선택의 기회 문제라고 보지 않습니다. F/OSS 진영의 속성상 개발자 인력 자원을 독재적인 권력으로 컨트롤이 가능한 강력한 마케팅적 황제를 가질 수 없다는 점이 확산의 장애로 남을 것입니다. (반대로 MS는 그런 황제의 존재가 최대 무기입니다.)

그리고 윈도 app을 돌릴 수 있는 linux또는 기타 OS들은 꼭 개발자만 원한다고 보지도 않습니다. 다른 쓰레드에서도 지적을 한 바가 있는데, 아마 마케팅 전략으로 게임정도만 커버가 가능한 윈도우 에뮬레이션 OS가 나와서, 윈도XP 홈 에디션의 반값에만 판매한다고 쳐도 국내 게임방(내지 PC방) 절반 이상 판매 가능할겁니다. 그정도면 최소 3-400만 카피는 됩니다.

물론 MS라는 최대의 경쟁자가 내놓는 장벽을 성공적으로 통과하거나 우회한다는 전제가 필요하긴 하지만 말입니다.

기본적으로 자본주의 사회의 산업은 시장논리로 움직이지, 희망사항으로 움직이지 않습니다. 만약 우리같은 호사가가 아닌 기업이 시장의 현실적 또는 잠재적 요구를 멋대로 해석하여 그에 따른 결정을 내린다면 현실에서 치명적 타격을 입을 것입니다.

잠시 딴지를 걸자면...

데이터베이스 전공자로서 OODBMS를 연구해 본 결론을 잠시 인용하자면

1. OODMBS는 호스트 랭기지로 반드시 OOP를 써야 하며,
2. SQL에 해당하는 표준 질의 언어를 만드는 것이 거의 불가능할 정도로 난해하며
3. 기본적으로 class-instance와 다형성의 매핑이 그래프조차 아닌 네트워크 모델링에 최적화되어 있는 것이기 때문에 RDBMS보다 표현성이 더욱 제약을 받는 점

때문에 앞으로 시간이 한참 지나도 주류로 자리 잡을 수 없다고 DB관련 연구자들이 결론을 내린 상황입니다.

그래서 OODBMS 벤더들도 특수용도의 데이터베이스에 주로 사용되며 범용시장에는 진출할 생각을 하지 않습니다.

특히 OODDBMS를 쓸 때에는 질의의 결과를 돌려줄 인스턴스의 타입을 알 수 없는 상황이기 때문에 스몰토크 수준의 다이내믹 바인딩을 지원하는 OOP언어가 주류가 되지 않는 한 OODBMS는 오히려 RDBMS보다 불편합니다.

C++은 기본적으로 스태틱 바인딩이라서 OODBMS에 붙여도 인스턴스를 바로 변수에 로딩하지 못하고, C처럼 스트링 처리밖에 못합니다. 그것은 OODBMS가 내포한 가장 강력한 장점인 다양한 표현력을 포기해야 한다는 것을 뜻합니다.

또 OODBMS는 관계대수에 기반한 RDBMS와 달리 수학적 이론 위에 자리 잡은 데이터베이스가 아닙니다.

그리고 ORDBMS 경우에는 클래스를 레코드 타입으로 가질 수 있는 RDBMS이지 object 와 method (또는 operator) 위에 올라선 게 아닙니다. ORDBMS는 OODBMS와 RDBMS의 중간형이라기보다 RDBMS의 object 확장이라고 봐야 합니다. (기본 연산은 SQL 이며 instance의 비교부분만 oop를 사용합니다)

참고로 국제적으로 가장 권위있는 OODBMS의 권위자는 '김원' 박사님이고, 이분이 저술한 OODBMS 개념서가 현재 거의 전세계적으로OODBMS 강좌의 입문서로 활용됩니다. 이분도 90년대 초에OODBMS 관련 연구를 중지하고 UniSQL을 설립하셨었습니다.

WSDL하고 유사하군요...
왠지 java하고 궁합이 잘 맞을 것 같다는 생각이 드네요.

java도 부족한가?
WSDL에 따라 class가 자동 생성되기는 해도,
매번 동적으로 class가 만들어 지는 것은 아니니...

그런가요?? 함 물어봐야겠습니다...
저는 주워들은 이야기라 뭐 뒷받침할 근거고 뭐고도 없는지라..

이야기 들려주셔서 감사합니다..

kenny007one 님 말씀 참 이상합니다 -_-;
CPU 가 같아야 경쟁을 하는건가요?
아키텍쳐를 떠나 노리는 시장이 같으면 경쟁하는거겠지요.

애플은 이미 충분히 데스크탑 시장에서 경쟁하고 있었습니다.
한국시장이 특히 외소했을 뿐이지요.

x86 으로 선회하여 한번 경쟁할 기미를 보일까 하는 정도가 아니라
뒤집어 엎어보려는 전략이겠지요 --; ( 뒤집어 엎을 수 있을진 아무도 모르겠지만요. 적어도 한국시장에선 못 엎겠지요. )

MS Office 제품군, 버츄얼PC, 등등 Mac OS X 로 나오고, 수 많은 좋은 프로그램들이 Mac OS X 버젼이 나오는걸 보면 모르시겠습니까 -_-;;

p.s. 심지어 wwdc 2005 기조연설에선 ms office 쪽에서도 발표가 있었죠. 어차피 ms 는 소프트웨어를 파는 회사지 하드웨어를 파는 회사가 아니란거죠. mac os x 가 x86 이든 ppc 가 되었든 팔려서 office 수요로 필요로 한다면 ms 는 그걸 얼마든지 좋게 만들어서 팔겠다는 거죠.

오늘 찾아가서 여쭤보니깐 교수님께서 맞는 말이라고 하시면서
이런저런 이야기를 해주시더라구요..

근데 제가 허접해서 거의 이해를 못했습니다.. ㅡㅡ;

하지만 한가지는 알아들은건 오라클의 최근 버젼에서는
ORDBMS가 모두 구현되어 있다는 거였습니다...

mac 은 win32 로 포팅되는게 아닙니다... x86 으로 포팅되는 것일 뿐이죠... mac 이 인텔진영으로 포팅된다고 달라지는건 없을 듯 하군요