Вот люди пишут Wine, GNUStep, Cocotron, Reactos... мучаются с хакинтошами (вот я вчера поиграл немножко... новый OSX на реальной машине и то тормозит, на виртуалке так вообще запускаться не хочет).

А насколько реально написать, к примеру, некое дополнение к ядру Линукса, которое бы воспроизводило функционал ядра Windows и OSX?
В пользу этого варианта говорит то, что ядро ОС всяко меньше чем все остальное API. И тем ни менее люди пишут Wine (который как раз "все остальное API"), который вполне успешно запускает виндовые программы. Не все, но тем ни менее оно работает.

Итак, имеем некое дополнение к ядру линукса; дальше берем виндовсый установочный диск, вставляем в привод — и запускаем специальную нашу утилиту "установки", которая копирует с диска файлы и раскладывает их по папкам (Windows, Program Files и т.д) в специальной директории. В результате имеем Винду с полным набором своих родных DLL, но внутри линукса, используя от линукса только самый низкий уровень — т.е. ядро. Аналогично с макосью.

Просьба оценить — насколько такой проект был бы реален и выгоден в сравнении с тем же Wine? Может уже есть что-то подобное?
(Есть проект AndLinux который встраивает Linux в Windows, но там несколько другой подход- само ядро линукса собрано как драйвер; т.к. исходники линукса открыты, то с этим проще; макось в винду таким способом к сожалению не встроить)

Здравствуйте, x-code, Вы писали:


XC>Итак, имеем некое дополнение к ядру линукса; дальше берем виндовсый установочный диск, вставляем в привод — и запускаем специальную нашу утилиту "установки", которая копирует с диска файлы и раскладывает их по папкам (Windows, Program Files и т.д) в специальной директории. В результате имеем Винду с полным набором своих родных DLL, но внутри линукса
XC>Может уже есть что-то подобное?
Конечно есть. Только без линукса. Способ был даже популярным. Делается всё как ты написал: берётся установочный диск какой-нибудь windows home, "утилита установки" вводит серийный ключ или ещё что-то там делает, и вот у тебя уже с одного диска установилась лицензионная версия Windows на два (или более) компьютера. Ну может юристы считают, что она не совсем лицензионная, но выглядит-то и работает как настоящая. И, опять же, копировать дальше без линукса можно :) Но если хочешь, то можешь свою утилиту по копированию и "дополнением к ядру линукса" сделать — на лицензионность это не повлияет.

Здравствуйте, x-code, Вы писали:
XC>А насколько реально написать, к примеру, некое дополнение к ядру Линукса, которое бы воспроизводило функционал ядра Windows и OSX?
Да, и такого написано вагон и маленькая тележка.

XC>Итак, имеем некое дополнение к ядру линукса; дальше берем виндовсый установочный диск, вставляем в привод — и запускаем специальную нашу утилиту "установки", которая копирует с диска файлы и раскладывает их по папкам (Windows, Program Files и т.д) в специальной директории. В результате имеем Винду с полным набором своих родных DLL, но внутри линукса, используя от линукса только самый низкий уровень — т.е. ядро. Аналогично с макосью.

Гуглить по словам Virtual Machine.
Запустить "ядро windows" в "ядре Linux" можно только таким образом — потому что "ядро windows" полагается на то, что именно оно является единственным и неповторимым менеджером всего.
Изолировать его от ядра другой ОС можно исключительно при помощи гипервизора.

Здравствуйте, Sinclair, Вы писали:

S>Гуглить по словам Virtual Machine.
S>Запустить "ядро windows" в "ядре Linux" можно только таким образом — потому что "ядро windows" полагается на то, что именно оно является единственным и неповторимым менеджером всего.
S>Изолировать его от ядра другой ОС можно исключительно при помощи гипервизора.

Ну с виртуалками понятно, там мы целиком ставим одну систему в виртуальное окружение. Для этого крайне желательна аппаратная поддержка (по крайней мере OSX не работает в виртуалке на системах без аппаратной виртуализации). qemu вообще эмулирует аппаратный процессор.
Интересно другое — можно ли сделать замену ядра той же винды на самописный аналог (скажем на базе линукса) безболезненно для самой винды (для той части которая останется)? То есть — какова минимальная часть ядра Windows, которую можно заменить на нечто самописное, чтобы остальная часть работала в рамках другой ОС, причем без виртуализации?

Здравствуйте, x-code, Вы писали:
XC>Интересно другое — можно ли сделать замену ядра той же винды на самописный аналог (скажем на базе линукса) безболезненно для самой винды (для той части которая останется)?
Cамописанный аналог — можно. На базе линукса — нет.
XC> То есть — какова минимальная часть ядра Windows, которую можно заменить на нечто самописное, чтобы остальная часть работала в рамках другой ОС, причем без виртуализации?
АФАИК, весь userspace API.

Здравствуйте, x-code, Вы писали:

S>>Гуглить по словам Virtual Machine.
S>>Запустить "ядро windows" в "ядре Linux" можно только таким образом — потому что "ядро windows" полагается на то, что именно оно является единственным и неповторимым менеджером всего.
S>>Изолировать его от ядра другой ОС можно исключительно при помощи гипервизора.

XC>Ну с виртуалками понятно, там мы целиком ставим одну систему в виртуальное окружение. Для этого крайне желательна аппаратная поддержка (по крайней мере OSX не работает в виртуалке на системах без аппаратной виртуализации). qemu вообще эмулирует аппаратный процессор.
XC>Интересно другое — можно ли сделать замену ядра той же винды на самописный аналог (скажем на базе линукса) безболезненно для самой винды (для той части которая останется)? То есть — какова минимальная часть ядра Windows, которую можно заменить на нечто самописное, чтобы остальная часть работала в рамках другой ОС, причем без виртуализации?

Легальный статус wine до сих пор под вопросом. Microsoft в любой момент может его закрыть, т.к. они копируют API, а это интеллектуальная собственность. Или нет, но зона очень серая. Аналогичный спор был между Oracle и Google насчёт Java, Google пока победил, но за wine-ом нет гугла.

Если кто-то будет копировать вендовые проприетарные userland dll-ки непонятно куда, это уже чёткое и прямое нарушение копирайта. Нет такого права у пользователя. Поэтому легальный статус такого проекта будет очень спорным.

А в целом задача абсолютно решаемая, что тут такого. Пишем windows kernel api как linux kernel module и всё. Китайцы какие-то это даже делали.

Здравствуйте, x-code, Вы писали:

То есть — какова минимальная часть ядра Windows, которую можно заменить на нечто самописное, чтобы остальная часть работала в рамках другой ОС, причем без виртуализации?
Всё целиком, от ядра хоста и до winapi. И работать оно будет на порядки медленней, чем с аппаратной виртуализацией. Для поверхностного ознакомления хватит первых вводных глав из Руссиновича, если совсем ужать до комикса — картинки отсюда.

Начать придётся с HAL, дальше по цепочке мелкие исправления расползутся вплоть до system routines. И то с оччень большой вероятностью поломается куча вещей: от drm в аудио-видеостеке и до драйверов дешёвых карточек, которые даже дуалбут не переносят.

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

Здравствуйте, vsb, Вы писали:

vsb>А в целом задача абсолютно решаемая, что тут такого. Пишем windows kernel api как linux kernel module и всё. Китайцы какие-то это даже делали.

А есть пруф? Longene вроде бы не использует родные win-библиотеки и полагается на wine. CoLinux скорее наоборот, запускает lin поверх win. ndiswrapper — просто обёртка для драйверов. Что-то ещё?

Здравствуйте, Sinix, Вы писали:

vsb>>А в целом задача абсолютно решаемая, что тут такого. Пишем windows kernel api как linux kernel module и всё. Китайцы какие-то это даже делали.

S>А есть пруф? Longene вроде бы не использует родные win-библиотеки и полагается на wine.

Ну вот видимо поэтому и полагаются, что использовать родные win-библиотеки это уже наглость высшей категории, а сказать, что мол мы используем wine это ещё нормально, а пользователи сами потом подложат нужные библиотеки. В Wine тоже для некоторых игр надо (ну или, по крайней мере, нужно было) подменять некоторые DLL-ки вендовыми, потому что родные очень уж недоделанные.

Здравствуйте, vsb, Вы писали:

vsb>Ну вот видимо поэтому и полагаются, что использовать родные win-библиотеки это уже наглость высшей категории, а сказать, что мол мы используем wine это ещё нормально, а пользователи сами потом подложат нужные библиотеки.
А, ну это уже не совсем то, о чём спрашивал топикстартер, тут скорее wine, допиленный до kernel-компонентов.

XC>А насколько реально написать, к примеру, некое дополнение к ядру Линукса, которое бы воспроизводило функционал ядра Windows и OSX?
XC>В пользу этого варианта говорит то, что ядро ОС всяко меньше чем все остальное API. И тем ни менее люди пишут Wine (который как раз "все остальное API"), который вполне успешно запускает виндовые программы. Не все, но тем ни менее оно работает.
А где возьмем юзермодное API? Из винды? А денежку за пользование ее бинарями кто платить будет? И вообще еще вопрос — допускает ли брачный контакт винды такую разновидность сексуальных отношений с ней. Не говоря уж о том что интерфейс системных вызовов как ядра, win32k и в особенности всяких драйверов не стабилен и придется постоянно париться о совместимости твоего ядра и актуальных бинарей винды.