kernel32: Implement ReplaceFileW
I have read this patch sent in several times and have realised that every time it contains a large number of goto's. I certainly do not like goto in structured code. My question to the forum is if it is allowed to use goto in wine or if you prefer not to use it. Even when this will make the code larger but it may give a little nore readability,
Re: Patch tracking system - again...
On Friday 08 February 2008 08:51:15 Steven Edwards wrote: I'll skip the technical discussion and go right to the beef. Is there even still the desire to have a graphical patch tracking system? Personally I tend to use feature branches in git that I rebase on the top of Alexandre's tree. Simply starting gitk will show me which of my patches have been accepted and which of them are still on top of the tree. Of course that means I need to track which of those I sent. Using more branches, this is even more clear. Assume you have two git branches, 'submitted' and 'my-cool-feature' You develop in 'my-cool-feature'. Once a patch is ready to be committed, you git-cherry-pick it to the 'submitted' branch, git-format-patch | git-imap-send or whatever you do to send it to wine-patches. Now you can keep track of your submitted patches easily. A web interface can be nice, so if anyone feels like hacking this up I'm definitely not going to stop them. All I want to say is that I think it's not needed for personal use. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: War on conformance test suite failures!
On 05/02/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Dienstag, 5. Februar 2008 07:59:58 schrieb Reece Dunn: On 05/02/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Dienstag, 5. Februar 2008 00:50:55 schrieb Dan Kegel: Great progress was made at Wineconf last year on getting our test suite closer to always passing on wine, but http://test.winehq.org/data/200801301937/#Wine shows that, according to the results collected from people who run programs/winetest on Wine, twelve DLLs' tests are currently failing. (Let alone the test failures on Windows!) http://bugs.winehq.org/show_bug.cgi?id=9916 also talks about the fact that make test shows failures. This is only half on-topic, but the d3d9:visual test ran on this machine has some interesting results: Vista: Vista-HomePrem-NoUAC Do we have any track who reported them? That one is mine, along with Vista-HomePrem-UAC. They are both on the same high-spec recent HP laptop (HP Pavilion DV95000) machine with an NVidia GeForce 8600M GS graphics card. Do you have Half Life 2? If yes, can you start a new game and take a few screenshots from Doktor Kleiner's lab? If you don't have the game I'll try to find a place to reproduce the fog bug at a place that can be reached in the demo. No, I don't have the game, sorry. - Reece
Re: Code quality (was Re: comctl32: Fix invalid syntax)
On Fri, 8 Feb 2008, Bang Jun-young wrote: [...] In fact, this is a well known mistake many newbie Win32 developers make (and fix in minutes). It shouldn't have been in the tree in the first place if he actually have read the patch. News flash!!! You too are allowed to review patches posted to wine-patches and to point out their flaws. Some people do so regularly and thus help Alexandre. If bad patches are accepted it's partly your fault. (and mine too cause I don't review patches enough) There are a lot of easily catchable bugs in the tree, for example, potential security holes like buffer overrun, meaningless comparison of unsigned 0 (or 0), misuse of BOOL vs. HRESULT, misuse of functions such as strcasecmp(), use of non-portable syntax, etc. You are welcome to review the Wine code and submit patches too. Again some others do so on a regular basis (me included this time :-). But if you don't want Wine to get better, then sure, just bitch about it. That's the main reason why Wine keeps crashing every time I give it a try with my Windows apps. sarcasm Rght. It must be the *main* cause of crashes. All the stub functions and unimplemented undocumented features must really be secondary causes of crashes in comparison. /sarcasm -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: kernel32: Implement ReplaceFileW
[EMAIL PROTECTED] wrote: I have read this patch sent in several times and have realised that every time it contains a large number of goto's. I certainly do not like goto in structured code. My question to the forum is if it is allowed to use goto in wine or if you prefer not to use it. Wine takes the right (TM) approach to goto: the non ideological one: goto is fine for handling a lot and complex cleanups needed on error paths. You always need to balance the advantages and disadvantages of goto: does the goto make the code more readable and clear? If yes use the goto if not then don't. See also Donald Knuth paper Structured Programming with Goto Statements http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf Even when this will make the code larger but it may give a little nore readability, No, it doesn't increase readability it decreases readability a lot. Especially as you have to replace goto error: with deeply nested if/else code and that is not readable at all. Using goto right is an art; you need to look at the code and say that it looks good. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Consulting Communications Engineer Fax.: +49-711-96437-111 Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich
Re: user32: Implement GetWindowModuleFileName with tests
+hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); After reading MSDN and guessing from the API name shouldn't it simply fetch GWL_HINSTANCE and call GetModuleFileName on it? -- Dmitry.
Re: user32: Implement GetWindowModuleFileName with tests
Reece Dunn [EMAIL PROTECTED] wrote:
+retval = GetWindowModuleFileNameW(hwnd, filenameW, cchFileNameMax);
+if (retval)
+{
+DWORD lasterror = GetLastError();
+WideCharToMultiByte(CP_ACP, 0, filenameW, -1, lpszFileName,
cchFileNameMax, NULL, NULL);
+SetLastError(lasterror);
What's the point of saving/restoring last error value? If WideCharToMultiByte
fails you need to return an error in that case, not silently continue.
The usual model is something like this:
SetLastError(0xdeadbeef);
WinApiCall();
ok(GetLastError() == ERROR_SUCCESS, WinApiCall failed, expected
ERROR_SUCCESS, got %d, GetLastError());
In the tests, which is not the case here.
--
Dmitry.
Re: Fixing make test - progress update
I don't want to spoil your enthusiasm but how does that differ from for example (old one though) http://test.winehq.org/data/200801301937/#Wine ? The main difference is that I ran it from my Wine tree, and getting it built and ready to go was completely under my control. That is, this is as close to running make test in my tree, but dumping the results to a web site for collation. There is an arguably theoretical difference in that it was built with gcc and my tool chain and is more theoretically identical to a 'make test' run than running a prebuilt winetest.exe. Cheers, Jeremy
Re: user32: Implement GetWindowModuleFileName with tests
On 08/02/2008, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Maarten Lankhorst [EMAIL PROTECTED] wrote:
+retval = GetWindowModuleFileNameW(hwnd, filenameW, cchFileNameMax);
+if (retval)
+{
+DWORD lasterror = GetLastError();
+WideCharToMultiByte(CP_ACP, 0, filenameW, -1, lpszFileName,
cchFileNameMax, NULL, NULL);
+SetLastError(lasterror);
What's the point of saving/restoring last error value? If WideCharToMultiByte
fails you need to return an error in that case, not silently continue.
The usual model is something like this:
SetLastError(0xdeadbeef);
WinApiCall();
ok(GetLastError() == ERROR_SUCCESS, WinApiCall failed, expected
ERROR_SUCCESS, got %d, GetLastError());
- Reece
Re: Fixing make test - progress update
Jeremy White wrote: I believe that we have an easy way to find out the 'state of the art' wrt to make test. That is, my patch + request of a few days ago: http://www.winehq.org/pipermail/wine-devel/2008-February/062303.html resulted in a very nice, easy to digest report http://test.winehq.org/data/20080205/ Hi Jeremy, I don't want to spoil your enthusiasm but how does that differ from for example (old one though) http://test.winehq.org/data/200801301937/#Wine ? -- Cheers, Paul.
Re: Fixing make test - progress update
On 08/02/2008, Jeremy White [EMAIL PROTECTED] wrote: That data has five test runs and shows clear across the board failures in msi:install, shell32:shellink, user32:listbox, and user32:msg. The user32:listbox tests fail everywhere when not run from the dlls/user32/tests directory! I have a patch in wine-patches that is in current git (http://source.winehq.org/git/wine.git/?a=commitdiff;h=01af8501b992896a5fff38da365896b7708cc705) that fixes those failures. I had a look at the user32:msg failures, but the test results for these on Wine appear to be completely different on different wine versions. I suspect these are down to configuration variations (e.g. X vs. Wine window handling (with focus behaviour) and the like). I haven't had a look at the others yet. - Reece
Re: More correctly handle the presence of the default ime inputwindow on Ime open and close
Aric Stewart [EMAIL PROTECTED] wrote:
diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c
index 4acbde3..f3ed6f9 100644
--- a/dlls/imm32/imm.c
+++ b/dlls/imm32/imm.c
@@ -190,19 +190,17 @@ static LRESULT ImmInternalSendIMENotify(WPARAM notify,
LPARAM lParam)
static void ImmInternalSetOpenStatus(BOOL fOpen)
{
-TRACE(Setting internal state to %s\n,(fOpen)?OPEN:CLOSED);
+ TRACE(Setting internal state to %s\n,(fOpen)?OPEN:CLOSED);
Wouldn't it be better to change indentation to commonly used 4 spaces
instead of a strange mix of 3 and 4 spaces?
--
Dmitry.
re: msvcrt: Fix EOF behavior on read from pipe
Damjan wrote The problem is more general: consoles *also* break on short reads (Java 1.4.1's gdb takes 1 command then quits because it thinks it's the end of file) Try my patch, it should help that case. I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal. If you can come up with an example of a real app or even a test case that is currently broken, I'll gladly try to fix it. - Dan
Re: user32: Implement GetWindowModuleFileName with tests
Dmitry Timoshkov [EMAIL PROTECTED] wrote: +hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); After reading MSDN and guessing from the API name shouldn't it simply fetch GWL_HINSTANCE and call GetModuleFileName on it? And after looking at GetModuleFileNameW implementation, shouldn't it treat hModule == 0 as GetModuleHandle(0) and not be 16-bit specific? Guess this all needs a test case. -- Dmitry.
AppDB Issues
As many of you have noticed we've been having a bit of server trauma this past month. The issue boils down to a bug somewhere in mysqld. We are still trying to find the exact cause of the bug. We do have some leads. I just wanted to do a brain dump on wine-devel here before I go on Vacation for a week. The problem: mysqld will randomly eat up all resources on the system until the server is completely unresponsive to anything but pings. My band-aids thus far: 1. mysql is now running at a nice of 1. This should allow us to at least ssh in and kill it if it gets out of control again. 2. I've removed InnoDB table support to save on memory. Not many tables where using it anyway, and nothing is using transaction support at this time. 3. I've patched the appdb to use memcached for session management. This will reduce some load on the DB as the session table was busiest and slowest table of the appdb. These fixes should give longer uptime, but they are not solving the core issue. While I'm gone, if the server goes offline again, please contact Alexandre or Jeremy White. They can kick proverbial butt of the server to get it going again. Lastly, sorry for the issues. -Newman We do what we must because we can - GLaDOS
Re: user32: Implement GetWindowModuleFileName with tests
Hi folks, 2008/2/8, Dmitry Timoshkov [EMAIL PROTECTED]: Dmitry Timoshkov [EMAIL PROTECTED] wrote: +hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid); After reading MSDN and guessing from the API name shouldn't it simply fetch GWL_HINSTANCE and call GetModuleFileName on it? And after looking at GetModuleFileNameW implementation, shouldn't it treat hModule == 0 as GetModuleHandle(0) and not be 16-bit specific? Guess this all needs a test case. I've tried to do the GetWindowLongPtr GWLP_HINSTANCE thing but it seems to always return 0 in wine, which according to msdn means error, but it could just be not set in wine. Perhaps GWLP_HINSTANCE needs to be set when the window is being created? Cheers, Maarten.
Re: user32: Implement GetWindowModuleFileName with tests
Maarten Lankhorst [EMAIL PROTECTED] wrote:
UINT WINAPI GetWindowModuleFileNameA( HWND hwnd, LPSTR lpszFileName, UINT
cchFileNameMax)
{
-FIXME(GetWindowModuleFileNameA(hwnd %p, lpszFileName %p, cchFileNameMax
%u) stub!\n,
- hwnd, lpszFileName, cchFileNameMax);
-return 0;
+LPWSTR filenameW = NULL;
+UINT retval;
+
+if (cchFileNameMax)
+{
+filenameW = HeapAlloc(GetProcessHeap(), 0, cchFileNameMax);
+if (!filenameW)
+{
+SetLastError(ERROR_NOT_ENOUGH_MEMORY);
+return 0;
+}
+}
Probably GetWindowModuleFileNameA should simply allocate a buffer of size
MAX_PATH on the stack and fail with ERROR_FILENAME_EXCED_RANGE if unicode
counterpart returns a string longer than MAX_PATH. kernel32 APIs behave
that way.
+retval = GetWindowModuleFileNameW(hwnd, filenameW, cchFileNameMax);
+if (retval)
+{
+DWORD lasterror = GetLastError();
+WideCharToMultiByte(CP_ACP, 0, filenameW, -1, lpszFileName,
cchFileNameMax, NULL, NULL);
+SetLastError(lasterror);
What's the point of saving/restoring last error value? If WideCharToMultiByte
fails you need to return an error in that case, not silently continue.
Also GetWindowModuleFileNameA also should be fixed to return correct value,
and not assume that the buffer is '\0' terminated.
UINT WINAPI GetWindowModuleFileNameW( HWND hwnd, LPWSTR lpszFileName, UINT
cchFileNameMax)
{
-FIXME(GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax
%u) stub!\n,
- hwnd, lpszFileName, cchFileNameMax);
-return 0;
+PROCESS_BASIC_INFORMATION pbi;
+DWORD pid, retval;
+HANDLE hproc;
+DWORD lasterror = GetLastError();
+UNICODE_STRING *pathname;
+TRACE(GetWindowModuleFileNameW(hwnd %p, lpszFileName %p, cchFileNameMax
%u)\n, hwnd, lpszFileName,
cchFileNameMax);
TRACE/WARN/ERR/etc already print the caller's name, there is no need to
duplicate it.
+if (!GetWindowThreadProcessId(hwnd, pid))
+{
+SetLastError(ERROR_INVALID_WINDOW_HANDLE);
+return 0;
+}
GetWindowThreadProcessId already sets the error to the correct value,
there is no need to guess why it failed.
+if (!cchFileNameMax)
+{ /* Fail silently without setting filename */
+SetLastError(lasterror);
+return 0;
+}
Saving/restoring last error value doesn't look correct at all.
+hproc = OpenProcess(PROCESS_QUERY_INFORMATION, 0, pid);
+if (!hproc)
+{
+FIXME(Is this correct?);
+SetLastError(ERROR_INVALID_WINDOW_HANDLE);
+return 0;
+}
There is no need to guess why OpenProcess failed.
+retval = NtQueryInformationProcess(hproc, ProcessBasicInformation, pbi,
sizeof(pbi), NULL);
+pathname = pbi.PebBaseAddress-ProcessParameters-ImagePathName;
+if (pathname-Length / sizeof(WCHAR) cchFileNameMax)
+{
+memcpy(lpszFileName, pathname-Buffer, pathname-Length);
+lpszFileName[pathname-Length / sizeof(WCHAR)] = 0;
+retval = pathname-Length / sizeof(WCHAR) + 1;
+}
+else
+{
+memcpy(lpszFileName, pathname-Buffer, cchFileNameMax *
sizeof(WCHAR));
+retval = cchFileNameMax;
+}
Both branches above should be merged, that will simplify the code. Just '\0'
terminate the result if there is enough space in the provided buffer.
+CloseHandle(hproc);
+SetLastError(lasterror);
+FIXME(-- %u %s\n, retval, debugstr_w(lpszFileName));
Left-over from debugging?
--
Dmitry.
Re: Code quality (was Re: comctl32: Fix invalid syntax)
hi base, If winehq.org is Alexandre's own property, this is something fundametally wrong again. Well.. then 'something' must be wrong with the linux kernel aswell.. how comes noone forked? hmmm.. You may try to learn how things work in the Wine project by reading the following thread: http://www.winehq.org/pipermail/wine-devel/2006-September/050915.html Although time consuming, it was rather a good read. While digesting the follow up 'governance ideas' thread I had a little idea that might help, though I doubt the problems discussed at that time are still that relevant. IMHO most of the wine-patches-black-hole problem is complexity of submitted patches, making them hard to review and rather lead to those patches being silently skipped in favor of the infinitly queuing later patches. One simple fix for this would be to recommend a maximum size for diffs on the developer wiki (additionally to the recommendation to focus on a small context per patch) and set up a wine-patches auto-reply for patches beyond that size, warning the submitter that because of sheer size (=complexity), the patch is likely to be skipped because of merge pressure of the following patches. That way, new contributors would get another visible warning to submit patches that are easier to review. Again, I can't estimate how much of an issue this is atm. I see a lot of patches commit or discussed on -devel, so it might not be at all. Anyways.. Another thing: after my important exam in march, I will probably try setting up a drupal site and see how it can be merged/ integrated with the wineforum, mailing lists and bugzilla.. there are some cool modules and regexp power waiting to be explored :) Last note: Jesse's DIB engine stuff, my work on printing aswell as Detlef's progress on sanitizing the spooler will hopefully show some results, too. Jesse I'll discuss that stuff with you next month be sure to be ready for some wine-patches resubmit cycles ;D regards, marcel. -- div id=signature Obstacles are those frightful things you see when you take your eyes off your goal. -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future /div
Fixing make test - progress update
I believe that we have an easy way to find out the 'state of the art' wrt to make test. That is, my patch + request of a few days ago: http://www.winehq.org/pipermail/wine-devel/2008-February/062303.html resulted in a very nice, easy to digest report http://test.winehq.org/data/20080205/ That data has five test runs and shows clear across the board failures in msi:install, shell32:shellink, user32:listbox, and user32:msg. So, we can quickly and easily collate and visually see the make test failures. And, heck, I'm sure that fixing those failures is now a trivial exercise. Now we just need the will. :-/. Not sure how to arrange that, but I think having make test succeed on all systems should be a mandatory requirement for Wine 1.0, so I think we have to work on solving it sooner rather than later. The todo's as I see them are as follows: 1. Revise winetest to not require the 'make dist' step, so that the function of my patch can be implemented more cleanly. 2. Persuade people to run a script on a regular basis so we always have this data. It's trickier than the average bear because the tests require the 'real' console, so you can't just stick it in a headless cron job. Maybe some xauth magic... :-/ 3. (The hard one) Focus in and fix the issues. I'll work on #1 and #2 (although not for a week or two), if everyone else agrees to do #3 evil grin. Cheers, Jeremy
Re: More correctly handle the presence of the default ime inputwindow on Ime open and close
Good point, resending.
thanks,
-aric
Dmitry Timoshkov wrote:
Aric Stewart [EMAIL PROTECTED] wrote:
diff --git a/dlls/imm32/imm.c b/dlls/imm32/imm.c
index 4acbde3..f3ed6f9 100644
--- a/dlls/imm32/imm.c
+++ b/dlls/imm32/imm.c
@@ -190,19 +190,17 @@ static LRESULT ImmInternalSendIMENotify(WPARAM
notify, LPARAM lParam)
static void ImmInternalSetOpenStatus(BOOL fOpen)
{
-TRACE(Setting internal state to %s\n,(fOpen)?OPEN:CLOSED);
+ TRACE(Setting internal state to %s\n,(fOpen)?OPEN:CLOSED);
Wouldn't it be better to change indentation to commonly used 4 spaces
instead of a strange mix of 3 and 4 spaces?
re: [PATCH] msvcrt: Fix early pipe closing
On Sat Feb 2, Nguyễn Thái Ngọc Duy wrote: Pipes are not like other normal files. If we do not read enough bytes, it does not mean it reaches EOF ... fixes broken pipe on git-fetch-pack (MinGW port) This is the same problem as http://bugs.winehq.org/show_bug.cgi?id=11187 so it's my fault. Thanks for the information about git-fetch-pack failing, and for the proposed fix. Before we can commit a fix like yours, we need a test case, so I improved msvcrt/tests/file.c to test EOF on pipes more thoroughly. It shows your patch was almost right. I've fixed up your patch and will send it in. - Dan
Re: msvcrt: Fix EOF behavior on read from pipe
On Feb 8, 2008 4:31 PM, Dan Kegel [EMAIL PROTECTED] wrote: Nguyễn Thái Ngọc Duy's patch was almost right, he forgot a test case, and he neglected to move where EOF is detected for pipes instead of just removing it. Should fix http://bugs.winehq.org/show_bug.cgi?id=11187 The problem is more general: consoles *also* break on short reads (Java 1.4.1's gdb takes 1 command then quits because it thinks it's the end of file) and I'm sure short read != end of file for ordinary files either, especially in *nix where read() can easily be interrupted by a signal. Damjan
Re: user32:scroll.c: Compulsory enabling/disabling scrollbars after setting scrollbar`s flags.
Oh, Sorry! It crashes some another scrollbars. :( -- Best regards Anatoly Lyutin.
Re: Code quality (was Re: comctl32: Fix invalid syntax)
On Friday February 8 2008 04:41:28 Bang Jun-young wrote: That's the main reason why Wine keeps crashing every time I give it a try with my Windows apps. ... I see something fundamentally wrong with development process. I think that current development process isn't a problem at all. In fact AJ is very good at what he is doing! As far as I understand your patch (comctl32: Fix invalid syntax.) was rejected just because you forgot to add proper (descriptive) changelog entry. What is the real problem is the lack of testers (who report regressions and bugs) and developers. This is why WINE still has a lot of bugs, regressions are quite common thing to happen, etc. To fix this, more people should read wine-patches and test patches before they are committed, more people should write bug reports, more people should be involved in the development, and so on. Unfortunately, not all people have enough time for such tasks. However, WINE is pretty usable today. Since 1993, Wine has never gotten to the point where everybody could rely on it for his daily work. It has as awfully many bugs as Win95. WINE can work reliably even with very complex programs (such as Photoshop CS - I use it pretty often). And if you don't see BIG improvement in last years you either tried very few Windows programs or you are very unlucky... In my practice WINE run most of the programs I try (well, I didn't tried thousands of Windows programs and there is no hardcore gamers in my family so my statistic may be biased). In fact, it is so good that I typically can rely on it to run any program I'm downloading from the Internet (success rate for me is more than 85% for small and average programs/games downloadable for free from the Internet). And if Windows program(s) work correctly on WINE, cases of random crashes are very rare. They (generally) do exist but most of Windows programs aren't affected by such bugs - much more often you find repeatable crashes after specific sequence(s) of steps. And your statement Wine has never gotten to the point where everybody could rely on it for his daily work is strange. In fact it is true for Windows too (Windows never gotten to the point where everybody could rely on it for his daily work). Maybe you just mean that WINE doesn't work well for you and some (or maybe even most) other people? But working well for some people or for nobody is very different things... There is a lot of people who use WINE for their daily tasks. For example, I and whole my family use Linux and WINE on daily basis (because of dependency on some Windows software and Windows games). There is no Windows installed on our computers (only I have Windows XP in VMWare for my very specific purposes to run Autodesk products). In my practice WINE and Linux are absolutely stable (if no bugs in WINE triggered by the program of course). In fact, I have trading station for Windows working 24 hours per day on my Linux server with WINE (if trading station fail or crash, I potentially can lose real money). And for this purpose (which by definition requires high stability) WINE+Linux works MUCH better than Windows XP. And your comparison of WINE with Windows 95 isn't true at all. Did you actually ever tried to use Windows 95? It will fail MUCH more often than WINE, and WINE can run more Windows programs than Windows 95 (I have it in VMWare so I really tested this with some programs year ago or so, just for fun). Even Windows 98 cannot run many important programs such as Photoshop (it require at least Windows 2000). And Windows 95/98 have a LOT of random crashes; WINE is much better - for many programs it can work for months 24 hours per day without problems, and even if it crashes in some cases, other programs aren't affected (especially if they are launched from different prefix). Everything above is my personal experience, and for some users it may be worse. But for me, WINE work good enough for daily use, even for very important applications. So you can consider my story as yet-another-success-story-of-using-WINE. Obviously, this doesn't mean that WINE is good enough for everyone... But at least it is good enough for me, my family and some of my friends. There is some minor problems (for example, my brother have some games that don't work on WINE at all but he doesn't care very much about this) so WINE isn't perfect of course... But I just want to say that it is good enough for daily work and gaming at least for some people, and a lot of Windows software is usable on Linux with WINE. Personally, I think that AJ and all other WINE developers are doing very great and important work! Big thanks to all of them...
Re: user32: Implement GetWindowModuleFileName with tests
Maarten Lankhorst [EMAIL PROTECTED] wrote: I've tried to do the GetWindowLongPtr GWLP_HINSTANCE thing but it seems to always return 0 in wine, which according to msdn means error, but it could just be not set in wine. Perhaps GWLP_HINSTANCE needs to be set when the window is being created? It works just fine in Wine, have a look at dlls/user32/tests/class.c, test_instances(). -- Dmitry.
