Re: GSoC 2013 - Registry Merging Project
Tests for read-operations has been done.
http://newtestbot.winehq.org/JobDetails.pl?Key=942
All the results are expected:
1. query_value prefer values in hkcu.
2. query_key_info gives the count of subkeys and values distincted.
3. enum_value enum_key combine result from hkcu hklm and return in
sorted order
I've looked into server/registry.c to find the subkeys are stored in
alphabet order and is located by binary search. So when enumerating
subkeys or values from hkcr, the two branches hkcu and hklm can be
combined using a algorithm like part of merge_sort.
Had hard time testing what happens using a dumped key handle of hkcr
from another user, as mentioned in last mail. Steps in my test:
1. make sure hkcu/software/classes/subkey1 exist in hkcu of both user1
and user2.
2. program1 of user1 set 'val1' in hkcu/software/classes/subkey1 to 'user1'
3. program1 opens a handle to hkcr/subkey1, print it out then wait but not exit.
3. program2 of user2 dumps the handle from program1 to program2, set
value 'val1' to 'user2' with that handle.
4. program1 continues, open hkcu/classes/subkey1. query and print out
current value of 'val1'.
Here we care what value is eventually set to 'val1' in user1. As we
know a handle is associated with a kernel object. dumped handle points
to same object as original.
- If the final value is 'user1', that denotes operations by user2 with
hckr key objects created from user1 have no effect on user1.
- If the value is 'user2', operations from another user changes
content from owner user, obviously the key-view is associated with the
own user I'm considering to add a field 'owner' in my key view object.
The test code is attached, and output is as following, note that the
second program start running when the first paused.
runas /user:user1 testcls 1
program1 on user1 has pid : 2092
'val1' set to 'user1' on user1
handle of subkey1 opened from hkcr : 07D2
come back after runing program2 as user2
press any key to continue . .
'val1' on user1 is 'user2' now
runas /user:user2 testcls 2
input pid of program1
2092
input handle of subkey1 in program1
7d2
dumped handle on user2 : 07B0
'val1' set to 'user2'
The final result turned out to be 'user2'. As expected, isn't it?
Till now, most of my test work has finished. I'm going to make out a
stage conclusion soon then I'll come to the main point - the implement
of merging.
#include stdio.h
#include stdlib.h
#include windows.h
int main1()
{
DWORD res, size, type;
HKEY hkey;
char name[32];
printf(program1 on user1 has pid : %d\n, GetCurrentProcessId());
/* create subkey1 in hkcu */
if ((res = RegCreateKeyExA( HKEY_CURRENT_USER, Software\\Classes\\subkey1, 0, NULL, 0,
KEY_SET_VALUE|KEY_QUERY_VALUE,
NULL, hkey, NULL )) != ERROR_SUCCESS)
{
printf(RegCreateKeyExA failed with %08X\n, res);
return -1;
}
/* set val1 to user1 */
strcpy(name, user1);
if ((res = RegSetValueExA(hkey, val1, 0, REG_SZ, (CONST BYTE*)name, strlen(name))) != ERROR_SUCCESS)
{
printf(RegSetValueExA failed with %08X\n, res);
return -1;
}
if ((res = RegFlushKey(hkey)) != ERROR_SUCCESS)
{
printf(RegFlushKey failed with %08X\n, res);
return -1;
}
printf('val1' set to '%s' on user1\n, name);
RegCloseKey(hkey);
/* open subkey1 from hkcr */
if ((res = RegOpenKeyExA( HKEY_CLASSES_ROOT, subkey1, 0,
KEY_SET_VALUE|KEY_QUERY_VALUE,
hkey )) != ERROR_SUCCESS)
{
printf(RegOpenKeyExA failed with %08X\n, res);
return -1;
}
printf(handle of subkey1 opened from hkcr : %p\n, hkey);
/* wait program2 to dump the handle */
printf(come back after runing program2 as user2\n);
system(pause);
RegCloseKey(hkey);
/* see what is in val1 now */
if ((res = RegOpenKeyExA( HKEY_CURRENT_USER, Software\\Classes\\subkey1, 0,
KEY_SET_VALUE|KEY_QUERY_VALUE,
hkey )) != ERROR_SUCCESS)
{
printf(RegOpenKeyExA failed with %08X\n, res);
return -1;
}
type = REG_SZ;
size = sizeof(name);
if ((res = RegQueryValueExA(hkey, val1, 0, type, (BYTE*)name, size)) != ERROR_SUCCESS)
{
printf(RegQueryValueExA failed with %08X\n, res);
return -1;
}
printf('val1' on user1 is '%s' now\n, name);
RegCloseKey(hkey);
return 0;
}
int main2()
{
DWORD pid1, res, size, type;
HKEY hkey;
HANDLE hprocess, htoken;
TOKEN_PRIVILEGES tkp;
char name[32];
/* get a debug privilege so that we can open process of another user */
if(!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, htoken))
{
printf(OpenProcessToken failed with 0x%08X\n, GetLastError());
return -1;
}
tkp.PrivilegeCount = 1;
LookupPrivilegeValue(NULL,SE_DEBUG_NAME,
Re: GSoC 2013 - Registry Merging Project
I decided to rewrite the tests in orderliness. Today I have done the tests on write-operations ( http://newtestbot.winehq.org/JobDetails.pl?Key=931 ) . And ome of my assumptions has been confirmed: All the operations that change hkcr should prefer hkcu to hklm. That means if the _full_path_of_the_operation_ can be found in hkcu it act as mapping to hkcu, otherwise to hklm. _full_path_of_the_operation_ : for create_key and delete_key, it's the path of the handle plus the subkey path. for set_value and delete_value, it's the path of the handle. For example, set new value on 'val1 of hkcr/test1 affects hkcu when there are hkcu/software/classes/test1 and hklm/software/classes/test1, but affects hklm when there's only hklm/software/classes/test1. Another thing that I confirmed is that handle opened from hkcr is not the same as that from hkcu or hklm, even when there's only one such key in hkcu or hklm. Because further operations on the handle change the other when the 'path match' situation is meet. For example, make sure there is hkcu/software/classes/key1 but not hklm/software/classes/key1, after creating a new key subkey2 with the handle opened from hkcr/key1, it will be found as hklm/software/classes/key1/subkey2 rather than hkcu. Obviously operationg on a handle opened from hkcu/software/classes/key1 does not affect hklm, so there must be something necessary to do to tell the mapped key handle from oridinal one. My preliminary design: open_key for hkcr subkeys should return a new type handle - key_view, which have one field : key path relating to classes, all operations on the handle will be dynamic decided which branch to redirect to. As far as I know from my previous developing windows drivers, kernel and services run codes as system user, so the handle may be confused when using by different user, so I will test what happen when using a dumped key handle of hkcr subkeys across different users. To decide whether a more field 'owner uid' is needed. I'm going to test on read-operations soon, after this I'll start writing the test reports. -- Regards, Guo Jian
Re: GSoC 2013 - Registry Merging Project
I just found that the REG_OPTION_VOLATILE of create_key in hkcr may have some tricks. Not surprisingly found a strange situation when testing on windows. See my test here please : http://newtestbot.winehq.org/JobDetails.pl?Key=932 This happens as following : First create hkcu/software/classes/key1, then create the hkcr/key1/subkey with REG_OPTION_VOLATILE. RegEnumKey on hkcr will give two 'key1'. I tried to use RegQueryInfoKeyA to count them, also there are more than there should be. Why there are two duplicated keys? May it be a bug of windows? If it is, should we design our algorithm to avoid or treat it as a normal feature?
Re: GSoC 2013 - Registry Merging Project
And a new test is here http://newtestbot.winehq.org/JobDetails.pl?Key=934 2013/5/15 Guo Jian orz...@gmail.com: I just found that the REG_OPTION_VOLATILE of create_key in hkcr may have some tricks. Not surprisingly found a strange situation when testing on windows. See my test here please : http://newtestbot.winehq.org/JobDetails.pl?Key=932 This happens as following : First create hkcu/software/classes/key1, then create the hkcr/key1/subkey with REG_OPTION_VOLATILE. RegEnumKey on hkcr will give two 'key1'. I tried to use RegQueryInfoKeyA to count them, also there are more than there should be. Why there are two duplicated keys? May it be a bug of windows? If it is, should we design our algorithm to avoid or treat it as a normal feature? -- Regards, Guo Jian
Re: GSoC 2013 - Registry Merging Project
Hi Guo, On Tue, May 14, 2013 at 1:32 PM, Guo Jian orz...@gmail.com wrote: I just found that the REG_OPTION_VOLATILE of create_key in hkcr may have some tricks. Not surprisingly found a strange situation when testing on windows. See my test here please : http://newtestbot.winehq.org/JobDetails.pl?Key=932 This happens as following : First create hkcu/software/classes/key1, then create the hkcr/key1/subkey with REG_OPTION_VOLATILE. RegEnumKey on hkcr will give two 'key1'. I tried to use RegQueryInfoKeyA to count them, also there are more than there should be. Why there are two duplicated keys? May it be a bug of windows? If it is, should we design our algorithm to avoid or treat it as a normal feature? That's interesting. Windows might allow both a volatile and non-volatile key of the same name. Since the volatile one is kept in-memory, any values that exist in it will be discarded eventually, so any inconsistency that arises isn't the kernel's problem. That'd be my guess, at any rate: even though such a behavior has the potential to confuse application developers, since it's not the kernel's problem, it's probably an overlooked quirk. As far as what to do with it: this is one of those nuanced, i.e. hard to decide, things with our tests. In general, we assume that Windows's behavior is the correct behavior, unless we have strong reason to assume otherwise. We've encountered many times that even what appear to be bugs end up being relied upon by application developers. In this case, though, I think you might have stumbled across something that's relatively rare, and unless there's an application that depends on this behavior, it might be worth ignoring for now. Hope that helps. --Juan
Re: GSoC 2013 - Registry Merging Project
Sorry to bother. Forgot CC to wine-devel. In this case, though, I think you might have stumbled across something that's relatively rare, and unless there's an application that depends on this behavior, it might be worth ignoring for now. It's in rear case that applications use volatile key under hkcr. Won't waste time on the not so important detail if no further effects. Thank you.
Re: GSoC 2013 - Registry Merging Project
Have been working hard to get familiar with the workflow in wine, by reporting bugs (bug 33542 33550 and 33558) and sending patches (patch 96154 and 96157) to wine. I got more accustomed to the community to find I like here and I will keep working in wine even after GSoC. Working progress : I've concluded that all the registry operations : *create_key *delete_key *delete_value =enum_key =enum_value -flush_key -get_key_security -load_key -notify_change_key_value =open_key -override_predef_key =query_info_key =query_multipe_values =query_value -replace_key -restore_key -save_key -set_key_security *set_value -unload_key [ - operations that are not very important and less used, put them aside at first ] [ * operations that change the contents ] [ = operations that only read contents ] In my previous tests I found that create_key delete_key of HKCR works like simply redirecting to HKCU or HKLM (depending on how their subkeys conflict). So I guess that all the operations have such feature. The next thing I need to write tests for : - Where does each write-operations redirect to when there's [no subkey|both subkeys] in HKCU HKLM. - Where does each read-operations redirect to when HKCU HKLM conflicts. There is one thing that I can make sur, when it does not conflict in HKCU HKLM, operations are redirected to the only one. Another guess : open_key (including opening from create_key) will be a special operation, it should not return a handle directly based on HKCU or HKLM, or further operation on the handle will be treated as opened directly from the source. So it may be necessary to define a new type of key handle. Updated time table: Start Date End DateEvent 3rd, May12th, May Work on some basic knowledge (bugs, patches, winedbg debugchannel), learning workflow of wine. 13th, May * 16th, Jun Write full tests and test reports. Make puzzles clear. Design the main algorithm. 28th, May 24th, Jul Implement almost all of the registry merging feature. Submit as patch and track feedbacks. 25th, Jul 31st, Jul Finish and submit the Mid-term evaluations. 1st, Aug31st, Aug Implement the rest part of our scheme. Apply changes by patches. 1st, Sep22th, Sep Cleanups. Write the final evaluations. 23th, Sep / Submit to Google after some modification from the mentor. Note that the 2nd and 3rd part have time intersection beacause I think each of the two is based on another. -- Regards, Guo Jian
GSoC 2013 - Registry Merging Project
Hi, everyone. Thank you for your viewing and comments on the proposal. Sorry that the rough plan is kind of mess and now I've rewritten this part a little more like a Time Schedule. I appreciate it if you have a glance at it. From now to 27th, May. Work on some basic knowledge such as the usage of WineTestBot, getting familiar to debugging in wine or so, with help of the community, and do some favor if possible. 28th, May to 16th, June. Have interviews with the mentor at any time if convenient. Put forward my initial frame design and make puzzles clear, then adjust the plan under the guide of the mentor. So that the testing and development plan will be settled down after this part. 17th, June to 24, June. Carry out pre-work tests on variety versions of Windows. Write test reports which definite some questions and guesses. I wish to report some bugs during this part once I found one. Some invoking tests vie different layer of dlls both some additional test code (maybe for difference between versions of windows) to the existing one in the advapi32.dll should be written. 25th, June to 24th, July. Prophase of the official development. I'll implement almost all of the registry merging feature, especially code in the server part, so that I can submit my patch and looking forward to feedbacks as early as possible. 25th, July to 31st, July. The Mid-term evaluations will be finished and submitted. 1st, Auguest to 31st, August. Second stage of the development. Implement the rest part of our scheme. In this part, changes will be real-time reported in the mailing-list and apply improvement timely to make it closer to a final product. 1st, September to 27th, September. Only clean-ups and small fix of code should be left here. I'll write and verify the final evaluations and final test results, together with other documents produced in the project. Then with some modification from the mentor it's submitted to Google. The schedule will be carried out up to speed so that I may finish ahead of the end date in each part, in which case I'd like make prepare for the next part and contritube my spare time to the commutiry, rather that only such narrowed in one project. Considering that it may be a little fuzzy in boundarys of different phases, I came up with some Possible Milestones : 1.Pre-development test works are finished. 2.Complete the mostly full test codes. 3.Merging of classes in HKCU and HKLM is implemented in server part. 4.Merging is implemented in all aviable layer. 5.Compatibility of different Windows versions are fullfilled. 6.All the work including documents are done on time. That's most of the schedule I can think of now, and I'll be very happy to improve it before submitting it to the mentor If you have futher advise, to save time and make the communication smoother. Best Regards, Guo Jian
GSoC 2013 - Registry Merging Project
Hi. I'm applying for the Google Summer of Code 2013, this is my proposal for the registry merging project. I'll work on improving Wine's registry in its stability and simulation to solve frequently seen non user-friendly problems, which usually caused by that application or system settings are not stored and fetched correctly. Project My Understand: I'm most interested in the project Registry - implement merging between HKEY_CLASSES_ROOT and HKEY_CURRENT_USER\Software\Classes. Its core task is to implement RegOpenUserClassesRoot, which returns a key token of merging view of HKCU HKLM classes rather than present returning HKCR Classes. The difficulity is that as a view of two independent registry trees, how to treat conflicts and make changes to two seperated entrys when using HKCR as root, and how to achieve the function with no or least effect on other part of registry operation such as RegOpenKeyExX. I have some seed ideas that maybe not mature but I like solving problems initially from a burst port : Scheme 1. Registry operations based on hKey ( handle ) under HKEY_CLASSES_ROOT will be degeneration to full path in text, like HKEY_CLASSES_ROOT\Subdir1, and try the operation after HKEY_CLASSES_ROOT replaced with HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes in order, only the first success operation will be applied. This may satisfy the demand, both for query and modify. For details like the correct order, I'll make it out once get working on it. In this way, the HKCR key subtree does not exist in fact but only exists as a name. Scheme 2. After the base registry is initialized, build the HKCR's subkey trees with a new pulled in object type (say it 'symbol link') that directly point to the correct keys from HKLM or HKCU. Thus operation in HKCR tree are redirected to corresponding branch internally. When operating the HKCR itself, like creating new subkeys direct under HKCR, the operation is redirected to HKCU classes. This scheme seems more fluent but needs some tricks in the server part. What I'll Do : First of all I'll do a lot of tests on pure winows registry to definite my questions and guesses, write one or more test reports on different version of windows, some of which is already being done now. Followed by I will design the algorithms and data structures and make a complete development planation. Then enjoying coding and debuging Wine. I love the procedure, during the longest part of this project, keep writing daily report. Got the plan finished, I will applying improvement. Finally strict tests will be done to show if I achieved the final goal and a conclude paper will be carefully submitted. I'd like not only settle down the main project, but also several ideas to make Wine better, which are found in my daily use of Wine, such as add support for the shell context menu in Wine explorer for many convenient shotcuts of some software like the famous 7zip. I'll do this once time allows. Why Me : I myself is a faithful user of Wine. I know the thought of Wine and know not only basic usage but also a little implement of it. I understand Windows registry both Windows API pretty well from nearly 8 years coding. Have done much test and hooks in windows including RegXXX in advapi32.dll or lower level NtOpenKey in ntdll.dll. Further more, I used to do some kernel debug tests and hacks on registry, like hiding, protecting a subkey from regedit, resolving values from hive file rather than using API. These things are done under interests. I've been learning Windows API and OS theories from books and network like msdn for long. Ofcourse there will be no problem in registry knowledge. It's usual for me to write codes more than 1000 lines a day, for self use or for the competation ACM. I believe that I'm a careful man in codes and other things, I like discovering, guessing and proving. To prove I've developed a not too bad coding style, please refer to my submisions on codeforces http://codeforces.com/submissions/adnim (to view code click numbers under column #). And this may be a little evidence denoting that at least I've used git before, https://code.google.com/p/eryapass/ I know what should I do and what should not. I'm sure aware of the legal requirements. All of my tests will be done only in the black-box ways. No reverse work on Windows files is allowed and needed in Wine project, though I'm good at that. All codes will be written creatively and nothing will be copied from existing ones like WRK, RcactOS or something else. I love open source. I benefited much from the open source world and I'd be really happy to contribute to it one day. The last but most important, I'm much willing and I'm looking forward to throwing myself among the crowd of codes this entire summer, making maxium effort to improve Wine. I'd like schedule my personal activities to avoid conflicts with the development, meaning
Re: GSoC 2013 - Registry Merging Project
Hi Guo Jian, just so you know, there's another application for the same project. This doesn't mean that yours can't be accepted, but it does impact your chances. Thank you for your interest. Good luck, --Juan On Fri, May 3, 2013 at 1:05 AM, orzhvs orz...@gmail.com wrote: Hi. I'm applying for the Google Summer of Code 2013, this is my proposal for the registry merging project. I'll work on improving Wine's registry in its stability and simulation to solve frequently seen non user-friendly problems, which usually caused by that application or system settings are not stored and fetched correctly. Project My Understand: I'm most interested in the project Registry - implement merging between HKEY_CLASSES_ROOT and HKEY_CURRENT_USER\Software\Classes. Its core task is to implement RegOpenUserClassesRoot, which returns a key token of merging view of HKCU HKLM classes rather than present returning HKCR Classes. The difficulity is that as a view of two independent registry trees, how to treat conflicts and make changes to two seperated entrys when using HKCR as root, and how to achieve the function with no or least effect on other part of registry operation such as RegOpenKeyExX. I have some seed ideas that maybe not mature but I like solving problems initially from a burst port : Scheme 1. Registry operations based on hKey ( handle ) under HKEY_CLASSES_ROOT will be degeneration to full path in text, like HKEY_CLASSES_ROOT\Subdir1, and try the operation after HKEY_CLASSES_ROOT replaced with HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes in order, only the first success operation will be applied. This may satisfy the demand, both for query and modify. For details like the correct order, I'll make it out once get working on it. In this way, the HKCR key subtree does not exist in fact but only exists as a name. Scheme 2. After the base registry is initialized, build the HKCR's subkey trees with a new pulled in object type (say it 'symbol link') that directly point to the correct keys from HKLM or HKCU. Thus operation in HKCR tree are redirected to corresponding branch internally. When operating the HKCR itself, like creating new subkeys direct under HKCR, the operation is redirected to HKCU classes. This scheme seems more fluent but needs some tricks in the server part. What I'll Do : First of all I'll do a lot of tests on pure winows registry to definite my questions and guesses, write one or more test reports on different version of windows, some of which is already being done now. Followed by I will design the algorithms and data structures and make a complete development planation. Then enjoying coding and debuging Wine. I love the procedure, during the longest part of this project, keep writing daily report. Got the plan finished, I will applying improvement. Finally strict tests will be done to show if I achieved the final goal and a conclude paper will be carefully submitted. I'd like not only settle down the main project, but also several ideas to make Wine better, which are found in my daily use of Wine, such as add support for the shell context menu in Wine explorer for many convenient shotcuts of some software like the famous 7zip. I'll do this once time allows. Why Me : I myself is a faithful user of Wine. I know the thought of Wine and know not only basic usage but also a little implement of it. I understand Windows registry both Windows API pretty well from nearly 8 years coding. Have done much test and hooks in windows including RegXXX in advapi32.dll or lower level NtOpenKey in ntdll.dll. Further more, I used to do some kernel debug tests and hacks on registry, like hiding, protecting a subkey from regedit, resolving values from hive file rather than using API. These things are done under interests. I've been learning Windows API and OS theories from books and network like msdn for long. Ofcourse there will be no problem in registry knowledge. It's usual for me to write codes more than 1000 lines a day, for self use or for the competation ACM. I believe that I'm a careful man in codes and other things, I like discovering, guessing and proving. To prove I've developed a not too bad coding style, please refer to my submisions on codeforces http://codeforces.com/submissions/adnim (to view code click numbers under column #). And this may be a little evidence denoting that at least I've used git before, https://code.google.com/p/eryapass/ I know what should I do and what should not. I'm sure aware of the legal requirements. All of my tests will be done only in the black-box ways. No reverse work on Windows files is allowed and needed in Wine project, though I'm good at that. All codes will be written creatively and nothing will be copied from existing ones like WRK, RcactOS or something else. I love open source. I benefited
Re: GSoC 2013 - Registry Merging Project
Hi Juan, Thank you for your reply. Sincerely sorry for my late application, you know that's really not pleasing. But I think that increase my enthusiasm at the same time. I will keep focus and spend more time on it as I'm just getting start in the community. I love it even more when it seems to be a challenge :) regards. Guo Jian 2013/5/4 Juan Lang juan.l...@gmail.com Hi Guo Jian, just so you know, there's another application for the same project. This doesn't mean that yours can't be accepted, but it does impact your chances. Thank you for your interest. Good luck, --Juan On Fri, May 3, 2013 at 1:05 AM, orzhvs orz...@gmail.com wrote: Hi. I'm applying for the Google Summer of Code 2013, this is my proposal for the registry merging project. I'll work on improving Wine's registry in its stability and simulation to solve frequently seen non user-friendly problems, which usually caused by that application or system settings are not stored and fetched correctly. Project My Understand: I'm most interested in the project Registry - implement merging between HKEY_CLASSES_ROOT and HKEY_CURRENT_USER\Software\Classes. Its core task is to implement RegOpenUserClassesRoot, which returns a key token of merging view of HKCU HKLM classes rather than present returning HKCR Classes. The difficulity is that as a view of two independent registry trees, how to treat conflicts and make changes to two seperated entrys when using HKCR as root, and how to achieve the function with no or least effect on other part of registry operation such as RegOpenKeyExX. I have some seed ideas that maybe not mature but I like solving problems initially from a burst port : Scheme 1. Registry operations based on hKey ( handle ) under HKEY_CLASSES_ROOT will be degeneration to full path in text, like HKEY_CLASSES_ROOT\Subdir1, and try the operation after HKEY_CLASSES_ROOT replaced with HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes in order, only the first success operation will be applied. This may satisfy the demand, both for query and modify. For details like the correct order, I'll make it out once get working on it. In this way, the HKCR key subtree does not exist in fact but only exists as a name. Scheme 2. After the base registry is initialized, build the HKCR's subkey trees with a new pulled in object type (say it 'symbol link') that directly point to the correct keys from HKLM or HKCU. Thus operation in HKCR tree are redirected to corresponding branch internally. When operating the HKCR itself, like creating new subkeys direct under HKCR, the operation is redirected to HKCU classes. This scheme seems more fluent but needs some tricks in the server part. What I'll Do : First of all I'll do a lot of tests on pure winows registry to definite my questions and guesses, write one or more test reports on different version of windows, some of which is already being done now. Followed by I will design the algorithms and data structures and make a complete development planation. Then enjoying coding and debuging Wine. I love the procedure, during the longest part of this project, keep writing daily report. Got the plan finished, I will applying improvement. Finally strict tests will be done to show if I achieved the final goal and a conclude paper will be carefully submitted. I'd like not only settle down the main project, but also several ideas to make Wine better, which are found in my daily use of Wine, such as add support for the shell context menu in Wine explorer for many convenient shotcuts of some software like the famous 7zip. I'll do this once time allows. Why Me : I myself is a faithful user of Wine. I know the thought of Wine and know not only basic usage but also a little implement of it. I understand Windows registry both Windows API pretty well from nearly 8 years coding. Have done much test and hooks in windows including RegXXX in advapi32.dll or lower level NtOpenKey in ntdll.dll. Further more, I used to do some kernel debug tests and hacks on registry, like hiding, protecting a subkey from regedit, resolving values from hive file rather than using API. These things are done under interests. I've been learning Windows API and OS theories from books and network like msdn for long. Ofcourse there will be no problem in registry knowledge. It's usual for me to write codes more than 1000 lines a day, for self use or for the competation ACM. I believe that I'm a careful man in codes and other things, I like discovering, guessing and proving. To prove I've developed a not too bad coding style, please refer to my submisions on codeforces http://codeforces.com/submissions/adnim (to view code click numbers under column #). And this may be a little evidence denoting that at least I've used git before, https://code.google.com/p/eryapass/ I know what should I
