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 > [EMAIL PROTECTED] Maybe somebody else will make a better answer. If not, I hope this helps. Lawson ---oof---
