홈 | 정보 | 커뮤니티 | 개발 | myReactOS

네비게이션
  1. 홈
  2. 정보
  3. 커뮤니티
  4. 개발
  5. myReactOS

Development
  1. Overview
  2. How to take part
  3. Whitepaper
  4. Compiling ReactOS
  5. Developer FAQ
  6. Intellectual Property
  7. SVN Server
  8. Bugzilla
  9. Doxygen
  10. RosCMS
  11. Website Status
  12. Translate Website
  13. ReactOS CIA

Language

ReactOS Development > 개발자용 FAQ

 

개발자용 FAQ

ReactOS 개발자용 FAQ (Frequently Asked Questions)입니다. 사용자용은 사용자용 FAQ 을 참조하세요.

 

 

일반 사항

ReactOS에서 "마이크로소프트"라는 말을 어떻게 피할까?

마이크로소프트라는 말이 상당히 쓰일것이라고 생각된다. 레지스트리에서 특히 필요하다.

윈도우즈용 드라이버가 ReactOS에서 작동할까?

어떤 드라이버는 작동한다고 알려졌으나 구현되지 않은 커널 영역의 지원 드라이버에 대해서는 아직 의구심이 있다.

소스로 부터 ReactOS를 컴파일하려면 무엇이 필요할까?

다음 링크된 페이지를 참조하라. Build Environment page

차라리 Wine 프로젝트를 돕는게 낳지 않은가?

Wine프로젝트와 매우 밀접하게 작업하고 있다. Wine프로젝트는 ReactOS보다는 Linux와 더 가깝다. Wine프로젝트의 목표는 WineServer상에서 Windows API 전체를 구현하는 것이다. ReactOS에서 사용될 수 없는 WINE dll은 다음과 같다.NTDLL, USER32, KERNEL32, GDI32, ADVAPI. 나머지 WINE DLL들은 ReactOS에서 쓸 수 있다. 두 개의 프로젝트 사이의 상호 호환성에 대해서 작업하는 양쪽 프로젝트에 모두 참여하고 있는 개발자들도 있다. 우리는 Linux와 Wine의 결합으로는 마이크로소프트의 윈도우즈를 완전히 대치하는 것이 불가능하다고 생각한다. 마이크로소프트의 윈도우즈용 드라이버들과의 호환성 문제 때문를 해결할 수 있는 것은 결국 WINE으로는 불가능하고 ReactOS라야 가능하다고 생각한다.

ReactOS를 개발하려면 어떤 IDE를 사용해야 할까?

다음 링크를 참조하여 지원되는 코딩 에디터에 대한 정보를 얻기 바란다.using an IDE

소위 SEH문제는 어떤가?

Structured exception handling (SEH) 는 OS/2 나 Microsoft(R) Windows(R) NT와 마찬가지로 ReactOS용 프로그램에도 사용된다. SEH는 OS와 컴파일러에 의해 구현된다.(예약어: __try, __except, __finally). ReactOS자체는 SEH를 인식하고 SEH를 구현할 수 있게 한다. 그러나 현재까지는 GNU컴파일러가 SEH를 생성하지 못한다. 따라서 GNU컴파일러를 가지고는 SEH를 구현할 수 있는 드라이버나 응용 프로그램을 만들 수 없다.

그래픽 Subsystem

왜 그래픽 subsystem이 ring 3가 아니라 ring 0에 있는가?

간단히 답하면 마이크로소프트가 그렇게 했기 때문이고 우리는 드라이버 호환성을 목표로 하기 때문에 이것을 따라야 한다.

 

왜 마이크로소프트는 GUI를 ring 0에 놓았는가?

왜냐하면 속도 향상을 위해서이다. GUI-서버방식과 달리 자신의 프로세스에서 실행되므로 GUI 명령을 수행하는데는 context 변경이 필요 없다. 이것은 물론 시스템이 보다 복잡해지고 GUI에서 에러가 나면 시스템 전체를 복구해야 한다. 마이크로소프트에서도 윈도우즈 NT 4.0에서 GUI를 커널에 넣을때 같은 고민을 하였다. 마이크로소프트는 그때 GUI는 이미 충분히 안정화 되었고 잘못된 드라이버가 없다면 충돌이 날 일이 없으므로 그리고 유저 모드에서도 역시 비슷한 문제에 봉착할 것이므로 GUI를 커널에 넣었다.

 

ReactOS도 윈도우즈와 비슷한 보안 문제들을 가지고 있는가?

마이크로소프트의 윈도우즈 NT와 그 후속 OS들은 보안이 취약한 시스템이 아니다. 마이크로소프트의 몇 가지 잘못된 결정으로 보안이 취약해졌다고 생각한다. 예를 들면 윈도우즈 XP는 모든 사용자에게 기본값으로 관리자 권한을 준다. 몇 가지 서비스는 허술하게 코딩되었고 사용자의 편의성을 높이는 것이 종종 보안상의 취약점이 된다. 그러나 우리는 ReactOS에서 이런 것들을 조절할 수 있다. 문제가 되는 것은 마이크로소프트의 윈도우즈용 프로그램들은 보안성을 중시하지 않는 전통이 있다는 것이다.

 

어떤 GUI들이 지원되는가?

이것에 답하기 위해서 ReactOS와 윈도우즈에서 GUI가 어떻게 작동하는지 이해해야 한다.

- 그래픽 subsystem에 있는 DIB 엔진은 비디오 카드 드라이버와 연계해서 사각형, 선, BitBlit 함수등의 기본 그래픽 요소(primitive)들을 제공한다.

- 콘솔 윈도우를 포함한 윈도우를 만드는 기능을 제공하는 Win32 subsystem(csrss)이 있다.

- user32.dll은 약간 더 복잡한 윈도우를 제공하는데 버튼이나 체크박스 같은 것들이다.

- comctl32.dll은 훨씬 복잡한 윈도우를 제공하는데 파일 열기 대화상자 같은 것들이다.

- shell(예를 들어 탐색기)은 부팅시 시작되는 일반 프로그램이다. 아이콘들이 있는 바탕화면과 시작 메뉴를 만든다. 또다른 shell로 변경시킬 수도 있다. open source 탐색기 대체물이 LiteStep과 BlackBox인데 우리가 지원하려는 것들이다.

 

파일 시스템

ReactOS는 윈도우즈와 같이 파일 시스템 드라이버를 사용한다. 따라서 IFS(Installable File System) 인터페이스를 제공한다. ReactOS는 IFS 드라이버를 탑재하고

사용할 것이다. ReactOS를 작성하는 동안에는 마이크로소프트의 NT 고유의 IFS 드라이버를 탑재할 수 없다. 그러나 조만간 탑재 가능할 것이다.

 

FAT32 파일시스템의 FreeDOS 버젼을 쓸 수 있을까?

ReactOS는 여러 해 동안 FAT32를 지원해 왔다. 또다른 것은 필요없다.

ReactOS가 VFAT과 긴 파일명을 지원하나?

ReactOS은 내부적으로 긴 파일명과 유니코드를 지원한다. 그것을 어떻게 다루는가는 파일 시스템 드라이버에 달려있다. ReactOS에 있는 FAT 드라이버는 VFAT(FAT상의 긴 파일명)을 지원한다.

NTFS에 집중하지 않고 Ext2/3를 구현하면 어떤가?

NTFS는 향후 지원해야할 주요 특징이기 때문이다. Ext2/3는 물론 우리의 주제이나 NT를 위해 Ext2/3를 구현하는 것이 주목적인 프로젝트들이 이미 있다. 필요하면 이들 드라이버를 사용할 것이다.

 

NT를 위한 Ext2/3-IFS은 어디서 구할 수 있나?

다음 사이트들에서 구할 수 있다: http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm http://sys.xiloo.com/projects/projects.htm#ext2fsd http://ashedel.chat.ru/ext2fsnt/.

IFS를 프로그래밍하는 것을 내가 도울 수 있나?

있다. IFS 드라이버에 대해 할 일이 많다. 그러나 드라이버 프로그래밍 하는 것보다 IFS 프로그래밍하는 것이 더 어렵다고 할 만큼 어려운 분야이다. 당신이 진정한 커널 핵커라면 우리의 메일링 리스트에 와서 스스로를 알려라.

NTFS대신에 Ext2/3를 사용할 수 있나?

있다. 어떤 파일 시스템을 사용할지는 당신에게 달려있다. 그러나 현재는 NTFS도 Ext2/3도 파일 입출력을 위해 사용할 수 없다. 따라서 할 일이 많고 현재는 FAT-IFS만이 사용 가능하다.

리눅스 NTFS 프로젝트의 소스를 이용하면 어떤가?

그 소스들은 유용하다. 그러나 마이크로소프트의 NTFS만큼 완벽하지 못하고 쓰기가 지원되지 않는다. 현재는 NTFS가 우선순위에서 밀려 있어 관심있게 다루지 않는다.

NTFS 지원이 ReactOS의 성공에 중요한가?

NTFS를 언젠가는 지원할 것이지만 현재로서는 중요하게 다루지 않는다. NTFS는 하드 디스크에 대한 파일 시스템이다. 그러므로 NTFS로 포멧된 파티션에 대해서 접근할 때만 필요하다. 다른 파일 시스템들도 NTFS와의 철저한 호환성이 중요하지 않다면 NTFS의 고급 특성인 journalling, ACL(access control list), 압축, hard link등을 지원한다. 모든 소프트웨어는 CD나 DVD(ISO-9660 or UDFS) 또는 플로피 디스크(FAT)로 제공된다. 외부 저장 장치(compact flash, 메모리 스틱 등)도 FAT로 포멧되는 경향이다.

OS/2를 위한 JFS 소스가 무료로 배포되고 있다. 왜 ReactOS의 표준 파일 시스템으로 사용하지 않는가?

그렇다. 적어도 IFS의 하나로 이미 계획되 있다. JFS는 journalling, 대형 파일과 파티션 지원, ACL과 확장된 속성, hard link를 지원하는 첨단 파일 시스템이며 ReactOS에 맞을 것이다. 우리는 그것에 대해 작업하고 있고 당신의 도움을 환영한다.

대소문자 구분(즉 ext2)은 어떻게 다루는가?

대소문자 구분은 파일 시스템 자체의 문제가 아니다. 해당 드라이버의 문제이다. object manager가 namespace를 제공하면서 대소문자 구분을 다룬다. 그러므로 IFS 드라이버는 적절히 처리되야할 special case flag를 얻는다. 포팅된 파일 시스템 드라이버는 따라서 대소문자 구분과 비구분 모두를 다뤄야 한다.

32비트 컴퓨터에서 64비트 파일 시스템이 작동하나?

작동한다. 64비트 부분은 디스크에 대해서의 주소일 뿐이다. 드라이버를 포함한 실행 파일과는 아무런 관련이 없다. 실행 파일은 운영 체제와 같은 주소 비트를 갖는다.

현재ReactOS가 지원하는 파일 시스템들은?

FAT(12/16/32)과 VFAT, ISO-9660 - CD-ROM, NPFS - named pipe file system (internal FS), MSFS - mailslot file system (internal FS)

ReactOS가 지원하는 파일 시스템들은 어떤 것들이 있나?

우리의 목표는 가능한 한 많은 파일 시스템을 지원하는 것이다. IFS 드라이버들은 적어도 리눅스 만큼의 파일 시스템을 지원하기 위해서 개발될 수 있다. 그러나 개발은 쉽지 않고 시간이 걸릴 것이다. 적어도 다음은 지원할 것이다. FAT(12/16/32)과 VFAT, ISO-9660 - CD-ROM, ext3, NTFS or JFS, NPFS - named pipe file system (internal FS), MSFS - mailslot file system (internal FS)같은 고급 파일 시스템들

내 생각에는 이 괴상한 드라이브 문자를 없애는 것이 좋을 듯 싶은데요?

이것은 이미 마이크로소프트도 했던 생각이다. 그러나 그렇게 하지 않았다. ReactOS 팀에서도 그런 생각들이 있었다. 그러나 현재까지는 이 문제에 대해 충분한 결론에 도달해 있지 않다. 메모리 상의 파일 시스템이나 object manager의 namespace를 win32 응용프로그램이나 드라이브 문자에 노출시키는 아이디어들이 있었으나 모두 결점들을 가지고 있다. 주의:ReactOS나 마이크로소프트의 윈도우즈 NT 커널이나 드라이브 문자가 필요가 없다. CP/M에서 DOS를 거쳐 Win32로 내려온 유산일 뿐이다.

Redirector란 무엇인가?

이것은 IFS 드라이버의 특별한 형태이다. 디스크 상의 파일 시스템이 아니라 커널의 네트워크 스택 드라이버에 의존하여 원격 파일 시스템을 제공한다.(즉 SMB 공유)

파일 시스템 인식자는 무엇인가?

실제 파일 시스템 드라이버는 크기가 크다. 사용할 파티션이 없는데 확인을 위해서 로딩하는 것은 시간 낭비이다. 이런 이유 때문에 Dave Cutler(NT의 창시자)는 인식자(recognizer) 드라이버를 발명했다. 그것은 드라이버 아키텍쳐의 일부 처럼 여겨진다. 이 드라이버는 로딩되서 해당 IFS가 읽을 수 있는 파일 시스템을 위한 파티션이 있는지를 찾아본다. 있다면 해당 IFS를 로딩한다.

SEH 문제

OS/2와 마이크로소프트의 윈도우즈의 프로그래밍에서 사용되는 것처럼 ReactOS의 프로그래밍에도 Structured exception handling (SEH)가 사용된다. SEH는 OS와 컴파일러에 의해 구현된다.(예약어: __try, __except, __finally). ReactOS자체는 SEH를 인식하고 SEH를 구현할 수 있게 한다. 그러나 현재까지는 GNU컴파일러가 SEH를 생성하지 못한다. 따라서 GNU컴파일러를 가지고는 SEH를 구현할 수 있는 드라이버나 응용 프로그램을 만들 수 없다.

디버깅

사용자 모드에서 처리되지 않는 에러를 추적하는 방법은?

추적은 다음과 같을 것이다. (KERNEL32:process/create.c:328) 처리되지 않은 에러 때문에 프로세스가 갑자기 끝났다. (KERNEL32:process/create.c:329) 주소: 761a13e0 (KERNEL32:process/create.c:334) 프레임: (KERNEL32:process/create.c:338) 761a2be9 reactos/baseaddress.cfg를 보고 추적하려는 주소와 일치하는 가장 가까운 낮은 주소를 찾아라. 해당 dll의 .map파일을 뷰어에서 열고 offset을 찾아라.

ReactOS is a registered trademark or a trademark of ReactOS Foundation in the United States and other countries.