Wine (phần mềm)

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ính đến  năm 2010 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.

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ừ December 12, 2016, 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: wine [program.exe].

winecfg

Có tiện ích winecfg 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).

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. Tính đến  tháng 4 năm 2019, 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.
Tính đến  tháng 4 năm 2019, 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ó. Tính đến  tháng 4 năm 2019, 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, usử 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.

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). For 2010, 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.

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à:
OS/2 cung cấp khả năng tương thích tuyệt vời với các ứng dụng DOS và Windows 3.1. Không, đây không phải là một lỗi. Nhiều nhà cung cấp ứng dụng lập luận rằng bằng cách phát triển ứng dụng DOS hoặc Windows, họ sẽ tiếp cận thị trường OS/2 ngoài thị trường DOS/Windows và họ không phát triển ứng dụng OS/2 gốc.
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ó:
Đối với hầu hết mọi người, vẫn còn một số chương trình khóa chúng vào Windows. Rõ ràng là sẽ không bao giờ có Microsoft Office được chuyển sang Linux, tuy nhiên các phiên bản chương trình cũ hơn như TurboTax cũng sẽ không được chuyển. Tương tự, có hàng chục ngàn trò chơi và ứng dụng nội bộ của công ty sẽ không bao giờ được chuyển. Nếu bạn muốn sử dụng Linux và dựa vào bất kỳ ứng dụng Windows cũ nào, một thứ như Wine là điều cần thiết ... Wine làm cho Linux trở nên hữu ích hơn và cho phép hàng triệu người dùng chuyển đổi những người không thể khác. Điều này làm tăng đáng kể thị trường Linux, thu hút nhiều nhà phát triển thương mại và cộng đồng hơn vào Linux.
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:
Điều này đưa chúng ta đến vấn đề con gà và quả trứng của Linux trên máy tính để bàn. Cho đến khi Linux có thể cung cấp nhiều ứng dụng hơn, thị phần của nó trên máy tính để bàn sẽ bị đình trệ. Nhưng cho đến khi thị phần của Linux trên máy tính để bàn tăng lên, sẽ không có nhà cung cấp nào phát triển ứng dụng cho Linux. Làm thế nào để phá vỡ vòng luẩn quẩn này?
Một lần nữa, Wine có thể cung cấp một câu trả lời. Bằng cách cho phép người dùng sử dụng lại các ứng dụng Windows mà họ đã đầu tư thời gian và tiền bạc, Wine làm giảm đáng kể rào cản ngăn người dùng chuyển sang Linux. Điều này sau đó giúp Linux có thể cất cánh trên máy tính để bàn, giúp tăng thị phần trong phân khúc đó. Đổi lại, điều này giúp các công ty có thể sản xuất các phiên bản ứng dụng Linux của họ và cho các sản phẩm mới ra mắt chỉ dành cho thị trường Linux.
Lý do này có thể được bác bỏ dễ dàng nếu Wine chỉ có khả năng chạy Solitaire. Tuy nhiên, giờ đây, nó có thể chạy Microsoft Office, các ứng dụng đa phương tiện như QuickTime và Windows Media Player và thậm chí các trò chơi như Max Payne hoặc Unreal Tourathon 3. Hầu như bất kỳ ứng dụng phức tạp nào khác đều có thể được chạy để có một chút thời gian. Và mỗi khi công việc đó được thực hiện để thêm một ứng dụng vào danh sách này, nhiều ứng dụng khác được hưởng lợi từ công việc này và cũng có thể sử dụng được.
Hãy xem Cơ sở dữ liệu ứng dụng của chúng tôi để có ý tưởng về những gì có thể chạy trong Wine.
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."