Slashdot Mirror

If you read the thread on the mailing list, Steven Edwards considers this. But, as 10.4 doesn't have this "secret" ability to load the PE format and also supports EFI (on Intel anyway) it's probably not there for this purpose.

You're right about that, but it's obviously got the fanbois worked up. They're modding me to oblivion, for some reason.

A lot of the speculation is coming from the guys over at Wine. They found PE loading capabilities in Leopard that wasn't there in Tiger. Further dissection shows that Apple is hiding references to *Win* and *PE* in the dll, which means it's not an accidental inclusion.

The moderation of my original post is interesting too. I don't think there's anything particularly provocative about it, yet it's attracting "troll" mods. Strange.

You're right about that, but it's obviously got the fanbois worked up. They're modding me to oblivion, for some reason.

A lot of the speculation is coming from the guys over at Wine. They found PE loading capabilities in Leopard that wasn't there in Tiger. Further dissection shows that Apple is hiding references to *Win* and *PE* in the dll, which means it's not an accidental inclusion.

The moderation of my original post is interesting too. I don't think there's anything particularly provocative about it, yet it's attracting "troll" mods. Strange.

You're right about that, but it's obviously got the fanbois worked up. They're modding me to oblivion, for some reason.

A lot of the speculation is coming from the guys over at Wine. They found PE loading capabilities in Leopard that wasn't there in Tiger. Further dissection shows that Apple is hiding references to *Win* and *PE* in the dll, which means it's not an accidental inclusion.

The moderation of my original post is interesting too. I don't think there's anything particularly provocative about it, yet it's attracting "troll" mods. Strange.

Why use windows? It's cheaper than Apple, gives me more options, and i don't have to manually do everything like I would with linux.

• I plug in a device, it usually works out of the box. No drivers required (this includes tablets, bluetooth, wireless cards etc)
• On the off chance a device doesn't work after I plugged it in, I start restricted-manager, which automatically downloads the required (proprietary) drivers and sets up the system for me. Working immediately after that (exception is graphical drivers where you will need to logout and back in, or simply restart).
• I do not need to defragment my drives or invest in expensive software to maintain for me (while many people do not under Windows, I do because I notice the performance difference -- Hell, it's so bad that Valve even had to add a defragmenter to Steam). Linuxs' file systems just do not require it.
• I do not need to manually go around to websites, download the applications, install them. The distribution's repositories contains the majority of notable software.
• I do not need to constantly visit websites to find updates for my preferred software, the package managers in my distribution inform of updates and let me install them automatically if I so wish

I use windows because out of the box I can play games with my friends, I can connect it to my 360, I can use 100% of the software that I WANT to use.

If these things are even possible with your alternatives, you have done a pathetic job of making that information available to the non-geek inclined public.

The bookeen does not support Linux, even though it is linux-based... go figure. Read the FAQ under point 8 "The Mobipocket Desktop Reader is not available fro Mac and Linux. On these machines, the Cybook is seen as a simple external storage drive and the Mobipocket files must be transferred manually." I guess you could say they are being nice by not deliberately locking-out non-windows users, but if I'm gonna pay that much, then ALL features should work for Linux. Furthermore, it doesn't look like there's a linux prog out there that does the same thing as mobipocket or ereader. I would love to be corrected on this point but that's what I've seen so far.

The specific incompatibility is this: the software that the reader uses for synchronization, "mobipocket", is windows-only. The features seem really cool though - it can even download RSS feeds so you can view them offline. The WINE Entry for this program says it crashes frequently so that's not an answer(Does wine ever work right?)

Also noticed... ebooks can sometimes cost more than their paper-based counterparts.

When users think of an emulator, they tend to think of things like Super Nintendo emulators or virtualization software. This is the wrong way to think about Wine - Wine runs Windows applications in essentially the same way Windows does. There is no inherent loss of speed due to "emulation" when using Wine, nor is there a need to open Wine before running your application.

I get you did not get the memo: Wine Is Not an Emulator.

Good. Hit a nerve with that one.

Even if those home users are stuck in the Windows quagmire (for whatever reason or excuse), most OEMs still allow purchasers to upgrade from MS Vista to XP for the asking. That's the catch though, they have to ask for the upgrade from Vista to XP or else they're stuck with the infected machine.

Seriously, for 99% of what most home users do, Kubuntu / Ubuntu would be a drop in replacement -- except for the maintenance and malware nightmares -- and it's now possible to get Ubuntu installed on several big brand OEMs like Dell. WINE is seriously underrated for the one or two legacy apps holding people back.

No, Cedega doesn't generally contribute back to Wine. The two are basically completely separate projects now. http://www.winehq.org/?issue=329#Cedega%206.0%20&%20Wine%20Benchmarks

• Cedega's core is based off the original Wine tree and was forked in 2002. There are several core components that no longer share a similarity with Wine as it exists today.
• TransGaming has not actively contributed to Wine in about 5 years with the exception of a few patches (less than 5 a year.)

it's insane to expect blizzard to start supporting it's game on such an unpolished platform.

Also, MS provide very good tools for migrating your applications from XP to Vista. Can you say the same about Wine?

I have no doubt blizzard have looked at the numbers and found supporting a linux version to be unprofitable.

For languages:

• Parley - Introduced in KDE 4
• KVerbos - in the Edutainment package of all KDE-based distros
• Rosetta Stone under Wine (gold rated as of 2006)
• Konjue - an add-on, but useful

For Physics:

• eduKator - an hypertext based book for physics instruction with working examples
• Step - a physics particle simulator

For Math:

• KAlgebra - a function plotter with advanced capabilities
• Kalcul - simple arithmetic trainer
• GeoGebra - similar to geometer's sketchpad
• At an upper level, Scilab, Octave, R, QtiPlot, RKWard

For geography:

• Marble - to be released with KDE 4
• KGeography - currently in the KDE Edutainment pack

For music:

• Score Reading Trainer
• KLearnNotes2 - a basic score tutor
• NoteEdit - reads midi files and converts them to scores - also great for composing
• A ton of other audio programs including Audacity, Rosegarden, etc. for composing, editing, multitracking...

For Mind-Mapping:

• Semantik

I play 32-bit EVE Online under 64-bit Wine on 64-bit Ubuntu. Works pretty nearly perfectly.

http://www.winehq.org/site/download

You have to add Wine's own repository to Ubuntu's "Software Sources" (System->Administration) that's all. If you're not using Ubuntu, then do the equivalent for your OS. Wine has both Debian-style and Redhat-style repositories available.

Enjoy.

The people who made WINE are probably crying now....

I'm curious. Were you using the WineHQ's repositories for Wine? Because I didn't see this issue on Edgy either (I was using WineHQ's repositories).

If this person had hacked Microsoft and posted the Windows source code online you would all be heralding him as a true freedom fighter.

Wine provides 64bit Ubuntu packages. There is a repo from www.winehq.org. Debian and Ubuntu have a 32bit compatibility layer (roughly speaking) built in. So you can execute any 32bit code as normal. You can install a 32bit Firefox if you desire, and it will not bother the 64bit Firefox. So you can have all 32bit plugins. In a nut shell, there are no issues.

Yes: http://appdb.winehq.org/objectManager.php?sClass=version&iId=9432

Well, it's getting there... recently I've become a fan of World in Conflict, thought I'd check out winehq just for laughs, figuring it's new and latest-gen and almost certainly doesn't work. Well, they got it working and seem to work fine BUT it involves:

1. Two manual copies of files
2. Downloading a cracked exe from gamecopyworld
3. Opening a terminal and making a dll override
4. Getting another dll from a Windows install, making another override

Granted, that's enough dark voodoo to scare away 95% of users but probably not the ones interested in running Linux in the first place. My gaming rig is Windows and will stay that way a while longer, but wine continues to surprise me. I've heard World of Warcrack runs fine too, to put it this way - a lot of the people playing WoW aren't concerned with compatibility of any other game. Right now it's more along the lines of "why go down the thorny path, when there's a well-paved road called Windows?", but if push came to shove I'd make Linux work well enough for me.

I'm just gonna post the following each time someone says its the year of desktop Linux:

GAMES GAMES GAMES
Most of the top 25 requested apps for wine are games - http://appdb.winehq.org/votestats.php
(Also note these are games that seem to benefit the most from a mouse)

I know I can do everything else under a Linux based OS (e.g. Ubuntu), but the only reason I have windows OS on my PC is because I enjoy playing games.

And buying an MS or Sony console seems a bit "Meet the old boss same as the new boss".

I believe yes, it is.

Sort of, Im not that aware of the project on that page, but WINE is trying to get it to Linux/XP
http://wiki.winehq.org/FAQ#head-fbaa851e07d7484640cc10b6d0c48abc741260b2

from that page

Does Wine support DirectX? Can I install Microsoft's DirectX under Wine? Wine itself provides a DirectX implementation that, although it has a few bugs left, should run fine. Wine supports DirectX 9.0c at this time. Plans for DirectX 10 are underway. If you attempt to install Microsoft's DirectX, you'll run into some problems. You can install the runtime, but it will not run. The runtime needs access to the Windows drivers, and Wine cannot access them for obvious reasons. The only native Microsoft DLLs that could be useful anyway are the d3dx9_xx.dll type ones, and these require you to accept Microsoft's license. Regardless, don't try and do this.

Just because you can't does not mean Linux can't.

VideoConference http://ekiga.org/

Edit Video http://www.kdenlive.org/

Make mp3s: Insert CD copy mp3 folder with kde.org or Create new with http://audacity.sourceforge.net/

play video games with http://www.winehq.org/ or http://www.transgaming.com/ or god forbid you play open source games designed for linux. Too many to list see here http://icculus.org/lgfaq/gamelist.php for a start.

make a slideshow, Ever use http://picasa.google.com/linux/ or KDE creates them on the fly from directory of pictures. Not to mention openoffice Impress http://www.openoffice.org/product/impress.html

How about a couple of kernel devs drop off and help Linux go the last mile.

How about you let the kernel devs do what they do best, and acquaint yourself with a little thing I like to call Google http://www.google.com/webhp.

sounds like your friend will be a skeleton sitting there next to those laptops collecting dust himself before they offer driver support for Windows XP. Is it possible to run the applications that he needs with Wine? If so then Ubuntu awaits, either that or he can eBay the vista laptops and bid on a used XP laptop (or at least one that has hardware with XP drivers available). Heck, the Vista debacle may even increase the value of good used XP laptops...hehe he better bid soon if that is what he decides to do.

1. It uses a more modern business model
   free software => free unlimited innovation possible
2. OpenOffice uses ODF which is a multi-platform ISO standard instead of that OOXML crap.
   => you can exchange documents between many different platforms.
3. It runs natively on GNU/Linux, Mac, Solaris, (soon FreeBSD) and many other systems, no need for e.g. Wine.
4. It can generate LaTeX, which is good when you want to make a professional publishing of your text.
5. OO can generate PDF natively even though I rarely use this option as the generated PDF files are too big.
   I use to print to PS and then run ps2pdf instead

Future solution: either using virtualization or crafty API emulation, make Linux be able to transparently run Windows games and software.

Nope, that's a trap. OS/2 was essentially 100% Windows 3.1 compatible, and what happened? Developers thought, "Why bother writing an OS/2 native app when I can just write a Windows app and be compatible?" So OS/2 never got any apps to speak of.

Linux needs a better, cross-platform gaming API. Fortunately, it has one.

However, if you really have your heart set on compatibility, check out WINE. I'm running a few older Windows games (Alice, Freedom Force, Tomb Raider III) flawlessly with that. Many of 'em don't work, but I'm surprised how many are playable.

Nice, but ehm... was I the only one who thought 'load/run arbitrary Windows executables from your Linux desktop/commandline' ?

(I know that is possible for a large number of specific Windows applications -through Wine-, but I meant everywhere, transparent, use Windows executables *as if* they were normal Linux binaries)

Consider supporting Wine/CrossOver instead. That way everybody benefits. For me I find Wine is getting very noticeably better with every release. http://appdb.winehq.org/appview.php?iVersionId=7440

As a user of both Ubuntu 7.10 and Windows XP, Ubuntu is easier to use and easier to install native software on. I don't have a DVD burner on my Linux box, so I can't comment on how well that works, but Windows XP didn't come with any tools for creating DVD's, I have crappy third-party applications to do that. WoW is listed as "gold" on wine so that should be doable (I'm not a gamer, so I never tried it).

I don't know about your parents, but I would install it on my parent's machine if they ever wanted it. They use their computer for email, web surfing, and office, all of which can be done on Ubuntu. Support would be easy: as long as it was running and connected to the internet I could use VNC or SSH to have as much control over their system as I would sitting right in front of it. I also wouldn't have to run virus scanners or malware tools, no registry hacking, nothing.

Supporting Linux is easier for people who know Linux, than supporting Windows is for people who know Windows.

... grinding that anti-MS axe.

Hey, that's not fair. I stand up for Microsoft now and then. Were those posts not helpful?

The Fine Article is about HP selling consumer desktop PCs with Linux, though. I don't what your post has to do with that but you anonymous cowards aren't getting astroturf points off of me today. Instead I'll provide informative topical discussion and foil your evil plot.

The original source for this story is apcmag. From that article:

Hewlett-Packard, the world's largest PC manufacturer, has announced it will start selling Linux-based PCs from $AU600 in Australia.

I can only hope this is a pilot, with PCs for the US market to follow. Like many of the people leaving comments on that story, I would like to buy some Linux laptops from HP here in the US. I would also like to see a choice of processors. This is a nice start though.

Red Hat Enterprise Linux 5 Desktop also comes with OpenOffice preinstalled, Firefox for web browsing and Evolution for email.

That sounds like a full featured environment for the average user. Much better than Microsoft Works, a non-removable trial copy of Office and the usual collection of junkware that comes with a Windows PC. With compatible software vendors like this impressive list finding commercial software for your HP/Red Hat system should be no trouble. Dag has a whole bunch of free stuff available for it too. I imagine Windows users will have a hard time understanding that yes, you can just click on one of thousands of great free programs and it will install but it won't turn your PC into a spam zombie. It shouldn't take them long to get fond of it though. That's a significant change for people used to dealing with a software vendor that's proud that three quarters of a million of their customers were infested with root kits.

Windows gamers will be relieved to hear that for a measly $5/mo they can join Transgaming and play Windows games. If they have Windows programs they don't want to throw away like one of these, Wine will be a nice free addition to their Red Hat desktop. If they prefer a professionally maintained compatibility engine they might like Codeweavers' Crossover Linux which supports these programs and only costs $40.

The list of hardware known to be compatible with RHEL 5 is impressive, as is the list of systems that are certified and supported.

Disclosure - I also don't work for anybody mentioned here or sell their stuff. My opinions belong to me and I'm not getting paid to have them. YMMV, yadda yadda.

The choice of Red Hat as a partner in this venture shows just how GNU/Linux

... grinding that anti-MS axe.

Hey, that's not fair. I stand up for Microsoft now and then. Were those posts not helpful?

The Fine Article is about HP selling consumer desktop PCs with Linux, though. I don't what your post has to do with that but you anonymous cowards aren't getting astroturf points off of me today. Instead I'll provide informative topical discussion and foil your evil plot.

The original source for this story is apcmag. From that article:

Hewlett-Packard, the world's largest PC manufacturer, has announced it will start selling Linux-based PCs from $AU600 in Australia.

I can only hope this is a pilot, with PCs for the US market to follow. Like many of the people leaving comments on that story, I would like to buy some Linux laptops from HP here in the US. I would also like to see a choice of processors. This is a nice start though.

Red Hat Enterprise Linux 5 Desktop also comes with OpenOffice preinstalled, Firefox for web browsing and Evolution for email.

That sounds like a full featured environment for the average user. Much better than Microsoft Works, a non-removable trial copy of Office and the usual collection of junkware that comes with a Windows PC. With compatible software vendors like this impressive list finding commercial software for your HP/Red Hat system should be no trouble. Dag has a whole bunch of free stuff available for it too. I imagine Windows users will have a hard time understanding that yes, you can just click on one of thousands of great free programs and it will install but it won't turn your PC into a spam zombie. It shouldn't take them long to get fond of it though. That's a significant change for people used to dealing with a software vendor that's proud that three quarters of a million of their customers were infested with root kits.

Windows gamers will be relieved to hear that for a measly $5/mo they can join Transgaming and play Windows games. If they have Windows programs they don't want to throw away like one of these, Wine will be a nice free addition to their Red Hat desktop. If they prefer a professionally maintained compatibility engine they might like Codeweavers' Crossover Linux which supports these programs and only costs $40.

The list of hardware known to be compatible with RHEL 5 is impressive, as is the list of systems that are certified and supported.

Disclosure - I also don't work for anybody mentioned here or sell their stuff. My opinions belong to me and I'm not getting paid to have them. YMMV, yadda yadda.

The choice of Red Hat as a partner in this venture shows just how GNU/Linux

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

It's not about repeating the "party line" (to be honest, I don't think there is one), I'm not really a Wine developer either (although I've had 2 small patches committed), I'm just presenting the situation the way I see it.

Currently I can't say: function x, it gets executed by Acrobat Reader 2.1, Firefox, fuzzycalc and Darly's Printshop. So the person who implements it can test it with these applications that make use of it.

Strictly speaking, you're right, but that data is fairly easily accessable. For example, here's a tiny script that'll give you said information (just feed it a +relay trace), I just wrote it in the span of a few minutes. It could be useful to integrate such data with the AppDB.

I understand that a function does not need to be 100% implemented. But think about a sponsor who says: I want to sponsor dll x. Or: My program WAccounting uses these 5 API calls, I want this program to run perfect under Wine, what does it cost me?

In general, people don't seem to care about how much of a DLL is implemented, they care about if their programs foo, baz and bar work. Most of the major investments into Wine have been to make a particular program (or set of programs) work, such as Google with Picasa (list of patches), or Corel with Wordperfect and CorelDRAW (until Microsoft threw a large chunk of money at them).

In a similar vein, Codeweavers offers porting services for Wine, ie, they'll make a particular application work, and they can give you an estimate of how much it'll cost, on a case by case basis.

What also motivates people is to see a kind of progress bar. I mean a automated script that indicates how much stubs and so on are in there.

I agree that people like progress bars (so do I), but they can be deceptive. For example, the Wine status pages have an automated script that guesses the completion status of all DLLs based on the contents of the .spec file for each DLL, but this isn't always accurate. For example, the .spec files don't seem to contain all functions for a given DLL, (I'd guess any COM functions aren't in there, as they're special, AFAIK), and while the automated tool thinks that d3d8 and d3d9 are 40% and 20% completed, respectively, the actual case is closer to 95% in both cases, based upon developer inspection.

I also would like to get informed how to debug an application with Wine. The documentation is heavily outdated and imcomplete here. WINEDEBUG=+relay is intresting, I tried it out. But the documentation is not very informative here.

Here's the complete list of WINEDEBUG channels, as well as some useful registry keys, and a debugging tutorial. Generally when you're debugging something, WINEDEBUG can be very useful with the right channels selected.

My perception is that we will get
- almost perfect DirectX games support
- very good installer and crypto support.
because here it really does scale but wine development did not scale that much over the past years.

Actually, as I menti

Full DirectX support. Yeah, yeah, I know. The whole Microsoft thing. But it'd be cool to have.

Er, sorry. My quote was from the FAQ on the wiki:
http://wiki.winehq.org/FAQ

Another post mentioned why they most likely will not merge, but Wine performance with DirectX games has improved drastically in the last couple of months - I seem to recall someone saying Wine has surpassed Cedegar in terms of performance, but I can't find a link to back that up.

Here is the last benchmarks that were done - http://wiki.winehq.org/BenchMark-0.9.5

Out of 148 tests:
Wine has the current lead on 67 tests
Wine has a lag between 0.1 and 10.0 percent on 14 tests
Wine has a lag between 10.1 and 20.0 percent on 9 tests
Wine has a lag between 20.1 and 50.0 percent on 19 tests
Wine has a lag of more than 50.1 percent on 21 tests
Wine or XP aborted on 18 tests

Right, but the question for me is how it scales. How much money and time needs to be dumped on it?

How much does it cost to make a DLL that is currently 75% --> 100% ?

what Wine is really missing is a tool that documents all calls by programs, so you say: aha, this stub is needed by these applications, so let's implement it.

Or: this application sents these messages to the function.

control Spy as an interesting test tool
http://bugs.winehq.org/show_bug.cgi?id=239

Speaking of Wine, I don't use it a lot. I have some Windows foreign-language-study programs that run just fine under it. Some Windows games run all right under it; the occasional crash is part of the fun :). The one application I'd like to see working better is Personal Ancestral File, but the Linux alternatives are competitive. I use OpenOffice or Koffice or emacs for office stuff, and write new software in perl or Java or C#, all of which are cross-platform.