Как, вероятно, известно нескольким людям, компания Microsoft сделала фреймворк приложений .NET открытым исходным кодом.
Означает ли это, что можно будет запускать больше программ Windows на Linux и каким-то образом ускорить Wine путем прямой интеграции API? Или это больше похоже на систему разработки, которую невозможно будет изначально интегрировать, чтобы она работала так же гладко, как программы, написанные для использования bash?
Я использовал Wine и обнаружил, что даже в дистрибутивах, где он изначально установлен, он в конечном итоге работает медленно даже для самых простых программ, а с виртуальными дисками и т. п. его использование становится мучением. Можно ли будет интегрировать API на уровне ядра, может быть, изменить пару вещей, чтобы слеши представлялись по-другому, и добавить сообщенную версию Windows и позволить им работать так, как они будут работать изначально? Если кто-то думает, что это станет возможным только после того, как свиньи полетят сами по себе, пожалуйста, скажите мне, что это никогда не сработает, но я хотел бы знать конкретно, почему это будет или не будет работать, а не просто односложный ответ.
решение1
При чем тут вино? Давайте на минутку забудем об этом.
Microsoft открывает исходный код основных частей .NET, а также делает ASP.NET более открытым исходным кодом, чем он был раньше. Сами по себе эти две части позволят вам создавать приложения командной строки и веб-сайты ASP.NET. Если у вас есть такие приложения, то в конечном итоге должно быть возможно создавать цели Linux (если это вообще требуется) и запускать их нативно в Ubuntu.
Тем не менее, для создания чего-то вроде приложения с графическим интерфейсом требуется целый парк компонентов .NET. В Windows разработчики используют такие вещи, как Windows Presentation Foundation, чтобы рисовать на экране. В Mono мы можем использовать такие вещи, как GTK# и Qt#. Если вам нужно кроссплатформенное приложение, вам нужен кроссплатформенный набор инструментов.
Это очень длинный способ сказать, что изначально мало что изменится. Разработчики могли использовать Mono и раньше, если им нужны были кроссплатформенные приложения, и они все еще могут это делать. В будущем, возможно, будет проще вставить наборы инструментов Mono в проект VS.NET, или MS заменит WPF на кроссплатформенный набор инструментов.
Возвращаемся к Wine. Приложению .NET, работающему в Wine, все равно понадобится что-то, что предоставит ему библиотеки представления, и (если это собственные библиотеки Windows) им все равно придется идтичерезWine, поэтому для них предоставляется правильная среда. Wine по-прежнему является связующим звеном между приложением и оборудованием (ну, виртуальным оборудованием через Linux), на котором находится .NET. Я не вижу, чтобы это соглашение изменилось в ближайшее время.