Wine (phần mềm)

Wine (viết tắt của Wine is not an emulator - "Wine không phải là chương trình giả lập") là một phần mềm tự do nguồn mở dùng để chạy các phần mềm viết cho Windows trên các hệ điều hành tương tự Unix (Linux, FreeBSD...). Wine cũng cung cấp một thư viện phần mềm, được gọi là Winelib, dựa vào đó các nhà phát triển có thể biên dịch các ứng dụng Windows để giúp port chúng sang các hệ thống tương tự Unix.
Wine cung cấp môi trường runtime Windows riêng để chuyển các lời gọi hệ thống Windows thành các lời gọi hệ thống tuân thủ POSIX, tạo lại cấu trúc thư mục của hệ thống Windows và cung cấp các triển khai thay thế của các thư viện hệ thống, dịch vụ hệ thống Windows thông qua codice_1 và nhiều thành phần khác (như Internet Explorer, Windows Registry Editor, và msiexec). Wine chủ yếu được viết bằng kỹ thuật đảo ngược thử nghiệm hộp đen, để tránh các vấn đề bản quyền.
Việc lựa chọn "Wine is Not an Emulator" làm tên của Wine Project là kết quả của một cuộc thảo luận đặt tên vào tháng 8 năm 1993 và ghi danh cho David Niemi. Có một số nhầm lẫn gây ra bởi FAQ khi sử dụng "Windows Emulator" và các nguồn không hợp lệ khác xuất hiện sau khi tên Wine Project được đặt. Không có mô phỏng mã hoặc ảo hóa xảy ra khi chạy một ứng dụng Windows trong Wine. Mô phỏng "thường sẽ đề cập đến việc thực thi mã được biên dịch dành cho một bộ xử lý (ví như x86) bằng cách giải thích/biên dịch lại phần mềm chạy trên một bộ xử lý khác (ví như PowerPC). 
Mặc dù tên đôi khi xuất hiện trong các biểu mẫu "WINE" và "wine", các nhà phát triển dự án đã đồng ý tiêu chuẩn hóa mẫu "Wine".
Wine được phát triển chủ yếu cho Linux và macOS, và () các gói được duy trì tốt có sẵn cho cả hai nền tảng.
Trong một khảo sát năm 2007 bởi desktoplinux.com với 38.500 người dùng máy tính để bàn Linux, 31,5% số người được hỏi đã báo cáo sử dụng Wine để chạy các ứng dụng Windows. Con số này lớn hơn tất cả các chương trình ảo hóa x86 cộng lại, cũng như lớn hơn 27,9% người báo cáo không chạy các ứng dụng Windows.
Lịch sử.
Dự án Wine khởi đầu năm 1993 nhằm hỗ trợ chạy các phần mềm của Windows 3.1 trên nền Linux. Người điều hành ban đầu là Bob Amstadt, sau đó là Alexander Julliard. Các bản phiên bản Wine sau này được mở rộng cho Unix, và hỗ trợ Win32.
Bob Amstadt, người lãnh đạo dự án ban đầu và Eric Youngdale bắt đầu dự án Wine vào năm 1993 như một cách để chạy các ứng dụng Windows trên Linux. Nó lấy cảm hứng từ hai sản phẩm của Sun Microsystems, Wabi cho hệ điều hành Solaris, và Public Windows Initiative, đó là một nỗ lực để Windows API được triển khai lại hoàn toàn trong phạm vi công cộng dưới dạng tiêu chuẩn ISO nhưng bị từ chối do áp lực từ Microsoft năm 1996. Wine ban đầu hướng đến các ứng dụng 16-bit cho Windows 3.x, nhưng tập trung vào các phiên bản 32-bit và 64 bit đã trở thành tiêu chuẩn trên các hệ điều hành mới hơn. Dự án bắt nguồn từ các cuộc thảo luận trên Usenet comp.os.linux vào tháng 6 năm 1993. Alexandre Julliard has led the project since 1994.
Dự án đã được chứng minh là tốn thời gian và khó khăn cho các nhà phát triển, chủ yếu là do tài liệu không đầy đủ và không chính xác của Windows API. Mặc dù Microsoft cung cấp tài liệu rộng rãi cho hầu hết các chức năng Win32, một số lĩnh vực như định dạng file và giao thức không có thông số kỹ thuật có sẵn công khai từ Microsoft và Windows cũng bao gồm các chức năng cấp thấp không có docs, hành vi không có docs và che giấu lỗi mà Wine phải sao chép chính xác để cho phép một số ứng dụng hoạt động đúng. Do đó, nhóm Wine đã dò ngược nhiều lệnh gọi chức năng và định dạng file trong các lĩnh vực như thunk.
Dự án Wine ban đầu phát hành Wine theo cùng Giấy phép MIT với X Window System, nhưng do lo ngại về các phiên bản độc quyền của Wine không đóng góp các thay đổi của họ trở lại dự án cốt lõi, các hoạt động kể từ tháng 3 năm 2002 đã sử dụng LGPL để cấp phép.
Wine chính thức bước vào phiên bản beta với phiên bản 0.9 ngày 25/10/2005. Phiên bản 1.0 được phát hành ngày 17/6/2008, sau 15 năm phát triển. Phiên bản 1.2 được phát hành ngày 16/7/2010, version 1.4 ngày 7/3/2012, Phiên bản 1.6 ngày 18/7/2013. và phiên bản 1.8 ngày 19/12/2015. Phiên bản phát triển được phát hành khoảng hai tuần một lần.
Wine-staging là một tập hợp các bản vá tương đối tích cực được duy trì một cách tương đối độc lập mà các nhà phát triển WineHQ coi là đã sẵn sàng để sáp nhập vào wine repository, nhưng vẫn được coi là hữu ích bởi phân nhánh wine-compholio. Nó chủ yếu bao gồm các chức năng thử nghiệm và sửa lỗi. Kể từ tháng 1 năm 2017, các bản vá trong wine-staging bắt đầu được tích cực sáp nhập vào thượng nguồn WineHQ khi wine-compholio chuyển giao dự án cho Alistair Leslie-Hughes, một nhà phát triển chính của WineHQ.
Tài trợ doanh nghiệp.
Nhà tài trợ chính của Wine là CodeWeavers, công ty thuê Julliard và nhiều nhà phát triển Wine khác để làm việc trên Wine và trên CrossOver, phiên bản Wine được hỗ trợ của CodeWeavers. CrossOver bao gồm một số điều chỉnh dành riêng cho ứng dụng không được coi là phù hợp với phiên bản WineHQ, cũng như một số thành phần độc quyền bổ sung.
Sự tham gia của Corel trong một thời gian đã hỗ trợ dự án, chủ yếu bằng cách thuê Julliard và những người khác làm việc với nó. Corel đã quan tâm đến việc port WordPerfect Office, bộ ứng dụng văn phòng của họ, sang Linux (đặc biệt là Corel Linux). Corel sau đó đã hủy tất cả các dự án liên quan đến Linux sau khi Microsoft đầu tư lớn vào Corel, dừng nỗ lực Wine của họ.
Các nhà tài trợ khác của công ty bao gồm Google, đã thuê CodeWeavers để sửa Wine để Picasa chạy đủ tốt để port trực tiếp sang Linux bằng cách sử dụng cùng một nhị phân như trên Windows; Google sau đó đã trả tiền để cải thiện sự hỗ trợ của Wine cho Adobe Photoshop CS2. Wine ũng là người thụ hưởng thường xuyên của chương trình Summer of Code của Google.
Thiết kế.
Mục tiêu của Wine là triển khai các Windows API đầy đủ hoặc một phần được yêu cầu bởi các chương trình mà người dùng Wine muốn chạy trên hệ thống tương tự Unix.
Kiến trúc cơ bản.
Các giao diện lập trình của họ hệ điều hành Microsoft Windows bao gồm phần lớn thư viện liên kết động (DLL). Chúng chứa một số lượng lớn các wrapper sub-routines cho các lời gọi hệ thống của kernel, chương trình NTOS kernel-mode (ntoskrnl.exe). Một chương trình Windows thông thường gọi một số Windows DLLs, lần lượt gọi các thư viện gdi/user32 ở chế độ người dùng, lần lượt sử dụng kernel32.dll (hệ thống con win32) chịu trách nhiệm xử lý kernel thông qua các cuộc gọi hệ thống. Lớp lời gọi hệ thống được coi là riêng tư đối với các lập trình viên Microsoft vì tài liệu không có sẵn công khai và tất cả các giao diện được xuất bản đều dựa vào các hệ thống con chạy trên kernel. Bên cạnh đó, có một số giao diện lập trình được triển khai như các dịch vụ chạy dưới dạng các tiến trình riêng biệt. Các ứng dụng giao tiếp với các dịch vụ chế độ người dùng thông qua RPC.
Wine triển khai giao diện nhị phân ứng dụng Windows (ABI) hoàn toàn trong không gian người dùng, thay vì dưới dạng mô-đun hạt nhân. Wine chủ yếu phản ánh hệ thống phân cấp, với các dịch vụ thường được cung cấp bởi kernel trong Windows thay vào đó được cung cấp bởi một daemon được gọi là wineserver, có nhiệm vụ thực hiện chức năng cơ bản của Windows, cũng như tích hợp với X Window System, và dịch tín hiệu thành bản địa Windows ngoại lệ. Mặc dù Wineserver triển khai một số khía cạnh của Windows kernel, nhưng không thể sử dụng trình điều khiển Windows gốc với nó, do kiến trúc cơ bản của Wine. Điều này ngăn các ứng dụng và trò chơi nhất định hoạt động, ví dụ: những ứng dụng sử dụng tính năng chống sao chép StarForce yêu cầu các driver ảo hóa thiết bị để cài đặt.
Các thư viện và ứng dụng.
Wine cho phép tải cả Windows DLL và các đối tượng chia sẻ Unix cho các chương trình Windows của nó. Việc triển khai dựng sẵn của nó đối với Windows DLL cơ bản nhất, cụ thể là NTDLL, KERNEL32, GDI32, USER32, sử dụng phương thức đối tượng dùng chung vì họ phải sử dụng các hàm trong hệ điều hành máy chủ là tốt. Các thư viện cấp cao hơn, chẳng hạn như WineD3D, được sử dụng định dạng DLL tự do. Trong nhiều trường hợp, người dùng có thể chọn tải DLL từ Windows thay vì cài đặt bằng wine. Làm như vậy có thể cung cấp các chức năng chưa được thực hiện bởi wine, nhưng cũng có thể gây ra trục trặc nếu nó phụ thuộc vào một thứ khác không có trong wine.
Wine theo dõi trạng thái thực hiện thông qua kiểm thử đơn vị được thực hiện tại mỗi lần commit git.
Đồ họa và gaming.
Mặc dù hầu hết các phần mềm văn phòng không sử dụng các API đồ họa tăng tốc GPU phức tạp, các trò chơi máy tính làm vậy. Để chạy các trò chơi này một cách chính xác, Wine sẽ phải chuyển tiếp các hướng dẫn vẽ tới hệ điều hành chủ và thậm chí dịch chúng sang thứ mà hệ điều hành chủ có thể hiểu.
DirectX là một bộ sưu tập các API của Microsoft cho render, âm thanh và đầu vào. Kể từ năm 2019, Wine 4.0 chứa triển khai DirectX 12 cho API Vulkan và DirectX 11.2 cho OpenGL. Wine 4.0 cũng cho phép Wine chạy các ứng dụng Vulkan bằng cách trao các lệnh vẽ cho hệ điều hành chủ hoặc trong trường hợp macOS, bằng cách dịch chúng sang Metal API bằng MoltenVK.
Direct3D.
Phần lớn nỗ lực DirectX của Wine tập trung vào việc xây dựng WineD3D, một lớp dịch từ các lệnh gọi Direct3D và DirectDraw API vào OpenGL. Kể từ năm 2019, thành phần này hỗ trợ tối đa DirectX 11. Kể từ , wine đủ tốt để chạy "Overwatch" với D3D11. Bên cạnh việc được sử dụng trong Wine, WineD3D DLLs cũng hữu ích trong chính Hệ điều hành Windows, cho phép các card đồ họa cũ hơn chạy các trò chơi bằng các phiên bản DirectX mới hơn và cho các trò chơi dựa trên DDraw cũ để hiển thị chính xác.
Một số công việc đang diễn ra để chuyển phụ trợ Direct3D sang API Vulkan. Hỗ trợ Direct3D 12 trong 4.0 được cung cấp bởi tiểu dự án "vkd3d", and WineD3D has in 2019 been experimentally ported to use the Vulkan API.
Wine, khi được vá, có thể chạy Direct3D 9 mà không cần dịch thông qua ứng dụng tự do nguồn mở Gallium3D State Tracker for DX9. Lớp Gallium3D cho phép truyền trực tiếp các lệnh vẽ.
Giao diện người dùng.
Wine thường được gọi từ trình thông dịch dòng lệnh: codice_2.
winecfg.
Có tiện ích codice_3 khởi động giao diện người dùng đồ họa với các điều khiển để điều chỉnh các tùy chọn cơ bản. Nó là một tiện ích cấu hình GUI đi kèm với Wine. Winecfg giúp cấu hình Wine dễ dàng hơn bằng cách không cần chỉnh sửa trực tiếp registry, mặc dù, nếu cần, điều này có thể được thực hiện với trình chỉnh sửa sổ đăng ký đi kèm (tương tự như "regedit" của Windows).
Ứng dụng bên thứ 3.
Một số ứng dụng yêu cầu nhiều tinh chỉnh hơn là chỉ cài đặt ứng dụng để hoạt động chính xác, chẳng hạn như cấu hình thủ công Wine để sử dụng một số Windows DLLs. Dự án Wine không tích hợp các cách giải quyết đó vào codebase của Wine, thay vào đó chỉ muốn tập trung vào việc cải thiện việc triển khai Windows API của Wine. Mặc dù cách tiếp cận này tập trung phát triển Wine vào khả năng tương thích lâu dài, nhưng nó khiến người dùng gặp khó khăn khi chạy các ứng dụng yêu cầu giải pháp. Do đó, nhiều ứng dụng của bên thứ ba đã được tạo để giảm bớt việc sử dụng những ứng dụng không hoạt động "ngoài hộp" trong chính Wine. Wine wiki duy trì một trang các ứng dụng của bên thứ ba hiện tại và trước đây.
Chức năng.
Các nhà phát triển phần Direct3D của Wine đã tiếp tục triển khai các tính năng mới như shader pixel để tăng hỗ trợ trò chơi. Wine cũng có thể sử dụng DLL gốc trực tiếp, do đó tăng chức năng, nhưng sau đó cần có giấy phép cho Windows trừ khi DLL được phân phối cùng với ứng dụng.
cũng bao gồm các triển khai nguồn mở của riêng mình đối với một số chương trình Windows, chẳng hạn như "notepad", "wordpad", "control", "iexplore", và "explorer".
The Wine Application Database (AppDB) là một cơ sở dữ liệu trực tuyến được cộng đồng duy trì về các chương trình Windows hoạt động với Wine và chúng hoạt động tốt như thế nào.
Tương thích ngược.
Wine đảm bảo tốt khả năng tương thích ngược với các ứng dụng Windows cũ, bao gồm cả những ứng dụng được viết cho Windows 3.1x. Wine có thể bắt chước các phiên bản Windows khác nhau cần thiết cho một số chương trình, đi xa như phiên bản Windows 2.0. Tuy nhiên, hỗ trợ Windows 1.x và Windows 2.x đã bị xóa khỏi phiên bản phát triển Wine 1.3.12. Nếu DOSBox được cài đặt trên hệ thống, phiên bản phát triển Wine 1.3.12 và sau đó sẽ hiển thị tùy chọn "Windows 2.0" để phiên bản Windows bắt chước, nhưng Wine vẫn không chạy hầu hết các chương trình Windows 2.0 vì các chức năng MS-DOS và Windows hiện chưa được tích hợp.
Khả năng tương thích ngược trong Wine vượt trội so với Windows, vì các phiên bản Windows mới hơn có thể buộc người dùng nâng cấp các ứng dụng Windows cũ. Trong nhiều trường hợp, Wine có thể cung cấp hỗ trợ kế thừa tốt hơn so với các phiên bản Windows mới hơn với "Compatibility Mode". Wine có thể chạy các ứng dụng Windows 16-bit trên hệ điều hành 64-bit, sử dụng CPU x86-64 (64-bit), một chức năng không có trong các phiên bản 64 bit của Microsoft Windows.
Wine hỗ trợ một phần các ứng dụng console Windows và người dùng có thể chọn sử dụng phụ trợ nào để quản lý console (các lựa chọn bao gồm raw streams, curses và user32). Khi sử dụng raw streams hay curses backends, các ứng dụng Windows sẽ chạy trong Unix terminal.
Ứng dụng 64-bit.
Hỗ trợ sơ bộ cho các ứng dụng Windows 64 bit đã được thêm vào Wine 1.1.10, vào tháng 12 năm 2008. , sự hỗ trợ được coi là ổn định. Hai phiên bản wine được built riêng biệt và kết quả là chỉ bản built Wine64 tạo ra một môi trường chỉ có khả năng chạy các ứng dụng x86-64.
, Wine có hỗ trợ ổn định cho bản build WoW64, cho phép cả ứng dụng Windows 32 bit và 64 bit chạy trong cùng một phiên bản Wine. Để thực hiện quá trình xây dựng như vậy, trước tiên người ta phải build phiên bản 64 bit, sau đó build phiên bản 32 bit tham chiếu phiên bản 64 bit. Giống như WoW64 của Microsoft, quy trình build 32 bit sẽ thêm các phần cần thiết để xử lý các chương trình 32 bit vào bản build 64 bit. This functionality is seen from at least 2010.
MS-DOS.
Các phiên bản đầu tiên của Microsoft Windows chạy trên MS-DOS và các chương trình Windows có thể phụ thuộc vào các chương trình MS-DOS có thể chạy được. Wine không hỗ trợ tốt cho MS-DOS, nhưng bắt đầu với phiên bản phát triển 1.3.12, Wine thử chạy các chương trình MS-DOS trong DOSBox nếu DOSBox có sẵn trên hệ thống. Tuy nhiên, do lỗi., các phiên bản hiện tại của Wine xác định không chính xác các chương trình Windows 1.x và Windows 2.x là các chương trình MS-DOS, cố gắng chạy chúng trong DOSBox (không hoạt động).
Winelib.
Wine cung cấp Winelib, cho phép các triển khai đối tượng dùng chung của Windows API được sử dụng làm thư viện thực tế cho chương trình Unix. Điều này cho phép mã Windows được tích hợp vào các file thực thi Unix gốc. Kể từ tháng 10 năm 2010, Winelib cũng hoạt động trên nền tảng ARM.
Kiến trúc phi-x86.
Hỗ trợ cho Solaris SPARC đã bị loại bỏ trong phiên bản 1.5.26.
ARM, Windows CE, và Windows RT.
Wine cung cấp một số hỗ trợ cho bộ xử lý ARM (cũng như ARM64/AArch64) và các bản Windows chính thức chạy trên nó. , Wine có thể chạy cá ứng dụng ARM/Win32 dành cho các thiết bị đã mở khóa Windows RT (nhưng không phải chương trình Windows RT). Không hỗ trợ Windows CE (x86 hoặc ARM), nhưng không chính thức, một bản concept tiền alpha được gọi là WineCE cho phép một số hỗ trợ.
Wine cho Android.
Ngày 3 tháng 2 năm 2013 tại buổi hội nghị FOSDEM ở Brussels, Alexandre Julliard đã trình diễn bản demo đầu tiên của Wine chạy trên hệ điều hành [Android (hệ điều hành)|Android] của Google.
Các bản build thử nghiệm của WINE cho Android (x86 và ARM) đã được phát hành vào cuối năm 2017. Nó đã được cập nhật thường xuyên bởi các nhà phát triển chính thức kể từ đó. Các bản build mặc định không triển khai mô phỏng kiến trúc chéo thông qua QEMU và kết quả là các phiên bản ARM sẽ chỉ chạy các ứng dụng ARM sử dụng Win32 API.
Ứng dụng Microsoft.
Wine, mặc định, sử dụng các bản dựng Windows chuyên dụng của Gecko và Mono để thay thế cho Internet Explorer và .NET Framework của Microsoft. Wine có các triển khai tích hợp của JScript và VBScript. Có thể tải xuống và chạy trình cài đặt của Microsoft cho các chương trình đó thông qua winetricks hoặc thủ công.
Wine được biết là không có hỗ trợ tốt cho hầu hết các phiên bản Internet Explorer. Trong tất cả các phiên bản gần đây, Internet Explorer 8 cho Windows XP là phiên bản duy nhất báo cáo xếp hạng có thể sử dụng trên AppDB của Wine, vượt trội. Winetricks cung cấp cài đặt tự động cho Internet Explorer 6 đến 8, vì vậy các phiên bản này có thể được mong đợi hoạt động tốt với các cách giải quyết tích hợp của nó.
Một cách khác để cài đặt Internet Explorer trực tiếp là sử dụng IEs4Linux không còn tồn tại. Nó không tương thích với các phiên bản mới nhất của Wine, và sự phát triển của IEs4Linux không hoạt động.
Các phiên bản khác của Wine.
Sự phát triển cốt lõi của Wine nhằm mục đích triển khai chính xác toàn bộ API Windows và đôi khi bị tụt lại trong một số lĩnh vực tương thích với các ứng dụng nhất định. Ví dụ như Direct3D vẫn chưa được triển khai cho đến năm 1998, mặc dù các bản phát hành mới hơn đã có một triển khai ngày càng hoàn thiện.
CrossOver.
CodeWeavers tiếp thị CrossOver đặc biệt để chạy Microsoft Office và các ứng dụng Windows lớn khác, bao gồm một số trò chơi. CodeWeavers thuê Alexandre Julliard để làm việc trên Wine và đóng góp phần lớn mã của nó cho dự án Wine theo LGPL. CodeWeavers cũng đã phát hành một phiên bản mới có tên CrossOver Mac cho các máy tính Apple Macintosh dựa trên chip Intel ngày 10 tháng 1 năm 2007.
CrossOver hiện bao gồm chức năng của cả hai dòng CrossOver Games và CrossOver Pro, do đó CrossOver Games và CrossOver Pro không còn có sẵn dưới dạng các sản phẩm đơn lẻ.
CrossOver Games đã được tối ưu hóa để chạy video game Windows. Không giống CrossOver, nó không tập trung vào việc cung cấp phiên bản Wine ổn định nhất. Thay vào đó, các tính năng thử nghiệm được cung cấp để hỗ trợ các trò chơi mới hơn.
Cedega/WineX.
Findev Inc. sản xuất phần mềm Cedega độc quyền. sản xuất phần mềm Cedega độc quyền. Trước đây được biết đến với tên WineX, Cedega là một phân nhánh từ phiên bản Wine được cấp phép cuối cùng của MIT vào năm 2002. Giống như CrossOver Games, Cedega của Findev được nhắm đến để chạy các trò chơi video của Windows. Vào ngày 7 tháng 1 năm 2011, Findev Inc. đã công bố tiếp tục phát triển Cedega Technology dưới GameTree Developer Program. Findev Inc. cho phép các thành viên tiếp tục sử dụng ID và mật khẩu Cedega của họ cho đến ngày 28 tháng 2 năm 2011.
Cider.
Findev cũng đã sản xuất Cider, một thư viện cho các máy Macintosh chạy chip Intel của Apple. Thay vì là một sản phẩm của người dùng cuối, Cider (giống với Winelib) là một trình bao cho phép các nhà phát triển điều chỉnh các trò chơi của họ để chạy tự nhiên trên máy Macintosh chạy chip Intel mà không có bất kỳ thay đổi nào về mã nguồn.
WINE@Etersoft.
Công ty Nga Etersoft đã phát triển phiên bản độc quyền của Wine từ năm 2006. WINE@Etersoft hỗ trợ các ứng dụng phổ biến của Nga (ví dụ như, 1C:Enterprise của 1C Company). , Etersoft sẽ phát hành WINE @ Etersoft CAD, được định hướng theo hệ thống CAD, chẳng hạn như AutoCAD, BricsCAD và Compass-3D.
Darwine.
Darwine là một port của các thư viện Wine đến Darwin và macOS cho cả kiến trúc PowerPC và Intel x86. Tất cả các bản vá cho phiên bản x86 đã được sáp nhập trở lại vào nhánh chính của Wine vào năm 2009. Phát triển trên phiên bản PPC đã bị hủy bỏ. Mike Kronenberg trước đây đã tạo WineHelper cho Darwine để thêm ứng dụng kiểu GUI và macOS để tương tác với Wine, sau này được thay thế bởi WineBottler. Darwine hiện cung cấp các gói tương thích macOS được biên dịch từ kho lưu trữ Wine.
Pipelight.
Pipelight Team đã tạo một phiên bản tùy chỉnh của Wine (Wine-compholio) hoạt động như một trình bao cho các plugin Windows NPAPI trong trình duyệt Linux. Công cụ này cho phép người dùng Linux chạy Microsoft Silverlight, tương đương với Microsoft Adobe Flash và Unity web plugin, cùng với nhiều plugin NPAPI khác. Dự án cung cấp một bộ các bản vá rộng rãi chống lại dự án Wine thượng nguồn, một số trong đó đôi khi được phê duyệt và thêm vào thượng nguồn Wine. Pipelight phần lớn đã lỗi thời, vì các trình duyệt hiện đại không còn hỗ trợ các plugin NPAPI và Silverlight đã bị Microsoft phản đối.
Proton.
Vào ngày 21 tháng 8 năm 2018, Valve đã công bố một biến thể mới của Wine, có tên Proton, được thiết kế để tích hợp với phiên bản Linux của phần mềm Steam (bao gồm cả cài đặt Steam được tích hợp trong hệ điều hành SteamOS dựa trên Linux của họ và máy tính Steam Machine). Mục tiêu của Valve đối với Proton là cho phép người dùng Steam trên Linux chơi các trò chơi thiếu port Linux gốc (đặc biệt là các trò chơi có mục lục), và cuối cùng, thông qua tích hợp với Steam cũng như các cải tiến để hỗ trợ trò chơi so với dòng chính Wine, để cung cấp cho người dùng "cùng trải nghiệm plug-and-play đơn giản" mà họ có được khi họ chơi trò chơi tự nhiên trên Linux. Proton bước vào phiên bản beta công khai ngay sau khi được công bố.
Valve đã hợp tác với CodeWeavers từ năm 2016 để phát triển các cải tiến cho hiệu suất chơi trò chơi của Wine, một số trong đó đã được sáp nhập vào dự án Wine thượng nguồn. Một số cải tiến cụ thể được tích hợp vào Proton bao gồm triển khai Direct3D 10, 11 và 12 dựa trên Vulkan thông qua vkd3d và DXVK, cải tiến hiệu suất đa luồng thông qua esync, cải thiện xử lý các trò chơi toàn màn hình và hỗ trợ phần cứng bộ điều khiển trò chơi tự động tốt hơn.
Proton là nguồn mở hoàn toàn và có sẵn thông qua GitHub.
Các dự án khác sử dụng mã nguồn của Wine.
Các dự án khác sử dụng mã nguồn của Wine bao gồm:
Tiếp nhận.
Dự án Wine đã nhận được một số khiếu nại và quan tâm về kỹ thuật và triết học trong những năm qua.
Bảo mật.
Do khả năng chạy mã nhị phân Windows của Wine, các mối lo ngại đã được đặt ra đối với các vi-rút và phần mềm độc hại của Windows ảnh hưởng đến các hệ điều hành tương tự Unix. Wine có thể chạy hầu hết các phần mềm độc hại, nhưng các chương trình chạy trong Wine bị giới hạn trong các đặc quyền của người dùng hiện tại, hạn chế một số hậu quả không mong muốn. Vì lý do này, các nhà phát triển của Wine khuyên không bao giờ chạy nó bằng superuser. Phần mềm nghiên cứu phần mềm độc hại như ZeroWine chạy Wine trên Linux trong máy ảo, để tách phần mềm độc hại hoàn toàn khỏi hệ thống chủ.
Một cách khác để cải thiện bảo mật mà không bị chậm sử dụng máy ảo, là chạy Wine trong bộ chứa LXC, như phần mềm Anbox đang hoạt động theo mặc định với Android.
Một mối quan tâm bảo mật khác là khi các thông số kỹ thuật được triển khai không được thiết kế và cho phép thỏa hiệp bảo mật. Bởi vì Wine thực hiện các thông số kỹ thuật này, nó cũng sẽ thực hiện bất kỳ lỗ hổng bảo mật nào mà chúng chứa. Một ví dụ của vấn đề này là lỗ hổng Windows Metafile năm 2006, đã cho thấy Wine thực hiện lối thoát SETABORTPROC dễ bị tổn thương.
Wine với các ứng dụng Unix thuần.
Một mối quan tâm chung về Wine là sự tồn tại của nó có nghĩa là các nhà cung cấp ít có khả năng viết các ứng dụng Linux, macOS và BSD thuần. Một ví dụ về điều này, đáng để xem xét hệ điều hành năm 1994 của IBM, OS/2 Warp. Một bài viết mô tả những điểm yếu của OS/2 đã giết chết nó, cái đầu tiên là:
Dự án Wine tự trả lời các khiếu nại này trên một trong các trang wiki của nó:
Ngoài ra, trang Wine Wiki tuyên bố rằng Wine có thể giúp phá vỡ vấn đề con gà và quả trứng cho Linux trên máy tính để bàn:
Việc sử dụng Wine để chơi game đã gây tranh cãi đặc biệt trong cộng đồng Linux, vì một số người cảm thấy điều đó đang ngăn chặn hoặc ít nhất là cản trở sự phát triển hơn nữa của trò chơi Linux gốc trên nền tảng này.
Microsoft.
Microsoft đã không đưa ra tuyên bố công khai về Wine. Tuy nhiên, phần mềm Windows Update sẽ chặn các bản cập nhật cho các ứng dụng Microsoft đang chạy trong Wine.Vào ngày 16 tháng 2 năm 2005, Ivan Leo Puoti phát hiện ra rằng Microsoft đã bắt đầu kiểm tra Windows Registry cho khóa cấu hình Wine và sẽ chặn Windows Update bất kỳ thành phần nào. Như Puoti đã lưu ý: "Đây cũng là lần đầu tiên Microsoft thừa nhận sự tồn tại của Wine."