WWN Issue 253

This is the 253rd issue of the Wine Weekly News publication. Its main goal is to open Silverton. 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.org

This week, 211 posts consumed 686 K. There were 66 different contributors. 39 (59%) posted more than once. 33 (50%) posted last week too.

The top 5 posters of the week were:

20 posts in 58K by Mike Hearn
16 posts in 41K by Alexandre Julliard
11 posts in 27K by Eric Pouech
10 posts in 38K by Robert Shearman
8 posts in 22K by Dmitry Timoshkov

MSI Status Update	09/ /2004	Archive
Aric Stewart dropped a quick update on some work done with Microsoft Installer APIs: Long time no post :) I just wanted to give an update that Mike M. and I have done a lot of msi work over the first few weeks of December which caused a few significant changes to particularly action.c where we eliminated many of the static buffers for file paths and replaced them with dynamic buffers. Vitaly Lipatov's patches reminded me that i should probably give you all a heads up about that. We were going to break them down and start submitting them but then Mike went off and got married and is on his Honeymoon. So when he gets back we are going to either break the changes down into smaller patches or try to get Alexandre to approve a big one. I will start trying to get some of the smaller ones broken down and submitted in the meantime. Vitaly Lipatov's patchs do not directly conflict with anything so we are just fine there. I will work them into our tree so that i can be sure they are not lost. But if anyone else is also doing msi work you may want to check in here so that we can make sure it all fits together ok.

Direct3D 9	12/13/2004	Archive
DirectX Jason Edmeades continued working on Direct3D 9 this week. A major patch was blocked for a few weeks, but since it went in there's been quite a few steady patches. Jason reported some initial success this week: Yes, with this patch all the d3d9 programs that only require the support of a single flat triangle in the middle of the screen will now work fine :-) Ok... perhaps an exaggeration but the good news is my patches are finally getting to the point where I can test and see output, and the first d3d9 program to work under the wine cvs tree is one of the following tutorials: http://triplebuffer.devmaster.net/tutorials.php Specifically Stepping Stones tutorial 2 (I never bothered with (1) as I can't tell whether a blank screen looks right or not). Actually, I've also tried tutorials 3,4 and 5 - all of which behave about the same as windows. There's a long, long way to go, but d3d9 things will slowly start working from here onwards (I hope!). What's left? RenderTargets, Textures, Shaders are the main things

Removing Stubs	12/14/2004	Archive
Creating Stubs Ge van Geldorp added a new mode to winebuild to build a PE DLL C file from a spec file. He wondered why the patch he submitted last month hadn't been committed, so Alexandre explained, I don't think we want to add a special mode just for stubs; they should really be replaced by proper functions (even if the functions are stubs themselves, at least they can print the parameters and try to return something meaningful instead of killing the app). You can view the lack of stubs support on PE as an encouragement to help us remove them from the spec files ;-) If you've ever looked at Wine's .spec files you'll see lots of stub entries. Stubs don't exist yet as functions, not even empty functions returning something like 'success'. Instead, they simply serve as a reminder for future work to be done. Ge thought turning stubs into even empty functions was a daunting task, Seems impossible for functions with unknown calling conventions and number of parameters. Andi Mohr didn't think it was so hard to figure out: What's the problem here? If you have an app exercising that function, then you have an object ready for examination already, and if you don't have any app using it, then you don't have any problem anyway... OK, mere mortal endusers might have problems with some apps crashing, but they're easily lost in slightly more severe cases anyway ;) Alexandre thought stubs caused problems though, we have added stubs as placeholders all over the place, while we should have only added them where there is a real need (mostly for ordinal imports). So now it will be a bit of work before we can get rid of them, but that should be the long term goal; and that's why I don't think we should add more code to support them. Mike Hearn thought they were needed: I'm a bit confused, the specfile level stubs are handy if only because when an app calls them you can see exactly which function was called in the error. Otherwise you'd just get a crash at 0xdeadbeef (what if that address is mapped? can that even happen?). It also suppresses all the warnings from the linker when using native DLLs that are linked against internal functions but never use them, for whatever reason. They also make adding new DLLs easier, as you don't have to submit lots of stub functions for every entry point. I guess we could have a script to generate them given a header, but still Alexandre thought all that could be worked around, Not adding the functions at all is even easier, and the results are pretty much the same... As you noted, in general the only advantage of stubs is that you get a better error message, but that would be fairly easy to handle at the loader level. The problem with adding stubs everywhere is that now we don't know which ones are really needed. Mike understood what needed to be done: Hmm, you mean we could remove the spec file entries that apps never actually link against? Perhaps the first step then would be to implement support in winebuild and the loader such that the list of stubbed functions is exported then the loader can link imports from those to stubs generated on the fly. At that point the winebuild support for stubs could be removed, and all the @ stub entries also deleted in one go. There was some concern that just removing stubs would lead to losing information. For example, ordinal functions that are called by a number are pretty much undocumented and removing the blank stubs would lose things like function name and calling parameters. Alexandre thought that could be worked out, Obviously we can't blindly remove all stubs, each individual case needs to be looked at. But there aren't that many ordinal exports, and adding dummy functions for them shouldn't be that hard. Jon Griffiths pointed out another reason to remove stubs: I had a patch which enabled stub generation for building native dlls last year (http://www.winehq.org/hypermail/wine-patches/2003/07/0176.html ), that part was not accepted for the same reasons that are being mentioned in this thread. I would like to point out again that the VC linker will not generate a correct dll unless the ordinal stubs are present. Other native linkers may have the same problem. It seems very silly to me that we can't use M$'s own compiler/linker to build valid dlls (especially since these tools can be downloaded for free these days). M$ defined the dll format we are using, after all. Alexandre agreed, Yes, that's exactly why we need to get rid of stubs; there is no such concept on Windows. The solution is not to start building a .spec.c file for MSVC, it's to fix our spec files so that they can work on Windows without generating extra code. This means replacing the stubs by real functions.

Removing Stubs

12/14/2004

Archive

Creating Stubs

Ge van Geldorp added a new mode to winebuild to build a PE DLL C file from a spec file. He wondered why the patch he submitted last month hadn't been committed, so Alexandre explained, I don't think we want to add a special mode just for stubs; they should really be replaced by proper functions (even if the functions are stubs themselves, at least they can print the parameters and try to return something meaningful instead of killing the app). You can view the lack of stubs support on PE as an encouragement to help us remove them from the spec files ;-)

If you've ever looked at Wine's .spec files you'll see lots of stub entries. Stubs don't exist yet as functions, not even empty functions returning something like 'success'. Instead, they simply serve as a reminder for future work to be done. Ge thought turning stubs into even empty functions was a daunting task, Seems impossible for functions with unknown calling conventions and number of parameters.

Andi Mohr didn't think it was so hard to figure out:

What's the problem here?

If you have an app exercising that function, then you have an object ready for examination already, and if you don't have any app using it, then you don't have any problem anyway...

OK, mere mortal endusers might have problems with some apps crashing, but they're easily lost in slightly more severe cases anyway ;)

Alexandre thought stubs caused problems though, we have added stubs as placeholders all over the place, while we should have only added them where there is a real need (mostly for ordinal imports). So now it will be a bit of work before we can get rid of them, but that should be the long term goal; and that's why I don't think we should add more code to support them.

Mike Hearn thought they were needed:

I'm a bit confused, the specfile level stubs are handy if only because when an app calls them you can see exactly which function was called in the error. Otherwise you'd just get a crash at 0xdeadbeef (what if that address is mapped? can that even happen?).

It also suppresses all the warnings from the linker when using native DLLs that are linked against internal functions but never use them, for whatever reason.

They also make adding new DLLs easier, as you don't have to submit lots of stub functions for every entry point. I guess we could have a script to generate them given a header, but still

Alexandre thought all that could be worked around, Not adding the functions at all is even easier, and the results are pretty much the same... As you noted, in general the only advantage of stubs is that you get a better error message, but that would be fairly easy to handle at the loader level. The problem with adding stubs everywhere is that now we don't know which ones are really needed.

Mike understood what needed to be done:

Hmm, you mean we could remove the spec file entries that apps never actually link against?

Perhaps the first step then would be to implement support in winebuild and the loader such that the list of stubbed functions is exported then the loader can link imports from those to stubs generated on the fly. At that point the winebuild support for stubs could be removed, and all the @ stub entries also deleted in one go.

There was some concern that just removing stubs would lead to losing information. For example, ordinal functions that are called by a number are pretty much undocumented and removing the blank stubs would lose things like function name and calling parameters. Alexandre thought that could be worked out, Obviously we can't blindly remove all stubs, each individual case needs to be looked at. But there aren't that many ordinal exports, and adding dummy functions for them shouldn't be that hard.

Jon Griffiths pointed out another reason to remove stubs:

I had a patch which enabled stub generation for building native dlls last year (http://www.winehq.org/hypermail/wine-patches/2003/07/0176.html ), that part was not accepted for the same reasons that are being mentioned in this thread.

I would like to point out again that the VC linker will not generate a correct dll unless the ordinal stubs are present. Other native linkers may have the same problem. It seems very silly to me that we can't use M$'s own compiler/linker to build valid dlls (especially since these tools can be downloaded for free these days). M$ defined the dll format we are using, after all.

Alexandre agreed, Yes, that's exactly why we need to get rid of stubs; there is no such concept on Windows. The solution is not to start building a .spec.c file for MSVC, it's to fix our spec files so that they can work on Windows without generating extra code. This means replacing the stubs by real functions.

Apartment Breakage	12/17/2004	Archive
RPC / COM / OLE It appears the dust in the air from the recent COM/OLE work caused a bit of a problem for Bill Medland: For one reason or another I need to help get the ole32/oleaut32/rpcrt4 working for our application (the REG_EXPAND_SZ issue means that we don't work with wine after 200409 because of the mix of native dlls we use) I just tried running with the native ole32/oleaut32/rpcrt4 and the first thing I tripped over was (what I presume is) an out-of-process COM problem. The actual stack dump is that: _LocalServerThread (compobj.c) calls StdMarshalImpl_MarshalInterface (...) which has mid.oxid = COM_CurrentApt()->oxid; which throws a memory error because COM_CurrentApt is null because, presumably the thread hasn't yet initialised an apartment. Does anyone know anything about this? e.g. when starting a new thread where does the apartment get initialized? Mike Hearn took a stab at diagnosing the problem: It's supposed to get initialized in the call to CoInitialize[Ex] however the _LocalServerThread never calls this as it's an internal implementation detail of out of process DCOM. This looks like we haven't got the design quite right here, the LocalServerThread doesn't exist in native DCOM as far as I can tell so it may need to be replaced by something else. The code in StdMarshalImpl is correct, the problem is that the local server thread is violating the COM laws by using CoMarshalInterface before entering an apartment. For now, does this patch help? The patch got Bill further, but he still ran into problems. There was a bit of back and forth on it, without much resolved, then Mike figured out the root of the problem: I see the problem. The patch which switched us over to using OXIDs isn't complete, the listener_thread should be per-apartment not per-process, and the pipe it creates should therefore use the oxid >> 32 + oxid string formatter. Rob is travelling back to the UK today. I don't know when he'll be back online, or even if he'll be working over the Christmas period. If not I'll see if I can write a patch to fix this regression this weekend. Then Rob Shearman popped up and mentioned he was working on this very area. He also thought Mike's patch was hackish and posted a one-liner to accomplish the same thing. Mike didn't think it was right though, Well, now we have a variation on the same problem. The apartments are getting mixed up, I suspect because Rob's patch creates a new apartment but we still don't create a new listener thread for each apt (rather it's still half process-scoped). Rob verified there was a problem and mentioned two quick solutions, you can either wait for my patch to fix local servers, or you can revert to ole32 as of 28th November. It'll likely be a few weeks before this work settles down, so if you depend on Wine's COM you may want steer clear of CVS.

Apartment Breakage

12/17/2004

World Wine News