Re: xfs getting case-insensitive filesystem support...
Joerg Mayer [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 08:39:40PM -0700, Dan Kegel wrote: Hrm. This is interesting: http://lwn.net/Articles/278961/ I wonder if Wine could run faster if it could delegate the case-insensitvity to the filesystem... Would be nice indeed, but I don't think it will come: Linus shot down similar patches in the past because to_lower may be easy to implement for ascii, but once you want to implement it for all charsets supported by the files system it gets very messy. Sure, it's messy until the filesystem is unicode internally, and uses something more reasonable instead of a multibyte UTF-8. -- Dmitry.
Re: xfs getting case-insensitive filesystem support...
On Thu, Apr 24, 2008 at 03:05:51PM +0900, Dmitry Timoshkov wrote: Joerg Mayer [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 08:39:40PM -0700, Dan Kegel wrote: Hrm. This is interesting: http://lwn.net/Articles/278961/ I wonder if Wine could run faster if it could delegate the case-insensitvity to the filesystem... Would be nice indeed, but I don't think it will come: Linus shot down similar patches in the past because to_lower may be easy to implement for ascii, but once you want to implement it for all charsets supported by the files system it gets very messy. Sure, it's messy until the filesystem is unicode internally, and uses something more reasonable instead of a multibyte UTF-8. Unix filesystems treat filenames as byte-strings, this is 100% reasonable :-) Any conversion to glygps isn't a filesyatem operation. David -- David Laight: [EMAIL PROTECTED]
Re: imm32: If ImmNotifyIME fails, ImmSetOpenStatus should also fail.
Kusanagi Kouichi wrote:
if (!fOpen != !data-IMC.fOpen)
{
+if (!ImmNotifyIME( hIMC, NI_CONTEXTUPDATED, 0, IMC_SETOPENSTATUS))
+return FALSE;
data-IMC.fOpen = fOpen;
-ImmNotifyIME( hIMC, NI_CONTEXTUPDATED, 0, IMC_SETOPENSTATUS);
ImmInternalSendIMENotify(data, IMN_SETSENTENCEMODE, 0);
Hi,
MS Windows's native imm32.dll return TRUE although NotifyIME return
FALSE. I have tested it with the DDK's Japanese FakeIME.
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Wed, Apr 23, 2008 at 9:45 PM, Steven Edwards [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 12:33 AM, Steven Edwards [EMAIL PROTECTED] wrote: Your right, I thought it was loaded yet but I guess it does anytime user32 is initalized. Looking at the process list after the messagebox exits only wineserver, services and winedevice stay resident for a while so I thought it had not loaded yet. I'll see if I can rework it to send a message to explorer to display the dialog. You were right. Looking at it a bit more maybe the best route is to add a set of custom messages to user32 and explorer maybe something like WM_WINE_DLLNOTFOUND/WM_WINE_MISSINGFUCTION or something and manually do the server call using send_message. I am not exactly sure how to do it as the actual wineserver call yet. I'll look at it a bit more tomorrow and see if I can figure the plumbing out. Alternately we could cheeze it and exec xmessage :-)
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
Steven Edwards [EMAIL PROTECTED] writes: On Wed, Apr 23, 2008 at 11:14 PM, Dan Kegel [EMAIL PROTECTED] wrote: Why not? I thought Explorer was the first thing to start up... Your right, I thought it was loaded yet but I guess it does anytime user32 is initalized. Looking at the process list after the messagebox exits only wineserver, services and winedevice stay resident for a while so I thought it had not loaded yet. I'll see if I can rework it to send a message to explorer to display the dialog. You certainly don't want to call through explorer for that, showing a message box directly is fine. You have to be careful to only do it when loading the main exe, not for any random dll load; also you have to properly handle the case of a missing X display. -- Alexandre Julliard [EMAIL PROTECTED]
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Thu, Apr 24, 2008 at 2:36 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: You certainly don't want to call through explorer for that, showing a message box directly is fine. Well, that's easier :-) You have to be careful to only do it when loading the main exe, not for any random dll load Yeah, I guess some apps tolerate missing DLLs by loading them manually. We'll miss a few problems (e.g. apps that delay-load but can't handle the missing dll) but that's ok. also you have to properly handle the case of a missing X display right, and just not call MessageBox. Hmm, ideally we would send them to a web page that gave information tailored to the dll in question, but a MessageBox is good enough for 1.0.
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Thu, Apr 24, 2008 at 4:50 AM, Dan Kegel [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 2:36 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: You certainly don't want to call through explorer for that, showing a message box directly is fine. Well, that's easier :-) You have to be careful to only do it when loading the main exe, not for any random dll load Yeah, I guess some apps tolerate missing DLLs by loading them manually. We'll miss a few problems (e.g. apps that delay-load but can't handle the missing dll) but that's ok. also you have to properly handle the case of a missing X display right, and just not call MessageBox. Hmm, ideally we would send them to a web page that gave information tailored to the dll in question, but a MessageBox is good enough for 1.0. A link to a wiki page (http://wiki.winehq/MissingDLL ?) with list of common dlls/where they come from/what they do/how to use winetricks/etc.) would be a bit easier/quicker to implement.
Re: mshtml #5: Added more IDispatchEx tests.
Jacek Caban [EMAIL PROTECTED] writes: dlls/mshtml/tests/dom.c | 56 +++ 1 files changed, 37 insertions(+), 19 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so dom.c touch dom.ok dom.c:1381: Test failed: GetTypeInfo failed: 8002802b dom.c:1394: Test failed: GetTypeInfo failed: 8002802b make[2]: *** [dom.ok] Error 2 -- Alexandre Julliard [EMAIL PROTECTED]
Re: [3/4] user32: Set the vkey value to VK_PROCESSKEY when IME process key.
Thank you for these investigations This is really nice. I support those
patches.
I just wanted to also communicate a bit of additional information from
my investigations just in case someone asks. I placed hooks on both
WH_KEYBOARD_LL and WH_KEYBOARD. Even when the IME is active both of
those hooks showed the VKEY of the actual keystroke.
This showed me that all of this processing happened after
process_keyboard_message.
great work and thanks,
-aric
ByeongSik Jeon wrote:
When the MS Windows set the vkey value(MSG.wParam) to VK_PROCESSKEY?
I have tested following code:
while ( GetMessage(msg, 0, 0, 0) ) {
if ( msg.message == WM_KEYDOWN )
printf(OLD: %x %x %x\n, msg.message, msg.wParam, msg.lParam);
TranslateMessage( msg );
if ( msg.message == WM_KEYDOWN )
printf(NEW: %x %x %x\n, msg.message, msg.wParam, msg.lParam);
DispatchMessage( msg );
}
-
The result is:
-
OLD: 100 e5 130001
NEW: 100 e5 130001
OLD: 100 e5 250001
NEW: 100 e5 250001
OLD: 100 e5 130001
NEW: 100 e5 130001
-
e5 is VK_PROCESSKEY.
Before GetMessage, PeekMessage return, msg.wPram ahs seted to VK_PROCESSKEY.
---
dlls/user32/message.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
Re: [1/7] D3D9: Make the offscreen format test a bit more tolerant
2008/4/24 Stefan Dösinger [EMAIL PROTECTED]: FWIW, for my texop test I wrote a function to do this in a generic way. I'll probably submit that in the next few days.
Re: dinput: Limit number of supported axis and buttons
On Thu, Apr 24, 2008 at 08:06:07AM -0600, Vitaliy Margolen wrote: +FIXME(Can't support %d axis. Clamping down to 16\n, newDevice-axes); FIXME(Can't support %d axes. Clamping down to 16\n, newDevice-axes); -- cu pgpCuOEwa3C1c.pgp Description: PGP signature
Re: mshtml #5: Added more IDispatchEx tests.
Alexandre Julliard wrote: Jacek Caban [EMAIL PROTECTED] writes: dlls/mshtml/tests/dom.c | 56 +++ 1 files changed, 37 insertions(+), 19 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so dom.c touch dom.ok dom.c:1381: Test failed: GetTypeInfo failed: 8002802b dom.c:1394: Test failed: GetTypeInfo failed: 8002802b make[2]: *** [dom.ok] Error 2 mshtml.tlb needs to be rebuilt after mshtml.idl: Added DispHTMLUnknownElement declaration. patch. make depend is not enough. Thanks, Jacek
Re: winmm/tests: waveOutGetDevCaps called with invalid size
There are only two options: only pass the number of bytes requested or return an error for unreasonable sizes. What is Terminal Server doing? It's returning an error. And what is the error? If you know the error code returned, Ill add it to the code so we can end this discussion. The error is MMSYSERR_INVALPARAM. Sure, you can add the error code to the list of accepted return code, but I still don't understand the meaning of this test. You are basically testing the sound card driver, rather than the winmm subsystem. waveOutGetDevCapsW lets the driver do the copy (just like old versions of windows). The driver should be checking the size and only copying that much. If it doesn't, then it broken. Any references for this claim? Read the code. Since we are trying to follow MS, reading the Wine code doesn't really give us a hint of what MS considers valid or invalid. You are saying that the driver should only copy that much, but *what* should it copy? In other words: If the size doesn't match the size of any known structure (WAVEOUTCAPSA/WAVEOUTCAPSW/WAVEOUTCAPS2A/WAVEOUTCAPS2W), should the driver then just *assume* some structure? Which one? As far as I know, there's no guarantee that, for example, the first sizeof(WAVEOUTCAPSW) bytes of WAVEOUTCAPSW are the same as WAVEOUTCAPS2W. Again, read the code. WAVEOUTCAPS2 is a superset of WAVEOUTCAPS so it doesn't matter when the length is shorter than WAVEOUTCAPS. The drivers only support W so mixing A and W is not an issue. Are you saying that WODM_GETDEVCAPS messages are always limited to the W versions? So, drivers don't need to handle WODM_GETDEVCAPS messages with A type structs? I had no idea of that. Any reference for this? Rgds, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 LinköpingPhone: +46-13-21 46 00
Re: mshtml #5: Added more IDispatchEx tests.
Jacek Caban [EMAIL PROTECTED] writes: mshtml.tlb needs to be rebuilt after mshtml.idl: Added DispHTMLUnknownElement declaration. patch. make depend is not enough. I see, make depend needs to be fixed. I'll have a look. -- Alexandre Julliard [EMAIL PROTECTED]
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
On Thu, Apr 24, 2008 at 5:36 AM, Alexandre Julliard [EMAIL PROTECTED] wrote:
You certainly don't want to call through explorer for that, showing a
message box directly is fine. You have to be careful to only do it when
loading the main exe, not for any random dll load; also you have to
properly handle the case of a missing X display.
OK so is doing this in ntdll even the right case? I don't really see
where to do it only from the main exe. I understand we don't want to
report the error if the application is manually doing a
GetProcAddress/LoadLibrary but again don't really know how to limit
it. Here is my stab #2, it actually returns something sane to the
user.
--
Steven Edwards
There is one thing stronger than all the armies in the world, and
that is an idea whose time has come. - Victor Hugo
From a9a763015d9d4738fc9187e6d913d54cd5d6f25f Mon Sep 17 00:00:00 2001
From: Steven Edwards [EMAIL PROTECTED]
Date: Thu, 24 Apr 2008 02:21:08 -0400
Subject: [PATCH] Took a stab at graphically reporting an error when a dll was not found
---
dlls/ntdll/loader.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/dlls/ntdll/loader.c b/dlls/ntdll/loader.c
index bb8..4d37e64 100644
--- a/dlls/ntdll/loader.c
+++ b/dlls/ntdll/loader.c
@@ -464,6 +464,32 @@ static FARPROC find_named_export( HMODULE module, const IMAGE_EXPORT_DIRECTORY *
}
+FARPROC pMessageBoxW;
+static NTSTATUS report_error()
+{
+NTSTATUS nts,nts2;
+UNICODE_STRING wstr;
+ANSI_STRING str;
+HMODULE hdll;
+WCHAR user32[] = {'u','s','e','r','3','2','.','d','l','l',0};
+
+RtlInitUnicodeString( wstr, user32 );
+nts = LdrLoadDll(0, 0, wstr, hdll);
+if (nts != STATUS_SUCCESS)
+{
+ERR(couldn't load user32 to display error\n);
+return nts;
+}
+
+RtlInitAnsiString( str, MessageBoxW );
+nts2 = LdrGetProcedureAddress( hdll, str, 0, (void**)pMessageBoxW );
+if (nts2 != STATUS_SUCCESS)
+{
+ERR(Couldn't import MessageBoxW\n);
+return nts;
+}
+return nts;
+}
/*
* import_dll
@@ -514,8 +540,15 @@ static WINE_MODREF *import_dll( HMODULE module, const IMAGE_IMPORT_DESCRIPTOR *d
if (status)
{
if (status == STATUS_DLL_NOT_FOUND)
+{
+WCHAR dll_error[] = {'A',' ','r','e','q','i','u','r','e','d',' ','d','l','l',' ','w','a','s',' ','n','o','t',' ','f','o','u','n','d',0};
+NTSTATUS nts = report_error();
+if (nts == STATUS_SUCCESS)
+pMessageBoxW(NULL,dll_error,NULL,NULL);
+
ERR(Library %s (which is needed by %s) not found\n,
name, debugstr_w(current_modref-ldr.FullDllName.Buffer));
+}
else
ERR(Loading library %s (which is needed by %s) failed (error %x).\n,
name, debugstr_w(current_modref-ldr.FullDllName.Buffer), status);
--
1.5.3.7
Re: dinput: Limit number of supported axis and buttons
Christoph Frick wrote: On Thu, Apr 24, 2008 at 08:06:07AM -0600, Vitaliy Margolen wrote: +FIXME(Can't support %d axis. Clamping down to 16\n, newDevice-axes); FIXME(Can't support %d axes. Clamping down to 16\n, newDevice-axes); Thanks for catching it. Fixed patch resent. Vitaliy
Re: 1.0 idea - ntdll - add a messagebox for missing dlls
Steven Edwards [EMAIL PROTECTED] writes: On Thu, Apr 24, 2008 at 5:36 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: You certainly don't want to call through explorer for that, showing a message box directly is fine. You have to be careful to only do it when loading the main exe, not for any random dll load; also you have to properly handle the case of a missing X display. OK so is doing this in ntdll even the right case? I don't really see where to do it only from the main exe. It depends which cases you are trying to catch, but for the case of users starting an app from their desktop, you could probably do it in start.exe. -- Alexandre Julliard [EMAIL PROTECTED]
Re: SOC 2008 Projects Announced
Could the students come forward and say something about themself? Hi there I'm from Spain and I'm supposed to hack DirectPlay support up until wine can fully run at least GTA2 multiplayer out of the box, but I hope to have time enough to give some love to other dplay games. I'll try not to have too much fun in the testing phases, I promise :) I still have to get some exams done before embracing the sleepless nights of passionate coding (and/or swearing against msdn), but things are going faster than expected and I hopefully will be free of urgent duties in two or three weeks. Hope not to break anything Over and out Ismael
Re: dinput: Limit number of supported axis and buttons [try 2]
On Thu, Apr 24, 2008 at 09:04:11AM -0600, Vitaliy Margolen wrote: ok, don't beat me on this one (i guess i could have asked this also for try one): +FIXME(Can't support %d axes. Clamping down to 16\n, newDevice-axes); ... +WARN(Can't support %d buttons. Clamping down to 128\n, newDevice-buttons); why is axes a FIXME and buttons a WARN? -- cu pgp3Au79OUy5f.pgp Description: PGP signature
Call for testers
Has you may have seen, a new rendering interface is now available for Winhelp It should be better (with the last row of patches) than the old one, but still not perfect And likely not bug free, hence the call for testers I'm waiting for some real feedback from real users about reading your old .hlp files The new rendering is turned on by setting the env variable WINHELP_RICHEDIT to 1 A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: [PATCH 06/12] widl: Create a statement object for import statements.
Robert Shearman [EMAIL PROTECTED] writes: Move the writing of include directives into the generated header into header.c. This one doesn't work right, it doesn't output the #include statements so the resulting .h files don't compile. -- Alexandre Julliard [EMAIL PROTECTED]
Re: dnghelp : Fix pointer cast.
Erik de Castro Lopo wrote: Make the pointer cast safe for Wine64. Please disregard this one as there is a better patch on the way. Cheers, Erik -- - Erik de Castro Lopo - Within C++, there is a much smaller and cleaner language struggling to get out. -- Bjarne Stroustrup
Re: dinput: Limit number of supported axis and buttons [try 2]
Christoph Frick wrote: On Thu, Apr 24, 2008 at 09:04:11AM -0600, Vitaliy Margolen wrote: ok, don't beat me on this one (i guess i could have asked this also for try one): +FIXME(Can't support %d axes. Clamping down to 16\n, newDevice-axes); ... +WARN(Can't support %d buttons. Clamping down to 128\n, newDevice-buttons); why is axes a FIXME and buttons a WARN? Because default joystick data format supports up to 128 buttons. So even if Wine would be using custom data format most programs probably won't be able to use all of the buttons. At the same time there are number of extra axes left in the data format that Wine is not using. So in short - there is something that can be done to support more axes but not much about buttons. PS. I'd like to see a joystick with more then 128 buttons... Vitaliy.
Safedisc for 1.0+ ?
It has just occurred to me that safedisc copy protection (bug 219!) wasn't put on the Wine 1.0 task list. It's a pretty major bug and covers a wide range of programs, with a wide range of safedisc versions. Considering this, how should we plan for this implementation?
Re: Wine t-shirts?
Jeremy White wrote: http://kegel.com/wine/wine-penguin-corkscrew.png Jon Parshall is proud of his ability to draw those penguins, and we'd gladly send that artwork to anyone that wanted to make a T-shirt. Note, though, that we felt we had to (very sadly) drop the penguin; it doesn't really work for Mac users. Why not? There is always Yellow Dog and several Linux variants for the Mac. And I'm always for support the 'quin and have been before Slack 1.0 (yes, I'm older than dirt and proud of it!) (And I remember Wine, a long, long time ago in a galaxy far, far away (think Far East)) At one time I was a supporter and tester for Project Odin and its predecessors. James McKenzie
Re: Safedisc for 1.0+ ?
TheBlunderbuss wrote: It has just occurred to me that safedisc copy protection (bug 219!) wasn't put on the Wine 1.0 task list. It's a pretty major bug and covers a wide range of programs, with a wide range of safedisc versions. Considering this, how should we plan for this implementation? Some versions should work. Newer versions mos likely won't. But as usual in these cases your mileage may vary. Since there are so many variables. Setting target for such bugs to 1.0 won't magically fix them. Nor will it keep them from breaking. Vitaliy.
Re: user32 : Temporarily disable test for _WIN64.
Erik de Castro Lopo [EMAIL PROTECTED] wrote: The file dlls/user32/tests/edit.c currently doesn't compile when configured with --enable-win64 because GWL_WNDPROC (in include/winuser.h) is not defined when _WIN64 is defined. Then you need to fix the test instead of disabling it. -- Dmitry.
Re: shel32/tests : Use LOWORD to extract rc from pointer.
Erik de Castro Lopo [EMAIL PROTECTED] wrote:
-rc=(int)ShellExecute(NULL, operation, file, parameters, directory,
- SW_SHOWNORMAL);
+rc=LOWORD(ShellExecute(NULL, operation, file, parameters, directory,
+ SW_SHOWNORMAL));
if (rc 32)
{
@@ -167,7 +167,7 @@ static int shell_execute_ex(DWORD mask, LPCSTR operation,
LPCSTR file,
DeleteFile(child_file);
SetLastError(0xcafebabe);
success=ShellExecuteEx(sei);
-rc=(int)sei.hInstApp;
+rc=LOWORD(sei.hInstApp);
ok((success rc 32) || (!success rc = 32),
%s rc=%d and hInstApp=%d is not allowed\n, shell_call, success, rc);
@@ -836,24 +836,24 @@ static void test_find_executable(void)
/* Don't test FindExecutable(..., NULL), it always crashes */
strcpy(command, your word);
-rc=(int)FindExecutableA(NULL, NULL, command);
+rc=LOWORD(FindExecutableA(NULL, NULL, command));
ok(rc == SE_ERR_FNF || rc 32 /* nt4 */, FindExecutable(NULL) returned
%d\n, rc);
You need to change the type of rc to HINSTANCE and fix the comparisons instead.
What happens if the returned HINSTANCE has a value = 32 in its low word?
--
Dmitry.
Re: user32 : Temporarily disable test for _WIN64.
Dmitry Timoshkov wrote: Erik de Castro Lopo [EMAIL PROTECTED] wrote: The file dlls/user32/tests/edit.c currently doesn't compile when configured with --enable-win64 because GWL_WNDPROC (in include/winuser.h) is not defined when _WIN64 is defined. Then you need to fix the test instead of disabling it. In include/winuser.h we have: #if !defined _WIN64 !defined __WINESRC__ # define GWL_USERDATA(-21) # define GWL_ID (-12) # define GWL_HWNDPARENT (-8) # define GWL_HINSTANCE (-6) # define GWL_WNDPROC (-4) # define DWL_MSGRESULT 0 # define DWL_DLGPROC 4 # define DWL_USER8 #endif /* _WIN64 __WINESRC__ */ which means fixing the test requires first finding out the correct values of these defines under _WIN64. That seems a waste of effort when I'm aiming to get the simplest of WIN64 apps running, like a Hello world program that prints to stdout. Secondly, being unable to compile wine configured with --enable-win64 because of a test for code that has zero percent chance of being correct anyway seems counter productive. Erik -- - Erik de Castro Lopo - Seen on comp.lang.python: Q : If someone has the code in python for a buffer overflow, please post it. A : Python does not support buffer overflows, sorry.
Re: Add an include/config.h variable WINE_IS_WIN64 which is 1 whenconfigured with --enable-win64 and 0 otherwise.
Erik de Castro Lopo [EMAIL PROTECTED] wrote: Add an include/config.h variable WINE_IS_WIN64 which is 1 whenconfigured with --enable-win64 and 0 otherwise. It would be helpful to at least provide an explanation why yo need this, and why _WIN64 macro is not enough. -- Dmitry.
Re: ntdll : Do not error out on AMD-64 architecture when compiling win64.
Erik de Castro Lopo [EMAIL PROTECTED] wrote: +#if WINE_IS_WIN64 +if (nt-FileHeader.Machine == IMAGE_FILE_MACHINE_AMD64) +MESSAGE(Support for AMD-64 architecture in progress but not yet working\n); +else +#endif What's the point of this? -- Dmitry.
Re: Wine t-shirts?
James McKenzie [EMAIL PROTECTED] wrote: At one time I was a supporter and tester for Project Odin and its predecessors. Wow. I gave up on OS/2 Warp right from the git-go, when they shipped me 30 floppies instead of a cd-rom. I really wanted Microsoft to have competition, but I just couldn't bear the thought of going through a 30 floppy install! - Dan
Re: ntdll : Do not error out on AMD-64 architecture when compiling win64.
Dmitry Timoshkov wrote: Erik de Castro Lopo [EMAIL PROTECTED] wrote: +#if WINE_IS_WIN64 +if (nt-FileHeader.Machine == IMAGE_FILE_MACHINE_AMD64) +MESSAGE(Support for AMD-64 architecture in progress but not yet working\n); +else +#endif What's the point of this? At the moment trying to get wine to execute a win64 binary fails if nt-FileHeader.Machine != IMAGE_FILE_MACHINE_I386 This patch along with the last one which added WINE_IS_WIN64 allows an attempt to be made to execute a WIN64 binary. Erik -- - Erik de Castro Lopo - C++: The power, elegance and simplicity of a hand grenade.
Re: user32 : Temporarily disable test for _WIN64.
Erik de Castro Lopo [EMAIL PROTECTED] wrote: In include/winuser.h we have: #if !defined _WIN64 !defined __WINESRC__ # define GWL_USERDATA(-21) # define GWL_ID (-12) # define GWL_HWNDPARENT (-8) # define GWL_HINSTANCE (-6) # define GWL_WNDPROC (-4) # define DWL_MSGRESULT 0 # define DWL_DLGPROC 4 # define DWL_USER8 #endif /* _WIN64 __WINESRC__ */ which means fixing the test requires first finding out the correct values of these defines under _WIN64. winuser.h already has the correct values for _WIN64. That seems a waste of effort when I'm aiming to get the simplest of WIN64 apps running, like a Hello world program that prints to stdout. I assume that you have all other problems sorted out? (compiler support, TLS layout, calling conventions, other ABI incompatibilities). Secondly, being unable to compile wine configured with --enable-win64 because of a test for code that has zero percent chance of being correct anyway seems counter productive. It's counter productive to start fighting without investigating the subject first. -- Dmitry.
Re: Add an include/config.h variable WINE_IS_WIN64 which is 1 whenconfigured with --enable-win64 and 0 otherwise.
Dmitry Timoshkov wrote: Erik de Castro Lopo [EMAIL PROTECTED] wrote: Add an include/config.h variable WINE_IS_WIN64 which is 1 when configured with --enable-win64 and 0 otherwise. It would be helpful to at least provide an explanation why yo need this, and why _WIN64 macro is not enough. You are right, _WIN64 is sufficient. Erik -- - Erik de Castro Lopo - A good debugger is no substitute for a good test suite.
make test - only four tests failing!
make test is pretty darn close to passing; only four tests left to fix. (Oddly, different sets fail depending on display mode.) Details at the end of http://bugs.winehq.org/show_bug.cgi?id=9916 Let's get these fixed before code freeze!
Re: make test - only four tests failing!
On Thu, Apr 24, 2008 at 11:50 PM, Dan Kegel [EMAIL PROTECTED] wrote: make test is pretty darn close to passing; only four tests left to fix. (Oddly, different sets fail depending on display mode.) Details at the end of http://bugs.winehq.org/show_bug.cgi?id=9916 Let's get these fixed before code freeze! Yours is one of the lucky machines. According to test.winehq.org, the average number of wine module failures is 11. -- James Hawkins
Re: user32 : Temporarily disable test for _WIN64.
Dmitry Timoshkov wrote: Erik de Castro Lopo [EMAIL PROTECTED] wrote: In include/winuser.h we have: #if !defined _WIN64 !defined __WINESRC__ # define GWL_USERDATA(-21) # define GWL_ID (-12) # define GWL_HWNDPARENT (-8) # define GWL_HINSTANCE (-6) # define GWL_WNDPROC (-4) # define DWL_MSGRESULT 0 # define DWL_DLGPROC 4 # define DWL_USER8 #endif /* _WIN64 __WINESRC__ */ which means fixing the test requires first finding out the correct values of these defines under _WIN64. winuser.h already has the correct values for _WIN64. I has _WIN64, but if _WIN64 is defined then GWL_WNDPROC is undefined and the test in dlls/user32/tests/edit.c fails to compile. I assume that you have all other problems sorted out? (compiler support, TLS layout, calling conventions, other ABI incompatibilities). I'm sure I haven't, but if the wine code doesn't compile I can't debug any problems in these areas. Erik -- - Erik de Castro Lopo - In civilian equipment, such as computers, the number of components alone makes miniaturization essential if the computer is to be housed in a reasonable-sized building. Electronics Oct. 1, 1957, p. 178
Re: user32 : Temporarily disable test for _WIN64.
Erik de Castro Lopo [EMAIL PROTECTED] wrote: I has _WIN64, but if _WIN64 is defined then GWL_WNDPROC is undefined and the test in dlls/user32/tests/edit.c fails to compile. I'll let you figure this out on your own, that's a helpful thing to learn. I assume that you have all other problems sorted out? (compiler support, TLS layout, calling conventions, other ABI incompatibilities). I'm sure I haven't, but if the wine code doesn't compile I can't debug any problems in these areas. user32 is not required for a simple Hello World app, isn't it? -- Dmitry.
Re: [PATCH] advapi32: add more checks in CRYPT_CreateMachineGuid.
Lei Zhang [EMAIL PROTECTED] wrote: I'm getting a crash in CRYPT_CreateMachineGuid() with native rpcrt4.dll. This adds some checks to work around it. I assume that native == win9x in this case. pRpcStringFree = GetProcAddress(lib, RpcStringFreeW); +if (!pUuidCreate || !pUuidToString || !pRpcStringFree) goto CreateMachineGuidCleaup; It would be better to use A versions of APIs then instead of failing, -- Dmitry.
Re: [PATCH] advapi32: add more checks in CRYPT_CreateMachineGuid.
On Thu, Apr 24, 2008 at 10:42 PM, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Lei Zhang [EMAIL PROTECTED] wrote: I'm getting a crash in CRYPT_CreateMachineGuid() with native rpcrt4.dll. This adds some checks to work around it. I assume that native == win9x in this case. pRpcStringFree = GetProcAddress(lib, RpcStringFreeW); +if (!pUuidCreate || !pUuidToString || !pRpcStringFree) goto CreateMachineGuidCleaup; It would be better to use A versions of APIs then instead of failing, -- Dmitry. Right, native == win9x here. The GetProcAddress call actually succeeds, but then pUuidToString returns RPC_S_CANNOT_SUPPORT. I'll send a better patch out tomorrow.
