So I'm still stumbling through advapi32 and there seems to be some functions that were not exported. ANy reason why?
For example, AccessCheckByType was but AccessCheckByTypeAndAuditAlarm, AccessCheckByTypeResultList, AccessCheckByTypeResultListAndAuditAlarm, and AccessCheckByTypeResultListAndAuditAlarmByHandle were not mentioned in the .spec file. Are these missed exports? Do they need to be at least stubbed?
I know this all may seem bit anal, what with about a few thousand spec'ed APIs that need to be documented and all. I would just like to fill in the blankes as much as possable the first time through. I've already had to backtrack three times to add intresting comments I found important.(Function XYZ is only avilible on WinNT 3.1 or higher) It would be nice to at least have a fully spec'ed out DLL.
-Joshua
Joshua Walker wrote:
I know this all may seem bit anal,
The more anal the merrier if you ask me.......
what with about a
few thousand spec'ed APIs that need to be documented and all.
I think this is a grand idea!
I would just like to fill in the blankes as
much as possable the first time through. I've already had to backtrack three times to add intresting comments I found important.(Function XYZ is only avilible on WinNT 3.1 or higher) It would be nice to at least have a fully spec'ed out DLL.
Could you spec/stub out all the DX dlls? i'm verrrry aware that this could break some apps/games if a stub dlls is called. and in ceartin circumstances it may be best not to have a stub dll.... But there is a thing called .cvsignore and we coul'd just ignore the trouble makers untill there at a point of usability.
And who knows I might jump in and try my hand at helping out. And i'm sure there are others out there who could chip in.. and if all goes well we could in the end have a nice DX implementation...
So if your willing to spec/stub,,,, ill start with version resource's and go from there.
Any other volunteers?
Alexandre this is up to you I guess....... Can we ??
One way of looking at this is, we just want some space on http://cvs.winehq.org/ to work....collaborate..... And there are many examples of great things that happened from meager beginnings..
Tom
-Joshua
Tom twickline@skybest.com writes:
So if your willing to spec/stub,,,, ill start with version resource's and go from there.
Any other volunteers?
Alexandre this is up to you I guess....... Can we ??
No. As already explained a number of times, adding stubs for new functions is just asking for trouble, since apps will now try to call the functions and die. Stubs should only be added if there's an app that requires them. Same thing with dlls, unless there is a reason to have a stub dll it's much better to not have one at all so that the native one gets used.
On Thu, 2004-01-01 at 00:21, Alexandre Julliard wrote:
Same thing with dlls, unless there is a reason to have a stub dll it's much better to not have one at all so that the native one gets used.
I guess it's a matter of long term vs short term thinking, but in that case why do we build MSHTML when we have no implementation for it, and probably won't for some time?
Obviously we have to start somewhere, but I remember when MSHTML was first introduced some apps stopped working because we favour builtin DLLs over native ones, so everybody had to debug the problem (easy for people who can interpret stub FIXMEs and know what they mean) and then alter their config file to force mshtml to native.
thanks -mike
I guess it's a matter of long term vs short term thinking, but in that case why do we build MSHTML when we have no implementation for it, and probably won't for some time?
Well, creating the stubs is often the easiest part of working on a DLL.. So if nobody wants to work on a DLL, what would it gain us to have the stubs (as the people who are competent to work on it will also know how to create the stubs themselves).
Lionel
Alexandre Julliard wrote:
No. As already explained a number of times, adding stubs for new functions is just asking for trouble, since apps will now try to call the functions and die. Stubs should only be added if there's an app that requires them. Same thing with dlls, unless there is a reason to have a stub dll it's much better to not have one at all so that the native one gets used.
Okay, It has finally sunk into my hard head.. I won't ask again :-)
Tom
Joshua Walker wrote:
So I'm still stumbling through advapi32 and there seems to be some functions that were not exported. ANy reason why?
For example, AccessCheckByType was but AccessCheckByTypeAndAuditAlarm, AccessCheckByTypeResultList, AccessCheckByTypeResultListAndAuditAlarm, and AccessCheckByTypeResultListAndAuditAlarmByHandle were not mentioned in the .spec file. Are these missed exports? Do they need to be at least stubbed?
If no app uses them, we probably shouldn't export them. Let cruft die. - Dan
-
Alexandre Julliard -
Dan Kegel -
Joshua Walker -
Lionel Ulmer -
Mike Hearn -
Tom