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
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
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
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
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.
> 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
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
> 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
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