RE: Clipping regions on windows and Expose Xevents issue
Thanks Alexandre, (BTW This createwindow / movewindow / draw to window is all occurring in LBUTTONDOWN processing) 1. MoveWindow doesn't update the DCEx clip_region region, and hence when the visible region changes, it is merged with the clip region and since there is no overlap the visible region is empty so all subsequent processing ends. Q: Whats the best way to handle that - I was tempted to reset the clip_region to the visible_region (as MSDN sort of implies - you cant really query them so tests don't help much here) in a movewindow call You can query the visible region, so with well-chosen dimensions and clip region it shouldn't be too hard to write test cases. Make sure you test both GetDCEx with an explicit clip region and BeginPaint, the behavior is probably different The difficulty here is the inability to directly query the concealed (within the struct DCE) clip_rgn not the visible region. For example, GetClipRgn returns dc-hClipRgn, whereas the dce clip_rgn is internal to user32 painting.c. The only call I can see replaces the region with GetDCEx? What kind of test did you have in mind - The only idea I had was something like CreateWindow at 100,100, begin paint, MoveWindow to 50,50, FillRect into red, endpaint, then read it back to see if it really is read? Q: This is getting way outside my understanding of X events, but shouldn't the Expose event for the child (popup) window be processed before returning from CreateWindow with style WS_VISIBLE? The way we hack around the asynchronous events is by checking for expose events in UpdateWindow, but of course if the app doesn't even use that it won't help. And on a slow connection the expose events will always arrive too late anyway. We'd need to explicitly wait for the event, but that would hurt badly on slow connections. The app is processing in a WM_LBUTTONDOWN, and just creates a window and draws to it immediately, and the windows message loop wont redraw it. Is there any workaround for this or is it going to be an impossibility to get it working? (I wondered, for example, if we can do anything about ignoring the first expose if the window was created as visible, or removing the rdw_erase if the window had explicitly painted itself before the first event)? Jason
Clipping regions on windows and Expose Xevents issue
Hello, I've been investigating defect 11562, and would appreciate some thoughts on how to move forward... Basically the application creates a new visible window (eg at 0,0 - 200,50) and then draws in it by: 1. BeginPaint - This sets up the cliprgn to the whole window 2. Works out some sizes... 3. MoveWindow - This moves the window to an appropriate place on the screen 4. FillRect (DrawText, EndPaint) to empty the window... From this call (and all follow on ones) nothing is written to the window because although the visible region is correctly calculated, the clip region was not updated by the MoveWindow call. This highlights 2 problems.. 1. MoveWindow doesn't update the DCEx clip_region region, and hence when the visible region changes, it is merged with the clip region and since there is no overlap the visible region is empty so all subsequent processing ends. Q: Whats the best way to handle that - I was tempted to reset the clip_region to the visible_region (as MSDN sort of implies - you cant really query them so tests don't help much here) in a movewindow call 2. I then hacked MoveWindow to do nothing, so I could progress... What I see then is the popup is drawn, emptied and framed etc, and THEN overwritten with grey. Debugging this shows the application does not respond to WM_PAINT calls for the popup window - ie its drawn once and once only. You can see this on windows if you alt+tab to a covering window, and then back again. HOWEVER, on windows the popup does display correctly the once Investigating the cause, all is ok until the trace:event:process_events Expose for hwnd/window 0xd50026/220002c This drives the trace:win:RedrawWindow 0xd50026 rect (0,0)-(250,50) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN and *bang*, all the drawing which has been done is lost Q: This is getting way outside my understanding of X events, but shouldn't the Expose event for the child (popup) window be processed before returning from CreateWindow with style WS_VISIBLE? All suggestions welcome - I don't mind writing tests etc but would like to try to come up with a solution for the problem as well! Jason
RE: Summer of code 2008 - cmd.exe compatibility?
Out of interest, what is meant by improving cmd.exe compatibility? Add support for all the cmd.exe switches and all the dos batch programming constructs? I do track bugzilla for any cmd.exe issues regularly and aside from one which I started work on, I don't know of any other batch issues. I spent quite a bit of time working on cmd.exe compatibility, including adding the newer 'odd' syntax (e.g. %~$PATH:i) and getting it as close to native as possible. Additionally, the 'missing' commands are almost all external applications, not inbuilt to the command shell. I do know of some differences, but few apps require complex batch. You can download some complex batch which require specific text to come out from specific commands, but if no real app needs them, its not worth persuing yet. Jason
Summer of code 2008 - cmd.exe compatibility?
Hiya, Out of interest, what is meant by improving cmd.exe compatibility? Jason
Re: [1/3] comctl32: Do not call parent of tool window for tip text
Hi Alexander, In the process of debugging I also determined that Windows doesn't seem to send this message to parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 normal installation). So I'm deleting this second call altogether and a conformance test for this situation will be included in the next patch. Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason
Re: [1/3] comctl32: Do not call parent of tool window for tip text
Sending message to parent in tooltip code probably simply works around toolbar's broken behavior. In this case I think I've identified a line in toolbar.c that fails to properly detect empty string causing not appearing tooltips in Radmin. I'll try to submit another patch with this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason
FW: [Bug 2520] menu bar problem
Vitaliy Jason, please don't forget to cc wine-bugs when you reassign the bug. Yeah, sorry... Its late here :-) Out of interest, why don't we fix bugzilla to always enforce that userid (ie if it gets removed, it automatically gets inserted back). I'm sure I'm not the only one who forgets to do it sometimes? Jason
RE: cmd:batch: Check for a context is added
I run a program which uses a *.bat files via wine wineconsole
--backend=user start program.bat and this program runs well but after
exit it program fails
The context should be valid as it was allocated a few lines higher up. To be
fair, there's no checking the LocalAlloc worked, but you would have trapped
higher up if it didn't, and from what you say the command worked fine, its
on exit its failed.
Given the fact your fix worked, it would appear someone is setting the
context to null.
Ah
I see the problem...
Batch pgm a runs (not calls) batch pgm b
When B ends it shouldn't go back to A, but to a's caller. Therefore it frees
the parents caller and shifts up the heirachy. I think that is wrong
behaviour, and a simpler solution is to set skip_rest in the prev_context,
ie change (sorry its not in diff) Line 126 (ish) of batch.c
if ((prev_context != NULL) (!called)) {
prev_context - skip_rest = TRUE; /* added */
/* remove: CloseHandle (prev_context - h);
context = prev_context - prev_context;
LocalFree ((HANDLE)prev_context);*/
}
I did a simple test here and it works, although I would like to test 2
scnarios:
a calls b which runs c
a runs b runs c
Can you let me know if it works for you
Jason
RE: cmd:batch: Check for a context is added
I did a simple test here and it works, although I would like to test 2 scnarios: a calls b which runs c a runs b runs c I test that and found the previous email was very slightly wrong. I've coded and sent my new patch into wine-patches as it corrects an identical trap to what you were seeing plus fixes the a runs b runs c case. Can you please try that and confirm it resolves the problem for you as well. Hope this helps Jason
Re: cmd:batch: Check for a context is added
We need to check context before than refer to context - skip_rest . But we have just referred to it higher up, and I didn't think it was valid to get into this routine without a context. Whats the problem you are trying to fix? Jason
cmd.exe console question
Out of interest, is there any way to get (read here 'write code for') the wine's cmd.exe better integrated in the window you launch it from when it is not in wineconsole mode. For example, I would love to see cls clear the screen (I suppose I could just launch 'clear'!), or command retrieval work (and, but by far the lowest priority, colo(u)rs). I *know* you can do it with wineconsole with user and curses backend, but in a 'normal' shell window the shell itself manages it, and is there any programming interface to that? One problem I can perceive is I cant tell between output being redirected to a file, or output being redirected to the shell window (neither query the console attributes) Jason
RE: [PATCH 1/6] CMD.EXE: Move english constants into NLS files
I'll double check later, but are you sure? When I said I hadn't changed the patches, I meant the contents, but I had done a git fetch, git rebase origin on the branch (and resolved the german resource conflict) before resubmitting Jason
RE: [PATCH 4/6] CMD.EXE: Convert cmd into unicode
Apologies for the size of this patch - I tried 3 or 4 ways of converting chunks to unicode and always ended up duplicating huge bits of code and having problems keeping track of duplicated variables that in the end I did the lot in one go. You need TCHAR and friends to reduce the Patch-Size (char = TCHAR when you did char = WCHAR) Alexandre explicitly stated he didn't want TCHAR's anywhere, hence the conversion to WCHAR (See post on 5/4/2007, 8:31 re regedit) Jason
RE: CMD.EXE patchset 1-6
With git commit, you can use the --author switch for example: $ git commit -a --author Jesse Allen [EMAIL PROTECTED] Set user.email and user.name once with: git repo-config Thanks! I found I'd already done it when installing git (must have made a mistake and actually read the docs when doing the install!!) Jason
RE: CMD.EXE patchset 1-6
I believe what is happening is that the WineHQ mail server only accepts one SMTP connection at a time. This will probably reject half the messages sent by your mail server. Then they will get resent after a short period of time, but in batches so more messages will get rejected and then resent after a longer period of time, and so on until all the messages have been sent. What probably sets your mail server apart from the gmail servers, for example, is that gmail probably sends out each message individually, rather than batching it with other messages bound for WineHQ. Hiya, (Sorry - been away for 2 weeks so just catching up) Maybe Demon are caching, I don't know if I can tell - files do turn up eventually. I've just set up msmtp so I can send my emails in through a gmail account instead, so I'll give that a try Alexandre - How does the email address get into the change log, is it a manual process or by hand. Ideally I'd like my main email address to be the one in the Changelog, rather than the gmail one which is purely to see if it resolves the problems I am having sending in patchsets - Is there any way I can make this easy for you? Regards, Jason
RE: CMD.EXE patchset 1-6
Alexandre - How does the email address get into the change log, is it a manual process or by hand. Ideally I'd like my main email address to be the one in the Changelog, rather than the gmail one which is purely to see if it resolves the problems I am having sending in patchsets - Is there any way I can make this easy for you? With git commit, you can use the --author switch Thanks - I'll have a play. I noticed git send-email asks who it should appear from, and I have configured it to be my other account so I am waiting to see what that does with it - Submitting it now :-) Jason
CMD.EXE patchset 1-6
Apologies if this set arrives multiple times - I sent it all on Friday, and the mailing list only shows 1,2 and 4. I sent then again tonight separately, and immediately 3 went missing... FYI I had this problem before the last hardware upgrade on winehq, and it appeared fixed since then. I'll start copying a gmail account in future to confirm what I am seeing, but last time some emails got delayed about a month in transit and eventually appeared, but ONLY when winehq was involved, gmail, hotmail, my own email addr etc all got immediate copies... Regards, Jason
sprintfW formatting in lib\wine\string.c
Whilst trying to convert cmd to Unicode, I've stumbled across a problem
which I either need to work around or fix, and I am not sure which.
WCHAR h[] = {'h','e','l','l','o','\0'};
WCHAR fmt[] = {':', '%', '1', '0','s',':','\0'};
char test[255];
WCHAR result[255];
sprintf(test, '%10s', hello);
sprintfW(result, fmt, h);
WINE_FIXME(%s vs %s\n, test, wine_dbgstr_w(result));
Gives:
fixme:cmd:WCMD_list_directory ' hello' vs L:hello:
ie
sprintf of %10s means right justified field of 10 characters
sprintfW of %10s gives left justified field of n characters
(I haven't tried if the string is 10, as I don't care...)
Basically, the format strings in cmd rely on the padding behaviour. Is this
a bug in sprintfW which needs fixing, or should I work around it?
Unfortunately, looking in the code to lib\wine\string.c, it just copies the
field and ignores justification or min/max width precisions for strings, and
as it is used all over the place there's also a concern of what would be
changed by fixing it.
Any suggestions for a workable alternative?
Jason
Fw: [PATCH] CMD.exe: Remove code duplication for _splitpath
Alexandre Julliard [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Jason Edmeades [EMAIL PROTECTED] writes: Note: This makes cmd.exe pull in msvcrt, but so does native Native doesn't have a choice, but we do. Unless there are good reasons to import msvcrt it's better to stick to standard libc. Well, I am trying to convert cmd.exe to unicode, and was hoping to use the wide crt functions to replace e.g. strstr, strdup etc. This way it's a relatively simple transition from char to WCHAR without having to rewrite other functions. LstrcatW and lstrcpyW help, but there's other functions with no non-CRT equivalents. Does this change your mind? :-) Jason
RE: locales, unicode and ansi with msvcrt (bug 8022)
Hiya, Firstly, fantastic work, and its also explained to me something Eric said which I didn't grasp... While preparing tests I found the 'user' backend of wineconsole works with WriteConsole/WriteFile correct (see test1 and test2), so I used it as etal. I figured out the main issue with cmd: It passes strings to WriteFile in ANSI, but should in OEM. I think the main locale issue is found. CMD and XCOPY violate this. So it is not MSVCRT bug. Moreover, [w]fprintf MUST NOT perform any AnsiToOem convertions (as test3 and test4 show). I made and attached a quick hack to demostrate that cmd was buggy. Attached screenshots show the difference. The patch heals almost everything, even localized filenames. So I'm CC'ing mail to wine-devel, console/cmd gurus must know much more ;-) I found some issues with wprintf, see README for test3 and test4. The attached tests are made with your patch applied. Another interesting url is here, which confirms what you are saying http://smallcode.weblogs.us/2006/10/25/code-page-for-win32-console-programs/ So, another round of discussion but things have moved forward a lot... 1. The underlying problem appears to be that the output from both programs (and any other command line program) should not be done through msvcrt's i/o functions or writeconsoleA/writefileA, it needs to be either converted to OEM and then printf/writefile/writeconsole'd. Ideally, a Unicode string would work better, which should be writeconsolew'd / writefile'd if that fails (eg if output is redirected to a file). = The only problem with this I can see is that this would result in redirected output containing Unicode which is wrong. However, advice I found on a URL on the web said this: Tips and considerations: * use WriteConsole to output Unicode strings. Note that this API works only on console handles and can not be used for a redirection to a disk file. * If the output is being redirected to a disk file, use WriteFile with the current console code page that can be retrieved by GetConsoleOutputCP (the console code page might be different from the currently selected OEM code page!). So I believe the output function in cmd.exe should end up (When fully unicoded): writeconsoleW if this fails Convert from wide to multibyte using consoleoutputpt Writefile the result endif Temporarily, since in cmd.exe we have an ANSI string in our hands, use something like the mechanism you have coded using chartooem. Out of interest since the string is in ansi, the msdn says CharToOEM(A) can convert in place, so if you put CharToOem(message, message); just before the WriteFiles (and remove the const qualifier), does this work? 2. The testcases I have previously confirm that msvcrt's functions are also misfunctioning, and I strongly believe my current solution to those is correct. Ie for applications using msvcrt wprintf functionality it needs to take into account the mode the file was opened. (I don't know which other msvcrt routines have similar impacts, but if this is accepted I'll try to take a look) = Unless I get any negative comments soon I will tidy the tests up and submit that as a patch 3. The right solution is that cmd.exe works in Unicode, which is an exercise I plan to do as soon as I have finished work on the few remaining issues I want to address (I want to look at attrib, for and copy, plus a few bugs I have written on scraps of paper...) 4. xcopy needs a similar fix - If you are happy to do some tests (especially xcopying files with russian names, plus copying directories created with Russian names) I'll contact you directly with a patch to test for me 5. Once all the above is done, I'd like to check on your test3/4 cases to see if there's any residual problems. Again, thanks for your excellent work. I never thought I'd be so pleased to see Russian characters on a screen...! Jason
RE: FW: locales, unicode and ansi with msvcrt (bug 8022)
Detlef - Thanks... You can see what I added as an afterthough! Eric, Thanks for taking the time to look at this and for your answers - ensure that all msvcrt's function needing to write unicode strings behave as follows: + if the output handle is a console handle, use WriteConsoleW - this is the only way to get the proper output + if not, convert the unicode string to ansi string and use WriteFile For the implementation, note that the call to WriteConsoleW will fail if the output stream is not a console handle, ie has been redirected to a file, pipe... = which makes the coding rather straightforward I disagree... - My tests have shown that when writing to files as well, the output depends on whether the file was opened as text or binary. If opened as text, then it comes out in ansi. - What makes you say calling WriteConsoleW is the only way to get proper output. WriteFileA will call WriteConsoleA for a console handle, so the calling code can then not need to care if it's a console or file handle. - As has been seen when trying to work out what windows does, it converts as it parses character by character which is better than formatting into Unicode, then converting to ansi (possibly twice with a heapalloc inbetween to allocate a temporary buffer). This is exactly the change my patch introduces. - Finally, debugging under windows seems to show it uses _putwc which does wctomb in memory, followed by a flush which results in a writefile (even for a console) call. All of this would point at the fact the patch as written is functionally correct, I think. What do you think? the current issue is that all the w-functions end up calling WriteFile which is wrong Right, that's what I am looking at solving, and the patch will address all the *printf calls. There may be another exercise to look into some of the other msvcrt calls but I'm concentrating on the issue at hand to start with. NB : in your test cases, don't use Lxxx strings, they won't work when your test case is compiled under linux Sure - I was doing it so the simplicity of the tests stood out (and I was compiling them on windows and running under wine). The tests added in msvcrt did not use this syntax... Jason
FW: locales, unicode and ansi with msvcrt (bug 8022)
(Meant to copy wine-devel as well, in case anyone else had any comments)
Subject: RE: locales, unicode and ansi with msvcrt (bug 8022)
My current plan, unless you have strong objections, is to make the
wprintf
msvcrt routines use WideCharToMultiByte on the string into the GetACP
codepage before being written out, and add file tests for this into the
msvcrt testsuite
You shouldn't really guess, you need to investigate how the things are
supposed
to work in Windows. IMO you are going wrong route by looking how msvcrt
works
instead of looking how cmd.exe does. Did you try to run native cmd.exe in
WIne
and see how it handles cp conversions, or under logger.exe in Windows?
Firstly, leave cmd.exe out of the equation. This has nothing to do with it
at all. Just to emphasize, I am looking at the part of the bug where xcopy
was writing out characters padded with gaps (nulls) which is caused by it
simply calling msvcrt's wprintf.
I can recreate the problem with a simple, one line console application run
through wine (not cmd.exe nor wineconsole):
void main() { wprintf(Ltest with wprintf); }
[program was compiled VC6 : cl /MD test.c ]
wine test a.a
od -x a.a
000 0074 0065 0073 0074 0020 0077 0069 0074
020 0068 0020 0077 0070 0072 0069 006e 0074
040 0066
export WINEDLLOVERRIDES=msvcrt=n
wine test a.a
od -x a.a
000 6574 7473 7720 7469 2068 7077 6972 746e
020 0066
Shows wine internal msvcrt differs from windows msvcrt and incorrectly
outputs Unicode
I'm also guessing relay and snoop cant see internal dll calls, so that
might
explain the lack of calls. Perhaps something like wcstombs would be the
key
to this
Even if internal dll calls are not logged, wcstombs does an external call
to do
its job.
What makes you say that? It potentially doesn't need to, given the internal
caching it does in process_attach, it could do it all in memory. However...
WINEDEBUG=+all,+relay,+snoop wine test 2a.a
a.a (removing Set/GetLastError and Tls call) shows:
0009:CALL msvcrt.wprintf(00403010) ret=0040100d
0009:Call ntdll.RtlAllocateHeap(0041,,1000) ret=77c2c3c9
0009:trace:heap:RtlAllocateHeap (0x41,0002,1000): returning
0x412168
0009:Ret ntdll.RtlAllocateHeap() retval=00412168 ret=77c2c3c9
0009:Call kernel32.WriteFile(0008,0033f9c8,0011,0033f9ac,)
ret=77c30218
0009:trace:file:WriteFile 0x8 0x33f9c8 17 0x33f9ac (nil)
0009:trace:ntdll:NtWriteFile
(0x8,(nil),(nil),(nil),0x33f8b8,0x33f9c8,0x0011,(nil),(nil))!
0009: get_handle_fd( handle=0x8, access=0002, cached=1 )
0009: get_handle_fd() = 0 { type=1, flags=0 }
0009:Ret kernel32.WriteFile() retval=0001 ret=77c30218
0009:RET msvcrt.wprintf() retval=0011 ret=0040100d
Note the writefile call - it passed 0x11 bytes (number of bytes in the
narrow string)
Logger shows no calls from msvcrt during that time, but I don't trust it.
Running test program under windbg and trying to follow it through it does
appear wctomb is called (it does NOT result in WideCharToMultiByte, possibly
due to the characters or locale I am using?) but it does it on a character
by character basis (I believe during the formatting). This would be the
equivalent on wine to calling pf_vsnprintf with out.unicode set to false.
(I don't know why it doesn't come up on snoop - maybe it's a near call (no
fixups?).
So its back to a necessity to ensure for text streams we only output
multibyte (not wide).
I can see 2 ways of doing it:
1. Change MSVCRT_vfwprintf and add a conversion widechartomultibyte for a
text stream (if (MSVCRT_fdesc[fd].wxflag WX_TEXT) ...)
Advantages: Changes self contained, easy
Disadvantages: Formatting into Unicode buffer, then need to allocate space
for answer, convert, print, free
2. Change MSVCRT_vfwprintf to use a new internal function which is identical
to MSVCRT_vsnwprintf but sets out-Unicode = FALSE and out.buf.A as
destination string.
Advantages: Fastest way (conversion is WC-MB as the formatting is
processed)
Disadvantage: Needs new internal function
My preference is (2), and I have coded and tested it to confirm it does
solve both the file i/o tests (included in patch) and the console output
tests (performed by hand)
Comments?
Jason
0002-MSVCRT-f-printfw-should-output-Multibyte-not-unicode-to-text-streams.patch
Description: Binary data
RE: locales, unicode and ansi with msvcrt (bug 8022)
Anything else I can test, or am I ok to put file tests into msvcrt test buckets and allow the msvcrt unicode printf and friends to convert to non-unicode using the console codepage before being output to the file handle? Why don't you simply run native MSVCRT under +relay,+snoop and see how it does things under win9x and NT based systems instead of inventing the wheel? I started with that, but the problem is msvcrt doesn't call anything in order to do the translations, which are definitely happening. What I think is being done is that at startup msvcrt uses GetACP to retrieve a codepage, and then converts 0x00, 0x01, 0x02 - 0xff into wide chars. It then does some playing around producing non-unicode versions in upper and lowercase plus a character mapping so it knows what each character is (LCMapString) so I strongly suspect it is simply using caching to do the conversion. However, since I cant snoop, relay or debug (I tried - far too confusing), that left the 'replicate via tests' alternative... I was surprised that GetACP was the only codepage call I could see msvcrt making (rather than consolecp - I guess its because you don't know/care if its going to the console or a file?). My current plan, unless you have strong objections, is to make the wprintf msvcrt routines use WideCharToMultiByte on the string into the GetACP codepage before being written out, and add file tests for this into the msvcrt testsuite Jason
RE: locales, unicode and ansi with msvcrt (bug 8022)
My current plan, unless you have strong objections, is to make the wprintf msvcrt routines use WideCharToMultiByte on the string into the GetACP codepage before being written out, and add file tests for this into the msvcrt testsuite OK, A bit more testing and a bit more research starts to help... f1 = fopen(text.file, w+t); fwprintf(f1, Lhello\n); fclose(f1); f2 = fopen(binary.file, w+b); fwprintf(f1, Lhello\n); fclose(f2); In this case text.file comes out in multibyte (single byte in my case), and binary.file comes out in Unicode. So I think the answer is to see whether the stream we are writing to is binary or text and only convert if text. This is on the assumption that the stdhandles are opened in text mode. Next problem is to see how to tell :-) I'm also guessing relay and snoop cant see internal dll calls, so that might explain the lack of calls. Perhaps something like wcstombs would be the key to this Jason
Re: locales, unicode and ansi with msvcrt (bug 8022)
What your test app is doing? It probably needs a test under Windows to see in which encoding (ANSI/OEM) a not unicode app should receive input via a pipe. I meant things like 'dir lst.txt', 'dir | sort lst.txt'. 'dir' and 'sort' could be replaced by some external .exes that get input and produce outpup. Hiya, I wrote an app which did ReadConsoleW and then traced out the hex of the first character read in, and used ALT+157 as a mechanism to supply a character which differs between the codepages I was playing with: (All the following was under windows XP) Code: ReadConsoleW(GetStdHandle(STD_INPUT_HANDLE), buf, sizeof(buf)/sizeof(WCHAR), nChars, NULL); printf(Character at position 0 is %x\n, buf[0]); Results: Active code page: 437 - Character at position 0 is a5 Active code page: 850 - Character at position 0 is d8 Active code page: 1252 - Character at position 0 is 9d So I think its converting between the console codepage and Unicode, if I interpret that correctly. I then modified it to write out (**) unicode character 0xa5 to see if the conversion is back to oem or ansi, and although its hard to prove beyond doubt(*), it appears to me I am getting the reverse of that, it its converted to the console codepage before being output.. (*) in cmd.exe if its not full screen, the font does not change when chcp is executed, so for 437 and 850 I get an 0 type char and a yen. If I do it full screen, both give me a yen, so I would concur from that the character codepoint is changing and comes out depending on the font (**) Because I want to test this with WriteConsoleW, this does not get redirected to a file so I cant see the raw codepoints... Anything else I can test, or am I ok to put file tests into msvcrt test buckets and allow the msvcrt unicode printf and friends to convert to non-unicode using the console codepage before being output to the file handle? Suggested tests welcome, but I was planning on using the unicode wide file i/o functions, the opening in and confirming the bytes were as expected (If I stick to a-z, 0-9 we will know if its come out with extra 0's) Regards and thanks for your time, Jason
RE: locales, unicode and ansi with msvcrt (bug 8022)
Apparently you need to use appropriate console output APIs directly (that take into account the console input/output code page) instead of using MSVCRT APIs. Unfortunately just using the wide console function will only help the output to the screen, but as my test program shows there is the same discrepency when the output is to a file handle... What your test app is doing? It probably needs a test under Windows to see in which encoding (ANSI/OEM) a not unicode app should receive input via a pipe. From the original mail: // File i/o has same problem? (Windows - narrow, Wine - includes nulls) WCHAR buffer[] = LHello Jason\n; f = _wfopen(Ltest, Lw+t); fwprintf(f, buffer); fclose(f); So basically inside msvcrt we know we have a Unicode string to output from wprintf (and friends), but what conversion occurs before physically outputting it - Is it just a straight conversion to the console codepage perhaps? Jason
RE: locales, unicode and ansi with msvcrt (bug 8022)
What your test app is doing? It probably needs a test under Windows to see in which encoding (ANSI/OEM) a not unicode app should receive input via a pipe. Sorry, just realized I had not addressed your last comment - Can you expand on this sample test please and I'll do some experimenting. How do you mean a pipe (just stdin?) and what would this be showing beyond the straight file i/o case (My original test does straight writes to the console, and to a file). Also, for example, any suggestions on how to tell OEM from ANSI, and on telling the codepage used for the conversions. Thanks Jason
locales, unicode and ansi with msvcrt (bug 8022)
Hello,
Bug 8022 (http://bugs.winehq.org/show_bug.cgi?id=8022) has highlighted
something interesting which has me puzzled...
Basically lets take xcopy as an example command line application. It issues
messages to the screen using MSVCRT's wprintf(LUnicode string) type
function
Wprintf - vsnwprintf and builds a Unicode string to output.
This ends up calling fwrite - _write - WriteFile - WriteConsoleA
Since an ANSI function gets called, the string gets converted into Unicode
again (it was Unicode, so now ifs char with 3 0x00's!) and it comes out
garbled. This garbage is only visible with e.g. wineconsole --backend=user
wine cmd /K xcopy, and non-wineconsole modes the extra 0x00's seem to do no
harm, but they are there (try sending wine xcopy a.a 22 then vi a.a).
So it looks like the problem is we shouldn't call fwrite from a Unicode
msvcrt function. However, references like:
http://groups.google.co.uk/group/comp.os.ms-windows.programmer.win32/browse_
thread/thread/6c0ecec3ad89d5b9/aa7a8c2085a12aa1?lnk=stq=fwide+fwriternum=1
0#aa7a8c2085a12aa1
seem to imply MSVCRT only outputs narrow characters.
Now I am out of my depth... Should msvcrt be changed so all unicode
functions convert to narrow before outputting anything - feels wrong.
Ideally I could change the fwrites to WriteConsoleW's, but if the output
should be to a file this is wrong.
Is the solution to see if it's a console handle and call WriteConsoleW, and
if not convert to narrow and then call fwrite, all within the msvcrt layer?
Now I know there's much better people here than me who might be able to
answer this, so all info welcome! The last of these will easily fit into
msvcrt's tests, which I will do, but I'd also like to know how to approach a
fix which I can do at the same time
Jason
PS Sample test program for compilation under windows (use /MD) - I can send
an exe if anyone wants it...
#include windows.h
#include stdio.h
void main() {
WCHAR buffer[] = LHello Jason\n;
DWORD x;
FILE *f;
// Proves WriteFile outputs as-is
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buffer, sizeof(buffer), x,
NULL);
// Proves msvcrt converts to narrow (send output to file) - fails on
wine
wprintf(buffer);
// File i/o has same problem? (Windows - narrow, Wine - includes nulls)
f = _wfopen(Ltest, Lw+t);
fwprintf(f, buffer);
fclose(f);
}
RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc
+if (wcsstr(copyFromUpper, pos-name) != NULL) {
wcsstr() doesn't seem the right way to compare file names. You
probably want to do a wcsicmp() of the end of the name or something
like that.
It's not a file compare, it's a substring compare, eg if the file contains
just the letter s, all files with s(/S) in either the directory, name or
extension will not get copied. Because there is not a stristr / strstri type
function, I uppercase the lines as read from the exclude file when I save
them away, and then uppercase the source names when doing the search. Hence
I can use strstr (wcsstr) to do the substring matching.
So I think the patch was right...
Until I started thinking harder about it...
There is another unrelated bug, in that the matching should only occur in
the new parts of the tree, not in the original stem. My patch would fail all
files if you put eg, a ':' in there as I am strstr'ing against an expanded
path.
I'll fix that bit and resubmit. If there's anything wrong with the wcsstr
logic though, please let me know.
Thanks for the commits
Jason
[PATCH 18/18] XCOPY: Add help
Er... I have just managed to get git send-email set up and working, and it would appear to be a feature of it. I do get one question which I answered n to, perhaps I should anser yes to it and see what happens :-) Anyone else using git send-email want to comment on how to avoid this? Thanks! Jason
Jason Edmeades : xcopy: Add support for COPYCMD override and
wouldn't it be nicer to use sizeof(copyCmd) here?
if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) {
There are many spots like this in wcmdmain.c
Yes... I'm blaming cut and paste as I didn't do all the wcmd ones :-)
Once I get all my xcopy patches in I want to continue my rework of the cmd
commands, finishing off some more inbuilt ones which I know are broken. I
also want to extend your last patch to ensure all parts which process a
command line are using the MAXSTRING length, and I'll do a patch for this
while I am at it.
Thanks,
Jason
RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc
Further investigations shows the strstr bit is right, but the string I am comparing with differs from windows. I have fixed up xcopy's output display to mirror windows, and added that as a patch on the end of the resubmitted patchset, as it is not directly related to the strstr bit Regards, Jason
Localization resources
Hiya,
If adding files for translation to a new directory (xcopy), can anyone
confirm of deny whether the following is all I need to do:
1. Add rsrc.rc containing (* - see below)
#include windows.h
#include resources.h
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
#include En.rc
2. Add En.rc containing
LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US
STRINGTABLE DISCARDABLE LANGUAGE LANG_ENGLISH, SUBLANG_DEFAULT
{
id1, string
id2, string2 etc
}
3. Modify Makefile.in to contain
RC_SRCS = rsrc.rc
(*) Do I need add other languages or do I let translators add their own? If
I look at programs\start vs programs\winecfg, one has 18 languages and one
has 14, so I am not quite sure what to do here
Thanks!
jason
RE: xcopy / cmd question (lack of real exe in system32)
The installer I was fiddling with which caused me to write xcopy actually uses (effectively) cmd.exe /c xcopy. The fact I cant run a wine supplied program from within another portion of wine was what concerned me. I was trying to understand how wine locates it, given that CreateProcess doesnt find it (nor SearchPath). IF the answer is that we need fake dlls, we probably need to ensure we do it for any exe from the wine 'programs' branch. No, cmd.exe should be fixed to be able to run a builtin exe even if the file is not found in the path. CreateProcess is able to do that already, so it's probably just a matter of not bailing out when SearchPath fails. Unfortunately I need to know if it's a console app or not, and hence call FindExecutable followed by SHGetFileInfo. These don't seem to report anything on the internal programs so I couldn't tell whether to wait for it to complete (eg xcopy) or let it run (eg notepad). I'm patching it to assume worse case (run it synchronous) and just wait, unless you have any other suggestions, working on the theory this is a very rare case. Jason
Re: wine opinion of a user
Sage Line 50 already has a bug filed: http://bugs.winehq.org/show_bug.cgi?id=2956 but we're hampered because there's no free demo for us to test. You could register for a free trial cd? http://www.sage.co.uk/considering/TryNow.aspx?tid=213114
Re: Enlarge max. length of PATH variable in programs/cmd/wcmdmain.c
However according to http://support.microsoft.com/kb/830473 : the total length cannot contain more than either 2047 or 8191 characters (as appropriate to your operating system) I'd suggest changing it to MAXSTRING which is used throughout cmd to refer to a 'big' string (of 8192 chars). At least this way you can grow the max line length simply! PS: I think char string[1024]; in the main() should be extended to char string[2048]; as well! (please see the MS note above) Yes, I'd agree (to MAXSTRING, but change the 1024 in at least one of the calls appropriately as well) Jason
some emails not arriving to wine-patches (was CMD.EXE resubmits)
There does not seem to be a patch attached. They followed However - I sent all 9, and got immediate cc: copies returned to me for all 9. Browsing the patches through either gmame or wine-patches archives, only shows 1,2,5 and 7 got through. This is the same as yesterday when a number of the 19 I sent failed to get through and vanished (no rejection emails or anything).. - Can anyone who subscribes to wine-patches tell me if they received any more than 1,2,5 and 7? - Anyone got any ideas as to what might be going on, or how to persue it... I'd blame the ISP but I've never (knowingly) lost emails before, only when sent to wine-patches! I did contact the ISP help desk and they said its probably a problem with the receiving mail server (surprise, surprise) Jason
RE: xcopy try 3
diff --git a/programs/xcopy/Makefile.in b/programs/xcopy/Makefile.in new file mode 100755 All the files you create or modify are marked executable, could you please fix that? Thanks for the heads up - I should have fixed it now, any problems please let me know. For reference, in case anyone else hits it, the problem here is I like my windows editor so generally edit over a samba share. (I've just found...) Samba by default 'maps' the archive bit on windows to the execute bit on unix, hence any time I modified the file it was turning the execute bit on. To remove it, add 'map archive no' to the share in smb.conf The things you learn! Jason
RE: xcopy try 2
Hi Detlef, Firstly thanks for taking the time to comment on this... Configure.ac - I included that because another 'regular' developer who added a dll recently added it (See:) http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html) I'll leave it in for that reason unless there's a big problem with it (I always thought you were supposed to send in configure.ac but not configure) +EXTRADEFS = -DUNICODE There is no need for that define. Remove that line to get a warning for all ANSI-Functions, that missed the W and +if (GetFullPathName(suppliedsource, MAX_PATH, W missing: = GetFullPathNameW (More Functions in various locations and WIN32_FIND_DATA = WIN32_FIND_DATAW) I disagree here - I don't think we should be coding with explicit W and A method names, that's the whole point of the define, and when you look through the MSDN it's the main symbol name which is used all the time, the W and A ones are side effects of the implementation of the definitions. It also mirrors what is used by e.g. oleview, wineconsole and winefile. +C_SRCS = \ Yes - my mistake, I'll fix that and resubmit it in try 3 +/* Prototypes */ This can be avoided completly, when you rearange your functions (so main() is then the last function in the file) It can, but I also believed that putting prototypes was good programming practice. Why would we not want them as they are harmless? They are easy enough to remove, I just wanted justification. + printf(Invalid number of parameters - Use xcopy /? for help\n); The text should be read from the resources, so it can be localized . You should convert the UNICODE-Message with WideCharToMultiByte. When the output-handle is the console, printing UNICODE-messages avoid converting the message twice (xcopy and kernel32) You wanted the patch small, remember :-) Lets leave that as something for a later patch - I just want to get the infrastructure in first, then fix up some of the other parameters, localization, help etc - Its something which is trivial to do. This is wrong. tested with: xcopy file1 file2 file3 Yes, I'll also fix that in the try 3 resubmit (and your suggested solution is fine). The code as it stands certainly isn't perfect especially as I am just trying to put the minimum in to be functional, and some other error checking may also be missing. (ToDo-Reminder: xcopy file1 name_not_found = is name_not_found a file or a directory) Its already in there (another string to be localized though!) - See middle of XCOPY_ProcessDestParm. Thanks for your work. It's pretty good as start! Thanks - its all pretty simple, and I am surprised how little code it is! Jason
RE: xcopy try 2
Hi Detlef, (again) Configure.ac - I included that because another 'regular' developer who added a dll recently added it (See:) http://www.winehq.org/pipermail/wine-patches/2007-February/036243.html) I'll leave it in for that reason unless there's a big problem with it (I always thought you were supposed to send in configure.ac but not configure) I stand corrected - tools\make_makefiles does that update for me as well as the others :-) Jason
unicoding xcopy - question on wcschr
Hi, Trying to convert my xcopy to Unicode proved simple on windows, but when putting into wine has proved more interesting. Most of the wide string calls are like lstrcmpW and they all work fine, but I really need the Unicode equivalent to strchr and strrchr. As far as I can tell my only option is wcschr. If I build as-is, I get errors saying wcschr is implicitly defined but the link etc is all ok (from a url http://fgouget.free.fr/wine/PrgApps/Chap7.shtml#filerev it implies this is because I am using the GNU C headers, and they don't define it in string.h). Grepping the source, I can only find a hit inside the msvcrt/string.h or wchar.h. If I add to the makefile EXTRAINCL = -I$(TOPSRCDIR)/include/msvcrt, to ensure I pick up the wine headers, I now get warnings like: ./../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function 'iswalnum' How do I #include / link a program using this function? It all just worked under windows :-) Jason
RE: unicoding xcopy - question on wcschr
For reference: 'obviously'... adding this line to the makefile solves it MODCFLAGS = -fno-builtin (Copied from msvcrt\tests) Jason
XCOPY support
Hi, Looking at the cmd.exe bugs in the database, one is caused by a lack of XCOPY support. Does anyone have anything like this in their tree, or should I try to knock something up? I also assume it needs to be a separate program, not part of cmd.exe, to mimic how windows does it? Jason
calling _splitpath from cmd.exe, and 64 bit decimal formatting
Hello, Its been a while since I did any wine work so thought I'd fix some bugs in the cmd shell. I have come across a call which fails at compile time which I was interested in knowing the 'right' way to solve _splitpath appears to exist in ntdll, but none of the #includes I have tried pick it up. Stblib, for example, is just using the standard compiler one. Additionally looking at winefile it has just copied the implementation in, so why did it do that? Also, I wanted to sprintf using %I64d but again I believe we are ending up using the standard sprintf gcc library function which does not support it. Is there any easy way around this (its trivial functionality which can be left as a fixme if not). Jason
RE: [Bug 3095] ID Collisions in menus
Again, the very first thing I'd suggest to do is to write a comprehensive test case and send it to wine-patches with appropriate todo_wine statements to make it pass. Then we could see exact steps which lead to a failure and could start thinking of a possible fix. Attached is a set of tests which try to exercise locating via the id parameter when there is a collision between a popup (id == hMenu) and a menu item. As far as I cal tell if a non-popup exists anywhere in the menu then it is returned, and only if none are found then the popup itself is returned. Can anyone think of any tests I can use to prove or disprove this beyond what is in the attached patch? My current though on solving this would be to remember any matching popup match but not return it, only using the remembered value if we exit the search having found no matching ids. Anyone object before I submit? Changelog Tests for bug#3095 where the menu is incorrect because of duplication of a Menu id and an hMenu Jason menutest_3095.patch Description: Binary data
[Bug 3095] ID Collisions in menus
Hiya, I've found my changes for this other bug, which also relates to the menu code are wrong, and am trying to work out how to identify how windows does it. The problem is that there is a menu item with the same id as a popup menu. In all the tests for all the calling functions, windows will return the menu item rather than the popup when the bycommand options are used. I assumed this meant that popups weren't returned, but that is wrong. If there is no conflict then the functions will return the popup itself even if called by id, so I am trying to work out exactly what search algorithm windows uses via tests. Currently my added tests are: 1. Menu with menuitem id A, get info via id A obviously gives the menuitem 2. Menu containing empty submenu with hmenu (and hence id) of B, getinfo via id B gives the menuitem (ie popups can be returned) 3. Menu containing submenu with hmenu (and hence id) of B which in turn contains 2 menu items, both with id of B. Getinfo on id B gives the first of the two items. I wondered if this meant it searched the submenu for items before possibly returning the submenu itself, but... 4. Menu containing submenus with ids of A and B. The second submenu (with id B) contains 2 items with ids of A, Getinfo on id A gives the first of the two items which come from the second submenu. Ie windows has searched the first menu and found no items (even though the first submenu itself is a match), then searched the second submenu and found an item. Are there any other testcases you think I could add which might shed light onto how windows does it? Given my test results, my current thoughts are to change the algorithm to search for an item but remembering the first matching submenu. If we get to the end of the search with no menuitem hits, but did find a submenu on the way, return that. Regards, Jason
RE: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
The fact that you need to intorduce the txtWasAllocated flag suggests that something is wrong. Also MF_OWNERDRAW certainly does not qualify as a MF_STRING alias. I'll try to play with your test case and see if I can find a better fix. The particular problem in the bug report was that the ownerdraw can indeed have an associated string value (which is converted to Unicode if necessary) which is kept across the menu item being converted to a String or Ownerdraw type, and our code wouldn't allow returning the string value nor did it save a copy of it in the ownerdraw case. It also highlighted problems with the code where we wouldn't free up the allocated storage in one of the cases even for the string type, and once you added the ownerdraw type into the decision making about freeing then it was a lot simpler and cleaner to save whether the memory was allocated or not. I don't doubt you could do it without the flag, but it would also be more complex checks in each case. You are correct. The real problem is that the text field should not be used anymore for bitmaps handles after the hbmpItem field was added just for that. This is proven by the fact that strings cannot only be combined with owner draw menu, but also with bitmaps and even separators. Hmmm... As was found from the tests once I checked the rc, you cant convert a string type to a bitmap type directly, although I didn't test adding a valid bitmap handle. My tests haven't proved (or attempted to prove) whether you can have a string attached to a bitmap type, but reading the MSDN it states that a menuitem which is a bitmap has the low-order word of the dwTypeData member as the bitmap handle, and hence implies you couldn't have an associated text (as that is normally pointed to via the same field). However, since Windows also copies the value, they too may have the equivalent of the internal 'text' field which may or may not get cleared, so perhaps this is wrong. It was outside the scope of what I was trying to fix. I am too busy celebrating vacation atm, but I hope to send in a patch with extensive tests somewhere tomorrow or so. Sure, thanks - I'll watch out for it. Can you make sure you incorporate the specific tests for the bug report in it too please. Jason PS While I think about it, I've also fixed another menu issue as well (bug 3095), and have attached a sample patch to the bug report which includes this and the changes to fix and test that one, and if you have an interest in the menu code you might want to check that out as well. I was going to submit it once this one got into cvs.
RE: [bug 4004] MenuItemInfo vs GetMenuString - Try 2
I attach it here now (bzip2'ed for once because of its size). Before
submitting to wine-patches, I need some time to review the code once
more for remnants of old way of thinking and to get rid of the
IS__ITEM macro's ( or rename them to reflect the true intention).
Glancing through the patch, I see what you are trying to do, and some
comments (and remember this is just from a glance so far)
1. I'm not sure the MENU_SetItemData for the ownerdraw case is correct as it
doesn't actually take a copy of the data, it saves the pointer. I'm pretty
sure Windows would take a copy (It does when inserting). In fact the
ownerdraw code doesn't set text, just dwitemdata in this routine
2. SetMenuItemInfo_common, In the MIIM_TYPE case for ownerdraw - You would
lose the dwtypedata value for ownerdraw with text
3. Unrelated but just spotted, GetMenuItemInfo_common doesn't return
dwTypeData for ownerdraw what TYPE is used, can we add a test to confirm
that?
You tests from 4004.patch2 are included. I just removed the todo_wine{}
which is a probably a good sign.
Yeah, the todo was a condition I didn't really care about at the time, but
fixing it is good :-)
Thanks
Jason
[bug 4004] MenuItemInfo vs GetMenuString - Try 2
You don't check SetMenuItemInfo return code after the above calls and I very much suspect that they fail leading to the observed results. Well spotted, thanks! In the one case of string - ownerdraw you are right, and I have now modified the tests to flag a todo where this unexpectedly works on wine but fails on windows. In the case of ownerdraw - string - ownerdraw, the calls do indeed work and keep the saved string. Debugging on windows seems to show the string is copied and saved as well, which concurs with the rest of the patch. The fix (rather than the tests) is still accurate for this as far as I can tell. Attached is new patch, which checks the rc of the SetMenuItemInfo (and InsertMenuItem) calls... Changelog Copy and store the dwTypeData of a menu item even for a ownerdraw item, and ensure the memory allocations/freeing occurs correctly Jason 4004.patch2 Description: Binary data
16 bit code, breakpoints?
Hi, How do you set breakpoints in 16 bit code, or cant you? I can add in the winedos code a debugbreak at a particular point in time, and I really want to step through some of the code following the return to see why something is happening. If I do, for example, break 0x1257:0x33f3 or *0x1257:0x33f3 it doesn't work. Jason
FW: Help debugging a problem!
Ok, more information...
The routine (slightly modified to allow code before the return) is
ATOM WINAPI RegisterClass16( const WNDCLASS16 *wc )
{
WNDCLASSEX16 wcex;
ATOM fred;
wcex.cbSize= sizeof(wcex);
:
fred = RegisterClassEx16( wcex );
return fred;
}
This fails for the application as it stands.
Adding inchar temp[8]; before the WNDCLASSEX16 and it still fails
Adding inchar temp[9]; and the program starts working...
Adding inchar temp[9]; after the WNDCLASSEX16 and it still fails
(Yes, temp is unused...)
So that would agree heap corruption of some sort
Next question... how to pin this down.
I've tried the following
1. Use DebugBreak before and after the RegisterClassEx16 call with no temp
defined
- Stacks are identical as far as winedbg traces (0x60 bytes)
- registers are nearly identical, only difference is ESI after
2. Initialize temp to 0x00's (still works @ 9 and fails @ 8). Then adding an
'if' statement before the return to query the bytes...
a. If I put a stream of if statements it always works
b. If I put a single statement it [EMAIL PROTECTED] / [EMAIL PROTECTED]
Manually, I have
confirmed chars 0-11 are not touched (3 longs).
c. I changed temp to be 8192 in size, memset it to 0x00 and then post call
checked each byte to see if it had changed - it hadn't, they were all still
0x00
= I don't think the actual values are important, size matters (so they
say!)
3. I recompiled user.c with -O0 and got different results.
With char temp; in it works, with it removed it fails!
4. I compared the assembler output produced with temp[8] and temp[9] and as
expected they are identical except for some offsets in that routine.
ARGH...
Advice please Anyone...
Jason
Help debugging a problem!
Hiya, I've got a weird issue and was wondering if anyone could advise on how to resolve. (Comes from a 16bit windows app, but is a more general debugging issue). The problem is ... 1) If I run the application, it just hangs - no overly helpful information at all. 2) If I add WINEDEBUG +relay trace, it runs ok :-) (Workaround...!) 3) If I add anything else on WINEDEBUG other than relay, it fails 4) Running under winedbg didn't help at all - I could code to stop it before the hang but it wouldn't step through to the failure 5) Attaching to the hung process shows code in 16 bit user app, and winedbg didn't overly help there either So - I've (painstakingly) got to the point of failure with the add of debug tracepoints and comparing the relay with the debug statements. Now the odd bit! If you look at dlls\user\wnd16.c, routine RegisterClass16 the final line is: return RegisterClassEx16( wcex ); If I change this to fred = RegisterClassEx16( wcex ); TRACE(Here... %d\n, fred); return fred; it all works.! How can I debug this further? I was thinking about trying to dump the registers before and after the trace statement, but I really can't think of what could be causing the problem! Does windows guarantee any of the registers across a win16 call which we don't honour? What about i386 flags? Any suggestions please? Jason
RE: [bug 1858] WM_MOUSEACTIVATE processing
How about an one line test case which simply does ret = DefWindowProc(hwnd, WM_MOUSEACTIVATE, 0, HTNOWHERE); ok(ret == MA_ACTIVATE, expected to return MA_ACTIVATE\n); Yes, the patch does that (via the window proc for the test, but it gets forwarded on as its not handled). I didn't think of driving it directly, but the end result is the same. I was just concerned in case the default windows procedure does something different based off windows styles etc. I cant find any evidence it does, but I'm just paranoid :-) Jason
Re: wined3d - d3d9 regression testing 7_12_2005
Out of interest, does reversing this patch fix the wc3 fonts - If I recall correctly if was the glTranslate calls which originally made the wc3 fonts look correct, and I noticed in one of the patches Oliver changed them. He's probably right, but just in case its worth a test Try changing glTranslatef(0.9 / This-stateBlock-viewport.Width, -0.9 / This-stateBlock-viewport.Height, 0); to glTranslatef(1.0/This-stateBlock-viewport.Width, -1.0/This-stateBlock-viewport.Height, 0); in drawprim.c Jason
[bug 3064] Refix: Listbox fails to populate
LISTBOX_RemoveItem already does pretty much the same check, you should reuse that instead of duplicating it, you just need to remove the -1 special case in there. OK - Done, and changed the special case use by setcount appropriately Changelog Listbox delete string handling should validate the range of the index + tests Jason 3064.patch2 Description: Binary data
Bugzilla - old rubbish bugs...
I asked this a while ago and noone was too upset, but I am going to try to spend some time slowly closing off some of the bugs which do not have enough info in them to be reproduced, and have not had a response to a request to see if the problem persists for a long time (e.g. 6 months). I wont close anything which is reproducible (I'll try if I can) and I believe if something is wrongfully closed it can always be reopened? If anyone else has a spare moment, feel free to help! At the moment there is 1300 available bugs, but looking at lots of them in detail I doubt there's 500 which are worth keeping! (I was bored and looking for some things to fix and it's like a needle in the haystack looking in bugzilla at the moment). Jason
RE: UT2003 Regression - Patch at last :-))
Without removing the update region there's no way to step further in the list, if I understand the problem correctly? Yes, but that's what needs to be fixed, we need to make progress even if the update region is not validated. We will then get a WM_PAINT in the main message loop, which I believe is what we want. Try something like this: (For reference you need to run tools/make_requests after applying the patch for compilation to work...) Yes, that works fine for both the test case I sent (want me to submit standalond?), and UT2003. Its much simpler than what I had planned, because I wasn't going to change the server protocol! Thanks for taking the time to look at this Jason
RE: Bug 2660
the resulting patch that was attached to the bug do fix the problem. I'm not sure if the patch has been committed to CVS, but if it hasn't it probably should before the next wine release... No it hasn't. The problem is that the fix does indeed solve the problem, but also makes the behaviour slightly incorrect. See the latest here... http://www.winehq.org/hypermail/wine-devel/2005/05/0797.html Jason
