최근 수정 시각 : 2024-12-03 12:24:43

Windows 9x

윈도우 9x에서 넘어옴
파일:Windows 로고 화이트.svg 버전 일람
{{{#!wiki style="margin:0 -10px -5px; min-height: 26px"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin:-6px -1px -11px" 		파일:MS-DOS 아이콘.svg
DOS 커널 		클라이언트 워크스테이션 서버 {{{#!wiki style="margin:0 -10px -5px; min-height: 26px"
{{{#!folding [ 임베디드/모바일 ]
{{{#!wiki style="margin:-6px -1px -11px" 		SKU
임베디드 에디션 		파일:Windows CE 아이콘_화이트.png CE 커널
1996 CE 1.0
1997 CE 2.x
Poket PC 2000/2002 (CE 3.0)
2002 Mobile 2003/SE (CE 4.x)
2004 Mobile 5.0/SE/6.x (CE 5.x)
2006 CE 6.0
2011 Embedded Compact 7
Embedded Compact 2013 (CE 8.0)
1999 NT 4.0 Embedded
2000 Powered
2002 XP Embedded( FLP 2006)
2005 Embedded for POS
2009 Embedded Standard/POSReady
2010/2011 Embedded Standard 7/POSReady 7( Thin PC)
2012/2013 Windows Embedded 8/Standard 8(Industry)
2013 Embedded 8.1 Industry 		파일:silverlight-f9eea009c90bbdf966eb62abee29092a.png Silverlight 프레임워크
2010 Phone 7
파일:Windows 아이콘 2012_화이트.svg NT 커널
2012 Phone 8
2014 Phone 8.1
파일:Windows 아이콘 2012_화이트.svg One 코어
<rowcolor=#212529,#e0e0e0> 2015 10 IoT
2021 11 IoT 		2015 10 Mobile }}}}}}}}}
1985 1.x
1987 2.x
1990 3.x
파일:Windows 95.png
9x 기반 		19 95 (4.0)
1996 Nashville (4.1)
19 98( SE 1999) (4.1)
2000 Me (4.9) 		파일:Windows 아이콘 1992_화이트.svg
NT 커널 		1993 NT 3.1
1994 NT 3.5
1995 NT 3.51
1996 Cairo (NT 4.0)
1996 NT 4.0
파일:Windows 아이콘 2001_화이트.svg
NT 커널 		2000 Neptune (NT 5.5) 1999 2000 ( NT 5.0)
2001 XP (NT 5.1)
2005 (x64) (NT 5.2)
2006 Vista (NT 6.0)
2009 7 (NT 6.1)
2012 8( RT) (NT 6.2)
2013 8.1( RT) (NT 6.3) 		Server 2003( R2 2005) (NT 5.2)
2007 Home Server (NT 6.0)
Server 2008 (NT 6.0)
2009 ( R2) (NT 6.1)
Home Server 2011 (NT 6.1)
Server 2012 (NT 6.2)
2013 ( R2) (NT 6.3)
파일:Windows 아이콘 2012_화이트.svg
One 코어
(NT 10.0) 		2015 10( 버전, X 2021)
2018 ( Polaris OS, Andromeda OS)
2021 11( 버전)
( Factory OS) 		Server 2016( Hyper-V)
2017 ( 반기 채널)
2018 Server 2019( Hyper-V)
2021 Server 2022
2023 ( 연간 채널)
Server 2025
파일:Windows_Insider_logo.webp
개발 중
shhh... 		2025? vNext 2028? Server vNext
파일:Windows 365 아이콘.svg Windows 365 파일:Windows Insider Program.png Windows Insider Program
}}}}}}}}} ||

1. 개요2. 내부 구조 및 부팅 과정3. 보안 취약점 덩어리4. Windows 9x 시절 DOS의 역할5. Windows NT과의 관계6. 흥망7. 실사용
7.1. 시대적 한계
8. 기타

1. 개요

파일:external/www.subtafuge.com/windows-95-bootscreen.gif
파일:windows_98_boot_screen_by_pkmnct-d3hkkxk.jpg
파일:external/winsupersite.com/winme_b3_splash.gif

MS-DOS 기반의 컴퓨터 운영체제인 Windows 95, Windows 98( SE), Windows Me 세 가지를 아울러 가리키는 말이다. 버전상으로는 Windows 95(4.0), Windows 98(4.1), Windows Me(4.9)로 셋 다 Windows 4에 속하는지라 Windows 9x라는 표현 대신 Windows 4.x라는 표현으로 불리기도 한다.

마이크로소프트에서는 공식적으로 Windows 98 SE를 '마지막 MS-DOS 기반 운영 체제'로, Windows Me를 '마지막 Windows 95 코드 기반 운영 체제'로 설명하고 있다. Windows Me에 포함되어 있는 DOS는 우리가 알고 있는 DOS와는 조금 다르다.[1]

Windows Me 이후로는 가정용 OS까지 Windows XP부터 Windows NT 기반으로 이관했다. Windows Me보다 7개월 먼저 발매된 Windows 2000도 Windows NT 기반이지만 기업용 및 전문가용 타깃이라 가정용이라고 하기에는 포지션이 다소 어정쩡했다. 물론 기업용으로는 Windows XP 대비 비교적 빠르게 정착된 OS 버전이었고 Windows Me의 답 없는 안정성 때문에 Windows 2000 Professional을 가정용으로 사용하는 사람들이 있었다. 대기업 컴퓨터 중에도 주로 관공서나 기업 납품용으로 Windows 2000 Professional이 OEM으로 탑재된 모델이 있었다. 그래서 바로 뒤에 나온 Windows XP가 사실상 가정용으로 가장 처음 보급된 Windows NT 기반 운영 체제가 된다.

2. 내부 구조 및 부팅 과정

부팅 과정을 조금 더 자세히 보면 아래와 같다.
  1. 우선 일반적인 MS-DOS의 부팅 과정을 밟기 시작한다.
  2. DOS 부팅 중 MSDOS.SYS에 의해 Logo.sys를 불러들이면서 부팅 로고가 뜬다. 이는 MSDOS.SYS에 해당 파일을 불러들이도록 설정되어있기 때문이다. MS-DOS 부팅 과정을 지나면서 같이 불러들여진 것으로 MSDOS.SYS 파일 내용중 Logo=1을 Logo=0으로 수정하면 로고를 끌 수 있다.[2]
  3. IO.SYS가 레지스트리를 불러들인다. 만약 없다면 확장자 da0의 백업 파일을 불러들여 내부적으로 Ctrl CV를 먼저 한다.
  4. 리얼모드를 설정한 후 드라이버를 불러들인다.
  5. 더블스페이스가 설정되어 있다면 더블스페이스 설정을 불러들인다. 설정이 되어 있지 않으면 그냥 생략한다.
  6. Win.com이 실행되고 가상 장치 드라이버를 점검하고 불러들이는 등의 과정이 끝나면 보호 모드로 전환된다.
  7. 동적 가상 장치 드라이버를 모두 불러들이면 본격적으로 GUI 환경을 구축하기 시작한다.
  8. 로그온이 있다면 로그온 과정을 거치고 시작 프로그램 및 RunOnce 레지스트리의 시작 프로그램을 모두 불러들임으로써 끝나게 된다. RunOnce에 있는 시작 프로그램은 한 번 불러들이면 다음 부팅에서는 실행되지 않는다.

파일:windows 9x os workmap.png
Windows 98까지는 시스템 종료에서 다시 DOS로 빠져 나갈 수 있었다. 이후 Windows Me는 일정 부분 DOS의 영향력에서 벗어나고자 시도했기 때문에 자연히 이 옵션이 빠지게 됐다. 실제로 Windows Me는 DOS 기반이 아니라는 MS의 답변이 나온 적이 있다. 다만 DOS 모드를 사용할 수 있도록 한 비공식 패치가 있기는 하다.

3. 보안 취약점 덩어리

가정용이라는 특성상 사용자 분리라는 개념이 없다시피 했는데, 바탕 화면을 공유했다. 사용자 초기화 파일로 분리시킬 수는 있었지만 사용자 초기화 파일 사용 전까지는 저장한 아이콘과 파일이 모두 공유된다. 게다가 NT 계열과는 다르게 암호 입력 창에서 취소 버튼을 클릭해도 로그온이 된다. 다만 사용자 초기화 파일을 사용하면 남의 문서가 바로 대놓고 보이지는 않는다. 네트워크 파일 공유 같은 일부 기능만 사용할 수 없을 뿐이다. Microsoft Network 로그온 대신 Windows 로그온을 사용할 수도 있다. 거기에 관리자라는 개념이 전무하다시피 했는데, 알기 쉽게 말하자면 사용자가 곧 관리자이다. 이들은 Windows Vista( 2008)에서 사용자 계정 컨트롤(UAC)과 관련하여 헬게이트를 열게 된 원흉이 되기도 했다. Windows NT 3.1부터 Windows XP(2003/R2)까지는 당연히 사용자 분리라는 개념이 있었다는 것과는 별개로 Vista( 2008)부터 도입된 사용자 계정 컨트롤 기능의 존재 자체가 없었던 점 또한 한 몫했을 것이다.

9x 구조 자체가 Windows NT와는 많이 달랐다. 예시로 DLL과 같이 동적으로 로드해서 사용하는 라이브러리의 경우 NT 커널처럼 각각의 프로세스 주소 공간에 올라가는 게 아니라 공유 메모리에 올라가게 된다. 만일 해당 DLL에 의해 올라간 공간을 조금이라도 잘못 조작하면 시스템이 심하게 맛이 간다. 또한 일반적으로 커널 모드에서만 사용할 수 있던 Port I/O 명령어 같은 Privileged Instruction을 사용자 모드에서 실행되는 응용 프로그램에서도 제대로 사용할 수 있었다. 이러한 점을 악용했던 대표적인 바이러스가 바로 CIH 바이러스이다. 9x 자체의 결함에다가 잘못된 서드파티 디바이스 드라이버에 의한 시너지 효과까지 받아서 일어났다고 볼 수 있다. 빌 게이츠의 굴욕 역시 디바이스 드라이버가 문제를 일으켜서 발생한 사건이다. 결국 Windows 2000에서 WHQL을 도입하면서 서명되지 않은 드라이버는 경고를 띄우게 바뀌었으며 Windows 8( 2012) 이후부터는 아예 설치하는 것 자체를 막아버린다. 억지로라도 설치를 하기 위해서는 고급 부팅 옵션에서 '드라이버 서명 적용 사용 안 함'을 선택해서 부팅하거나, 아예 명령어 창을 띄워서 서명되지 않은 드라이버를 설치해도 막히지 않게 조작을 해야 하는 등의 삽질을 좀 해야 하는 데 어떻게 하면 되는지는 디바이스 드라이버 2번 문단을 참조하라.

2018년도 초반에는 CPU 게이트로 인해 CPU가 읽어들이는 데이터가 제3자에 의해 노출당하게 생겼다는 사실이 드러났다. 마이크로소프트사가 내놓은 그 불완전하다는 보안 패치 지원 대상에서도 제외되어 있다. 지원 기간이 종료됐고 9x를 특수한 이유가 아닌 이상 사용하지 않으니 굳이 보안 패치를 내놔야 할 이유가 없었을 것이고 설령 지원 기간이 끝나지 않아서 보안 패치를 내놨다 하더라도 크래커들 입장에서는 CPU에 내재된 취약점들을 사실상 공략할 필요가 없는 이유가 있는데 9x가 구조적으로 떠안을 수밖에 없는 버그들을 악용할 선택지들이 얼마든지 차고 넘쳐나기 때문에 CPU의 보안 취약점을 바이오스를 비롯한 펌웨어를 건드려야만 하는 마이크로코드 업데이트와 더불어 OS 차원에서 틀어막는 보안 패치는 의미가 없을 것이다. 즉, 아직까지는 멜트다운이나 스펙터 등에 취약하지 않다고 여겨지고 있는 P5 계열 까지의 구형 CPU가 장착되어 있다 하더라도 다른 보안 취약점들 앞에서는 어차피 무력해질 수밖에 없기 때문이다.

4. Windows 9x 시절 DOS의 역할

도스가 포함된 Windows 버전과 그 기반 DOS 버전을 요약한 표이다.
DOS 버전 Windows 버전
7.0 Windows 95 RTM, SP1
7.1 Windows 95 OSR 2.x
Windows 98, 98 SE
8.0 Windows Me

Windows 95로 넘어가던 시기 컴퓨터 서적을 보면 구 DOS용 응용 프로그램(예를 들면 게임)과의 공존을 위한 온갖 삽질 테크닉을 소개하는 경우가 많다. 왜냐하면 버전 업이 이루어지면서 MS-DOS 6.x까지 구동되던 프로그램들이 MS-DOS 7.x~8.x에서 돌아가지 않는 일이 허다했기 때문이다. MS-DOS 7.x~8.x의 설정과 Windows의 설정 삽질을 해서 겨우 구동시킬 수 있는 소프트웨어도 있긴 했으나 MS-DOS 6.x가 아니면 죽어도 실행이 안 되는 경우가 많아서 과도기 사용자들의 불만이 하늘을 찔렀다. 다행히 Windows 9x의 경우 구 버전의 DOS로 멀티 부팅을 할 수 있는 기능을 제공했으나 문제는 이 방식을 사용하려면 이용자들이 Windows 95 발매 이전에 구 버전의 DOS 설치 디스켓을 사서 보관하고 있어야 했다. 물론 이 시기에 도스나 윈도우를 정품으로 구입해서 쓴 사람은 적었기 때문에 큰 문제는 아니었다. 윈도우 정품 인증이 도입되기 휠씬 이전이었고, 정품 사용에 대한 인식이 부족했던 시기라 너도나도 불법복제로 썼기 때문이다. 상기한 특징으로 인해 해당 윈도우의 도스 파일만 추출해 별도의 도스로 만든 것도 있었다. 해당 버전에는 자체적인 GUI 기능과 부팅 로고가 지원됐다. 9x의 지원이 끝난 현재는 Windows 98 SE의 기저에 깔린 MS-DOS 7.1이면 MSDOS.SYS의 BootGUI=0 혹은 Command Prompt Only에서 99% 이상의 호환률로 도스 게임이 정상 동작하므로 게임을 위해서라면 굳이 6.22를 멀티부팅해야 할 이유는 없고, 만약 필요하다면 따로 6.22 부팅 디스크를 사용하면 그만이다.

Microsoft Windows는 3.1까지는 MS-DOS 상에서 실행하는 일종의 응용 프로그램이었다. 하지만 Windows 3.1이 보급될 즈음에 Windows가 사실상의 운영 체제에 준하는 존재로 취급되기 시작했다. Windows 9x( 95, 98/ 98 SE, Me)의 경우 호환성을 위해 도스를 내장하고 있으며 Windows에서 도스용 응용 프로그램을 실행하기 위해 내장된 도스 가상 머신과 일시적으로 Windows를 중단하고 리얼도스 상에서 실행하는 리얼도스 모드도 지원했지만 본질적으로 MS-DOS의 존재는 어디까지나 Windows의 하부 구조였고 호환성상 문제가 있었던 경우를 제외하면 사용자들이 직접적으로 도스를 이용하는 것은 드물어졌다.

5. Windows NT과의 관계

MS-DOS를 완전히 빼고 자체 커널을 사용하는 Windows NT 기반 운영체제는 9x와 구조가 매우 다르다.

1993년에 Windows 95 개발이 시작된 당시에는 Windows NT 3.1도 함께 개발되고 있었다. 기존의 DOS 기반 Windows(1.x, 2.x, 3.x)와 비교할 때 성능이랑 안정성 면에서는 Windows NT가 가장 우수했다. 하지만 구조가 완전히 달라져버린 관계로 DOS와 DOS 기반 Windows(1.x, 2.x, 3.x)용 프로그램이 제대로 동작하지 않는 문제가 있었다. 물론 이들 프로그램을 위해 VDM(Virtual DOS Machine)이나 WoW(Windows on Windows)[3]가 내장되어 있었지만 실제로 돌려오면 완벽하지 않았다.

DOS 프로그램과 16비트 윈도우 프로그램이 Windows NT에서 제대로 동작하지 못하게된 원인에는 여러 원인이 있지만 16비트와 32비트의 차이와 하드웨어 직접 제어 제약이 가장 켰다. 16비트와 32비트의 코드가 서로 다르기에 16비트 코드를 32비트 코드로 변환시켜 실행시키는 에뮬레이팅을 거쳐야 하기에 성능의 일정 부분이 상실되었다. 그리고 Windows NT에서 프로그램이 하드웨어를 직접적으로 제어할 수 없는데 커널 모드과 사용자 모드과의 경계가 모호했던 DOS, DOS 기반 윈도우와 다르게 경계가 명확해지면서 오직 커널 모드에서만 하드웨어를 직접 제어할 수 있다. 그래서 일반 프로그램은 사용자 모드에서 실행되므로 직접 하드웨어를 제어할 수 없고 시스템 콜과 같은 방법으로 커널 모드 드라이버를 통해 간접적으로만 제어할 수 있다.

그리고 Windows NT는 본래 기업과 서버용으로 개발되었으며 가정용을 목표로 개발된게 아니었다. 따라서 마이크로소프트는 개인 사용자 시장에서 DOS 및 16비트 윈도우용 프로그램을 포기할 수 없었고 NT 커널 대신 DOS 기반으로 개발하기로 하면서 '호환성이 보장되는 범위 안에서 안정성을 확보'하는 식으로 방향을 정하게 되었다.

이렇게 Windows 95는 DOS 기반으로 개발되었으며 이후의 98, Me도 DOS 기반으로 개발되었다. 그래도 32비트 프로그램이 Windows NT에서도 호환될 수 있도록 했는데 다음과 같다.
  • Windows NT의 시스템 콜 라이브러리 파일인 ntdll.dll는 9x에서도 있다.
  • Windows NT는 유니코드를 사용하고 9x는 ANSI를 사용하여 문자열을 처리한다. Windows API 중에서 문자열을 취급하는 함수의 경우 함수 이름의 맨 뒤에 A(ANSI), W(유니코드)를 붙여 ANSI와 유니코드 버전이 존재하고 있다. 예를 들어 LoadLibrary의 경우 ANSI 버전은 LoadLibraryA이고 유니코드 버전은 LoadLibraryW이다. 각각 함수에서 취급하는 문자열 형식이 달라진다. Windows NT에서 ANSI 함수를 호출할 경우 내부적으로 유니코드로 변환한 후 유니코드 함수를 호출하며 반대로 9x의 경우 유니코드 함수를 호출할 시 내부적으로 ANSI로 변환시킨 후 ANSI 함수를 호출한다. 즉 Windows NT에서는 유니코드 함수, 9x에서는 ANSI 함수가 본래의 기능을 수행한다.

따라서 32비트 프로그램은 9x와 NT 사이에서 호환성이 있는게 원칙이다. 그런데 왜 원칙이냐고 하면 API는 똑같은데 안되는 경우가 꽤 있기 때문이다.

6. 흥망

Windows 9x계의 첫 시작을 끊은 Windows 95의 경우에는 IT계의 혁명이라는 수식어와 함께 좋은 스타트를 끊었다. 이 시기쯤 가정용 PC 보급률도 오르기 시작했다. 이후 Windows 98 SE 또한 한참 이후에 출시된 Windows XP와 한때(2002~2006년) 시장을 양분했을 정도의 인기를 구가했다. 98 자체가 특출나서라기보다는 서로의 기반이 달라 발생하는 호환성 문제 등 해결해야 할 문제도 있었고, XP의 경우 테마 기능도 있는 등 당시 PC 사양의 업그레이드 주기 등도 고려해야 한다. 여기에 출시 초기의 경우 안정성 검증도 필요했다. 정착에 필요한 모든 검증 및 과정이 충분히 끝난 이후에는 당연히 XP가 빠르게 자리를 채웠다. 그런데 마지막은 Windows Me로 장식하면서 용두사Me로 끝났다.

다만 MS가 Windows 9x의 끝을 별로 좋지 않게 마무리한 것은 이 시기 쯤 넵튠을 넘어 Windows XP 베타 버전을 배포하고 있을 시기였으므로 Windows Me는 9x 커널의 최후 제품이라는 것 정도에만 의미를 두었기 때문이다.

7. 실사용

산업 현장 등에서는 비용, 호환성 문제 때문에 여전히 많은 곳에서 애용되고 있다.

Windows NT 계열에서는 하드웨어 직접 제어가 차단되어 있고 드라이버를 통해서만 제어할 수 있다. 시스템 폴더 문서에서도 이미 언급하고 있지만 하드웨어를 직접적으로 제어할 수가 있게끔 해놓으면 무조건 커널을 뚫고 제어하고자 하는 하드웨어에 접근하고자 한다면 보안상의 위험이 뒤따를 수밖에 없기 때문에 3.1을 시작으로 NT 계열의 윈도우부터는 하드웨어에 직접 접근하여 제어하는 일을 차단했을 것으로 보인다. 따라서 ISA 버스 기반의 I/O 제어를 하고 있는 곳이라면 NT 계열로 OS 교체에 어려움이 큰 정도가 아니라 사실상 불가능한 처지에 놓여 있다. 따라서 이런 장소에서는 여전히 사용될 것으로 보인다.

일부 아케이드 시스템에서도 Windows 9x 계열 운영 체제를 사용하고 있었다. EZ2AC 시리즈는 영문 Windows 98(1st, 1st SE, 일부 물량은 한글판을 사용), 영문 Windows 98 SE(2nd ~ EC)를 사용하다가 EZ2AC : EVOLVE 1.3c부터 한글 Windows XP Professional(EV 구기판 한정으로 영문판을 사용)로 변경됐다. 네오드럼은 영문 Windows 95를 사용하다가 마지막 버전인 뉴 패러다임에서 한글 Windows 98 SE로 변경했다.

한편 Windows 9x에서 Windows NT용 프로그램을 구동시키기 위해 KernelEX라는 호환성 지원 툴이 개발됐다.

2000년대 이전의 OS다 보니 2010년대 부터의 하드웨어 위에서는 절대로 호환되지 않는다. 또한 현 시점에서는 9x와 호환되는 하드웨어는 단종된지 오래라 구하기도 매우 어렵다. 까놓고 말해 CPU 기준으로 잡으면 인텔 펜티엄4 시리즈가 마지노선이라고 생각하는 것이 편하다. 9x를 돌리기에 적합한 컴퓨터가 없는 상황에서 고전게임 구동을 위해 가상 머신에 올려놓고 쓴다면 반드시 고려해야 할 사항이다.


Windows 98 게이밍 PC를 제작하는 영상이 있는데 이 영상에 따르면 Windows 98 패키지를 포함한 모든 부품을 조립할 때 20년 동안 묵혀있던 미개봉 부품으로 만들었다고 한다.[4]

독일 베를린 법원에서 2010년대에도 여전히 Windows 95를 사용하다가 2019년에 결국 바이러스에 감염되어 업무가 정지, 결국 타자기와 팩스를 창고에서 꺼내 써야 했다. 사실 2017년에 이미 전문가들이 경고했던 문제라고 한다. 결국 이를 무시하고 계속 사용한 법원이 문제이다.[5]

7.1. 시대적 한계

  • CPU 제한: 멀티 코어와 SMT를 포함한 멀티 CPU를 지원하지 않으며, 특히 Windows 95에는 높은 클럭의 CPU를 사용하지 못하게 하는 두 가지 버그가 있다.
    • 첫 번째는 AMD의 K6-2 350MHz 이상의 CPU에서 나타나는 IOS 장치 초기화 문제이며, 이는 amdk6upd.exe라는 패치 파일을 받아 해결할 수 있다.
    • 두 번째는 2.2GHz 이상의 CPU에서 나타나는 NDIS 장치 초기화 문제이며, 전화접속 네트워킹 1.4 업데이트[6]를 설치하면 해결된다고 한다.
  • RAM 제한: Windows 98 SE 기준으로 512MB를 초과하면 윈도우에서의 도스 프롬프트 사용이 불가능하며, 1GB를 넘으면 부팅이 불가능해진다. 물리적으로 RAM 용량을 줄이거나, Burnmem 등의 도스 프로그램을 통해 RAM 용량을 제한하면 된다. [7] R. Loew의 비공식 패치를 이용해 2GB까지 사용이 가능하며 그 이상의 램 장착되어 있어도 2GB로 인식하고 정상 부팅 가능.
    • 설치 중 첫번째 재부팅 할 때 다시 부팅디스크를 이용해 도스 모드로 들어가 edit.com 등 텍스트 편집 프로그램을 이용해 Windows 폴더의 System.ini를 열고 [386Enh] 항목 아래에 MaxPhysPage=20000을 추가하고 현대식 메인보드의 CSM 호환 관련해서 발생하는 VCACHE 에러를 해결하기 위해 Cregfix.com[8] 를 C:\에 미리 복사해두고 Autoexec에 cregfix.com을 추가해준다. 재부팅 후 설치 과정을 진행하고 두번째 재부팅 이후 다시 도스 모드로 들어가 patchmem[9]을 실행해준다. 이제 다시 설치로 돌아가면 정상적으로 진행된다.
  • 인텔 11세대, 라이젠 3000번대부터는 실제 하드웨어는 물론 가상머신에서도 가상화가 켜져있을 때 정상부팅이 되지 않는 문제가 있다.
    patcher9x [10]를 받아 현재 설치된 윈도우 폴더에 적용하거나 및 설치 파일이 들어있는 폴더를 하드 디스크에 미리 복사하여 패치를 미리 적용할 수 있다. 프로그램이 도스에서는 동작하지 않으므로 미리 패치를 적용한 파일을 이용해 설치할 수 있는 방법을 찾아야 한다.
  • UEFI 펌웨어 미지원: 레거시 바이오스만 지원한다. 정확히는 UEFI Class 0 ~ 2.x까지는 문제가 되지 않는다. 클래스 2.xx 버전대라면 레거시 기능을 사용하기 위한 CSM이 포함되어 있는 덕분에 CSM을 켜고 Secure Boot 기능을 꺼버리면 UEFI와 관련한 문제로 설치를 못하거나 이후에 부팅을 못하는 일은 없다. 그런데 UEFI를 개발한 인텔이 2020년부터 개인 PC든 서버용 컴퓨터든 용도를 불문하고 CSM을 흔적도 없이 날려버린 UEFI Class 3를 도입하겠다고 예고했었고, 실제로 UEFI Class 3를 도입하게 되는 롬이 심어진 메인보드가 본체에 장착되는 컴퓨터에서는 설치 단계부터 불가능 해진다. 왜 이런 문제가 발생할 수밖에 없는가 하면 UEFI는 인텔이 독자적으로 개발하여 개방한 규격이고 당연히 제조업체 입장에서는 최고 개발 위치인 인텔의 말을 무조건 듣는 수밖에 없고 게다가 인텔이 x2xx 칩셋부터 Windows 10 미만의 OS 공식 지원을 제외시켜 버린 탓에 더더욱 지원할 이유가 사라졌기 때문이다. GPT 파티션 역시 지원하지 않는다.
  • IDE 인터페이스만 지원: Windows 9x에는 AHCI나 NVMe 드라이버가 포함되어 있지 않다. 바이오스에 따라 MS-DOS 호환 모드로 작동할 수는 있지만 속도가 느리다. 설치 후 R. Loew의 드라이버를 설치하여 AHCI로 작동 가능하다. 약 인텔 10세대까지는 호환되며 이후 출시된 보드는 설치시 입출력 에러 발생. 바이오스의 구형 OS 지원 수준에 따라 호환성 문제가 발생할 수 있다.
  • 137GB 이상 디스크 용량 사용 불가 문제: 이 역시 OS에서 지원하지 않는다. R. Loew의 패치를 통해 137기가 이상 사용 가능하며 이 사람이 만든 별도의 패치를 또 적용하면 1TB 이상도 인식 가능하다. 단, 비공식 패치 특성상 하드웨어 조합에 따라 문제가 발생할 수 있다.
  • 고해상도 그래픽 처리 불가: 사실 Windows 95 때부터 화면 DPI 설정 기능 자체는 있었다.[11] 그러나 이 때의 DPI 설정 기능은 96DPI보다 더 낮은 해상도를 가정하고 만든 것이라서 Windows 8.1( 2012 R2)부터 정식으로 지원하기 시작한 HiDPI 지원과는 거리가 굉장히 멀었다. 당시에는 고해상도 디스플레이가 상용화되지 않았기 때문에 윈도우 9x에서 창을 최소화시키면 3000, 3000 좌표에 창을 배치시켰다.[12] 이는 4K UHD 모니터 두 개만 써도 9x의 최소화된 프로그램이 노출된다는 이야기이다. 물론 예시를 든 것뿐이며, 실제로는 Windows 9x가 돌아가는 하드웨어에서는 UHD 해상도 출력 자체가 불가능하다. HDMI나 DP는 아예 없으며 DVI는 듀얼 링크로 출력해도 2560×1600이 최대이다. DVI조차 없는 구형 그래픽 카드는 1920×1200( D-Sub)이 최대이다. 윈도우 NT와 GUI 스택 구조가 근본적으로 다른 탓에 화면 해상도를 높이면 Windows의 중요 모듈인 GDI, USER 등이 사용하는 힙(heap) 공간을 의미하는 리소스를 조금이나마 깎아먹기 때문에 해상도를 높게 잡기가 부담스러웠다. 게다가 이러한 리소스 공간은 일정한 크기로 고정되어있는 구조이기 때문에 단지 이 공간을 늘릴 목적으로만 램을 추가로 장착하는 것은 아무런 의미가 없다. 특히 시스템 리소스가 40% 내지 50% 미만까지 떨어지면 가뜩이나 불안정한 윈도우가 더욱 불안정해지는 것도 모자라 결국에는 리소스 점유율을 정상 수치로 회복하기 위해서는 재부팅을 하는 수밖에 없어진다. 9x 계열의 윈도우들은 메모리 사용량을 관리하는 데만 신경써도 되는 NT 계열의 윈도우들과 달리 리소스 점유율을 최대한 관리하는 것 또한 메모리 사용량을 관리하는 것 못지않게 중요하게 여길 수밖에 없기도 했다.
  • 각종 디바이스 드라이버 미지원: 이미 연장 지원이 종료된 지 한참 지나버린 OS인 만큼 최신 그래픽 카드 및 온보드 사운드 카드, 네트워크 카드 등을 사용하기 위한 드라이버 지원이 없다. 물론 유저들이 만든 비공식 드라이버가 몇몇 있지만 불안정할 수 있으므로 추천하지 않는다.
    • 메인보드 칩셋: 인텔 칩셋은 i865/875까지 INF를 공식 지원한다. 대략 펜티엄 4나 일부 코어 2 시리즈 컴퓨터까지 이에 해당한다. 비공식 드라이버를 통해 ICH10까지도 드라이버를 설치해볼 수 있다. [13]
    • GPU: 공식적으로 GeForce 6 시리즈와 라데온 X300~X850 시리즈까지 지원한다. 6600GT 등 6000번대 PCIe 모델도 FHD 해상도에서 잘 작동했으며 비공식 드라이버 패치를 통해 GeForce 7까지도 사용해볼 수 있다. 바이오스의 OS 지원 수준에 따라 호환성 문제가 발생할 수 있음. 최신 그래픽카드[14]도 Univbe를 이용하여 1280x1024 해상도까지 이용해볼 수 있으나 텍스트 모드 창이 뜨는 모든 프로그램 (Bat, Pif 파일 포함)이 돌아가지 않는 문제가 있다. 모든 드라이버와 업데이트를 설치하고 마지막에 설치해야 한다.
    • 사운드: AC'97 코덱 또는 사운드 블라스터 Live!, Audigy 2를 비롯한 초기 PCI 사운드 카드까지만 지원한다. 윈도우 3.1용 HD Audio 드라이버를 이용하여 설정이 복잡하고 다소 불안정하지만 보드 내장 사운드를 사용해볼 수 있지만 추천하지 않음.
    • USB: VIA VT6212 칩셋이 장착된 PCI 카드를 이용해 정상 사용 가능. 비공식 ICH 드라이버를 이용해 ICH7 장착된 보드에서 내장 USB 또한 사용 가능하다. 다만 KVM 스위치 등을 이용할 때 핫플러그인 문제가 있어 블루스크린이 발생함. USB 3.0은 사용 불가. 게이밍 USB 키보드 중 동시키 입력을 위해 장치가 여러개로 인식되는 경우가 있는데 이 경우에도 호환성 문제가 발생할 수 있음.
    • 네트워크: 리얼텍의 RTL8111 시리즈 및 RTL8169 시리즈가 장착된 내장 및 PCI, PCIe 랜카드 사용이 가능하다. 상기된 Dial Up Networking 1.4 패치 설치해야 NDIS 문제가 없어 정상 사용 가능.
  • 장시간 사용시 리소스를 비롯한 메모리 누수: 9x 커널 특성이라 근본적인 해결책은 없다. Windows Me에서는 리소스 누수 뿐만 아니라 아예 메모리 누수가 심한 편이다. 주기적인 재부팅이 필요하고 RAM Idle 같은 메모리 관리 유틸리티를 사용하는 것이 좋다.
  • DOS 앱을 실행하다가 뭔가 꼬여서 Windows로 부팅이 안 돼서 앱에 갇히는 현상: autoexec.bat랑 config.sys를 삭제하면 Windows로 부팅이 된다. 다만 이렇게 하면 MS-DOS 모드에서 사용에 문제가 있으니 복구하는 게 좋다.

8. 기타

아주 오래 전에 나온 운영 체제이지만 먼 훗날 Windows 8 다음에 Windows 9가 나오지 않고 Windows 10으로 바로 넘어가게 된 주범이 됐다는 설이 있다. 자세한 건 Windows 10 항목에 있다.

Windows NT 커널은 DOS가 포함되지 않았기에 2001년 가을에 Windows XP가 출시되면서 DOS는 사라졌다. 지금 윈도우에 남아 있는 명령 프롬프트(cmd.exe)는 CLI 인터페이스와 도스와 비슷한 명령 체계를 빼면 근본부터가 다른 물건이다. 여기에서 16비트 프로그램을 돌릴 때에는 x86 CPU의 기능인 가상 8086 모드를 이용한 NTVDM(Virutal DOS Machine)이라는 가상 머신을 통해서 어느 정도 실행할 수는 있다. 64비트 모드에서는 32비트 모드와는 다르게 가상 8086 모드를 사용할 수 없기 때문에 64비트 윈도우에서는 NTVDM이 빠졌다. 이러한 연유로 인해 도스박스 등의 에뮬레이터를 쓸 수밖에 없다. 그리고 PowerShell이 야금야금 명령 처리기의 자리를 갉아먹고 있다.

리테일 버전과 OEM 버전으로 나뉘어 있는데 이게 NT 계열의 윈도우들과는 달리 단순히 라이선스만 다른 것이 아니라 부팅 방식까지도 달랐다. 리테일 버전은 CD에 부팅 기능이 내장되어 있지 않았으며 동봉된 부팅 디스크를 통해 부팅을 해줘야 했다. 먼저 시동 디스크 내의 FDISK 프로그램을 이용하여 파티션을 잡아주고 CD 드라이브를 불러와서 Setup.exe를 실행해야 한다. 반면 OEM 버전은 CD만으로 부팅이 가능했다. 그래서 인터넷에 떠돌아다니는 ISO 파일은 거의 다 OEM 버전이다. 더군다나 Windows 95는 인스톨러에서 CD 드라이브를 인식할 수가 없어 파일을 HDD에 복사해야하는 번거로운 작업이 필요하다.
  1. fdisk로 파티션을 잡은 뒤 설치 CD의 win95 폴더로 이동해서(D: cd win95) format 명령어로 C: 드라이브를 포맷한다(format C:).
  2. 포맷이 끝나면 C: 드라이브로 이동한 다음 md 명령어로 win95 폴더를 만든다(C: md win95).
  3. 폴더가 만들어졌으면 다시 설치 CD의 win95 폴더로 이동한 뒤(D: cd win95) copy 명령어로 폴더 내의 모든 파일을 복사한다(copy *.* C:\\win95).[15]
  4. 복사가 끝나면 다시 C: 드라이브의 win95 폴더로 이동해서(C: cd win95) setup.exe를 실행하면 된다.[16]

Windows 98이나 Windows Me에는 이런 문제는 없지만 같은 방법으로 HDD에서 설치할 수 있기는 하다. 사실 98도 구성 요소 설치나 드라이버 설치를 위해서 설치 CD가 필요하며 CD 없이 설치하려면 설치본을 하드에 복사해놔야 한다. Me에서는 설치 과정에서 설치본도 같이 하드에 복사되기에 하드에 복사를 할 필요가 없어졌다. 폴더명은 각각 win98, win9x이다.

부팅을 통한 1차 설치 화면에서는 GUI 테마와 굴림체가 3.1의 것으로 되어 있는데 파일 복사가 끝나고 '처음으로 실행하기 위해 준비 중'이라는 전용 부팅 화면(ME 제외)이 나타난 다음부터는 9x의 것으로 적용된다.

기본적으로는 종료음(logoff.wav)이 비활성화되어 있다.

SATA AHCI 환경의 경우 XP나 2000은 드라이버 설치가 필요하지만 Windows 95/98에서는 별도의 드라이버 설치 없이도 SATA(AHCI)에서 정상 부팅이 가능하며, 이는 MS-DOS도 마찬가지다. 심지어 USB 플래시 드라이브에 Windows 95/98를 설치하고 GUI로 부팅시킬 수 있다. 단, 파일 시스템은 FAT32이어야 한다(Windows 95는 OSR 2 이상으로 패치해 주지 않으면 FAT16). 이는 9x 계열 윈도우가 하드웨어 제어를 바이오스에 의존하는 방식이기 때문에 가능한 것인데, 이 경우 장치가 32비트 드라이버가 아닌 MS-DOS 호환 모드로 작동하기 때문에 비교적 불안정하며 완전한 성능을 뽑아낼 수 없게 된다.

Windows 95와 Windows 98은 부팅 후 49.7일 경과 시 시스템이 정지하는 문제가 있었다. 이는 윈도우가 부팅 후 32비트 정수 범위에서 밀리초(ms) 단위로 시스템 기동 시간을 세는데, 32비트의 한계인 4,294,967,296 ms가 49일 17시간 2분 47.296초이기 때문에 이 범위를 벗어나면 더 이상 시간을 셀 수 없어 해당 문제가 발생했다. 이후 1999년에 패치가 공개되어 해당 문제는 해결됐다. 이 문제는 상당히 오래 지나서 발견됐는데, 윈도우가 부팅 후 49일이 되기 전에 다른 이유로 정지해 재부팅하는 경우가 많았기 때문이다.[17]

일부 메인보드에선 PCI버스가 설치되지않아 수동으로 설치해야 한다.

[1] 출처 [2] 참고로 일반 MS-DOS에 있는 MSDOS.SYS는 Windows 9x에서 IO.SYS에 통합됐고, Windows 9x의 MSDOS.SYS는 텍스트 파일이다. [3] 16비트 윈도우 프로그램용 호환계층이다. 홋날 64비트에서 기존 32비트 윈도우 프로그램의 실행을 지원하기 위해 존재하는 WoW64(Windows 32-Bit on Windows 64-Bit)와는 엄연히 다르다! [4] 한가지 예외는 있는데, 20년동안 묵혀있는 파워서플라이는 상태가 좋지 않아서 최근의 것을 썼다고 한다. [5] # [6] 영문판만 제공. 1.3까지만 타언어로 제공되었다. [7] 외국 웹사이트 등지에서 1024MB 이상을 지원하는 비공식 패치를 제공하기는 하나 정상적인 동작을 담보하지는 않기 때문에 메모리 관리 프로그램을 설치하는 것이 권장된다. [8] # [9] # [10] # [11] # [12] # [13] http://vogonsdrivers.com/getfile.php?fileid=2114&menustate=0 [14] RTX 4070으로 확인 [15] 설치 CD로 이동하지 않고도 copy [ODD문자열]\win95\*.* c:\win95로 복사해도 되며 *.cab만 있어도 설치가 된다. [16] 미리 C드라이브의 win95폴더로 이동한 다음 설치 CD로 이동하고 복사한 다음 다시 이동하여 실행해도 된다. [17] 패치 아카이브 당시 보도

분류