Ge van Geldorp wrote:
+SPEC_SRC32 = $(BASEMODULE).spec +SPEC_SRC64 ?= $(SPEC_SRC32)
Not sure we want seperate spec files. In any case, ?= doesn't look portable.
-ULONG WINAPI MAPILogon(ULONG uiparam, LPSTR profile, LPSTR password, +ULONG WINAPI MAPILogon(ULONG_PTR uiparam, LPSTR profile, LPSTR password, FLAGS flags, ULONG reserved, LPLHANDLE session)
--- programs/wordpad/wordpad.c 14 Feb 2006 16:48:40 -0000 1.1 +++ programs/wordpad/wordpad.c 19 Jun 2006 17:34:48 -0000
I thought I already fixed these... I don't think these will apply to the current git tree.
--- dlls/ntdll/tests/generated.c 3 Jul 2005 11:23:30 -0000 1.23 +++ dlls/ntdll/tests/generated.c 19 Jun 2006 17:20:17 -0000
You should be changing tools/winapi/winapi_test*, not the generated files.
The heap changes look useful, I will check them out when I get back from my holiday.
Mike
From: Mike McCormack [mailto:mike@codeweavers.com]
Ge van Geldorp wrote:
+SPEC_SRC32 = $(BASEMODULE).spec +SPEC_SRC64 ?= $(SPEC_SRC32)
Not sure we want seperate spec files. In any case, ?= doesn't look portable.
I don't want them either, but I didn't see another option. 32-bit doesn't export Get/SetWindowLongPtrA/W and GetSetClassLongPtrA/W (they are just #defines in winuser.h), while 64-bit has to export them. Is there a portable solution to set a Make variable only when it doesn't have a value yet?
I thought I already fixed these... I don't think these will apply to the current git tree.
Changes are against current CVS.
--- dlls/ntdll/tests/generated.c 3 Jul 2005 11:23:30
-0000 1.23
+++ dlls/ntdll/tests/generated.c 19 Jun 2006 17:20:17 -0000
You should be changing tools/winapi/winapi_test*, not the generated files.
Except that dlls/ntdll/tests/generated.c was hand-modified.
Thanks for your comments, Gé.
Ge van Geldorp wrote:
I don't want them either, but I didn't see another option. 32-bit doesn't export Get/SetWindowLongPtrA/W and GetSetClassLongPtrA/W (they are just #defines in winuser.h), while 64-bit has to export them. Is there a portable solution to set a Make variable only when it doesn't have a value yet?
Is there any problem with just exporting them in win32 also? Last time I talked to Alexandre about this, I think that was the conclusion that was reached.
I thought I already fixed these... I don't think these will apply to the current git tree.
Changes are against current CVS.
I think you're a bit behind the times:
http://cvs.winehq.org/cvsweb/wine/dlls/mapi32/mapi32_main.c.diff?r1=1.13&... http://cvs.winehq.org/cvsweb/wine/dlls/user/user32.spec.diff?r1=1.114&r2...
Except that dlls/ntdll/tests/generated.c was hand-modified.
That would explain the rather large diff that I saw when I regenerated these tests :/
Mike
From: Mike McCormack [mailto:mike@codeweavers.com]
I think you're a bit behind the times:
http://cvs.winehq.org/cvsweb/wine/dlls/mapi32/mapi32_main.c.diff?r1=1.13&... 1.14
http://cvs.winehq.org/cvsweb/wine/dlls/user/user32.spec.diff?r1=1.114&r2... 15
Indeed... Being on the European side of the ocean, I used the rhlx01.fht-esslingen.de mirror. Seems it's no longer up-to-date. Apparently, it has been removed from http://www.winehq.org/site/cvs too. Time to make the switch to git I guess.
Gé.
From: Mike McCormack [mailto:mike@codeweavers.com]
Except that dlls/ntdll/tests/generated.c was hand-modified.
That would explain the rather large diff that I saw when I regenerated these tests :/
Sorry, I mixed up two files :( I have no evidence that dlls/ntdll/tests/generated.c was hand-modified (dlls/oleaut32/oaidl_p.c, another file for which I sent a patch, was). After updating to current git I saw that you already changed tools/winapi/tests.dat, but it seems the tests were not regenerated (so the dlls/*/tests/generated.c files are out of sync). Should I send a patch with the regenerated files or is it easier if Alexandre just runs tools/winapi/winapi_test?
Gé van Geldorp.
-
Ge van Geldorp -
Mike McCormack