Wine Traffic #180 For 25 Jul 2003

This is the 180th release of the weekly Wine Weekly News publication. Its main goal is to circumvent the proofreading process so that small grammatical errors will keep the reader attentive. It also serves inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of Wine as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.com

There were 52 different contributors. 34 posted more than once. 37 posted last week too.

Jon Griffiths took a moment to answer some questions. That was our 10th interview with Wine developers. Previous ones can be found in the news archive.

Here are June's top-ranked technology poll items:

DirectX 8 Support: Direct3D
Improve overall sound support
Improve 3D performance
Windows Installer Support
Support Older Games
Optimize WineX's memory utilization

And some of the top-ranked and top-voted games included:

Battlefield 1942
Grand Theft Auto: Vice City
Elder Scrolls III: Morrowind
Command and Conquer: Generals
DeusEx
Enter the Matrix

Because many of you have requested it, TransGaming is launching a beta testing program this fall for its WineX and Point2Play technologies. This offer is available to TransGamers only. TransGaming's beta testers will be able to look under the hood at the newest features before anyone else; experience the thrill of the chase discovering and reporting bugs; and help develop what could have far-reaching benefits for TransGaming's other users.

Andi Mohr got mentioned on Slashdot for the work he's doing on TI ACX100 wireless drivers for Linux. Andi's name was linked to his WineHQ interview. That interview was from a few months ago and at the time the driver was barely working. From the sounds of it there's been a lot of progress. Maybe he'll wrap that project up and get back to Wine ;)

There was a brief mention of Wine over at Independent.co.uk. Charles Arthur wrote an article about trying out Linux. Several people responded to his evaluation with tips for improving his experience. Among them, several people suggested using Wine to interoperate with Windows apps.

I'd also like to point out that I didn't cover some threads about OLE / COM this week. Mike Hearn seems to be taking a crash course in OLE and there was a fair amount of traffic exchanged between the COM gurus. I didn't understand a lot of it so I just ignored the threads. If you enjoy that sort of masochistic stuff you'll find it all in the wine-devel archives.

It's been a while since we've posted a list of projects you could get involved with. For the most part that's due to the new janitorial and fun projects pages on WineHQ. This week Jonathon Wilson wanted to start working on something and he posted his list asking for feedback:

After looking at all the things windows provides, I have identified the folowing possible programs that I could write for the wine project. Some of them are usefull for WINE itself and some of them might be usefull for (for example) ReactOS

Things:

improve comdlg32.dll, implement stuff added in WINVER>=0x500 like PrintDlgEx and generally make comdlg32.dll behave more like the windows counterpart (implement a few other things as well, like some of the currently stubbed out items).
work on wine notepad. Wont do this until the changes refered to before are merged.
write a clone of fontview.exe (windows font sample viewer). This is probobly not usefull for WINE but might be usefull for ReactOS, plus it would be a good excercise in windows GDI programming.
write clones of guidgen.exe and/or uuidgen.exe, 2 different windows SDK tools for generating GUIDs/UUIDs. (if we are providing an IDL compiler and other such OLE-esque things, having a GUID/UUID generator is probobly a good thing to have, mainly it is just a stub around a call to CoCreateGUID
write a clone of rebase.exe, a win32 PE image rebasing tool. Probobly not usefull to WINE but might be helpfull for ReactOS development, dont know.
writing a clone of the cards.dll used by the windows card games. Only problem here is that I would need to find a sutably licenced set of card images since I dont have the skills to draw them myself :)
writing a clone of the card games (solitare,freecell etc) included with windows to use said cards.dll (hey, we have WineMine...)
writing a character map applet (basically a clone of charmap.exe). Dont know if WINE needs this but ReactOS probobly does (how else are you going to insert all those fancy foreign language characters and dingbats? :)
writing a calculaor app (i.e. a calc.exe clone), again dont know if WINE needs one but ReactOS might...
writing a clone of the Win32 volume control applet. Dont think WINE needs this (since the linux sound API has one already) but ReactOS might...

Which of these should I work on? Which of these are usefull to Wine/ReactOS? Are any of these considered "a big beast" (as richedit was refered to by Dimitrie O. Paun?)

A few people wrote in to discourage working on anything that already exists in the open source community. Jonathon went ahead and started work on #4 and created a program that generated GUID's (see the thread below for details.) From there, Jonathon announced that he would begin work on a cards.dll. I volunteered to do some of the artwork.

Jonathon Wilson wrote a utility to generate GUID's - globally unique identifiers. Microsoft actually ships a utility like this.

Basically, its a console app that will generate GUIDs using CoCreateGUID. All output is to STDOUT. Will return 1 if there is an error, 0 if there is success.

Ouput is in one of 5 formats:

IMPLEMENT_OLECREATE macro definition
DEFINE_GUID macro definition
static const GUID definition
registry format {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
uuidgen.exe output format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

The makefile and stuff were just copied from /programs/expand.

Alexandre looked it over and decided not to add it to Wine, " It looks good, but I'm not convinced we really need that in Wine, there are Unix tools that can generate UUIDs. "

However, Jonathon's effort wasn't wasted. Steven Edwards replied, " I will go ahead and merge this in to the ReactOS rosapps tree. "

Jonathon Wilson asked a question that would be unfamiliar to most Unix developers, " I see that all the wine dlls put the bitmaps in the resource file directly... Whats the best way to do it for a 32 bit wine dll (in this case cards.dll) amd where can I find a program to do it for me?"

Try the tools/bin2res program. It's use is a bit unintuitive, but essentially you need to add some markers (in comments) in the .rc file.

Look for an example in:

./programs/winecfg/winecfg.rc

search for BINRES.

Mike Hearn followed up with, " Out of interest, how do you go about writing GUIs using that stuff? I'm thinking of winecfg here, I can't see any gui definitions in the code, they seem to be loaded from dialog templates. Are there any free editors available?"

Dimi replied, " I don't know about free editors, but most people use the ones that come with MSVC, or Borland, etc. I use vim :)"

Last time I tried running Microsoft Visual Sourcesafe's gui tools under Wine (six months or a year ago), it had Z-ordering and/or visibility problems, and was only partially usable. Now those problems are all gone, and ssexp.exe is from what I can tell quite functional (if bloody slow over smbfs). It still doesn't update the journal with your changes, so the ss admin will think you're sneaking in changes by magic, but progress is progress. Kudos!

Mike Hearn posted a patch that included some version definitions for ole32.dll. Alexandre commented on it, " Version 2.0 is awfully old for ole32.dll. Why do you need that? "

The primary motivation for this bugfix was to enable the DCOM98 installer to work again correctly. It requires at least < 4.something, otherwise it refuses to install. As our OLE framework isn't yet up to scratch for some tasks, being able to install it is important (hopefully once I finish digesting Oves work maybe it will be less important).

I suppose we could make it every so slightly below the version DCOM98 requires, but there are only so many versions, and if an app checks for the version shipped in the DCOM updates, it'd still be too low.

The real fix is just to get the DCOM infrastructure to the point where nobody needs to install Microsofts version anymore, but it's going to be a couple of months before I have this patch in a form suitable for submission I suspect (unless Ove decides to beat me to it).

Alexandre didn't think it was the proper solution for that and suggested, " You may be able to install it by playing with the load order (i.e. set ole32 to native only). Having a bogus version in the builtin is going to force everybody to install the native, which is not what we want. "

grrrr, yes you are quite right, setting ole32=n does force it to install. I wish I'd thought of that :/

So, I attached a patch to add this case to the sample configuration, as it seems non-obvious (and quite a lot of end user queries are related to this).

+; force it to install even though wine has a newer version +[AppDefaults\\dcom98.exe\\DllOverrides] +"ole32" = "native" + +[AppDefaults\\dcom95.exe\\DllOverrides] +"ole32" = "native" +

If you haven't run into a problem with terminal emulation you haven't used Unix or Linux enough. Thankfully, there's now a surplus of real terminals and smashing them with a baseball bat does wonders to relieve frustration. Dan Kegel wrote to wine-devel:

OK, so with the normal X11 driver, you can no longer redirect stdout from commandline apps under Wine; the output just vanishes if you try to send it to a file.

That's rather unacceptable dain bramage, if you ask me.

Bill Medland poked around and reported some test results, " Even with the ttydrv stdout disappears and cannot be redirected. Except it depends upon the terminal!!! Under a real terminal (whatever you want to call it; what I get when I press Ctrl+Alt+F1 and log in) it is OK. I have just discovered that under a true xterm it is OK. However it disappears under whatever virtual terminal KDE gives you. "

Steven Edwards started playing with Wine on an Alpha and began running into obstacles. First he reported:

On just about every file that is built we are getting this warrning. This is the most minor problem we have with the alpha build but I couldnt figure it out.


../../include/wine/debug.h: In function `wine_dbgstr_guid':

../../include/wine/debug.h:152: warning: cast from pointer to integer of different size

../../include/wine/debug.h:152: warning: cast from pointer to integer of different size

This system is a Alpha AXP 21164.

That's an easy one. On an Alpha, sizeof(int) != sizeof(foo *).

gcc is kind enough to warn you about this potentially nasty situation, although in these particular cases I don't see how putting the pointer in something larger will create a problem.

Still, fixing the warning would be a good idea as there's probably a whole lot of lines passing by at compilation.

Todd Vierling clarified that by pointing out, "sizeof(int) == 4; sizeof(void *) == 8."

He also suggested casting to intptr_t or, if not available, defining intptr_t it as an unsigned long. Dmitry Timoshkov pointed out another way to make casts, " In Wine we have to use UINT_PTR, ULONG_PTR, DWORD_PTR for casting pointer to an integer type. These macros have correct behaviour on Win32 and Win64. " He added, " In that case Wine needs to be compiled with _WIN64 macro defined. In that case WPARAM and LPARAM will have correct size as well. But be warned that compiling for Win64 is a completely unexplored terrain. "

Steven wrote back with more details on the system, " Its gcc on RH 7.1 for Alpha. On a Dec PWS 500 workstation. I dont know anything about Alpha asm so I cannot implement the interlocked* functions or the import and spec support in winebuild so I have just stubbed it for now. The other issues I am having is with compiling resources. WRC doesnot work proplerly on Alpha and I dont know why."

And in another email added, " I have this Alpha that HP loaned us for ReactOS but I have never been able to build a current gcc/binutils that build for a alpha-pe target. I figure while I still have it then I will work on getting WINE working. Anyone know AXP assembly interested in helping with the port? I will put it on the net with SSH if anyone wants to play with it. "

As a side note, I used to own 21164 and it was rockin' system. Unfortunately it seems Alpha based systems are slowly meeting their demise.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	19 Jul 2003 - 25 Jul 2003	(4 posts)	News: Interview with Jon Griffiths, TransGaming Beta Program
2.	21 Jul 2003 - 22 Jul 2003	(5 posts)	Project List
3.	22 Jul 2003	(4 posts)	A GUID Generator
4.	23 Jul 2003	(4 posts)	Bitmaps in Resource Files
5.	22 Jul 2003	(5 posts)	Visual Sourcesafe Success
6.	21 Jul 2003 - 23 Jul 2003	(5 posts)	Configuring Native OLE DLL's
7.	22 Jul 2003 - 23 Jul 2003	(3 posts)	Terminal Emulation and stdout
8.	19 Jul 2003 - 20 Jul 2003	(12 posts)	Wine on Alpha Linux

Wine Traffic #180 For 25 Jul 2003

By Brian Vincent