Re: user32:tests:msg Add test for switch mdi childs
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote:
+/* Switch visible mdi childs */
Please use the word 'children' to avoid confusion.
+trace("Switch child window.\n");
+
+ret = SendMessageA(mdi_client, WM_MDIACTIVATE, (WPARAM)mdi_child2, 0);
+ok(!ret, "Child not been deactivate(Switch test)\n");
active_child == mdi_child2, so it's not clear what you try to do in the test
above.
Besides, you don't check any subsequences of the call.
Since below starts another test 'flush_sequence();' should be added before.
+ret = SendMessageA(mdi_client, WM_MDIACTIVATE, (WPARAM)mdi_child, 0);
+
+ok(!ret, "Child not activate(Switch test)\n");
+
+ok_sequence(WmSwitchChild,"Child not switch correctly\n",TRUE);
Again, you don't check any subsequences of the call.
Also if you could add comments in the added message sequence what is going on,
it will help a lot later figuring out how to make the test pass under Wine.
Something along the following lines present in the existing sequences:
/* maximize the 1st MDI child */
...
/* restore the 2nd MDI child */
...
{ WM_CHILDACTIVATE, sent|defwinproc|wparam|lparam, 0, 0 }, /* in the 1st MDI
child */
{ WM_NCACTIVATE, sent|wparam|defwinproc, 0 }, /* in the 1st MDI child */
{ WM_MDIACTIVATE, sent|defwinproc }, /* in the 1st MDI child */
...
{ WM_KILLFOCUS, sent }, /* in MDI client */
{ WM_IME_SETCONTEXT, sent|wparam|optional, 0 }, /* in MDI client */
etc.
I understand that this is a tedious work, but it should be done.
--
Dmitry.
Re: Wine on FreeBSD (Was: Re: How to determine if something is "debuggable" ... ?)
On Saturday 02 June 2007 20:27:09 Marc G. Fournier wrote: > --On Saturday, June 02, 2007 10:55:00 +0200 Kai Blin <[EMAIL PROTECTED]> > > As I said in my email, I'm really happy to provide the Wine side of > > things for this bug, but I don't feel like doing the FreeBSD research. I > > don't use FreeBSD and my time is limited. > > S'alright, I don't mind working from the FreeBSD side of things, as long as > I'm not hitting a 'Linux vs FreeBSD' wall trying to do it :) Why I run > FreeBSD is my choice, why you run Linux is yours ... IMHO, neither of us > are running Windows, which should be all that truly matters :) Great. Now that this is settled, let's get some work done. > Let me read through your email and see if I can nudge some comments out of > some of the 'kernel developers' that I know, who might be able to help shed > some light ... or at least get us moving forward ... Thanks for the help, I really appreciate it. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton. pgpnKZFlYAzCk.pgp Description: PGP signature
Re: crypt32: remove 'recursive registry key delete' function
Am Saturday 02 June 2007 12:03 schrieb Paul Vriens: > On 6/1/07, Stefan Leichter <[EMAIL PROTECTED]> wrote: > > ChangeLog > > - > > replace CRYPT_RecurseDeleteKey with RegDeleteTreeW > > Hi Stefan, > > I don't think that's enough. There's a difference between SHDeleteKeyW > and RegDeleteTreeW (see also > http://wiki.winehq.org/RecursiveRegistryKeyDelete, but I guess that's > a known page to you). Basically you have to remove the key itself as > well. > > Cheers, > > Paul. Hello Paul, i think the comment is wrong. The removed function does not behave like SHDeleteKeyW. If you look at the removed code the key itself is not removed. At least i don't see the place where. But you are welcome to tell me where. Bye Stefan
Re: Wine on FreeBSD (Was: Re: How to determine if something is "debuggable" ... ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Saturday, June 02, 2007 10:55:00 +0200 Kai Blin <[EMAIL PROTECTED]> wrote: > Right. And it's not as if we didn't try. > Just two days ago, I've sent the following email to the freebsd-hackers > mailing list: > http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020761.html > > So far I've received one response, telling me to contact the ports > maintainer. I haven't followed up on this yet, but being a maintainer for a > couple of RPMs myself, I know that just being the maintainer doesn't mean I > know how to fix the source code of the package I maintain. I was kind of > hoping for some FreeBSD developers who know the memory management of their > OS to at least offer some pointers on where to look. Didn't happen so far. > > As I said in my email, I'm really happy to provide the Wine side of things > for this bug, but I don't feel like doing the FreeBSD research. I don't use > FreeBSD and my time is limited. S'alright, I don't mind working from the FreeBSD side of things, as long as I'm not hitting a 'Linux vs FreeBSD' wall trying to do it :) Why I run FreeBSD is my choice, why you run Linux is yours ... IMHO, neither of us are running Windows, which should be all that truly matters :) Let me read through your email and see if I can nudge some comments out of some of the 'kernel developers' that I know, who might be able to help shed some light ... or at least get us moving forward ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD4DBQFGYbZ94QvfyHIvDvMRAiZaAKC1IEzj2bIIPElQHWt2g12de5EtagCWIXBo IT1yZpYMoNTitRqVu7lI6Q== =OiGO -END PGP SIGNATURE-
Re: crypt32: implement CryptSIPLoad (try 5)
To kick off this first after memorial day weekend: http://x-coverage.com/micro-mini-string-bikinis/ See ya monday! -- Robert Q Kim, Wireless Internet Provider http://evdo-coverage.com/satellite-wireless-internet.html http://iptv-coverage.com http://wimax-coverage.com 2611 S. Pacific Coast Highway 101 Suite 203 Cardiff by the Sea, CA 92007 206 984 0880
Re: crypt32: implement CryptSIPLoad (try 5)
On 6/1/07, Juan Lang <[EMAIL PROTECTED]> wrote:
> I think it's worth figuring out why native does it like this.
Believe me, I've been trying to. I'm only inferring that it should be
loaded because using native wintrust calls CryptSIPLoad, and my
implementation makes it continue on to call other functions that seem
reasonable in that context.
I don't know what tests I can write to show that I should not pass the
DLL's function pointers directly back to the caller. That might make
sense if crypt32 were to try to unload unused function pointers
periodically, since the API doesn't provide an unload function - but that
seems overly complicated, and I unload them at DLL unload time instead.
If you have suggestions on tests I can write, I'm all ears.
I'm trying to come up with more tests but unfortunately no luck yet.
I've added some extra calls in the sip.c tests (with native CRYPT32
and msasn1) that directly call the returned pointer:
SetLastError(0xdeadbeef);
si.cbSize = sizeof(SIP_SUBJECTINFO);
si.pgSubjectType = &unknown;
ret2 = sdi.pfGet(&si, &a, 0, &b, &msg);
trace("ret : %d, GLE : 0x%08x\n", ret, GetLastError());
ret2 = funcCryptSIPGetSignedDataMsg(&si, &a, 0, &b, &msg);
trace("ret : %d, GLE : 0x%08x\n", ret, GetLastError());
Both run the function from crypt32 and forward to wintrust as can be
seen from the trace (+snoop,+wintrust):
fixme:wintrust:CryptSIPGetSignedDataMsg (0x33fdb4 0x33fe44 0 0x33fe40
0x33fe4b) stub
sip.c:341:ret : 1, GLE : 0x007a
0009:CALL CRYPT32.CryptSIPGetSignedDataMsg() ret=60309229
fixme:wintrust:CryptSIPGetSignedDataMsg (0x33fdb4 0x33fe44 0 0x33fe40
0x33fe4b) stub
0009:RET
CRYPT32.CryptSIPGetSignedDataMsg(0033fdb4,0033fe44,,0033fe40,0033fe4b)
retval= ret=60309229
sip.c:344:ret : 1, GLE : 0x007a
I don't see however how we can write a test for this (apart from the
one that tells us already that the function pointers are from
crypt32).
It appears that the loading part of all the function pointer is done
in CryptSIPLoad and the CryptSIPLoad returns the crypt32 function
pointers. All referenced crypt32 functions (such as
CryptSIPGetSignedDataMsg) seem to retrieve the dll function pointers
(as loaded by CryptSIPLoad) and forward to the appropriate DLL.
Doesn't the above method solve you're problem as well?
A trace with a native WINTRUST/CRYPT32/msasn gives:
0009:CALL WINTRUST.CryptSIPGetSignedDataMsg()
ret=7c74de52
0009:RET
WINTRUST.CryptSIPGetSignedDataMsg(0033fdb4,0033fe44,,0033fe40,0033fe4b)
retval= ret=7c74de52
sip.c:341:ret : 1, GLE : 0x0006
0009:CALL CRYPT32.CryptSIPGetSignedDataMsg() ret=60309229
0009:CALL
WINTRUST.CryptSIPGetSignedDataMsg(0033fdb4,0033fe44,,0033fe40,0033fe4b)
ret=7c74de52
0009:RET WINTRUST.CryptSIPGetSignedDataMsg() retval= ret=7c74de52
0009:RET
CRYPT32.CryptSIPGetSignedDataMsg(0033fdb4,0033fe44,,0033fe40,0033fe4b)
retval= ret=60309229
sip.c:344:ret : 1, GLE : 0x0006
(Both traces lack of information about the first calls as it's done
directly to a function pointer).
I will keep investigating.
Cheers,
Paul.
Re: crypt32: remove 'recursive registry key delete' function
On 6/1/07, Stefan Leichter <[EMAIL PROTECTED]> wrote: ChangeLog - replace CRYPT_RecurseDeleteKey with RegDeleteTreeW Hi Stefan, I don't think that's enough. There's a difference between SHDeleteKeyW and RegDeleteTreeW (see also http://wiki.winehq.org/RecursiveRegistryKeyDelete, but I guess that's a known page to you). Basically you have to remove the key itself as well. Cheers, Paul.
Re: Wine on FreeBSD (Was: Re: How to determine if something is "debuggable" ... ?)
On Saturday 02 June 2007 08:07:48 Marc G. Fournier wrote: > --On Saturday, June 02, 2007 05:28:31 + "L. Rahyen" > > I'm pretty sure he is. There is problems with FreeBSD that needs to be > > resolved by FreeBSD community - i.e. by people who knows FreeBSD and have > > time, will and neccessary skills to help. Problems will never resolve > > magically themself. Unfortunatelly most (all?) Wine developers know > > little > or > > nothing about FreeBSD and cannot solve these problems. And I know nothing > > about FreeBSD too - I even never used it... You may want to search for > > FreeBSD related bugs in bugzilla to understand current problems with Wine > > and FreeBSD better. > > Well, it kind of works both ways ... one has to know what the problem if > with wine under FreeBSD before one can provide a 'FreeBSD solution' to it > :( Right. And it's not as if we didn't try. Just two days ago, I've sent the following email to the freebsd-hackers mailing list: http://lists.freebsd.org/pipermail/freebsd-hackers/2007-May/020761.html So far I've received one response, telling me to contact the ports maintainer. I haven't followed up on this yet, but being a maintainer for a couple of RPMs myself, I know that just being the maintainer doesn't mean I know how to fix the source code of the package I maintain. I was kind of hoping for some FreeBSD developers who know the memory management of their OS to at least offer some pointers on where to look. Didn't happen so far. As I said in my email, I'm really happy to provide the Wine side of things for this bug, but I don't feel like doing the FreeBSD research. I don't use FreeBSD and my time is limited. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://us1.samba.org/samba/team/ -- Will code for cotton. pgpA5N9LW54oA.pgp Description: PGP signature
Re: wordpad: (1/6) Split code into set_caption function
Alexander Nicolaysen Sørnes wrote:
This will be useful for the file saving code.
Regards,
Alexander N. Sørnes
+WCHAR wszCaption[MAX_PATH];
+
+if(wszNewFileName)
+{
+lstrcpyW(wszCaption, wszNewFileName);
+lstrcatW(wszCaption, wszSeparator);
+lstrcatW(wszCaption, wszAppTitle);
Looks like there are possible buffer overflow
