With iTunes support, CrossOver Office users will be able to download and organize songs from the iTunes Music Store. Soon they will also be able to plug their iPod into their Linux PC for music transfers and other jukebox-related tasks.

Part of the problem has been the secrecy surrounding the David development, said Jeremy White, CEO of CodeWeavers in St Paul, Minn. "They're breaking some unwritten rules of the open-source economy," White said. "That's why people are incensed about it."

"When we write a DLL, (dynamic link library) we share it with everyone," White said of his company. "What they're going to do is write a really cool GDI32.DLL and share it with no one."

SpecOps Labs will adhere to Wine's software license, but its ultimate goal is to create a completely proprietary product, the company says.

Ah, FINALLY, after so many USB user requests, someone actually wants to get something done :)

You need to figure out how Windows implements USB support (I don't have the slightest clue either, sorry). Try searching on http://search.microsoft.com to figure out if you should implement a VxD or .sys driver DLL in Wine or so. I'm quite sure it should be possible somehow, without any operating system ring 0 issues or so (after all you're writing your own Wine driver, so it should be fairly doable). On the Linux side, of course you should interface to the USB stack (fairly obvious anyway ;). One plea: please don't implement that for oldish 2.4.x USB stack, start with the new 2.6.x USB stack (adding support for the older 2.4.x stack later is pretty easy anyway IMHO). It might be that you actually need to implement your own Wine-USB Linux driver (for interfacing to the non-privileged Wine application side, via ioctls or so).

Good luck, and keep asking if you run into problems!

please talk to Aric first, I think he may have some basic code already. Certainly he was looking into USB support last week.

He's gone to LinuxWorld right now I think so you may have to wait a few days. Researching what needs to be done would be a great way to get started even if Aric has written some code, it's unlikely he'll get time to finish it off properly soon so your help would certainly be appreciated!

It seems quite a few people have been seeing this message lately, and I'm not sure why. This occurs even with a non-existant ~/.wine directory, so wineprefixcreate should set up a correct system for them.

Examples:

• http://www.linuxquestions.org/questions/showthread.php?s=&threadid=204255&highlight=wine
• http://forums.devshed.com/archive/t-166324

This one seems to imply that the symlinks aren't being created properly:

http://www.winehq.org/hypermail/wine-users/2004/07/0022.html

but that sounds like a migration issue rather than something you'd see with a clean .wine

If anybody has any ideas I'd love to track this one down. I am wondering if it's to do with packaging, I have never been able to reproduce this with Wine CVS builds (ie from source) but I know some packagers are still shipping custom ~/.wine building scripts.

I used to get this message when I first started using wine. It came when I tried to use the windows partition AND when I had installed wine from a package.

I have not recreated it since I have learned to use a "fake" windows, but I suspect that this was a symptom of either a packaging error or the bug that got corrected (Bug 2356) in the latest snapshot.

You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff.

Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be.

Other things are:

• Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of ''
• Browse in the "Add/Edit drive" dialog is a WRITEME
• Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates.
• "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file! Ditto for Libraries tab.
• The Add/Remove application buttons are *way* too big!
• Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab.
• Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin"
• We ask the user to understand a magic * symbol to set the default - what is up with that?
• There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override.
• We have way too many (eg, more than zero) tree controls in this app.
• Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to.

Basically I'd recommend reading the GNOME HIG: http://developer.gnome.org/projects/gup/hig/

It's a very informative read. Obviously we have to use Win32 UI conventions at least at first, but there's a lot of generically good advice there. Well worth reading for anybody who is going to work on winecfg.

You can also find this application on the CD of the book Debugging Applications by John Robbins (from the "MSDN Bugslayer" column).

See also http://www.wintellect.com/about/instructors/robbins/code.aspx for his available code.