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

Re: mapi32: Replace CRITICAL_SECTION by RTL_CRITICAL_SECTION.
by Robert Shearman June 30, 2006

June 30, 2006

Hervé Poussineau wrote: >Replace CRITICAL_SECTION by RTL_CRITICAL_SECTION, according to prototype of >RtlEnterCriticalSection and others. > It would be better to fix the file to use the kernel32 critical section functions instead of the ntdll ones. -- Rob Shearman

1 0

Re: [AppDb] [Resend] prefix all GPC variables
by Chris Morgan June 30, 2006

June 30, 2006

There are several issues that I've found so far in this patch. It appears that you used a search and replace. You'll need to go through EVERY line of the patch and undo the changes to things like sql queries and others where the changes don't make sense. At some point we can discuss altering tables to match our internal variable scheme but we should wait until the php part of the patch is complete. Chris On Friday 30 June 2006 3:31 am, Jonathan Ernst wrote: > Before you ask, there was no possibility to split this one up because > everything is interdependant. > > Please commit it before other patches, it's a pain to rediff it agains head > and fix the conflicts everytime. > > Changelog: > - rename all Get/Post/Cookies variables using type prefixes so that we can > later use the autofiltering function

1 0

Re: [AppDb] appsubmit fix
by Chris Morgan June 30, 2006

June 30, 2006

Can we pass the parameters we need into the function instead of using a global? Chris On Thursday 29 June 2006 2:29 am, Jonathan Ernst wrote: > Changelog: > - $aClean was not visible in function

2 2

Debugging string comparison problem
by Juan Lang June 30, 2006

June 30, 2006

I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings "\1" and "\2". (See bug 5469, and the todo_wine test case in dlls/kernel/tests/locale.c) CompareStringA does the usual thing, calls MultiByteToWideChar and calls CompareStringW. So CompareStringW is comparing L"\0001" to L"\0002". CompareStringW calls wine_compare_string, in libs/unicode/sortkey.c That calls compare_unicode_weights. That has this little bit of code: ce1 = collation_table[collation_table[*str1 >> 8] + (*str1 & 0xff)]; ce2 = collation_table[collation_table[*str2 >> 8] + (*str2 & 0xff)]; With the strings L"\0001" and L"\0002", *str1 is 0x0001, and *str2 is 0x0002. So *str1 >> 8 is 0, and *str2 >> 8 is 0. *str1 & 0xff is 0x01, *str2 & 0xff is 0x02. So, ce1 == collation_table[1], which is 0x00000300 (in collation.c), and ce2 == collation_table[2], which is 0x00000400. That gets us here: if (ce1 != (unsigned int)-1 && ce2 != (unsigned int)-1) ret = (ce1 >> 16) - (ce2 >> 16); else ret = *str1 - *str2; Well, 0x00000300 >> 16 is 0, and so is 0x00000400, so ce1 - ce2 is 0, so these strings are considered equal. But as the test case shows, they're not supposed to be. I'm just not sure what to do about it. Changing collation.c isn't really an option, since it's generated. So there's some flaw in the logic here, but I don't understand the meaning of collation_table. Could someone explain to me what it is? Thanks, --Juan

3 5

Using firefox with ietab extension
by Paul Vriens June 30, 2006

June 30, 2006

Hi, anybody tried this already? I wanted to use Firefox 1.5.4 together with the ietab extension for some specific sites (Outlook Web Access). I don't want to install the Mozilla ActiveX plugin but instead us our internal stuff, but wasn't able yet to get this going. Installation of firefox and the extension is fine btw. Cheers, Paul.

1 0

Re: wine autorun utility
by William Knop June 30, 2006

June 30, 2006

> On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > >> Parsing a windows inf hardly belongs anywhere but wine. > > Actually, Troy makes that point rather well in an earlier mail: > >> This is not true. The existing action-on-CD-insertion programs >> provided by the >> desktop environment try to detect the contents of the CD to see >> what they >> should do, so they will be looking for the autorun.inf file. >> Additionally the >> autorun.inf file format is designed to include specifications of >> different >> commands for multiple environments, so if autorun.inf files are to be >> respected at all it makes sense that they should also be able to >> start a >> native Linux executable or shell script (discovered from an >> [autorun.linux.i386] section, for example). >> >> There is nothing in this that requires or enhances the Win32 API >> facilities >> that Wine seeks to provide. Only once the native Windows >> executable has been >> identified as the only (or best) target for autorun would Wine become >> involved, when the program in the desktop environment invoked Wine >> to run the >> executable. Sorry, I missed this one (mailer digest mode). Hmm... You're saying the autorun.inf format is os-independent? If so, I was unaware, and I agree that the functionality belongs elsewhere. Will

1 0

Re: advapi32: Implement RegisterServiceCtrlHandleExW.
by Andrey Turkin June 30, 2006

June 30, 2006

Robert Shearman wrote: > --- ... > @@ -603,10 +608,18 @@ static BOOL service_handle_control(HANDL > > TRACE("received control %ld\n", dwControl); > > - if (service_accepts_control(service, dwControl) && service->handler) > + if (service_accepts_control(service, dwControl)) > { > - service->handler(dwControl); > - ret = ERROR_SUCCESS; > + if (service->extended && service->handler.handler) > + { > + service->handler.handler(dwControl); > + ret = ERROR_SUCCESS; > + } > + else if (service->handler.handler_ex) > + { > + service->handler.handler_ex(dwControl, 0, NULL, service->context); > + ret = ERROR_SUCCESS; > + } > } Just wondering why you use Ex handler when service->extended==FALSE and vice versa.

2 1

Re: DDRAW: Releasing attached surfaces
by Stefan Dösinger June 30, 2006

June 30, 2006

Hi, > That's weird, now it works without the "fix" and even Tiberian Sun > starts where previously it hung. > I must have wrongly assumed that the bug was related to surface > implementation code... > But i'm still curious what might be the cause. Will check that out later. > Sorry for bothering then... ;) It was most likely the fix for Tiberian Sun that fixed dune. The problem with ts was that the primary surfaces(front and back) were missing some flags. Maybe dune didn't like the surfaces it got and tried to get rid of them and hit a buggy code path in its code. Stefan

1 0

Re: wine autorun utility
by William Knop June 30, 2006

June 30, 2006

> Gee sounds like a "great" idea. We all waiting too see some patches... > > It sure would be cool to have: > - Multiuser Wine > - Wine stable enough to run as service (err hmm whatever the hell > that means... > ah you mean daemon ?) > - Run something more complicated then 'printf("hello world\n");' > without X > - Talk to WMs to show icons and ask questions. > > Chris if you think that autostart is such a great idea - you are > very welcome to > start sending patches in. And if they are reasonable enough they > might get in. > But if you want to rant about that Linux doesn't have some > absolutely required > "feature" that windows has - this not the right place. > > Vitaliy Um hold on a second. Clearly many developers have different ideas about what's reasonable. It makes sense to obtain a semblance of unanimity and mutual understanding before taking action. You shouldn't go around quashing discussions like that. Will

4 7

Re: wine autorun utility
by Tim Schmidt June 30, 2006

June 30, 2006

On 6/30/06, William Knop <william.knop(a)gmail.com> wrote: > Parsing a windows inf hardly belongs anywhere but wine. Actually, Troy makes that point rather well in an earlier mail: > This is not true. The existing action-on-CD-insertion programs provided by the > desktop environment try to detect the contents of the CD to see what they > should do, so they will be looking for the autorun.inf file. Additionally the > autorun.inf file format is designed to include specifications of different > commands for multiple environments, so if autorun.inf files are to be > respected at all it makes sense that they should also be able to start a > native Linux executable or shell script (discovered from an > [autorun.linux.i386] section, for example). > > There is nothing in this that requires or enhances the Win32 API facilities > that Wine seeks to provide. Only once the native Windows executable has been > identified as the only (or best) target for autorun would Wine become > involved, when the program in the desktop environment invoked Wine to run the >executable. --tim

1 0