World Wine News

This is release 0.9 of Wine, a free implementation of Windows on Unix. After 12 years of development, this release marks the beginning of the beta testing phase. Everybody is encouraged to try it; while there are still bugs, most applications are expected to at least install and do something useful.

Because of lags created by using mirrors, this message may reach you before the release is available at the ftp sites. The sources will be available from the following locations:

http://ibiblio.org/pub/linux/system/emulators/wine/wine-0.9.tar.bz2
http://prdownloads.sourceforge.net/wine/wine-0.9.tar.bz2

Binary packages for various distributions will be available from:

http://www.winehq.org/download

You will find documentation on http://www.winehq.org/documentation.

You can also get the current source directly from the CVS tree. Check http://www.winehq.org/cvs for details.

Patches should be submitted to "[email protected] ". Please don't forget to include a ChangeLog entry. If you submitted a patch, please check to make sure it has been included in the new release.

Wine is available thanks to the work of many people. See the file AUTHORS in the distribution for the complete list.

we still have a lot of work to do on usability issues (winecfg, desktop mode, cdrom support, systray, etc.), and we need better support for the various code obfuscation tools, it's probably the number one cause of apps not even starting today.

just getting into a fresh installation with 0.9

ran up winecfg and tried to add a device for my dvd burner.

editing the device name is unusable. No cursor, then after a first character is entered the edit seems to jump to insert mode and puts the cursor at the beginning of the line. There seems to be no way enter text normally to enter a device name.

This whole interface seems badly broken. I had to fall back to good old command line to sort out the mess made by winecfg and add the devices I need.

I noticed this as well last night when I was testing some Windows programs for compatibility. I'm glad Wino mentioned it here, because I almost forgot.

I went into the dosdevices directory and set up the links manually, because it's real hard to get non-fubar'd results with winecfg.

It was then discussed that bugs that are FIXED and where resolution is not LATER or DUPLICATE or REMIND should be marked CLOSED as the fixes have been integrated in an official release (namely 0.9).

However it seems that ivanleo didn't like my CLOSING session because some of the bugs were not "fixed". Can someone tell me how a bug can be not fixed and marked as resolved-fixed (see my query) ?

First, it is the responsibility of the reporter to verify the bug. It is totally unrealistic to think that others will go do the verification -- they lack the software, the context, and the motivation/

Second, we had close to a thousand bugs in that state. They do more harm than good lingering about. If the original reporter cannot be bothered to verify it, they should be closed.

I have posted my local patches to wine-patches.

Note that for 0.9 I have posted most of the patches that are likely to be essential to build a working Wine package (other than those previously rejected) regardless of the shape the code is in. Some of it is very ugly and lacks integration for other OSen, I have noted these. Since this code is maintained as a delta from CVS wine specific to Solaris and only used for binary packages, it's not necessary to start out with the niceties all there (This particularly happens when I get deep into week long debugging sessions).

Patches not sent are listed hereunder along with the reasons...

Possibly essential (Show stoppers)

ptrace stub patch

Disable debugger by returning error for all ptrace calls, add ptrace stubs (framework) to allow work on ptrace emulation layer for wine. -Previously rejected

linking patch

since libwinecrt0.a was added wine has been broken due to the linker wanting to import main() in dlls, this results in unresolved symbols. I have temporarily worked around this and can build wine with a change to winegcc that links another archive (I call winedllcrt0.a) which omits the main() definitions in the case where -shared is passed to winegcc. Alexandre has asked that I keep looking for a way to make the Solaris linker successfully link an archive containing main() to dlls without the need to have two runtime startoff libraries. Patch won't be submitted until a final solution is found.

Recommended functionality patches

cpuid patch

CPUID detection using x86 cpuid instruction - previously rejected

wineconsole/curses.c

Patch non-essential and FAR too hacky at this point - just removes all mouse code.

Other Patches

tools

automation patches to allow unattended build No interest to Wine project

Debugger

work in progress, not working

A complete set of patches (even the gross ones) are maintained at

http://www.blastwave.org/wine

OK, I think I've cracked it.

After a lot of heaving and grunting I managed to reinstall Dragon Naturally Speaking into a fresh user account with the help of sidenet.

This time I carefully documented the steps I took so as to be sure it was reproducible.

What worked:

wine-20050524; sidenet-1.8.1; Dragon NS v7 preferred En. and v7 pref Fr Ensoniq 1371 pci "soundblaster"

What won't:

winecfg based wine releases ; more recent sidenet on previous above wine. muse5.1 cmipci (too quiet)

Required natives:

comdlg32.dll only

That it in a nutshell , here's the log:

INSTALLATION NOTES FOR NATURALLY SPEAKING 7 PREFERRED

1. installed wine is 20050524
2. new user account with no wine
   • su <username>
   • cd ~
3. untar sidenet 1.8.1
   • chown <username> users
   • ## cp some prev download files from other user space , save time on sidenet.
   • cd wine-config-sidenet
   • ./setup
   • #sidenet : option [3] select y to IE6 MSinst DCOM98 fonts
   • sidenet runs OK, reboots, displays sid-site in ie6: success!
4. bash# ~/.wine $ wcmd
   • D:\.wine>ver
     WCMD Version 0.17
   • D:\.wine>path
     PATH=c:\windows;c:\windows\system;c:\windows\command
   • D:\.wine>exit
5. cd ~/.wine/dosdevices
6. ln -s /mnt/dvd h:
7. wine h:setup
8. installshield says req reboot, ok restarts
9. into reg code entry dlg OK.
10. #file select dlg crashes, rerun and accept default folders.
11. installation runs cleanly and exits, then throws following to console:
    bash # ~/.wine/dosdevices $ fixme:ddeml:DdeConnectList
(1,0xc000,0xc000,(nil),(nil)): stub
fixme:ddeml:DdeQueryNextServer (0x1,(nil)): stub
fixme:ddeml:DdeQueryNextServer (0x1,(nil)): stub
fixme:ddeml:DdeDisconnectList (0x1): stub
err:wineboot:runCmd Failed to run command (0)
err:wineboot:ProcessRunKeys Error running cmd #1 (0)
    #ignorable.
12. ~/.wine/c/Program Files/ScanSoft/NaturallySpeaking/Program $ wine natspeak.exe
"cannot find windows/system/comdlg32"
    OK exits cleanly.
13. find comdlg32.dll and put in system.
14. $ wine natspeak
    enter user general training.
15. NS cannot control the volume level although it thinks it does.
    use alsamixer or similar to ensure capture is on MIK and capture level around 80% (YMMV)
    84 vol gives 22 quality rating but message says too high, basic training sticky.
    req reduce vol to 82: fine

Able to complete general training and begin dictation into DragonPad. Excellent results.

HTH, Have fun

I rencently read a whole lot of MSDN documentation about the LDDM infrastructure. The new Windows graphics vista driver model.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/ DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f06eb8.xml.asp

And what made me think we could have support for it in linux.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Display_d/hh/Display_d/ DisplayDriverModel_Guide_c96d975e-dcc9-49b5-be73-b4d8b9f06eb8.xml.asp

It seem to me that having the most important parts of the driver being in user mode would really help to use it on other systems.

From what I read, the user mode driver would create the command buffer that would need to be uploaded to the GPU and a kernel module would need to schedule GPU access handle memory of the GPU and send the command buffer to it.

This would need the Wine Expertise of DirectX reimplementation as well as some good kernel hacker, but in the end maybe the struggle to have linux specific support from Graphics adapter vendors could be once and for all removed if we had LDDM driver support and then X build on top of it (same philosophy as Xgl).

it could also benefit to the wine project itself as we would have really windows driver being used, it should help increase compatibility.

sorry if it sounds crazy...

The display driver model architecture for Microsoft Windows codename "Longhorn" is composed of user-mode and kernel-mode parts. The following figure shows the architecture required to support the Windows Longhorn display driver model. A graphics hardware vendor must supply the user-mode display driver and the display miniport driver. The user-mode display driver is a dynamic-link library (DLL) that is loaded by the Microsoft Direct3D runtime. The display miniport driver communicates with the Microsoft DirectX graphics kernel subsystem. For more information about the user-mode display driver and display miniport driver, see the Windows Codename Longhorn Display Driver Model Reference.