June 2004 - Wine-Devel - list.winehq.org

Re: Scrollbars, an application bug or a wine regression ? (#2314)

by Dmitry Timoshkov

"George Marshall" <g.marshall(a)nospam.com> wrote: > Basically everything with the scrollbars worked fine > untill Wine 20040615. Does reverting of the following patch help? http://cvs.winehq.org/patch.py?id=12586 If no, you have to find an offending patch on your own. -- Dmitry.

June 30, 2004

Re: Cleaning up W->A calls

by Danny Hawkins

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 (truiken(a)comcast.net now truiken(a)gmail.com) On Wed, 30 Jun 2004 03:47:09 -0300, Marcelo Duarte <wine-devel(a)bol.com.br> 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 > >

June 30, 2004

Re: Scrollbars, an application bug or a wine regression ? (#2314)

by George Marshall

Nicolai Kuntze wrote: > Is it possible that you got confused with the wine versions? I think you > have permuted the names of your uploaded pictures .... Maybe I am wrong. > Well no, with the Wine release of May the application had no scrollbars (correctly) while with June release the scrollbars are shown and are not working properly. Regards.

June 30, 2004

Re: Scrollbars, an application bug or a wine regression ? (#2314)

by George Marshall

Gabriele Giorgetti wrote: > Hello, I've noticed a problem with scrollbars in the > latest Wine's release (20040615). With wine version > 20040505 everything was just fine. > > I've attacched a zip file with two screenshots > (pls. see wine BUG #2314 @ bugs.winehq.org ) > the first one is the correct behavior of the app using > wine 20040505 the second one is wine 20040615 and the > app in its wrong behavior. > > Trying to describe the problem: > The application show up with a bottom scrollbar and > a right scrollbar even if they are not needed. When > executing the very same application, with the very > same settings and size with wine 20040505 the scrollbars > are not there. Basically everything with the scrollbars worked fine untill Wine 20040615. Same correct (I guess) scrollbars behavior: wine: 20031016,20031118,20031212,20040121,20040309,20040408,20040505

June 30, 2004

Re: Cleaning up W->A calls

by Marcelo Duarte

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

June 30, 2004

Re: Typo in winedbg

by Andrei Barbu

Wouldn't that sound better as 'the process being debugged'? On Tue, 2004-06-29 at 10:14, Mike Hearn wrote: > On Mon, 28 Jun 2004 20:45:35 -0400, Andrei Barbu wrote: > > This fixes debuggee to debugger. > > I think debuggee is the right word, it means "the one that is being debugged". > Ctrl-C doesn't interrupt winedbg, it interrupts the process you are currently > attached to. > > >

June 30, 2004

Failed to compile on Sparc/Solaris 9

by John O'Donnell

make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/export/home/root/wine/wine/dlls/newdev' make[2]: Entering directory `/export/home/root/wine/wine/dlls/ntdll' ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./ntdll.spec cdrom.o critsection.o debugbuffer.o debugtools.o directory.o env.o error.o exception.o file.o heap.o large_int.o loader.o loadorder.o misc.o nt.o om.o path.o process.o reg.o relay.o resource.o rtl.o rtlbitmap.o rtlstr.o sec.o server.o signal_i386.o signal_powerpc.o signal_sparc.o string.o sync.o version.o thread.o time.o virtual.o wcstring.o relay32.o ntdll.dll.dbg.o -o ntdll.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lresolv -lsocket -lnsl ntdll.dll-IHmocZ.spec.c:20:1: warning: "__stdcall" redefined <command line>:17:1: warning: this is the location of the previous definition thread.o: In function `NtCurrentTeb': /export/home/root/wine/wine/dlls/ntdll/thread.c:582: undefined reference to `wine_pthread_get_current_teb' collect2: ld returned 1 exit status winegcc: gcc failed. make[2]: *** [ntdll.dll.so] Error 2 make[2]: Leaving directory `/export/home/root/wine/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/export/home/root/wine/wine/dlls' make: *** [dlls] Error 2 root(a)gold251:/root/wine/wine# This is CVS'ed a day ago. Any ideas? Any more info needed?

June 30, 2004

Cleaning up W->A calls

by James Hawkins

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. I'll start the question with an example: dlls/advapi32/crypt.c line 255, 482 BOOL WINAPI CryptAcquireContextA (HCRYPTPROV *phProv, LPCSTR pszContainer, LPCSTR pszProvider, DWORD dwProvType, DWORD dwFlags) { ... complete implementation } BOOL WINAPI CryptAcquireContextW (HCRYPTPROV *phProv, LPCWSTR pszContainer, LPCWSTR pszProvider, DWORD dwProvType, DWORD dwFlags) { PSTR pProvider = NULL, pContainer = NULL; BOOL ret = FALSE; TRACE("(%p, %s, %s, %ld, %08lx)\n", phProv, debugstr_w(pszContainer), debugstr_w(pszProvider), dwProvType, dwFlags); if ( !CRYPT_UnicodeToANSI(pszContainer, &pContainer, -1) ) CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); if ( !CRYPT_UnicodeToANSI(pszProvider, &pProvider, -1) ) { CRYPT_Free(pContainer); CRYPT_ReturnLastError(ERROR_NOT_ENOUGH_MEMORY); } ret = CryptAcquireContextA(phProv, pContainer, pProvider, dwProvType, dwFlags); if (pContainer) CRYPT_Free(pContainer); if (pProvider) CRYPT_Free(pProvider); return ret; } 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 B) implement both asci and wide-char functions separately ie asci functions only call asci functions etc. 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 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. 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 truiken(a)comcast.net

June 30, 2004

Re: [RFC] Wine upgrade procedure (spec)

by Vincent Béron

Le mar 29/06/2004 à 09:29, Dimitrie O. Paun a écrit : > On Tue, Jun 29, 2004 at 11:49:12AM +0100, Mike Hearn wrote: > > Short of copying the entire codebase into the users account when they > > explicitly choose to upgrade (ew, no other program does this) I can't see > > I agree, I personally hate this too, but Alexandre has a point in that > this may be the most compatible setup, so at least in theory we should > be able to support it just in case we need to employ it later. However, > I'm fairly sure we don't need to actually get a working version for it > at this time, we just need to make sure we could, if we wanted to, without > replacing the entire upgrade mechanism. Point2Play (Transgaming's Cedega frontend) does manage multiple Cedega versions for the following reason: less risks of running into regressions (you can specify which version to use for each application). > > > a good way of upgrading Wine while it's running that's free of race > > conditions. For instance, you could be in the middle of upgrading when a > > program you're running starts a new process: the wineserver may be using a > > different protocol to what the DLLs expect. > > > > I really don't think for now we should try and support upgrades while > > running. It should probably be up to the packages/install scripts to alert > > the user if they try that. > > Agreed. I think the most important thing is for Wine to integrate nicely > with the system where it's running, so that rpm -U / yum update works as > expected. If we go overboard with these sort of things, we may screw up > the OS integration (remember, rpm -U must be able to run unattended for > example), and this is a greater evil. Also, we have to be careful to not > be more catholics than the Pope: I really doubt that any significant number > of apps out there support 100% upgradability when they are running. Numerous server packages do a shutdown as a preinstall step and a start as a postinstall. It's quite ok for stateless programs, but could be a bit rude for Wine users. Still, it's possible to fail the upgrade (via rpm) if wine is detected as running at installation time. There's always the chance of a race between the time the detection is made and actual upgrade though. Vincent

June 30, 2004

Re: A wine magic trace key

by Eric Pouech

Andrei Barbu a écrit : > I'm about to implement a set of keys that lets me enable disable traces > any time. Seems to me like it's a good idea, like that I can get traces > for exactly what I need. Especially when I'm faced with weird debugger > output that's 10 minutes into the game and I can't turn traces on to > begin with. > > Is there another way, possibly existing, to do this? you can use the task manager (programs/taskmgr) to set/unset debug channels for any running program in a session A+

June 29, 2004