Re: Broken cross-build, again.
On Wed, 2005-02-09 at 05:54, Paul Millar wrote: On Friday 04 February 2005 22:14, Stefan Leichter wrote: the attached patch fixes the build problem for me. Thanks, Stefan, that seems to have fixed the problem. Test-build worked correctly, so the next production build cycle should be us back in business again. Cheers, Paul. Am Freitag, 4. Februar 2005 16:30 schrieb Paul Millar: Just a head's up that the new tests broken cross-building winetest.exe. The gory details are reproduced below. I'm afraid I'm away for a long weekend, without net access, so can't fix any until I'm back (Wednesday). Hi, the new build is there, but no shlwapi-tests. Cheers, Paul.
Re: x86_64 multilib configure fix
Alex Woods [EMAIL PROTECTED] writes: Changelog: * configure.ac: Alex Woods [EMAIL PROTECTED] Handle host_cpu of x86_64 like other x86s. This will break the 64-bit build. -- Alexandre Julliard [EMAIL PROTECTED]
Re: rsaenh: CPGetProvParam's PP_ENUMCONTAINERS
Michael Jung [EMAIL PROTECTED] writes: Changelog: Implemented CPGetProvParam's PP_ENUMCONTAINERS parameter type Added corresponding test Removed some tabs that slipped in with the last patch The test fails for me: rsaenh.c:1383: Test failed: 0103 rsaenh.c:1391: Test failed: 0, 0103 -- Alexandre Julliard [EMAIL PROTECTED]
Re: More complete stubs for DuplicateTokenEx and NtAdjustPrivilegesToken
Dmitry Timoshkov wrote: Hello, Changelog: Dmitry Timoshkov [EMAIL PROTECTED] More complete stubs for DuplicateTokenEx and NtAdjustPrivilegesToken. I have an even more complete patch for this that implements the necessary server calls. Alexandre, please don't apply. Rob
Re: x86_64 multilib configure fix
On Wed, Feb 09, 2005 at 01:38:21PM +0100, Alexandre Julliard wrote: Alex Woods [EMAIL PROTECTED] writes: Changelog: * configure.ac: Alex Woods [EMAIL PROTECTED] Handle host_cpu of x86_64 like other x86s. This will break the 64-bit build. Unfortunately, the 64-bit build doesn't seem to build for me at all, but I can see how my previous patch might affect it. Hopefully this one treads on less toes. Index: configure.ac === RCS file: /home/wine/wine/configure.ac,v retrieving revision 1.338 diff -u -p -r1.338 configure.ac --- configure.ac28 Jan 2005 14:13:08 - 1.338 +++ configure.ac9 Feb 2005 13:39:07 - @@ -42,6 +42,7 @@ fi dnl Check for some programs AC_CANONICAL_HOST +build_host_cpu=$host_cpu case $host in x86_64*linux*) if test x$enable_win64 != xyes @@ -49,6 +50,7 @@ case $host in test -n $CC || CC=gcc -m32 test -n $LD || LD=ld -m elf_i386 test -n $AS || AS=as --32 + build_host_cpu=i386 fi ;; esac @@ -977,7 +979,7 @@ case $host_os in AC_SUBST(LDEXECFLAGS,[-Wl,--export-dynamic]) fi -case $host_cpu in +case $build_host_cpu in *i[[3456789]]86*) AC_CACHE_CHECK([whether we can relocate the executable to 0x77f0], ac_cv_ld_reloc_exec, [WINE_TRY_CFLAGS([-Wl,--section-start,.interp=0x77f00400], @@ -1072,7 +1074,7 @@ esac case $host_os in linux*) -case $host_cpu in +case $build_host_cpu in *i[[3456789]]86*) AC_SUBST(WINE_BINARIES,wine-glibc wine-kthread wine-pthread wine-preloader) ;; *) AC_SUBST(WINE_BINARIES,wine-glibc wine-kthread wine-pthread) ;; esac @@ -1453,7 +1455,7 @@ AC_CHECK_MEMBERS([struct stat.st_blocks] dnl *** check for the need to define platform-specific symbols -case $host_cpu in +case $build_host_cpu in *i[[3456789]]86*) WINE_CHECK_DEFINE([__i386__]) ;; *alpha*) WINE_CHECK_DEFINE([__ALPHA__]) ;; *sparc*) WINE_CHECK_DEFINE([__sparc__]) ;;
Re: rsaenh: CPGetProvParam's PP_ENUMCONTAINERS
On Wednesday 09 February 2005 13:38, Alexandre Julliard wrote:
The test fails for me:
rsaenh.c:1383: Test failed: 0103
rsaenh.c:1391: Test failed: 0, 0103
It doesn't fail for me on a clean .wine directory and a fresh wine cvs
install. I've attached a modified version of the patch with some added
tracing code. If you find a minute, could you please try it and send me a
'crypt' debug channel trace? Do not apply this patch to cvs, please.
Thanks,
--
Michael Jung
[EMAIL PROTECTED]
Index: dlls/rsaenh/rsaenh.c
===
RCS file: /home/wine/wine/dlls/rsaenh/rsaenh.c,v
retrieving revision 1.20
diff -u -r1.20 rsaenh.c
--- dlls/rsaenh/rsaenh.c31 Jan 2005 11:28:41 - 1.20
+++ dlls/rsaenh/rsaenh.c9 Feb 2005 14:13:24 -
@@ -119,6 +119,7 @@
DWORDdwFlags;
DWORDdwPersonality;
DWORDdwEnumAlgsCtr;
+DWORDdwEnumContainersCtr;
CHAR szName[MAX_PATH];
CHAR szProvName[MAX_PATH];
HCRYPTKEYhKeyExchangeKeyPair;
@@ -977,6 +978,31 @@
pKeyContainer-dwPersonality = RSAENH_PERSONALITY_STRONG;
}
}
+
+/* The new key container has to be inserted into the CSP immediately
+ * after creation to be available for CPGetProvParam's
PP_ENUMCONTAINERS. */
+if (!(dwFlags CRYPT_VERIFYCONTEXT)) {
+BYTE szRSABase[MAX_PATH];
+HKEY hRootKey, hKey;
+LONG lResult;
+
+sprintf(szRSABase, RSAENH_REGKEY, pKeyContainer-szName);
+
+if (pKeyContainer-dwFlags CRYPT_MACHINE_KEYSET) {
+hRootKey = HKEY_LOCAL_MACHINE;
+} else {
+hRootKey = HKEY_CURRENT_USER;
+}
+
+lResult = RegCreateKeyExA(hRootKey, szRSABase, 0, NULL,
+REG_OPTION_NON_VOLATILE, 0, NULL, hKey, NULL);
+if (lResult == ERROR_SUCCESS) {
+RegCloseKey(hKey);
+} else {
+WARN(Failed to create new key container registry key:
+ %08lx\n, lResult);
+}
+}
}
return hKeyContainer;
@@ -1862,10 +1888,10 @@
} else if (GET_ALG_TYPE(pCryptKey-aiAlgid) == ALG_TYPE_STREAM) {
encrypt_stream_impl(pCryptKey-aiAlgid, pCryptKey-context, pbData,
*pdwDataLen);
} else if (GET_ALG_TYPE(pCryptKey-aiAlgid) == ALG_TYPE_RSA) {
- if (pCryptKey-aiAlgid == CALG_RSA_SIGN) {
- SetLastError(NTE_BAD_KEY);
- return FALSE;
- }
+if (pCryptKey-aiAlgid == CALG_RSA_SIGN) {
+SetLastError(NTE_BAD_KEY);
+return FALSE;
+}
if (dwBufLen pCryptKey-dwBlockLen) {
SetLastError(ERROR_MORE_DATA);
return FALSE;
@@ -1982,10 +2008,10 @@
} else if (GET_ALG_TYPE(pCryptKey-aiAlgid) == ALG_TYPE_STREAM) {
encrypt_stream_impl(pCryptKey-aiAlgid, pCryptKey-context, pbData,
*pdwDataLen);
} else if (GET_ALG_TYPE(pCryptKey-aiAlgid) == ALG_TYPE_RSA) {
- if (pCryptKey-aiAlgid == CALG_RSA_SIGN) {
- SetLastError(NTE_BAD_KEY);
- return FALSE;
- }
+if (pCryptKey-aiAlgid == CALG_RSA_SIGN) {
+SetLastError(NTE_BAD_KEY);
+return FALSE;
+}
encrypt_block_impl(pCryptKey-aiAlgid, pCryptKey-context, pbData,
pbData, RSAENH_DECRYPT);
if (!unpad_data(pbData, pCryptKey-dwBlockLen, pbData, pdwDataLen,
dwFlags)) return FALSE;
Final = TRUE;
@@ -2717,6 +2743,9 @@
KEYCONTAINER *pKeyContainer;
PROV_ENUMALGS provEnumalgs;
DWORD dwTemp;
+BYTE szRSABase[MAX_PATH];
+HKEY hKey, hRootKey;
+LONG lResult;
/* This is for dwParam 41, which does not seem to be documented
* on MSDN. IE6 SP1 asks for it in the 'About' dialog, however.
@@ -2763,7 +2792,53 @@
case PP_KEYX_KEYSIZE_INC:
dwTemp = 8;
return copy_param(pbData, pdwDataLen, (CONST BYTE*)dwTemp,
sizeof(dwTemp));
-
+
+case PP_ENUMCONTAINERS:
+if ((dwFlags CRYPT_FIRST) == CRYPT_FIRST)
pKeyContainer-dwEnumContainersCtr = 0;
+
+if (!pbData) {
+*pdwDataLen = (DWORD)MAX_PATH + 1;
+return TRUE;
+}
+
+sprintf(szRSABase, RSAENH_REGKEY, );
+
+if (dwFlags CRYPT_MACHINE_KEYSET) {
+hRootKey = HKEY_LOCAL_MACHINE;
+} else {
+hRootKey = HKEY_CURRENT_USER;
+}
+
+lResult = RegOpenKeyExA(hRootKey, szRSABase, 0, KEY_READ, hKey);
+if (lResult != ERROR_SUCCESS)
+{
+WARN(Failed to open CSP registry key: %08lx\n, lResult);
+SetLastError(ERROR_NO_MORE_ITEMS);
+return FALSE;
+}
+
+dwTemp
Re: Re: winrash bug
Oh, that's mostly because I was lazy. I'm pretty sure the text says that if you are on windows95 you should install winsock2. I'm not sure how to detect whether the user needs to install winsock2 or not by looking at dlls. I was planning on adding detection of the windows version and using that as a way of narrowing down who sees the winsock prompt. That doesn't address which version of winsock the user has installed though... I'll put in the windows version check so only 95 users see the winsock2 prompt since thats pretty easy. Chris From: Ivan Leo Puoti [EMAIL PROTECTED] Date: 2005/02/08 Tue PM 02:11:29 EST To: [EMAIL PROTECTED] CC: wine-devel@winehq.com Subject: Re: winrash bug Chris Morgan wrote: Is this based on what the installer displays or upon output from winrash in the debug.txt file? It is based on the installer telling me I'm on windows 95 and that I must install the winsock2 update for windows 95. Ivan.
Re: IDC_RIGHT, IDC_CENTER not defined ?
George Ginden wrote: George Ginden ha scritto: OK I'm trying to implement text alignment in the edit control. Now, one question how do I know (in the EDIT_WM_NCCreate for example) if the text alignment has been requested by the programmer ? Nevermind, I've figured it out. Now I need to set the caret position within the edit control... Something which converts x,y coords to the column would be cool... Eg: text is at x offset, and the cursor position should be updated as well... EDIT_SetCaretPosition at x, y ... Regards. If you use GetCharacterPlacement (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_4l84.asp), you will get the following: 1. A list of pixel offsets for each character. 2. Caret position. 3. For future BiDi support - logical to visual mapping. I.e. - the next character logically is three characters down visually. Please consider using it, so as my task (when I finally get to it, sigh) will be easier. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
Re: Broken cross-build, again.
On Wed, 2005-02-09 at 16:59, Paul Millar wrote: I haven't worked on any of winetest's innards, so this is largely guess work... On Wednesday 09 February 2005 13:22, you wrote: If I run winetest-200502091000-paul-mingw manually on my win98 box I get several messages Can't parse subtests output of for the following tests [...] just before the tests actually start. My guess is that winetest is attempting to run these tests, but that they are dying straight away, with some error message. This error message is not the expected output, hence the error messsage. [...] Does this mean that we have a deeper lying problem? Yes, obviously! The tests are failing and we have no mechanism for detecting this. This, in itself, is a bug. Or just that more tests are somehow not correct (in combination with mingw)? I've bundled the individual tests in: http://www.astro.gla.ac.uk/users/paulm/WRT/winetest-bin-20050209.zip (its some 2.6MiB in size, though) I image you should be able to run the shlwapi test individually, which should help narrow down the cause. HTH, Paul. Hi Paul, I've included wine-devel again as this must touch others as well. I wasn't able to run the shlwapi tests on my win98 box, by itself. Running this gives an error box: The SHLWAPI_.EXE file is linked to missing export SHLWAPI.DLL:PathIsValidCharA and just for completeness sake: dsound: ... linked to missing export DSOUND.DLL:DirectSoundCreate8 mlang: ... linked to missing export NTDLL.DLL:atoi msvcrtd: A required .DLL, MSVCRTD.DLL, was not found ole32: ... linked to missing export NTDLL.DLL:atoi Cheers, Paul Vriens.
Re: Broken cross-build, again.
If I run winetest-200502091000-paul-mingw manually on my win98 box I get several messages Can't parse subtests output of for the following tests [...] just before the tests actually start. In the first round winetest runs all the individual test executables to find out the names of subtests they contain. In case of a failure it obiously has no way to run those tests, so they are skipped. You have the freedom the run the problematic executables manually and find out more. Winetest could be massaged to include the unparsable output in the report, but it didn't seem worth it, as most of the time it means that the test doesn't apply for the given system (no such DLL installed). -- Feri.
Re: Real-world appdb
A Wine FAQ at the forefront of the appdb, or even linked to each application's overview page might be nice, too, for more general issues like the above comment-- an explanation of basic procedures such as exporting/importing registry entries, what common errors mean, like the Warning: The specified Windows directory LC:\\Windows is not accessible error and what to do about it, why not to get all freaked out by seeing fixmes, and simple statements like the fact that some programs will run fine with wine /path/to/app.exe, but some will fail that way with very scary looking errors, but will run fine if one first cds to /path/to/ and then runs wine app.exe. This kind of thing is often something new Wine users don't know, but is a very simple way to eliminate possible vectors of error before going to any mailing list or forum with problems, and may eliminate the need for a user to ask for help at all (as the program works when started in the alternate manner). [FIXED] I sent a patch that add and updates the content of the current FAQs and help topics. You find a link to this documentation on the right menu. Currently you have both Help Support and Documentation , but the patch I sent removes one of these two links and adds a link called Help Documentation which contains FAQ, explanation on how to run Windows application under wine (you might want to add some entries here) and also informatons about what a maintainer/supermaintainer is and what he is expected to do. Best regards, Jonathan signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Broken cross-build, again.
On Wednesday 09 February 2005 16:57, Ferenc Wagner wrote: In the first round winetest runs all the individual test executables to find out the names of subtests they contain. In case of a failure it obiously has no way to run those tests, so they are skipped. You have the freedom the run the problematic executables manually and find out more. To me it seems silly to blanket accept broken programs. Known exclusions could be catered for such as ntdll tests on a W95 box (those fail, right?) either client-side (i.e. within winetest.exe) or server-side. The current situation supposes that the person debugging the problem has access to the Win box that generated the fault, and so can recreate the problem by running the original xxx_test.exe executable. By reporting back the error, someone can fix it without needing the specific version of Win98 that demonstrated the error. Paul (just my 2 euro-cent worth ;^) pgpuYfsaRuGbd.pgp Description: PGP signature
Re: Rearrange WINPROC_CallWndProc to give clearer tracing
Mike Hearn [EMAIL PROTECTED] writes:
ChangeLog:
Rearrange WINPROC_CallWndProc to give clearer tracing
--- windows/winproc.c (revision 132)
+++ windows/winproc.c (local)
@@ -408,20 +408,25 @@ static LRESULT WINPROC_CallWndProc( WNDP
{
LRESULT retvalue;
int iWndsLocks;
+char msgname[1024];
You don't want to do that, window procs can be nested quite deeply.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [Discuss] Recycle Bin problem with Preclick image editing software
On Wed, 2005-02-09 at 15:34 -0500, Don Feliciano wrote: SUCCESS! Woo Hoo! You rock... now my wife can't tell me b*tch at me for ditching Windows. Thanks a ton. Niceness Don. Of course, it'd rock more if this had worked out of the box. I expect we're missing some shell magic for the recycle bin. Wouldn't be hard to investigate but have a million other things to do so I'll CC this to wine-devel. Context is: app has a send to recycle bin option to delete photos. Doesn't work. Native shell32/shfolder fixes it. If anybody is up for what is probably an easy task, figure out why and fix it so c:\Recycled is used. For bonus points we should bridge it to KDE/GNOME so if an app recycles something it appears in your actual trash can :) thanks -mike
Re: Rearrange WINPROC_CallWndProc to give clearer tracing
Mike Hearn [EMAIL PROTECTED] writes: Yes, I realised the stack allocation might be a problem but only a while after I sent the patch. Here's another that uses the heap. I don't think you want that either, it won't really make things less confusing if you are adding extra heap calls. You may want to look into using RelayFromExclude instead. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Rearrange WINPROC_CallWndProc to give clearer tracing
On Wed, 09 Feb 2005 22:24:39 +0100, Alexandre Julliard wrote: I don't think you want that either, it won't really make things less confusing if you are adding extra heap calls. You may want to look into using RelayFromExclude instead. Well, the key thing is that they occur before the trace. I don't really mind what happens before the Call window proc line, it's when there are calls that look like they are coming from the app actually aren't. RelayFromExclude works but needs fiddling and more to the point, you have to know to do it for this particular case. I'd like to make the traces less confusing by default as part of chipping away at the learning curve. Also a heap allocation is just an RtlAllocateHeap, I looked at the trace with the new patch and it is still less confusing IMHO. thanks -mike
Re: Broken cross-build, again.
Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens: On Wed, 2005-02-09 at 16:59, Paul Millar wrote: [snip] Hi Paul, I've included wine-devel again as this must touch others as well. I wasn't able to run the shlwapi tests on my win98 box, by itself. Running this gives an error box: The SHLWAPI_.EXE file is linked to missing export SHLWAPI.DLL:PathIsValidCharA and just for completeness sake: dsound: ... linked to missing export DSOUND.DLL:DirectSoundCreate8 mlang: ... linked to missing export NTDLL.DLL:atoi msvcrtd: A required .DLL, MSVCRTD.DLL, was not found ole32: ... linked to missing export NTDLL.DLL:atoi Cheers, Paul Vriens. Hello, mlang.dll and ole32.dll can be linked against msvcrt.dll insted of ntdll (like in the attached patch). Will this cause problems? Bye Stefan PS: Is someone working on a fix for the missing import of shlwapi.dll? If nobody 'complains' I will make a patch tomorrow evening --- ../wine/dlls/mlang/tests/Makefile.in 2004-08-04 20:33:06.0 +0200 +++ dlls/mlang/tests/Makefile.in 2005-02-09 22:37:02.0 +0100 @@ -3,7 +3,7 @@ SRCDIR= @srcdir@ VPATH = @srcdir@ TESTDLL = mlang.dll -IMPORTS = ole32 gdi32 kernel32 ntdll +IMPORTS = ole32 gdi32 kernel32 msvcrt EXTRALIBS = -luuid CTESTS = \ --- ../wine/dlls/ole32/tests/Makefile.in 2004-12-21 15:51:27.0 +0100 +++ dlls/ole32/tests/Makefile.in 2005-02-09 22:36:41.0 +0100 @@ -3,7 +3,7 @@ SRCDIR= @srcdir@ VPATH = @srcdir@ TESTDLL = ole32.dll -IMPORTS = oleaut32 ole32 user32 kernel32 ntdll +IMPORTS = oleaut32 ole32 user32 kernel32 msvcrt EXTRALIBS = -luuid CTESTS = \
Re: [wine] Re: [Discuss] Recycle Bin problem with Preclick image editing software
On Wed, Feb 09, 2005 at 09:00:10PM +, Mike Hearn wrote: Niceness Don. Of course, it'd rock more if this had worked out of the box. I expect we're missing some shell magic for the recycle bin. Wouldn't be hard to investigate but have a million other things to do so I'll CC this to wine-devel. Context is: app has a send to recycle bin option to delete photos. Doesn't work. Native shell32/shfolder fixes it. If anybody is up for what is probably an easy task, figure out why and fix it so c:\Recycled is used. For bonus points we should bridge it to KDE/GNOME so if an app recycles something it appears in your actual trash can :) comment in dlls/shell32/shlfileop.c says: unimplemented and break if any other flag set: FOF_ALLOWUNDO, FOF_WANTMAPPINGHANDLE. FOF_ALLOWUNDO = 0x40 is the flag that says to use the Recycle Bin, if available. Note that Windows itself doesn't use the recycle bin on network drives or removable disks. Probably some extra logic could be added around line 1085 to issue a 'rename' (or MoveFileEx) call in either of the following situations: 1. The file is under the user's home directory; move it to ~/Desktop/Trash or ~/.gnome-desktop/Trash 2. The file is on a VFAT partition; move it to $(MOUNT_POINT)/Recycled However, the app in question is probably upset about something else, and there are still some stub functions in that file, so I doubt that a correct Recycle Bin is first-priority for the Wine team. -- David Lee Lambert (also [EMAIL PROTECTED])cell ph# 586-873-8813 PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey resume at http://www.cse.msu.edu/~lamber45/resume.htm
Re: rsaenh: CPGetProvParam's PP_ENUMCONTAINERS
Michael Jung [EMAIL PROTECTED] writes: On Wednesday 09 February 2005 13:38, Alexandre Julliard wrote: The test fails for me: rsaenh.c:1383: Test failed: 0103 rsaenh.c:1391: Test failed: 0, 0103 It doesn't fail for me on a clean .wine directory and a fresh wine cvs install. I've attached a modified version of the patch with some added tracing code. If you find a minute, could you please try it and send me a 'crypt' debug channel trace? Do not apply this patch to cvs, please. It turned out to be the wrong access rights in the RegCreateKeyEx call. You don't see the problem if you are running with version set to win9x since access rights are ignored then. I have fixed it and committed the patch. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Broken cross-build, again.
On Wednesday 09 February 2005 21:55, Stefan Leichter wrote: Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens: mlang: linked to missing export NTDLL.DLL:atoi [...] ole32: linked to missing export NTDLL.DLL:atoi mlang.dll and ole32.dll can be linked against msvcrt.dll insted of ntdll (like in the attached patch). Will this cause problems? Yes, and no. If msvcrt.dll is available then this will solve the problem. But (from vague memories) although msvcrt is available for W95/98, its by no means installed by default. On Paul's machine, the msvcrt-specific tests are failing due to a lack of that DLL. Really, someone should write a simple atoi() implementation and the tests link against the portable code. This can't take more than ten minutes, right? Cheers, Paul. pgprcAlNZ8Fff.pgp Description: PGP signature
Re: [Discuss] Recycle Bin problem with Preclick image editing software
Hi, On Wed, 2005-02-09 at 16:00, Mike Hearn wrote: Context is: app has a send to recycle bin option to delete photos. Doesn't work. Native shell32/shfolder fixes it. If anybody is up for what is probably an easy task, figure out why and fix it so c:\Recycled is used. I've looked in to this a bit and been wanting to implement it for ReactOS. We need to implement some of the SHQuery* functions in shell32. I have a bunch of command apps that use these shell32 apis to talk to the Recycle bin. For bonus points we should bridge it to KDE/GNOME so if an app recycles something it appears in your actual trash can :) The problem is the FreeDesktop.org Trashcan spec is just a draft and I don't know how properly the major desktops follow it...if at all at this point. Thanks Steven
