PCL 딥다이브
— 게임 실행 버튼 뒤의 작은 작업 관리자

1프로젝트 한줄 요약

PCL은 Minecraft Java Edition의 설치와 실행을 돕는 런처입니다. 게임 엔진을 구현하는 프로그램이 아니라, 게임이 실행될 환경을 준비하는 프로그램입니다. 이 저장소의 핵심 학습 주제는 실행 버튼 하나를 여러 개의 추적 가능한 작업으로 바꾸는 방법입니다.

소스의 Plain Craft Launcher 2/Modules/Minecraft/ModLaunch.vb를 보면 이 말이 구체적으로 드러납니다. 공개 진입점 McLaunchStart()를 거쳐 호출되는 비공개 McLaunchStart(Loader)는 Java 확보, 로그인, 누락 파일 보충, 인자 생성, 압축 해제, 사전 처리, 사용자 명령, 프로세스 시작, 창 대기, 마무리를 작업 목록으로 만듭니다.

2왜 주목받는가

2-1. 평범한 실행 버튼에 실전 문제가 모여 있다

2026-10-23 TrendShift Repositories #4 선정과 스타 8,836개는 관심의 신호입니다. 다만 이 숫자만으로 특정 기능이나 게시물이 상승을 일으켰다고 증명할 수는 없습니다. 10월 20일의 2.99.0.0 릴리스와 분석일이 가깝다는 사실도 인과관계와 구분해야 합니다.

코드에서 확인되는 주목할 점은 분명합니다. 다운로드 소스가 중간에 실패하고, Java 버전이 맞지 않고, 게임 파일 일부가 지워지고, 모드가 충돌하는 상황을 각각 처리합니다. PCL은 새로운 문법보다 오래 살아남는 데스크톱 제품의 예외 처리와 작업 조율을 배우기에 좋은 사례입니다.

2-2. 이 저장소에서 직접 확인되는 강점

• 실행 준비의 통합: McLaunchJava(), DlClientFix(), McLaunchArgumentMain()가 하나의 실행 흐름에 연결됩니다.
• 여러 자원 서비스 연결: ResourceSearcher가 CurseForge와 Modrinth 요청 형식·페이지 위치를 따로 관리한 뒤 결과를 정리합니다.
• 실패 이후의 안내: CrashAnalyzer가 로그를 수집하고 분류한 뒤 알려진 패턴과 스택 정보를 분석합니다. 단순한 오류 팝업보다 한 단계 더 나아갑니다.
• 화면까지 읽을 수 있는 공개 범위: README는 UI 라이브러리·애니메이션·다운로드·실행을 포함한 “대부분의 소스”를 공개한다고 설명합니다. 실제로 해당 모듈을 확인할 수 있습니다.

중국어 검색어를 영문 검색어로 바꾸는 처리도 ResourceSearcher.Run()에 있습니다. 이는 해당 언어권 사용자를 위한 세부 구현의 예입니다. 한국어 검색을 같은 수준으로 지원한다고 해석해서는 안 됩니다. 화면과 문서의 언어도 학습 진입 비용에 포함됩니다.

2-3. 다른 런처와 비교할 때 볼 기준

비교 근거(2026-10-23 공식 소개 기준): Prism Launcher 공식 소개, HMCL 공식 저장소. 기능의 독점성이나 속도 우위를 뜻하는 표는 아닙니다. 같은 게임을 실행하더라도 PCL은 Windows UI와 시스템 연동을 공부하려는 독자에게 특히 맞습니다.

3기술 스택 전체 지도

웹 서비스의 용어를 빌리면 화면은 프론트엔드, 설치·실행·다운로드는 백엔드 역할을 합니다. 하지만 PCL에는 이 기능을 제공하는 자체 웹 서버가 필요한 구조가 보이지 않습니다. PCL의 화면과 핵심 업무 로직은 같은 데스크톱 프로세스 안에 있고, 게임은 별도 Java 프로세스로 실행됩니다.

3-1. 프론트엔드: XAML로 그리고 VB.NET으로 반응하기

OptionStrict Off는 VB 코드에서 암시적 변환 등에 관대한 설정입니다. 편하게 작성할 수 있지만 타입 실수가 실행 시점까지 숨어 있을 수 있습니다. 학습용 작은 예제에서는 타입을 명시하고 Option Strict On도 비교해 보세요.

3-2. 로컬 백엔드와 실제 의존성 버전

의존성의 중심은 package.json이 아니라 Plain Craft Launcher 2/Plain Craft Launcher 2.vbproj와 PCLCS/PCLCS.csproj입니다. 아래 DLL 숫자는 VB 프로젝트의 어셈블리 참조 버전이며, NuGet 패키지의 세부 배포 버전과 같다고 단정하지 않습니다.

3-3. 인프라·빌드: Windows CI가 만드는 실행 파일

.github/workflows/build.yml은 windows-latest에서 Debug와 Release 두 구성을 빌드합니다. actions/checkout@v6, microsoft/setup-msbuild@v3, actions/upload-artifact@v7을 사용하고 MSBuild는 x64로 설정합니다. 이들은 CI 액션의 버전이지 PCL에 포함되는 런타임 의존성이 아닙니다.

# .github/workflows/build.yml에 선언된 주요 빌드 명령
dotnet restore PCLCS\PCLCS.csproj
msbuild "Plain Craft Launcher 2\Plain Craft Launcher 2.vbproj" -p:Configuration=Release

# 설명용 인용입니다. 소스 독해에는 빌드 실행이 필요하지 않습니다.

CI는 서브모듈을 함께 가져오고, LTCatt/PCL2Help의 도움말을 압축해 Plain Craft Launcher 2/Resources/Help.zip으로 교체합니다. 또 OAuth 클라이언트 ID와 CurseForge API 키를 CI 비밀값으로 주입하고, CommitHash를 빌드 커밋으로 채웁니다. 공개 소스와 배포 산출물 사이에 이런 준비 단계가 있다는 뜻입니다.

현재 워크플로의 경로 필터는 Plain Craft Launcher 2/**와 .github/workflows/**입니다. PCLCS/**만 바뀐 push·PR은 이 필터에 걸리지 않을 수 있습니다. 또한 빌드·업로드 단계는 있지만 테스트 실행 단계는 없습니다. 빌드 성공과 동작 검증의 범위를 구분해 읽어야 합니다.

4아키텍처 심화 분석

4-1. 전체 구조: UI, 작업, 파일, 게임 프로세스

출발점은 Plain Craft Launcher 2/Application.xaml.vb의 Application_Startup()입니다. 공통 코어와 WPF를 초기화하고, 일반 실행에서는 중복 실행을 검사하고 로그를 준비합니다. WaitingMutex()는 PCL_SingletonMutex라는 이름의 뮤텍스로 이미 실행 중인 인스턴스가 있는지 확인합니다. 개발자 빌드와 업데이트 등 일부 명령행 작업은 이 검사를 건너뜁니다.

이 그림은 실행 경로 중심의 요약입니다. 모드 검색·설정·연결 기능이 모두 이 경로를 그대로 통과하는 것은 아닙니다. 공통 코어 내부 구현과 외부 인증 서버도 그림의 바깥 경계로 남겨 둡니다.

4-2. 패턴 ① 복합 작업과 상태 머신

Plain Craft Launcher 2/Modules/Base/ModLoader.vb에서 LoaderBase는 상태·진행률·취소·오류의 공통 틀입니다. LoaderTask(Of TIn, TOut)는 한 작업, LoaderCombo(Of InputType)는 여러 작업의 묶음입니다. 묶음도 같은 기반 타입이므로 다른 묶음 안에 넣을 수 있습니다. 이것이 복합체(Composite) 패턴로 읽을 수 있는 부분입니다.

Plain Craft Launcher 2/Modules/Minecraft/ModLaunch.vb의 비공개 McLaunchStart(Loader)는 실제 작업 목록을 만듭니다. DlClientFix()가 반환하는 파일 보충 작업도 다시 LoaderCombo로 감싸집니다. 작업 하나와 작업 묶음이 같은 인터페이스를 가지면, 복잡한 절차를 작은 절차의 조합으로 표현할 수 있습니다.

' ModLaunch.vb의 작업 구성 방식을 설명하기 위한 축약 예시
Dim steps As New List(Of LoaderBase) From {
    New LoaderTask(Of Integer, Integer)("Java 준비", AddressOf McLaunchJava) With {
        .ProgressWeight = 4, .Block = False},
    McLoginLoader,
    New LoaderCombo(Of String)("파일 보충", DlClientFix(McInstanceSelected, False, True)) With {
        .ProgressWeight = 15, .Show = False},
    New LoaderTask(Of String, Integer)("인자 생성", AddressOf McLaunchArgumentMain) With {
        .ProgressWeight = 2}
}

Block=False는 해당 작업을 처음 시작한 뒤 같은 순회에서 다음 작업의 시작을 막지 않도록 하는 설정입니다. Java 준비와 로그인처럼 겹쳐 진행할 수 있는 일이 있습니다. 다만 LoaderCombo.Update()의 재순회·입력 갱신 로직까지 포함된 조율이므로 이 목록을 임의의 의존성 그래프를 해결하는 범용 병렬 스케줄러라고 부르지는 않는 편이 정확합니다.

LoaderCombo.Progress는 각 작업의 ProgressWeight를 이용합니다. 예를 들어 가중치가 4와 2이고 진행률이 50%와 0%이면 전체는 (4 × 0.5 + 2 × 0) / 6 = 약 33.3%입니다. 이는 파일 바이트 수나 남은 시간을 그대로 측정한 값이 아니라 제품이 정한 가중 진행률입니다.

주의할 구현도 있습니다. LoaderBase.Progress는 처리 중이 아닌 종료 상태에서 1을 돌려줍니다. 따라서 진행률이 100%라고 성공을 판정하면 안 됩니다. 성공 여부는 반드시 State=Finished인지 확인해야 합니다.

4-3. 패턴 ② 전송과 검증을 나눈 복구 흐름

Plain Craft Launcher 2/Modules/Minecraft/ModDownload.vb의 DlClientJarGet()는 게임 JSON의 다운로드 URL·크기·SHA-1을 읽어 FileChecker와 NetFile을 만듭니다. 이미 검증을 통과한 파일이면 다운로드를 생략할 수 있습니다. “무엇을 받을지 결정하기”와 “실제로 전송하기”를 나누는 설계입니다.

전송은 Plain Craft Launcher 2/Modules/Base/ModNet.vb의 LoaderDownload·NetFile이 맡습니다. NetFile.IsNoSplit는 크기를 모르거나 파일이 1 MiB보다 작으면 분할하지 않습니다. 분할 전송에는 HTTP Range 헤더를 사용하고, 소스가 이를 지원하지 않거나 실패하면 다른 소스·단일 전송 경로를 시도하는 처리가 있습니다.

NetFile.Merge()는 분할 데이터를 합친 뒤 Check?.Check(LocalPath)를 호출합니다. 병합 실패는 최대 세 번 시도하며, 다음 시도 전 500 × RetryCount 밀리초를 기다립니다. 복구가 안 되면 해당 소스를 배제하고 재다운로드를 시도하는 경로로 이어집니다.

여기서 배울 핵심은 “응답을 받았다”와 “쓸 수 있는 파일을 얻었다”를 나누는 것입니다. 해시는 파일의 일치 여부를 확인하는 재료입니다. 메타데이터의 출처까지 검증하는 서명이나 신뢰 체계 전체를 대신하지는 않습니다. FileChecker 내부 구현은 별도 공통 코어 경계에 있으므로 여기서는 호출과 전달값까지만 확정합니다.

4-4. 패턴 ③ 서로 다른 API를 하나의 모델로 연결하기

Plain Craft Launcher 2/Modules/Resource/ResourceSearcher.vb의 SearchRequest는 자원 종류·모드 로더·게임 버전·검색어를 담습니다. GetCurseForgeAddress()와 GetModrinthAddress()가 이 공통 입력을 각 서비스의 요청 형식으로 바꿉니다. 이를 어댑터 역할로 이해할 수 있습니다.

페이지당 요청 크기는 RESULT_PAGE_SIZE=40입니다. GetLoader()는 ReloadTimeout=60 * 1000으로 작업을 만듭니다. 이 값은 입력이 같을 때 재실행을 제어하는 작업 설정이지, 모든 HTTP 응답을 60초 동안 디스크 캐시에 넣는다는 뜻은 아닙니다.

Run()은 작업 스레드를 기다린 뒤 한 서비스만 실패하고 다른 서비스의 결과가 남아 있으면 SearchResult.ErrorMessage에 불완전한 결과임을 적습니다. 중복 제거 전에는 완료 순서와 관계없이 CurseForge 쪽을 먼저 놓고 IsLike()로 중복을 걸러냅니다. 최종 표시 목록은 다운로드 수와 검색 관련도 등의 점수로 다시 정렬합니다. 앞의 처리 순서를 CurseForge가 항상 화면 위에 표시된다는 뜻으로 읽으면 안 됩니다.

4-5. 패턴 ④ 부착 속성과 인터페이스로 설정 연결하기

Plain Craft Launcher 2/Pages/PageSetup/SettingService.vb는 WPF의 DependencyProperty.RegisterAttached()로 Key·Value를 정의합니다. 화면은 어떤 설정을 다루는지만 적고, 실제 저장은 공통 코드에 맡깁니다.

<!-- 실제 설정 키를 사용한 설명용 XAML -->
<local:MyCheckBox
    local:SettingService.Key="LaunchArgumentRam"
    Text="실행 전 메모리 정리" />

' MyCheckBox.xaml.vb의 설정 연결
Private Sub SaveSetting() Handles Me.Change
    SettingService.SaveSetting(Me)
End Sub

ISettingControl의 두 메서드 RefreshSetting()·GetCurrentSetting()가 컨트롤과 설정 서비스 사이의 약속입니다. SaveSetting()은 키를 읽고 Settings.Set()을 호출합니다. RefreshSettings()와 ResetSettings()는 논리 트리를 따라 하위 컨트롤까지 처리합니다.

또한 AniControlEnabled가 0이 아니면 저장을 건너뜁니다. 화면에 값을 채우는 과정에서 변경 이벤트가 일어나 다시 저장되는 상황을 제어합니다. 변수 이름만 보고 단순 애니메이션 스위치로 생각하기 쉽지만 설정 흐름에도 영향을 줍니다.

이 구조를 “엄격한 MVVM”이라고 소개하기는 어렵습니다. FrmMain 같은 전역 화면 참조와 코드 비하인드가 업무 모듈에도 등장합니다. 반복을 줄인 부분을 배우면서, 화면과 업무 로직이 결합된 비용도 함께 읽는 것이 좋습니다.

Plain Craft Launcher 2/Pages/PageSetup/Settings.vb의 Setting.Save()는 저장 위치도 나눕니다. Sources.Normal은 공통 INI, Sources.Registry는 현재 사용자 레지스트리, Sources.Instance는 해당 버전의 PCL\Setup.ini로 이어집니다. 설정 화면의 컨트롤 이름과 실제 저장 위치를 분리하면, 화면을 바꾸더라도 저장 규칙을 유지하기 쉽습니다.

4-6. 마지막 경계: 프로세스 시작 이후에도 일이 남는다

McLaunchArgumentMain()는 JVM 인자, JSON의 mainClass, 게임 인자를 차례로 모으고 치환값과 따옴표 처리를 적용합니다. 이어 McLaunchRun()은 java.exe용 ProcessStartInfo를 만들고, 작업 디렉터리·환경 변수·인코딩을 설정합니다.

' McLaunchRun()에서 확인되는 핵심 설정
StartInfo.WorkingDirectory = McInstanceSelected.PathIndie
StartInfo.UseShellExecute = False
StartInfo.RedirectStandardOutput = True
StartInfo.RedirectStandardError = True
StartInfo.CreateNoWindow = True
StartInfo.Arguments = McLaunchArgument

McLaunchWait()와 Plain Craft Launcher 2/Modules/Minecraft/ModWatcher.vb의 Watcher는 게임 창과 프로세스를 살핍니다. BeginOutputReadLine()·BeginErrorReadLine()으로 로그를 읽고, Loading·Running·Crashed·Ended 등의 상태를 구분합니다. 프로세스가 생성됐다는 사실과 사용자가 게임을 할 수 있다는 사실은 다르기 때문입니다.

문제가 생기면 Plain Craft Launcher 2/Modules/Minecraft/ModCrash.vb의 CrashAnalyzer가 Collect() → Prepare() → Analyze() 흐름으로 로그를 수집·정리·분석합니다. AnalyzeCrit1()·AnalyzeCrit2()의 알려진 패턴을 먼저 보고, 스택 단서와 모드 이름을 찾은 뒤 낮은 우선순위 패턴을 봅니다. LLM을 부르는 분석이 아니라 소스에 작성된 규칙과 문자열 처리에 기반한 진단입니다.

5디렉토리 구조 해부

5-1. 코드 규모: 공백·주석을 포함한 물리적 줄 수

줄 수는 복잡도나 품질 점수가 아닙니다. Plain Craft Launcher 2/Modules/Minecraft/ModLaunch.vb는 2,221줄, Plain Craft Launcher 2/Modules/Base/ModNet.vb는 1,933줄로 책임이 큰 파일입니다. 처음에는 이를 통독하지 말고 함수 이름을 검색하며 필요한 범위만 읽는 편이 좋습니다. 두 Plain Craft Launcher 2/My Project/*.Designer.vb는 합계 304줄이며 VB 집계에 포함되어 있습니다.

5-2. 추천 독서 순서

1. Plain Craft Launcher 2/Application.xaml.vb: 시작 시 검사와 초기화 경계를 확인합니다.
2. Plain Craft Launcher 2/Modules/Minecraft/ModLaunch.vb: 실행 작업 목록과 최종 프로세스 생성을 연결합니다.
3. Plain Craft Launcher 2/Modules/Base/ModLoader.vb: 상태·진행률·실패 전파의 공통 규칙을 읽습니다.
4. Plain Craft Launcher 2/Modules/Minecraft/ModDownload.vb와 Plain Craft Launcher 2/Modules/Base/ModNet.vb: 파일 목록과 전송 엔진의 역할을 나눕니다.
5. Plain Craft Launcher 2/Pages/PageSetup/SettingService.vb·Plain Craft Launcher 2/Controls/MyCheckBox.xaml.vb: 화면의 값이 저장되는 경로를 따라갑니다.
6. PCLCS/Minecraft/McVersion.cs: 더 작은 입력 변환 문제로 돌아와 이해를 확인합니다.

6학습 포인트 (기술별)

VB.NET을 처음 접해도 Class, Function, Sub, AddressOf, With의 역할만 알면 큰 흐름을 읽을 수 있습니다. 문법을 전부 익히기 전에 입력·상태·출력·실패의 네 칸을 채우는 것이 소스 독해의 좋은 출발점입니다.

6-6. 보안과 데이터 수명도 코드 독해의 일부다

McLaunchLog()는 FilterAccessToken()과 FilterUserName()을 거쳐 로그를 남깁니다. Plain Craft Launcher 2/Pages/PageSetup/Settings.vb에는 계정 캐시를 Encrypted:=True로 선언한 항목이 있습니다. 이를 보고 모든 로그·모든 데이터가 안전하다고 결론 내리지 말고, 민감한 값이 어느 경로로 저장·출력되는지 더 확인해야 합니다.

또한 SystemSystemTelemetry의 기본값은 True이고, 실행 성공·실패 경로에는 Telemetry() 호출이 있습니다. 그러나 ModSecret 모듈의 ClsBaseUrl은 빈 문자열이고, ModMain 모듈의 해당 함수는 주소가 http로 시작하지 않으면 즉시 반환합니다. 따라서 이 커밋의 해당 경로에서는 텔레메트리를 전송하지 않습니다. 게임 인증·자원 조회 등의 네트워크 요청과는 구분해야 합니다.

7하드웨어 / 시스템 요구사항

PCL이 실행되는 조건과 Minecraft가 쾌적하게 돌아가는 조건은 서로 다릅니다. 소스에는 PCL 자체의 공식 CPU·RAM·GPU 최소 사양표가 없습니다. 대신 시작 검사와 빌드 설정에서 확정할 수 있는 조건은 다음과 같습니다.

7-1. Java는 “최신 하나”로 끝나는 문제가 아니다

Plain Craft Launcher 2/Modules/Minecraft/ModJava.vb의 GetJavaRequirement()는 게임 버전과 설치된 구성요소가 요구하는 Java 범위의 교집합을 구합니다. 조건이 충돌하면 경고를 남기고 새 조건으로 대체하며, 사용자가 버전 설정에서 범위를 지정하면 그 값을 우선합니다. 원본 메타데이터의 새로운 Java 요구도 반영합니다. 아래는 해당 함수의 일부 분기이며 전체 호환성 표가 아닙니다.

PCLCS/Java.cs의 CheckAsync()는 -XshowSettings:properties -version 출력을 읽고 인코딩 속성도 얻습니다. 검사 제한 시간은 15000밀리초입니다. 게임 실행 실패가 단순히 “Java가 없다”가 아니라 버전·비트수·인코딩 문제일 수도 있음을 보여 줍니다.

7-2. 학습 환경을 고른다면

소스만 읽을 때는 편집기와 텍스트 검색 도구면 충분합니다. WPF 예제를 별도로 만들어 볼 때는 Windows 11 64비트와 C# 13을 지원하는 컴파일러, .NET Framework 4.8 대상 개발 도구를 우선 고려할 수 있습니다. 이 저장소의 CI가 사용하는 windows-latest는 고정된 Windows·SDK 버전 이름이 아닙니다.

편집기·개발 도구를 함께 쓰는 편의를 위한 참고선은 RAM 8GB 이상, 여유가 있다면 16GB, SSD의 충분한 빈 공간입니다. 이는 이 글의 학습 환경 제안이며 PCL의 공식 최소 사양이나 Minecraft 성능 보장이 아닙니다. GPU·게임용 RAM은 게임 버전과 모드·셰이더 구성에 따라 별도로 정해야 합니다. 런타임의 운영체제 호환성은 Microsoft의 .NET Framework 시스템 요구사항을 참고하세요.

8직접 해볼 수 있는 실습 과제

실습은 원본을 고쳐 빌드하기보다, 독립된 작은 예제와 가짜 데이터로 진행하도록 구성했습니다. 정상 동작을 흉내 내는 데서 끝내지 말고, 실패와 취소가 어떻게 구분되는지까지 확인하세요.

# 소스의 정규화 규칙을 읽고 얻을 수 있는 예시
1.9      → 9.0.0
1.10     → 10.0.0
1.20.3   → 20.0.3
26.1     → 26.1.0
unknown  → 9999.0.0

# 실습용 가짜 응답. 실제 API의 완전한 응답 형식은 아닙니다.
{"data": [{"id": 101, "name": "Example A"}], "pagination": {"totalCount": 1}}
{"hits": [{"project_id": "abc", "title": "Example B"}], "total_hits": 1}

9관련 기술 심화 학습 로드맵

주당 3~5시간을 기준으로 한 예시입니다. 게임 지식이 없어도 작업 조율·파일 검증·UI 이벤트는 충분히 배울 수 있습니다. 매주 읽은 소스에서 하나의 규칙을 꺼내 작은 독립 예제로 설명할 수 있으면 학습이 쌓이고 있다는 뜻입니다.

9-1. 관심사에 따른 다음 갈림길

• 화면 개발: WPF의 데이터 바인딩과 MVVM을 배우고, PCL의 코드 비하인드 방식과 화면 의존성을 비교합니다. “상태를 별도 모델로 옮기면 어떤 함수가 쉬워지는가”를 질문하세요.
• 시스템 개발: 프로세스 종료 코드, 표준 출력·오류, 파일 교체, 취소 전파를 공부합니다. 다운로드나 설치 작업의 부작용이 어디서 확정되는지 따져 보세요.
• 라이브러리 설계: PCLCS의 모델과 VB 앱의 호출 경계를 비교하고, 화면을 몰라도 검증 가능한 순수 함수를 분리하는 연습을 합니다.
• 빌드·품질: 서브모듈과 외부 도움말의 버전 고정, 경로 필터, 테스트 실행 단계, 배포 산출물의 재현성을 공부합니다.

10핵심 키워드 사전

11참고 링크

11-1. 프로젝트와 코드 근거

• PCL 공식 저장소 · 2.99.0.0 릴리스 · 공식 다운로드 안내
• 분석 기준 커밋 6b9a50d 전체 트리
• 실행 경로: ModLaunch.vb · 작업 조율: ModLoader.vb
• 다운로드 엔진: ModNet.vb · 게임 파일 목록: ModDownload.vb
• 통합 검색: ResourceSearcher.vb · 설정 연결: SettingService.vb
• Java 검사: Java.cs · 버전 정규화: McVersion.cs
• VB 빌드·참조 버전 · C# 빌드·PolySharp 버전 · GitHub Actions 빌드 설정
• LICENCE: 배포 제한과 이용 안내 · LICENCE가 가리키는 별도 배포 허가 문서
• 연결된 MeloongCore 커밋 · 내장 도움말 저장소 · TrendShift

11-2. 관련 기술 공식 문서

• Visual Basic 프로그래밍 가이드 — 클래스·이벤트·제네릭의 기본 문법
• WPF 개요 — XAML·컨트롤·화면과 동작의 분리. PCL의 대상은 .NET Framework 4.8
• WPF 스레딩 모델 — Dispatcher와 작업 스레드의 경계
• .NET Framework 시스템 요구사항 — 런타임과 Windows 호환성
• 관리형 스레드의 취소 — 협력적 취소의 원리
• HTTP 표준의 범위 요청 — Range와 부분 응답
• Modrinth API 공식 문서 · CurseForge API 공식 문서 — 각 플랫폼의 요청·응답 형식
• Git 공식 책: 서브모듈 — 별도 저장소와 커밋 포인터
• Prism Launcher 공식 소개 · HMCL 공식 저장소 — 다른 기술 선택과 지원 범위 비교

11-3. 현재 상태 (2026-10-23 확인)