Access Control Functions

Gregory Hicks ghicks at
Fri Nov 30 23:36:04 CST 2001

Does this mean wine has a new author working on it?


lawson_whitney at wrote:

> 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
> helps.
> Lawson
> ---oof---

More information about the wine-devel mailing list