Hi guys,
I note that Win98 is about to be finally obsoleted. After this, it's possible Microsoft will do the same as they did with IE and other stuff for Win95 and pull downloads from their website. This is a problem, because we currently need the DCOM downloads in order for some apps to work - can somebody with legal knowledge check the EULA and see if we are allowed to redistribute this file?
thanks -mike
I note that Win98 is about to be finally obsoleted. After this, it's possible Microsoft will do the same as they did with IE and other stuff for Win95 and pull downloads from their website. This is a problem, because we currently need the DCOM downloads in order for some apps to work
I guess we need to finish our DCOM implementation before that happens then :)
Rob
man, 05.01.2004 kl. 02.07 skrev Robert Shearman:
I note that Win98 is about to be finally obsoleted. After this, it's possible Microsoft will do the same as they did with IE and other stuff for Win95 and pull downloads from their website. This is a problem, because we currently need the DCOM downloads in order for some apps to work
I guess we need to finish our DCOM implementation before that happens then :)
Nobody has yet added typelib stuff to widl, eh... I guess I could whip up a framework or something to help with that, since nobody else has yet done it...
On Mon, 05 Jan 2004 14:17:28 +0100, Ove Kaaven wrote:
Nobody has yet added typelib stuff to widl, eh... I guess I could whip up a framework or something to help with that, since nobody else has yet done it...
Actually, in the last 4 days I recruited somebody to hack on this from IRC. He seems pretty competent and is currently implementing the ICreateTypeLib[2] interfaces I think. Alexander (nyef), are you tracking wine-devel yet?
If you could work on the widl backend of course that'd be fantastic. I'm still hoping to get back to properly submitting your DCOM/apartments work soon, but I have 3 or 4 higher priority things on my todo list currently.
I think once those two things are done we'll be able to make do without native DCOM in like 95% of cases..... we'd still need it for code that uses NdrClientCall but I think that'd be the only major missing feature remaining.
thanks -mike
It has been on my to do list for a while. I'm glad someone will beat me to it.
While at typelib.c in member TLB_ReadTypeLib
Note that only IMAGE_DOS_SIGNATURE is supported for native DLLS. Support most be for builtin DLLs as well. I'm not sure what the signature is. Than it goes on to do LoadLibraryExW( ...LOAD_LIBRARY_AS_DATAFILE ) and FindResourceA / LoadResource. This should all work for builtin DLLS as well, so there should be no problems. Just the check.
If you do that, and widl can make typlibs, we could embed them in .RC files Just like on MSVC.
Mike Hearn wrote:
On Mon, 05 Jan 2004 14:17:28 +0100, Ove Kaaven wrote:
Nobody has yet added typelib stuff to widl, eh... I guess I could whip up a framework or something to help with that, since nobody else has yet done it...
Actually, in the last 4 days I recruited somebody to hack on this from IRC. He seems pretty competent and is currently implementing the ICreateTypeLib[2] interfaces I think. Alexander (nyef), are you tracking wine-devel yet?
If you could work on the widl backend of course that'd be fantastic. I'm still hoping to get back to properly submitting your DCOM/apartments work soon, but I have 3 or 4 higher priority things on my todo list currently.
I think once those two things are done we'll be able to make do without native DCOM in like 95% of cases..... we'd still need it for code that uses NdrClientCall but I think that'd be the only major missing feature remaining.
thanks -mike
Nobody has yet added typelib stuff to widl, eh... I guess I could whip up a framework or something to help with that, since nobody else has yet done it...
Actually, in the last 4 days I recruited somebody to hack on this from IRC. He seems pretty competent and is currently implementing the ICreateTypeLib[2] interfaces I think. Alexander (nyef), are you tracking wine-devel yet?
That's lucky, because I was going to work on that. I thought about moving all of the typelib stuff to a library (because ITypeLib and ICreateTypeLib must be part of the same object), so that we could use it from widl as part of the build process.
If you could work on the widl backend of course that'd be fantastic. I'm still hoping to get back to properly submitting your DCOM/apartments work soon, but I have 3 or 4 higher priority things on my todo list currently.
I think once those two things are done we'll be able to make do without native DCOM in like 95% of cases..... we'd still need it for code that uses NdrClientCall but I think that'd be the only major missing feature remaining.
I have a load of code that implements NdrClientCall2 (what's the difference between NdrClientCall and NdrClientCall2?). I am just starting work on NdrServerCall2/NdrStubCall2.
Rob
On Mon, 2004-01-05 at 15:16, Robert Shearman wrote:
That's lucky, because I was going to work on that. I thought about moving all of the typelib stuff to a library (because ITypeLib and ICreateTypeLib must be part of the same object), so that we could use it from widl as part of the build process.
Well, this guy has no history of Wine contribution other than the _putenv unit tests so don't scrub it from your todo list yet. Let's wait until we see the code. Still, he has been seemingly been making good progress. He wants our TLBs to be exactly the same as the windows ones, the _putenv tests were part of making MIDL work correctly again on Wine.
I have a load of code that implements NdrClientCall2 (what's the difference between NdrClientCall and NdrClientCall2?). I am just starting work on NdrServerCall2/NdrStubCall2.
I have no idea, I expect I just misremembered the name actually.
thanks -mike
man, 05.01.2004 kl. 14.34 skrev Mike Hearn:
On Mon, 05 Jan 2004 14:17:28 +0100, Ove Kaaven wrote:
Nobody has yet added typelib stuff to widl, eh... I guess I could whip up a framework or something to help with that, since nobody else has yet done it...
Actually, in the last 4 days I recruited somebody to hack on this from IRC. He seems pretty competent and is currently implementing the ICreateTypeLib[2] interfaces I think. Alexander (nyef), are you tracking wine-devel yet?
If you could work on the widl backend of course that'd be fantastic. I'm still hoping to get back to properly submitting your DCOM/apartments work soon, but I have 3 or 4 higher priority things on my todo list currently.
Well, I've done about as much as I dared do without knowing exactly what plans you have. After all, widl can *not* link to oleaut32 since widl is not a Winelib app (and wasn't meant to be since someday we may want widl to generate some of the .c and .h files used by Wine DLLs such as oleaut32 at build time, instead of putting the generated files into CVS). My original plan was to use stdio to write typelibs straight from widl, not to use ICreateTypeLib.
On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote:
Well, I've done about as much as I dared do without knowing exactly what plans you have. After all, widl can *not* link to oleaut32 since widl is not a Winelib app (and wasn't meant to be since someday we may want widl to generate some of the .c and .h files used by Wine DLLs such as oleaut32 at build time, instead of putting the generated files into CVS). My original plan was to use stdio to write typelibs straight from widl, not to use ICreateTypeLib.
OK, I thought I'd CC this to Alexander so he realises this, I must admit I had just assumed widl was a winelib app like all the others.
To be honest, as we might one day have to implement ICreateTypeLib anyway (and i think Alexander mentioned he wanted these for his own project anyway), it seems like a lot of extra work to do this once in widl and again in oleaut32. Is being able take generated files out of CVS really that big a gain? We already ship quite a few (wineserver, build system, idl->h) and it doesn't really cause problems.
thanks -mike
tor, 08.01.2004 kl. 12.52 skrev Mike Hearn:
On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote:
Well, I've done about as much as I dared do without knowing exactly what plans you have. After all, widl can *not* link to oleaut32 since widl is not a Winelib app (and wasn't meant to be since someday we may want widl to generate some of the .c and .h files used by Wine DLLs such as oleaut32 at build time, instead of putting the generated files into CVS). My original plan was to use stdio to write typelibs straight from widl, not to use ICreateTypeLib.
OK, I thought I'd CC this to Alexander so he realises this, I must admit I had just assumed widl was a winelib app like all the others.
Huh? None of the other programs in tools/ are Winelib either AFAIK.
To be honest, as we might one day have to implement ICreateTypeLib anyway (and i think Alexander mentioned he wanted these for his own project anyway), it seems like a lot of extra work to do this once in widl and again in oleaut32. Is being able take generated files out of CVS really that big a gain? We already ship quite a few (wineserver, build system, idl->h) and it doesn't really cause problems.
I'm just saying that wasn't what it was supposed to be. But nothing a little rewriting can't change if we don't care about circular dependencies I guess, though the common typelib library (which Robert Shearman mentioned) would also be a solution.
On Thu, Jan 08, 2004 at 02:11:28PM +0100, Ove Kaaven wrote:
tor, 08.01.2004 kl. 12.52 skrev Mike Hearn:
On Wed, 2004-01-07 at 23:39, Ove Kaaven wrote:
Well, I've done about as much as I dared do without knowing exactly what plans you have. After all, widl can *not* link to oleaut32 since widl is not a Winelib app (and wasn't meant to be since someday we may want widl to generate some of the .c and .h files used by Wine DLLs such as oleaut32 at build time, instead of putting the generated files into CVS). My original plan was to use stdio to write typelibs straight from widl, not to use ICreateTypeLib.
OK, I thought I'd CC this to Alexander so he realises this, I must admit I had just assumed widl was a winelib app like all the others.
Huh? None of the other programs in tools/ are Winelib either AFAIK.
To be honest, as we might one day have to implement ICreateTypeLib anyway (and i think Alexander mentioned he wanted these for his own project anyway), it seems like a lot of extra work to do this once in widl and again in oleaut32. Is being able take generated files out of CVS really that big a gain? We already ship quite a few (wineserver, build system, idl->h) and it doesn't really cause problems.
I'm just saying that wasn't what it was supposed to be. But nothing a little rewriting can't change if we don't care about circular dependencies I guess, though the common typelib library (which Robert Shearman mentioned) would also be a solution.
Well, here's what I've got for ideas:
We could build widl twice, the second time as a winelib app.
We could set widl up to use an external winelib app to actually create the type libraries when needed.
We could move the implementation of the type library creation out to a separate library.
We could have some way of conditionally-compiling the typelib creation code so that it could be run without using any services other than libc or whatever.
However you slice it, though, if you use the ICreateTypeLib interfaces you're going to get bitten with a circular dependancy, if only because of the wtypes.h thing. And if you use an external library you're going to want to use it in oleaut32.dll as well just to avoid the code duplication. And that external library is going to want to duplicate the same parts from wtypes.h for VARENUM and such.
I hate to say it, but I think the best option might be to use an external winelib app to create the typelibs or to build a second copy of widl as a winelib app once winelib is available.
-- Alastair Bridgewater
On Thu, 2004-01-08 at 16:41, Nyef wrote:
However you slice it, though, if you use the ICreateTypeLib interfaces you're going to get bitten with a circular dependancy, if only because of the wtypes.h thing. And if you use an external library you're going to want to use it in oleaut32.dll as well just to avoid the code duplication. And that external library is going to want to duplicate the same parts from wtypes.h for VARENUM and such.
I hate to say it, but I think the best option might be to use an external winelib app to create the typelibs or to build a second copy of widl as a winelib app once winelib is available.
The other alternative is to have the generated files in CVS. That way we only deal with the bootstrapping issue once. We already have quite a few generated files in CVS because that makes our lives easier (think build system etc) - would it be acceptable to do the same here Alexandre?
Mike Hearn mike@theoretic.com writes:
The other alternative is to have the generated files in CVS. That way we only deal with the bootstrapping issue once. We already have quite a few generated files in CVS because that makes our lives easier (think build system etc) - would it be acceptable to do the same here Alexandre?
As a temporary hack maybe, but not as the proper solution. widl must be able to generate typelibs by itself without depending on the OLE dlls. Duplicating a bit of code if necessary is not a big deal.
-
Alexandre Julliard -
Boaz Harrosh -
Mike Hearn -
Nyef -
Ove Kaaven -
Robert Shearman