Wine Traffic #200 For 12 Dec 2003

By Brian Vincent

Table Of Contents

Introduction

This is the 200th issue of the Wine Weekly News publication. Its main goal is to be scared of #300. It also serves to 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 it 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 (http://www.winehq.com)

Mailing List Stats For This Week

We looked at 155 posts in 481K.

There were 43 different contributors. 28 posted more than once. 24 posted last week too.

The top posters of the week were:

1. News: Issue #200

6 Dec 2003 - 12 Dec 2003 (1 post) Archive Link: "News"

Topics: News

People: George CarlinNews

Wow.. 200 issues of this little rag have come out. Going through the archives I see that the first issue came out in June of 1999. Guess that means we've got four and a half years behind us. Time flies. George Carlin explained it pretty well:

Do you realize that the only time in our lives when we like to get old is when we're kids? If you're less than 10 years old, you're so excited about aging that you think in fractions." How old are you?" "I'm four and a half!" You're never thirty-six and a half. You're four and a half, going on five!

That's the key.

You get into your teens, now they can't hold you back. You jump to the next number, or even a few ahead.

"How old are you?" "I'm gonna be 16!" You could be 13, but hey, you're gonna be 16!

And then the greatest day of your life... you become 21.

Even the words sound like a ceremony... YOU BECOME 21... YESSSS!!!

But then you turn 30. Oooohh, what happened there? Makes you sound like bad milk. He TURNED; we had to throw him out. There's no fun now, you're just a sour-dumpling. What's wrong? What's changed?

You BECOME 21, you TURN 30, then you're PUSHING 40.

Whoa! Put on the brakes, it's all slipping away. Before you know it, you REACH 50... and your dreams are gone.

But wait!!! You MAKE it to 60. You didn't think you would!

So you BECOME 21, TURN 30, PUSH 40, REACH 50 and MAKE it to 60.

You've built up so much speed that you HIT 70! After that it's a day-by-day thing; you HIT Wednesday!

You get into your 80s and every day is a complete cycle; you HIT lunch; you TURN 4:30; you REACH bedtime.

And it doesn't end there. Into the 90s, you start going backwards; "I was JUST 92."

Then a strange thing happens. If you make it over 100, you become a little kid again. "I'm 100 and a half!"

May you all make it to a healthy 100 and a half!!

Ironically, this was a rather slow news week for Wine. Grab a cup of coffee and read on..

2. C++: Where's the Love?

9 Dec 2003 - 10 Dec 2003 (12 posts) Archive Link: "I made a wish, wrote a letter to Santa..."

Topics: Project Management

People: Subhobroto SinhaAlexandre JulliardOve KaavenMicrosoftOve Kåven

Time to start putting together a list of everything you want for Christmas. Subhobroto Sinha put his together:

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo.

But that could be solved using yet another language called C++ - if only Santa would let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ?

Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can at least run under WINE ?

DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it !

As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy.

Most of the time we are passing around multilevel pointers when a simple reference would have done:

For example a call like

can be made to a simple

using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR &pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..)

We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" !

Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails to deliver just remove it after a stipulated period !

If WINE stuck to C only because some platforms do not support C++, then will Win32 apps run on such OS at all ? Things like SPARC do not need MS Apps at all (though SPARC has C++..)

For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html Microsoft themselves use C++ :

Subhobroto certainly isn't the first to ask for this; the topic tends to come up about once a year. In fact, looking back in the archives I see it appeared in issue #153 (http://www.winehq.com/?issue=153#No%20C++%20in%20Wine) . At the time Alexandre certainly wasn't against the idea, he just didn't know a compelling reason to allow it. Surprise.. his view hasn't changed as evidenced by his reply:

You don't need Santa's permission for that, just go ahead and implement DCOM in C++ and show us how easy it is. I suspect you will quickly realize that the complexity of the problem does not come from having to explicitly pass the this pointer around...

Ove Kåven backed that up with his experiences:

Consider that the reason could be that C++ has too many interoperability problems to solve any within an interoperability project like Wine. Just try to compile something like MFC with g++ and see how well the result would run MSVC++-compiled programs.

Okay, perhaps I should say right away that it won't run, because g++ won't generate VC++-compatible code. In any case, I don't see why MFC should be part of Wine, it's not a core Windows component. There's nothing wrong with having a separate FreeMFC project outside Wine using C++ (and compiling their FreeMFC libs with MSVC++ for the benefit of Wine users)

As for COM/DCOM, having implemented big parts of it myself, I'm not so sure C++ would have helped a whole lot in any case. It's a mess and the only thing you'd achieve with C++ is a different style of mess (a more unreadable one, for starters).

3. Using Native DLL's in a Winelib App

9 Dec 2003 - 10 Dec 2003 (6 posts) Archive Link: "Using a windows dll from a winelib or possibly native linux app."

Topics: Winelib

People: Arthur BergmanKevin CousinsAlexandre JulliardBoaz Harrosh

Arthur Bergman ran into some stumbling blocks trying to create a Winelib app, " I have been trying to develop an application using a vendor provided dll from an external vendor to work under linux. If we develop the app on a windows box and move it over to the wine environment it works, but it would be preferable to have a more native approach. So I tried using winelib and have progressed to a point where I have an application that compiles using the vendor supplied header files under gcc, and a vendor.dll.spec file that describes the DLL. However when I compile everything, the generated vendor.dll.so file does contain the correct symbols but they are undefined. Having played around using winemaker and winedump while trying to read up everything on winelib I am now stuck and not sure how to proceed forward. "

Kevin Cousins offered the first bit of help:

Well done. It took me a significant amount of effort just to get that far in a similar project!

I found a piece of WineLib documentation (sorry: I don't have an appropriate cross-reference handy) that advocates that you write a shim layer between your Linux code and your vendor's DLL.

Basically, regardless of how clever WineLib really is, you still can't statically link an ELF object file against a PE COFF DLL. That's the reason you see undefined symbols---they really are undefined! You can, however, achieve what you want through another layer of indirection! :) Basically, you have to define simple statically-linked definitions for those symbols which merely call through to the dynamically linked versions contained in your vendor's DLL. It works like this:

Compile and link against /that/ (or similar specialised for your particular situation), and you're undefined symbols will now have a definition, and your code should work as advertised. At the very least, all this worked for me!

Alexandre wrote back with a different (and easier) approach, " You shouldn't compile to a .dll.so since you don't have the dll code. What you should do is generate a libvendor.def from the spec file (with winebuild --def) and then link your app as a winelib app, adding -lvendor to the import list. winebuild will then resolve the symbols properly to point to the native dll."

Boaz Harrosh described this approach:

See if I understand what you need:

Check that you have done the following

  1. wrote a vendor.dll.spec (spec syntax for all functions used from "vendor" headers)
  2. compiled a libvendor.def file from above .spec file using winebuild (put libvendor.def in a directory specified by -L)
      <Makefile>
      # libvendor.def generation
      libvendor.def: vendor.dll.spec
      $(LDPATH) $(WINEBUILD) -fPIC -o $@ --def vendor.dll.spec \
      $(vendor_dll_DLL_PATH) $(WINE_DLL_PATH) $(GLOBAL_DLL_PATH) \
      $(vendor_dll_DLLS:%=-l%) $(GLOBAL_DLLS:%=-l%)
      </Makefile>
  3. make a myapp.exe.spec.c using winebuild including "vendor" to the list of needed dlls like kernel32 and advapi32 ... (this was done for you by winemaker Just add vendor at the end of the dlls list)
  4. link myapp.exe.so with myapp.exe.spec.o (also done by winemaker)
  5. Have vendor.dll available in runtime

4. RPC Info

8 Dec 2003 - 9 Dec 2003 (6 posts) Archive Link: "rpcrt4 and rpcss with WINE and ReactOS"

Topics: RPC / COM / OLE

People: Steven EdwardsCasper HornstrupGreg TurnerReactOS

Steven Edwards knew exactly what to expect when he started the following thread:

Ok I know this going to start YALD (Yet Another Long Discussion) that wont go anywhere right away but......

ReactOS is getting ready to do a major import of the WINE dlls as you guys know due to my repeated cross-postings to Wine-devel and ros-kernel. When we compile rpcrt and ole32 from WINE with some hacks we can make it work under ReactOS but I would like to develop a implementation that works properly without dirty hacking. I dont know much about WINEs rpcss other than whats in the comments of the code and for that matter I dont know much about Windows rpcss. Can we share these components? How are we going to break compatibility by doing this?

Casper Hornstrup followed up behind that, " ReactOS can use the relatively fast LPC facility for cross-process communication in rpcrt4. I'm not sure if WINE implements this, but if both WINE and ReactOS implements it in the same way, then I see no reason not to share implementations of this component."

Greg Turner has done a lot of Wine's RPC backend and explained some of the mechanisms:

Wine doesn't have LPC per se. If ReactOS does, I'd love to see their implementation and talk to you all about stealing it :)

Rpcss (in wine) is really a nasty kludge at this time. It only performs a single function: mapping of endpoints. Eventually, this is where the Running Object Table, the OXID Resolver, and maybe some other things should go. Furthermore, the endpoint mapping is done in completely the wrong way: it uses an arbitrary protocol over named pipes. It is supposed to be using RPC according to a standard interface (maybe there are two standards, though, the MS ORPC one and the ONC RPC one, which are supposed to coexist). That's not particularly important, however, until the wire protocol is fixed.

At the RPC API level, wine appears to support lpc -- but in fact it's using named pipes. The actual LPC API's (NT "Ports") are just do-nothing stubs. Implementing them might be easy; implementing them /well/ would probably require shared memory and be kinda scary. I have designs to do this myself (starting with the poor, easy implementation), but lately I'm not finding the time I want to dedicate to wine development.

Uhh... so in answer to your question, rpcrt4 and rpcss are designed to work together, and shouldn't have too many ugly dependencies (except that rpcrt4 has some ole32 deps for its ndr implementation). For the most part, they only use high-level Windows-y stuff found in kernel32; there may be a few unixisms/wineisms, of course, but compared to other dlls these should be trivial.

My advice: just run the code and see what happens. So long as ROS has working named-pipes, and a few other kernel essentials like critical sections, string atoms, etc, it ought to "just work", deficiencies and all. Just test with "/Oi/index.html" midl-generated code, and stick to the supported transports (lpc, ironically, or named pipes), or you will get no love. AFAIK, the only snag you may encounter is if your ole diverges from that of wine.. if that happens, just break the ndr types which require ole32 until you get your ole32 up to speed. Furthermore, you only need rpcss for dynamic endpoints!!! Fixed endpoints will work fine without rpcss. In real-world situations, due to the deficiencies of wine's RPC, there is almost never any reason to invoke rpcss, and it rarely runs.

Sorry to fulfill the prophecy about "YALD (Yet Another Long Discussion) that wont go anywhere right away but......",

Steven then gave a pointer to ReactOS' LPC: http://cvs.reactos.com/cvsweb.cgi/reactos/ntoskrnl/lpc/ (http://cvs.reactos.com/cvsweb.cgi/reactos/ntoskrnl/lpc/)

5. Updated ALSA Support

7 Dec 2003 - 10 Dec 2003 (10 posts) Archive Link: "Status of winealsa patch"

Topics: Multimedia

People: Sylvain PetreolleAlexandre JulliardChristian Costa

For a while it seemed ALSA was trying to make a run at Wine to become the oldest open source project without a 1.0 release. It seems they've failed miserably and are now on their second release candidate. Sylvain Petreolle decided to submit a patch to update Wine's ALSA interface but wondered why it wasn't applied:

My winalsa patch for alsa 1.0 support wasnt commited and there wasnt any feedback fo it. Another winealsa patch was commited after that, should I resubmit mine ?

References:

The other patch in question was from Alexandre:

He explained the reasoning behind it, " My understanding of the ALSA_PCM_OLD defines is that this shouldn't be the case, the current code should work fine on 1.0. Do you still have problems with it? "

Sylvain thought there was more to it, " The current code works with today alsa cvs if I use the ALSA_PCM_OLD* defines, no problem at all. The goal of my patch is to make us use the new API. When the 1.0 state will be reached, the 0.9 API will be considered deprecated (like the already deprecated 0.5 series) "

Alexandre felt that it might not be appropriate, " Well, I'm not sure that's really necessary at this point. The 0.9 code builds just fine, and IMO we can simply wait until supporting 0.9 is no longer required and then switch to the 1.0 version, instead of having to maintain both with #ifdefs. "

Sylvain wondered if support for 0.9 could be dropped. A couple people were against that because nearly every ALSA installation is based on it right now.

Mostly unrelated to this, Christian Costa submitted a patch adding WaveIn support to the ALSA driver and noted, " I've succesfully done record and playback at the same time. "

6. DirectX Status Page

9 Dec 2003 (1 post) Archive Link: "DirectX Status Section"

Topics: Status Updates

People: Tom Wickline

Tom Wickline maintains a nice list on WineHQ of the status of various components. He put together a page for DirectX and asked for comments. Unfortunately the colorful HTML won't display properly if I try to include it here, so instead I'll just refer you to Tom's original post (http://www.winehq.com/hypermail/wine-devel/2003/12/0242.html) in the archives.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.