Access Control Functions

lawson_whitney at lawson_whitney at
Fri Nov 30 23:25:34 CST 2001

On Fri, 30 Nov 2001, Karl Bielefeldt wrote:

> I am new to open source development and to the wine project so please
> forgive me for sounding like a newbie.  I think wine is great and the key to
> the growth of Linux in the desktop market.
> I decided to begin my efforts by debugging the installation of MS Money 2001
> (my wife's must-have MS program) on a completely non-windows box.  This led
> to needing to install the msiexec installer (instmsia.exe, available from MS
> website).

I contribute to wine so we can have windows without microsoft, and what
do people do with it?  Try to get it to run microsoft apps, of course.
Don't mind me, I am only the oddest of wine's 300 odd authors.
> Everything works okay until we get to the access control functions.
> advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a
> stub.  Now, as far as I can tell, the stubs default to the least restrictive
> set of permissions, which I believe is fine for our purposes.  The problem
> comes when the program calls  kernel32.CloseHandle on the non-existent
> handle that was returned by the OpenProcessToken stub.
> Somebody please stop me if there is an easier way of solving this problem.
> It looks like we at least need to create some sort of dummy handle that can
> be removed by kernel32.CloseHandle without causing an error.  To do this we
> would need to add an open_process_token request handler to the wineserver
> (perhaps in a new file server/access.c).  Another alternative would be to
> create an open_dummy_handle request handler in server/handle.c that could be
> used for any generic dummy handle.  The advantage of the first method is
> that if someone decides to implement  all the access control functions
> properly, the framework is already in place.  Probably some combination of
> the two is best.
> I am willing to do the coding myself, but I'm unsure of the procedures for
> open source development.  How do you decide what changes are to be made, how
> do you submit your changes, how do you make sure you don't undo what someone
> else did, and things like that?  I also am having trouble finding
> documentation on the make_requests tool.

Just do it as best you can, test it, and if it works for you, make up a
patch against the current cvs and offer it on wine-patches.  It is up to
Alexandre Julliard if he will accept it without comment, ignore it
without comment, or tell you what he doesn't like.  Patches without an
accompanying ChangeLog entry (to go into <wine>/ChangeLog) or patches
made by diff without -u tend to be silently ignored.  If you think about
it, diff -u is the only reasonable format for an open-source project.
I make patches by making a shadow before and after wine direcrory tree
(with cp -Ppar from <wine>) and doing diff -urN before after; no doubt
this is obsoleted by cvs, but it still works.  You can also offer your
patch for comments on wine-devel before offering it to wine-patches.

AFAICT, the only doco on make_requests is the file itself (complete with
obsolete comments) and the generated comments in the files it generates.
All requests are defined in server/protocol.def, and make_requests
generates the headers and trace code to suit.  AFAICT.

> Thanks for tolerating my newbieness.  I'm looking forward to being able to
> start contributing to this great project.

> --Karl Bielefeldt
> kbielefe at

Maybe somebody else will make a better answer.  If not, I hope this


More information about the wine-devel mailing list