This page documents work needed to improve the WineWiki to be more complete, accurate, and easier to use/read. If you find a page with problems, which you cannot easily fix yourself (due to time constraints, knowledge, volume of work needed, etc) link it here and place a short blurb about what needs to change.
If you are new to this Wiki you may want to browse through WineWikiTips.
ListofCommands - Many references to pages which do not exist yet.
FAQ - Rework the old FAQ content (listed below). What can be salvaged, put back onto the wiki; what can't be, delete from this page.
- Improve/audit wiki pages linked from static pages (many used to be static pages):
Fix up the SummerOfCode page
- Add a few more details about how to apply
- Add more tips on how to have a successful project
- Triage suggested projects by feasibility/difficulty
Create a page on Prefix Management and link it to http://code.google.com/p/winezeug/wiki/ConvergedFrontends
Useful tools for improving this Wiki
WantedPages - These pages are linked to but do not exist
OrphanedPages - Pages which are not linked to from other pages. If it is useful information we should link to it from related pages.
PageHits - Pages at the top of this list should be well cared for and up to date to prevent misleading the masses.
RecentChanges - Find out what's going on in the Wiki
Old FAQ Content
These questions were removed from the FAQ for various reasons. These were originally in the "Old Content" section of the FAQ because they needed rewritten and/or moved somewhere else. To reduce confusion to FAQ readers, they have been exiled here until they can fixed.
Does it matter what filesystem I use? Windows only supports Fat32 and NTFS. !!!
Wine is written to be file system independent, so MS Windows applications will install and run under virtually any file system supported by your brand of UNIX. However please note that not all file systems / drivers support the full range of features required. One such example is ntfsv3 drivers that do not provide shared-write mmap, which cannot be emulated, and which is required by applications such as Steam.
-(make a note about case insensitive filesystems though) - Wine is a weird application in that it might actually work better in a case-insensitive filesystem. See (case-insensitivity link) for more.
Will Wine run only under X, or can it run in character mode? !!!
Most of Wine's development effort is geared towards MS Windows' GUI, but some limited support for character mode is available with "null" driver. It is activated automatically whenever x11driver could not be loaded. However Wine still requires xorg libraries to operate properly. And this will only work for pure console applications that also do not use any parts of the system that create windows for their own use. For example some parts of OLE do create internal windows.
Wine's infrastructure is already somewhat prepared for supporting other graphics drivers than x11drv, but no real "alternative" graphics driver has been developed yet.
Can I launch a Unix program from a Windows program?
Sure, Wine supports that. Just enter the unix program name wherever a program has something that it's supposed to execute, and it should just work.
You can also, launch a Windows program from a unix program without specifically calling Wine (like .sh scripts may be directly executed) however your linux kernels binfmt_misc support needs to be configured for this to work (e.g. there is a Debian package for this).
Keep in mind that Wine operates with 2 different paths - unix and windows. When calling unix program from Wine and wise-versa don't forget to translate file paths. This can easily be done with winepath.
What undocumented APIs / interfaces are not understood? Would seeing Microsoft source help? !!!
The best solution would be if the Windows API were fully documented, so Wine could be a perfect "clean-room" implementation. Seeing the source code might make it harder to prove that no copyright violations have taken place. That said, the documentation is often bad, nonexistent, and even misleading where it exists, so a fair amount of reverse engineering has been necessary, particularly in the shell (Explorer) interface. The biggest problem facing Wine though is simply lack of manpower. At one point, over 5000 people were working on Windows 2000. While Wine doesn't need to replicate all of Windows (we only cover the parts needed to make Windows programs work), that's still nearly 8 times more people working simply on one release than have ever worked on Wine, in the history of the project.
(rewrite/purge maybe: move to contributing FAQ)
What parts of Windows does Wine not implement? !!!
Wine's goal is to make it possible to run Windows applications on Unix. To this end it will provide replacements for just those DLLs and APIs that are needed by these Windows applications. This means that Wine will not provide replacements for DLLs that are not shipped with Windows or are always shipped with Windows applications (e.g. the Visual Basic run time). This also means that implementing an API that no application ever uses is not a priority. That being said, we will certainly try to keep our options open and to improve our API coverage as we can.
Also Wine is not an operating system, so that writing device drivers is not part of Wine's goals. However if you are interested in device drivers, the Linux, FreeBSD and ReactOS kernel developers would certainly appreciate your contribution.
Similarly Wine does not try to be a desktop environment so providing applets such as a calculator, a file manager or even window manager that look like Windows, are low priority or would even best be done as a separate project. Such projects would also to a large extant be redundant with other open-source projects. Again, there are projects that would certainly appreciate your contributions in this areas, such as the Gnome or KDE desktop environments. You will get the added benefit that your contribution will then be usable by everyone, not just by Wine users.