Re: shell32[2/2]: implements shell link's GetCurFile (with tests, fixes bug #21297) [try4]
Juan Lang pisze: Hi Mikolaj, this one was rejected due to formatting, I imagine because of C++ comments in the tests: +// Setting the same value will not set IsDirty... Would you mind fixing and resending? Thanks, --Juan Yes, I've sent the old patch with C++ comments (and a typo). I should be able to generate a correct one today. Mikołaj
Re: Another aspiring GSoC applicant..
David Hedberg pisze: I've also looked a bit at implementing support for IFileDialog, and the Explorer, but I have yet to dig too deep into either of them. Are there currently any known applications out there that uses IFileDialog explicitly? I've looked a bit, probably not enough, but I haven't been able to find anything except example code. Also, are there any applications that fail to run because explorer is missing functionality, or would the end-result of that suggested project function mainly as an end-user utility? In older version of Gnome, Gnome was not using the freedesktop.org standard trash directory, what caused files deleted under Wine not to show up in Gnome Trash. As we have in Wine a Trash virtual folder, I was thinking about fixing it by implementing a IShellBrowser (single explorer window) to show it to the users. However, as this is fixed in newer Gnomes, this is probably not that useful anymore. Still, if anyone is interested, I attach the skeleton code I have written (written under Windows XP x64, to be ported to Wine once finished possibly fixing some bugs) that does some logging and may be useful as a starting point. Apart from the 'shellbrowser' folder, I also put the 'shellfolder' one that I've used when implementing the recycle bin folder that may be useful if one needs logs from the other side (i.e. from a custom folder inside the true Explorer). Mikołaj Thanks, David shell.tar.bz2 Description: application/bzip
Re: include[1/2]: add a strcmpW-equivalent function usable in tests.
2010/2/22 Dmitry Timoshkov dmi...@codeweavers.com:
Mikołaj Zalewski miko...@zalewski.pl wrote:
+/* strcmpW is avaiable for tests compiled under Wine, but not in standalone
+ * builds under Windows, so we reimplement it under a different name. */
+static inline int winetest_strcmpW( const WCHAR *str1, const WCHAR *str2 )
+{
+ while (*str1 (*str1 == *str2)) { str1++; str2++; }
+ return *str1 - *str2;
+}
'inline' should not be used in Wine tests, and existing 'inline's should be
removed since that's not a valid modifier for MSVC, and we can't include
config.h in tests.
Inline is already present in include/wine/test.h - in wine_dbgstr_w.
To compile tests under Visual C++, I use #define inline or add this
define to project properties.
Mikołaj
Re: shell32[1/2]: implements shell link's GetCurFile (with tests, fixes bug #21297)
On Wed, Feb 10, 2010 at 9:32 PM, Nikolay Sivov bungleh...@gmail.com wrote: On 2/10/2010 23:28, Austin English wrote: 2010/2/10 Mikołaj Zalewskimiko...@zalewski.pl: Some installers require this. + expect_eq_x(S_FALSE, IPersistFile_IsDirty(pf)); + expect_eq_x(S_FALSE, IPersistFile_GetCurFile(pf,string)); + expect_eq_p(NULL, string); + expect_eq_x(S_OK, IShellLinkA_GetHotkey(link,hotkey)); + expect_eq_x(0, hotkey); + expect_eq_x(S_FALSE, IPersistFile_IsDirty(pf)); + // Setting the same value will not set IsDirty... + expect_eq_x(S_OK, IShellLinkA_SetHotkey(link, 0)); + todo_wine expect_eq_x(S_FALSE, IPersistFile_IsDirty(pf)); + // ... but a different one will. You've got C++ comments in there... + /* TODO: obejct should be reset on failure (see tests). */ TRACE(-- returning hr %08x\n, r); And a typo here. Thanks. I've sent an updated version. Mikołaj
Re: Running 13 months locales
Nikolay Sivov pisze: Hi. Working on monthcal control I've realized that some locales could have 13 months calendars. How could I guess that I'm running such locale? After a brief look I didn't find anything useful in GetLocaleInfo(). AFAIK the GetCalendarInfo() and EnumCalendarInfo() are for that. However, I have a faint recollection of a post on some blog that the monthcal control is not good for internationalization as it doesn't support non-Gregorian calendars. Thus, it may be worth checking if this is needed before using it. Mikołaj
New version of UUID lookup tool
Hi, I had little time to work on Wine lately, but recently I could work a bit on my UUID database. The new version retrieves the identifier name after __declspec(uuid) macros and is available as an online app on AppEngine at http://mikolajapp.appspot.com/uuid/ . The offline version with the source code is available at http://www.mikolaj.zalewski.pl/dl/uuid2.tgz . Mikołaj
Re: Running 13 months locales
If it does support Gregorian only there's nothing to worry about. Actually I don't know how to test this, if we're talking about some Asian locales like Chinese or Japanese are you experienced with that? A best way will be to test under Linux with native comctl32 but I'm not sure builtin kernel32 (and maybe something else) is capable to support such locale features. The last time I checked (something like one year ago), our kernel32 calendar function were hardcoded for Gregorian Calendar. Thus, to check this, you would need native Windows, change the locale to several Asian or Arabic ones (in Regional Settings, this shouldn't change the UI language) and create a monthcal control. If it still displays a Gregorian calendar, then, I think, no implementation is necessary. You could also check if there is no monthcal message to choose the calendar (locales can support multiple calendars. But AFAIR all support also the Gregorian one), but I think I've been checking this once and there wasn't (however, I might have been checking the datetime control instead). Mikołaj
Re: Wine translation statistics sources
The results for Wone 1.0.x ( http://pf128.krakow.sdi.tpnet.pl/wine-transl/ ) won't open (tryied several times yesterday and today) The correct URL is http://www.mikolaj.zalewski.pl/wine-transl/1.0.x/ . This can be fixed in config.php (I've forgotten to update the example config in the sources). Of course, this can be also moved to WineHQ (by creating a new tree with the same PHP scripts, but with different config and data) to have everything in one place. Mikołaj
Re: Wine translation statistics sources
It's now online at http://source.winehq.org/transl/ and will be updated every time there's a git push. Please let me know if you find any problems. The source is also available now in the tools.git repository. It looks like there is a problem with CSS - some formatting is gone and I get a 403 forbidden on http://source.winehq.org/transl/style.css . Mikołaj
Re: Wine translation statistics sources
If you send me the necessary information I can probably take care of it. I've uploaded the lastest version to http://www.mikolaj.zalewski.pl/dl/wine-transl.tgz . There is a README there, but basically one needs to start with copying scripts/config-example to scripts/config and setting the paths. There should be a path to a Wine tree, a path to a temporary work directory and a path to the directory with the final data (all of these must be writeable by the scripts). With this set, one should do 'cd scripts ./Master.sh'. This should create langs/ and dumps/ directories, first in the work directory and then move them to the final data directory (it's good for the temporary and final directory to be on the same filesystem for the move to appear to be atomic). It will also synchronize the conf directory in scripts/ with the one in the permanent data directory. With these files persent, the php/config.php should be edited to point to the final data directory. With this set, the PHP should show the translation state. I'm showing separate statistics for 1.1.x and 1.0.x by having the same code in two different places. The config.php contains some options that allow to use the same codebase for this (with changes only in config). Mikołaj
Re: Wine translation statistics sources
Jonathan Ernst napisał(a): Hello, Le dimanche 07 décembre 2008 à 02:15 +0100, Mikołaj Zalewski a écrit : Hi, I didn't update the translation statistics (http://www.mikolaj.zalewski.pl/wine-transl/) very regularly lately - my Your server seems down. Wouldn't it be better to host your script on WineHQ ? It's online again. Having it on WineHQ would probably give a better uptime (and a much better latency, but this should also improve on my side, when I won't need a temporary SSH tunnel anymore and will move the HTTP server from my good old Pentium 100MHz to a new Atom machine). I've been in contact with Jeremy Newman about it some time ago, but, after a few exchanges, my e-mails got unanswered, so I assumed he is too busy to help with it (and, alone, I don't know how to do it). Mikołaj
Re: [shell32] Improve the Dutch 'about' message box
Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though. I also think I would be better to use po files (without them, our translations get out-of-sync - e.g. in start a new /Unix switch was intruduced, but only 7 out of 16 languages has it in the help message. For the users of the other 9 languages, we are providing an incorrect help message. This is adding a new line to an existing message, so wrc --verify-translation won't notice it). I was thinking about the widget layout that may need to be different in a translation and I think this can be solved by adding a possibility to add some transformations of controls relative to the English ones. Something like: msgid transform.dialog.133 msgstr control 12 resize by (10, 10) control 13 move by (10, 10) Making the transformations relative should make updating such resources not very common (and in most cases there will be even no need for this). There may still be cases when it looks ugly if e.g. one adds a new button to the English dialog while the localized ones are enlarged and takes a place where the new button is added, but we could be solved by adding to msgid e.g. a hash of the English resource with localizable stirngs removed, so that the translation will be fuzzy after a merge. I could try to look into po2rc and rc2po if they work and can be augmented with such a functionality, but I'm not sure if I will have time soon. Mikołaj
Re: winedbg: add a crash dialog for --auto mode
Austin English wrote: 2009/4/16 Mikołaj Zalewski miko...@zalewski.pl: This version of the patch uses the now implemented GetProcessImageFileName. From 549bdead0736d63bc2c05557b6813a64b53aa2ec Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Miko=C5=82aj_Zalewski?= miko...@zalewski.pl Date: Sun, 21 Dec 2008 22:28:32 +0100 Subject: [PATCH] winedbg: add a crash dialog for --auto mode --- dlls/kernel32/tests/debugger.c | 96 ++- programs/winedbg/Makefile.in |5 +- programs/winedbg/crashdlg.c| 172 programs/winedbg/debugger.h|6 ++ programs/winedbg/intvar.h |3 + programs/winedbg/resource.h| 34 programs/winedbg/rsrc.rc | 26 ++ programs/winedbg/rsrc_En.rc| 53 programs/winedbg/tgt_active.c | 16 +++- programs/winedbg/winedbg.c | 36 +--- 10 files changed, 392 insertions(+), 55 deletions(-) Howdy Mikołaj, Looks like this patch caused a regression in http://bugs.winehq.org/show_bug.cgi?id=18216. Could you have a look? Before, it would crash, but the app continued on happily. After the crash dialog patch, the debugger is spawned infinitely, until the X client limit is reached. Seems to be hitting a loop somewhere... Thanks for the info. I will look into it on Wednesday. If this is the debugger crashing (and causing another instance of it to start), it should be easy to fix. If this is the application spawning lots of subprocesses (e.g. because there is no response after a timeout), this could be much harder. Mikołaj
Re: Need help writing test
Igor Tarasov wrote: Hi! I've found few visual glitches in comctl32/toolbar, and now try to write this all down as conformance tests, but I have some problems. I see that there is bug, when I test it with control spy. But when I repeat it in testcase, it won't work. Here is how you can reproduce it: TB_SETBITMAPSIZE 20,20 TB_SETBUTTONSIZE 30,30 TB_SETBITMAPSIZE 10,10 Now, if you do TB_SETBUTTONSIZE, you'll see the difference. builtin comctl will return 17,16. Native - 30,16. But when I write something like this: rebuild_toolbar_with_buttons(hToolbar); himl = ImageList_LoadImage(GetModuleHandle(NULL), MAKEINTRESOURCE(IDB_BITMAP_80x15), 20, 2, CLR_NONE, IMAGE_BITMAP, LR_DEFAULTCOLOR); ok(SendMessageA(hToolbar, TB_SETIMAGELIST, 0, (LRESULT)himl) == 0, TB_SETIMAGELIST failed\n); SendMessageA(hToolbar, TB_SETBITMAPSIZE, 0, MAKELONG(20, 20)); SendMessageA(hToolbar, TB_SETBUTTONSIZE, 0, MAKELONG(30, 30)); ok(SendMessageA(hToolbar, TB_GETBUTTONSIZE, 0, 0) == MAKELONG(30, 30), Unexpected button size\n); SendMessageA(hToolbar, TB_SETBITMAPSIZE, 0, MAKELONG(10, 10)); compare((int)SendMessageA(hToolbar, TB_GETBUTTONSIZE, 0, 0), MAKELONG(30, 16), %x); This test fails, when I test it with native comctl32 (the size is 17,16). Why could this happen or what am I doing wrong? TB_SETBITMAPSIZE does some work in WM_PAINT. You could try add some UpdateWindow(hToolbar) calls after TB_SETBITMAPSIZE or TB_SETIMAGELIST - maybe this will change something? (of course, another possibility is that this behaviour is a side-effect of some other messages or some parameters. On Wine, you can use WINEDEBUG=+message to get the tree of messages that have been sent). Mikołaj
Re: [PATCH 1/2] comctl32/tests: test toolbar separator with uninitialized iString
Hi, I think it would be interesting to test what TB_GETBUTTONINFO returns as iString for such a separator. That way we will know if the value is simply ignored, or it's something more complicated. +static void test_deadbeef(void) I think you should find a better name. Maybe test_addbuttons would be better - some more tests for this message could be added later? +#if 0 +/* It is also possible that a poorly written program doesn't initialize the + * iString field of an actual button. Different versions of Windows seem to + * operate differently in this case. + *+ Windows XP doesn't seem to be bothered in the least + *+ Windows 2008 crashes + *+ Windows Vista does not crash, but the subsequent TB_ADDBUTTONS + * call fails + * Since I know of no program that suffers from this particular issue, I'm + * commenting out this part of the test for the time being. If it gets + * uncommented, the subsequent TB_ADDBUTTONS should be adjusted + * appropriately. */ Tests with #if 0 are discouraged - usually after some time and changes in the surrounding, the code doesn't compile anymore. Probably leaving only the comment would be appropriate in this case. It's interesting that the behaviour changed with the version of Windows. You were testing with a program without a manifest? (i.e. using comctl32 v5.82. But it's hard to make a mistake, as if you used a manifest, you would have a lot of failures in check_sizes) Mikołaj
Re: Setting working directories for applications?
Well, I've already have looked into start.exe, and it does not provide functionality I need. Look: we have some program, prog.exe It is located it ~/.wine/drive_c/foo/ . But it needs it's working dir to be set to ~/.wine/drive_c/foo/bar. So, from terminal you can launch it this way: cd ~/.wine/drive_c/foo/bar wine ../prog.exe Start.exe won't help here, as I don't see any path-related options there. Using: wine start 'c:\windows\Start Menu\My App\App.lnk' ususally does the trick. However, this can also be hard for a novice to guess. Mikołaj Zalewski
Re: comctl32: Fix bitmap size calculation
Anyway, e.g. Sib Icon Edit required ~ 30 Mb (something like 27 images * 13440 width * 24 height * sizeof(each pixel)) of memory for every instance to run (due to this bug). Now it requires only about 300kb Fixing one app doesn't mean it's correct. Yes, there is an obvious error in the image list, but you are not just fixing it. You also removing some functionality that tool bar depends on. The toolbar doesn't need it anymore - currently after a button size change, TOOLBAR_CheckImageListIconSize (called from TOOLBAR_Refresh) destroys the imagelist and creates a new one. It seems that even before, it was resizing the bitmap using ImageList_SetIconSize (however only when no images were added). Mikołaj
Re: faultrep:display useful information in ReportFault
Jérôme Gardou pisze: Let's rephrase it : most bug reporters expect the console log to be useful for developers willing to fix their problem :-) Maybe I should have made it clear - I think that your patch, even in the first version, was a step forward :). As for the second patch, Alexandre doesn't like when we export some wine-specific functions from DLLs. On the other hand, kernel32 is always builtin, so the main argument against it (that it will break if someone uses a native DLL) is not present, so maybe it could be accepted. But it's Alexandre who can answer it. Mikołaj
Re: faultrep:display useful information in ReportFault
I've written a dialog about a crash some time ago to add to winedbg (http://www.winehq.org/pipermail/wine-patches/2009-January/068073.html). It's probably time to ask what is the status of this patch? If this patch gets accepted (Alexandre seemed to like the previous version, but pointed that it broke kernel32 tests because there had been no way to disable it and he didn't have much time to review it), maybe calling `winedbg --auto` from ReportFault would be the best way - you would then have a dialog (the same as during a regular crash, can be disabled from the registry), the full debugger output and an option to run an interactive debugger. AFAIK this is the other way round than Windows does (AFAIK drwatson loads faultrep.dll into the process that crashed and calls ReportFault), but loading a DLL into a process where everything could be corrupted seems a strange idea. Jérôme Gardou pisze: Most wine users, when their app crashes, open a bug report and attach the console log. If the log contains information got from ReportFault, developers will gain some time, and have the preceding context of the call. I'm affraid this is what is done by the 1% best users ;). I'd expect that a typical user to complain that Linux is broken because on Linux, from time to time, apps just disappear from the screen while on Windows they don't. Already knowing that there is such a thing like Wine requires some knowledge :). Mikołaj Zalewski
Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64
Dmitry Timoshkov wrote:
Mikolaj Zalewski miko...@zalewski.pl wrote:
+/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of
the structure
+ * is the same as of TBBUTTON */
typedef struct
{
INT iBitmap;
@@ -96,6 +98,9 @@ typedef struct
BYTE fsStyle;
BYTE bHot;
BYTE bDropDownPressed;
+#ifdef _WIN64
+BYTE bReserved64[4];
+#endif
DWORD_PTR dwData;
INT_PTR iString;
INT nRow;
Then probably it would make sense to make TBBUTTON the first member of
the above
structure. That would help in avoiding possible layout problems in
future.
The bHot and bDropDownPressed would then be called bReserved[0] and
bReserved[1] so this could make more harm than good.
Mikolaj
Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64
Dmitry Timoshkov wrote:
Mikołaj Zalewski miko...@zalewski.pl wrote:
+/* Note: TOOLBAR_DumpButton assumes the layout of the beginning of
the structure
+ * is the same as of TBBUTTON */
typedef struct
{
INT iBitmap;
@@ -96,6 +98,9 @@ typedef struct
BYTE fsStyle;
BYTE bHot;
BYTE bDropDownPressed;
+#ifdef _WIN64
+BYTE bReserved64[4];
+#endif
DWORD_PTR dwData;
INT_PTR iString;
INT nRow;
Then probably it would make sense to make TBBUTTON the first member
of the above
structure. That would help in avoiding possible layout problems in
future.
The bHot and bDropDownPressed would then be called bReserved[0] and
bReserved[1] so this could make more harm than good.
You can make a union for that case, with an appropriate comment.
TBBUTTON is an official Windows API structure. Adding a union inside
and doing it just because of some internals of our toolbar
implementation is IMHO not the best idea.
Mikolaj
Re: comctl32[2/2]: toolbar: fix the layout of TBUTTON_INFO on Win64
Alexandre Julliard wrote: If there is evidence that Windows really uses the reserved fields to store bHot and bDropDownPressed then the code should be using bReserved[0] and bReserved[1], wrapped with appropriate accessor functions if necessary. Otherwise they should be moved somewhere else and the bReserved fields left alone. Either way, if we need the correct TBBUTTON layout we should be using a TBBUTTON structure. The bHot and bDropDownPressed fields are in the TBUTTON_INFO structure that is internal to our implementation. It is not visible to the outside world. Probably for convinience, one debug function (TOOLBAR_DumpButton) assumes that the first fields of it are the same as of TBBUTTON and the same function is used dump TBBUTTON and TBUTTON_INFO (with a flag to dump the additional fields). When I noticed this won't work on Win64, I thought adding the padding is the easiest solution. Another solution would be to split the dump function into one for TBUTTON_INFO and one TBBUTTON. Mikołaj
Re: winedbg: add a crash dialog for --auto mode (3rd try)
Is there something wrong with this patch?
Wine translation statistics sources
Hi, I didn't update the translation statistics (http://www.mikolaj.zalewski.pl/wine-transl/) very regularly lately - my server is a bit broken and I can't run the scripts from cron but have remember to do it manually from a different computer. I have plans to fix it, but in the mean time, as some people may want fresh data, I have finished the changes I've been working on and uploaded the sources. It should be very easy to run them on ones machine and check the tree one has on disk - there is a README with explanations. The archive is available at http://www.mikolaj.zalewski.pl/dl/wine-transl.tgz . It is the latest version that adds support for dumping/diffing dialogs. Mikolaj Zalewski
Re: Problem compiling wine tests with msvc in standalone mode.
Where does the ../../../include\rpc.h file come from? If you are mixing Wine and Windows headers then conflicts are quite possible. I copy only wine/test.h from the Wine headers. Often, I also need a #include windows.h at the top of the file for it to compile with MS headers, but after this, it works. BTW, as a reminder, you shouldn't use VS for msvcrt tests as you will link to e.g. msvcr80.dll instead of msvcrt.dll. Mikołaj Zalewski
Re: Starting point to debug an application error
If someone has the time to look at it, I'd love a pointer on where / how to start investigating this.. You could try to do a WINEDEBUG=+message,+seh log. This will give you all the messages, and a search for seh: lines will give you the exceptions that are being thrown/handled. Often, this will give information what message caused a crash in Wine control code or what notify caused a crash in application code. Mikołaj Zalewski
Re: user32: Problem using SetClassLongW to subclass built-in control (Edit)
As it was written, you need to write some more tests for such changes. It required a few iterations before we got SetWindowLongPtr(GWLP_WNDPROC, ...) right, so this might be also not easy. The tests for SetWindowLongPtr are in dlls/user32/tests/class.c. Some things I can think of that requires checking: 1. Is the edit class still special after changing the winproc - does the unicodeness of controls created after the SetClassLongPtr call depend on whether CreateWindowA or CreateWindowW was used 2. Does the same winproc really receive both Unicode and ANSI messages. That's the strangest thing in your patch. Does calling SetWindowTextW and SetWindowTextA call the same function, but once with a Unicode string in lparam and the other time with an ANSI string. 3. Does GetClassLongPtr[AW] return an address or a winproc handle (there is a IS_WINPROC_HANDLE macro in dlls/users32/tests/class.c). The same for GetWindowLongPtr[AW]. If point 1 is true then it would be good to check it for controls created with both CreateWindowA and W 4. Does this apply only to the edit class or to all built-in classes. The edit class is special from the point of view of GetWindowLongPtr so it may be also special here. I think, knowing the answers to these questions would make it easier to create a good patch. This patch seems very strange as it seems unlikely that the same function would be used for both the A and W calls. Mikołaj
Re: services: when displayname is absent, the keyname should be used when searching by displayname (fixes bug #13958)
You should not change scmdatabase_find_service_by_displayname, it does what its name implies. You should fix the callers where necessary. The scmdatabase_find_service_by_displayname is currently wrong. It dereferences a NULL pointer if the registry database contains a service without a display name. The callers can't do anything about that. Both callers expects that if the display name is not explicitly set, the key name should be used as the display name - it looks like a general rule (I've just found that QueryServiceConfig also needs such a feature). Alternatively, code could be added to load_service_config and CreateService to set lpDisplayName to service-name if the display name is not present in the registery. However, this would create a side-effect not present on Windows - this display name would be written to the registery after e.g. a ChangeServiceConfig. Mikolaj Zalewski
UUID lookup utility
To be able to check quickly what a UUID in Bugzilla means, I wrote a script to show some information about them. It uses data retrieved from Windows and Wine include files and registries (it finds information about more than 32000 different UUIDs). If someone is interested in it, I have put to on http://pf128.krakow.sdi.tpnet.pl/uuid.tgz . It's written in JavaScript and works under Firefox 1.5+ (it would require some small modifications to work on IE). Mikołaj Zalewski
Re: Add German translation for xcopy
Does this work for you? When I apply the attached patch and run wine xcopy /? I get garbled German umlauts in the output (also tried with SUBLANG_NEUTRAL) . Is it the same for you? Wine console applications output in the OEMCP (i.e. the DOS codepage for the given locale) that is usually different from the Unix console charset. It works if you run the program in a wine console (`wineconsole cmd` and run 'xcopy /?' there). I think, Wine should detect if the output is a Unix tty and do a conversion from OEMCP to UNIXCP, but that's not something that could be done before Wine 1.0. Mikołaj Zalewski
Re: Can someone get a Maximizer 8 trial CD for me?
I have filled the form but got error 404 after clicking Request Trial CD. Mikołaj Zalewski
Re: Text bug in winecfg!
Is this a wine bug or not? It is a wine bug - the controls for such languages should be bigger. Mikolaj Zalewski
Re: [PATCH] winecfg = control panel applets patch
Frank Richter wrote: On 10.04.2008 09:47, [EMAIL PROTECTED] wrote: However, since control panel does not utilize Unicode yet, the additionalb Bulgarian translation matches the English one. Even for non-Unicode apps you should have no problems with adding a Bulgarian translation to a GUI app (when Bulgarian is selected as your preferred language the active codepage will be chosen accordingly). Maybe you used a wrong charset? You should use the Windows charset or use #pragma (see http://wiki.winehq.org/Developers-Hints?highlight=%28Developers%29#head-ef42a958e4f633dbd4a0ae42649fa02a4d1827fd ) Mikołaj Zalewski
Re: [PATCH] winecfg = control panel applets patch
Hmmm, I'll have to check up on that. The translations themselves are for the description/title that appears under the applet in the control panel. Once launched,(LANG=bg_BG) the winecfg translations take over and no problem there, just the unicode thing looks like rubbish under the icon. And, has twice as many characters as the text itself, which points to a problem within the control, rather than the codepage (?) - most probably, usage of ASCII rather than Unicode in control itself. If there are twice as many characters in the text as there should be then you have probably encoded the file in UTF-8. Try to add '#pragma code_page(65001)' at the top and '#pragma code_page(default)' at the bottom of Bg.rc. By default wrc expects the string to be in the Windows codepage for the specified language. Mikołaj Zalewski
Re: Translations and Wine 1.0
I think the release candidate phase for Wine 1.0 is a good time to add new translations and it's also important to fix out-of-sync resources. They may cause programs to run incorrectly when running under with a different language (I've filled a bug about it: http://bugs.winehq.org/show_bug.cgi?id=12097). The lanuchpad looks interesting. What's the format for importing/exporting data from it? Extracting strings from a *.res is quite easy. Building a *.rc from a *.res and strings is also not too hard. It would be more tricky if we would like to extract the #define'd symbolic names of resources or comments. There is the problem of changing dialogs geometry (but we could use special files for that and write a dialog editor to edit them) and that sometimes the same string have different translations - e.g. in same langauges the column Size for directory view (where it means file size) is translated differently then the column Size in My Computer (where is means disk size). But that can be solved by preppending the string id to the string. Having string in different files than the resources would also help fixing out-of-sync resources (we could use English string if translated ones are not available). Mikolaj Zalewski
Re: services.exe: series of patches - empty attachments.
Hi, Empty patches are attached to every e-mail in this series. Size: 0 bytes http://www.winehq.org/pipermail/wine-patches/2008-March/051638.html http://www.winehq.org/pipermail/wine-patches/2008-March/051651.html http://www.winehq.org/pipermail/wine-patches/2008-March/051641.html ... For some reason the attachements are shown by the mail archive as separate [PATCH] entries, like: http://www.winehq.org/pipermail/wine-patches/2008-March/051639.html . Mikołaj Zalewski
Re: Running services in WINE?
Thanks for sending in your patch Mikołaj, I tested MozyHome with it, but it didn't help anything, the service still wouldn't start. I don't have the experience to work on that patch by myself, but if someone else starts on it and would like assistance making tests or something I'm happy to try. I can look into that (I see it's bug #12030) however it looks like it's not a problem with starting the service but may be a problem with the service itself. Have you tried to run this service with e.g. notepad running in the background - the services are marked as system processes and if there is no non-system process left, all the system processes will terminate themselves. Mikołaj Zalewski
Re: Running services in WINE?
If we wanted to implemented a SCM where would that reside? wineboot? The SCM is the servies.exe program. Other programs using advapi32 communicates with it using RPC. I've started writing it - see http://www.winehq.org/pipermail/wine-patches/2007-September/044396.html . The problems with widl are fixed so it should be possible to add this code to Wine. Probably this code should be updated to current Wine and I'm not sure if I moved all the database query function to services.exe (it's good to more them all in one go to avoid discrepancies between the current advapi implementation that relies on the current state of registry keys and services.exe that loads all the keys at start time and keeps them in memory). I may have some time to work on it and I can help if someone who wants to do it (if one wants to have an idea how the SCM works there is a chapter about it in Windows Internals by M. Russinovich and D. Solomon). Mikołaj Zalewski
Re: [comctl32/tests #3] Use GetModuleHandleA instead of LoadLibraryA
If LoadLibrary is indeed needed it should be accompanied with a FreeLibrary and we probably need a comment for the why as well. Does it matter if we call FreeLibrary on the library we are testing? I don't think we will be able to free it before the end of the tests when anyhow it will be unloaded by the process shutdown. But maybe I should care more about elegant code? Mikolaj Zalewski
Re: [comctl32/tests #3] Use GetModuleHandleA instead of LoadLibraryA
I've changed GetModuleHandle to LoadLibrary because when I compiled only tests/rebar.c as standalone, the comctl32 wasn't loaded and GetModuleHandle returned NULL. Are there advantages from using GetModuleHandle? Mikołaj Zalewski
Re: msi: Revert commit 96e4320feb22b3a2c9564de100c09990622edb59
I have no idea what Mikolaj tried to fix with this patch but As I wrote in http://www.winehq.org/pipermail/wine-patches/2007-October/045479.html the problem was in the Photoshop CS2 installer where the groupbox consumed mouse events. They didn't arrive to the edit box (which was created earlier) what caused it to appear to be disabled. I checked that in that installer the groupbox had the BS_GROUPBOX style. Maybe that depends on some flags? Mikołaj Zalewski
Re: [3/4] msxml: Implement removeAttribute
A problem with this patch is that the user may have an IXMLDOMNode * reference to the attribute node being removed. The xmlFreeProp will free the xmlnode so accessing the IXMLDOMNode could result in memory corruption. Under MSXML it's possible to access such node and even reconnect it e.g. to a different documents (at least I seem to remember such a thing for element nodes). I don't think supporting it is possible with our current reference counting only for the whole document. I was thinking about also keeping reference counts for each connected component and each node. The connected component count could be used to determine if the node can be freed in such a situation and the node count could be used to update the connected component counts if the tree gets split. But so far I haven't written any code (Another possibility is to keep in each node the refcount of the whole subtree starting in this node. This is more elegant but it would take a linear time with respect to the tree height to update the refcount). Mikołaj Zalewski
Re: comctl32: remove unneeded todo_wine, because test pass
I can pick a new coordinate to fix this, but then the new hit test will be just as brittle as the current one. Anyone have better ideas on how to make these coordinate based tests more robust? For the toolbar tests I have been sending WM_SETFONT with GetStockObject(SYSTEM_FONT) . It seems to work fine. For the default font the results will vary depending on if corefonts are installed or not. Mikolaj
Re: wine.inf: add some four keys in Active Setup\Installed Components [resend]
Robert Shearman wrote: You might want to find four real components always present on Windows to add to this key. From the keys present on my system I could add HTML Help, DirectDrawEx and some two versions of .NET Framework but I didn't know if it wouldn't interfere with some setup programs - e.g. they would claim the information is incomplete because the others subkeys of Active Setup are missing. Especially that it seems there is no official documentation of it. On the other hand from what I've found on some forums adding new keys is something what sysadmins sometimes do to run software for all users so it should be safe. But if it's better to add real keys I can change the patch. Mikolaj Zalewski
Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources
Dmitry Timoshkov pisze: Mikolaj Zalewski [EMAIL PROTECTED] wrote: Then there is no point in using FreeType for loading font files at all, (or adding support for new font file formats to FreeType) since FreeType can load fonts from memory. Do you mean that in AddFontResource I shouldn't try to call WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work as at least according to MSDN the parameter to AddFontResource can be a FNT file or a Win16 NE executable) or that in AddFileToList I should not make a distinction between memory and file fonts but always load the font from memory, mmaping it before if necessary? I mean that we should choose from either leaving the task to FreeType, or doing the whole job of loading the font files internally in Wine. I admit I don't understand - what would we gain from doing all the loading internally in Wine? Wouldn't that be simply rewriting a big part of freetype? You wrote that loading fonts from memory will help but isn't FT_New_Memory_Face using the same parsing code as FT_New_Face and only the source differs? Anyhow it looks to me as something rather orthogonal to this patch as I don't try to parse the content of the font but only remove the PE wrapping. Mikolaj Zalewski
Re: gdi32[3/3]: if freetype fails try to load manually fonts wrapped as PE resources
Then there is no point in using FreeType for loading font files at all, (or adding support for new font file formats to FreeType) since FreeType can load fonts from memory. Do you mean that in AddFontResource I shouldn't try to call WineEngAddFontResourceEx but do only a LoadLibraryEx (that won't work as at least according to MSDN the parameter to AddFontResource can be a FNT file or a Win16 NE executable) or that in AddFileToList I should not make a distinction between memory and file fonts but always load the font from memory, mmaping it before if necessary? This code snippet causes a stack corruption since load_enumed_resource has wrong calling convention. I wonder whether gcc issued a warning here. Thanks for catching it. I haven't noticed a warning but I think there should have been one. Mikolaj Zalewski
Re: wine.inf: add Internet Explorer AppPath registry key
Why don't you try it yourself and see if it works? When I tried it last time it didn't work at all - it wrote it can't find Microsoft servers. But now I gave it another try and it worked with the AppPath (it doesn't work with `winetricks fakeie6` - the Version and VersionVector should not be filled for IE to install). Mikołaj Zalewski
Re: user32: CallWindowProc[AW] for mismatched built-in winprocs should take into account if the window is Unicode (with testcase, fixes bug #9198)
static const char classA[] = deftest;
static const WCHAR classW[] = {'d','e','f','t','e','s','t',0};
+WCHAR unistring[] = {0x142, 0x40e, 0x3b4, 0}; /* a string that
would be destoryed by a W-A-W conversion */
Any other string should work just fine. In the current form the test
will fail
for some locales.
It will work as this string is never converted to ANSI. On the other
hand if there is a conversion to ANSI I expect it to fail on any locale
as the characters are chosen each from a different script. And that's
why this string was chosen - to show that we shouldn't try to convert
the result of the ANSI function but call the wide function directly.
As for the other suggestions I'll send soon an improved patch.
Mikolaj Zalewski
Re: comctl32: tooltips: avoid buffer overrun (spotted by [EMAIL PROTECTED], bug #8361), make sure some strings are NUL-terminated
Alexandre Julliard wrote:
Mikołaj Zalewski [EMAIL PROTECTED] writes:
@@ -389,10 +390,10 @@ static void TOOLTIPS_GetDispInfoW(HWND hwnd,
TOOLTIPS_INFO *infoPtr, TTTOOL_INFO
sizeof(ttnmdi.szText)/sizeof(ttnmdi.szText[0]) : INFOTIPSIZE-1;
lstrcpynW(infoPtr-szTipText, ttnmdi.lpszText, max_len);
if (ttnmdi.uFlags TTF_DI_SETITEM) {
-INT len = max(strlenW(ttnmdi.lpszText), max_len);
+INT len = min(strlenW(ttnmdi.lpszText), max_len);
It the text is really allowed to not be null-terminated then calling
strlenW on it is wrong in any case. It does seem surprising though,
are you sure we really need to support this?
I forgot that only lstrlenW has an exception handler. There is a
(somewhat broken) support for non-NULL-terminated string it in the
current code and I don't know why it was added so I didn't want to
remove it. But the main part of the patch is the min instead of max.
Should I change strlenW to lstrlenW or should I remove the
non-NULL-terminated support?
Mikolaj Zalewski
Re: SUBLANG Rules
I think the best thing is for Wine to support things like LC_ALL=nn nb LANG=nn nb because even though we provide a Nynorsk translation, most programs will only be available in Bokmål. It seems that Vista supports many user preferred languages and many system fallback languages so it should possible to implement. But I don't know how it works under the hood. Are the functions from ntdll documented somewhere? I've put Chinese and Portugese on the Wiki as languages using sublang codes because we already have distinct translations for different variants using the sublang codes. Also as far as I know the variants are quite different and in other open source projects they also usually have distinct translations. But of course it would be interesting to learn what native speakers think about it. Mikolaj Zalewski
Can we catch access violation exceptions in tests?
I'm trying to write a tests for invalid cbSize in Shell_NotifyIcon. The behaviour under Windows XP is to assume in such a case that the size is NOTIFYICONDATA_V1_SIZE. AFAIK Shell_NotifyIcon doesn't provide a way to read icon data to check that the data introduced after Win95 is not modified. So I'm using VirtualAlloc+VirtualProtect to make Shell_NotifyIcon fail if it tries to access this data. I'd like to catch the exception to make a tests fail if something goes wrong instead of crashing the testsuite. However __try doesn't work under gcc and using wine/exception.h gives an unresolved symbol '__wine_handle_exception'. Is it possible to catch exceptions in tests? Mikolaj Zalewski
Re: shell32: check cbSize in Shell_NotifyIconW to make apps sending garbage work (fixes bug #7940)
Dmitry Timoshkov wrote:
Mikolaj Zalewski [EMAIL PROTECTED] wrote:
+/* The validation is also done in explorer. However we must also
do it
+ * on the client size so that WM_COPYDATA doesn't crash the
application
+ */
+if (nid-cbSize != NOTIFYICONDATAW_V1_SIZE
+nid-cbSize != NOTIFYICONDATAW_V2_SIZE
+nid-cbSize != NOTIFYICONDATAW_V3_SIZE
+nid-cbSize != sizeof(NOTIFYICONDATAW))
+{
+WARN(Invalid size\n);
+return FALSE;
+}
Do you have a test case for this?
I was testing this but now I see my tests failed because the hWnd was
invalid. With a valid hWnd this works even for an invalid cbSize, so
this patch is wrong. I'll try to check tomorrow how that should be done
correctly.
Mikolaj Zalewski
Re: localui: add Polish translation
+#include ui_Pl.rc You missed the translated File, but it would be nice, when you wait a week please: I have a Patch for AddPortUI, that add more strings and a Dialog and the Patchs grow whith more translations. I forgot the git add. But then I won't resend it but I'll wait for your patches. Mikolaj Zalewski
Re: comctl32: toolbar[1/4]: avoid using CopyImage as it doesn't work well when the DDBs are RGB565 (fixes bug #7905)
Since it clearly sounds like a CopyImage bug it would be more appropriate to fix CopyImage instead, Microsoft may do that at some point as well. I was a bit affraid that even Windows Vista has this bug so there might be apps depending on it. However it would be strange for some app to depend on it so if you think it's better to patch CopyImage I'll send a patch for it. Mikolaj Zalewski
Is anyone using wrc --verify-translation?
For my translations statistics (http://pf128.krakow.sdi.tpnet.pl/wine-transl/) I use a patched wrc that has a different output for wrc --verify-translation. Could I send this patch to wine-patches or is there someone other using wrc --verify-translation and would be upset if the format changes (in such a case I could try to keep both formats lauched by different options)? I'm asking because I've contacted Jeremy Newman about integrating the statistics with WineHQ and having the patch in the official tree would probably simplify the maintenance. Mikolaj Zalewski
Re: netapi32 tests not linked with netapi32.dll
Paul Vriens wrote: Hi, Could anyone think of a reason that the netapi32 tests are not linked with netapi32.dll although this is specified in the Makefile? It looks like the tests doesn't call directly any function from netapi32. In such a case the compiler can skip linking the DLL (e.g. VC++ does it). Mikolaj Zalewski
Re: comctl32: CreateToolbarEx should send TB_SETBITMAPSIZE twice (fixes bug #6392)
If you're testing what message is sent, why not use the message sequence testing code? That's true that a message sequence test would be better. I haven't thought about it. Mikolaj Zalewski
Re: MikoX, aj Zalewski : user32: tests:Using DefWindowProcA with RegisterClassW works under Windows.
The test doesn't pass here under XP: I've also tested it under (a fully patched) XP. However it might be a differance in compilers - in your output the pointers to DefWindowProc[AW] looks like pointing to the EXE image. What compiler did you use? I've used Visual C++ 7.1 and get pointer pointing to user32. Could you do: printf(%p, %p, %p\n, DefWindowProcA, GetModuleHandle(NULL), GetModuleHandle(user32)); I get: 77D4D4EE, 0040, 77D4 Mikołaj Zalewski
Re: comctl32: register all the controls in DllMain (fixes bug #7641)
Could it be that 6.0 only registers those controls listed using window class dependencies in the manifest file? If what you say about 5.82 is true your patch is correct though ofcourse. I've checked both 5.82 and 6.0 (with a standard manifest) and both registers all the classes. I don't know if it's possible to list window classes dependancies in the manifest and how comctl 6.0 treats it. But as currenly we don't parse the manifest file we couldn't do anything with this. Mikolaj Zalewski
Re: comctl32: rebar: rewrite the layouting code
Robert Shearman napisał(a): Mikołaj Zalewski wrote: I've been trying to fix the rebar layouting code. But fixes in one place caused regressions because of bugs in other places and I ended up rewriting the whole layouting code. It does roughly the same as the current code however the details are quite different and I hope more correct. It's also much shorter so it should be earier to understand/debug. My code work for me for all apps I tested (except for the sidebars of IE but I'm trying to find out why). It also passes some tests I've written and produces identical results that the native. Two things could be potentially better in the old code: - it contains some support for RBBS_FIXEDSIZE (however different from what Windows does) - it can break rows to fill the given space (but that should be only done for RBS_AUTOSIZE rebars) I have yet to test the REBAR_Maximize and REBAR_Minimize but I have two questions. Does this code cause regressions in apps that works with the current code and would such big patch be accepted? I haven't got any apps to test with (other than IE and it looks like you've already tried that), but nice work! I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. For the next week I won't work on wine but what should I do later - would such a big patch be accepted? Mikolaj Zalewski
Re: comctl32: rebar: rewrite the layouting code
Dan Kegel wrote: Mikołaj wrote: I've tested it also with WinRAR, WinSCP3 3.30, 7-Zip and Pirch98 (the last two have Bugzilla entries and are fixed by the new code). The only thing I've found not to work are the sidebars of IE. Did they work with the old code? WinRAR did. Other had bigger or smaller problems. For the next week I won't work on wine but what should I do later - would such a big patch be accepted? As long as it doesn't cause regressions in IE, probably, though adding more conformance tests would make acceptance more likely. IE sidebars didn't work before and the main toolbar seems to work OK. Even the sidebars seems to work slighty better as some horizontal toolbar are now visible. Next week I'll add some more tests - especially I'd need to test RB_MAXIMIZE/RB_MINIMIZE and changing the band cx. Mikolaj Zalewski
Re: shell32[2/3]: add a confirmation dialog with a Yes to All option
The usual convention is that IDD_* are used for IDs of dialogs and IDC_* are used for IDs of controls. The Browse For Folders dialog uses IDD_ for controls and I wanted to follow the convention in this file. Mikolaj Zalewski
Re: shell32: shlfileop tests: avoid buffer overflows for paths
@@ -329,8 +329,8 @@ static void test_delete(void)
static void test_rename(void)
{
SHFILEOPSTRUCTA shfo, shfo2;
-CHAR from[MAX_PATH];
-CHAR to[MAX_PATH];
+CHAR from[5*MAX_PATH];
+CHAR to[5*MAX_PATH];
DWORD retval;
shfo.hwnd = NULL;
This is really hacky. If this is fixed, it needs to be fixed properly.
I thought this is enough - we never put more that three paths in the
buffer and tester probably won't have paths longer than MAX_PATH as they
are not supported by the shell.
What do you mean by a proper fix - some overflow checking in
set_curr_dir_path and skipping the rest of tests in such a case?
Mikolaj Zalewski
Re: loader: Mark the stack as executable if possible.
AFAIK by default Windows XP enables the no-exec protection only for essential Windows programs and services. I couldn't find what that means but it's described as if it is a fixed list of Windows system binaries. The protection can enabled for all programs (except for a list provided by the user) in System Properties Advanced Performance Data Execution Protection. Then when a program executs data it is killed and a dialog like this is shown: http://img.microsoft.com/library/media/1033/technet/images/prodtechnol/winxppro/deploy/appcom/acxpsp37.gif . After clicking Change Settings the list already contains the buggy program and it's enough to check the checkbox for the program to work the next time. AFAIK this OptOut mode is the default for Windows Server 2003. Apart from these OptIn and OptOut modes by a manual change of system boot params it's possible to set AlwaysOn and AlwaysOff modes. Also the documentation says that the DEP is always enabled for x64 programs regardless for the NoExecute setting. Mikolaj Zalewski
Re: When to use SUBLANG_NEUTRAL
Actually there's now some differences for the German and Austrian sublang spellings of some words. I'm not sure how windows handles the new spelling rules used in Germany now, though. I admit I don't know how large are the differances between German and Austrian spelling but as Frank Richter wrote there is no problem to provide some resources in a German/Austria translation (I assume the resources currently use the German spelling?). IMO the question is what would an Austrian user (who have chosen German as his preferred language) want to see if there is no such translation: the German spelling or English? I don't know the answer but I'd expect that if the differances are minor then German? Mikolaj Zalewski
Re: When to use SUBLANG_NEUTRAL
Christoph Frick wrote: He or she wants de; anything else would be like: ``there is no en_UK? then lets use mongolian!``. So it looks like SUBLANG_NEUTRAL is the best choice. I could make a patch to modify all the sublang code in German files to SUBLANG_NEUTRAL. Mikolaj Zalewski
When to use SUBLANG_NEUTRAL
As I wrote I've found that there is a mess in wine with the usage of SUBLANG_NEUTRAL and SUBLANG_DEFAULT. I tried to understand when to use which and wrote a wiki page about it: http://wiki.winehq.org/SublangNeutral . It contains some generic information about it but I thought that it would be best to have also a list of languages for each case. I've took the wine languages list and sorted the obvious cases. There are however 7 languages which have many sublangs and I don't know if they should have one generic translation or be translated into each sublang. If someone knowing one of these languages could CutPaste the language from the undecided list to one of the lists, I think it would help. Mikolaj Zalewski
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
the test could force the user backend (see the console test in kernel32 directory) I see - I haven't noticed that --use-event automatically chooses the user backend. Mikolaj Zalewski
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
case WM_LBUTTONUP:
-if (data-curcfg.quick_edit)
+if (data-curcfg.quick_edit || PRIVATE(data)-has_selection)
{
if (GetCapture() == PRIVATE(data)-hWnd
PRIVATE(data)-has_selection
(wParam MK_LBUTTON))
{
WCUSER_MoveSelection(data, PRIVATE(data)-selectPt1,
WCUSER_GetCell(data, lParam));
ReleaseCapture();
-PRIVATE(data)-has_selection = FALSE;
this looks suspicious to me ? how to do end the selection ? the only
time you do it is when a second button down :-/
The selection is cancelled if the hits Enter to copy the data to the
clipboard (or after the later patch hit any other key to cancel). The
current behaviour is strange as why to select a rectangle with a mouse
if it will be unselected on WM_LBUTTONUP? Currectly the user would need
to keep the mouse button down and press Enter to copy the data and have
any use of the mouse selection.
Mikolaj Zalewski
Re: wineconsole[5/6]: when selection with the mouse, any key except for Enter should cancel the selection
as a principle, why do oppose keyboard selection to mouse selection looks to me you could in principle do both... so any key except return, arrow keys should end the selection and you woun't need the extraneous mouse_selection I wanted to make it in the same way as on Windows. But I think it's a good idea to allow keyboard movements on mouse selections and always canceling the selection with the keyboard. I'll rewrite the patch and resend it. Mikolaj Zalewski
Re: wineconsole[3/6]: remove spaces from the ends of lines while copying to the clipboard
did you check that this behavior is done for every mode of the console ? A+ What do you mean by every mode? Mikolaj Zalewski
Re: wineconsole[4/6]: allow making selections with a mouse also when not in the QuickEdit mode
but your code doesn't release the selection on button up, which is rather strange when you do only mouse selection A+ I've checked it and currently the whole section is dead code as on WM_LBUTTONUP the (wParamMK_LBUTTON) is always false. However if I remove this condition I think my code is correct. I release the mouse capture - that's enough as the handler for WM_MOUSEMOVE and WM_LBUTTONUP checks if GetCapture() == PRIVATE(data)-hWnd. Setting has_selection = FALSE would means that the seletion has been removed - there would be no way to copy it to the clipboard. Also the window is not updated to show that the selection is removed. I'll check if the spaces are removed for other console modes. I don't know if it's possible to write an automatic test as this requires mouse interaction, I don't know how to get a hWnd of a console windows. Also it would fail on wine as by default it starts the ncurses backend. Mikolaj Zalewski
Re: [Korean] Use the SUBLANG_NEUTRAL in Korean resources.
It should make no differance for Korean is you use SUBLANG_NEUTRAL or SUBLANG_DEFAULT as there is only one sublang. SUBLANG_NEUTRAL is a fallback that is used if no translation is available in the user's selected sublang. In can be used for locales that have many sublangs (e.g. French have French (France), French (Belgian), French (Canada), French (Swiss) etc) but the language is the same so it's enough to make one translation. While making the translations statistics I've found that SUBLANG_NEUTRAL and SUBLANG_DEFAULT are often randomly mixed. Maybe I should make a wiki page where people knowing the language could write if it requires separate translations for each sublang or one translation with SUBLANG_NEUTRAL and then update all the files? Mikolaj Zalewski
Re: user32[2/3]: send a WM_MOUSELEAVE even if another window calls TrackMouseEvent before the timer proc is called
Alexandre Julliard wrote:
Mikołaj Zalewski [EMAIL PROTECTED] writes:
@@ -949,6 +954,12 @@ TrackMouseEvent (TRACKMOUSEEVENT *ptme)
}
}
} else {
+/* In our implementation it's possible that another window will
receive a
+ * WM_MOUSEMOVE and call TrackMouseEvent before TrackMouseEventProc is
+ * called. In such a situation post the WM_MOUSELEAVE now */
+if (tracking_info.tme.hwndTrack != NULL)
+check_mouse_leave(hwnd, hittest);
+
Shouldn't you check for TME_LEAVE first?
Yes, we should. I'll send a corrected version.
Mikolaj Zalewski
winetest question
Why does winetest start programs with STARTUPINFO.wShowWindow = SW_HIDE? I think this makes some of the toolbar tests fail as they depend UpdateWindow sending a WM_PAINT (they fail when launched by winetest but pass when running comctl32_test.exe from the command line). Could I remove this line or call ShowWindow twice to cancel this effect? Mikolaj Zalewski
Re: shlwapi: Resupply array sizes stripped by function interface
I am now inclined to think - and in line with what you say - that it would be safer and more efficient to modify FillNumberFmt() to take two more arguments and pass the buffer sizes in as well, i.e., in effect, its declaration should be: static void FillNumberFmt(NUMBERFMTW *fmt, LPWSTR decimal_buffer, int decbuf_wlen, LPSTR thousand_buffer, int thoubuf_wlen); Does that sound better? -- Andy. Yes, it's probably more elegant to send the buffer sizes explicitly as a parameter than to use a constant. Mikolaj Zalewski
Re: shlwapi: Resupply array sizes stripped by function interface
Andrew Talbot wrote: Dan Kegel wrote: BTW the way you define the new size, as a magic constant, seems bad. Can you use 4 * sizeof(WCHAR), or whatever, instead of 8? And even then, the '4' seems almost as bad. - Dan Yes, I did feel uneasy about using a magic constant, I must admit. Another way to handle it would be to call GetLocaleInfoW() twice for each buffer. The first time with its lpLCData parameter equal to NULL and its cchData parameter equal to zero, which should return the number of characters required for the buffer. The second time to then retrieve the required locale information. I had originally decided against this, because I felt that it might be over-engineering, but how does that sound to you? I've wrote that code and forgot that sizeof(parameter array) is the size of a pointer. The current code will actually work as in current wine there is no locale that has more than one character (plus the NUL terminator) for the decimal or thousand separator but it's better to fix it to use the whole buffer in case a locale with a strange separator is added. I've chosen the value 8 because I can't imagine a longer separator. I agree #defining a constant for it (and using it in FillNumberFmt, FormatInt, FormatDouble) would be good but writing it as 4*sizeof(WCHAR) isn't a good idea as the fourth parameter is the number of characters, not the number of bytes. Mikolaj Zalewski
Re: shlwapi: Resupply array sizes stripped by function interface
Andrew Talbot wrote: I am about to submit another try, to see what people think. This time I'm using GetLocaleInfoW() twice for each buffer: once, to determine the size needed, and again, to actually get the locale info. I'm afraid this is worse than it was - if a separator will happen to be longer than 7 characters plus NUL you will write part the end of the buffer (the buffers in FormatInt and FormatDouble are 8 characters long). If you really want to support strings of any length you should allocate the buffer dynamically. But IMHO that would be a wait of time for you and the CPU executing such code. I'd expect #defining a constant for the 8 as the buffer length should be enough. As for the changelog entry I'm not an expert but maybe shlwapi: bugfix: sizeof(array passed as a parameter) can't be used to count it's elements would be better? Mikolaj Zalewski
Wine translations statistics
To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Mikolaj Zalewski
Re: Wine translations statistics
To check what needs to be translated I have played a bit with wrc --verify-translation and made some HTML from it's results. As this might interest other translators I've put the statistics at http://pf128.krakow.sdi.tpnet.pl/wine-transl/ . Very nice! It would be cool if we could integrate this on winehq.org. Care to try that? Yes, I could try to do it. However I would need to know where could I find some winehq.org pages source codes that could be used as an example, how to send my code (also through wine-patches?) and how to update the data files for the pages (e.g. I could send my scripts to be run on winehq or do it on my server and upload the results to winehq?). Mikolaj Zalewski
Re: Wine translations statistics
Nice one! I'll see if I can update some of the German resources. One thing I noticed is that the message table in kernel32 is treated as one resource in the statistics, although it contains quite a number of strings itself. Maybe wmc can be augmented with some --verify-translation equivalent as well... Yes, currently every resource is counted as one (also a string table that could have up to 16 strings or a menu with many items). Maybe if someone will start translating the kernel32 message table I'll look into it. As of the German translations I've found that in many resources there is LANG_GERMAN, SUBLANG_DEFAULT. So when starting e.g.: LANG=de_AT winecfg the translation is not used. Wouldn't LANG_GERMAN, SUBLANG_NEUTRAL be better? (however I don't know if locales like de_AT are set up by Linux distributions) Mikolaj Zalewski
Re: shell32[1/2]: document the shell32 mini-COM functions
Maybe you've seen it already, but this blog post talks about the various allocators: http://blogs.msdn.com/oldnewthing/archive/2004/07/05/173226.aspx -f.r. Yes, that's where I learned about it (a link to it is included in the documentation of SHLoadOLE) Mikolaj
Re: tools[1/2]: wineprefixcreate: create a freedesktop-enabled menu directory
+NameApplications/Name +Menu +NameWine/Name +LegacyDir__HOME__/.wine/menu/LegacyDir +/Menu +/Menu Why are you hard-coding this path to being .wine? You correctly used $WINEPREFIX before. I've forgot about WINEPREFIX here but when I added it there is a problem that wineprefixcreate is called with a directory like ~/.wine-F6YHsT . If we make a reference to such a directory it won't work. Maybe we could keep it that wineprefixcreate creates the default file and document somewhere how to create the menu files if someone creates a custom wineprefix. Alternatively I could add a parameter to wineprefixcreate with the final name of the directory and make the menu filename dependent on this path. Mikolaj
Re: All right, let's solve these .desktop issues forever
I was investigating the menu problems and now I'm back so I could try to fix it. The problem is with the support for the new freedesktop.org standard. In it the /usr/share/applications and ~/.local/share/applications contains a flat list of applications while the menu structure is controlled by XML files. Thus adding items to ~/.local/share/applications is harder than adding them to legacy directories as the XML files would need to be updated. There is however a possibility to add an XML file that includes a legacy directory where the menu structure is given by the directory structure. That would be the easiest way to quickly fix this problem. I've attached a simple menu file that could be created by wineprefixcreate. It should be copied to ~/.config/menus/applications-merged/ and ~/.config/menus/kde-applications-merged/ directories and the path in it should be fixed - username changed to the actual user name. After copying the files from ~/.kde/share/applnk/Wine to ~/.wine/menu the items should be visible in the menu (I think it's a good idea to keep the .desktop files in ~/.wine). If anyone would test it I would be glad to know how it works. There is a small problem that KDE scans the ~/.kde/applnk directory (unlike Gnome that scans only the global directories /usr/share/applnk and /etc/X11/applnk and that why the menu is not visible) and after this change will display the menu items twice. This can be fixed by creating the .desktop in legacy directories with OnlyShowIn=Old;. If this sound good I can send patches to winecreateprefix and wineshelllink with these fixes. Mikolaj Zalewski Applications Wine /home/username/.wine/menu
What's wrong in my Trash patches?
I've sent patches to implement the trashing of files (starting from http://www.winehq.org/pipermail/wine-patches/2006-July/028782.html ) and they were rejected. Could someone tell me what's wrong with them? Mikolaj Zalewski
Shell integration
I've changed the code not to use COM. Now it loads a DLL and searches for a GetIntegrationObject entry point. That function returns structures with a pointer to the ops structure. This is similar to how GDI objects are implemented. One could also export all the function from the DLL and build the ops structs on the client side (like it is done in GDI/User drivers) but that would require more code to be written and make it harder to forward all the unhandler objects from e.g. the kde driver to the freedesktop driver - we would need to add entry point forwarding every time we add a new functions to the freedesktop driver. Is this approach good? Mikolaj Zalewski shell-integr.patch.gz Description: GNU Zip compressed data
Re: Shell integration idea
The number of developers that understand COM aggregation and all the baroque rules that make it up is very, very low. A simple ops struct of function pointers as used in the wineserver or kernel would be fine here ... COM adds an awful lot of complexity that really isn't needed at all (eg you must call CoInitialize, which means caring about apartments, which means possibly instantiating a STA when windows wouldn't, which means pain). OK, I won't insist on aggregation :). As for apartments I've thought that something like that: HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED); /* working with objects with ThreadingModel Both */ if (SUCCEEDED(res)) CoUninitialize(); won't have any side effects. But if the number of developers that knows about COM is low then maybe that it's better to use simple ops structs instead. Mikolaj Zalewski PS: I will be absent during the next week so I won't be able to reply to e-mails.
Re: Shell integration idea
I think the general approach is good. The way you handle the built in implementation seems odd to me. I think setting the registry key to make the freedesktop.org version as the default would be good enough. If we don't have built-in trash etc. objects then when we add a new object we will require all the implementations have it, with no backward compatibility. However this should not be a big problem as the freedesktop.org implementation can be kept up-to-date with shell32 and the other implementation can fallback to it if they don't support a specific object. I'm not convinced we need IWineShellIntegration. I think it would be cleaner to directly create an IWineTrash object. If we integrate more closely with the desktop environments we may need to have one central object that will know that e.g. KDE 3.4 uses the freedesktop.org Trash but KDE 3.3 has it's own Trash implementation. If we read the Trash CLSID from the registry such an implementation would require creating proxy classes or hacks in the class factory. Also by storing only one CLSID we don't have a problem which implementation to use if a new kind of objects is introduced. Of course when we use COM aggregation instead of a factory pattern we will have all the interfaces visible under one CLSID so we will be able to construct a IWineTrash directly with the main object hidden behind the scene. Mikolaj Zalewski
Re: Shell integration idea
Alexandre Julliard wrote: I think using COM for that sort of thing is overkill. If we want to allow multiple implementations then using a structure with callback functions is probably the easiest way. If we are using structures with callback functions then why not to make it COM interfaces - IMHO the overhead of adding the QueryInterface, AddRef, Release is relatively small and we obtain structures with which probably most of developpers are more of less familliar. Besides, you most likely want to put all of that in the explorer process, and communicate with shell32 using the same protocol that Microsoft is using, like we do already for the system tray. For the Trash I don't know if there is any protocol. I've placed a DELETE security audit on a file and it was the application trashing the file that triggered it - so it seems Windows also doesn't need to communicate with the explorer. For things like file associations, to maintain compatibility we will need to keep the settings in the registry. What we can do is to mirror the changes to the Linux database. That's a feature that is not present in Windows so we can choose a protocol. Mikolaj Zalewski
Shell integration idea
As a SoC project I'll try to improve the integration of wine with the Unix shells. My first step will be to implement the freedesktop.org Trash. I've written some code that doesn't add any new features but shows how I want to add it. I'd like to know if this is a good design? The main idea is not to hard-code one implementation of things like the Trash into shell32 - not everything is standardized by the freedesktop and even if it would this might not work on other systems like MacOS X. We should allow for many implementations. The correct one is loaded depending on a registry settings (so that a winecfg entry can be added). My implementation uses COM objects as it's standard dlls provides support for such tasks. Currently there is one interface (IWineShellIntegration) that acts as a factory for specialized objects. That could also be implemented using COM Aggregation - when we do that we could use QueryInterface instead of GetIntegrationObejct. Some COM objects can run in the address space of the calling process - e.g. the trash can be implemented like that. For others it would be a waist of resources (e.g. there is no need for every process to watch is the file associations have changed) - it's enough to load them only once. The explorer seems to be a good candidate to create such objects. In the attached patch there is one specialized interface - the IWineTrash. The SHELL_DeleteFile[AW] is patched to use it - it shows a different icon if the file can be trashed (these are not the correct icons as wine's shell32 uses a message box instead of a special dialog) and calls the trash method then. Currently there is only one built-in trash that can't trash anything. (note that SHELL_DeleteFile is called in the folders that are decendents of My Computer. If choose delete on a file that is a decendent of the '/', it will be deleted without a warning). Mikolaj Zalewski integration.patch.gz Description: GNU Zip compressed data
Re: comctl32[1/8]: header: don't check lpItem for NULL in GetItemT
You will need to split this patch into two. Checking for NULL has nothing to do with callback. Also I'm not sure why are you removing NULL check? Any explanations, tests? This patch is already split into eight parts - I hope thay are small enough. That's true the first patch doesn't have much to do with callbacks but without it the other patches would have offsets during patching. I've removed the checks because lpItem can't be NULL (lpItem = infoPtr-items[nItem]) and I thought it's useless to have conditions that are always true. From the CVS history it seems that in the past lpItem could be NULL for out-of-range indexes but after some time GetItemT was changed to return FALSE in such cases but the checks remained. Mikolaj Zalewski
SoC proposal: shell integration
I've had an idea for a SoC project and filled the application. In a comment I was advised to discuss it on wine-devel. The idea is to integrate the wine shell32 with the Linux desktops. The main problem is of course that there are many desktop environments and only some things are standardized by freedesktop.org. Even if all is standardised the wine's shell32 might be used on other platforms like MacOS X which, I guess, doesn't comply to freedesktop.org. That's why I think the implementation should allow many implementations of e.g. the trash or MIME database through e.g. COM interfaces. The actual implementation used will be configured by winecfg/registry or (if I will a way to implement it) autodetected. There would be one generic library (e.g. shell32_unix) implementing mainly the freedesktop standards with no dependencies on desktop environments (DE) libraries. If this generic code would integrate badly with a DE then a specific implementation would be provided by specific libraries (e.g. shell32_gnome, shell32_kde) that could link to the DE libraries. Of course if there are no libraries for a specific DE on the host system then the appropriate shell32_* isn't built. I would focus on recent version of KDE and Gnome and I thought of implementing: - The Trash. The freedesktop has a nice standard. It is a draft but it seems KDE from version 3.4 is already using it so wine would integrate with them. Gnome is using another Trash format but if that would be a big problem I could provide an implementation in shell32_gnome through the Gnome libs. The shell32 would contain a stub implementation of the Trash that would say no trash is available - so that shell32 could work even if the shell32_unix is not available. - The Start Menu. This is currently handled by wineshelllink but if we'd like to implement file associations we might need more control over it. Creating the 'app.desktop' file is easy. A bit harder is to know where to create it. The freedesktop standard specifies a standard place for the file. The older version of KDE and Gnome used different directories (usually ~/.kde/share/applnk or ~/.gnome/apps) but their shell32_* libraries could check the version of the DE and if it is old store the app.desktop in the DE private directory obtained by a DE library call. There could be a problem with detecting the Windows Start Menu changes. The links creation can be trapped in IShellLink like it is currently done but traping link removal can't be done that way as it is done with filesystem calls bypassing the shell32. We may need to put a filesystem change notify on the start menu directory and start a synchronization program if a change is detected. - The file associations. This might be the hardest part. If we detect a change to the Windows associations (here again we might need to put a change notify on HKEY_CLASSES_ROOT) we should get the class MIME type from the registry. If there is no we search the Linux MIME database for this extension. If none was found we can make a dummy one e.g. applicaton/x-wineapp.extension.xxx. If the found/created MIME type is not in the Linux database we should register it. The next step is to check if this application has a menu item. If there is no we should create a hidden one. Once we have the menu 'app.desktop' file we add the line that it handles the specified MIME type. (there are three MIME databases I think we should care about - the freedesktop /usr/share/mime the KDE /usr/share/mimelnk and maybe the old Gnome /usr/share/mime-info) Where was also a comment that this may be to much for one summer. If implementing only a part of this plan is enough then of course I'll agree. Mikolaj Zalewski
Re: SoC proposal: shell integration
Segin wrote: If this was to be done, there are a few things I suggest: First should be everything that Freedesktop.org has laid out, and nothing more. That does into the FD.org integration code. For a lot of this to work, Wine may have to be ran as a system service (is that even a good idea?). I don't know what you mean by a system service but there will be no need for a new kind of processes. The Trash code can run in the client's process. Checking the Start Menu and HKEY_CLASSES_ROOT needs to be done in a separate process/thread and but as I see the wine explorer is used for such tasks. No privileges are required as the code can create the menu items/MIME entries in the home directory (and it is probably the desired way as by default wine is installed in each home directory for the current user only). Each part of the integration profiles that is Wine-specific code should be done like the audio drivers, a Wine .drv.so or similar. shellfdorg.drv.so for Freedesktop, shellkde3.drv.so for KDE 3, shellkde.drv.so for generic KDE (stuff that works on both 3 and 4), and so on. I was thinking about COM interfaces. Then the code would be in regular DLLs with no need for a special infrastructure. The shell32_unix.dll from my proposal was what you call shellfdorg.drv.so, the shell32_kde.dll is the shellkde.drv.so etc. Mikolaj Zalewski
Re: Comctl32: fix listview column resize [2/2] (resend)
The Drivers-Listview in winecfg works now (thanks for that fix), but the Listview-Issues in winefile are still present. Any Ideas? I haven't noticed them but I'll try to look into them tomorrow. Mikolaj Zalewski
