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@hotmail.com
Maybe somebody else will make a better answer. If not, I hope this helps.
Lawson ---oof---