Windows CE 앱 컨테이너 시작
이 Windows CE 앱 컨테이너 Windows 10 IoT Core를 기반으로 대부분의 CE 애플리케이션을 실행할 수 있는 기술입니다.
솔루션은 두 단계로 빌드됩니다. 첫 번째 단계에서는 x86 또는 ARM32 아키텍처에 BSP를 사용하여 Windows CE 2013 이미지를 만듭니다. 그런 다음 두 번째 단계에서 이 이미지는 솔루션을 설치할 특정 디바이스 하드웨어에 대해 x64 또는 ARM32 BSP를 활용하는 Windows 10 IoT Core 이미지에 포함됩니다.
이 아키텍처에 대한 자세한 내용은 Windows CE 디바이스 현대화 비디오를 검토하세요.
필수 조건
Windows CE 앱 컨테이너 소프트웨어에는 업데이트된 버전의 Windows Compact 2013(2020년 6월 이상 빌드 번호 6294)과 x64 및 ARM32용 업데이트된 Windows 10 IoT Core 패키지(2020년 8월 업데이트 이상)가 필요합니다. Windows 10 IoT Core에 대한 최신 패키지를 얻으려면 Microsoft 배포자에 문의하세요.
참고 항목
CE 앱 컨테이너 기술을 사용하는 디바이스를 배포하려면 유효한 IoT Core Services 구독이 있어야 합니다.
또한 다음이 필요합니다.
Microsoft Visual Studio 2013 Professional 또는 Visual Studio 2015 Professional. 이러한 버전은 Application Builder 및 Platform Builder 도구 모두에 필요합니다.
Windows Compact 2013용 플랫폼 작성기
작동하는 IoT Core BSP
Windows IoT 제조 가이드에서 참조하는 도구
이 가이드에서 참조하는 구성 요소 대신 업데이트된 구성 요소를 설치해야 합니다(Windows 10 ADK 및 Windows 10 ADK PE 추가 기능, IoT Core ADK 추가 기능, Windows 10 IoT Core 대시보드).
Windows CE 앱 컨테이너 대한 CE 구성, 빌드 및 패키징
Windows Embedded Compact 2013 이미지를 만드는 프로세스는 크게 업데이트되지 않았습니다. 이미지를 빌드하는 일반적인 프로세스는 다음과 같습니다.
플랫폼 빌더를 사용하여 OS 디자인 프로젝트 만들기
BSP(플랫폼 작성기 보드 지원 패키지) 선택
적절한 디자인 템플릿 선택
디자인 템플릿에서 제공하는 옵션 구성
필요에 따라 디자인 프로젝트에 하위 프로젝트 추가
이미지 빌드
기본 변경 사항은 올바른 BSP 선택 및 CE 이미지에 대한 추가 고려 사항입니다. 이 가이드에서는 Windows CE 시스템 이미지를 빌드하는 프로세스에 이미 익숙하다고 가정하지만 변경된 섹션을 더 자세히 살펴볼 가치가 있습니다.
2단계는 CE 앱 컨테이너를 사용할 때 변경된 이전 OS 디자인 프로젝트 프로세스의 유일한 부분입니다. 자세한 내용은 아래를 참조하세요.
2단계 - 플랫폼 작성기 BSP 선택
Windows CE 앱 컨테이너 지원하기 위해 x86 및 ARM 아키텍처를 대상으로 하는 새 BSP가 Platform Builder에 추가되었습니다.
CE 앱 컨테이너에 대한 OS 디자인을 만들 때 IoT Core 기반 디바이스의 기본 하드웨어에 따라 "Windows CE 앱 컨테이너: x86" 또는 "Windows CE 앱 컨테이너: ARMv7"(ARM32)을 선택합니다.
예를 들어 대상 IoT Core 디바이스에서 Intel 하드웨어를 사용하는 경우 "Windows CE 앱 컨테이너: x86" 옵션을 선택합니다. 또는 IoT Core 하드웨어에서 NXP i.MX6을 사용하는 경우 "Windows CE 앱 컨테이너: ARMv7" 옵션을 선택합니다.
이렇게 하면 일반적으로 Windows Embedded Compact 이미지에 대해 수행하는 것처럼 옵션 및 하위 프로젝트를 구성할 수 있습니다. 이러한 구성은 Windows 10 IoT Core 이미지에 배포할 CE 컨테이너에 기본 제공될 예정입니다.
Windows 10 IoT Core 이미지 빌드
참고 항목
이 프로세스는 Windows 10 IoT Core 제조 가이드의 일부인 랩에서 자세히 설명합니다. 아래 섹션에서는 IoT Core 이미지 빌드 프로세스의 특정 단계에서 실행할 추가 작업만 제공합니다. 계속하기 전에 Windows 10 IoT Core 제조 가이드를 숙지하는 것이 좋습니다.
프로세스 개요
Windows Embedded Compact 이미지를 빌드하는 프로세스와 달리 Windows 10 IoT Core는 펌웨어, 보드 지원 패키지, 이미지 정의 및 애플리케이션 포함 생성을 아직 통합합니다. 이러한 부분에 대해 다양한 기술을 활용하여 조직의 여러 팀 또는 개인 간에 수행해야 하는 작업을 구분할 수 있습니다.
이미지를 만드는 기본 단계는 다음과 같습니다.
이전에 만든 CE 앱 컨테이너 가져오기
Windows 10 IoT Core 제조 가이드의 일부로 이러한 각 단계에 대한 자세한 가이드가 있습니다. 이러한 단계 중 일부는 PB(Platform Builder)를 사용하여 디바이스 이미지를 만드는 프로세스와 비슷하지만 일부 영역을 더 자세히 살펴볼 가치가 있습니다.
1단계 - 작업 영역 만들기
IoT Core 제조 가이드에서 기본 이미지 만들기 설명서를 검토하여 작업 영역을 만드는 방법을 알아봅니다.
2단계 - 적절한 BSP(IoT Core 보드 지원 패키지) 가져오기
보드 지원을 위해 IoT Core 제조 가이드에서 기본 이미지 만들기 설명서를 검토합니다.
3단계 - Windows CE 앱 컨테이너 가져오기
Windows CE 앱 컨테이너 위에서 설명한 대로 PB를 사용하여 만들어지고 Import-IoTCEPAL 명령을 사용하여 IoT Core 작업 영역으로 가져옵니다. 이 명령은 CE 플랫 릴리스 디렉터리의 필수 콘텐츠를 IoT ADK 작업 영역으로 복사합니다. 여러 번 호출된 경우 이전 상태는 작업 영역의 Source-\$Arch\CEPAL.OLD 디렉터리 아래에 백업됩니다.
4단계 - 제품 정의 만들기
IoT Core 제조 가이드에서 기본 이미지 만들기 설명서를 검토하여 제품 정의를 만듭니다.
5단계 - 제품에 CE 앱 컨테이너 추가
CE 앱 컨테이너 정의를 작업 영역으로 가져온 후에는 관련 제품 OEMInput.xml 파일(테스트 및 소매)에 CE 앱 컨테이너 패키지에 대한 참조를 추가하는 Add-IoTCEPAL 명령을 실행해야 합니다.
다음 단계는 Add-IoTProductFeature 명령을 사용하여 OEMInput.xml IOT_CEPAL 기능을 추가하는 것입니다. 이렇게 하면 제품 정의에 Windows CE 앱 컨테이너(Windows CE 프런트 엔드 UWP 앱 + 지원 드라이버)에 대한 Windows 호스트 지원이 추가되고 기본 앱 그룹에 CE 앱 컨테이너가 포함됩니다. 이후 섹션에서는 시작 구성에 대해 설명합니다.
6단계 - CAB 파일 빌드
이는 FFU를 만드는 동안 중요한 단계이며 구성을 변경하고 애플리케이션 또는 드라이버를 추가/변경할 때마다 수행해야 합니다. "모두" 옵션과 함께 New-IoTCabPackage를 사용합니다. 필요에 따라 단일 기능을 빌드할 수도 있지만 일반적으로 FFU를 모범 사례로 빌드하기 전에 모든 패키지를 다시 빌드해야 합니다.
7단계 - 디바이스에 FFU 배포
이미지가 빌드되면 디바이스에 배포할 수 있습니다. DISM을 사용하는 명령줄, 디바이스별 배포 프로세스 또는 Windows 10 IoT Core 대시보드 사용하여 이 작업을 수행할 수 있습니다. 자세한 내용은 Windows 10 IoT Core 제조 가이드의 일부로 제공됩니다.
기존 FFU를 사용할 때 디바이스에 Windows CE 앱 컨테이너 배포
CE CAB는 IoT Core에서 배포 가능한 패키지입니다. 기존 IoT Core 이미지가 있는 경우 명령을 사용하여 APPLYUPDATE 이러한 CAB를 디바이스에 배포할 수 있습니다. 먼저 CAB를 디바이스에 복사한 다음, 을 사용하여 CAB를 스테이징하고 커밋합니다 APPLYUPDATE. 이러한 방식으로 업데이트하면 패키지 버전 관리가 적용되므로 업데이트된 패키지 버전을 디바이스에 배포하려면 버전 번호가 더 커야 합니다. (IoT ADK 환경의 Set-IoTCabVersion 명령을 참조하세요). 이에 대한 자세한 내용은 패키지 만들기 및 설치에서 찾을 수 있습니다.
8단계 - 소매 이미지 빌드
제대로 서명된 이미지를 갖는 것은 디바이스를 보호 및 업데이트하는 데 중요한 부분입니다. Windows 10 IoT Core의 경우 테스트 서명된 빌드와 Retail 서명된 빌드 간의 차이로 나타납니다. 테스트 서명된 이미지를 공개적으로 배포해서는 안 됩니다. 테스트 서명된 이미지는 디버그 목적으로만 사용해야 하며 최종 소매 서명 이미지를 만들기 전에 오류 또는 구성 변경 내용을 수정해야 합니다.
참고 항목
컴퓨터에 설치된 개발 및 배포 도구 외에도 소매 서명을 사용하도록 설정하려면 다음이 필요합니다.
- 정품 코드 서명 인증서
- 상호 서명 인증서
애플리케이션에 올바르게 서명 및 포함
Windows 10 IoT Core 소매 이미지에 포함하려는 사용자 지정 애플리케이션이 하나 이상 있는 경우 소매 이미지에 포함할 때 이러한 애플리케이션이 제대로 서명되었는지 확인해야 합니다.
추가 정보
기존 이미지에 새 애플리케이션 추가
기존 OS 디자인에 새 애플리케이션을 추가하려면 프로젝트를 OS 디자인 프로젝트에 하위 프로젝트로 추가하거나 일반 배포 CAB 패키지를 만들어 초기 디바이스 설정의 일부로 디바이스에 배포할 수 있습니다.
패키징 모범 사례
항상 패키지가 업데이트 시간을 줄이기 위해 가능한 한 세분화되도록 하는 것을 목표로 해야 합니다.
패키지는 업데이트의 가장 작은 단위이므로 각 패키지가 가능한 한 작은지 확인합니다. Platform Builder에서 빌드할 때 생성된 패키지는 메모리 섹션 및 bib 파일에 따라 모듈/파일 형식에 따라 자동으로 구분됩니다.
Platform Builder에서 빌드되고 OSDesign.bib를 통해 패키지된 사용자 지정 자산의 경우 사용자 지정 코드 업데이트가 CE OS에 대한 업데이트와 별도로 제공될 수 있도록 BIB(NK가 아님)의 별도 메모리 섹션에 사용자 지정 자산을 추가하는 것이 좋습니다.
IoT ADK 패키징 명령을 통해 추가된 사용자 지정 자산의 경우: 만든 패키지가 가능한 한 작은지 확인합니다.
Platform Builder 패키지에 다른 항목 추가
일반적으로 시스템 이미지에 추가 구성 요소를 포함하도록 Platform Builder에서 생성된 결과 패키지를 수정하지 않는 것이 좋습니다. 대신 Windows 10 IoT Core 제조 가이드를 따릅니다. 그러나 Platform Builder에서 만든 패키지에 파일을 추가해야 하는 경우 기존 프로세스를 따릅니다. PB에서 생성된 패키지에 콘텐츠를 추가할 때 다음을 고려합니다.
패키지의 최대 크기(약 400MB)가 있으며 이 크기를 초과하면 업데이트가 방지됩니다.
업데이트 패키지 세분성에서 발생합니다. 패키지의 단일 자산을 업데이트해야 하는 경우 해당 패키지의 모든 자산이 동시에 업데이트됩니다. 업데이트 크기를 줄이려면 콘텐츠를 별도의 패키지로 격리하여 전체 업데이트 크기를 최소화합니다.
플랫폼 작성기에서 추가 파일 추가
위에서 자세히 설명한 패키징 프로세스는 CE BIN 파일을 빌드하는 것과 동일한 입력에 의해 구동됩니다. 따라서 OSDesign.bib에서 파일이 참조되고 레지스트리 항목이 OSDesign.reg MAKEIMG 추가되면 프로세스에 이러한 파일이 결과 CAB 파일에 포함됩니다. 이 프로세스 중에는 이제 다음이 수행 MAKEIMG 됩니다.
ROMIMAGE는 CEPAL용 Windows CE에 대해 설치된 디렉터리 구조를 준비하는 FRD(Flat Release Directory) 내에 이름이 지정된CEPAL\_PKG디렉터리를 만듭니다.ROMIMAGE는 CE BIB 파일을 기반으로 배치된 모든 CE 파일을 인벤토리에 넣습니다CEPAL\_PKG.ROMIMAGE는 각 메모리 섹션에 대해 여러 WM.XML 파일을 만듭니다. 이 작업은 업데이트의 최소 단위가 패키지이므로 업데이트를 보다 세분화된 방식으로 푸시할 수 있도록 수행됩니다.ROMIMAGE는 생성된 모든 패키지를 참조하는 패키지를 만듭니다.
생성된 모든 패키지의 이름은 고정된 접두사“%OEM\_NAME%.WindowsCE.\*”로 지정되며, New-IoTCabPackage%OEM\_NAME%를 호출할 때 IoT Core 생성 프로세스 중에 채워집니다. 이름 공간 내의 패키지 이름은 BIB 파일(예: NK)의 메모리 섹션에서 파생된 다음 모듈/파일(BIB 파일에 의해 결정됨)이 뒤따릅니다.
Windows Embedded Compact 2013과 Windows 10 IoT Core 애플리케이션 간 통신
CE 컨테이너에서 실행되는 애플리케이션 간에 통신하는 권장 방법은 로컬 루프백을 사용하는 것입니다. 이 문서에서 로컬 루프백에 대해 자세히 읽을 수 있습니다.
CE 앱 컨테이너 애플리케이션 자동 시작
CE 컨테이너 애플리케이션을 자동으로 시작하려면 시작 애플리케이션 을 "Microsoft.Windows.IoT.CEPAL.DkMonUWP_cw5n1h2txyewy! 앱"을 선택하고 이 프로비저닝 패키지를 이미지에 포함했습니다. 또한 Remove-IoTProductFeature 명령을 사용하고 IoT Core 제품 정의에서 IOT_BERTHA 기능 ID를 제거하여 기본 시작 애플리케이션을 제거해야 합니다.
Windows CE 앱 컨테이너 사용 가능한 구성 설정
CE의 레지스트리 기반 구성
기본적으로 실행 불가능한 스택
Windows CE 앱 컨테이너 보안을 개선하기 위해 기본적으로 실행 가능한 스택 페이지를 사용하지 않도록 설정했습니다. 그러나 일부 레거시 애플리케이션은 이 동작을 사용하여 올바르게 실행할 수 있습니다. 실행 파일 스택을 사용하도록 설정하려면 CE 이미지에서 다음 레지스트리 값을 설정합니다(플랫폼 작성기에서 OSDesign.reg 사용하는 것이 좋습니다.)
KeyPath = HKEY\_LOCAL\_MACHINE\CEPAL
ValueName = MemoryOptions Type = REG\_DWORD
Value = 1
GWES에 대한 16비트 565 재정의
Windows CE 앱 컨테이너 32비트 디스플레이로 구성된 경우 16비트 RGB 픽셀 데이터가 RGB555 형식이라는 가정하에 GWES에서 16비트~32비트 RGB 변환을 수행합니다. 비트맵 리소스가 16비트 565에 있고 이러한 리소스의 RGB555로 변환할 수 없는 경우 레지스트리 키를 통해 GWES의 기본 변환 동작을 변경할 수 있습니다. 다음 레지스트리 키를 만듭니다.
HKEY\_LOCAL\_MACHINE\SYSTEM\GDI\16bpp565RGBPalette.
호스트의 레지스트리 기반 구성(IoT Core)
Windows CE 앱 컨테이너 대한 직렬 포트 구성
호스트 직렬 포트는 CE 환경에 매핑되어야 합니다. 이 매핑은 IoT Core의 레지스트리에 존재하며 이미지 작성자가 구성해야 합니다.
아래에서 HKEY\_CURRENT\_USER\Software\Microsoft\Windows NT\CurrentVersion\CEPAL\Devices\Serial다음 스키마를 사용하여 게스트 COM 포트를 호스트 COM 포트에 매핑하기 위한 구성 항목이 있습니다.
KeyPath = HKEY\_CURRENT\_USER\Software\Microsoft\Windows NT\CurrentVersion\CEPAL\Devices\Serial\0
ValueName = Guest Type = REG\_SZ Value = COM1
ValueName = Host
Type = REG\_SZ
Value = \\?\Some\DeviceInterface\Path
KeyPath= HKEY\_CURRENT\_USER\Software\Microsoft\Windows NT\CurrentVersion\CEPAL\Devices\Serial\1
ValueName = Guest Type = REG\_SZ Value = COM2
ValueName= Host Type = REG\_SZ
Value = \\?\Some\Other\DeviceInterface\Path
CE를 부팅할 때 위의 레지스트리 경로가 없는 경우 시스템에서 검색된 직렬 디바이스를 기반으로 기본 구성이 작성됩니다.
호스트의 파일 기반 구성
CE 컨테이너는 호스트 C:\WindowsCE\CEEnvConfig.json의 로컬 파일을 사용하여 구성할 수 있습니다. 이 구성 파일의 샘플은 다음과 같습니다.
{
"OEMOptions" :
{
"GUI" : true,
"Width" : 1024,
"Height" : 768, "FillScreen" : true, "ColorDepth" : 32,
"RefreshRate" : 30, "noAslrSupport" : true, "OemConfigApp" : "",
"OemConfigFile" : ""
},
"CEPALDevOptions" :
{
"VsDebugMode" : true, "FastDebugBoot" : false
}
}
OEMOptions
| 키 | 설명 |
|---|---|
| GUI | UI를 사용하여 CE 앱 컨테이너 시작(기본값 true) |
| Width | CE 앱 컨테이너 표시의 너비(기본값 1024) |
| Height | CE 앱 컨테이너 디스플레이의 높이(기본값 768) |
| FillScreen | |
| ColorDepth | 픽셀당 기본 비트 설정(기본값 32) |
| RefreshRate | 디스플레이가 초당 다시 그려지는 횟수 |
| noAslrSupport | CE 앱 컨테이너에서 주소 공간 레이아웃 임의화를 사용하지 않도록 설정(기본값 true) |
| OEMConfigApp | 구성을 위해 시작해야 하는 OEM 제공 앱의 패키지 패밀리 이름입니다. |
| OEMConfigFile | OEMConfigApp과 CE 앱 컨테이너 간에 공유되는 추가 구성 옵션이 포함된 파일의 경로 |
CE 앱 컨테이너는 하나의 네트워크 인터페이스만 사용할 수 있도록 합니다. 호스트 시스템에 여러 NIC가 있는 경우 선택한 NIC가 결정적인지 확인하려면 호스트 레지스트리에서 하나의 인터페이스를 선택해야 합니다.
OEMConfigFile
OEMConfigFile은 에 C:\WindowsCE\CEEnvConfig.json지정됩니다. UWP 애플리케이션에서 이 파일을 읽을 수 있는지 확인합니다. 다음은 샘플입니다.
{
“FactoryReset”: false, “PlatformBuilderDebugMode”: false,
“NetInterface”: “Some Network Profile Id”
}
옵션:
| 키 | 설명 |
|---|---|
| FactoryReset | config 앱에서 영구 상태를 덤프하도록 CE 앱 컨테이너에 신호를 보낼 때 사용됩니다. |
| PlatformBuilderDebugMode | Platform Builder를 사용하여 디버깅을 지원하는 KITL을 사용하여 CE 앱 컨테이너를 부팅하는 데 사용됩니다. |
| NetInterface | 프로필 이름에 따라 CE용 네트워크 인터페이스를 선택합니다. |