Wino (oprogramowanie) - Wine (software)

Wino
	winecfg (konfiguracja Wine) w trybie 32-bitowym , oficjalny program konfiguracyjny dla Wine (wersja 5.5)
Pierwotny autor (autorzy)	Bob Amstadt, Eric Youngdale
Deweloper(zy)	Autorzy wina ; (1 755)
Pierwsze wydanie	4 lipca 1993 ; 28 lat temu
Wersja stabilna	6.0.1 / 7 czerwca 2021 ; 4 miesiące temu
Wersja zapoznawcza	6.19 / 8 października 2021 r .; 2 dni temu
Magazyn	źródło .winehq .org /git /wino .git
Napisane w	C
System operacyjny	Linux; ReactOS (kompatybilny z aplikacją Windows i sterownikiem); macOS ( 10.9 – 10.14 ) (rozwój); Android (eksperymentalny);
Platforma	x86-32 , x86-64 , ARM
Dostępne w	Wielojęzyczny
Rodzaj	Warstwa kompatybilności
Licencja	LGPLv2.1+
Strona internetowa	winehq .org

Wine ( recursive backronim dla Wine Is Not an Emulator ) to bezpłatna warstwa kompatybilności o otwartym kodzie źródłowym , która ma na celu umożliwienie uruchamiania aplikacji i gier komputerowych opracowanych dla systemu Microsoft Windows w systemach operacyjnych typu Unix . Wine udostępnia również bibliotekę oprogramowania o nazwie Winelib , na podstawie której programiści mogą kompilować aplikacje Windows, aby pomóc w przenoszeniu ich do systemów uniksopodobnych.

Wino zapewnia jej warstwy zgodności dla Windows systemu wykonawczego (zwany także środowiska wykonawczego), co przekłada Okna wywołań systemowych język POSIX zgodny ze wywołań systemowych , odtwarzając strukturę katalogów Windows oraz zapewnienie alternatywnych implementacji systemu Windows bibliotek systemowych , usług systemowych przez wineserveri różne inne składniki (takich jak Internet Explorer , Edytor rejestru Windows i msiexec ). Wine jest głównie napisane przy użyciu inżynierii wstecznej testowania czarnoskrzynkowego , aby uniknąć problemów z prawami autorskimi .

Wybór "Wino nie jest emulatorem" jako nazwy projektu Wine był wynikiem dyskusji na temat nazewnictwa w sierpniu 1993 roku i przypisywany jest Davidowi Niemi. Istnieje pewne zamieszanie spowodowane wczesnymi często zadawanymi pytaniami dotyczącymi emulatora systemu Windows i innymi nieprawidłowymi źródłami, które pojawiają się po ustawieniu nazwy projektu Wine. Nie emulacja kodu lub wirtualizacji występuje podczas uruchamiania systemu Windows aplikacji pod Wine. „Emulacja” zwykle odsyła do wykonania z skompilowanego kodu przeznaczonego dla jednego procesora (jak x86 ) przez interpretowanie / rekompilacji oprogramowania uruchomionego na innym procesorze (takich jak PowerPC ). Chociaż nazwa czasami pojawia się w formach WINE i wine , twórcy projektu zgodzili się na standaryzację w formie Wine .

Wine jest przede wszystkim rozwijane dla systemów Linux i macOS , a od lipca 2020 r. dostępne są dobrze utrzymane pakiety dla obu platform.

W ankiecie przeprowadzonej w 2007 r. przez desktoplinux.com wśród 38 500 użytkowników komputerów stacjonarnych z Linuksem, 31,5% respondentów przyznało, że używa Wine do uruchamiania aplikacji Windows. Ta różnorodność była większa niż wszystkich programów do wirtualizacji x86 łącznie, a także większa niż 27,9%, które zgłosiły, że nie działają aplikacje Windows.

Historia

Bob Amstadt, początkowy lider projektu, i Eric Youngdale rozpoczęli projekt Wine w 1993 roku jako sposób na uruchamianie aplikacji Windows na Linuksie . Został zainspirowany dwoma produktami Sun Microsystems , Wabi dla systemu operacyjnego Solaris oraz Public Windows Initiative , która była próbą pełnego ponownego zaimplementowania Windows API w domenie publicznej jako standardu ISO, ale została odrzucona z powodu nacisków Microsoftu. w 1996 roku. Początkowo Wine atakowało 16-bitowe aplikacje dla Windows 3.x , ale od 2010 roku koncentruje się na wersjach 32-bitowych i 64-bitowych, które stały się standardem w nowszych systemach operacyjnych. Projekt powstał podczas dyskusji na Usenet w comp.os.linux w czerwcu 1993 roku. Alexandre Julliard kieruje projektem od 1994 roku.

Projekt okazał się czasochłonny i trudny dla programistów, głównie ze względu na niekompletną i niepoprawną dokumentację Windows API. Podczas gdy Microsoft obszernie dokumentuje większość funkcji Win32 , niektóre obszary, takie jak formaty plików i protokoły , nie mają publicznie dostępnych specyfikacji Microsoft, a Windows zawiera również nieudokumentowane funkcje niskiego poziomu, nieudokumentowane zachowanie i ukryte błędy, które Wine musi dokładnie powielać, aby umożliwić niektórym aplikacjom działać prawidłowo. W związku z tym zespół Wine dokonał inżynierii wstecznej wielu wywołań funkcji i formatów plików w takich obszarach, jak thunking .

Projekt Wine pierwotnie wydał Wine na tej samej licencji MIT, co X Window System, ale ze względu na obawy związane z zastrzeżonymi wersjami Wine, które nie wnoszą swoich zmian z powrotem do głównego projektu, prace od marca 2002 r. używały licencji LGPL do jego licencjonowania.

Wine oficjalnie weszło do bety z wersją 0.9 25 października 2005. Wersja 1.0 została wydana 17 czerwca 2008, po 15 latach rozwoju. Wersja 1.2 została wydana 16 lipca 2010 r., wersja 1.4 7 marca 2012 r., wersja 1.6 18 lipca 2013 r., a wersja 1.8 19 grudnia 2015 r. Wersje rozwojowe są wydawane mniej więcej co dwa tygodnie.

Wine-staging to niezależnie utrzymywany zestaw agresywnych łat, które nie są uważane przez programistów WineHQ za gotowe do połączenia z repozytorium Wine, ale nadal są uważane za przydatne przez widelec wine-compholio. Obejmuje głównie funkcje eksperymentalne i poprawki błędów. Od stycznia 2017 r. łatki w inscenizacji wina zaczynają być aktywnie łączone z upstream WineHQ, ponieważ wine-compholio przeniosło projekt do Alistair Leslie-Hughes, kluczowego dewelopera WineHQ.

Sponsoring korporacyjny

Głównym sponsorem korporacyjnym Wine jest CodeWeavers , który zatrudnia Julliarda i wielu innych programistów Wine do pracy nad Wine i CrossOver , wspieraną przez CodeWeavers wersją Wine. CrossOver zawiera kilka ulepszeń specyficznych dla aplikacji, które nie są uważane za odpowiednie dla pierwotnej wersji, a także kilka dodatkowych, zastrzeżonych komponentów.

Zaangażowanie firmy Corel przez pewien czas wspomagało projekt, głównie poprzez zatrudnienie Julliarda i innych do pracy nad nim. Corel miał interes w przenoszeniu WordPerfect Office , jego pakiet biurowy , Linux (szczególnie Corel Linux ). Corel później anulował wszystkie projekty związane z Linuksem po tym, jak Microsoft poczynił duże inwestycje w Corel, przerywając wysiłki Wine.

Inni sponsorzy korporacyjni to Google , który wynajął CodeWeavers do naprawy Wine, dzięki czemu Picasa działała na tyle dobrze, że można go było przenieść bezpośrednio do Linuksa przy użyciu tego samego pliku binarnego, co w systemie Windows; Google zapłacił później za ulepszenia obsługi programu Wine dla programu Adobe Photoshop CS2 . Wine jest również stałym beneficjentem programu Google Summer of Code .

Projekt

Celem Wine jest pełne lub częściowe zaimplementowanie API Windows, które jest wymagane przez programy, które użytkownicy Wine chcą uruchamiać na systemie uniksopodobnym.

Podstawowa architektura

Interfejs programistyczny Microsoft Windows składa się głównie z bibliotek dołączanych dynamicznie (DLL). Zawierają one ogromną liczbę podprogramów opakowujących dla wywołań systemowych jądra, programu trybu jądra NTOS (ntoskrnl.exe). Typowy program Windows wywołuje niektóre biblioteki DLL systemu Windows, które z kolei wywołują biblioteki gdi/user32 trybu użytkownika, które z kolei wykorzystują kernel32.dll (podsystem win32) odpowiedzialny za obsługę jądra poprzez wywołania systemowe. Warstwa wywołań systemowych jest uważana za prywatną dla programistów firmy Microsoft, ponieważ dokumentacja nie jest publicznie dostępna, a wszystkie opublikowane interfejsy opierają się na podsystemach działających na jądrze. Oprócz tego istnieje szereg interfejsów programistycznych zaimplementowanych jako usługi, które działają jako oddzielne procesy. Aplikacje komunikują się z usługami trybu użytkownika za pośrednictwem RPC.

Wine implementuje interfejs binarny aplikacji Windows (ABI) całkowicie w przestrzeni użytkownika , a nie jako moduł jądra . Wine w większości odzwierciedla hierarchię, z usługami zwykle dostarczanymi przez jądro w systemie Windows zamiast zapewnianymi przez demona zwanego wineserver, którego zadaniem jest implementacja podstawowych funkcji systemu Windows, a także integracja z systemem X Window i tłumaczenie sygnałów na natywny Wyjątki Windows. Chociaż Wineserver implementuje niektóre aspekty jądra Windows , nie jest możliwe użycie z nim natywnych sterowników Windows, ze względu na podstawową architekturę Wine. Uniemożliwia to działanie niektórych aplikacji i gier, na przykład tych korzystających z ochrony przed kopiowaniem StarForce, która wymaga zainstalowania sterowników urządzeń wirtualnych .

Biblioteki i aplikacje

Wine pozwala na ładowanie zarówno bibliotek DLL systemu Windows, jak i obiektów współdzielonych systemu Unix dla swoich programów systemu Windows. Jego wbudowana implementacja najbardziej podstawowych bibliotek DLL systemu Windows , a mianowicie NTDLL , KERNEL32 , GDI32 i USER32 , wykorzystuje metodę obiektu współdzielonego, ponieważ muszą one również korzystać z funkcji w systemie operacyjnym hosta. Biblioteki wyższego poziomu, takie jak WineD3D, mogą swobodnie korzystać z formatu DLL. W wielu przypadkach użytkownicy mogą wybrać ładowanie biblioteki DLL z systemu Windows zamiast tej zaimplementowanej przez Wine. Może to zapewnić funkcje, które nie zostały jeszcze zaimplementowane przez Wine, ale może również spowodować awarię, jeśli opiera się na czymś innym, czego nie ma w Wine.

Wine śledzi stan implementacji poprzez zautomatyzowane testy jednostkowe wykonywane przy każdym zatwierdzeniu git.

Grafika i gry

Podczas gdy większość oprogramowania biurowego nie korzysta ze złożonych graficznych interfejsów API akcelerowanych przez GPU, gry komputerowe to robią. Aby poprawnie uruchomić te gry, Wine musiałby przekazać instrukcje rysowania do systemu operacyjnego hosta, a nawet przetłumaczyć je na coś, co host może zrozumieć.

DirectX to zbiór interfejsów API firmy Microsoft do renderowania, dźwięku i wprowadzania danych. Od 2019 roku Wine 4.0 zawiera implementację DirectX 12 dla Vulkan API oraz DirectX 11.2 dla OpenGL. Wine 4.0 umożliwia również Wine uruchamianie aplikacji Vulkan poprzez przekazywanie poleceń rysowania do systemu operacyjnego hosta lub, w przypadku macOS, poprzez tłumaczenie ich na Metal API przez MoltenVK .

XAudio: Od lutego 2019 r. Wine 4.3 używa biblioteki FAudio (i Wine 4.13 zawiera poprawkę) do implementacji API audio XAudio2 (i nie tylko).
XInput i surowe dane wejściowe: Wine od 4.0 (2019) wspiera kontrolery gier poprzez wbudowane implementacje tych bibliotek. Są one budowane jako obiekty współdzielone Unix, ponieważ potrzebują dostępu do interfejsów kontrolera bazowego systemu operacyjnego, w szczególności poprzez SDL .
Direct2D: Wine 4.0 obsługuje Direct2D 1.2.

Direct3D

Większość wysiłków związanych z DirectX Wine polega na zbudowaniu WineD3D, warstwy tłumaczenia z wywołań API Direct3D i DirectDraw do OpenGL . Od 2019 r. ten komponent obsługuje do DirectX 11. Od 12 grudnia 2016 r. Wine jest wystarczająco dobre, aby uruchomić Overwatch z D3D11. Oprócz tego, że są używane w Wine, biblioteki DLL WineD3D były również używane w samym systemie Windows, umożliwiając starszym procesorom graficznym uruchamianie gier przy użyciu nowszych wersji DirectX i starych gier opartych na DDraw, aby działały poprawnie.

Trwają prace nad przeniesieniem zaplecza Direct3D do Vulkan API. Obsługa Direct3D 12 w wersji 4.0 jest zapewniana przez podprojekt „vkd3d”, a WineD3D w 2019 roku zostało eksperymentalnie przeniesione do korzystania z API Vulkan. Inna implementacja, DXVK, tłumaczy wywołania Direct3D 9, 10 i 11 również za pomocą Vulkan i jest osobnym projektem.

Wine, po załataniu, może alternatywnie uruchamiać polecenia API Direct3D 9 bezpośrednio za pomocą bezpłatnego i otwartego oprogramowania Gallium3D State Tracker (znanego również jako sterownik GPU Gallium3D) bez tłumaczenia na wywołania API OpenGL. W tym przypadku warstwa Gallium3D umożliwia bezpośrednie przekazywanie poleceń rysowania DX9, co skutkuje poprawą wydajności nawet o współczynnik 2. Od 2020 roku projekt nosi nazwę Gallium.Nine. Jest teraz dostępny jako osobny, samodzielny pakiet i nie wymaga już poprawionej wersji Wine.

Interfejs użytkownika

Wine jest zwykle wywoływane z interpretera wiersza poleceń: wine program.exe.

winecfg

Zrzut ekranu pokazujący, jak można skonfigurować Wine do naśladowania różnych wersji systemu Windows, począwszy od systemu Windows 2.0 w wersji 32-bitowej (64-bitowe Wine obsługuje tylko 64-bitowe wersje systemu Windows)

Jest narzędzie, winecfgktóre uruchamia graficzny interfejs użytkownika z kontrolkami do regulacji podstawowych opcji. Jest to narzędzie konfiguracyjne GUI dołączone do Wine. Winecfg ułatwia konfigurowanie Wine, eliminując konieczność bezpośredniej edycji rejestru, chociaż w razie potrzeby można to zrobić za pomocą dołączonego edytora rejestru (podobnego do regedit w systemie Windows ).

Aplikacje innych firm

Graj na Linuksie

Niektóre aplikacje wymagają więcej poprawek niż zwykła instalacja aplikacji, aby działały poprawnie, na przykład ręczna konfiguracja Wine do korzystania z niektórych bibliotek DLL systemu Windows . Projekt Wine nie integruje takich obejścia z bazą kodu Wine, zamiast tego woli skupić się wyłącznie na ulepszaniu implementacji Windows API . Chociaż takie podejście koncentruje rozwój Wine na długoterminowej zgodności, utrudnia użytkownikom uruchamianie aplikacji wymagających obejścia. W związku z tym stworzono wiele aplikacji innych firm, aby ułatwić korzystanie z tych aplikacji, które nie działają po wyjęciu z pudełka w samym Wine. Wiki Wine utrzymuje stronę z aktualnymi i przestarzałymi aplikacjami innych firm.

Winetricks to skrypt do instalowania podstawowych komponentów (zwykle Microsoft DLL i czcionek) i dostrajania ustawień wymaganych do prawidłowego działania niektórych aplikacji pod Wine. Może w pełni zautomatyzować instalację wielu aplikacji i gier, w tym zastosować wszelkie potrzebne obejścia. Winetricks ma GUI . Projekt Wine zaakceptuje raporty o błędach dla użytkowników Winetricks, w przeciwieństwie do większości aplikacji innych firm. Jest utrzymywany przez programistę Wine Austin English.
Q4Wine to otwarty GUI do zaawansowanej konfiguracji Wine.
Wine-Doors to narzędzie do zarządzania aplikacjami dla pulpitu GNOME, które dodaje funkcjonalność do Wine. Wine-Doors to alternatywa dla WineTools, która ma na celu ulepszenie funkcji WineTools i rozszerzenie oryginalnego pomysłu z bardziej nowoczesnym podejściem do projektowania.
IEs4Linux to narzędzie do instalacji wszystkich wersji Internet Explorera, w tym wersji od 4 do 6 i wersji 7 (w wersji beta).
Wineskin to narzędzie do zarządzania wersjami silnika Wine i tworzenia opakowań dla systemu macOS .
PlayOnLinux to aplikacja ułatwiająca instalację aplikacji Windows (głównie gier). Istnieje również odpowiednia wersja dla komputerów Macintosh o nazwie PlayOnMac .
Lutris to aplikacja typu open source do łatwego instalowania gier Windows w systemie Linux.
Bordeaux to zastrzeżony menedżer konfiguracji Wine GUI, który uruchamia aplikacje winelib. Obsługuje również instalację narzędzi innych firm, instalację aplikacji i gier oraz możliwość korzystania z niestandardowych konfiguracji. Bordeaux obecnie działa na komputerach z systemami Linux, FreeBSD, PC-BSD, Solaris, OpenSolaris, OpenIndiana i macOS.
Bottles jest graficznym prefiksem wine o otwartym kodzie źródłowym i menedżerem runnerów dla Wine opartym na GTK. Zapewnia oparty na repozytorium system instalacji zależności i wersjonowanie butelek w celu przywrócenia poprzedniego stanu.

Funkcjonalność

Postęp kompatybilności aplikacji w wersji 0.9, zgodnie z wynikami testów Wine AppDB.

Oprogramowanie działa bez zarzutu

Oprogramowanie działa bezbłędnie po konfiguracji

Drobne problemy z oprogramowaniem

Główne problemy z oprogramowaniem

Całkowicie niefunkcjonalne oprogramowanie

Twórcy części Wine Direct3D nadal wdrażają nowe funkcje, takie jak shadery pikseli, aby zwiększyć wsparcie dla gier. Wine może również bezpośrednio korzystać z natywnych bibliotek DLL, zwiększając w ten sposób funkcjonalność, ale wtedy potrzebna jest licencja dla systemu Windows, chyba że biblioteki DLL były dystrybuowane z samą aplikacją.

Wine zawiera również własne implementacje open-source kilku programów Windows, takich jak notepad , wordpad , control , iexplore i explorer .

Wine Application Database (AppDB) to utrzymywana przez społeczność internetowa baza danych o tym, które programy Windows współpracują z Wine i jak dobrze działają.

Kompatybilność wsteczna

Wine zapewnia dobrą kompatybilność wsteczną ze starszymi aplikacjami Windows, w tym tymi napisanymi dla Windows 3.1x . Wine może naśladować różne wersje systemu Windows wymagane dla niektórych programów, począwszy od wersji 2.0 systemu Windows. Jednak obsługa Windows 1.x i Windows 2.x została usunięta z wersji rozwojowej Wine 1.3.12. Jeśli DOSBox jest zainstalowany w systemie (patrz poniżej na MS-DOS ), Wine w wersji rozwojowej 1.3.12 i nowszej mimo to pokazuje opcję "Windows 2.0" dla wersji Windows, aby naśladować, ale Wine nadal nie będzie uruchamiać większości programów Windows 2.0, ponieważ Funkcje MS-DOS i Windows nie są obecnie zintegrowane.

Kompatybilność wsteczna w Wine jest generalnie lepsza niż w systemie Windows, ponieważ nowsze wersje systemu Windows mogą zmusić użytkowników do uaktualniania starszych aplikacji Windows i mogą na zawsze zepsuć porzucone oprogramowanie, ponieważ nikt nie dostosowuje programu do zmian w systemie operacyjnym. W wielu przypadkach Wine może zaoferować lepszą obsługę starszych wersji niż nowsze wersje systemu Windows z „trybem zgodności”. Wine może uruchamiać 16-bitowe programy Windows ( Win16 ) w 64-bitowym systemie operacyjnym, który używa procesora x86-64 (64-bitowego), czego nie można znaleźć w 64-bitowych wersjach systemu Microsoft Windows. WineVDM umożliwia uruchamianie 16-bitowych aplikacji Windows w 64-bitowych wersjach systemu Windows.

Wine częściowo obsługuje aplikacje konsolowe Windows , a użytkownik może wybrać, którego zaplecza będzie używać do zarządzania konsolą (do wyboru są strumienie surowe, curses i user32 ). Podczas korzystania z surowych strumieni lub backendów curses aplikacje Windows będą działać na terminalu uniksowym.

Aplikacje 64-bitowe

Wstępne wsparcie dla 64-bitowych aplikacji Windows zostało dodane do Wine 1.1.10 w grudniu 2008. Od kwietnia 2019 wsparcie jest uważane za stabilne. Dwie wersje wine są budowane oddzielnie, w wyniku czego tylko budowanie wine64 daje środowisko zdolne tylko do uruchamiania aplikacji x86-64.

Od kwietnia 2019 r. Wine ma stabilną obsługę kompilacji WoW64 , która umożliwia uruchamianie zarówno 32-bitowych, jak i 64-bitowych aplikacji Windows w tej samej instancji Wine. Aby wykonać taką kompilację, należy najpierw zbudować wersję 64-bitową, a następnie wersję 32-bitową odwołującą się do wersji 64-bitowej. Podobnie jak w przypadku WoW64 firmy Microsoft, proces kompilacji 32-bitowej doda części niezbędne do obsługi programów 32-bitowych do kompilacji 64-bitowej. Ta funkcjonalność jest widoczna od co najmniej 2010 roku.

MS-DOS

Wczesne wersje systemu Microsoft Windows działają w oparciu o system MS-DOS , a ich użytkowanie może zależeć od programów systemu Windows. Wino nie posiada dobre wsparcie dla MS-DOS, ale wychodząc z rozwojowej wersji 1.3.12, wino próbuje uruchamianie programów MS-DOS w DOSBox jeśli DOSBox jest dostępny w systemie. Jednak z powodu błędu obecne wersje Wine błędnie identyfikują programy Windows 1.xi Windows 2.x jako programy MS-DOS, próbując je uruchomić w DOSBox (co nie działa).

Winelib

Wine dostarcza bibliotekę Winelib, która pozwala na używanie implementacji Windows API jako rzeczywistych bibliotek dla programów uniksowych. Pozwala to na wbudowanie kodu systemu Windows w natywne pliki wykonywalne systemu Unix. Od października 2010 Winelib działa również na platformie ARM .

Architektury inne niż x86

Wsparcie dla Solaris SPARC zostało usunięte w wersji 1.5.26.

ARM, Windows CE i Windows RT

Wine zapewnia wsparcie dla procesorów ARM (jak również ARM64/AArch64) i uruchamianych na nim smaków Windows. Od kwietnia 2019 r. Wine może uruchamiać aplikacje ARM/Win32 przeznaczone dla odblokowanych urządzeń Windows RT (ale nie programów Windows RT). Brakuje obsługi Windows CE (zarówno x86, jak i ARM), ale nieoficjalna, weryfikacja koncepcji pre-alpha o nazwie WineCE pozwala na pewne wsparcie.

Wino na Androida

WINE Solitaire na Androida

3 lutego 2013 r. podczas konferencji FOSDEM w Brukseli Alexandre Julliard zademonstrował wczesną wersję demonstracyjną Wine działającego na systemie operacyjnym Google Android .

Eksperymentalne wersje WINE dla Androida (x86 i ARM) zostały wydane pod koniec 2017 roku. Od tego czasu jest ono regularnie aktualizowane przez oficjalnych programistów. Domyślne kompilacje nie implementują emulacji między architekturą za pośrednictwem QEMU , w wyniku czego wersje ARM będą uruchamiać tylko aplikacje ARM korzystające z interfejsu API Win32.

Aplikacje Microsoft

Wine domyślnie używa wyspecjalizowanych kompilacji Gecko i Mono dla systemu Windows, aby zastąpić Microsoft Internet Explorer i .NET Framework . Wine ma wbudowane implementacje JScript i VBScript . Możliwe jest pobranie i uruchomienie instalatorów Microsoftu dla tych programów za pomocą sztuczek Winetric lub ręcznie.

Wine nie ma dobrego wsparcia dla większości wersji Internet Explorera (IE). Ze wszystkich całkiem nowych wersji, Internet Explorer 8 dla Windows XP jest jedyną wersją, która zgłasza użyteczną ocenę w bazie danych AppDB Wine, po wyjęciu z pudełka. Jednak Google Chrome otrzymuje złotą ocenę (od wersji Wine 5.5), a Edge, zastępująca przeglądarkę internetową Microsoftu, jest oparta na tej przeglądarce (po przejściu z własnego silnika renderującego Microsoftu). Winetricks oferuje automatyczną instalację dla Internet Explorera od 6 do 8, więc można rozsądnie oczekiwać, że te wersje będą działać z wbudowanymi obejściami.

Alternatywą dla bezpośredniej instalacji Internet Explorera jest użycie nieistniejącego już IEs4Linux . Nie jest kompatybilny z najnowszymi wersjami Wine, a rozwój IEs4Linux jest nieaktywny.

Inne wersje wina

Rozwój rdzenia Wine ma na celu poprawną implementację Windows API jako całości i czasami ma opóźnienia w niektórych obszarach kompatybilności z niektórymi aplikacjami. Na przykład Direct3D pozostał niezaimplementowany do 1998 r., chociaż nowsze wersje mają coraz bardziej kompletną implementację.

Krzyżowanie

CodeWeavers sprzedaje CrossOver specjalnie do uruchamiania Microsoft Office i innych głównych aplikacji Windows, w tym niektórych gier. CodeWeavers zatrudnia Alexandre'a Julliarda do pracy nad Wine i wnosi większość swojego kodu do projektu Wine w ramach LGPL. CodeWeavers wydał również nową wersję o nazwie CrossOver Mac dla komputerów Apple Macintosh z procesorami Intel w dniu 10 stycznia 2007 r.

Od 2012 r. CrossOver obejmuje funkcjonalność obu linii CrossOver Games i CrossOver Pro, dlatego CrossOver Games i CrossOver Pro nie są już dostępne jako pojedyncze produkty.

CrossOver Games został zoptymalizowany pod kątem uruchamiania gier wideo w systemie Windows . W przeciwieństwie do CrossOver nie skupiał się na zapewnieniu najbardziej stabilnej wersji Wine. Zamiast tego dostępne są eksperymentalne funkcje do obsługi nowszych gier.

WINE@Etersoft

Rosyjska firma Etersoft rozwija autorski wersję Wine od 2006 roku WINA @ Etersoft obsługuje popularne aplikacje Rosyjskiej (na przykład 1C: Enterprise przez 1C Company ).

Proton

W dniu 21 sierpnia 2018 r Zawór zapowiedział nową odmianę wina o nazwie Proton, zaprojektowany do integracji z wersji linuksowej firmy pary oprogramowanie (w tym instalacje parowe wbudowane w swoich linuksowych steamos system operacyjny i maszyna parowa komputerach). Celem Valve dla Protona jest umożliwienie użytkownikom Steam na Linuksie granie w gry, które nie mają natywnego portu Linuksa (zwłaszcza gier z katalogu wstecznego), a ostatecznie, poprzez integrację ze Steam, a także ulepszenia obsługi gier w stosunku do głównej linii Wine, aby dać użytkownikom "to samo proste doświadczenie plug-and-play", które mieliby, gdyby grali w tę grę natywnie pod Linuksem. Proton wszedł do publicznej wersji beta natychmiast po ogłoszeniu.

Valve współpracowało już z CodeWeavers od 2016 roku, aby opracować ulepszenia wydajności gier Wine, z których niektóre zostały już połączone z projektem Wine. Niektóre z konkretnych ulepszeń wprowadzonych do Protona obejmują oparte na Vulkan implementacje Direct3D 9, 10, 11 i 12 za pośrednictwem vkd3d , DXVK i D9VK wielowątkowe ulepszenia wydajności dzięki esync, ulepszona obsługa gier pełnoekranowych i lepsza obsługa automatycznego kontrolera gier .

Proton jest w pełni open-source i dostępny za pośrednictwem GitHub.

Inne projekty wykorzystujące kod źródłowy Wine

Inne projekty wykorzystujące kod źródłowy Wine obejmują:

OTVDM , 16-bitowa warstwa kompatybilności aplikacji dla 64-bitowego systemu Windows.
ReactOS , projekt mający na celu napisanie systemu operacyjnego zgodnego z Windows NT w wersji 5.x i nowszych (w tym Windows 2000 i jego następców) aż do poziomu sterownika urządzenia . ReactOS w znacznym stopniu korzysta z kodu źródłowego Wine, ale ze względu na różnice architektoniczne, kod ReactOS (taki jak biblioteki DLL napisane specjalnie dla niego, takie jak ntdll, user32, kernel32, gdi32 i advapi) generalnie nie jest ponownie wykorzystywany w Wine. W lipcu 2009 roku Aleksey Bragin, lider projektu ReactOS, uruchomił nową gałąź ReactOS o nazwie Arwinss , która została oficjalnie ogłoszona w styczniu 2010 roku. Arwinss jest alternatywną implementacją podstawowych komponentów Win32 i wykorzystuje w większości niezmienione wersje user32.dll Wine'a i gdi32.dll.
WineBottler, opakowanie wokół Wine w formie normalnej Aplikacji Mac. Zarządza wieloma konfiguracjami wina dla różnych programów w formie „butelek”.
Wineskin , open source'owy menedżer konfiguracji Wine GUI dla macOS . Wineskin tworzy opakowanie wokół Wine w postaci normalnej Aplikacji Mac. Wrapper może być również użyty do stworzenia dystrybucyjnego „portu” oprogramowania.
Odin , projekt do uruchamiania plików binarnych Win32 na OS/2 lub konwertowania ich do natywnego formatu OS/2. Projekt dostarcza również Odin32 API do kompilacji programów Win32 dla OS/2.
Produkty do wirtualizacji, takie jak Parallels Desktop for Mac i VirtualBox, wykorzystują WineD3D do korzystania z GPU.
WinOnX, komercyjny pakiet Wine dla macOS, który zawiera GUI do dodawania i zarządzania aplikacjami i maszynami wirtualnymi.
WineD3D dla Windows, opakowanie kompatybilności, które emuluje stare wersje Direct3D i funkcje, które zostały usunięte przez Microsoft w ostatnich wydaniach Windows, używając OpenGL. Czasami sprawia to, że starsze gry znów działają.

Wycofane

CeCedega / WineX : TransGaming Inc. (obecnie Findev Inc. od czasu sprzedaży swoich firm programistycznych) wyprodukowała zastrzeżone oprogramowanie Cedega. Poprzednio znana jako WineX, Cedega stanowiła rozwidlenie ostatniej wersji Wine na licencji MIT w 2002 roku. Podobnie jak CrossOver Games, Cedega firmy TransGaming była nastawiona na uruchamianie gier wideo dla systemu Windows. 7 stycznia 2011 roku firma TransGaming Inc. ogłosiła dalszy rozwój technologii Cedega w ramach programu GameTree Developer Program. TransGaming Inc. zezwolił członkom na używanie identyfikatora Cedega i hasła do 28 lutego 2011 r.
Cider : TransGaming wyprodukował również Cider, bibliotekę dla komputerów Macintosh o architekturze Apple-Intel . Zamiast być produktem dla użytkownika końcowego, Cider (podobnie jak Winelib) jest opakowaniem, które pozwala programistom dostosowywać swoje gry do natywnego działania na Intel Mac bez żadnych zmian w kodzie źródłowym.
Darwine : przestarzały port bibliotek Wine do Darwin i macOS dla architektur PowerPC i Intel x86. Wszystkie łaty dla wersji x86 zostały ponownie włączone do głównej gałęzi Wine w 2009 roku. Rozwój wersji PPC został porzucony (a w 2020 Wine 5.11 zrezygnował ze wsparcia dla PowerPC.). Mike Kronenberg wcześniej stworzył WineHelper dla Darwine, aby dodać GUI i aplikację w stylu macOS do interakcji z Wine, która została później zastąpiona przez WineBottler. Darwine dostarcza teraz kompatybilne z macOS pakiety skompilowane z repozytorium Wine.
E/OS LX [ fr ] : projekt mający na celu umożliwienie uruchomienia dowolnego programu zaprojektowanego dla dowolnego systemu operacyjnego bez konieczności faktycznego instalowania jakiegokolwiek innego systemu operacyjnego.
Pipelight : niestandardowa wersja Wine (wine-compholio), która działa jako opakowanie dla wtyczek Windows NPAPI w przeglądarkach Linux. To narzędzie pozwala użytkownikom Linuksa na uruchamianie Microsoft Silverlight , odpowiednika Microsoft Flash , oraz wtyczki internetowej Unity , a także wielu innych wtyczek NPAPI. Projekt dostarcza obszerny zestaw łatek przeciwko projektowi upstream Wine, z których część została zatwierdzona i dodana do upstream Wine. Pipelight jest w dużej mierze przestarzały, ponieważ nowoczesne przeglądarki nie obsługują już wtyczek NPAPI, a Silverlight został wycofany przez Microsoft.

Przyjęcie

Projekt Wine otrzymał na przestrzeni lat wiele skarg i obaw natury technicznej i filozoficznej.

Bezpieczeństwo

Ze względu na zdolność Wine do uruchamiania kodu binarnego systemu Windows, pojawiły się obawy dotyczące natywnych wirusów Windows i złośliwego oprogramowania wpływającego na systemy operacyjne typu Unix, ponieważ Wine może uruchamiać ograniczone złośliwe oprogramowanie stworzone dla systemu Windows. Analiza bezpieczeństwa z 2018 r. wykazała, że 5 z 30 próbek złośliwego oprogramowania z powodzeniem przeszło przez Wine, co jest stosunkowo niskim wskaźnikiem, który mimo to stanowił zagrożenie dla bezpieczeństwa. Z tego powodu twórcy Wine zalecają, aby nigdy nie uruchamiać go jako superużytkownik . Oprogramowanie do badania złośliwego oprogramowania, takie jak ZeroWine, uruchamia Wine w systemie Linux na maszynie wirtualnej , aby całkowicie odizolować złośliwe oprogramowanie od systemu hosta. Alternatywą dla poprawy bezpieczeństwa bez kosztów wydajności przy użyciu maszyny wirtualnej, jest uruchomienie Wine w lxc pojemnika, jak Anbox oprogramowanie robi domyślnie z systemem Android .

Innym problemem związanym z bezpieczeństwem jest to, że zaimplementowane specyfikacje są źle zaprojektowane i pozwalają na naruszenie bezpieczeństwa. Ponieważ Wine implementuje te specyfikacje, prawdopodobnie zaimplementuje również wszelkie zawarte w nich luki w zabezpieczeniach. Jednym z przykładów tego problemu była luka 2006 Windows Metafile , która spowodowała, że Wine zaimplementował lukę SETABORTPROC.

Wine kontra natywne aplikacje uniksowe

Powszechnym problemem związanym z Wine jest to, że jego istnienie oznacza, że dostawcy rzadziej piszą natywne aplikacje dla systemów Linux, macOS i BSD. Jako przykład warto rozważyć system operacyjny IBM z 1994 roku, OS/2 Warp . Artykuł opisuje słabości systemu OS/2, które go zabiły, pierwszą z nich jest:

OS/2 oferował doskonałą kompatybilność z aplikacjami DOS i Windows 3.1. Nie, to nie jest błąd. Wielu producentów aplikacji twierdziło, że rozwijając aplikację DOS lub Windows, mogliby wejść na rynek OS/2 jako dodatek do rynków DOS/Windows i nie tworzyli natywnych aplikacji dla OS/2.

OS/2 miał jednak wiele problemów z akceptacją przez użytkownika końcowego. Być może najpoważniejsze było to, że większość sprzedawanych komputerów była już wyposażona w DOS i Windows, a wiele osób nie zadało sobie trudu, aby ocenić OS/2 pod kątem jego zalet z powodu posiadania już systemu operacyjnego. „Pakietowanie” DOS i Windows oraz efekt mrożący, jaki miało to na rynku systemów operacyjnych, często pojawiały się w sprawie Stany Zjednoczone przeciwko Microsoft Corporation .

Sam projekt Wine odpowiada na konkretną skargę „zachęcania” do dalszego rozwoju Windows API na jednej z jego stron wiki :

Dla większości ludzi pozostaje kilka programów blokujących je w systemie Windows. To oczywiste, że Microsoft Office nigdy nie zostanie przeniesiony na Linuksa, jednak starsze wersje programów, takich jak TurboTax, również nie zostaną przeniesione. Podobnie istnieją dziesiątki tysięcy gier i wewnętrznych aplikacji korporacyjnych, które nigdy nie zostaną przeniesione. Jeśli chcesz używać Linuksa i polegać na dowolnej starszej aplikacji Windows, coś takiego jak Wine jest niezbędne... Wine czyni Linuksa bardziej użytecznym i pozwala milionom użytkowników na zmianę, którzy nie mogliby inaczej. To znacznie zwiększa udział w rynku Linuksa, przyciągając więcej komercyjnych i społecznościowych programistów do Linuksa.

Ponadto strona Wine Wiki twierdzi, że Wine może pomóc w rozwiązaniu problemu kurczaka i jajka dla Linuksa na pulpicie :

To prowadzi nas do kwestii kurczaka i jajka w Linuksie na pulpicie. Dopóki Linux nie będzie w stanie zapewnić odpowiedników dla powyższych aplikacji, jego udział w rynku desktopów będzie stagnować. Ale dopóki udział Linuksa w rynku nie wzrośnie, żaden dostawca nie będzie tworzyć aplikacji dla Linuksa. Jak przerwać ten zaklęty krąg?

Ponownie, Wine może udzielić odpowiedzi. Umożliwiając użytkownikom ponowne wykorzystanie aplikacji Windows, w które zainwestowali czas i pieniądze, Wine znacznie obniża barierę uniemożliwiającą użytkownikom przejście na Linuksa. To z kolei umożliwia Linuksowi start na desktopie, co zwiększa jego udział w rynku w tym segmencie. To z kolei sprawia, że firmy mogą produkować wersje swoich aplikacji dla Linuksa, a nowe produkty będą pojawiać się tylko na rynku Linuksa. To rozumowanie można by łatwo odrzucić, gdyby Wine był zdolny tylko do prowadzenia pasjansa. Jednak teraz może uruchamiać Microsoft Office, aplikacje multimedialne, takie jak QuickTime i Windows Media Player, a nawet gry, takie jak Max Payne lub Unreal Tournament 3. Prawie każda inna skomplikowana aplikacja może działać dobrze, jeśli starczy trochę czasu. I za każdym razem, gdy wykonywana jest praca, aby dodać jedną aplikację do tej listy, wiele innych aplikacji korzysta z tej pracy i również staje się użytecznych.

Zajrzyj do naszej Bazy Danych Aplikacji, aby dowiedzieć się, co można uruchomić pod Wine.

Wykorzystanie Wine do gier okazało się szczególnie kontrowersyjne w społeczności Linuksa, ponieważ niektórzy uważają, że uniemożliwia lub przynajmniej utrudnia dalszy rozwój rodzimych gier linuksowych na tej platformie.

Microsoft

Do 2020 roku Microsoft nie wydał żadnych publicznych oświadczeń na temat Wine. Jednak oprogramowanie Windows Update zablokuje aktualizacje aplikacji Microsoft działających w Wine. 16 lutego 2005 r. Ivan Leo Puoti odkrył, że Microsoft zaczął sprawdzać rejestr systemu Windows pod kątem klucza konfiguracyjnego Wine i blokował aktualizację systemu Windows dla dowolnego składnika. Jak zauważył Puoti: „Po raz pierwszy Microsoft potwierdza istnienie Wine”.

W styczniu 2020 r. Microsoft wymienił Wine jako pozytywną konsekwencję możliwości ponownego wdrożenia interfejsów API w swoim raporcie amicus curiae dla Google LLC przeciwko Oracle America, Inc.

Zobacz też

Bibliografia

Dalsza lektura

Jeremy White's Wine Answers – wywiad Slashdot z Jeremy White z CodeWeavers
Wywiad Jeremy'ego White'a na stronie internetowej "Mad Penguin" , 25 maja 2004 r.
Powołanie Software Freedom Law Center na radcę prawnego do reprezentowania projektu Wine
Wino: Skąd pochodzi, jak go używać, dokąd zmierza – praca Dana Kegla

Zewnętrzne linki

Oficjalna strona internetowa

Languages

In other projects