Re: *** GMX Spamverdacht *** MSYS touch.exe timestamp resolution issue on Wine-1.6
Am 12.10.2013 23:28, schrieb Alan W. Irwin: Under MSYS bash.exe if I use the touch command I only get 1-second resolution when reading the results. bash.exe-3.1$ touch touch1.test touch2.test bash.exe-3.1$ ls --full-time touch*.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch1.test -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch2.test Would somebody be willing to make the above test for MSYS on the Microsoft version of Windows (which I don't have access to) to see if time stamps are being read with 1-second resolution as above. That test should help distinguish whether this is a Wine issue or else an MSYS issue. I have also done some tests with the MSYS find.exe and make.exe commands, and in all cases touch2.test is not newer than touch1.text. This can be an important issue for the make command where one-second time resolution can potentially screw up file dependencies. If I use the equivalent Linux ls (and find and make) commands to read the time stamps on the above files, then touch2.test is newer than touch1.text, e.g., wine@raven ls --full-time touch*.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -0700 touch2.test So I think this implies the MSYS touch.exe command is writing high-resolution (i.e., millisecond) time stamps, and it is only reading that high-resolution time stamp that seems to be an issue for MSYS on Wine. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science _ Sure -- seems to be a MSYS issue though: root@me ~ $ touch touch1 touch2 root@me ~ $ ls --full-time touch* -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.0 + touch1 -rw-r--r-- 1 root Administratoren 0 2013-10-13 13:33:47.0 + touch2 root@me ~ $ uname MINGW32_NT-6.1 root@me ~ $ Have a nice Day ! Thorsten
Re: Small Direct3D milestone . Thank you - Wine team!
Fascinating work - please continue it! Please note that i am exited from Wine as a whole - without people doing the 'unsexy' jobs (eg: COM Work...), Wine would never be succesful. ;) so long, Thorsten Stefan Dösinger schrieb: Hi! With Wine 0.9.37 we've archieved something that I allow myself to call a small milestone - All Direct3D7 Immediate mode SDK demos successfully perform their intended rendering. I have some screenshots on my university junk server: http://stud4.tuwien.ac.at/~e0526822/sdkdemos1.png http://stud4.tuwien.ac.at/~e0526822/sdkdemos2.png Two major problems are left though, namely windowed opengl rendering(see the junk where a menu bar should be) and GetDC(there should be a little bit of text rendered, I disabled render target locking to get proper performance). Some demos have a few smaller problems too. The bump earth and bump waves need vendor specific extensions(GL_NV_texture_shader2 / GL_ATI_envmap_bumpmap) and the bend demo needs GL_ARB_vertex_blend which nvidia does not support. So I took that screenshot on my mac running linux(ati radeon X1600. The mipmap demo renders the mipmaped texture garbled, although this works on nvidia cards. The Z buffer demo says w buffers aren't supported, but the normal z buffer does what the w buffer is supposed to do. What does that mean for gamers? Nothing fancy really, the features used by games are implemented since a long time, the ones that used to miss(fixed function bump mapping, vertex blending) aren't really important for games. Other DirectDraw features like Overlays aren't implemented either, but we are Direct3D 7 feature complete. Where to go from here? I am currently fixing the DirectDraw rewrite regressions I can get hold of, and I am trying to make D3D thread safe finally. From the application point of view my focus will stay on fixing older apps first, which somewhat includes getting thread safety, render target locking and GetDC working properly. My hope is also to fix the other related DX7 sdk demos, like the DDraw demos(except overlays, they are highly tricky with the current wined3d-x11drv integration) and getting native d3drm.dll working. I also want to say thanks to all the small and big helpers who help with technical advise, debugging and regression testing. Special thanks goes to Henri without whom I'd be totally lost and who has to be credited for a huge majority of the shader work in the last half year, and a lot of other things too. Thanks and continue the good work :-) Stefan PS: As for the screenshots, my space on that server is limited, so they will be gone sooner or later. I didn't want to send huge screenshots as attachments, not even as jpgs.
Re: Listview notify_dispinfoT Messageformat
I asked the List about the Problem and how to solve it correctly. Please excuse my bad English (: - will try your patch asap. Tho Why are you saying that. The code treats LVN_GETDISPINFOW special because it's the only type of message that *gets* textual data rather then sending. SO for this reason, we just reset the buffer on the way out. What other difference is there? This leads to problems with Braindamaged_Apps(TM) wich handle only the Unicode Message. (Tested App was Explorer) Heh. Right now we only send ASCII notifications, which would be even worse. We need proper test cases.
Re: Listview notify_dispinfoT Messageformat
Oh, come on, it was just a few more lines of code. In fact, I was happy with the code as it standed (that's no surprise, as I wrote it :)). I think we should just revert to it, and accept changes only with supporting tests. At the time that Aric submitted the patch, I was rather unhappy with it, but he claimed he performed extensive tests that proved that behaviour. He should have submitted them as part of the test suite. As i understand it, the old Listview code was assuming that LVN_GETDISPINFOW is never used and tried to convince apps with the A version of the Message.. This leads to problems with Braindamaged_Apps(TM) wich handle only the Unicode Message. (Tested App was Explorer)
Re: Listview notify_dispinfoT Messageformat
Testing out your more general solution introduced no Problems with the
Listview on my Testsystem.
If the Patch gets applied, i will modify the callers of notify_dispinfo
to respect that isW isnt longer used.
Tho
Robert Shearman wrote:
Thorsten Kani wrote:
Hello,
Testing showed that the current implementation of notify_dispinfoT
doesnt work with W2K. (or at least not with SP4 (: )
The attached patch corrects that our Listview doesnt display anything
on native.
Following assumption proved to be wrong for the Message
LVN_GETDISPINFOW:
/*
With testing on Windows 2000 it looks like the notify format
has nothing to do with this message. It ALWAYS seems to be
in ansi format. */
This time, only LVN_*ETDISPINFOW is patched, anything else is untouched.
-Anybody please tell me if you see problems with this Fix since i
dont want to break things.-
I have seen exactly the same problem with the IShellView
implementation in native shell32. I have attached the patch I did at
the time. I didn't submit it, because I soon got into a tangled mess
where the function name was wrong and the isW parameter completely
unnecessary and a whole bunch of functions calling it were also wrong.
To summarise: *all* common control notifications should be sent in the
same format (ANSI/Unicode) as their parent (except if overriden by the
CCS_SETUNICODEFORMAT message). It should not be based on the message
sent to the control.
Rob
Index: listview.c
===
RCS file: /home/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.394
diff -u -p -r1.394 listview.c
--- listview.c 2 Sep 2004 23:00:53 - 1.394
+++ listview.c 27 Oct 2004 20:16:51 -
@@ -818,10 +818,6 @@ static int get_ansi_notification(INT uni
}
/*
- With testing on Windows 2000 it looks like the notify format
- has nothing to do with this message. It ALWAYS seems to be
- in ansi format.
-
infoPtr : listview struct
notificationCode : *Unicode* notification code
pdi : dispinfo structure (can be unicode or ansi)
@@ -830,14 +826,10 @@ static int get_ansi_notification(INT uni
static BOOL notify_dispinfoT(LISTVIEW_INFO *infoPtr, INT notificationCode,
LPNMLVDISPINFOW pdi, BOOL isW)
{
BOOL bResult = FALSE;
-BOOL convertToAnsi = FALSE;
INT cchTempBufMax = 0, savCchTextMax = 0;
LPWSTR pszTempBuf = NULL, savPszText = NULL;
-if ((pdi-item.mask LVIF_TEXT) is_textT(pdi-item.pszText, isW))
- convertToAnsi = isW;
-
-if (convertToAnsi)
+if ((pdi-item.mask LVIF_TEXT) (infoPtr-notifyFormat == NFR_ANSI))
{
if (notificationCode != LVN_GETDISPINFOW)
{
@@ -861,15 +853,16 @@ static BOOL notify_dispinfoT(LISTVIEW_IN
savPszText = pdi-item.pszText;
pdi-item.pszText = pszTempBuf;
pdi-item.cchTextMax = cchTempBufMax;
+
+notificationCode = get_ansi_notification(notificationCode);
}
TRACE( pdi-item=%s\n, debuglvitem_t(pdi-item, infoPtr-notifyFormat !=
NFR_ANSI));
-bResult = notify_hdr(infoPtr, get_ansi_notification(notificationCode),
-(LPNMHDR)pdi);
+bResult = notify_hdr(infoPtr, notificationCode, pdi-hdr);
-if (convertToAnsi)
+if ((pdi-item.mask LVIF_TEXT) (infoPtr-notifyFormat == NFR_ANSI))
{
MultiByteToWideChar(CP_ACP, 0, (LPSTR) pdi-item.pszText, -1,
savPszText, savCchTextMax);
Listview notify_dispinfoT Messageformat
Hello,
Testing showed that the current implementation of notify_dispinfoT
doesnt work with W2K. (or at least not with SP4 (: )
The attached patch corrects that our Listview doesnt display anything on
native.
Following assumption proved to be wrong for the Message LVN_GETDISPINFOW:
/*
With testing on Windows 2000 it looks like the notify format
has nothing to do with this message. It ALWAYS seems to be
in ansi format. */
This time, only LVN_*ETDISPINFOW is patched, anything else is untouched.
-Anybody please tell me if you see problems with this Fix since i dont
want to break things.-
Tho
Index: listview.c
===
RCS file: /home/wine/wine/dlls/comctl32/listview.c,v
retrieving revision 1.394
diff -u -r1.394 listview.c
--- listview.c 2 Sep 2004 23:00:53 - 1.394
+++ listview.c 27 Oct 2004 17:22:39 -
@@ -807,8 +807,6 @@
{
case LVN_BEGINLABELEDITW: return LVN_BEGINLABELEDITA;
case LVN_ENDLABELEDITW: return LVN_ENDLABELEDITA;
-case LVN_GETDISPINFOW: return LVN_GETDISPINFOA;
-case LVN_SETDISPINFOW: return LVN_SETDISPINFOA;
case LVN_ODFINDITEMW: return LVN_ODFINDITEMA;
case LVN_GETINFOTIPW: return LVN_GETINFOTIPA;
}
@@ -834,21 +832,20 @@
INT cchTempBufMax = 0, savCchTextMax = 0;
LPWSTR pszTempBuf = NULL, savPszText = NULL;
+if ((notificationCode = LVN_GETDISPINFOW)||(notificationCode = LVN_SETDISPINFOW))
+{
+ bResult = notify_hdr(infoPtr, notificationCode,
+(LPNMHDR)pdi);
+return bResult;
+}
+
if ((pdi-item.mask LVIF_TEXT) is_textT(pdi-item.pszText, isW))
convertToAnsi = isW;
if (convertToAnsi)
-{
- if (notificationCode != LVN_GETDISPINFOW)
- {
-cchTempBufMax = WideCharToMultiByte(CP_ACP, 0, pdi-item.pszText,
--1, NULL, 0, NULL, NULL);
-}
- else
- {
- cchTempBufMax = pdi-item.cchTextMax;
- *pdi-item.pszText = 0; /* make sure we don't process garbage */
- }
+{
+ cchTempBufMax = WideCharToMultiByte(CP_ACP, 0, pdi-item.pszText,
+-1, NULL, 0, NULL, NULL);
pszTempBuf = HeapAlloc(GetProcessHeap(), 0, sizeof(CHAR) *
cchTempBufMax);
@@ -3621,7 +3618,7 @@
if (uStateImage)
{
TRACE(uStateImage=%d\n, uStateImage);
- ImageList_Draw(infoPtr-himlState, uStateImage - 1, hdc, rcState.left, rcState.top, ILD_NORMAL);
+ ImageList_Draw(infoPtr-himlState, uStateImage - 1, hdc, rcState.left, rcState.top, ILD_TRANSPARENT);
}
}
@@ -3631,7 +3628,7 @@
{
TRACE(iImage=%d\n, lvItem.iImage);
ImageList_Draw(himl, lvItem.iImage, hdc, rcIcon.left, rcIcon.top,
- (lvItem.state LVIS_SELECTED) (infoPtr-bFocus) ? ILD_SELECTED : ILD_NORMAL);
+ (lvItem.state LVIS_SELECTED) (infoPtr-bFocus) ? ILD_SELECTED|ILD_TRANSPARENT : ILD_TRANSPARENT);
}
/* Don't bother painting item being edited */
Toolbar control Messages causing WM_PAINT
I did a quick check of ToolbarMessages that cause WM_PAINT instantly: TB_CHANGEBITMAP TB_CHECKBUTTON TB_DELETEBUTTON TB_ENABLEBUTTON TB_INDERTERMINATE TB_MARKBUTTON TB_PRESSBUTTON TB_SETBITMAPSIZE TB_SETBUTTONSIZE TB_SETBUTTONWIDTH TB_SETCOLOSCHEME TB_SETIMAGELIST TB_SETINDENT TB_SETINSERTMARK TB_SETMAXTEXTROWS TB_SETSTATE I left some the remaining ToolbarMessages untestet because i did not know how to send them correcty with controlspy. other Messages showing up and caused Paint: WM_UNKNOWN(128) WM_CHILDACTIVATE WM_ERASEBKGND WM_MOUSELEAVE(borders) probably this is not everything you need. (: Tho
Re: Startmenu
Hmm, sorry- i meant SM_CYBORDER and SM_CYEDGE. (classical past_1:00am typo) testing shows that using SM_CYBORDER instead of SM_CYEDGE affects appearence only minimal. if this bug only appears while using it under windows, it shouldnt be really important. Do you agree setting OFFSET_Y to zero is a good compromise in this case ? Tho http://dict.leo.org/se?p=/Mn4k.search=tradeoff Robert Shearman wrote: Thorsten Kani wrote: Nice Patch - looks good now! EDIT: i have changed the offsets and used SM_C*y*BORDER instead of SM_C*y*EDGE. (According to MSDN, cxedge is used for 3D while cxborder is used for Flat ) This seems to fix thedraw below issue. Visual Experience comes now really near native. I noticed that SM_CXEDGE is used everywhere, regardless of Style TBSTYLE_FLAT. Please review my attached Patch. It seems to me that this Stylechecks shoud be used everywhere. I don't think this is correct. If you change the return value for GetSystemMetrics(SM_CXEDGE) in wine/windows/sysmetrics.c then you can see that it does affect the spacing between border and icon (but our toolbar control doesn't exactly match the native for this). As for String position issue, maybe i can help out with the controlspy check. Im interested in understanding the controls and wanted to play around with CSpy anyway. Suggestions ? You can download controlspy here: http://www.microsoft.com/msj/0798/controlspy.aspx It is very useful for throwing messages at the common controls, but it cannot test custom draw functionality and it is becoming dated (it is missing new functionality from comctl32 v5.80 and new controls). Rob
Re: Startmenu
...now with screenshots included. Hi, I took a look at the Startmenu. It does its job except for the following minor problems: -Keyboard input is completely ignored -Icon Backgrounds are white instead of grey -All the Icons were drawn a few pixels below where they belong, wich makes them a bit overdrawn by the Icon below. -The Strings above the seperator were drawn next to the* *_left_ border wich makes them partially overdrawn by the Buttons Icon. Tho inline: menu.pnginline: menu_orig.png
Startmenu
Hi, I took a look at the Startmenu. It does its job except for the following minor problems: -Keyboard input is completely ignored -Icon Backgrounds are white instead of grey -All the Icons were drawn a few pixels below where they belong, wich makes them a bit overdrawn by the Icon below. -The Strings above the seperator were drawn next to the right border wich makes them partially overdrawn by the Buttons Icon. (Strings and Buttons beyond the seperator are drawn right) If the mouse hovers over the button, the text redraws at the right place Tho
Re: fix tbn_deletingbutton
revised the patch following your comments. please let me know if you see anything left to do before it can be applied. Thorsten Index: toolbar.c === RCS file: /home/wine/wine/dlls/comctl32/toolbar.c,v retrieving revision 1.194 diff -r1.194 toolbar.c 3193a3194 LPWSTR lpText = NULL; 3197a3199,3200 lpText= TOOLBAR_GetText(infoPtr,infoPtr-buttons[nIndex]); 3199a3203,3207 memcpy(nmtb.tbButton, infoPtr-buttons[nIndex], sizeof(nmtb.tbButton) ); nmtb.cchText = lstrlenW(lpText); nmtb.pszText = lpText; nmtb.rcButton = infoPtr-buttons[nIndex].rect;
Re: fix tbn_deletingbutton
First, thank you both for supporting me in this case (: Actually my totally lack of C knowledge is something i have to work on asap. -- Rob, i have tried your patch and it fixes the problem. seeing my mistake using TBUTTON_INFO as TBBUTTON makes me realize that i wasnt at least too far away from the right track. By the way, your implementation of ImageList_SetColorTable also works fine for me. I still have one question regarding the relation of NMTOOLBAR.pszText and TBBUTTON.iString: You did not use nmtoolbar.pszText here. Is it optional, because its already in the TBButton struct ? If yes - what about nmtoolbar.rect then ? Tho
Re: Stupid thing to try ...
Lars Segerlund wrote: I was thinking of a silly thing to try, namely replacing windows dll's with wines, does anybody have any thoughts about it ? I just thought about it as a debugging trick I wanted to try, but I don't know enough to evaluate if it's even worth trying. So what about it, is it worth giving a shot ? Regards, Lars Segerlund. Hello Lars, I am currently using the reactos (www.reactos.com) tree to debug comctl32.dll under Windows. For this to work, you will also need the Mingw package and a recent gcc/binutil package. (also available from there). Also make sure to disableWindows File Protection. I am using a patched SFC.DLL + a tool called 'Wfpadmin' for the job. If you have Problems, just mail me and i will try to help out. Thorsten
Re: Commctl32 Stubs
Thank you for your comments and for trying to implement the Functions. They are all very short in asm. I hope the following help: -MirrorIcon is used by the Windows Taskmanager (clicking File - New Task) -SetPathwordProc is imported by MSTask, W2K refuses to load if it can't find this Ordinal. As for the last one, Explorer throwed exception STATUS_ORDINAL_NOT_FOUND while trying to load shlwapi.dll. It came out that it was trying to import Imagelist_SetColortable. (With this Stub, Explorer and IE works.) Thorsten Robert Shearman wrote: Thorsten Kani wrote: Added -SetPathWordBreakProc -MirrorICON -ImageList_SetColorTable This Patch makes MSGina and native Shlwapi happy. With it, commctl32 can be replaced on Win2k SP4. Thanks for the patch, but I'd rather get the params correct for the stubs. Can you let me know where each function is used? Changelog: New Stubs in Commctl32: SetPathWordBreakProc, MirrorICON and ImageList_SetColorTable MirrorIcon is a nop on Wine at the moment. ImageList_SetColorTable is trivial with using DIBs internally now. That just leaves SetPathWordBreakProc. I believe that should set the word break proc of an edit control to one that understands paths. It shouldn't be too hard to implement if you leave it with me. PS: FirstPatchWarning:Be warned (: Good first patch, but leave it with and I should be able to implement these functions for you. Rob
