Обсуждение:Службы Windows для UNIX

Сопоставление имени пользователя SUA

Одна вещь, которой всегда не хватает в каждой части информации о SUA, — это отсутствие инструмента сопоставления имен пользователей, такого как MSSFU3.5. Кажется, он полагается на Active Directory для сопоставления имен пользователей Windows с UID. — Предыдущий неподписанный комментарий добавлен 187.57.147.35 (обсуждение) 02:25, 14 сентября 2011 (UTC) [ ответить ]

Против Cygwin

Когда я прибыл, статья содержала следующее утверждение: «Это реализация подсистемы среды, работающей в ядре Windows. Это значительно повышает производительность, стабильность и безопасность по сравнению с эмуляцией, используемой Cygwin ».

Это вполне может быть так, но источники не указаны. Таким образом, это утверждение не поддается проверке , и утверждение о безопасности в частности может считаться точкой зрения. В качестве временной меры я перефразировал второе предложение, чтобы соответствовать основным стандартам Википедии для утверждений, для которых нет доказательств. Может ли кто-нибудь помочь, предоставив поддающиеся проверке источники для любого или всех этих утверждений? Haeleth 14:25, 3 октября 2005 (UTC) [ ответить ]

Cygwin определенно не является "эмуляционным слоем", это DLL, которая обеспечивает различные низкоуровневые библиотечные вызовы, которые нужны приложениям unix/linux при общении с ядром. Все программы, работающие с cygwin, должны быть перекомпилированы, в большинстве случаев это требует немалых усилий по портированию. Пожалуйста, посетите http://www.cygwin.com для получения полной информации.

Правда, то, что делает Cygwin, не следует называть эмуляцией. Однако он находится в пространстве приложений над подсистемой Win32, тогда как Interix — это подсистема, подобная Win32, и находится рядом с ней поверх ядра NT. (По крайней мере, до Vista его называли ядром NT; я не уверен, что это все еще правильный термин.) Когда я прочитал предыдущий абзац, я зашел на два авторитетных сайта для подтверждения — microsoft.com и interopsystems.com. Interix изначально разработала Interop Systems (первоначальное название — OpenNT). Впоследствии Microsoft купила у них технологию, наняла их ведущего архитектора и сделала Interix частью своего предложения Services for Unix (SFU). С тех пор они по понятным причинам низвели его до роли инструмента миграции в Windows. Из-за этого я не смог найти документацию того, что я сказал выше, ни на interopsystems.com, ни в MSDN. Ближайшими, которые я нашел, были следующие два предложения из устаревшей статьи TechNet по адресу http://www.microsoft.com/technet/interopmigration/unix/sfu/runwin32.mspx: "Подсистема Interix заменяет исходную подсистему Microsoft® POSIX. Interix предоставляет полную, собственную среду UNIX, которая может работать одновременно с подсистемой Windows". (1) Исходная подсистема POSIX от Microsoft также работала вместе с Win32 поверх ядра NT. Она была не такой уж замечательной, и Microsoft не хотела тратить много денег на то, что они считали инструментом миграции, поэтому они купили технологию Interix. (2) В предложении неточная формулировка; ссылка на "Windows" на самом деле относится к Win32. UnConnoisseur

После написания вышеприведенного параграфа я заметил, что Microsoft не ссылается в SUA на ОС (подсистему) как на Interix, как это было в SFU. Я предполагаю, что это все та же кодовая база, но я этого не знаю, и, похоже, это название уходит в отставку. UnConnoisseur

Эмуляция

На мой взгляд, нет ничего плохого в том, чтобы называть Cygwin слоем эмуляции, учитывая, что он эмулирует Unix-подобный API поверх Win32 API. Аналогично, SUA (Interix) эмулирует Unix API поверх собственного NT API. В некоторых официальных документах Microsoft даже называет текущие и бывшие подсистемы для NT/Windows (Win32, POSIX, Interix и OS/2) «подсистемами эмуляции».

Учитывая, что у некоторых людей есть довольно сильное (но, на мой взгляд, иррациональное) возражение против слова «эмуляция», я пока воздержусь от его добавления в эту статью, но в эмуляции на самом деле нет ничего плохого. Она не подразумевает плохую производительность, плохой дизайн или что-либо еще, что можно было бы истолковать как негативное. Действительно, система, разработанная для эффективной эмуляции нескольких других (например, путем реализации объединенного набора функций, предлагаемых этими системами), возможно, по крайней мере так же хороша, как и система, которая не использует эмуляцию. Shalineth 09:57, 3 апреля 2007 (UTC) [ ответить ]

SUA и Cygwin

Важное различие между SUA и Cygwin заключается в том, что первый работает поверх API NT, тогда как последний работает поверх Win32. Это означает, что Cygwin может использовать только подмножество функциональности ядра NT, используемой Win32, тогда как SUA имеет доступ к полному набору функций, предлагаемых ядром, включая специфичные для Unix функции.

Наиболее очевидным примером, где вышеизложенное приведет к различиям в производительности (и безопасности), является fork(). Менеджер памяти NT включает возможность разветвления процессов (с копированием при записи для дочернего адресного пространства и т. д.), но это было включено специально для того, чтобы позволить реализовать Unix поверх NT, и никогда не использовалось Win32.

Win32 не имеет понятия о ветвлении процессов, поэтому подсистема Win32 не вызывает и не предлагает способа вызвать функциональность ветвления NT. Это означает, что нет способа ветвления процесса Win32, и, следовательно, Cygwin должен имитировать процедуру, создавая новый процесс Win32 и вручную настраивая его адресное пространство из другого процесса пользовательского режима (копируя данные и т. д.). Это крайне неэффективно и гораздо менее безопасно, чем оставить это делать ядру, как в случае с типичной системой Unix (включая SUA).

Другой пример, где Win32 представляет проблему для Cygwin, — чувствительность к регистру. Win32 сохраняет регистр, но не чувствителен к регистру, что означает, что у вас не может быть двух имен файлов, которые отличаются только регистром. Однако базовая файловая система (NTFS) поддерживает операции с учетом регистра, но, как и в случае с функцией fork() в NT, это было включено для реализации POSIX/Unix в NT. И снова Interix или SUA могут вызывать ядро ​​NT для создания имен файлов, которые отличаются только регистром, но Win32 не может (и, следовательно, Cygwin не может).

Исторически основным недостатком подсистемы, работающей поверх ядра NT, было то, что сама NT не предоставляла никаких графических возможностей: графические компоненты ОС на базе NT всегда были частью Win32 (часть из которых, начиная с NT 4.0, работала в режиме ядра, в модуле win32k.sys). Это означало, что код, работающий в не-Win32-процессе (например, Interix), не имел возможности напрямую отображать графику, поэтому для этой цели приходилось использовать IPC для связи с процессом Win32 (например, X-сервером).

С выпуском SUA в Server 2003 и Vista появилась поддержка двоичных файлов «смешанного режима», которые создаются и управляются подсистемой Unix, но также могут вызывать API Win32 (что процессы Cygwin, как и сами процессы Win32, всегда могли делать). Предположительно, это означает, что X-сервер может быть перенесен непосредственно в подсистему Unix и по-прежнему вызывать часть режима ядра Win32 для доступа к графическим устройствам.

Насколько мне известно, ни один X-сервер не был перенесен на подсистему Unix на Windows, но технических препятствий для этого больше нет, просто никто этого не сделал.

Подводя итог, с добавлением двоичных файлов «смешанного режима» нет никаких технических недостатков в использовании собственной подсистемы для реализации Unix поверх ядра NT по сравнению с подходом Unix-on-Win32 Cygwin. С другой стороны, Microsoft никогда не публиковала документацию, объясняющую, как разработать подсистему для NT (хотя я считаю, что они поддерживали некоторые академические проекты в этой области), поэтому единственный поддерживаемый способ для кого-то, кроме Microsoft, реализовать Unix-подобную систему поверх ядра NT — это реализовать ее поверх Win32 (например, Cygwin) со всеми вытекающими из этого недостатками.

У меня сейчас нет времени искать официальную документацию по вышеизложенному, но я читал об этом в авторитетных источниках по дизайну ядра NT, так что я постараюсь найти источник и добавить его в статью, когда у меня будет время. Shalineth 09:57, 3 апреля 2007 (UTC) [ ответить ]

Следующая версия

Следующий запланированный релиз — версия 5.2 на декабрь 2005 г. (только для Windows 2003 Server Release 2, также известной как W2K3/R2 — об этом нет упоминания на странице SFU [1] — на самом деле она была прекращена корпорацией Microsoft. Может ли кто-нибудь подтвердить/опровергнуть новую версию? Не обращайте внимания на этот вопрос. Ответ я нашел сам, по адресу [2].

Может ли кто-нибудь исправить изображение RaviC (изменить его до нужного размера?), так как это единственное изображение, которое я смог найти. TheGuest

Из OpenBSD?

Я припоминаю, что многие пользовательские программы из OpenBSD (по сравнению с MKS Toolkit , который использует независимые переопределения), но не могу вспомнить источник. У кого-нибудь есть? - Дэвид Джерард 12:04, 3 июля 2006 (UTC) [ ответить ]

Я далеко не эксперт в этой теме, но в документе USENIX, ссылка на который приведена в статье под названием « История подсистемы Interix», содержится следующее:
Большая часть исходной базы утилит для ранних команд и утилит INTERIX пришла прямо из дистрибутива 4.4BSD-Lite. Общий поток был в том, чтобы скопировать исходный дистрибутив в рабочий каталог, использовать простой шаблон makefile и начать простые циклы компиляции-редактирования, пока утилита не будет собрана. (6.14.4, стр.10)
Может быть, это то, о чем вы думали? — Haeleth Talk 12:44, 3 июля 2006 (UTC) [ ответить ]
http://undeadly.org/cgi?action=article&sid=20030927090008 Запускаем строки на нем, смотрим, какие есть источники. Janizary 23:10, 24 августа 2006 (UTC) [ ответить ]
Насколько я понимаю (из вторых рук), SUA изначально была основана на коде из подсистемы NT POSIX (лицензированной у Microsoft компанией Softway Systems) вместе с кодом 4.4BSD-Lite, но многие пользовательские инструменты BSD впоследствии были обновлены путем импорта кода из OpenBSD.
Однако, начиная с SUA для Server 2003 R2, Microsoft также добавила инструменты System V наряду с инструментами BSD, первый из которых, как я полагаю, происходит от исходной кодовой базы UNIX SVR5 (UnixWare), лицензированной через SCO Group (ранее известной как Caldera, которая купила код Unix System V, а название «SCO» — от бывшей Santa Cruz Operation, которая приобрела первый из них у Novell, который, в свою очередь, приобрел его у UNIX System Laboratories компании AT&T в начале 90-х). Это сделало бы SUA «генетическим Unix», хотя я не уверен, является ли он официальным «UNIX» (т. е. лицензированным The Open Group (TOG) на использование этого названия), хотя я знаю, что Interix был когда-то сертифицирован TOG как официальный «UNIX». Shalineth 10:13, 3 апреля 2007 (UTC) [ ответить ]

Слияние Interix с этим

Следующее обсуждение закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны в новом разделе. Ниже приводится резюме сделанных выводов.
Результатом этого обсуждения стало отсутствие слияния . Закрыто по предложению WP:AN [3]

Кто-то предложил объединить запись Interix с SFU. Это неправильно. Не делайте этого. SFU теперь EOL, хотя он будет использоваться еще много лет. Interix (один из компонентов SFU) продолжает развиваться, поскольку теперь он связан с базовой версией ОС, начиная с Windows 2003/R2 (Interix версии 5.2) и продолжая Vista (Interix версии 6.0).

Как и SFU, SUA — это пакет миграции, содержащий инструменты, в том числе Interix. Interix должен быть независимо ссылаемым с перекрестными ссылками между ними.

Статьи Windows Services for UNIX и Interix имеют перекрывающееся содержание, например, каждая статья приводит список функций, идентичный другой статье (« более 350 утилит Unix, таких как vi, ksh, csh, ls, cat, awk, grep, kill и т. д. » и т. д.). Поэтому я снова добавил шаблон слияния.
Либо статьи должны быть объединены, либо обе статьи могут оставаться отдельными. В последнем случае они должны быть отделены друг от друга. -- Абдулл ( обсуждение ) 20:51, 13 сентября 2010 (UTC) [ ответить ]

Согласен, что эти два варианта должны оставаться отдельными, в основном для WSFU, который устарел из-за Microsoft и будет иметь другой путь, чем interix. WebSurfinMurf — Предыдущий недатированный комментарий добавлен 12:16, 12 апреля 2011 (UTC). [ ответить ]

Я тоже согласен, что их не следует объединять. Хотя Interix был включен в SFU 3.0 и 3.5 (последняя версия), он не был включен в SFU 1.0 и 2.0. Объединение статей сделало бы их громоздкими, поскольку они не были бы посвящены какой-либо одной теме. 67.210.196.5 ( обсуждение ) 17:07, 19 мая 2011 (UTC) [ ответ ]

Я согласен, и я добавил большую часть недостающей информации в статью. FuFoFuEd ( обсуждение ) 07:35, 30 мая 2011 (UTC) [ ответ ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.

Предложение о слиянии, обсуждение 2015 г.

Следующее обсуждение закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.


Поскольку последний комментарий с возражением был здесь почти 4 года назад, и у нас есть пара версий Windows, можно ли это сейчас объединить? Мне кажется разумным. -- Адамфилд ( Адамфилд ) 09:49, 17 февраля 2015 (UTC) [ ответить ]

Что здесь произошло, похоже, консенсус против слияния был достигнут, но никто на самом деле не потрудился закрыть обсуждение. Однако, поскольку вы недавно прокомментировали слияние статей в противовес консенсусу с того времени, и мое собственное мнение заключается в том, чтобы держать их отдельно (по соображениям «зачем объединять Interix, но не MKS Toolkit?»), я собираюсь пойти дальше и разместить это в WP:AN , чтобы они решили, закрыть ли слиянием, закрыть с текущим статусом или определить новый консенсус. //  coldacid ( talk | contrib ) 01:16, 13 марта 2015 (UTC) [ ответить ]
В списке . //  coldacid ( обсуждение | вклад ) 01:28, 13 марта 2015 (UTC) [ ответить ]
  • Oppose . Interix сформировал ядро ​​3.x версий Windows Services для UNIX, но обе системы существовали и до этого, и поэтому их не следует считать одним и тем же. //  coldacid ( talk | contrib ) 17:28, 14 марта 2015 (UTC) [ ответить ]
  • Oppose . Interix является частью некоторых выпусков Windows Services for UNIX (но не всех). Версии Interix выпускались отдельно (как до, так и после Windows Services for UNIX). Объединение этих двух систем привело бы к серьезному искажению. Это было бы аналогично объединению MS-DOS и Microsoft Windows , поскольку DOS является частью некоторых выпусков Windows (но DOS изначально существовал сам по себе, а Windows продолжал существовать без него). 50.126.125.240 ( talk ) 10:48, 23 мая 2015 (UTC) [ reply ]
Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.

Изменение названия статьи

Текущая версия называется "Подсистема для приложений на базе UNIX". Нет причин, по которым эта статья должна придерживаться старого названия. Его следует переместить, чтобы отразить изменения около 2003 года. 99.253.232.40 (обсуждение) 03:18, 8 августа 2009 (UTC) [ ответить ]

Что? www.microsoft.com/downloads: "Сведения о загрузке: Windows Services for UNIX Version 3.5" [4] — Предыдущий неподписанный комментарий добавлен 218.214.18.240 ( обсуждение ) 08:25, 4 октября 2009 (UTC) [ ответить ]
Он был переименован в SUA для Windows 2003 R2, [5] которая включила его на Диск 2. Они также утверждают, что он был переработан на этом этапе, например, чтобы разрешить связывание библиотек Win32. [6] Загрузка Vista называется SUA [7], как и для Windows 7 [8]. FuFoFuEd ( обсуждение ) 07:42, 30 мая 2011 (UTC) [ ответ ]

Подсистема Posix больше не является процессом режима ядра

Поскольку Microsoft удалила подсистему OS2, подсистема Posix была удалена из режима ядра в Vista и Windows 7.

http://download.microsoft.com/download/3/C/4/3C4C7C9C-AAA0-4BD4-9C14-5BA29BDD7D4C/sua.pdf "Interix — это процесс Win32"

Shjacks45 ( обсуждение ) 01:42, 22 апреля 2010 (UTC) [ ответить ]

Этого утверждения нет в предоставленном вами источнике. Там просто говорится, что Interix работал поверх Win32, когда он был впервые разработан, и что SUA является заменой старой подсистемы POSIX.
Мне нравится эта часть документа:

«Для дальнейшего взаимодействия с программистами UNIX и ПО с открытым исходным кодом, а также системными администраторами, использующими эту технологию, команда SUA предоставила пользователям исходный код изменений GCC и GNU, а также двоичные файлы».

Как будто у них был выбор.
169.231.16.35 (обсуждение) 04:26, 6 мая 2010 (UTC) [ ответить ]

«Подсистема Interix обеспечивает полностью совместимую с POSIX среду, которая работает как собственная подсистема в ядре Windows». http://support.microsoft.com/kb/324539/EN-US — Предыдущий неподписанный комментарий добавлен 203.206.162.148 ( обсуждение ) 01:12, 8 марта 2011 (UTC) [ ответить ]

Ядро Windows не запускает подсистемы, эта страница неверна. Оно всегда было «родным» приложением и стало приложением Win32 в Vista и более поздних версиях для поддержки межсистемных вызовов. В обоих случаях драйвер (psxdrv.sys) используется для предоставления дополнительных функций, но это не подсистема в собственном смысле. — Предыдущий неподписанный комментарий добавлен 80.194.88.34 ( обсуждение ) 11:47, 11 октября 2012 (UTC) [ ответить ]

НФС в 2012 R2

Похоже, они уволили или переназначили всю команду (2-3 человека), поскольку все они прекратили вести блог в конце 2012 года [9]. Кто-то не использовал свое настоящее имя ( обсуждение ) 07:51, 10 января 2014 (UTC) [ ответить ]

Здравствуйте, уважаемые википедисты!

Я только что добавил архивные ссылки на одну внешнюю ссылку на Windows Services for UNIX . Пожалуйста, уделите немного времени, чтобы просмотреть мою правку. Если необходимо, добавьте после ссылки, чтобы я не мог ее изменить. Или же вы можете добавить, чтобы я вообще не попадал на страницу. Я внес следующие изменения:{{cbignore}}{{nobots|deny=InternetArchiveBot}}

  • Добавлен архив https://web.archive.org/20050510025015/http://www.microsoft.com:80/windowsserver2003/R2/unixcomponents/default.mspx в http://www.microsoft.com/windowsserver2003/R2/unixcomponents/default.mspx

Когда вы закончите просматривать мои изменения, пожалуйста, установите отмеченный параметр ниже на значение true, чтобы сообщить об этом другим.

проверятьY Редактор проверил эту правку и исправил все обнаруженные ошибки.

  • Если вы обнаружили URL-адреса, которые бот ошибочно посчитал неработающими, вы можете сообщить о них с помощью этого инструмента.
  • Если вы обнаружили ошибку в архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента.

Привет.— cyberbot II Поговорить с моим владельцем : Онлайн 09:01, 10 января 2016 (UTC) [ ответить ]

Windows 8.1 и Sever 2012 и более поздние версии

В статье неясно, было ли удаление [большинства] этих функций в Windows 8.1 и Windows Server 2012 R2 заменено чем-то другим (либо в этих выпусках, либо в Windows 10 и Windows Server 2016). Вероятно, следует прояснить для читателей, какие Unix-подобные инструменты доступны в этих ОС (сейчас, и включая предстоящие bash и Ubuntu на Windows, по крайней мере в Windows 10, которая уже работает в сборках для разработчиков).  —  SMcCandlish ¢  ≽ ʌ ⱷ҅ ʌ ≼  08:40, 13 июня 2016 (UTC) [ ответить ]

"и включая предстоящие bash и Ubuntu на Windows, по крайней мере в Windows 10, которые уже работают в сборках для разработчиков" Т.е. упомянуть подсистему Windows для Linux где-нибудь, кроме как в заметке в шапке и разделе "См. также". Гай Харрис ( обсуждение ) 16:56, 13 июня 2016 (UTC) [ ответить ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Windows_Services_for_UNIX&oldid=1206057089"