Long time no post :) I just wanted to give an update that Mike M. and I have done alot 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 patchs reminded me that i should probably give you all a heads up about that. We where 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.

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 cant 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

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 ;)

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

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.

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.

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?

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.

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.

Looking at the archives it appears that wine-license has had very little traffic, to the point where a lot of it is probably not being read when it comes up, since people like me are not subscribed to that list.

It seems like a lot of the stuff being sent there should instead go to wine-devel.