Slashdot Mirror
Ask Jeremy White and Alexandre Julliard About the Future of WINE
Last week, after 15 years of development, tempered by the need for arduous reverse engineering, the WINE project released version 1.0. What "1.0" means for WINE is neither that the project is finished, nor that it is perfect, but rather that the software runs a small subset of specific freely downloadable Windows applications. That's not to say it doesn't run scads of others, too -- the apps database is proof that thousands of programs run to at least some degree. Here's your chance to ask WINE developer Jeremy White and WINE project lead Alexandre Julliard (both of Codeweavers) about the future of WINE, or any other questions about the project that cross your mind. The usual Slashdot interview rules apply; please ask as many questions as you'd like, but limit yourself to one question per post. We'll pass on the best questions to Jeremy and Alexandre for their answers.
I hear people often say that its important for Wine to be able to run major applications like Office and Photoshop. However, from a migrate to Linux point, I think the thing that holds people up the most is the small propreitary applications that are written for a specific function. Is there going to be any focus on those programs in the future? Disclaimer, I realize that there are tens of thousands of such apps, but maybe many have something in common.
I think the question that is most pressing on our minds (and the one that will determine the magnitude of the pigs flying) is, "Will we be able to run Duke Nukem Forever on Wine 1.0 in the Year of the Linux Desktop?"
Comment removed based on user account deletion
1.0 is used to mark the API as being stable: it is now safe to build your Windows' program's source code against the wine headers without having to worry about them changing in the future.
That a few of the important Windows applications work was a side goal: the wine developers merely thought that it would be fitting, given the apparent significance of the 1.0 release name, to perfect support for what they can.
Perhaps you're thinking of wine the wrong way. It is, first and foremost, a windows-compatible API for porting applications to posix.
When are you going to start on that windoze emulator?
You are not alone. This is not normal. None of this is normal.
If in 10 years the dominant platform is Linux, or OS X, where does that leave WINE?
Vinegar?Isn't it a generally known fact that wine gets better as it ages?
Able to run any apps that are (still) only available on Windows. Many old apps are no longer produced, but runable in Wine (small, low use, very specific proprietary programs that businesses depend on, for instance).
Has anyone from WINE engaged apple to see about getting wine better ported and available to OSX users? I am currently using parallels to support my win32 needs under OSX, but that is all. I do not like the idea of having to pay FRP for a full windows OS when all I want to do is run win32 apps. I think it would be awesome to see WINE shipping directly in 10.7, with support from apple.
Modding Trolls +1 inciteful since 1999
Wine was a great idea in its day but now with multi-core CPUs and excellent VMs (VMWare, VirtualBox, etc.) do you still see the need for Wine?
Question:
With Vista stumbling terribly and now XP being removed from the marketplace, in the medium term do you see Wine / Linux as a true potential commercial viable alternative rather than just a niche as it is now? If so, what financial steps have you taken to prepare for legal threats?
Thanks!! :)
I can answer this one. WINE will still be around and used, because the (by then) 30 years worth of Windows software development will include applications still around and being used.
Also, using 10 years as the endpoint for Windows dominance doesn't address what happens between then and now. It's going to have to be gradual, and as development shifts to a different platform, I guarantee some developers will be tweak their code to run in either Windows or WINE, or use Winelibs to shoehorn most of their application onto OSX and Linux.
Square Enix has released 12 Fantasies, and each of those are like 30-50 hours long.
What's taken you so long to get 1 WINE out?
About where Dosbox is today I reckon.
How does your usual reverse engineering work flow look like? (How do you start, short note on tools, do you use (unit) tests)
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
With virtual machines becoming ever easier to install and use, maintaining a Windows VM on my Linux desktop substantially reduces my need for Wine. Will Wine become an afterthought in another ten years as we move to desktops running multiple operating systems simultaneously?
Any plans to improve compatability with Adobe apps like Photoshop, Premiere, InDesign, etc.?
SJW: Someone who has run out of real oppression, and has to fake it.
Will the WINE project try to implement the Windows Vista APIs or will the project aim only for the Windows XP APIs? Seeing that Windows Vista didn't catch on and a lot of applications are still written for Windows XP. Maybe it is a good time to iron out the DirectX 9 and Windows XP DLLs.
From Zero to Hero... Starbuck Zero
I hear that Microsoft are trying to get prohibition reinstated, just because that will take the their future problem of wine away now.
When I first started using GNU/Linux in 1999, I knew that if I wanted to run Windows apps, the best way to go about it was to dual-boot. Now, it appears that the most convenient way to run Windows apps is to run Windows in a virtual machine. Since both dual-booting and virtualization appear to be more convenient ways to run Windows apps than WINE, where does WINE fit in?
I write sci-fi for metalheads
Virtual environments are becoming increasingly useful and prominent. Do you see virtualization making a dent in the demand for WINE?
Hi,
Suppose that the APIs delivered with Windows XP are the 100% baseline for app compatibility that you want to achieve. Could you give an estimate of how much percent is already implemented and how much work it would be to implement the rest?
Thanks!
I would like to ask what your plans are to improve the process of/increase the number of people contributing to Wine? Do you plan to provide more feedback on patches (they are often ignored without comment), for example? Do you see Alexandre ever trusting other devs enough to take over subsystems/individual dlls?
By BEER do you mean BEos EmulatoR?
Wine seems to making large improvements on ease of use in Linux desktops, especially with the simple installation afforded by package managers. However, installation of Wine on Mac OS X remains complicated.
Are there any efforts underway to simplify the use and installation of Wine on Mac OS X?
What is the biggest obstacle in getting 100% Win32 API compatibility? Is it undocumented "features"? Inaccurate documentation from Microsoft? Fundamental differences between "Windows" and "Linux"? Other technical limitations?
I know the obvious answer is, "When it runs 100% of the applications that Windows does." But achieving that most likely would require far more resources than Wine has had to date, and it's not something you two can accomplish alone.
So at what point do you personally say, "That's it, I'm satisfied, I don't need to improve this anymore" ? Is there any set of applications that would make you happy? Do you have any such criteria?
Wine today runs fine, but as desktop linux visuals become better with nice themes, wine becomes more and more an alien in your computer. Is this any plan to make it more native in the look & feel?
What plans do you have for better multi-threading support?
Whenever someone runs a program in Wine, it is because there is demand for that specific Windows application on Linux. Should end users be encouraged to write to software developers and request Linux or Wine-compatible software?
It is dangerous to be right when the government is wrong.
When will we see Microsoft Visual studio 2003 and above running on Wine? It seems that thoose are some of the hardest applications to get running, since they install a number of updates even if you are running a relatively updated windows xp. .net 1.1 we have to stick with 2003.
Also i would like to be able to run Wine in Vista since a lot of programs doesn't run properly, but i'm forced into using it since our customer has installed it on all their pc's, and Visual studio 2003 does NOT work very well with Vista, but since their websites run
I've never used wine to run windows programs. However, I have used the source code as a form of documentation/verification while doing win32 programming. How do you feel about that?
Do you even lift?
These aren't the 'roids you're looking for.
I've been using Wine for a long time and its ability to run applications such as Framemaker, Photoshop, uTorrent and some other useful abandonware (Delrina Perform, anyone?) has improved my productivity significantly. Thanks for your hard work... and yes, I sent money!
I see Wine as the only serious option for rapid cross-platform development (Linux/OS X/Windows).
Now that the API is stable(r), is this how you'd like to see Wine evolve?
I'm excited to see Wine working in OS X on the Intel Macs. I have however run into problems in this configuration that I don't see with the same applications using Wine on Linux.
What are the challenges for Wine on OS X/Intel?
Rich And Stupid is not so bad as Working For Rich And Stupid.
I tried Wine and it worked terribly.
Exactly. It's a Windows emulator.(no, it's not, but for the purpose of the joke...)
It is dangerous to be right when the government is wrong.
With you working for codeweavers (which produces the excellent Crossover Linux package), do you see a conflict of interest in wine not directly supporting MSOffice 2K at the gold level?
As a related question:
How do you decide which portions of the code you write goes to wine and which are crossover-specific?
Help! I'm a slashdot refugee.
No, that's a VNC client.
http://www.mhall119.com
Microsoft doesn't have any grounds for suing. The codebase was written from scratch (so no copyright issues), and if Wine infringes on Microsoft patents, then so does OS X, Linux, BSD, etc. Would you say that all of those are wasted projects, since they are going to be sued and shutdown?
Also, even if Wine suddenly disappeared tomorrow, it still would not have been a waste. It has taken 15 years for Wine to get to where it is now, but it was being actively used during those 15 years. Tens of thousands of people have been successfully using Wine to get their work done for over a decade. That's a success right there. Moreover, the developers no doubt have found Wine very useful over the years... hence why they continued working on it.
If Wine is a "waste", then so is every long-term software project.
So, what are your plans for Wine 2.0?
The world is made by those who show up for the job.
Aren't you (Codeweavers, in particular) in the business of putting yourself out of business?
In Wine HQ "Why Wine is so important" you state that it solves the chicken and egg problem "Until Linux can provide equivalents for the above applications, its marketshare on the desktop will stagnate. But until the marketshare of Linux on the desktop rises, no vendor will develop applications for Linux."
So if Wine is the solution to that problem, doesn't that mean that once the problem is solved, Wine will no longer be needed (apart from for running some legacy apps but that is a development need that will come to an end). When Linux is mainstream, virtually all new apps - except perhaps Microsoft-made - will be released for it too so to elaborate on my main question; if (or when) Linux becomes mainstream and the only major apps not released for it are those by MS, do you believe the need to run them on Linux suffices to keep you in business?
The future of Wine? Really? I mean, what, are you gonna improve the Win32 API or something? It's not like you can put new effects in or build new technologies here: you're implementing a pre-existing API for compatibility. The future of Wine is more apps running faster.
Although most of the modern distributions recently changed into using Pulseaudio by default why did not recently released Wine 1.0 support it by default? At least on Ubuntu Hardy Heron and OpenSuse 11.0 there is no Pulseaudio plugin available at all. Although Pulseaudio will handle output from the Wine ESD plugin, it really does not leverage any of the more advanced capabilities. Are there any plans for making the Pulseaudio support more solid in the near future?
Of course. There used to be just IBM BIOS.
Now there's Phoenix BIOS, Award BIOS, AMI BIOS, coreboot (aka Linux BIOS) etc.
There now is Windows XP.
Perhaps there will be more non-Microsoft operating systems that are Windows XP and DirectX10 compatible.
Why do you think Microsoft _must_ keep releasing slightly incompatible versions of Windows every few years? So that nobody will come up with a legal compatible.
Does the WINE team think they will ever catch up with Microsoft's goal post moving? Microsoft seem to have stalled a bit with Vista.
What do you think Microsoft will do though if WINE becomes such a threat? Is the WINE team prepared?
WINE allows you to attempt to run those obscure Windows only programs, which seem to be all over the place. It is free in both the Richard Stallman free, and the beer free.
example: http://linux.slashdot.org/linux/08/06/04/0043239.shtml
Why the name WINE? Similar idea from LAME?
Throughout all your adventures with the Win32 API, what would you say is the most brilliant part of the system, and which is the most horrible? Like, for which systems would you say, "Wow! I wish I had come up with that!" or "Dear GOD NO!"
A while ago when I was reading into Wine I found information on Winelib. Are you still actively promoting the use of Winelib for developers interested on an easy cross platform solution? If not, what are your thoughts on people developing cross platform applications with Windows as the primary interest?
What is the status of Wine's implementation of ntoskrnl.dll? Is there a possibility of Wine being able to run Windows drivers, like ndiswrapper does for wireless NICs?
http://www.mhall119.com
I know making certain key applications work in time for the 1.0 milestone was one of the WINE team's goals, but I just wanted to thank the team, on behalf of everyone in the /. crowd, for making sure Notepad.exe was one of them. It was the first Windows program I tried to use under WINE and it performed flawlessly, making me feel a little more at home on Linux.
We Linux users have been putting up with the likes of vim and Kate and gedit for years, but all of these editors come with major caveats, such as multiple levels of undo and the ability to read both UNIX and DOS text files. With WINE I've been able to use Notepad to delete entire lines when I really mean to delete only one word, and get little square characters where carriage returns should be. I'm so pleased by this app that I'll probably move on to trying Paint.exe next (the silly GIMP airbrush tool isn't as satisfyingly pixellated as the one MS Paint perfected way back in 1995).
Keep up the good work in bringing the Redmond's best software to the Linux desktop!
Most desktop machines today are capable of 64-bit support. When will we see WINE running 64-bit Windows apps? Wikipedia says that this was to be considered after the 1.0 release. Well, 1.0 has been released, so can we expect to see 64-bit support in the future?
Per the FAQ, it'll leave Wine as the best way to run twenty years of Windows crapware. It's about the apps, not the platform.
http://rocknerd.co.uk
While Wine clearly has a place on today's Linux desktop, how do you think Wine will compare to using something like ReactOS combined with virtualization in the future?
ReactOS has the potential to eventually support both applications and drivers relatively effortlessly. And as virtualization becomes cheaper, will Wine still have the advantage in the long run?
.: Max Romantschuk
So is there?
Let us not become the evil that we deplore.
I've loaded WINE numerous times over the past years - primarily to play 'legacy' video games/simulations. I've had limited success with the specific stable of games I am interested in and own. I've also paid for Cedega which was equally dissatisfying. With the demise of Loki Software, and the limited titles that have been ported directly to linux by icculus.org and LGP to date - there is still a very large sector of games that many would say hold back adoption of linux as a gaming platform.
What are your views on WINE gaming, and what are you doing (if anything) to address this issue?
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Do you have any idea how difficult that would be? Emulating Windows down to the last undocumented quirk amounts to re-creating the OS from scratch. It's just not practical. If it were, we'd have already seen a version of WINE that ran all Windows apps without any fancy configuration.
How much do the Wine and ReactOS teams contribute to each other's projects? What are your personal takes on ReactOS? Do you think it can become a serious Windows replacement?
Stupid flounders!
Ask yourself, what's keeping Linux from taking over? All those Windows applications that people need to be able to run. If Linux ever displaces Windows, most of its users will be running software on top of WINE. And developers will be able to target Linux without learning a new API.
WINE could easily outlive the platform it was designed to emulate. Emulators often do.
Any plans to implement DX10?
Or at least make DX9 games (like HL2EP2) work decently.
Will WINE or Codeweavers make a commitment to fully support a recent vintage of MS-Office (2007, 2003, XP) as a platinum app? By "fully", I mean everything in the suite--including Access, Outlook, Publisher, the little helper apps, VBA, clipart, etc. When I look at WINE's appdb, I see no consistency to the ratings people give to recent versions of MS-Office, which means users are having varying degrees of problems. Unfortunately, for many people (myself included), MS-Office doesn't work with WINE... Why not assign a group of coders & testers the task of getting 100% of the functionality of this one extremely popular app working???
Windows 3.1x calc: 3.11 - 3.10 = 0.00
Wine was started before the rise in popularity of FOSS and Virtualization. If Wine did not already exist and someone pitched the idea of Wine to you would you: A) Tell them that it'd be better to promote FOSS software that can be ported to other OSes. B) Tell them to just use a virtualization product. C) Start Wine. Would you do it even if you thought FOSS would become more common than closed source applications in the future?
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
Re-implementing windows' libraries must be enough to drive someone to drink, so I would assume so.
Sure, but not right now.
Please place it in a vacuum-sealed bag and FedEx it to me along with a prepaid return-ship label.
I'll have it sucked, re vacuum-packed, and shipped back to you just as soon as I possibly can.
But only on the HURD version of WINE.
Is there a way to run a program in Wine (development version? debugging version?) that will log all OS calls and can be sent off to the devs to show where and what calls are made.
I ask because I've used Wine and one application (MS Wine) still has a lot of problems but I can't collect the information Wine gives about what's gone wrong in a way that makes sense to me. Some "bug drop" version to instrument would help me help them with what OS calls are there or not.
That would only make sense if the windows APIs were nicer than, or at least equal to, the Linux or Mac APIs. In parctice, no one in their right minds would write for windows (or wine) when they could have something sane.
but it is DEFINITELY NOT a success. Not even close.
If you count only those licenses that are genuinely used, I don't think even the base development costs of Vista have been recovered, to say nothing of the marketing and so forth.
It's gained them money mostly because it's replaced by XP but is still revenue gained WHILE SELLING VISTA.
But then they could have NOT made Vista and still made that money, whilst having saved all that developer cost.
If in 10 years the dominant platform is Linux, or OS X, where does that leave WINE?
Vinegar?Don't we already have enough sour grapes here?
my insights may be modded Funny, but at least some of my jokes are modded Insightful
Does WINE have any plans regarding the .NET platform? I know that Mono provides a lot of support for .NET applications, but most professional applications require the Microsoft .NET Framework to be installed.
Apple is a formidable enough corporate overlord to stave off patent litigation, but Microsoft has already taken action regarding percieved Linux violations, but that's beside the point....
Windows is Microsoft's bread and butter; in a direct way that Linux and BSD are not. They would make eliminating any perceived threat to their OS and Office suite monopoly a higher priority than eradicating Linus.
However, your point about the software being used during development is one I didn't consider, but still --I'd be very surprised if MS's lawyers aren't sharpening their knives now that WINE is out of beta.
Premise:
I was a very hopeful wine user, and even tried to contribute
some small improvements to the project that never went anywhere
(support for the undocumented INI empty section and empty keyname
features of the profile kernel32 API), partly since I had
no real windows to test on, partly since I could not establish
a good dialog with the developers, partly because the applications
using this undocumented behavior are not the big known apps.
Question:
Currently wine strategy seems to be (correct me if I am wrong),
to target one application at a time, privileging the big known
apps, with less interest in supporting the smaller apps,
or in breaking them with new versions:
is there any chance that after getting most of the big apps
working, the current strategy will be changed to focus on a
more generic solution, matching the win32 API as closely as
possible, in order to support most if not all of the small
programs, and thus enabling much more migrations to free
software-only solutions and thus achieving world domination?
(http://www.catb.org/~esr/writings/world-domination/world-domination-201.html)
Thank you -
I don't get all the questions about Wine's support for MS Office. I think most of this comes from people who haven't tried Wine in years (or maybe have never used it at all). I run Office 2003 under Wine every day, and have for awhile. PowerPoint doesn't work, but Word and Excel run perfectly fine. Once in a blue moon I get a crash, so I save my work a bit more often than I normally would under Windows, but it's nowhere near frequent enough to be a problem for me.
Why the Wine team chose to target the Word and Excel VIEWERS for "official support", rather than the apps themselves, is a bit of a mystery to me as well. However, those two base apps DO run fine under Wine currently. Seeing as how those two apps are the only reason I'd ever need to run Windows in the first place, Wine is good stuff in my book.
Given that XP is at the end of life, I think Wine has an important role in keeping legacy software alive. One such app is Macromedia Freehand. This vector drawing program still has a dedicated following, even though it hasn't seen an update since Adobe bought Macromedia in 2005.
As far as I can tell there is no way to open Freehand documents in Linux. XP will not be available for much longer, and Freehand MX is not Vista compatible. There are a lot of graphic artists with a lot of data still in Freehand format, and they're going to need to access their art on modern operating systems.
Freehand almost works on Wine 1.0. It requires a dll download to run, then it works pretty well, except that the 'more fonts' menu doesn't work. It's 99% there. So my question is, is there going to be a push to get important legacy apps like Freehand 100% perfect? Or is the focus going to continue to be modern windows apps?
Give me Classic Slashdot or give me death!
First of all, I'm not a hardcore gamer. I do play Diablo II with Wine, and play the native NWN game on Linux - and surprisingly, the former works better.
Even though I haven't been following the Wine project eagerly, I see it as my best way out of Windows because of games (I have pretty much everything else covered by Linux).
Hence my question: I guess you have had your share of requests to port Direct* APIs to whatever platform Wine supports today. How hard has it been? Would you say that Direct* _is_ a better all-rounded API for games than what is available on the platforms that Wine runs on today?
Who said anything about Cider? That's a Mac-specific proprietary port of WineLib, the product under discussion. The market for Cider is much smaller than the overall market for WineLib, so saying that Cider isn't that popular really doesn't say anything about WineLib. It could be that the free WineLib is good enough that very few people porting apps off Windows need to bother with Cider. Or that people using WineLib to port stuff want to end up with Linux versions, too.
What are your biggest priorities and how well are they being worked on and fulfilled currently?
It seems many times installing Windows programs under Wine requires a great deal of jumping through hoops and special tricks. Is there any thought of creating some sort of script or configuration file that can be made available through the AppDB, so other users could easily adopt settings or sequences that have been found to work for a give application?
I know about usb-storage support, it works perfectly, but what about full USB support?
Many USB devices require Windows apps to use them correctly. For me, Line6 USB products for audio come to mind, but i'm sure there are plenty of others.
From what I've seen in the wine-devel discussions, it looks like a tough challenge. Are there any takers yet? What are the main showstoppers? Or, am I totally wrong on my figures and these other USB devices are not used that much?
If these are a lot of questions, please stick to the first one :)
The IRS will be President?
DRM: Terminator crops for your mind!
WINE shouldn't really release like a label or logo for games of some type that would allow buyers of some games to know that said game would play on an alternative platform than windows like Linux with WINE of course. that way it could help get the word out to regular people that yes many of the applications that you pay hundreds of dollars for can run on an open platform. you could do it through the website and the developers of other applications and games could include links to their apps being supported and links to bug fixes and stuff.
I was able to get the PC version of Oblivion running on Linux, via wine.
That's something which some Windows people have failed at, even though the game is written for Windows!
Applause and congrats are due all around.
Hmmm. That makes me wonder if you've ever thought of porting Wine to Windows? ;)
The Wine AppDB said Commandps: Behind Enemy Lines would run without any problems and had a Platinum grading. It was true, Commandos ran as if it were on Windows.
But, there was slight discomfort while playing the game, it did not have the "smoothness" or the "free flow" of playing it on Windows. The game often jerked as it should be expected for a game that was not fine tuned for Linux. Anyone who wanted to win the game would play it on Windows.
What I need to know how do you make sure an application has Platinum grading, and claim it will run without any problems on Linux? I get a feeling that App Testers exaggerate things a bit. What do you do to prevent exaggeration.
familiarity > sanity.
Just ask 98% of the PC-using public.
DRM: Terminator crops for your mind!
Dosbox has a future because it is cross-platform. Wine, on the other hand, only runs on x86. I'd say it has a bleak future compared to dosbox.
Could someone pretty please work on porting x11drv to Windows? Or a way of converting GDI calls to X? I saw some discussion on this topic a few years ago on the mailing list. I run coLinux on a full screen X server, and I would really love to be able to run my Windows applications inside the X window manager.
How has Microsoft interfered in the success of WINE? Any good examples?
Fifteen years? Geez, wouldn't the time have been better spent writing Linux apps that are better than anything in the Windows universe?
-- Slashdot: When Public Access TV Says "No"
Some have said that Wine DLLs run on Windows. This is to be expected.
Now given that you are in the process of implementing Direct3D 10, do you think it could be a solution to the mess that is Microsoft's insistence that D3D10 only run on Vista? Would it be feasible that users could take the Wine DLLs, install them on their XP system, and get around the OS upgrade?
ROMANES EUNT DOMUS
What does "nicer" have to do with anything? Sure, if all other factors are equal, people will use the nicest tool. But AOF rarely are equal. In this case there are a lot of factors: legacy code, the hassle of learning to use a new set of tools, etc, etc.
Programmer's may want to switch tools when better ones become available. (Or may not: people often prefer the tools they know to the ones they don't, regardless of the technical superiority of the latter.) But that doesn't mean they can. Retooling is not free.
Are there plans for WINE to directly target developers of legacy Win32 apps? For instance, I cannot find detailed API docs on the WINE site; you have to go to Redmond for that. The existence of such docs from WINE would have some added benefits: 1) increased mindshare for WINE; 2) much easier evaluation of what can be ported to WINE; and 3) enhanced debugging of WINE itself by comparing code behavior to the WINE-supplied documentation. Am I missing something here? Could this turn into an embrace-and-extend campaign?
Yup, and "easy to use" is more about familiarity than it is intuitive. I find Windows to be less and less easy to use these days simply because I am far more familiar with Linux. People will ask me things like "I need to fix all the spelling of all the artist tags on this directory full of mp3 files"
I think.. Easy, just id3v2 with foo options, and maybe find|xargs if I'm feeling fancy. Or if it's "I have a bunch of filenames with this format, but there are no tags".. easy just a little for loop with some sed or something and id3v2 and poof, done in seconds.
On windows.. crap, you gotta go find some tag editing GUI thing that does the exact operation you want.. I give up after a few min and say "Sorry, I don't know how to use Windows."
Reinventing bochs (or an equivalent) by including it in Wine would be an engineering mistake. For many, Wine runs faster than Windows itself... that's a big selling point.
I would like to be able to access applications on my windows side of a dual boot system while being booted on the Linux side. To do this I expect I would have to use the windows registry so that the settings would work.
Is this possible, or will it be possible under Wine?
Haiku
-Docvert converts MSWord to OpenDocument, clean HTML
Further, Wine (in theory) could provide a higher level of backwards compatibility than Windows chooses to. For example, what about older games written for Win9x which do not run on Win2K/XP properly? I know there's many other programs which don't run under NT but do run under 9x, as well. It'd be nice to be able to run that code again, even if it is "ancient" or "obsolete".
Hi,
Many thanks to wine developers for providing such an application. I would like to ask a few questions.
1. Is windows API exhaustively documented by MS? If yes, why is wine lagging behind so much? If no, why is nobody suing MS?
2. Among all windows apps on earth, what is the approximate percentage of windows apps that use undocumented hooks/syscalls/apis in MS Windows?
My best wishes.
My one question is when or if Wine will include some means to configure the amount of RAM and HD sizes that are reported to running application, including Windows itself, given that legacy Windows versions can't handle more than 512 MB of reported system RAM. Pulling some memory modules or crippling the host OS don't seem to be very practical solutions to what I consider to be the one reason why I can't use Wine at the moment.
I've tried to use Wine to run some windows-only applications and for some I ran into a snag: They use Windows DLLs which are not shipped with the Wine distribution.
In a recent case I had to hunt down several DLLs - from different sites - to get an application to install and then to get it to run. And at that point I hit a wall: It used the Jet database. Though I had a DLL that implemented the interface, I was unable to figure out how to get it the database to operate. I'm still not sure whether I got an inconsistent set of DLLs or missed an install step.
What I would have liked was a set of pages on the WineHQ web site giving:
- A list of what DLLs satisfy what dangling linkages.
- A pointer to a place, or set of places, where a consistent set of DLLs that work with Wine could be downloaded.
- Instructions on installing DLLs.
- Instructions on installing and/or initializing any support packages (such as Jet?) that need more setup than just stashing the DLLs in the appropriate directory.
Unfortunately I could not find such a handy reference.
Q: Is there such a reference? If so, what is the URL? If not, could the project please create one?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Then presumably it will have done its job well and can retire happy and fulfilled!
Don't ever tell a hacker that something can't be done. For he'll make Linux and his followers will create a whole desktop, graphics apps, office apps a web browser and conquer the world. If there is one thing I've found out in the past 11 years of using Linux, its that it CAN be done. Nothing is impossible. It just takes time.
For all we know, in 10 years Microsoft will have ditched their platform, moved their office apps to run in KDE/Gnome and everything will be Linux/BSD open source based.
I found that pretty funny, if trollish.
Seriously, though: how come whenever someone talks about windows sucking (not up for debate) there's a li'l posse of gamers saying "waah, WoW etc. reet rah"?
Go buy windows and all its acoutrements if your games are that big a deal to you. Most people use their computers for work and when they're done with work they go and do something that doesn't involve computers.
My turnips listen for the soft cry of your love
Wine is just an API computability layer, whilst DOSbox is an actual emulator which emulates the actual CPU.
If you want to see how cross-architecture Wine is it can run on PPC Macs using Qemu: http://wiki.winehq.org/MacOSX/QemuWork
Unicode in Slashdot
Hm... I'll bite!
Over the past few years we've seen major architectural concerns calm down. The DLL separation took a while, we had the major filesystem rewrite, and then in the past year we had the big windowing changes. Oh, and then throw in the big changes to support copy protection, real services, and oodles of D3D updates.
So where does that leave us? Are there any major architectural changes in the pipe? There are rumors Codeweavers will integrate a DIB engine - what does that do and why is that necessary? What about in the RPC world? Jeremy - you've battled with audio, how do you feel Wine is doing with regards to audio support?
----- obSig
Number of people ask what percent along are you.
Looking at where you are now, and what it's taken to get there... can you give an estimate of MAN hrs to get to a number of MILE stones you might pick..
win 3.1, win 95,win 98, win 98se, 2k, XP. .net versions
server versions
Vista?
direct x versions
(no i didn't miss ME is there anything that "requires it?")
I would think it's understood that one can't give 100% accurate numbers but i think it might be of value to everyone involved to have an estimated times for some target goals.
And thank you for your time and all the hard work you have put in to this.
While WINE is a useful wrapper for Windows-based Software, I find the biggest drawback to the use of it is that no software company will offer support for the software (paid for software) unless it is installed on a windows-based system, thusly giving the companies an incentive to not only drag their feet in producing a native client/application, but also an incentive to encourage you to use WINE to help the company cut costs on support calls.
what is the WINE project and/or the Code Weavers company doing to encourage software vendors to produce native linux versions of their software? As well, what is the WINE project and/or Code Weavers doing to encourage software vendors to offer support for WINE-based installations of Windows software?
How about supporting apps like CorelDRAW and the other from CS Suite like FLASH Illustrator, InDesign and Related. I'm more concerned about CorelDRAW. Yes, I know CorelDRAW is not so popular in the US but it's vastly used in third world in places like Brasil, india etc and it's per se a standard in design here. Unfortunately CorelDRAW relies too much in IE engine; Try upgrading to IE7 after you install CDX3, not only You have to reactivate your copy, but if you're not in mood of applying the SP's your CDX3 will be useless, It' will crash even creating a new document, and BTW and FYI If you apply the SP's you rendering performance will be hindered [NP I'm flaming Corel in that one]
Most people can survive with Photoshop and CorelDRAW my question is: Is there any hope to see support for CorelDRAW (X3/X4)and FLASH in WINE?
I don't have numbers but Design Community sure have more people than Gaming Community, people that relies heavily in uptime, people that are actually doing work in there.. work that you have to show to your clients, and clients that get very interested when they see their brochures inside some neatly customized compiz environment, Clients that ask: "What windows is that?" and you know the rest of the story.
Again, thanks and keep on the good job WINE team.
[If] when WINE reaches a satisfactory point of development, do you plan on marketing WINE in similar fashion to the "Games For Windows" campaign? How do you plan on getting WINE out there into mainstream as a big "name"?
Speaking of Mac support, what the heck is up with OpenGL support under the Mac version of WINE? Under Linux everything is great, a fair number of games can be used and everyone is happy. On the Mac side of things the OpenGL implementation is completely FUBAR and you can't do any 3D gaming with stock WINE; you have to use Codeweaver's CrossOver Gaming, which isn't free as in speech, free as in beer, or as good as stock WINE on Linux. Crossover makes it work, so whatever is broken can't be that hard to fix, can it?
Anyhow what the heck is going on as far as OpenGL is concerned? It's been broken for ages and I think everyone would like to know when it's going to get fixed.
Ask yourself, what's keeping Linux from taking over? All those Windows applications that people need to be able to run. If Linux ever displaces Windows, most of its users will be running software on top of WINE. And developers will be able to target Linux without learning a new API.
WINE could easily outlive the platform it was designed to emulate. Emulators often do.
I agree- theres a few games I can only play on emulators that were written on systems like the Commodore 64, Windows 3.1, and so on.
I'd say the same for the NES, but I still have a working console :)
Other than porting, compatibility layers or emulators are the best ways to keep old software running. Instead of wasting time porting each and every program, you can write a single program that can essentially make everything work.
There's nothing wrong with backwards compatibility, but I think that there are better ways than going about it than others (emulators, compatibility layers, etc).
Any priority to making sure VS 2008 runs on WINE, so that I can run VS 2008 on WINE in order to develop apps for Windows that I can then run under WINE?
I know that windows XP (and probably other versions) have a feature that dynamically changes the behavior of certain parts of the OS depending on the application being run. This is to allow applications that depend on bugs/behaviors specific to a version of windows to run.
Do you plan on implementing something like this?
Q: Previous interviews of eminent wine developers ([1] [2]) show the common need of a better regression test suite/framework. Is it the time to start some serious planning about it? Would existing (e.g. AutoIT, [3]) technologies help in the task?
FrancescoP
[1] http://www.winehq.org/?issue=348#WWN%20Wine%201.0%20Interview%20Series!%20%20Interview:%20Alexandre%20Julliard
[2] http://www.winehq.org/?issue=346#WWN%20Wine%201.0%20Interview%20Series%20Part%201,%20Dan%20Kegel
[3] http://www.autoitscript.com/autoit3/
When will Wine begin working on implementing Windows NT Services and when is this work likely to be completed?
I tried Wine and it worked terribly. I've stopped wasting my time trying to make things work in Linux. I'd rather spend the time being productive.
Productive? "You seem to be looking for a way to do stuff, would you like some help? Click a if you are trying to get out of a phone booth. Click b if you would like to peel an apple. Click c if you would like to do something else."
She made the willows dance
Which one would you classify as an intelligent question to be asked to an expert of Wine?
An important goal of DOSBox is support for games. Is support for (the newest) games an important goal of Wine or does it focus more on office applications?
Lots of Windows applications run on Wine. However, on Wine the application called ".NET framework" can't be installed and you need to use Mono instead. Since .NET is software that runs on Windows, what stops it from running on Wine? If there wouldn't be technical problems, would Wine have been made to support running the .NET framework, or is there another, non-technical reason why you need to use Mono instead?
He did that already but forgot to write the return address on the parcel and forgot where he posted it. I don't know, some people just like having a detachable penis.
What plans do you have for better multi-threading support?
Multi-threading works just fine as far as I know. If you are aware of any issues I'd suggest to report them to the wine-devel mailing list.
The way I look at the crossover vs. wine distinction is: wine is 100% pure "do it right" source code, and crossover is wine plus some code that doesn't meet that standard yet, but does make Office (and other supported apps) run well. (See http://www.codeweavers.com/products/source/ for the hacks in question.)
So really Wine is where the action is for developers, and Crossover is what end users who need Office to run well should run. The only reason Wine doesn't run Office well yet is that nobody's figured out how to do it right yet, and the temporary bandaids that do it wrong but work for now are in Crossover. If you figure out a clean replacement for any of the crossover hacks, they'll gladly commit them into the Wine tree.
In other words, from what I can see, Codeweavers' heart and actions are 100% where they should be from a free software point of view. All apps are permitted to run under Wine. None are reserved for CX.
Does that help?
(Disclaimer: I'm a big Codeweavers customer, occasional Wine contributor, and release manager for wine 1.0.)
"I'd love to switch to Linux, but I have to have Quickbooks/Quickbooks Pro and TurboTax." Can't tell you how many times I've heard that. Having the latest versions go Platinum on Wine--and keeping it that way--would do more to promote Linux home and business use than anything else in sight. So what's the issue? Do you disagree, just favor games, find the task impossible, worry over a legal reason, or what?
Are you going to make some improvements security wise and administration wise to the Application Database so not just anyone can login and trash the listings, or is it going to continue to be more or less a free for all wikipedia style system where vandals run wild?
As in multiple threads within a single process being scheduled to run concurrently on different processors? I've just naively run my Windows app on the latest Ubuntu on a quad core and my app was only aware of a single core. I can see that Wine handles multiple threads within a process (it quite clearly has to), but somehow they don't get scheduled concurrently onto different processors.
DOSBox can probably run these "low level" applications quite nicely and redirect serial port access to the TTY/COMx of your choice. It's designed to emulate a real-mode or x86 protected-mode DOS system with a virtual (and configurable) set of hardware that maps to your real hardware. If it can run all those crazy DOS games from the early to late 90s I don't think router control software is out of the question. They should try it.
Also, DOSBox runs on XP and Vista. (Boggle!)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Other than porting, compatibility layers or emulators are the best ways to keep old software running. Instead of wasting time porting each and every program, you can write a single program that can essentially make everything work.
When I first learned to program in the early 70s, the leading machine was the IBM 360. Guess what the leading compiler was for that system. Fortran? PL/1? Algol? No, it was a program that translated legacy IBM 7090 machine code!
One thing I wonder about future development (besides the obvious "what's planned for WINE 2.0?"):
There are lots of tweaks and dependencies that have to be taken into account when installing Windows applications in WINE. There have been some attempts to address this issue in WINE-Doors, Winetricks, and Crossover, but I can't detect any systematic approach to handling this issue in WINE itself.
Are there any plans to simplify this process? Have you considered looking to package managers (e.g. apt) to take care of listing out dependencies, downloading/installing them, etc., at least for things that are available online?
Because it would be great, IMO, if I could do something like set up an additional APT repository and type something like "apt-get install ie6-wine" and have it all taken care of for me.
I'm sure that's a lot to ask, but are there currently any plans in the same vein?
It will be renamed LINO - LINE is not an OS.
And converted into an OS (running under a microkernel) that will simulate the Linux SDKs and Kernel intricacies, attempting to allow you to run Linux apps on a Windows platform.
I work with many small businesses that could greatly benefit from Linux and many OpenSource applications. The biggest stumbling block I find to converting these people is the fact I cannot get Quickbooks to run on WINE. IF this single program was able to run as on native Windows, I don't think most small companies would ever need the Windows tax. I am still hoping that there is a viable alternative, but for now I'm hoping WINE might save the day.
Are there any plans (long term or not) to implement the PE format as a native executable format like the ELF format and if not, why not?
I can see that Wine handles multiple threads within a process (it quite clearly has to), but somehow they don't get scheduled concurrently onto different processors.
If they don't max out one core, then Linux will schedule them all on one core because that will be more efficient (cache sharing). However if each thread could use 100% of the CPU, then they should clearly be spread to multiple cores and, as far as I know, it's what happens normally. If so, then it would be worth investigating why it's not happening in your case. Maybe post on wine-users or the new Wine forum giving details about your application, workload and setup so others can hopefully help you diagnose more precisely what's happening.
I don't see why, a priori, scheduling onto a single core will be more cache efficient. If my threads are working on separate data (and that's essentially the goal of all parallel compute intensive software) then wouldn't it be better to schedule to different cores so that each thread can have an entire cache rather than sharing.
Anyway, the reason why I want my threads scheduled onto different cores is because they are maxed out. In fact Linux is not really relevant for my app because all my users are on Windows. I was just for fun seeing if it would run under WINE. I have to say I'm hugely impressed with what the WINE folk have done.
I don't see why, a priori, scheduling onto a single core will be more cache efficient. If my threads are working on separate data (and that's essentially the goal of all parallel compute intensive software)
For the special case of parallel compute intensive software yes it's better to schedule each thread on a separate core and Linux is supposed to do so. But this is a special case and since you did not provide this information before I had to envision all possibilities (and I did cover both cases).
Anyway, as I said before this is not the place to discuss this...
The only reason I still have Windows at all is for fruityloop.
When will you get it working?
It's the single piece of software that forces me to keep Windows.