Установка Windows заместо UNIX подобной, прямо в магазине
Здравстуйте, присмотрел себе ноутбук ASUS F570ZD-DM102, на нем стоит unix подобная ОС, увидел, что на сайте есть функция «Опциональная операционная система» и можно установить windows 10 можно ли сделать это не на сайте, а прям в магазине, чтоб там установили, при покупке?
Дешевле будет купить ноут с предустановленной Win 10. Потому что операционка в составе ноута стоит примерно тыс 5. Если ставить отдельно, то лицензия стоит примерно 9 тыс + работа по установке.
дешевле купить без винды
а скачать ее можно с оф сайта майкрософт бесплатно
Покупаешь и ставишь сам. Там ничего сложного.
А можешь рассказать, как это сделать?
1. Ваш вариант в учетом скидки стоит 36800. +8500 лицензия win 10 = 45300 + установка операционки.
Ноут с операционкой 44999 = 45 тыс.
Бонусом идет SSD, которого нет в вашем варианте. Минусом 6 гигов памяти вместо 8. Но если для игр. то память в любом случае наращивать.
990x.top
Простой компьютерный блог для души)
Операционная система UNIX-подобная на ноутбуке — что это такое?
Приветствую друзья! Сегодня мы поговорим про ноутбуки, а точнее — про операционные системы, которые могут быть на них при покупке. Вы можете выбирать ноутбук и его характеристиках будет указана операционка (OS, Operating System) — но какая лучше? Чем они отличаются? Ведь от операцонки также может зависит немного стоимость устройства. Я постараюсь написать все простыми словами, без сложных терминов, чтобы было понятно простому обычному человеку, не специалисту.
Операционная система UNIX-подобная на ноутбуке
Это может быть разная операционка, но только не Windows. Например Линукс, Minix, FreeBSD, NetBSD, OpenBSD. Скорее всего вам эти слова ни о чем не говорят и здесь нет ничего удивительного — эти малоизвестные операционки, они бесплатны или стоят копейки, поэтому чтобы сделать дешевле ноутбук — производители ставят именно их.
Стоит ли брать ноут с такой системой? Стоит если:
Пример внешнего вида Nexenta OS, это система из семейства UNIX:
Все хорошо, да, но приложений в сотни раз меньше, чем под Windows, мало игр поддерживает UNIX, в интернете намного меньше инструкций как что настроить. Помните что Windows — сама популярная ОС в мире, под нее собственно и подстраивается весь компьютерный мир.
Endless OS или Windows 10 — что лучше?
Операционка основана на Linux, то есть основана на UNIX-системе, поэтому минусы такие же — отсутствие софта, нет поддержки большинства игр, могут быть проблемы с драйверами, мало материалов в интернете как что настроить.
Новичку в мире ПК брать ноут с Endless OS — не стоит. Только при условии что у вас есть мастер или вы сможете самостоятельно поставить виндовс, во всех остальных случаях — вам будет сложно. Хотя бы потому что инструкций в интернете почти нет, по сравнению с количеством материалов под Windows.
Внешний вид Endless OS:
Очень даже неплохо, да, поэтому можно и такие выводы сделать:
Судя по этому скриншоту поддерживается много современных программ:
Поэтому повторюсь, если ноут берется для того, чтобы сидеть в социальных сетях, пользоваться Вайбером, Ватсапом, браузерами Хром, Мозилла — то в принципе можно брать. Но с другой стороны, вы возьмете, будете пользоваться, у вас ноутбук и вы не знаете Windows, когда кругом — именно Windows. Начинать знакомство с операционными системами обычному человеку лучше именно с Windows. Вот например есть Android, возможно у вас даже смартфон на этой операционке. А есть Palm, вы слышали о ней? Да, она уж старая. Но она от Microsoft и на ней почти также мало софта, как под Линукс.
Операционная система Linux на ноутбуке — что это такое?
Тоже самое — это UNIX-система со всеми вытекающими минусами. Плюс — цена ноута может быть ниже, если вы сможете поставить виндовс, то можно сэкономить.
На самом деле процесс установки Windows простой, если в двух словах:
Другими словами если у вас есть смартфон и доступ в интернет (для получения информации) — то поверьте, при большом желании вы сами сможете установить Windows, нужно только записать виндовс на флешку, при установке удалить существующие разделы и установить систему на незанятое место на диске (оно появится после удаления существующих разделов).
Вот как выглядит один из видов Линукса — Calculate Linux 12:
DOS — что это в ноутбуке?
В отличии от UNIX-систем эта операционка уже непригодна для полноценной работы, или даже для полуполноценной, как при UNIX. Это уже доисторическая система, в которой нет ничего нормального и место, где она может применяться — заводы, предприятия, например промышленное оборудование. Эта система ставится уже именно специально чтобы удешевить устройство.
Например вы купили ноут. Там скорее всего будет не DOS, а FreeDOS, что в принципе сути не меняет, вы включите ноут и увидите примерно такую картинку:
А дальше — работайте, наслаждайтесь. Разумеется что ничего здесь толкового не сделать, никакого комфорта и Ютуба. Поэтому если в ноуте FreeDOS — это значит вам в любом случае придется ставить Windows.
Максимум что может быть — такое некое подобие операционки:
Даже UNIX-система будет намного лучше, там хотя бы что-то можно делать, пользоваться полноценно интернетом, смотреть фильмы, слушать музыку.
Заключение
Давайте в качестве выводов подытожим — какие минусы нам светят при использовании операционки не Windows:
Зато вирусов под UNIX — почти нет. Почему? Все просто — а смысл создавать вирусы под систему, которой почти никто не пользуется по сравнению с Windows.
Опыт настройки и использования WSL (подсистемы Linux в Windows 10)
К написанию данной статьи меня побудил вопрос на Тостере, связанный с WSL. Я, после нескольких лет использования систем на ядре Linux, около полугода назад перешел к использованию Windows 10 на домашнем ПК. Зависимость от терминала и Linux окружения в моей работе практически сразу привели меня к вопросу: или ставить виртуалку или попробовать WSL. Я выбрал второе, и остался вполне доволен.
Под катом я расскажу как установить и настроить WSL, на какие я наткнулся проблемы и ограничения, как запускать Linux приложения из Windows и наоборот, а так же как интегрировать элементы окружения Xfce в окружение рабочего стола Windows.
Никогда не думал, что однажды вернусь на Windows, но повод попробовать мне дали стечения обстоятельств: жена, далекая от IT, дергала почти каждый раз, когда у нее возникала необходимость воспользоваться компом; проснулась ностальгия по одной игре, но она никак не хотела адекватно работать под wine; а тут еще мне подарили коробочную Windows 10 Pro. WSL я поставил чуть ли не сразу после установки системы, поигрался несколько вечеров, понял, что продукт для моих задач годный, но хочется более привычный терминал и вообще некоторых удобств.
Установка WSL и дистрибутива
Сразу оговорюсь, в интернете можно найти описание установки с помощью выполнения команды lxrun /install в командной строке или консоли PowerShell. Данный способ больше не работает (после выхода WSL в стабильный релиз). Насколько мне известно, сейчас WSL можно установить только из Microsoft Store вместе с предпочитаемым дистрибутивом.
Так же отмечу, что когда установку производил я, на выбор были доступны дистрибутивы OpenSUSE, SUSE Linux Enterprise и Ubuntu 16.04 — последний я и установил. Сейчас также доступны Ubuntu 18.04, Debian 9 и Kali Linux, возможно появятся и другие дистрибутивы. Действия по установке могут отличаться. Так же, часть проблем описанных в статье может быть уже исправлена.
Находим в магазине желаемый дистрибутив и устанавливаем. Установка пройдет быстро, так как скачает только эмулятор ядра Linux и утилиту для запуска подсистемы, которая окажется в системной папке в трех экземплярах: wsl.exe, bash.exe и ubuntu.exe (вместо ubuntu будет имя Вашего дистрибутива). Все они равнозначны и делают одно и то же — запускают собственный эмулятор терминала, в нем linux’овый bash работающий под эмулятором ядра. При первом же запуске нас попросят придумать логин и пароль для пользователя по умолчанию, а после произойдет непосредственно установка дистрибутива. В качестве пользователя по умолчанию указываем root без пароля — это потребуется для дальнейших шагов. Безопасность не пострадает, кроме того при подготовке материалов к статье, в англоязычном туториале, я наткнулся на информацию, что новые версии WSL теперь делают пользователем по умолчанию root без пароля без лишних вопросов.
Дожидаемся установки. Далее первым делом стоит обновить зеркала apt на ближайшие. Для этого понадобится CLI текстовый редактор. В комплекте только vi, я же больше предпочитаю nano, поэтому ставлю его:
sudo вводить не требуется, так как мы уже под root’ом. Отредактируем файл /etc/apt/sources.list:
У меня лучше всего работают зеркала Яндекса, поэтому мой файл выглядит так:
Нажимаем Ctrl+O для сохранения и Ctrl+X для выхода. Теперь можно обновить систему до актуального состояния:
После обновления можно создать нашего основного пользователя. В данной статье я назову его user1, Вы же можете задать привычное имя:
Далее переходим в папку юзера, зайдем под ним, установим пароль и отредактируем файл
Все, подсистема готова к использованию… почти.
Установка X-сервера, Xfce и прочих GUI’шных приложений
Первая же проблема, на которую я натолкнулся — bash-completion в предлагаемом эмуляторе терминала работал, мягко говоря, некорректно. Кроме того, данный эмулятор не умеет вкладки, а каждый его экземпляр запускает все в новом пространстве процессов, с отдельным init’ом (который кстати не заменить). Мне захотелось нормальный эмулятор терминала, некоторых других GUI приложений, а так же панельку, чтоб это все быстро запускать.
Когда я гуглил этот вопрос, я наткнулся на множество проблем, вроде необходимости перевода dbus на tcp протокол. На данный момент всех этих проблем нет. В подсистеме нормально работают unix-domain-socket’ы и все спокойно общается через них.
Первым делом нам понадобится X-сервер, притом установленный в основную систему (в Windows). Лично я использую для этих целей VcXsrv — порт X11 на Windows. Официальный сайт указанный в about самой утилиты его сейчас не предоставляет, поэтому гуглим установщик и устанавливаем все по умолчанию.
Пока идет установка возвращаемся в терминал WSL, командой exit выходим обратно в root’а. Первым делом настроим русские локали:
Далее установим некоторые компоненты Xfce. Можно конечно установить его целиком из мета-пакета, но большинство компонентов нам не понадобится, а модульная архитектура Xfce позволяет нам поставить только необходимое:
Запускать каждый раз окружение руками не очень удобно, поэтому я автоматизировал данный процесс. Для этого в основной системе создадим в удобном для нас месте папку, а в ней 3 файла для запуска:
x-run.vbs — WSL всегда запускается со своим эмулятором терминала, если его закрыть — завершатся все его дочерние процессы. Чтоб данное окно не мозолило глаза, неплохо его запускать скрытым. К счастью в Windows встроен интерпретатор VBScript, который позволяет это сделать в одну строчку:
Далее можем запустить наш start.bat и настроить панель Xfce под себя. Замечу, что здесь я наткнулся на еще одну проблему — панель прекрасно отображается поверх всех окон, но вот выделить себе место, как панель на рабочем столе Windows она не может. Если кто знает решение данной проблемы, поделитесь в комментариях.
Ну и под конец данной части, скриншот моего рабочего стола:
Взаимодействие окружения Windows и окружения подсистемы Linux
Из Linux так же можно запускать Windows приложения. Просто запускаем exe-шник и он выполнится в основной системе.
Сетевой стек у подсистемы общий с Windows. Сервер поднятый в Linux будет доступен на localhost в Windows и наоборот. Однако unix-domain-socket для Windows будет просто пустым файлом, работать с этим можно только внутри Linux. Выход во внешнюю сеть у Linux так же есть, в том числе можно слушать порты, если этого не запрещает фаервол.
ifconfig в Linux и ipconfig в Windows выдают одинаковую информацию о сетевых интерфейсах.
Из диспетчера задач Windows можно спокойно прибить процесс внутри подсистемы Linux. Однако Linux увидит только свои процессы.
Особенности, ограничения и подводные камни
Ядро Linux в WSL не настоящее. Это всего лишь прослойка-эмулятор, которая часть Linux-специфичных задач выполняет сама, а часть проксирует напрямую в ядро winNT. Большая часть api в нем реализована, но не все. Свое ядро собрать не получится, как и не получится подключить модули ядра (.ko, Kernel Object).
Init процесс у WSL тоже свой и заменить его, например, на system.d не выйдет. У меня давно есть желание написать менеджер демонов на go, который бы работал с файлами юнитов system.d и предоставлял бы схожий интерфейс, да все руки не доходят.
Нет поддержки openFUSE, соответственно примонтировать виртуальную или удаленную файловую систему не получится. Так же нельзя сделать mount из файла, mount вообще ничего кроме bind здесь, похоже, не умеет.
Так же нет никакой возможности разбить файловую систему Linux на несколько разделов/дисков.
Прямой доступ к железу практически отсутствует. Все таки мы находимся в песочнице Windows, а не в полноценном Linux. /dev и /sys заметно пустуют, в них лишь проц да виртуальные устройства. Доступ к GPU — только через X-сервер, напрямую — никак, так что нейросети обучать придется в Windows.
В JS разработке столкнулся с тем, что electron.js отказался запускаться в WSL, пришлось дублировать окружение node.js в Windows.
Итоги
Статья получилась довольно длинной, надеюсь, что она окажется еще и полезной.
WSL для меня лично оказался инструментом вполне юзабельным, решающим мои задачи fullstack backend разработчика. Виртуалка с Linux за полгода так и не понадобилась. По общим ощущениям Windows+WSL намного функциональнее, чем Linux+Wine.
Пока писал статью, обнаружил, что в Microsoft Store появилась сборка WSL с Debian 9.3, данный дистрибутив мне более симпатичен, чем Ubuntu, поэтому буду пробовать ставить.
Из UNIX в Windows: особенности миграции
Необходимость устанавливать UNIX ради запуска любимых приложений может иногда отпасть, если воспользоваться эмуляторами, позволяющими выполнять программы для UNIX в среде Windows 9x/NT.
В статье дается обзор основных отличий двух операционных систем и рассматриваются возможные варианты преодоления трудностей переноса программного обеспечения.
Microsoft предпринимает определенные усилия для облегчения переноса программного обеспечения с платформы UNIX в свои операционные системы. Так, в Service Pack 3 появились волокна (fiber), добавленные для упрощения переноса серверных приложений. В отличие от потоков (thread), коммутируемых и управляемых ядром, программист имеет полную власть над волокнами. Это позволяет эмулировать поведение UNIX-процессов и эмулировать системные функции exec и fork. Однако Windows 95 не поддерживает волокна и их использование ограничивает рынок потенциальных потребителей.
 |
| Рис. 1. Внешний вид Midnight Commander |
Стоит развернуть окно консоли на полный экран и не всякий разберется, в какой операционной системе он работает. Конечно, «живая» UNIX все же лучше, но для большинства повседневных задач эмулятор вполне подойдет.
Немного об отличиях
Прежде всего, полезно рассмотреть, в чем заключаются различия между Windows и UNIX, и как их можно преодолеть. Это пригодится разработчикам, не желающим связываться с эмуляторами и зависеть от сторонних производителей. Еще Кен Томпсон говорил, что никогда нельзя полностью доверять программам, написанным другими: помимо юридических проблем распространения чужого эмулятора или его компонентов вместе с вашим программным обеспечением, существует риск столкновения с ошибками эмулятора. Поэтому, в особо ответственных ситуациях перенос приложений приходится осуществлять самостоятельно.
Даже опытные разработчики на первых порах испытают значительные трудности, порой шаг за шагом проходя весь код отладчиком, никак не понимая, что же именно мешает ему работать. Большинство руководств, в том числе MSDN (Microsoft Developer Network), ограничивается описанием концептуальных различий системных вызовов UNIX и Windows, не затрагивая многочисленных тонкостей и особенностей обеих платформ. Отмахнуться от проблемы, приписывая использование тонкостей исключительно экзотическим и системным программам, не получится. Системно-зависимый код содержится во множестве прикладных приложений, таких, например, как популярный текстовой редактор EMACS.
 |
| Рис. 2. Создание эмулятором упорядоченной таблицы дескрипторов файлов |
 |
| Рис. 3. Локальные таблицы HANDLE для двух Windows-процессов и их отображение в глобальную таблицу дескрипторов UNIX-эмулятора |
Один и тот же дескриптор может ассоциироваться с несколькими HANDLE. Например, оба дескриптора консоли, одновременно открытой как на запись, так и на чтение должны управляться всего одним обработчиком. Это обстоятельство крайне важно, ибо в Windows не существует глобальной таблицы обработчиков общей для всех процессов (точнее сказать, она существует, но прикладным программам недоступна). Каждый процесс имеет собственную локальную таблицу, поэтому бессмысленно пытаться использовать HANDLE чужого процесса. Такой подход повышает надежность системы, но затрудняет межпроцессорные взаимодействия, поэтому все UNIX приложения, не рассчитывающие на такой поворот событий, тут же откажут в работе. Поэтому необходимо собрать все HANDLE в одну таблицу, общую для всех UNIX-процессов (рис. 3).
В Windows вызов CreateProcess порождает новый процесс, не затирая текущий. При этом сохраняется возможность наследования всех обработчиков установкой флага bInheritHandles. (Важно заметить, в Windows наследуются те и только те объекты ядра, при создании которых был явно установлен флаг наследования, в противном случае ничего не произойдет, даже если приказать дочернему процессу наследовать обработчики родительского процесса.) Поэтому функция CreateProcess практически эквивалентна последовательным вызовам fork + exec. Но аналога fork в Windows нет, как и возможности расщепления процессов. По большому счету это сегодня просто не нужно, но часто использовалось раньше разработчиками UNIX-приложений.
Любой эмулятор UNIX должен уметь имитировать вызов fork, благо архитектура Windows это позволяет. Чаще всего создается приостановленный (suspend) процесс, с той же самой стартовой информацией, что и текущий. До выполнения функции main() из родительского процесса потомку копируется сегмент данных, содержимое стека и дублируются все обработчики. В последнюю очередь модифицируется контекст процесса, хранящий значения регистров, в том числе и регистра указателя очередной выполняемой команды.
Гораздо проще имитировать exec: достаточно вызвать CreateProcess и «удалить» текущий процесс, имитируя его замещение новым. Остается всего лишь подменить идентификатор нового процесса на идентификатор прежнего. Если этого не сделать, вновь порожденный процесс станет потомком процесса, вызвавшего exec, а в оригинальной системе UNIX функция.exec, не создает дочернего процесса и сохраняет идентификатор текущего. Но идентификатор процесса выдается операционной системой и не может быть изменен по желанию приложения! Другими словами, если «Процесс 0» породил «Процесс 1» и запомнил его идентификатор, а «Процесс 1», имитируя вызов exec, обратился к функции CreateProcess и вызвал exit для завершения своей работы, то «Процесс 0» будет по-прежнему ссылаться на уже несуществующий «Процесс 1», ничего не зная о порожденном «Процессе 2», обладающим иным идентификатором.
Ситуация кажется безнадежной, но она элегантно разрешается созданием собственной таблицы идентификаторов эмулятором UNIX. Родительский процесс в качестве идентификатора получает индекс ячейки такой таблицы, содержащей настоящий идентификатор дочернего процесса. В результате появляется возможность «подменить» идентификатор «Процесса 1» на «Процесс 2» незаметно для родительского процесса. (рис. 4).
 |
| Рис. 4. Эмуляция вызова exec |
Сейчас в Windows 9x/Winwos NT наличествует многопоточность и выбор межпроцессорных взаимодействий, поэтому имитировать поддержку сигналов вполне реально. Для этого в каждом эмулируемом приложении необходимо выделить отдельный поток, ожидающий, например, события (Event) и передающий управление на соответствующую подпрограмму при его наступлении (рис. 5). События выгодно отличаются возможностью «заморозить» ожидающий поток, не теряя впустую драгоценного процессорного времени. Следует отметить, функция «kill» вовсе не убивает процесс, как это следует из ее названия, а направляет ему сигнал, который тот может либо проигнорировать, либо обработать по своему усмотрению.
 |
| Рис. 5. Эмуляция функции kill |
Некоторые приложения оказываются чувствительны к вариациям реализации стека в UNIX и Windows. Выделение памяти под стек в
Windows происходит очень сложным образом. Сначала выделяется всего несколько страниц, а все остальные предоставляются процессу по мере разрастания стека. На границе между выделенной и невыделенной памятью расположена сторожевая страница (PAGE_GUARD), при попытке обращения к которой генерируется исключение и операционная система выделяет память, перемещая сторожевую страницу вверх. Это великолепный механизм, но. Windows «падает» при выполнении следующего тривиального кода:
Гораздо больше неудобств доставляет «двойной» перенос строки в MS-DOS (Windows), задаваемый символами « », тогда как UNIX ожидает лишь одиночного символа « ». Из-за этого большинство UNIX-приложений не могут корректно обрабатывать тексты, созданные редакторами MS-DOS (Windows) и наоборот. Текст программы, набранный в редакторе edit, вызовет протест со стороны UNIX-версии интерпретатора Perl. Универсального выхода из этой ситуации не существует, но посредственных решений проблемы можно предложить сколько угодно. Чаще всего эмуляторы при открытии файла в текстовом режиме самостоятельно обрабатывают символы перевода строки, следуя UNIX-соглашению. Файл, открытый в двоичном режиме читается «как есть», поскольку невозможно различить действительный перевод строки, от совпадения последовательности символов. К сожалению, многие приложения обрабатывают текстовые файлы, открывая их в двоичном режиме. Поэтому, лучше всего переносить файлы данных вручную, при необходимости заменяя символы переноса строки.
 |
| Рис. 6. Эмуляция чувствительности к регистру в именах файлов |
Намного хуже дело обстоит с поддержкой «сырых сокетов» (SOCK_ RAW). Если говорить просто, сырые гнезда позволяют прикладной программе самостоятельно сформировать заголовок IP-пакета, действие редко используемое в нормальной жизни, но необходимое для множества атак. Спецификация WINSOCK 2.x как будто бы подтверждает их наличие в Windows, но на самом деле, соответствующие функции реализованы неправильно и посылают подложный пакет, помещая пользовательский заголовок в область данных. Не то чтобы ситуация была полностью безнадежна, но написание собственного драйвера TCP/IP требует надлежащей квалификации разработчиков и ни один из известных автору эмуляторов сырых сокетов не поддерживает. К слову сказать, помимо гнезд семейства AF_INET, в UNIX существуют и сокеты, используемые для межпроцессорного взаимодействия, не поддерживаемые WINSOCK, но реализуемые подавляющим большинством эмуляторов.
Рассмотрев теоретические различия между UNIX и Windows, перейдем к сравнению конкретных реализаций эмуляторов. Для этого возьмем двух ярких представителей, UWIN от корпорации AT&T (кто знает UNIX лучше самой AT&T?) и CYGWIN, поддерживаемый в рамках проекта GNU.
Эмулятор UWIN
Для некоммерческого использования полноценную копию UWIN можно получить бесплатно (http://www.research.att.com/sw/tools/uwin/). UWIN содержит множество популярных командных оболочек, свыше трехсот необходимых для работы утилит и даже позволяет запускать Apache WEB сервер и DNS сервер. Администраторов NT не может не порадовать наличие полноценного демона telnetd (как известно в штатную поставку Windows NT не входит никаких средств удаленного управления компьютером).
Но этим возможности UWIN не ограничиваются. В реестре становится возможным хранить и обрабатывать файлы, точь-в-точь как на обычном жестком диске.
Однако монтируемая файловая система видна только из-под UWIN, а Windows-приложения даже и не подозревают о ней. Поэтому, попытка вызвать notepad для просмотра фала /win/readme.txt провалится, а правильный вариант должен выглядеть так: «/win/notepad C:windows readme.txt». Обратите внимание на двойную косую черту. Если ее убрать, Windows сообщит о невозможности открыть файл «C:windowsreadme.txt». Так происходит потому, что в UNIX (и UWIN), косая черта «» зарезервирована за управляющими символами, а когда требуется отобразить сам символ обратной черты, прибегают к его дублированию.
 |
| Рис. 7. Все UWIN-приложения разделяют общую память |
При этом все UWIN-приложения разделяют общий регион памяти, содержащий таблицу открытых файлов и кучу [3] (рис. 7). Следовательно, одно UWIN-приложение потенциально способно «уронить» другое, а потому некорректно работающий код может предоставить злоумышленнику привилегированный доступ к системе. Поэтому, если UWIN используется в качестве серверной платформы, не следует запускать приложения сомнительного происхождения.
В остальном же, UWIN-приложения ничем не отличаются от обычных исполняемых файлов Windows и могут запускаться непосредственно из Explorer, минуя среду UIWN.
Эмулятор CYGWIN
В CYGWIN вообще нет файла «/etc/passwd», он не эмулирует подсистему безопасности UNIX. Конечно, это не мешает написать соответствующие процедуры самому, но не лучше ли воспользоваться готовым инструментарием UWIN? Кстати, в UWIN изначально входит базовый набор утилит и оболочек, автоматически устанавливаемых программой инсталляции. Напротив, пользователи CYGWIN вынуждены самостоятельно скачивать необходимые компоненты с сервера, порой исправляя грубые ошибки, часто приводящие к полной неработоспособности кода.
Больше всего огорчает отсутствие в CYGWIN механизма поддержки демонов. Так, на данный момент не известно ни одной реализации telnet-сервера под CYGWIN. В остальном архитектуры этих двух эмуляторов достаточно близки. Как и в UWIN используется разделяемая память для всех открытых дескрипторов и хранения данных по для fork и exec [4]. Реализация fork сводится к созданию приостановленного процесса с последующим копированием сегмента данных, а выполнение exec приводит к образованию нового процесса и подмене идентификаторов в локальной таблице эмулятора. Поэтому в точности воспроизведения ядра UNIX оба эмулятора практически идентичны и все отличия выпадают на долю прикладных утилит. Проигрывая в этом вопросе, CYGWIN значительно превосходит UWIN в производительности, особенно в операциях ввода-вывода. К сожалению, UWIN слишком медленно обращается с экраном и работа с Mortal Commander на нем превращается в сплошное мучение.
Оба эмулятора UWIN и CYGWIN не поддерживает сырых гнезд, причем CYGWIN никак не отмечает этот прискорбный факт в документации. В результате, многие программы, работающие с IP протоколом на низком уровне (большей частью предназначенные для атак на чужие системы) не смогут корректно выполнятся в среде CYGWIN.
Об авторе
Крис Касперски — независимый автор. С ним можно связаться по электронной почте по адресу: kpnc@sendmail.ru
Литература
[1] Д. Волков. Дума о миграции. «Открытые системы», 1999, № 4, с. 13-19
[2] Wipro UWIN Version 2.0 User Guide
[3] Wipro UWIN Version 2.0 Developer Guide
[4] Geoffrey J. Noer Cygwin: A Free Win32 Porting Layer for UNIX Applications
[5] Джефри Рихтер. «Windows для профессионалов. Программирование в Win32 API для Windows NT4.0 и Windows 95»
| Устройство | Название в UNIX | Название в MS-DOS |
| Консоль | /dev/tty | con |
| Стандартный ввод | /dev/stdin | con |
| Стандартный вывод | /dev/stdout | con |
| Черная дыра | /dev/null | nul |
| Привод гибких дисков | /dev/fd | А: (B:) |
| Параллельный порт | /dev/lp | com |
| Последовательный порт | /dev/mod | lpt |
Поделитесь материалом с коллегами и друзьями