자신의 운영 체제를 작성하는 방법. 간단한 UNIX 계열 OS를 만들기 위한 가이드입니다. 타사 프로그램 실행

요점으로 가시면...

OS는 멀티태스킹(일반적으로)을 구현하고 이러한 작업 간의 리소스 분배를 관리하고 일반적으로 관리하는 것입니다. 작업이 서로 해를 끼치지 않고 메모리의 다른 영역에서 작동하고 장치와 차례로 작동하지 않도록 해야 합니다. 최소한 그게 전부입니다. 또한 한 작업에서 다른 작업으로 메시지를 전송할 수 있는 기능을 제공해야 합니다.

또한 OS는 장기 메모리가 있는 경우 이에 대한 액세스를 제공해야 합니다. 즉, 작업을 위한 모든 기능을 제공해야 합니다. 파일 시스템. 최소입니다.

거의 모든 곳에서 가장 먼저 부팅 코드어셈블러로 작성해야 합니다. 어디에 있어야 하는지, 어떻게 보여야 하는지, 무엇을 해야 하는지, 어떤 크기를 초과하지 않아야 하는지에 대한 많은 규칙이 있습니다.

PC의 경우 BIOS에 의해 호출되고 400바이트를 초과하지 않고 무언가를 수행하고 메인 OS를 시작해야 하는 asma에 부트로더를 작성해야 합니다. future는 이미 C로 작성할 수 있습니다.

ARM의 경우 asma에 대한 인터럽트 테이블(리셋, 다른 오류, IRQ, FIQ 인터럽트 등)을 만들고 제어를 메인 코드로 이전해야 합니다. 많은 개발 환경에서 이러한 코드는 거의 모든 컨트롤러에서 사용할 수 있습니다.

즉, 다음이 필요합니다.

대상 플랫폼의 어셈블러를 알고 있습니다.
프로세서의 아키텍처와 모든 종류의 서비스 명령 및 레지스터를 알고 있어야 원하는 모드에서 작동하도록 구성할 수 있습니다. PC에서 이것은 예를 들어 보호 모드로의 전환 또는 64비트 모드로의 전환입니다. ARM에서는 코어 및 주변 장치 클록의 설정입니다.
OS가 어떻게 시작되는지, 어디에서 어떻게 코드를 밀어야 하는지 정확히 알아야 합니다.
언어 C를 알다 - 큰 코드경험 없이 asma에 글을 쓰는 것은 어렵고 유지하기가 훨씬 더 어려울 것입니다. 따라서 커널을 C로 작성해야 합니다.
OS가 어떻게 작동하는지 알 수 있습니다. 글쎄요, 이 주제에 대해 러시아어로 된 책이 많이 있지만 모두 좋은지는 모르겠습니다.
많은 인내와 인내를 가지십시오. 실수가 있을 것이고 그것들을 찾아 수정해야 할 것입니다. 그리고 책도 많이 읽어야 합니다.
많은 시간을 보내십시오.

더 나아가. 당신이 무언가를 썼다고 가정해 봅시다. 이것을 테스트해야합니다. 실험을 수행할 물리적 장치(디버그 보드, 두 번째 컴퓨터) 또는 에뮬레이터가 필요합니다. 두 번째는 일반적으로 사용하기 쉽고 빠릅니다. PC의 경우(예: VMWare).

잘 검색하면 인터넷에도 이 주제에 대한 기사가 충분합니다. 또한 소스 코드가 있는 기성 OS의 예도 많이 있습니다.

강한 열망이 있더라도 NT 시스템(Windows)의 이전 커널 소스를 별도로(마이크로소프트웨어에 의해 게시됨, 주석 및 다양한 종류의 참조 자료와 함께 게시됨) 및 동일한 소스와 함께 볼 수도 있습니다. 오래된 운영 체제(유출).

나는 즉시 "젠장, 또 다른 Popov"라는 생각으로 기사를 닫지 마십시오. 그는 우분투를 핥았을 뿐이고 나는 커널과 애플리케이션을 포함하여 처음부터 모든 것을 가지고 있습니다. 그래서, 컷 아래에 계속.

OS 그룹: 여기.
먼저 스크린샷을 하나 드리겠습니다.

그 중 더 이상은 없으며 이제 내가 그것을 쓰는 이유에 대해 더 자세히 설명합니다.

따뜻한 4월의 목요일 저녁이었습니다. 어린 시절부터 OS를 작성하는 꿈을 꾸었고 갑자기 "이제 장점과 장점을 알게 되었는데 왜 내 꿈을 실현하지 않겠습니까?"라고 생각했습니다. 이 주제에 대한 사이트를 검색하여 Habr에서 "OS 작성을 시작하고 중지하지 않는 방법"이라는 기사를 찾았습니다. 아래 OSDev Wiki 링크의 작성자에게 감사드립니다. 그곳에 가서 일을 시작했습니다. 최소 OS에 대한 모든 데이터가 한 기사에 있었습니다. 나는 cross-gcc와 binutils를 만들기 시작했고 거기에서 모든 것을 다시 작성했습니다. "Hello, kernel World!" 나는 의자에서 바로 뛰어올랐고 깨달았습니다. 나는 포기하지 않을 것입니다. 나는 "콘솔"이라고 썼지만(따옴표 안에, 나는 키보드에 접근할 수 없었다), 그러나 나는 윈도우 시스템을 쓰기로 결정했다. 결과적으로 작동했지만 키보드에 액세스 할 수 없었습니다. 그리고 나서 X Window System을 기반으로 이름을 짓기로 결정했습니다. Google에서 검색한 Y 윈도우 시스템 - 그렇습니다. 그 결과 그는 OS365 프리알파 0.1에 포함된 Z 윈도우 시스템 0.1을 불렀다. 그리고 네, 저 외에는 아무도 그것을 보지 못했습니다. 그런 다음 키보드 지원을 구현하는 방법을 알아냈습니다. 아무 것도 없었을 때, 심지어 윈도우 시스템도 없었을 때의 첫 번째 버전의 스크린샷:

보시다시피 텍스트 커서도 움직이지 않았습니다. 그런 다음 나는 몇 가지를 썼습니다. 간단한 응용 프로그램 Z를 기반으로 합니다. 그리고 여기에 릴리스 1.0.0 알파가 있습니다. 시스템 메뉴까지 많은 것들이 있었습니다. 하지만 파일 관리자그리고 계산기가 작동하지 않았습니다.

예쁨만 챙기는 친구에게 직접 겁을 먹었습니다(미트로판, 죄송합니다). 그는 "VBE 모드 1024 * 768 * 32를 씻어 내고 씻어 내고 씻어 냈습니다! 글쎄, 그들은 취했다! 글쎄, 나는 이미 그의 말을 듣는 데 지쳤고 여전히 그를 씻어냈다. 아래에서 구현에 대해 자세히 알아보세요.

내 부트로더, 즉 GRUB "ohm으로 모든 작업을 수행했습니다. 이를 사용하면 Multiboot 헤더에 몇 가지 매직 라인을 추가하여 복잡하지 않고 그래픽 모드를 설정할 수 있습니다.

정렬, 1 설정<<0 .set MEMINFO, 1<<1 .set GRAPH, 1<<2 .set FLAGS, ALIGN | MEMINFO | GRAPH .set MAGIC, 0x1BADB002 .set CHECKSUM, -(MAGIC + FLAGS) .align 4 .long MAGIC .long FLAGS .long CHECKSUM .long 0, 0, 0, 0, 0 .long 0 # 0 = set graphics mode .long 1024, 768, 32 # Width, height, depth
그런 다음 Multiboot 정보 구조에서 프레임 버퍼 주소와 화면 해상도를 가져와서 거기에 픽셀을 씁니다. VESA는 모든 것을 매우 혼란스럽게 했습니다. RGB 색상은 역순으로 입력해야 합니다(RG B가 아니라 B G R). 며칠 동안 이해하지 못했습니다. 픽셀이 표시되지 않는 이유는 무엇입니까!? 결국 16가지 색상 상수의 값을 0...15에서 RGB 값으로 변경하는 것을 잊었다는 것을 깨달았습니다. 결과적으로 나는 그것을 출시하면서 동시에 그라디언트 배경을 씻어 냈습니다. 그런 다음 콘솔, 2개의 응용 프로그램을 만들고 1.2를 출시했습니다. 예, 거의 잊어버렸습니다. 다음에서 OS를 다운로드할 수 있습니다.

원본: "자신만의 장난감 UNIX 클론 OS 롤"
저자: 제임스 몰로이
발행일: 2008년
번역: N. Romodanov
양도일: 2012년 1월

이 튜토리얼 세트는 간단한 UNIX 계열 프로그래밍 방법을 자세히 보여주기 위해 고안되었습니다. 운영 체제 x86 아키텍처용. 이 매뉴얼에서 C는 프로그래밍 언어로 선택되며 적절한 경우 어셈블리 언어로 보완됩니다. 튜토리얼의 목적은 우리가 구축하고 있는 OS의 운영 체제를 구조적으로 모놀리식으로 만드는 데 사용되는 솔루션의 설계 및 구현에 대해 알려주는 것입니다(드라이버는 사용자 모드가 아닌 커널 모듈 모드에서 로드됩니다. 이러한 솔루션이 더 간단하기 때문에.

이 가이드 세트는 본질적으로 매우 실용적입니다. 각 섹션은 이론적 정보를 제공하지만 대부분의 가이드는 고려된 추상적인 아이디어와 메커니즘의 실제 구현을 다룹니다. 핵심은 교육용으로 구현된다는 점에 유의하는 것이 중요합니다. 나는 사용된 알고리즘이 가장 공간 효율적이거나 최적이 아니라는 것을 알고 있습니다. 그들은 일반적으로 단순하고 이해하기 쉽도록 선택되었습니다. 이것의 목적은 당신에게 올바른 사고 방식을 제공하고 일할 수 있는 기반을 제공하는 것입니다. 이 코어는 확장 가능하며 최고의 알고리즘을 쉽게 연결할 수 있습니다. 이론에 문제가 있는 경우 이론을 이해하는 데 도움이 되는 사이트가 많이 있습니다. OSDev 포럼에서 논의된 대부분의 질문은 구현과 관련되어 있으며("내 가져오기 기능이 작동하지 않습니다! 도와주세요!" / "내 기능이 작동하지 않습니다! 도와주세요!") 많은 이론 질문은 신선함과 같습니다. air.이 소개를 마칩니다.

예비 준비

예제 코드를 컴파일하고 실행하려면 GCC, ld, NASM 및 GNU Make만 있으면 됩니다. NASM은 오픈 소스 x86 어셈블러이며 많은 x86 플랫폼용 OS 개발자가 선택합니다.

그러나 예제를 이해하지 못한다면 그냥 컴파일하고 실행하는 것은 의미가 없습니다. 인코딩되는 내용을 이해해야 하며 이를 위해서는 특히 포인터와 관련하여 C 언어를 잘 알아야 합니다. 또한 EBP 레지스터가 사용되는 용도를 포함하여 어셈블러(이 설명서에서는 Intel 구문을 사용함)에 대해 어느 정도 이해하고 있어야 합니다.

자원

당신이 알고 있다면 많은 자원이 있습니다 그들을 찾는 방법. 특히 다음 링크가 도움이 될 것입니다.

RTFM! 인텔의 설명서는 신의 선물입니다.
Wiki 페이지 및 포럼 사이트 osdev.org.
Osdever.net에는 많은 좋은 튜토리얼과 기사가 있으며, 특히 이 튜토리얼은 이전 코드를 기반으로 하는 Bran의 커널 개발 튜토리얼이 있습니다. 몇 년 동안 그것을 바꾸지 마십시오.
초보자가 아닌 경우 그룹에서 많은 질문에 대한 답변을 얻을 수 있습니다.

Operating System 0 to 1 책은 GitHub에 게시되었으며 2,000개 이상의 별과 100개의 포크가 있습니다. 이름에서 알 수 있듯이 이 책을 읽고 나면 자신만의 운영 체제를 만들 수 있습니다. 아마도 프로그래머의 세계에서 이보다 더 멋진 일은 거의 없을 것입니다.

이 책을 통해 다음을 배우게 됩니다.

하드웨어 기술 문서를 기반으로 운영 체제를 만드는 방법을 배웁니다. 이것이 실제 세계에서 작동하는 방식이며 빠른 답변을 위해 Google을 사용할 수 없습니다.
소프트웨어에서 하드웨어에 이르기까지 컴퓨터 구성 요소가 서로 어떻게 상호 작용하는지 이해합니다.
코드를 직접 작성하는 방법을 배웁니다. 맹목적으로 코드를 복사하는 것은 배우는 것이 아니라 실제로 문제를 해결하는 방법을 배우게 됩니다. 그건 그렇고, 블라인드 카피도 위험합니다.
저수준 개발을 위한 친숙한 도구를 마스터하십시오.
어셈블리 언어에 익숙해지십시오.
어떤 프로그램으로 구성되어 있고 운영 체제에서 프로그램을 실행하는 방법을 알아보십시오. 호기심 많은 사람들을 위해 이 주제에 대한 간략한 개요를 제공했습니다.
GDB 및 QEMU를 사용하여 하드웨어에서 직접 프로그램을 디버그하는 방법을 배우십시오.

C 프로그래밍 언어입니다. 따라하면 빠르게 마스터할 수 있습니다.
Linux에 대한 기본 지식. 웹사이트에서 공부하는 것으로 충분합니다.
물리학의 기본 지식: 원자, 전자, 양성자, 중성자, 전압.

약어 "NT"는 마케팅에서 "New Technologies"를 의미하지만 설계 문서에서는 완전히 다른 것을 의미했습니다. 사실 Windows NT는 1988년에 아직 출시되지 않은 새로운 Intel i860 프로세서용으로 개발되었습니다. 코드명은 "N10"( N T엔).

첫 번째 버전인 Windows NT 3.1은 5년 후인 1993년에 나왔습니다. 이 시점에서 팀에는 이미 250명의 개발자가 있었습니다.

윈도우 투데이

10억 사용자
1억 4천만 라인의 코드(테스트 코드 및 도구 포함)
Windows 코드는 매우 다릅니다. 일부는 20년 전에 작성되었으며 일부는 현재 버전에서만 나타납니다. 예를 들어 Windows Vista의 WSD(Web Services on Devices) 코드는 첫 번째 버전이고 GDI 코드는 개발 마지막 단계에 있으며 거의 변경되지 않으며 DirectX 코드는 이미 잘 개발되었지만 현재 활발하게 변경되고 있습니다. 시각.
8000명의 개발자
36개 현지화 언어
20년의 개발

윈도우 개발

20-30년 전에는 "Waterfall" 프로그래밍 방법론이 하나만 사용되었습니다. 다음과 같은 순서입니다.

사양 → 설계 → 구현 → 테스트 → 납품.

그러나 이 방법론은 소규모 프로젝트에서만 작동합니다. 오늘날 Windows와 같은 제품의 경우 다른 방법론이 필요합니다.

제품 주기 모델
팀 소프트웨어 프로세스
"익스트림 프로그래밍"

이러한 모든 방법론에는 장점과 단점이 있습니다. 팀의 규모와 구성 요소의 개발 단계에 따라 Windows 개발 팀마다 다른 개발 방법을 사용합니다.
Windows의 경우 일반적으로 제품 주기 모델이 사용됩니다.

3~4개월의 기간
기간 내부 - "폭포"

이 정도 규모의 제품을 개발할 때 가장 큰 문제는 개발에 시간이 걸린다는 점이다. 초기 단계에서는 현재 시간에 존재하는 문제와 기존 수단이 해결됩니다. 그러나 변하지 않는 유일한 것은 모든 것이 변한다는 것입니다. 수년간의 개발:

요구 사항이 변경됩니다
기회는 바뀔 것입니다
작업 일정이 변경됩니다
프로젝트가 변경됩니다
사용자가 변경됩니다.

다른 팀이 다른 방식으로 개발한다는 사실에도 불구하고 "보편적인" 규칙이 있습니다.

테스터 대중을 위한 중간 버전(마일스톤, 베타, CTP) 출시
주기가 짧은 내부 어셈블리 릴리스(1일)
디자인의 단순성과 신뢰성
개인 및 팀 코드 교정
단위 테스트
검증 테스트(빌드 검증 테스트)
모든 중간 어셈블리는 고품질이어야 합니다(작성된 내용이 작동해야 함).

필자는 한 달 동안 Windows 7 빌드 6801을 가정용 컴퓨터의 기본 OS로 사용하면서 이 어셈블리에 대해 긍정적인 인상을 받았습니다.

전체 Windows 개발 프로세스는 일일 빌드를 중심으로 구축됩니다.

이것은 제품의 펄스입니다.
개발은 멈추지 않는다
일일 자동화 테스트
초기 단계의 통합
개발자 책임
제품의 겉보기 상태

옛날 옛적에는 소스 코드의 분기가 하나만 있었고 모든 개발자가 직접 변경했습니다. 이제 개발 팀이 너무 커서 작동하지 않습니다. 많은 분기가 지원되며 그 중 주요 분기인 WinMain이 있습니다. 각 랩에는 변경 사항이 통합되는 자체 로컬 개발 분기가 있습니다. 확인된 변경 사항은 시간이 지남에 따라 WinMain에 통합됩니다.

일일 개발 주기:

15:00 - 통합 승인된 소스 코드 제어 시스템 변경
6개 버전 빌드(무료/선택 - x86, x64, IA64)
18:00 - 테스트용 새 버전 사용 가능
테스트를 위해 수천 개의 워크스테이션과 서버에 새 버전을 설치합니다.
자동화된 스트레스 테스트
05:00 - 테스트 보고서 분석, 실패 진단
09:00 - 요약 보고서가 자동으로 팀에 전송됩니다.
09:30 - 목표 설정을 위한 팀장 요약 회의

가장 고위 관리자를 포함한 모든 프로젝트 참가자는 직장(및 일반적으로 집) 컴퓨터에서 중간 버전을 사용합니다.

Windows 란 무엇입니까?

C, C++, C#, 어셈블러(x86, x64, IA64)
어셈블러는 필수적인 상황에서 다소 제한된 범위에서 사용됩니다.
Visual Studio, 소스 인사이트, 빌드, nmake
소스 저장소 - 소스 제어 시스템
WinDbg, KD, NTSD - 디버거

빌드와 같은 많은 내부 도구는 microsoft.com/whdc/devtools에서 다운로드할 수 있습니다.

Windows 7 커널 변경 사항

Windows 7 커널은 다음과 같이 변경되었습니다.

리팩토링
Windows에서 그래픽 하위 시스템을 제거할 수 없는 이유는 무엇입니까?
기술적인 관점에서 이 질문에 대한 대답은 Windows의 그래픽 하위 시스템이 독립적이지 않고 Win32 하위 시스템의 일부라는 것입니다.
Windows 7은 종속성을 없애기 위해 많은 하위 수준 구성 요소를 리팩토링했습니다. 이것은 사용자에게 눈에 띄지 않을 것입니다. 예를 들어 kernel32.dll이 kernel32.dll과 kernelbase.dll로 분할되는 것과 같이 새 Dll만 나타납니다.
이 분할을 통해 MinWin이라는 최소 커널(디스크에 20MB)을 할당할 수 있었습니다.
x86 및 x64에 대한 EFI 지원(Vista SP1에서와 같이)
많은 제조업체가 EFI를 위해 BIOS를 제거하려고 합니다.
VHD(가상 하드 디스크)에서 부팅
장치의 병렬 초기화 및 서비스 시작
Windows가 부팅될 때 장치 트리를 구축하는 데 꽤 오랜 시간이 걸립니다. PNP 관리자는 버스 드라이버(PCI, USB, FireWire 등)에 어떤 장치가 있는지 폴링해야 합니다. 그리고 대부분의 경우 CPU는 장치가 응답하기를 기다리고 있습니다(또는 응답하지 않음). 실제로 버스의 장치를 확인하려면 장치를 조사해야 합니다. 그렇다면 응답하고 그렇지 않은 경우 기다려야하며 프로세서는 유휴 상태입니다. 이러한 작업을 병렬로 실행하면 부팅 시간이 단축됩니다.
스케줄러에서 디스패처 잠금 제거 및 메모리 관리자에서 PFN 잠금 제거
지난 몇 년 동안 프로세서 클럭 속도는 증가하지 않았으며 개발은 단일 코어 수준과 시스템 수준(멀티코어) 모두에서 병렬 실행 명령의 수를 늘리는 방향으로 진행되고 있습니다. 이와 관련하여 스케일링을 개선하기 위해 많은 작업이 수행되었습니다.
커널에 있던 가장 인기 있는 두 가지 잠금인 Dispatcher 잠금과 PFN 잠금이 제거되었습니다.
스레드 상태가 변경될 때 스케줄러에서 디스패처 잠금을 사용했습니다. 이 잠금이 제거되었고 스레드의 "대기" 상태가 여러 개로 분할되었습니다.
- 대기 중: 진행 중
- 보류 중: 완료됨
- 보류 중: 취소됨
물리적 메모리 페이지의 속성을 변경할 때 PFN 잠금이 사용되었습니다. 다중 프로세서 시스템에서 각 프로세서는 이 잠금에 대한 액세스를 요청하여 많은 시간이 소요되었습니다.
256개의 논리 프로세서 지원
이전 Windows에서는 기계어가 선호도 마스크로 사용되었습니다. 이것은 무료 프로세서를 찾기가 매우 쉽기 때문에 수행되었습니다. 각 비트는 프로세서를 나타냅니다. 따라서 32비트 시스템에서는 32개의 논리 프로세서가 지원되고 64비트 시스템에서는 64개의 논리 프로세서가 지원되었습니다.
Windows 7에서는 선호도 마스크 세그먼트 모델로 전환한 결과 256개의 논리 프로세서에 대한 지원이 가능해졌습니다. 프로세서는 그룹/세그먼트로 그룹화되기 시작했습니다. 각 그룹은 최대 64개의 프로세서를 포함할 수 있습니다. 그 결과 이전 버전과의 호환성이 생겨 이전 프로그램은 한 그룹의 프로세서만 "볼" 수 있으며 새 인터페이스를 사용하는 새 프로그램은 시스템의 모든 프로세서와 함께 작동합니다.
향상된 에너지 절약: 프로세서 소켓 비활성화 오늘날 랩톱 소유자뿐만 아니라 데이터 센터 소유자도 심각한 에너지 절약 문제에 직면해 있습니다. 미국에서는 전기의 2%가 컴퓨터 데이터 센터에서 소비됩니다. 그들 중 많은 사람들이 낮은 사용자 활동(주말) 동안 서버의 일부를 끕니다.
여러 코어에서 하나의 코어보다 전체 프로세서 소켓을 비활성화하는 것이 훨씬 더 수익성이 높은 것으로 나타났습니다. 이 경우 전체 소켓 지원 인프라(메모리 컨트롤러)를 비활성화할 수도 있습니다.

Windows 유지 관리 업데이트

이전에는 업데이트가 종종 누적(누적)되었습니다. 즉, 초기 구성 요소 업데이트에 잘못된 코드가 포함된 경우 이후 버전에는 이 코드가 포함됩니다. 그러나 모든 사용자에게 모든 업데이트가 필요한 것은 아니며 구성이 다릅니다.

이제 Windows의 릴리스(RTM) 이후에는 두 가지 버전의 소스 코드가 있습니다.

RTM GDR(일반 배포 릴리스)
모든 사람을 위한 몇 가지 변경 사항이 포함되어 있습니다. 대부분 보안 수정.
RTM LDR(한정 배포 릴리스)
업데이트를 설치하는 동안 Windows Update 클라이언트는 필요한 분기를 선택하고 해당 분기에서 코드를 설치합니다.

보안 업데이트 만들기

보안 업데이트 생성 작업은 취약점 발견으로 시작됩니다. 내부 보안 팀, 보안 파트너, 개발자 등 다양한 방법으로 탐지할 수 있습니다. 취약점이 발견되면 2개의 병렬 프로세스가 시작됩니다.

모든 플랫폼에 대한 수정 사항 개발
"옵션"을 검색하십시오
모든 플랫폼에서 유사한 취약점 변종에 대한 대규모 검색. 동일하지는 않지만 유사한 코드를 검색합니다.

수정 사항을 개발한 후 코드 검사가 시작됩니다. 완료되면 수정 사항이 빌드에 통합되고 테스트를 위해 빌드가 제출됩니다.

수동 및 자동 구성 요소 테스트
파일 형식 왜곡, 네트워크 구성 요소 등의 자동 테스트 (백만 개 이상의 옵션)
이전 버전과의 호환성 테스트를 포함한 전체 시스템 테스트

모든 품질 기준을 충족하는 수정 사항만 Windows 업데이트 및 다운로드 센터에서 릴리스할 수 있습니다.

다음 >