World Wine News

"As the most popular third-party translation technology in use, Wine was the first emulator to be specifically tested for via WGA," said the spokesperson. "Microsoft does not knowingly provide copyrighted Microsoft Windows OS files to users of third-party emulators or cross-platform API translation technologies such as Wine."

The spokesperson said users who are not running Windows XP or Windows 2000 natively can still download updates for Microsoft Office from the Office Update Web site.

The goal of the project was to create a fully functional lab for about $200 a computer which had to factor in the cost of a server, software and a GB switch. A Windows based lab with XP was priced at $1748.30 per computer (includes server, software and switch) while the actual Linux solution cost only $216.30 per workstation. The cost savings was substantial and allowed the district to view the project as a long term solution based on price.

This is an attempt at starting a RichEdit 2.0 clone, plus a test app for it (which I, for some reason, decided to call Wine WordPad).

It lacks most essential functionality, and source formatting is not exactly standard, but it has enough functionality to make a couple of Wine developers convince me to release it now. Or weeks ago.

The test app uses the Mike McCormack's test snippet to fill the control with some fancy formatted text.

Hope the patch is OK. Adding new DLLs and EXEs isn't an easy process.

Cool. Looks like you've done a lot of good work.

I like that you've used lots of small functions, rather than monolithic 200 line globs. I like the asserts too.

OK, now some suggestions:

• submitting riched20 and the new wordpad program separately would be a good idea. The bigger the patch, the longer it tends to hang round before it's committed.
• instead of #ifndef __WINESRC__ ... printf ... #endif, how about using wine's debug macros TRACE, ERR, etc? Then you can just #define TRACE to printf when __WINESRC__ isn't defined
• instead of XXXFK how about FIXME?
• you probably should get rid of the _int3 macro in wrap.c, and replace it with DebugBreak()
• ME_DumpParaStyle isn't used... maybe change it to use MESSAGE() rather than a message box. You can dump stuff by checking the condition WINE_TRACE_ON(richedit). You'll need to declare a WINE_DEFAULT_DEBUG_CHANNEL for that..
• maybe you want to add LGPL licenses on your header files?
• keep the formatting in your Makefile.in the same as the other dlls. Julliard's a bit fussy about that, so he's probably going to change it anyway. Might as well save him the time.

Wine's fundamental architecture

The DOS drive devices stick out as a huge change, that was about 8 months ago. Here is Eric's first mail on the subject.
http://www.winehq.org/hypermail/wine-devel/2004/01/0220.html

Window management

AJ has done a huge amount of work here :-)

 

DLL separation

Eric and AJ keep chugging along at this..

 

Unicode support

There has been hundreds of patches to convert to unicode support.

 

Wine Conformance Test Suite

Francois tells me the infrastructure for the conformance tests is now finished.

 

Wine IDL compiler (widl)

Huw is on patch #38
http://www.winehq.org/hypermail/wine-patches/2005/02/0149.html

Steven Edwards sent a patch to sync with ReactOS, the work was done by Eric Kohl.
http://www.winehq.org/hypermail/wine-patches/2005/02/0496.html

Dlls Status

advapi32.dll & rsaenh.dll

http://www.winehq.org/hypermail/wine-devel/2005/02/0552.html

 

dbghelp.dll

Eric has sent a lot of dbghelp fixes

 

itss.dll

This little dll goes a long way toward getting html help working in apps.
http://www.winehq.org/hypermail/wine-patches/2004/08/0435.html

 

mscms.dll

The color management DLL is about 25% complete now. The fun projects status needs to be updated.
http://www.winehq.org/fun_projects

 

msi.dll

Mike and Aric have done a lot of work here...

 

oleaut32.dll

ole32.dll

rpcrt4.dll

As of today Robert & Mike are on patch #76 of ole work. In the end this will help installshield work better and get us away from the MS dcom9x.exe dependency.

 

stdole32.tlb

Huw implemented stdole32.tlb :-) one huge step toward not needing any part of dcom9x.exe....

DirectX Status

d3d9.dll

Here is Jason's last d3d9 patch, #22, he is waiting on Oliver to sync his changes and then he can move forward.
http://www.winehq.org/hypermail/wine-patches/2005/01/0484.html

 

wined3d.dll

Was part of the d3d9 work from Jason. Raphael has done a lot of work here as well:
http://www.winehq.org/hypermail/wine-patches/2005/01/0508.html

 

DirectMusic (as a group)

Raphael & Christian have sent a couple nice patches in the last couple of months to bump the status on a couple of DirectMusic dlls

 

dsound.dll

What can I say; Robert Reif has sent hundreds of DirectSound patches alone! Jeremy White is trying to track down the mmtimer bug and has sent some patches as well.

 

quartz.dll

Christian has sent over 30 quartz.dll patches in the past six months.

Multimedia Status

Eric has done a lot of unicode work on the multimedia codecs

http://www.winehq.org/hypermail/wine-patches/2005/02/0092.html

Here is the big patch:
http://www.winehq.org/hypermail/wine-patches/2004/12/0052.html

 

opengl32.dll

I sent the patch to sync to latest OpenGL specifications.
http://www.winehq.org/hypermail/wine-patches/2005/02/0214.html

 

Raphael, sent his patch to implement partial PBuffer support for wgl and minimal pixel format support for wgl
http://www.winehq.org/hypermail/wine-patches/2005/02/0535.html

I have Visual C++ 6.0 running under CrossOver Office 4.1, which of course means it's running under Wine. For one of the examples in the Wine/Winelib book, I decided to take the code produced by the VC++ Win32 "Hello World" wizard and see how to port it to Wine.

Turns out, it's almost trivial. Create an empty directory, copy the *.c, *.rc, *.h, and *.ico files to it. VC++ produces tons of other files, but they're either used to maintain the Visual Studio environment, or are intermediate compilation files that aren't needed. Then run:

$ winemaker .

The Makefile that Winemaker generates _almost_ works. You need to delete the references to the mfc library and mfc.dll. After doing that, running make generates the .so file. Wine runs it flawlessly.

I got to thinking - can I convert the code from the MFC application as easily? Seems like it's doable, because the generated code runs in VC++/CrossOver Office 4.1. I tried the same steps as before, with Winemaker, but I couldn't figure out what Makefile modifications were needed.

All of this got me to thinking - could Wine running Visual C++ be a viable IDE for porting? Maybe just linking VC++ with the Winelib libraries would do it. Maybe after tweaking Winemaker and publishing a HOWTO we could show that this is a viable path? It's certainly easier than for Visual Studio developers and could help attract them to Wine.

Another benefit - we could use the Visual C++ sample programs as tests for Wine. The programs might exercise areas that haven't been tested thoroughly.

There are 2 easier ways that I know of to do this.

1. Use dev-c++ from www.bloodshed.net/devcpp.html . It will Just open your DSP file and make a very good, very simple MinGW makefile for you. It will add all your -D and -I and all this nightmare in big projects. Both the result makefile and dev-c++ itself can be used with wine. It has a native Linux port has well. One thing to try is debugging. It uses gdb for windows. Does gdb for windows runs under wine??
2. Grab the DSW2MAKE util from MinGW. Written in Perl. The output makefile is very good for Winelib. Also keeps your -D(s), -I(s), and -l(s) and tries to convert other switchs as well. Better for very big projects.

Aleksandr Liber and I have put together a set of tests for cabinet.dll. Before we submit them to wine-patches, can anyone offer any critiques/input? We plan to submit in a day or two.

We're 4th+ year undergraduate students at the UCLA Computer Science program. We're among a group of students doing conformance tests as part of a software engineering course - more info can be found at

http://www.geekymedia.com/wine

Any advice you can offer will be greatly appreciated!

Wine cabinet.dll FDI Conformace Test Patch (gzipped)

Raw files available at :

http://www.geekymedia.com/viewcvs/cgi/viewcvs.cgi/group3/wine/

This patch adds tests for the cabinet dll, specifically testing the functions FDICreate, FDIDestroy, FDICopy and FDIIsCabinet. As the FCI functions are still marked TODO in wine, they haven't been tested.

The package is self containing, allowing additional cabinet features to be tested by preparing other cabinets in the same manner that ours were. A patch of -p1 will be needed.

Changelog:

• configure.ac
  added dlls/cabinet/tests/Makefile to be generated
• dlls/cabinet/Makefile.in
  added subdirectory reference
• dlls/cabinet/tests/Makefile.in
  standard Makefile.in for tests
• dlls/cabinet/tests/cabinet_fdi.c
  actual test code for FDICreate, FDIDestroy, FDIIsCabinet, FDICopy
• dlls/cabinet/tests/data.h
  contains hex representations of the two test cabinets
• dlls/cabinet/tests/tvfs.h
• dlls/cabinet/tests/tvfs.c
  Trivial Virtual File System emulating _read, _write, _open, _lseek and _close
• dlls/cabinet/tests/genfiles.sh
  Cabinet/data.h creation script used for simple.cab and complex.cab- current tests
• tools/chexify.pl
  converts input files to C style arrays

Here's some screenshots from the program while running:

http://www.grack.com/news/Picasa2underWine.html

Note that clicking the "email" button in Picasa will crash it - probably the MAPI stubs that cause it:

err:mapi:MAPILogon Stub
fixme:seh:EXC_RtlRaiseException call (from 0x53e297) to unimplemented
function mapi32.dll.MAPISendMail

Good news and what looks like a first.

Dragon Naturally Speaking 4 working under Wine.

• reqd riched32 and comdlg32 native from 98SE
• Gentoo Linux , 2.6.10-nitro4 kernel
• wine-20050111
• Fresh Wine installation
• installed IE6 using sidenet

1. Install Dragon from CD no major issues.
2. copy missing dlls
3. ran up Dragon , enter user name , setup sticks at setting mike level but exits cleanly.
4. #wine gentrain.exe picks up user name, dictated training text. It saves the vocab/voix profiles then drops out with 3 repeat errors but the profile is safe
5. #wine natspeak.exe

Can now dictate in stand-alone mode as in windoze.

I now need some help with the guts of Wine to see if I can capture the keystrokes output by Dragon and pipe it to another Linux thread.

Any suggestions on that?

World of Warcraft is working beautifully now apart from a crash that occurs seemingly randomly. The application is catching the crash, and giving a message like this:

This application has encountered a critical error:

ERROR #132 (0x85100084)
Program: C:\Program Files\World of Warcraft\WoW.exe
Exception: 0xC0000005 (ACCESS_VIOLATION) at 0023:557102CD

EAX=00000000 EBX=55BDFCA8 ECX=00000000 EDX=55BDFBB8 ESI=5E320308
EDI=00000000 EBP=55BDFC08 ESP=55BDFB9C EIP=557102CD FLG=00010212
CS =0023 DS =002B ES =002B SS =002B FS =005B GS=0063

Whilst playing around trying to get some kind of lead, the sound cut out on me whilst playing the game. I decided to keep going, and the game played for a surprisingly long time. The next day I booted the game with wine's sound drivers disabled and played for about 10 hours total without a crash (for purely stress-test reasons you understand ;)). I've had a chance to give it a go with the wineoss.drv.so now and that also seems stable, so I guess the problem is in winealsa.drv.so which I had been using.

I haven't had a chance to try to get some debug logs just for the sound yet, but when I get the time I will.

Sound depends a lot on the sound card. Some sound cards support only specific sampling rates while others are more accommodating. And that's just one issue, at least on the wineoss side there are a lot of other issues such as mmap support, full duplex support and DSP_GETOSPACE support that vary from one sound card to the next (and to some extent from one Alsa configuration / OSS emulation version to the next) and which all cause trouble.

<rant>

And Wine is way too sensible to these issues, even more so if the application uses DirectSound. Part of this is because the Windows API is painful to emulate, but part of it is lack of debugging of basic sound. Unfortunately, debugging supposes one has a sound configuration that does not work which makes it even trickier.

What this means is that each Wine developer who has sound problems can essentially only count on himself to debug them. To do so I would recommend first checking that winmm works fine:

cd dlls/winmm/tests make test

and if the above works, do:

WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c

And if the winmm tests worked fine, then do the DirectSound tests:

cd dlls/dsound/tests make test

already you may have to manually edit the Wine configuration file to set HardwareAcceleration = Emulation. That's an heresy, it should be automatic. Anyway once you get the above test going, do:

WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c

I know for a fact that many Wine users are having problems with basic not-low-latency stereo sound and unfortunately I have not seen any progress on this in the past couple of years (i.e. there are still about has many users having problems now as two years ago).

</rant>