فهرست مطالب

پیش‌نیازها و مقدمات راه‌اندازی محیط توسعه ویندوز ۱۱

آیا سیستم‌عامل مایکروسافت توانسته جایگاه اصلی خود را در میان برنامه‌نویسان ارشد بازپس گیرد؟ پاسخ کوتاه و قاطع این است: با قابلیت‌های مدرن، ویندوز ۱۱ برای توسعه‌دهندگان به یکی از قدرتمندترین، منعطف‌ترین و سریع‌ترین محیط‌های مهندسی نرم‌افزار تبدیل شده است. سال‌ها بود که برنامه‌نویسان وب، موبایل و متخصصان DevOps به دلیل سازگاری بومی هسته یونیکس و معماری سریع فایل‌سیستم، لینوکس و macOS را ترجیح می‌دادند. توسعه‌دهندگان در شرکت‌های نرم‌افزاری تهران و پارک‌های فناوری همواره با چالش کندی شدید اجرای دستورات پکیج‌منیجرها مانند npm install و بیلد پروژه‌های سنگین در ساختار سنتی NTFS ویندوز روبه‌رو بودند.

مایکروسافت با معرفی ویندوز ۱۱ نسخه 23H2 و به‌روزرسانی‌های جدیدتر، سه فناوری زیرساختی شامل Dev Drive (مبتنی بر فایل‌سیستم Resilient File System یا ReFS)، نسخه بازطراحی‌شده WSL (Windows Subsystem for Linux) و پلتفرم متمرکز Dev Home را پیاده‌سازی کرد تا گلوگاه‌های عملکردی را حذف کند. اگر به دنبال پاسخ به این پرسش هستید که آیا ویندوز ۱۱ برای توسعه‌دهندگان مناسب است، این راهنما به صورت گام‌به‌گام تمام مسیر راه‌اندازی این قابلیت‌ها را در اختیار شما قرار می‌دهد.

چک‌لیست پیش‌نیازهای سیستمی و لایسنس

  • سیستم‌عامل: ویندوز ۱۱ نسخه 23H2 یا بالاتر (بیلد 22631 به بعد).
  • نسخه ویندوز: استفاده از لایسنس Windows 11 Pro یا Enterprise برای دسترسی بدون محدودیت به Hyper-V، سیاست‌های امنیتی و ReFS. لایسنس باید قانونی (Retail یا سازمانی Volume Licensing) باشد. نسخه‌های غیررسمی یا کرک‌شده به علت نقص در به‌روزرسانی‌های ماژولار کرنل ویندوز، در اجرای درایورهای WSL و Dev Drive دچار اختلال می‌شوند. (توجه: لایسنس‌های OEM فقط برای عرضه پیش‌نصب روی سخت‌افزار کارخانه‌ای است و برای ارتقای مستقل توصیه نمی‌شود).
  • سخت‌افزار: پردازنده با پشتیبانی از Virtualization (فعال در BIOS/UEFI)، حداقل ۱۶ گیگابایت حافظه رم (توصیه ۳۲ گیگابایت برای استقرار کانتینرها) و حافظه NVMe SSD با حداقل ۵۰ گیگابایت فضای خالی پارتیشن‌بندی نشده.
  • دسترسی: حساب کاربری Administrator در ویندوز.

💡 نکته کلیدی: ترکیب Dev Drive و WSL 2 تنها یک به‌روزرسانی ظاهری نیست، بلکه معماری ارتباط لایه‌های I/O حافظه و کرنل را دگرگون ساخته تا سرعت بیلد کدهای حجیم تا ۲.۵ برابر افزایش یابد.

گام ۱: آموزش فعال‌سازی Dev Drive در ویندوز ۱۱ و ایجاد درایو ReFS

بزرگ‌ترین جهش عملکردی سیستم‌عامل در سناریوهای فشرده کامپایل و واکشی وابستگی‌ها (مانند فولدرهای غول‌آسای node_modules، تارگت‌های Cargo در Rust و کش Gradle)، قابلیت Dev Drive است. این فناوری بر پایه سیستم فایل ReFS توسعه یافته و حالت اختصاصی Performance Mode در Microsoft Defender Antivirus به آن اختصاص یافته است تا از اسکن‌های سنکرون و قفل‌کننده جلوگیری کند.

هدف

ایجاد یک پارتیشن یا Virtual Hard Disk (VHDX) اختصاصی بر مبنای ReFS به منظور میزبانی کدها، پکیج‌ها و کش ابزارهای توسعه و دستیابی به افزایش سرعت بیلد در ویندوز ۱۱ با refs.

دستور دقیق و مراحل پیاده‌سازی

  1. کلیدهای ترکیبی Win + I را فشرده و به مسیر System > Storage > Advanced storage settings > Disks & volumes بروید.
  2. روی دکمه Create Dev Drive کلیک کنید.
  3. در پنجره باز شده، نوع درایو را انتخاب کنید. پیشنهاد می‌شود گزینه Create VHD را برگزینید تا بدون نیاز به دستکاری پارتیشن‌های اصلی، یک دیسک مجازی پرسرعت روی حافظه NVMe شما ساخته شود.
  4. مسیر ذخیره‌سازی فایل VHDX را روی سریع‌ترین درایو SSD خود مشخص کرده و اندازه آن را حداقل ۵۰ گیگابایت (Dynamic یا Fixed) تنظیم کنید.
  5. حرف درایو (مثلاً V:) و برچسب (Label) مانند DevDrive را تعیین کرده و نوع فرمت را روی ReFS قرار دهید و دکمه Format را بزنید.

همچنین می‌توانید این کار را مستقیماً از طریق PowerShell (Run as Administrator) با دستورات زیر پیاده کنید:

New-Vhd -Path "C:\DevDisks\DevDrive.vhdx" -SizeBytes 64GB -Dynamic
$disk = Mount-Vhd -Path "C:\DevDisks\DevDrive.vhdx" -Passthru | Initialize-Disk -PartitionStyle GPT -Passthru
$part = $disk | New-Partition -AssignDriveLetter -UseMaximumSize
Format-Volume -Partition $part -FileSystem ReFS -NewFileSystemLabel "DevDrive"

نتیجه مورد انتظار

یک درایو جدید با حرف اختصاص‌داده‌شده در This PC نمایان می‌شود که در بخش Settings ویندوز، برچسب Dev Drive با وضعیت Protected with Performance Mode را نشان می‌دهد.

رفع اشکال (Troubleshooting)

⚠️ خطا: گزینه Dev Drive خاکستری است یا خطای ReFS format not supported دریافت می‌کنید.
راه‌حل: اطمینان حاصل کنید که ویندوز ۱۱ بیلد 22631 یا بالاتر است و مقدار متغیر ثبتی رجیستری مربوط به ReFS دستکاری نشده باشد. همچنین در سیستم‌های شرکتی، ممکن است Group Policy سازمانی مانع از فرمت ReFS شده باشد؛ خط‌مشی Enable Dev Drive را در Local Group Policy Editor تحت مسیر Administrative Templates > System > Filesystem بررسی نمایید.

گام ۲: انتقال و پیکربندی متغیرهای محیطی و کش پکیج‌ها به Dev Drive

برای توسعه‌دهندگانی که از پلتفرم‌های متعددی مانند Node.js، پایتون، دات‌نت یا جاوا استفاده می‌کنند، هدایت کش پکیج‌منیجرها به Dev Drive تأثیر شگرفی در حذف I/O سربار درایو سیستم (درایو C) دارد.

هدف

تغییر مسیر فولدرهای ذخیره پکیج‌ها مانند npm، NuGet، Cargo و pip به Dev Drive تا تمام فرایندهای نصب پکیج با سرعت ReFS خوانده و نوشته شوند.

دستور دقیق و مراحل پیاده‌سازی

یک ترمینال PowerShell در حالت ادمین باز کنید و دستورات زیر را برای تعیین متغیرهای سیستمی و تنظیمات پکیج‌منیجرها وارد کنید (فرض بر این است که درایو توسعه شما V: است):

# ساخت دایرکتوری‌های کش روی Dev Drive
New-Item -ItemType Directory -Force -Path "V:\Packages\npm-cache"
New-Item -ItemType Directory -Force -Path "V:\Packages\nuget-cache"
New-Item -ItemType Directory -Force -Path "V:\Packages\cargo-cache"

# هدایت کش npm
npm config set cache "V:\Packages\npm-cache" --global

# تنظیم متغیرهای محیطی سیستم برای Cargo و NuGet
[Environment]::SetEnvironmentVariable("NUGET_PACKAGES", "V:\Packages\nuget-cache", "User")
[Environment]::SetEnvironmentVariable("CARGO_HOME", "V:\Packages\cargo-cache", "User")
[Environment]::SetEnvironmentVariable("PIP_CACHE_DIR", "V:\Packages\pip-cache", "User")

نتیجه مورد انتظار

با اجرای دستور npm config get cache مقدار V:\Packages\npm-cache چاپ می‌شود و از این پس بسته‌های دانلود شده در سراسر سیستم، بدون مسدود شدن توسط Defender روی ReFS ذخیره می‌گردند.

رفع اشکال (Troubleshooting)

⚠️ خطا: پس از تغییر مسیر کش، خطای EACCES: permission denied در ابزارهایی نظیر npm ظاهر می‌شود.
راه‌حل: دسترسی مالکیت دایرکتوری روی Dev Drive را با اجرای icacls "V:\Packages" /grant "$($env:USERNAME):(OI)(CI)F" /T به کاربر جاری واگذار کنید.

گام ۳: پیاده‌سازی و استقرار WSL 2 بهینه‌سازی‌شده برای توسعه مدرن

سنگ بنای تبدیل شدن ویندوز ۱۱ به یک ایستگاه مهندسی حرفه‌ای، Windows Subsystem for Linux نسخه ۲ است. این معماری دیگر یک شبیه‌ساز نیست، بلکه یک کرنل کامل لینوکس سبک (Lightweight Utility VM) به همراه دارد که در کسری از ثانیه بارگذاری می‌شود.

هدف

نصب، استقرار و کانفیگ پایه‌ای WSL 2 با توزیع پیش‌فرض Ubuntu و به‌روزرسانی هسته کرنل به آخرین نسخه بدون اختلال با Hyper-V.

دستور دقیق و مراحل پیاده‌سازی

  1. ترمینال ویندوز (Windows Terminal) را با دسترسی Administrator اجرا کنید.
  2. دستور تک‌خطی مدرن زیر را وارد کنید تا تمام مؤلفه‌های پلتفرم ماشین مجازی و کرنل به صورت خودکار دانلود و فعال شوند: 
    wsl --install -d Ubuntu-24.04
  3. سیستم را ریستارت کنید.
  4. پس از راه‌اندازی مجدد، پنجره کنسول اوبونتو باز می‌شود؛ یک نام کاربری (Username) و رمز عبور (Password) اختصاص دهید.
  5. با دستور زیر وضعیت WSL را ارزیابی و نسخه آن را روی ۲ تثبیت نمایید: 
    wsl --status
wsl --set-default-version 2

نتیجه مورد انتظار

اجرای دستور wsl -l -v باید نسخه 2 را در ستون Version در کنار نام Ubuntu-24.04 با وضعیت Running یا Stopped نشان دهد.

رفع اشکال (Troubleshooting)

⚠️ خطا: خطای WslRegisterDistribution failed with error: 0x80370102 نمایش داده می‌شود.
راه‌حل: قابلیت مجازی‌سازی پردازنده (Intel VT-x یا AMD-V) در بایوس مادربرد سیستم شما غیرفعال است. سیستم را ریستارت کرده و از تنظیمات BIOS/UEFI، گزینه Virtualization Technology و SVM Support را فعال کنید.

گام ۴: اعمال تنظیمات فوق‌پیشرفته .wslconfig (Mirrored Networking و Memory Reclaim)

یکی از دغدغه‌های همیشگی برنامه‌نویسان در نسخه‌های اولیه WSL، مصرف مهارنشدنی رم (Vmmem) و مشکلات پیچیده تداخل پورت‌های شبکه داخلی بود. در ویندوز ۱۱، فایل کانفیگ .wslconfig جهش خیره‌کننده‌ای یافته است.

هدف

اعمال تنظیمات پیشرفته wsl 2 برای توسعه دهندگان جهت آزادسازی خودکار رم بی‌استفاده، آینه‌سازی شبکه (Mirrored Mode) و یکسان‌سازی پورت‌های لوکال‌هاست میان ویندوز و لینوکس.

دستور دقیق و مراحل پیاده‌سازی

  1. در ویندوز، کلیدهای Win + R را زده و عبارت notepad %UserProfile%\.wslconfig را تایپ کنید تا فایل کانفیگ اختصاصی باز شود.
  2. محتویات بهینه‌شده و فوق‌العاده حیاتی زیر را در فایل کپی و ذخیره کنید: 
    [wsl2]
# محدود کردن سقف حافظه رم به نصف ظرفیت کل سیستم (مثلاً برای سیستم 16 گیگابایتی)
memory=8GB
# اختصاص هسته‌های منطقی پردازنده
processors=4
# قابلیت بازپس‌گیری خودکار رم اشغال‌شده در لینوکس به حافظه ویندوز
autoMemoryReclaim=gradual

[experimental]
# اتصال مستقیم شبکه؛ لینوکس از IP کارت شبکه ویندوز استفاده می‌کند و پورت‌ها به طور کامل همگام می‌شوند
networkingMode=mirrored
# همگام‌سازی ترافیک DNS
dnsTunneling=true
# پشتیبانی خودکار از فایروال ویندوز برای پورت‌های باز شده در لینوکس
firewall=true
# بهینه‌سازی کپی ترافیک شبکه لوکال
autoProxy=true
  3. جهت اعمال این تنظیمات، تمام نمونه‌های در حال اجرای WSL را ریستارت کنید: 
    wsl --shutdown
    سپس مجدداً WSL را با اجرای دستور wsl در ترمینال فراخوانی نمایید.

نتیجه مورد انتظار

هنگامی که یک سرور تحت Node.js، Go یا کانتینر داکر را روی پورت 3000 در اوبونتو ران می‌کنید، بدون نیاز به دانستن IP داخلی WSL، مستقیماً از طریق مرورگر ویندوز در آدرس http://localhost:3000 یا هر کلاینت دیگر در شبکه محلی لایسنس‌شده، سرویس در دسترس خواهد بود.

رفع اشکال (Troubleshooting)

⚠️ خطا: پس از اعمال networkingMode=mirrored دسترسی اینترنت WSL قطع می‌شود.
راه‌حل: در صورتی که از VPNهای سازمانی شرکتی یا ابزارهای تانلینگ استفاده می‌کنید، گزینه dnsTunneling=false را قرار دهید تا تداخل کارت‌های شبکه مجازی برطرف شود.

گام ۵: راه‌اندازی و سفارشی‌سازی ابزار Dev Home مایکروسافت

مایکروسافت برای ایجاد یک مرکز فرماندهی منسجم، ابزار متن‌باز Dev Home را در ویندوز ۱۱ تعبیه کرده است. این پلتفرم جایگزین سردرگمی میان داشبوردهای مختلف شده و قابلیت اتصال عمیق به مخازن GitHub و رصد سخت‌افزاری پردازش‌ها را ممکن می‌سازد.

هدف

راه‌اندازی داشبورد یکپارچه، پایش زنده کارایی سخت‌افزار در حین کامپایل و فراخوانی مخازن کدهای گیت با استفاده از ویژگی‌های کار با dev home در ویندوز ۱۱.

دستور دقیق و مراحل پیاده‌سازی

  1. در صورتی که Dev Home به صورت پیش‌فرض نصب نیست، آن را از طریق ترمینال و با پکیج منیجر ویندوز نصب کنید: 
    winget install --id Microsoft.DevHome -e
  2. برنامه Dev Home را از منوی Start اجرا کنید.
  3. به بخش Machine configuration رفته و روی Clone repositories کلیک کنید. با متصل کردن اکانت GitHub یا Azure DevOps خود، مخازن مورد نظر را انتخاب و دایرکتوری مقصد را روی درایو ReFS (مثلاً V:\Repositories\ProjectA) تعیین کنید.
  4. به برگه Dashboard بروید؛ روی Add widget کلیک کرده و ویجت‌های حیاتی CPU Usage، GPU، Memory، Network و ویجت اختصاصی GitHub Issues را به صفحه مانیتورینگ خود اضافه کنید.

نتیجه مورد انتظار

یک داشبورد عملیاتی همواره در دسترس خواهید داشت که جهش‌های ناگهانی پردازنده، میزان فشار رم در زمان بیلدهای سنگین Maven یا Webpack و تغییرات کدهای ریپازیتوری را بدون باز کردن ابزارهای متفرقه نمایش می‌دهد.

رفع اشکال (Troubleshooting)

⚠️ خطا: ویجت‌های Dev Home بارگذاری نشده و صفحه سفید باقی می‌ماند.
راه‌حل: از بخش Microsoft Store اطمینان حاصل کنید که پکیج Windows Web Experience Pack به آخرین نسخه ارتقا یافته است؛ زیرساخت ویجت‌های ویندوز ۱۱ به این کامپوننت وابسته است.

گام ۶: خودکارسازی نصب پشته توسعه با فایلهای Dev Home Machine Configuration

راه‌اندازی دستی ابزارهای توسعه، کامپایلرها، فونت‌های کدنویسی و SDKها ساعت‌ها زمان می‌برد. ترکیب Dev Home با فایل‌های پیکربندی ابزار Winget (مبتنی بر استانداردهای DSC) این فرآیند را به یک عملیات تک‌کلیکه تبدیل می‌کند.

هدف

نصب خودکار کلیه نیازمندی‌ها شامل VS Code، Git، Node.js، Docker Desktop و فونت‌های برنامه‌نویسی نظیر Cascadia Code با کانفیگ زیرساخت به عنوان کد (Infrastructure as Code).

دستور دقیق و مراحل پیاده‌سازی

  1. یک فایل متنی با نام configuration.dsc.yaml بر روی دسکتاپ ایجاد کرده و ساختار زیر را در آن قرار دهید: 
    # yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2
properties:
  resources:
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: vscode
      directives:
        description: Install VS Code
        allowPrerelease: false
      settings:
        id: Microsoft.VisualStudioCode
        source: winget
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: git
      directives:
        description: Install Git CLI
      settings:
        id: Git.Git
        source: winget
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: terminal
      directives:
        description: Install Windows Terminal
      settings:
        id: Microsoft.WindowsTerminal
        source: winget
    - resource: Microsoft.WinGet.DSC/WinGetPackage
      id: node
      directives:
        description: Install Node.js LTS
      settings:
        id: OpenJS.NodeJS.LTS
        source: winget
  configurationVersion: 0.2.0
  2. در نرم‌افزار Dev Home، به بخش Machine Configuration رفته و گزینه Configuration file را انتخاب کنید.
  3. فایل YAML بالا را انتخاب کرده و روی Set up کلیک کنید. سیستم‌عامل تمامی پکیج‌های تایید شده را بدون مداخله کاربر و به شکلی استاندارد دانلود و رجیستر می‌نماید.

نتیجه مورد انتظار

کلیه نرم‌افزارهای تعریف‌شده بدون تداخل با پث‌های متفرقه نصب شده و محیط توسعه آماده پذیرش اولین کامیت‌ها خواهد بود.

رفع اشکال (Troubleshooting)

⚠️ خطا: پیام DSC module execution is disabled on this system صادر می‌شود.
راه‌حل: در یک ترمینال PowerShell ادمین، دستور Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine را وارد کنید تا اجازه اجرای اسکریپت‌های معتبر پیکربندی اعطا شود.

گام ۷: اتصال Visual Studio Code و Docker Desktop به معماری WSL و Dev Drive

برای توسعه‌دهندگانی که بر پروژه‌های کراس‌پلتفرم، میکروفرانت‌اند، هوش مصنوعی یا توسعه بک‌اند تحت لینوکس کار می‌کنند، ادغام بی‌نقص ادیتور ویندوزی VS Code با فایل‌های مستقر در WSL امری الزامی است.

هدف

اجرای بدون اصطکاک کدهای موجود در ریشه فایل‌سیستم لینوکس یا Dev Drive توسط رابط بصری VS Code در ویندوز ۱۱ با فعال‌سازی کامل امکانات هوشمند Intellisense و دیباگینگ کرنل.

دستور دقیق و مراحل پیاده‌سازی

  1. نرم‌افزار VS Code را در ویندوز ۱۱ باز کنید.
  2. از بخش افزونه‌ها (کلیدهای Ctrl + Shift + X)، افزونه رسمی WSL (توسعه‌داده شده توسط Microsoft) را نصب کنید.
  3. ترمینال لینوکس اوبونتو (WSL) را باز کنید و وارد پوشه پروژه خود شوید: 
    cd ~/projects/my-enterprise-app
  4. دستور جادویی زیر را وارد کنید: 
    code .

نتیجه مورد انتظار

کلاینت VS Code ویندوز بلافاصله فعال شده و در گوشه پایین سمت چپ آن برچسب WSL: Ubuntu-24.04 به رنگ سبز یا آبی ظاهر می‌شود. افزونه‌ها مستقیماً درون کانتینر سبک لینوکس اجرا می‌شوند، در حالی که رندرینگ گرافیکی روی پردازنده گرافیکی سیستم میزبان ویندوز ۱۱ صورت می‌گیرد.

رفع اشکال (Troubleshooting)

⚠️ خطا: دستور code . در خط فرمان لینوکس پیام command not found می‌دهد.
راه‌حل: در ویندوز، VS Code را باز کرده، کلیدهای Ctrl + Shift + P را فشرده و عبارت Shell Command: Install 'code' command in PATH را سرچ و اجرا کنید، سپس یک‌بار WSL را مجدداً باز نمایید.

تأیید نهایی، سنجش بنچ‌مارک سرعت و مانیتورینگ سیستم

پس از اجرای کلیه گام‌های پیکربندی و اتمام استقرار ابزارها، اکنون زمان آن فرا رسیده است که صحت عملکرد یکپارچه اکوسیستم توسعه را در عمل بسنجید و تفاوت بنیادین ویندوز ۱۱ پرو در برابر ویندوز ۱۰ برای توسعه را ارزیابی نمایید.

آزمون‌های سنجش کارکرد صحیح (Validation Tests)

  1. تست عملکرد Dev Drive:

    ترمینال را در شاخه یکی از پروژه‌های Dev Drive باز کنید و دستور زیر را برای بررسی فایل‌سیستم ثبت نمایید:

    fsutil fsinfo volumeinfo V:

    در خروجی این دستور، مقدار فیلد File System Name حتماً باید ReFS باشد. همچنین شاخص Dev Drive: Yes تایید می‌نماید که حالت بهینه‌سازی آنتی‌ویروس در وضعیت پایدار قرار دارد.

  2. تست سرعت کامپایل و I/O:

    یک ریپازیتوری تستی سنگین (مثلاً یک برنامه Next.js یا کلون NestJS) را در دو مسیر مختلف کلون کنید: یکی روی مسیر سنتی C:\Projects (تحت NTFS) و دیگری روی V:\Projects (تحت Dev Drive با ReFS). اجرای دستور Measure-Command { npm install } روی هر دو پوشه را مقایسه کنید؛ در Dev Drive کاهش زمان بین ۳۰ الی ۶۰ درصد به دلیل مهار اسکن فیلتردرایورها مشهود خواهد بود.

  3. تست همگام‌سازی شبکه آینه‌ای WSL:

    در محیط WSL دستور ساده زیر را برای اجرای یک وب‌سرور پایتون اجرا کنید:

    python3 -m http.server 8080

    سپس در مرورگر ویندوز آدرس http://localhost:8080 را باز کنید. صفحه وب‌سرور باید بلافاصله بدون هیچ‌گونه عملیات port-forwarding بارگذاری شود.

✅ نتیجه‌گیری فنی: با استقرار معماری‌های WSL 2، سیستم فایل ReFS در Dev Drive و یکپارچگی ارائه‌شده توسط Dev Home، ویندوز ۱۱ دیگر یک واسط ناپایدار میان ابزارهای متن‌باز و سیستم‌عامل اختصاصی نیست، بلکه یک بنچ‌مارک استاندارد جهانی و پرسرعت برای مهندسی نرم‌افزار محسوب می‌شود. تهیه لایسنس معتبر و پایدار Pro یا Enterprise این اطمینان را به شرکت‌های نرم‌افزاری و برنامه‌نویسان می‌دهد که محیطی بدون خطای هسته و همواره به‌روز را تجربه کنند.

📊 جدول مقایسه

ویژگی و ابزار ویندوز ۱۰ قدیمی ویندوز ۱۱ بدون پیکربندی تخصصی ویندوز ۱۱ بهینه‌شده (WSL + Dev Drive + Dev Home)
فایل‌سیستم توسعه NTFS با ردیابی سنگین فیلتر درایورها NTFS معمولی و سربار Windows Defender ReFS Dev Drive با کش مجزا و کاهش محسوس I/O
محیط لینوکس (WSL) WSL 1/2 اولیه با مدیریت دستی رم WSL 2 استاندارد با مصرف حافظه شناور WSL 2 پیشرفته (آینه‌سازی شبکه، Reclaim خودکار رم و پشتیبانی از GUI)
نصب وابستگی‌ها و SDK دانلود دستی یا اسکریپت‌های متفرقه Winget اولیه خط فرمان Dev Home Machine Configuration و فایل‌های خودکار .winget
پایش سخت‌افزار در حین بیلد Task Manager ساده و گیج‌کننده Game Bar یا ابزارهای مانیتورینگ جانبی Dev Home Widgets متصل به عملکرد هسته‌های CPU، رم و گیت
مجوز و لایسنس پیشنهادی Pro Retail / Volume Home / کرک‌شده (پرخطر) Windows 11 Pro / Enterprise (Retail یا VL) جهت دسترسی کامل به قابلیت‌های مجازی‌سازی

❓ سوالات متداول

آیا امکان ساخت Dev Drive روی ویندوز ۱۰ نیز وجود دارد؟
خیر؛ قابلیت Dev Drive مبتنی بر فایل‌سیستم ReFS تنها در ویندوز ۱۱ (نسخه 23H2 به بعد) عرضه شده است. همچنین ویژگی‌های معماری جدید WSL مانند Network Mirroring و آزادسازی خودکار رم، منحصراً برای هسته ویندوز ۱۱ بهینه‌سازی شده‌اند.
چرا سرعت اجرای دستورات npm و کامپایل در WSL گاهی کند می‌شود؟
به هیچ عنوان کدهای سورس و node_modules پروژه را روی درایو ویندوزی (مانند /mnt/c/) قرار ندهید؛ زیرا ترجمه فایل‌سیستم میان NTFS و لینوکس سربار شدیدی دارد. پروژه‌های خود را مستقیماً در ریشه لینوکس (مانند ~/projects) یا داخل یک Dev Drive فرمت‌شده با ReFS نگه دارید تا حداکثر کارایی I/O حاصل شود.
کدام نسخه و نوع لایسنس ویندوز ۱۱ برای برنامه‌نویسان و شرکت‌های نرم‌افزاری مناسب است؟
برای شرکت‌ها و تیم‌های نرم‌افزاری در ایران، لایسنس ویندوز ۱۱ پرو از نوع Retail (خرده‌فروشی معتبر) یا Volume Licensing سازمانی توصیه می‌شود. از خرید لایسنس‌های موسوم به OEM برای سیستم‌های موجود خودداری کنید؛ زیرا طبق قوانین مایکروسافت، OEM تنها به تولیدکنندگان سخت‌افزار تعلق دارد و قابلیت جابه‌جایی یا پشتیبانی مستقل سازمانی ندارد. همچنین نسخه‌های کرک‌شده با دستکاری سرویس‌های امنیتی و Hyper-V مانع از کارکرد پایدار WSL می‌شوند.
آیا Dev Drive امنیت سیستم را در برابر بدافزارها کاهش می‌دهد؟
بله؛ قابلیت Dev Drive با هماهنگی کامل آنتی‌ویروس Microsoft Defender عمل می‌کند. حالت «Performance Mode» به این معنی نیست که فایل‌ها اسکن نمی‌شوند، بلکه بررسی‌های بلادرنگ با استفاده از فیلترهای سبک‌تر و اسکن‌های ناهمگام (Asynchronous) انجام می‌گیرد تا عملیات فشرده I/O متوقف نشود، در حالی که امنیت سیستم کاملاً حفظ می‌گردد.
آیا Dev Home می‌تواند جایگزین Docker Desktop شود؟
خیر؛ Dev Home یک ابزار مدیریت محیط توسعه، پایش سخت‌افزار، ساخت Dev Drive و اتصال به مخازن گیت‌هاب است. در حالی که داکر دسکتاپ بر مدیریت کانتینرها تمرکز دارد. این دو ابزار در کنار یکدیگر کار می‌کنند و با Dev Home می‌توانید عملکرد کانتینرهای خود را نیز در یک داشبورد یکپارچه نظارت کنید.