Deployment di Windows

Windows adalah platform dengan jumlah pengguna akhir terbesar, dan aturan mainnya untuk deployment berbeda total dari Linux yang baru kita selesaikan: tidak ada manajer paket bawaan yang mengurus library, penempatan berkas mengikuti konvensi C:\ tersendiri, dan kepercayaan pengguna bergantung pada sertifikat digital, bukan repositori. Kabar baiknya, semua konsep section ini tetap berlaku — runtime dependencies, penautan statis vs dinamis, bundle mandiri — hanya bungkusnya yang berubah. Chapter ini menyiapkan Anda untuk distribusi Windows secara utuh, dari source portabel, persoalan runtime MSVC yang paling sering menggagalkan aplikasi pemula, hingga installer dan code signing. Karena lingkungan praktikum berupa Linux, semua contoh Windows tampil sebagai pola yang merujuk dokumentasi resmi Microsoft — tanpa klaim eksekusi — sementara program contohnya tetap kita uji sungguhan di sini.

Portabilitas Source: Persiapan Sebelum Menyentuh Windows #

Langkah pertama distribusi ke Windows adalah memastikan source-nya layak melintasi sistem operasi — dan kita sudah punya bahan uji untuk itu:

#include <filesystem>
#include <iomanip>
#include <iostream>

// Program portabel untuk latihan deployment Windows: konversi cm ke inci.
// Hanya standard library — tanpa API spesifik OS, sehingga dikompilasi
// bersih oleh GCC di Linux maupun MSVC/MinGW di Windows.
int main(int argc, char* argv[]) {
    if (argc < 2) {
        std::cerr << "Pemakaian: konversi-unit <cm>\n";
        return 1;
    }

    double cm = std::stod(argv[1]);

    std::cout << std::fixed << std::setprecision(2);
    for (double nilai = cm; nilai <= cm + 40.0; nilai += 20.0) {
        std::cout << nilai << " cm = " << nilai / 2.54 << " inci\n";
    }

    std::filesystem::path berkasKonfigurasi{"data/konfigurasi.cfg"};
    std::cout << "Berkas konfigurasi: " << berkasKonfigurasi.generic_string() << '\n';
    return 0;
}

Output yang Dihasilkan:

100.00 cm = 39.37 inci
120.00 cm = 47.24 inci
140.00 cm = 55.12 inci
Berkas konfigurasi: data/konfigurasi.cfg

Baris terakhir adalah pelajaran terpentingnya: generic_string() meminta std::filesystem::path tampil dalam format generik — pemisah / — sehingga satu string logika tampil sama di Linux dan Windows; tanpa itu, jalur yang dibangun di Windows tampil dengan \. Dua kebiasaan portabel lain yang sudah kita ikuti diam-diam: konversi angka lewat std::stod dan std::fixed (perilaku format konsisten antar platform), serta pemisah baris '\n' — di Windows mode teks akan menerjemahkannya menjadi CRLF secara otomatis, jadi jangan menulis "\r\n" manual ke stream teks.

Pilihan Toolchain: MSVC dan MinGW-w64 #

Ada dua keluarga toolchain untuk membangun aplikasi Windows dari C++. MSVC, compiler resmi Microsoft yang hadir lewat Visual Studio, adalah pilihan standar industri: debugger-nya menyatu dengan platform, dan flag /std: memilih tingkat standar bahasa yang dipakai. Keluarga kedua adalah MinGW-w64 — porting GCC ke Windows — yang menarik karena terhubung langsung dengan materi Chapter Cross-compilation: toolchain dengan target triple x86_64-w64-mingw32 memungkinkan mesin Linux membangun .exe Windows. Untuk aplikasi yang akan didistribusikan luas, MSVC umumnya dipilih karena ekosistemnya (SDK, alat sertifikasi, dukungan library pihak ketiga yang menyediakan biner .lib).

MSVC Runtime: Persoalan vcredist #

Di Linux, libstdc++.so.6 hampir selalu ada; di Windows tidak ada padanan bawaan, dan inilah sumber error dukungan paling umum aplikasi C++: pengguna menjalankan .exe Anda dan menerima VCRUNTIME140.dll not found. Mekanismenya identik dengan Chapter Executable dan Runtime Dependencies — hanya nama pemainnya yang berganti. Secara default MSVC menautkan runtime secara dinamis (flag /MD), sehingga biner menuntut DLL runtime Microsoft saat berjalan:

Jalan resmi untuk /MD adalah meminta pengguna memasang VC++ Redistributable (vc_redist.x64.exe) — installer kecil yang diterbitkan Microsoft dan diunduh dari dokumentasi resminya (lihat Referensi). Banyak installer aplikasi menjalankannya otomatis sebagai prasyarat. Alternatif /MT menghilangkan dependensi itu dengan harga yang sudah Anda kenal dari Chapter Static Linking vs Dynamic Linking: biner lebih besar dan patch keamanan runtime tidak ikut pembaruan sistem.

Penempatan DLL dan Pencarian Library #

Ketika aplikasi dinamis memuat DLL, Windows mencarinya dengan urutan yang tetap: pertama di direktori aplikasi tempat .exe berada, lalu direktori sistem (C:\Windows\System32), kemudian jalur PATH. Urutan ini memberi aturan praktis yang sederhana: letakkan DLL milik aplikasi di sebelah .exe-nya — mereka ditemukan lebih dulu dan tidak mencemari direktori sistem. Kebiasaan menyalin DLL ke System32 adalah sumber konflik versi antar aplikasi, persis dependency hell yang di Linux kita selesaikan dengan bundle $ORIGIN. Perhatikan juga dua perbedaan kosmetik yang sering menjebak skrip: pemisah jalur Windows adalah \ (tapi API dan std::filesystem menerima /), dan pemisah entri di PATH adalah titik koma ;, bukan titik dua.

Installer dan Aplikasi Portable #

Aplikasi Windows terdistribusi dalam dua wajah. Wajah pertama, installer — program yang menyalin berkas ke C:\Program Files\, membuat pintasan, dan mendaftar di Control Panel agar bisa dicopot bersih. Dua alat open source yang lazim: NSIS dengan skrip ringkasnya, dan WiX Toolset yang merakit installer standar MSI dari XML. Kerangka NSIS-nya hanya beberapa baris:

OutFile "SetupKalkulatorUnit.exe"
InstallDir "$PROGRAMFILES64\KalkulatorUnit"
File "konversi-unit.exe"
CreateShortcut "$SMPROGRAMS\KalkulatorUnit.lnk" "$INSTDIR\konversi-unit.exe"

Wajah kedua, aplikasi portable — folder atau arsip ZIP yang dijalankan tanpa instalasi sama sekali, padanan langsung dari tarball dan bundle Linux di chapter sebelumnya. Satu aturan pentingnya berkenaan dengan izin penulisan: folder C:\Program Files\ terlindungi UAC, sehingga aplikasi terpasang jangan menulis konfigurasi atau data di sebelah .exe-nya; tempat yang benar adalah profil pengguna (%APPDATA%\<nama-app>), dan std::filesystem bisa menyusun jalurnya secara portabel dari variabel lingkungan tersebut.

Code Signing Ringkas #

Installer dan .exe yang belum ditandatangani akan berhadapan dengan SmartScreen — peringatan “Windows protected your PC” yang membuat banyak pengguna berhenti. Solusinya sertifikat penandatanganan dari certificate authority, diterapkan dengan signtool yang menyertai Windows SDK:

signtool sign /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 SetupKalkulatorUnit.exe

Flag /fd memilih algoritma digest berkas, dan /tr menunjuk timestamp server — penting agar tanda tangan tetap sah setelah sertifikat kedaluwarsa, konsep yang sejajar dengan checksum yang bisa diverifikasi ulang pada release notes. Signing bukan formalitas: bagi pengguna itulah bukti bahwa berkas benar-benar berasal dari penerbit yang mereka kenal.

Checklist Rilis Windows #

• Source lolos uji portabilitas: standard library saja, std::filesystem untuk jalur, tanpa asumsi Linux.
• Build Release dengan MSVC (/MD plus vcredist sebagai prasyarat, atau /MT untuk portable).
• DLL aplikasi ditempatkan di sebelah .exe; tidak ada yang ditulis ke System32.
• Data pengguna ditulis ke %APPDATA%, bukan folder instalasi.
• Installer (NSIS/WiX) atau paket portable rapi; keduanya ditandatangani signtool.
• Uji di mesin bersih tanpa toolchain — runtime dependency yang terlupa baru terlihat di sana.

Dengan ini dua platform terbesar sudah kita lalui. Tinggal satu ekosistem dengan reputasi kerapian yang tinggi namun pintu masuknya paling ketat: macOS, dengan proses signing dan notarization yang akan kita bedah di chapter berikutnya.

Referensi: Latest supported VC++ Redistributable — Microsoft Learn , /MD, /MT, /LD — Microsoft Learn , Signtool — Microsoft Learn .