Thankyou very much for your reply. I will take your advice and begin working on my first patch using your reference as a guide.
James Hawkins ([EMAIL PROTECTED] now [EMAIL PROTECTED]) On Wed, 30 Jun 2004 03:47:09 -0300, Marcelo Duarte <[EMAIL PROTECTED]> wrote: > > James Hawkins wrote: > First I suggest you to subscribe in the list, you are welcome, thus you > will receive all the answers from the other users. > http://www.winehq.org/mailman/listinfo/wine-devel > > >I recently decided to help with the development of Wine, and seeing as > >how I am new to the process, I have chosen menial tasks to take on. > >This way I can learn more about Wine while contributing. > > > > I am currently working on the janitorial task of getting rid of W->A > >calls and I have a few questions about how I should implement these > >changes. > > > > > > Initially CryptAcquireContextW converts all of its arguments to ansi > >then calls CryptAcquireContextA (which is intuitively not what we're > >wanting and thus the cleanup.) > > > > The question is, what exactly is the best way to clean this up? > > > > It seems to me that there are two main options as to what can be done: > > > > A) convert the W->A calls in the wide-char functions to A->W calls in > >the asci functions and implement the wide-char functions instead, or > > > > > The best is option A. > > > If we are to choose plan A, I have seen several different methods of > >converting asci to wide-char, and I am wondering which method is best. > >for example: > > > > dlls/advapi32/crypt.c lines 133-141 > > > > wcount = MultiByteToWideChar(CP_ACP, 0, str, -1, NULL, 0); > > wcount = wcount < wstrsize/sizeof(WCHAR) ? wcount : > >wstrsize/sizeof(WCHAR); > > if (wstrsize == -1) > > *wstr = CRYPT_Alloc(wcount * sizeof(WCHAR)); > > if (*wstr) > > { > > MultiByteToWideChar(CP_ACP, 0, str, -1, *wstr, wcount); > > return TRUE; > > } > > > > and, > > > > dlls/advapi32/registry.c lines 1626-1636 > > > > LONG WINAPI RegSaveKeyA( HKEY hkey, LPCSTR file, > > LPSECURITY_ATTRIBUTES sa ) > > { > > UNICODE_STRING *fileW = &NtCurrentTeb()->StaticUnicodeString; > > NTSTATUS status; > > STRING fileA; > > > > RtlInitAnsiString(&fileA, file); > > if ((status = RtlAnsiStringToUnicodeString(fileW, &fileA, FALSE))) > > return RtlNtStatusToDosError( status ); > > return RegSaveKeyW(hkey, fileW->Buffer, sa); > > } > > > > Which method is better/more efficient? > > > > > I do not cheched your code, but each situation has its reason and you > decide which you will be better. > I suggest you to start converting something simple, like: > dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to > Shell_NotifyIconA > dlls/version/install.c: version: VerInstallFileW: illegal call to > VerInstallFileA > When I made one of these conversions, I chose "dlls/shell32/shlexec.c: > shell32: ShellExecuteExW: illegal call to ShellExecuteExAand" very > laborious and was complicated. You can give one looked at as I made: > http://cvs.winehq.com/patch.py?id=10692 > > > > > I would have to argue that implementing both the asci functions and > >wide-char functions separately would be the most efficient way to solve > >the W->A problem. Throughout all the wine libs, many conversion calls > >are being made from W->A and A->W, when most of these calls could be > >left out. I think performance would improve without all of the > >conversion calls. Granted the size of the code would increase, but > >speed would also increase. > > > > > > > Yes, but the bugs duplicates, the code increases and the future I > believe that the majority of the programs is in unicode. > > > There are a couple snags when it comes to implementing asci and > >wide-char functions independently, but that can be discussed later. > > > > If I'm totally off the mark, let me know, and if there are other jobs I > >could be doing, let me know as well because I would like to contribute, > >but I'm not exactly sure what to do yet. Thankyou for your time. > > > > James Hawkins > > > > > > > > > I wait to have helped. > --- > Marcelo Duarte > >
