Подсистема для запуска unix приложений windows 7

Использование Linux- или UNIX-приложений в Windows может быть продиктовано массой причин — от банальной привычки к некоторым программам до невозможности запуска отдельной машины с Linux. Кто-то хочет использовать нативные версии ПО для отладки, а кто-то надеется, что таким способом можно заставить пользователей плавно смигрировать на полноценный дистрибутив.

Прежде чем городить огород с эмуляторами, лучше поищите портированные версии или аналоги ваших любимых программ. Те же GIMP, Audacity, Pidgin и множество других утилит имеют родные сборки не только для Windows, но и для Mac OS X. Для получения какой-то конкретной функциональности зачастую не требуется полноценный аналог софта из Linux. Например, к автодополнению по Tab в оболочке bash привыкаешь очень быстро, а в командной строке Windows этого нет и в помине. Исправить это и другие досадные упущения поможет утилита clink.

Стандартные консольные утилиты, например из пакета GNU Coreutils, давно спортированы на Windows. Есть как довольно старые наборы GNUWin II и UnxUtils, так и постоянно обновляющиеся UWIN (не рекомендуется к использованию) и Gnuwin32. Для последнего по завершении установки базового инсталлятора надо последовательно запустить файлы download.bat и install.bat, а затем скопировать по желанию папку gnuwin32 в любое удобное место и запустить из неё файл update-links.bat. После отработки последнего скрипта в подкаталоге StartMenu будут ссылки на запуск командной строки с окружением GNU и документацию к утилитам.

Обладатели Windows Vista/7 в максимальной и корпоративной версиях, а также серверных версий ОС Microsoft могут вообще не заморачиваться. Для них доступна подсистема для приложений на базе UNIX (Subsystem for UNIX-based Applications, SUA) или сервисы Microsoft Windows для UNIX (Microsoft Windows Services for UNIX, SFU). Этот набор базовых утилит наличествует прямо в компонентах системы. Дополнительные наборы программ можно скачать здесь. Наконец, последнее в списке и первое по популярности решение для запуска UNIX-программ — это Cygwin. Этот пакет прост в установке и содержит далеко не маленький набор приложений, портированных под Windows. Рекомендуется использовать именно его.

Теперь можно поговорить о странном — запуске неродной для Windows системы KDE. Вообще-то проект KDE on Windows существует не первый год, и поначалу пользоваться им было просто невозможно из-за регулярных падений, которые разве что не загоняли несчастную систему в BSOD. Однако разработчики не сидели сложа руки, и в нынешней реинкарнации проекта его можно смело инсталлировать — ошибки довольно редки, да и те — некритичные. Всё сразу ставить смысла, наверное, нет, а вот некоторые приложения могут приглянуться.

К сожалению, портированные приложения далеко не всегда ведут себя так, как в родном окружении, или могут конфликтовать с другими программами. Поэтому единственным выходом, помимо установки «пингвиньей» ОС на голое железо, является эмулирование Linux. Для разового использования можно применить оболочку для QEMU под названием MobaLiveCD, которая без лишних телодвижений поможет запустить LiveCD/USB с различными дистрибутивами. Для постоянного использования лучше инсталлировать Linux в виртуальную машину: в VirtualBox или VMWare Player. Только не забудьте установить гостевые дополнения для более комфортной работы. Альтернативный вариант — применение VDI-решений с возможностью бесшовной интеграции в Windows Linux-приложений, запущенных на отдельном хосте, который также может быть виртуализирован.

Оптимальным вариантом для запуска Linux-приложений является использование среды coLinux. Она, условно говоря, запускает ядро Linux на уровне ядра Windows и имеет доступ ко всем аппаратным ресурсам машины, за счёт чего потерь производительности практически нет. При этом она сохраняет полную совместимость с Linux-приложениями, позволяя напрямую запускать их. На базе coLinux имеются готовые системы для быстрого запуска Portable Ubuntu Remix, Topologilinux (Slackware), SpeedLinux (различные дистрибутивы) и andLinux (Ubuntu). Единственным неприятным ограничением coLinux и всех пакетов на его основе является необходимость использования 32-битной версии Windows 2k/XP/2k3/Vista/7. В качестве примера разберём минимальную настройку Debian Squeeze. Первым делом установим свежую версию coLinux, отказавшись от загрузки готовых образов и попутно инсталлировав WinPcap.

Теперь необходимо скачать архив образа диска с Debian и распаковать его в ту папку, в которую был установлен coLinux. Размер диска rootfs_2gb.img при желании можно увеличить. Файл squeeze.conf придётся немного отредактировать. Изменений минимум — увеличить объём выделяемой RAM (mem), разрешить доступ к диску C: посредством COFS и добавить сетевой интерфейс TAP. Обратите внимание, что при использовании COFS лучше не обращаться одновременно к одним и тем же файлам с папками из Linux и Windows.

kernel=vmlinux
cobd0="rootfs_2gb.img"
cobd1="swap_128mb.img"
root=/dev/cobd0
ro
cofs0="C:"
initrd=initrd.gz
mem=512
eth0=slirp
eth1=tuntap

После запуска squeeze.bat вы попадёте в консоль Debian. Логин по умолчанию root, а пароля нет. С помощью nano отредактируем параметры сетевых интерфейсов в файле /etc/network/interfaces. Добавим секцию для eth1. В качестве IP-адреса используем любой, лишь бы не было пересечения с другими локальными подсетями. В Windows в настройках IPv4 сетевого адаптера TAP-Win32 Adapter V8 (coLinux) надо указать адрес из той же подсети.

auto eth1
iface eth1 inet static
address 192.168.100.2
netmask 255.255.255.0

Выходим из nano с сохранением изменений — F2, Y, Enter. Теперь создадим папку, куда будет монтироваться диск C:…

mkdir /mnt/windrvc 

…добавим одну строчку в конец файла /etc/fstab и сохраним его:

/dev/cofs0	/mnt/windrvc	cofs	defaults	0	0

Сейчас мы займёмся установкой X-сервера, а пока для простоты пропишем экспорт переменной DISPLAY в файл ~/.profile (это надо будет сделать и для любых других пользователей). В качестве IP-адреса используйте тот, что указан для TAP-адаптера в Windows. После этого можно перезагрузиться командой reboot.

export DISPLAY=192.168.100.1:0 

Нелишней будет установка набора шрифтов, в том числе и кириллических. Опционально можно пройтись по каталогам со шрифтами, включая C:WindowsFonts, утилитами mkfontdir и mkfontscale из состава Cygwin. Теперь всё готово для установки X-сервера Xming. Сразу же после этой процедуры добавляем в файл X0.hosts IP-адрес TAP-интерфейса в Debian (в нашем примере это 192.168.100.2).

«Поблагодарим» Windows за бдительность и в стандартном брандмауэре поменяем все правила, касающиеся Xming, с запрещающих на разрешающие, а иначе программы просто не достучатся до X-сервера. Теперь запускаем утилиту XLaunch, в которой можно выбрать режим отображения X-окон и задать дополнительные параметры. Для нас важно настроить поддержку русской и английской раскладок с переключением по Alt+Shift и опционально задать DPI. В конце файл настроек надо сохранить как имя.xlaunch. В дальнейшем по двойному клику по этому файлу X-сервер будет запускаться с заданными нами параметрами.

-xkblayout us,ru -xkbvariant basic,winkeys -xkboptions grp:alt_shift_toggle –dpi 96

Чтобы не было так скучно, установим графический менеджер пакетов synaptic для более удобной инсталляции софта и какую-нибудь легковесную панель с меню приложений, например lxpanel. Последнюю для простоты пропишем в автозапуск при входе, добавив в конец ~/.profile команду lxpanel&.

apt-get update
apt-get upgrade
apt-get install synaptic lxpanel

Для полноты картины добавим поддержку звука. Скачиваем отсюда архив с Pulseadio и распаковываем его в какой-нибудь каталог, в котором создаём текстовый файл default.pa. Наполняем этот файл нижеследующими строками. Здесь 192.168.100.0/24 — это наша TAP-подсеть.

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.100.0/24
load-module module-esound-protocol-tcp auth-ip-acl=127.0.0.1;192.168.100.0/24
load-module module-detect 
add-autoload-sink output module-waveout sink_name=output 
set-default-sink output

Запускаем pulseaudio.exe и в очередной раз идём править разрешения в брандмауэре Windows. В консоли Debian устанавливаем необходимые утилиты и библиотеки.

apt-get install libpulse0 libasound2-plugins alsa-utils

В файле /etc/pulse/client.conf добавляем IP-адрес хост-машины с запущенным сервером Pulseaudio — default-server = 192.168.100.1, а в /etc/asound.conf следующие параметры:

pcm.!default {type pulse}
ctl.!default {type pulse}
pcm.pulse {type pulse}
ctl.pulse {type pulse}

Для проверки работоспособности можно попробовать проиграть один из тестовых файлов.

aplay /usr/share/sounds/alsa/Front_Center.wav 

Автоматический запуск Pulseaudio при старте Debian осуществляется добавлением в конец файла конфигурации squeeze.conf такой команды.

exec0="X:путьдопапкиpulseaudiopulseaudio.exe"

Для X-сервера такой трюк не подходит. В принципе, того, что уже сделано, достаточно для работы. Однако неплохо было бы добавить в Linux нового не-root пользователя, настроить для него автологин с mingetty, установить coLinux в качестве службы Windows и прописать Xming в автозапуск. Для удобства можно поставить утилиту Desktops, которая создаёт несколько виртуальных рабочих столов в Windows, и запускать X-сервер в полноэкранном режиме на втором рабочем столе.

В итоге мы получили быструю среду для почти что нативного запуска Linux-приложений в Windows. Её можно использовать для написания и отладки веб-приложений, кросскомпиляции драйверов и прочих задач. Вот только вменяемого ускорения графики для работы тяжёлых приложений пока ещё нет, да 64-битная версия начала разрабатываться всего несколько месяцев назад. Тем не менее coLinux вполне пригоден для повседневного использования. Для дальнейшего изучения возможностей и настроек этой системы обратитесь к вики проекта. Ну а мы на этом пока что закроем тему симбиотических отношений Windows с Linux через разные места. Удачи!

Everyone says, that Linux subsystem,or WSL, IS only supported in windows 10.

Everyone is absolutely correct. Windows Linux Subsystem does not exist and cannot be enabled/installed on Windows 7.

Subsystem for UNIX-based Applications has nothing to do with the Windows 10 feature. It was also known as Interix before it was discontinued with the release of Windows 10.

Interix was an optional, POSIX-conformant Unix subsystem for Windows NT operating systems. Interix was a component of Windows Services for UNIX, and a superset of the Microsoft POSIX subsystem.

The tools that were supported were recompiled versions. The tools contained within a WSL instance are the same tools that run on Linux.

Unlike in the past the actual Linux distribution, is compiled into a UWP application, which interfaces with the Linux Subsystem allowing virtually any Linux distribution to now be compatible.

We distribute Linux distros for WSL as UWP applications through the Microsoft Store. You can install those applications that will then run on WSL — the subsystem that sits in the Windows kernel. This delivery mechanism has many benefits as discussed in an earlier blog post.

Source: Creating a Custom Linux Distro for WSL

There is an inherited limitation dealing with Linux kernel level drivers (they are not supported) so
all devices interface indirectly with the Windows device driver.

Source: Interix

Everyone says, that Linux subsystem,or WSL, IS only supported in windows 10.

Everyone is absolutely correct. Windows Linux Subsystem does not exist and cannot be enabled/installed on Windows 7.

Subsystem for UNIX-based Applications has nothing to do with the Windows 10 feature. It was also known as Interix before it was discontinued with the release of Windows 10.

Interix was an optional, POSIX-conformant Unix subsystem for Windows NT operating systems. Interix was a component of Windows Services for UNIX, and a superset of the Microsoft POSIX subsystem.

The tools that were supported were recompiled versions. The tools contained within a WSL instance are the same tools that run on Linux.

Unlike in the past the actual Linux distribution, is compiled into a UWP application, which interfaces with the Linux Subsystem allowing virtually any Linux distribution to now be compatible.

We distribute Linux distros for WSL as UWP applications through the Microsoft Store. You can install those applications that will then run on WSL — the subsystem that sits in the Windows kernel. This delivery mechanism has many benefits as discussed in an earlier blog post.

Source: Creating a Custom Linux Distro for WSL

There is an inherited limitation dealing with Linux kernel level drivers (they are not supported) so
all devices interface indirectly with the Windows device driver.

Source: Interix

Как настроить полноценное окружение разработчика, привыкшего к Linux и Mac OS X.

Традиционно считается, что разработчики (в особенности связанные с бэкенд-разработкой) предпочитают использовать unix-like-системы. Причиной тому было немало. Ситуация начала несколько меняться в 2017 году — именно тогда вышел первый стабильный релиз Windows Subsystem for Linux (также известен под более ранним названием BashOnWindows), который дал разработчикам то, чего они так давно ждали, — полноценный Linux в качестве приложения в Windows!

Но не всё оказалось так просто — лишь к концу 2018 года WSL стало возможно использовать полноценно, при этом способ отнюдь не очевиден. О нём и пойдёт речь.

Конечная цель

Для начала пара слов о том, что такое вообще Windows Subsystem for Linux, он же WSL в сокращённом варианте. Это прослойка между ядром Windows и приложениями для Linux, которая позволяет преобразовывать системные вызовы к ядру Linux в вызовы к ядру Windows. Благодаря тому, что виртуализация практически отсутствует, такое решение работает быстрее традиционной виртуализации, где эмулируется целый компьютер, как это происходит в Oracle VirtualBox и VMWare Player.

Кроме того, WSL включает в себя целый ряд утилит для интеграции с Windows — пути в файловой системе автоматически преобразовываются в нужный формат, из-под Linux можно запускать приложения в Windows (но не наоборот!), Linux в WSL имеет доступ ко всем портам и сервисам в Windows.

Для разработчика основное применение WSL сразу же видится в развёртывании среды разработки именно там. Всё же установка многих языков, компиляторов и интерпретаторов, утилит происходит в Linux куда проще — часто одной командой из репозитория. Да и привычная консоль под рукой.

В статье будет рассматриваться именно настройка среды разработки в WSL — для примера возьмём небольшой проект, написанный на Python/Angular/Go (а почему бы и нет?), разрабатываемый в Visual Studio Code. Однако описанные рекомендации в целом подойдут для любого другого редактора или IDE.

Установка для Windows 10 x64

Важный момент: WSL официально поддерживается только в Windows 10 x64, начиная с Anniversary Update. Если у вас иная версия — альтернативное решение представлено в следующем разделе.

При первом запуске необходимо задать ваши логин и пароль.

Далее уже вам откроется консоль с Ubuntu.

Установка для 32-битных редакций Windows 10 и Windows 7, 8 и 8.1

К сожалению, на этих редакциях WSL не поддерживается. Но мы можем без особого труда заменить его Vagrant — мощной утилитой для конфигурирования виртуальных машин. Vagrant работает поверх других сред виртуализации: VirtualBox, VMWare Player или Microsoft Hyper-V. Поэтому стоит понимать, что такой вариант будет по умолчанию медленнее, нежели WSL. А в случае с VirtualBox значительно медленнее из-за файловой системы vboxsf.

Установить Vagrant можно с официального сайта. Также вам потребуется VirtualBox и Git. После этого создайте папку для вашей виртуальной машины, в ней создайте файл Vagrantfile со следующим содержимым:

После чего в том же PowerShell или cmd выполните команду:

После загрузки, настройки и запуска виртуальной машины вы попадёте в консоль Linux. Ура!

Устанавливаем всякие скучные вещи

Разворачиваем наше окружение под Python/JS/Go.

Быстро проверяем работоспособность версий и, собственно, версии:

Неужели всё уже работает?

Конечно нет.

Сразу стоит отметить важный факт: ни Visual Studio Code, ни Sublime Text, ни даже ваша любимая IDE ничего не знают о существовании WSL. Из коробки более-менее с ним умеют работать только продукты от JetBrains. Лично мне Visual Studio Code по настройке, скорости работы нравится куда больше (но это текстовый редактор, о чём не стоит забывать).

И единственное, что вы можете сделать в Visual Studio Code, установленной на Windows, — подключить себе WSL вместо стандартного PowerShell в терминале. Это делается в User Settings:

На этом всё. Про линтер, автодополнение кода из библиотек, подсветку ошибок можете забыть, по крайней мере для Python. Способа решения сообщество ждёт вот уже три года. Сейчас самый простой и действенный способ заставить его работать — установить в WSL.

Вот теперь работает Ещё более кратко и по сути расписано вот тут.

Однако до совершенства есть ещё один штрих.

Добавьте приведённую выше настройку в User Settings. В противном случае окно VS Code не будет ресайзиться.

А ты ещё докажи, что работает

Разворачивается оно стандартно для подобного рода проектов.

Отличия в настройке между Vagrant и WSL

Единственное существенное различие в контексте статьи — необходимость пробрасывать порты в хостовую файловую систему. По умолчанию Vagrant поднимает SSH-туннель на порту 2222 — именно туда вам будет необходимо логиниться из Cmder и добавить соответствующее соединение в MobaXterm.

Более подробно об использовании Vagrant с MobaXterm можно прочитать по ссылке.

Итоги

Но стоит заметить, что даже подобные извращения могут помочь многим людям, вынужденно сталкивающимися с… не всегда очевидным поведением новой технологии от Microsoft.

Ранее известный как SFU или Сервисы для UNIX. Это подсистема среды в Windows, обеспечивающая полное соответствие POSIX и большое количество инструментов, которые обычно поставляются с системами UNIX.

Как подсистема среды это означает, что она работает вместе с Windows API, прямо над ядром. Таким образом, он не более эмулируется, чем сам Windows API, и, следовательно, работает намного лучше, чем Cygwin, например. ¹

Он в основном предназначен для сборки и запуска приложений UNIX непосредственно в Windows, поэтому, если ваша любимая программа UNIX не поставляется с портом Windows, вы можете попробовать создать ее в SUA:

Службы Windows для Unix и подсистема для приложений на основе Unix предоставляют заголовочные файлы и библиотеки, которые упрощают перекомпиляцию или перенос приложений Unix для использования в Windows; они не делают двоичные файлы Unix совместимыми с двоичными файлами Windows. Лучше всего думать, что это отдельная Unix-подобная платформа.

Текущая версия СФУ содержит:

• Более 350 утилит Unix, таких как vi, ksh, csh, ls, cat, awk, grep, kill и т.д.
• Компилятор GCC 3.3, включает в себя и библиотеки (через MS libc)
• Cc-подобная оболочка для компилятора C/C++ командной строки Microsoft Visual Studio
• Отладчик GDB
• NFS сервер и клиент
• Демон pcnfsd
• Инструменты и библиотеки X11
• Инструменты для создания точек монтирования NFS отображаются в виде общих ресурсов Windows и наоборот (службы шлюза)
• Возможность сервера NIS, связанная с Active Directory (AD)
• Некоторые средства синхронизации информации аутентификации Windows/Unix

SFU не содержит следующее (но двоичные файлы доступны для отдельной установки):

• bash, OpenSSH, sudo, CVS, ClamAV, bzip2, gmake, curl, emacs, Apache, XView, Ruby, Tcl, Python

(Википедия)

Так как SUA не пытается быть Linux или BSD, а представляет собой просто POSIX, это также может означать, что многие программы, которые зависят от платформы, могут не скомпилироваться или работать. Вспоминаются сценарии оболочки, которые предполагают использование bash вместо sh или системных вызовов Linux. В настоящее время написано очень мало программ, которые могут работать непосредственно в любой POSIX-совместимой системе. Также версия gcc, которая включена, является несколько старой, что означает, что она может не поддерживать вашу последнюю версию C99+.

¹ На него по-прежнему распространяются специфические для Windows ограничения, такие как медленное время запуска процесса, поэтому экстремальное разветвление будет по-прежнему очень медленным, поэтому вам придется долго ждать выполнения многих скриптов ./configure или некоторых make-файлов.