Re: cmd: Disable Ctrl-C interrupt
Hi Hugh, Thanks for looking at this issue with wine's cmd I do not think this patch is enough - From memory (I once tried something similar) the problem with resolving it the way you have is you then lose the ability of breaking out of a batch program. I think the right solution needs an actual handler which resets back to the command prompt mode, optionally asking something like whether you want to end the program or not (with a no continuing from where it left off, with consideration around for loops etc!). I would suggest it's better to allow control c for now rather than get into situations you cannot terminate Jason
testbot and NT4
Hiya, Its been a while since I did some cmd work and noticed there were some new bugs so am doing some fiddling. The real pain for me was always keeping the tests passing on nt4, so I noted with relief/surprise that the testbot doesnt have an NT4 VM anymore. Is it correct that there is no longer a requirement for tests to pass on NT4 for submission (if it's required, I really need a nt4 testbot!) If not, is there any objection to removing the numerous hacks in the test suite so they run on NT4? Thanks, Jason
cmd patches - please ignore them
Dont know what's happened, need to investigate further - Had 100% pass rate in job 23438 only to fail on submission... Needs some investigation so will work on it later in the week Jason
Re: [PATCH 1/3] [cmd] Convert the set /a tests to validate better
>NB: replies on wine-devel should be only the bottom
Hmm... gmail new style compose window missed the ...'s - How
obvious is that... hopefully sorted?
I don't really understand your point here. You're echoing the variable
> name anyway, so if the 'set foo' displays it as well; I don't see the
> advantage of your method
>
If you have a script which does e.g. set WINE_var1, then it outputs
'WINE_var1=42' or whatever, but is that the right value? With the existing
echo behviour its a real pain to know, and relies on you using the make
test to run all the suite, then compare the output with some predefined
list of results. If you have a script which echo's something like
'wine_var1 correctly 42' or 'ERROR: wine_var1 is 42 and it should be -1'
then you immediately see the result. This is especially useful in that you
can then extract the portion you need to test into a standalone command
file, test on multiple os's, add other tests, then put back into the test
suite trivially. Far better than just a straight echo out. I'd also suggest
such coding mirrors all the other testsuites, where you check the results
you expect then and there, meaning the code and expected values are all
side by side.
> An interim option might be something like 'checkcontents var value var
> > value' type routine - would that be better?
>
> Seems convoluted. Why just no go KISS?
>
>
Because of the above - I very strongly believe the above its far clearer
when both writing and debugging - See the cmd copy tests, for example
Unfortunately this is the point NT4 kicks in and is a right pain...
My ideal solution:
:check_vars
if "%1"=="" goto :eof
for /f "tokens=2 delims==" %%i in ('set %1') do (
if "%%i"=="%2" (echo %1 correctly %2) else echo ERROR: %1 incorrectly %%i
[%2]
)
set %1=
shift
shift
rem shift
goto :check_vars
This doesnt work as NT4s for /f is just screwed. The only solution I ended
up with is the far from ideal
:check_vars
if "%1"=="" goto :eof
call :executecmd set wine_result=%%%1%%
if "%wine_result%"=="%2" (
echo %1 correctly %2
) else echo ERROR: %1 incorrectly %wine_result% [%2]
set %1=
shift
shift
rem shift
goto :check_vars
:executecmd
%*
goto :eof
Any alternative suggestions?
In other "non-for /a" test, there's never a WINE_foo1 anywhere. Using
> "foo", "bar" and "baz" when you have at most 3 arguments seems
> standard practice to me.
>
Ok, I really dont care what they are called - easy enough to fix with a
simple search/replace.
Any comments on the rest of the patches, especially the code one?
Jason
Re: [PATCH 1/3] [cmd] Convert the set /a tests to validate better
Hiya, Thanks for the comments >I don't really like hardcoding a variable name in a function... I don't mind not having the variable hardcoded in the function, but I dont like the solution(s), and after all they are only test routines! One extremely useful benefit of naming the variable and checking the expected contents rather than just echoing them, is that you can extract the chunk of the test script into a standalone testcase and run/debug that on whatever o/s without needing to go through the test infrastructure - whereas getting output from the command script and not knowing whether it is right or wrong until you go off and compare it to some hard coded list of values is much harder to work with. An interim option might be something like 'checkcontents var value var value' type routine - would that be better? >2. The check for the presence of the first parameter is unneeded since >you always call with at least one param (you control all calls) Its just an example of defensive coding, for which I make no excuse :-) >3. When only 1 variable is used, no need to add a '1' suffix as in >'foo1' or 'WINE_foo1': the '1' doesn't help/add useful information No, but it doesnt hurt either and gives consistency with the other tests If the patch doesnt go in as-is, I'll recode the check routine using what I describe above and if it does, I'll just patch the routine... If its a generic routine as described above it can then be reused elsewhere in the tests potentially as well Thanks for the review! Jason On 14 December 2012 02:01, Frédéric Delanoy wrote: > On Fri, Dec 14, 2012 at 2:59 AM, Frédéric Delanoy > wrote: > > On Thu, Dec 13, 2012 at 10:59 PM, Ann and Jason Edmeades > > wrote: > >> The tests previously set a variable which was not checked until > >> the subsequent test completed (as env vars are expanded as the > >> line is read, meaning a sequence of set /a var=x & echo %var% > >> echos the contents before the set is executed). In addition when > >> multiple variables are involved in the calculation, only the > >> first one was being checked, and this is changed to check all > >> variables involved in the calculation. > >> > > + > > +REM Check the variables are set to the expected value and clear their > contents > > +:check_vars > > +if not "%1"=="" ( > > + if "%1"=="%WINE_var1%" ( > > +echo WINE_var1 correctly %1 > > + ) else ( > > +echo ERROR: WINE_var1 incorrectly %WINE_var1% [%1] > > + ) > > +) > > +if not "%2"=="" ( > > + if "%2"=="%WINE_var2%" ( > > +echo WINE_var2 correctly %2 > > + ) else ( > > +echo ERROR: WINE_var2 incorrectly %WINE_var2% [%2] > > + ) > > +) > > +if not "%3"=="" ( > > + if "%3"=="%WINE_var3%" ( > > +echo WINE_var3 correctly %1 > > + ) else ( > > +echo ERROR: WINE_var3 incorrectly %WINE_var3% [%3] > > + ) > > +) > > > > A couple comments: > > > > 1. I don't really like hardcoding a variable name in a function... Why > > not using something like: > > set /a var=1 +2 & call :compute var > > set /a foo=8, bar=foo+1 & call :compute foo bar > > > > goto :end > > :compute > > Note "compute" is probably a bad name, "display" might be better to > describe the purpose of the routine. > > Frédéric >
Re: [PATCH 4/5] [kernel] Support opening of console for read (try 2)
On 20 November 2012 12:31, Alexandre Julliard wrote: > > That doesn't guarantee that it's the process console, console handles > can be passed across processes. > > So apologies if this is an ignorant question, I dont really understand this console logic properly so I was researching the options. MSDN help for DuplicateHandle ( http://msdn.microsoft.com/en-gb/library/windows/desktop/ms724251(v=vs.85).aspx) states console handles cannot be duplicated for use in other processes, is there another context that I am missing? Any hints/suggestions on the best way to solve this problem - Ideally we would want to duplicate the handle extending to add write access, since the original device was opened read only, but I am not aware of a clean way to do this. Jason
Re: [PATCH 2/4] [cmd] Prevent external env vars causing tests to fail
On 20 November 2012 12:15, Jacek Caban wrote: > On 11/20/12 12:39 AM, Ann and Jason Edmeades wrote: > >> (I'll make this change in try 2, as I need to fix the broken NT4 stuff >> from patch 1 anyway) >> > > I think it's time to consider skipping all cmd tests on NT4. Adding > @or_broken@ for NT4 mostly pollutes those tests. > > Jacek > Please...please... please please I'm fed up with working around broken and missing functionality in NT4 for the tests - its taken longer sometimes than writing the code! Who makes this decision, and if agreed, how is the skipping done? Jason
Re: [PATCH 2/4] [cmd] Prevent external env vars causing tests to fail
> IMHO it might be better to use variable names like WINE_xxx for tests > involving "enumerations" to avoid needlessly altering the environment. > (not that BAR, FOO or FOOBAR are likely to be already used environment > variables) > > Frédéric > Thanks! We dont really change the environment long term, as the test spawns a process which has its process modified and runs to completion ie any changes are thrown away. However, I do agree that if there was an important environment variable which controlled the shell (in the bug's case it was BASH_xxx, but could be anything) then it would be wise to leave it in place, so such a change probably isnt a bad idea anyway. (I'll make this change in try 2, as I need to fix the broken NT4 stuff from patch 1 anyway) Jason
Re: Any advice please... Console input issue
Hi Eric, Thanks for taking the time to reply
The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the
>> CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try
>> to open it with GENERIC_WRITE).
>
>
You said...
> - you're using a bare console, ie didn't run your app under wineconsole,
>> but simply as wine foo.exe
>
> - if so, does running your app under wineconsole provides the same bad
> effects ?
>
Correct, I was running wine (Program is attached to bug 32183). I
had not tried it under wineconsole but just have. It works (passes) for all
3 test cases, ie read only file i/o, read and r/w CONIN$. (It does give a
slightly different GetLastError result to windows for the 4th testcase,
which I really dont care about as it is supposed to fail!)). So its really
only failing in bare console mode.
- another item to test would be to see if writeconsoleinput really enforces
> the generic_write flag as msdn states
>
So some tests seem to show on windows:
- WriteConsoleInput does fail if CONIN$ isnt opened for write
- WriteConsoleInput does not seem to work at all for a handle opened with
WriteFile, which I do not understand (Returns gle 3).
> but, for a bare handle, we have to convert unix console keystrokes into
> win32 keycodes, so we need to feed the keycodes into wine server
if we really have to enforce generic_write, then we should wrap for TERM_
> functions the calls to writeconsoleinput with a helper that reopens the
> console with the right mode
>
Do you mean TERM_? The only caller to WriteConsoleInput is console.c, and
I think the 'guilty' routine is bare_console_fetch_input. I think you are
saying that in read_console_input where we determine that it is a bare fd
(get_console_bare_fd == -1), we wrap the call to bare_console_fetch_input
by reopening the handle with r/w first? If so, is there any obvious way to
do this.. ideally we would want to test for write ability first, but I cant
see an API to do that, so I could just open CONIN$ r/w,
call bare_console_fetch_input and then close CONIN$ afterwards, is that
what you mean?
I tested the following
HANDLE hConRW = CreateFileA("CONIN$"
, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, 0);
if (hConRW == INVALID_HANDLE_VALUE) hConRW = handle;
ret = bare_console_fetch_input(hConRW, fd, timeout);
if (hConRW!=handle) CloseHandle(hConRW);
It works a charm, although feels inefficient for the times handle was
already r/w - (it feels slightly odd that the 'handle' we are working on is
unrelated to the handle passed in (I was worried about stdin redirection,
but that seems to work fine even after the change).
Was this what you meant or have I gone off on a tangent?
Jason
Any advice please... Console input issue
Hello,
I've been looking at a patch which sorts out NUL and CON handling in a part
of the command shell, and have stumbled upon a problem I am not sure how to
fix because I really dont understand the underlying console handling, and
would appreciate someone pointing me in a direction.
For simplicity sake I've cut this down to a tiny test program, which works
on windows and fails on wine which does the following:
Opens the device ("\\.\CON") with CreateFile with GENERIC_READ rights
(which internally opens a CONIN$ device with the same access rights)
Reads from the device with ReadFile
- Because its a console device, this drops through to ReadConsoleW, which
creates a CONOUT$ and then waits on a keystroke
- Once the key is pressed (WCEL_Get) the key is 'inserted' into the input
buffer by calling WriteConsoleInputW
The issue is that WriteConsoleInputW requires GENERIC_WRITE access, but the
CON device (\\.\CON) was opened as GENERIC_READ (and in fact fails if I try
to open it with GENERIC_WRITE). CreateFile("CONIN$"...) will let me open in
GENERIC_READ/GENERIC_WRITE mode and the program works on both windows and
wine, but if you open CONIN$ GENERIC_READ only then it fails on wine and
works on windows, with the same issue.
Now on windows, this works... the question is how to make it work on
wine...
My gut feeling, with nothing backing this at all, is that WCEL_Get should
not use WriteConsoleInputW to inject the values into the input buffer,
instead making the server call directly, but passing through to the server
call something to indicate that it is ok to add the data to the buffer, but
I'm fast getting out of my depth!
Thanks for any help! I'll file a bug with my analysis and testcase, but
would rather fix the thing!
Jason
Re: [PATCH 4/6] [cmd] Add for /f parsingkeyword parsing, add support for skip=
>It's clearly time to start splitting WCMD_for into several helper functions. I completely agree, and it was definitely on my radar to do... its really ugly code in there (I take responsibility for a lot of that!) as it has been a slow incremental increase in what we actually supported... I was aiming to get a set of working /f tests before I did such a reshuffle as that is the last of the functionality that for was missing (ie I could ensure I keep it all working), but will prioritize it if you want it before that. Jason
Re:cmd: /r is equivalent to /c
Concept of patch is fine (and we ought to support it), but I dont think
this would work as coded (if (tolowerW(c)=='c'||'r') will always be true).
Also, can you add a quick test for it (there's cmd.exe /c tests - just
add a cmd.exe /r echo test worked).
PS You might want to just hold off until the patch I submitted last night
gets committed as well otherwise there will be merge conflicts ("Change
command line parsing away from argv/argc")
'sort' implementation (Bug 27933) - any easy way?
Hello, While working on more of the 'for' processing in the command shell, I've come across a stumbling block that wildcard expansion 'ordering' is not guaranteed (findfirst/findnext) meaning I cannot automate tests for some of the key bits - this is frustrating as we really need tests for the things I'm looking at as the code is getting complex. Looking in the cmd testsuite, there's already some commented out tests as well, saying we really need a 'sort' implementation, and that would also resolve the problem I have at the moment. Therefore, I'd like to know if there's any simple way to implement a command line sort program which we can call from the command shell. This has subsequently been raised as bug 27933. My first thought was to avoid reinventing the wheel and to have a windows program called sort which parses its parameters and then runs the Unix 'sort' command with an equivalent command line. I think most of the windows command line parameters have Unix equivalents, and for the majority of cases it would be a case of transposing a windows path to a Unix path, and just running the Unix sort. However, I then started to get concerned about stdin / stdout... Is there any way to take the windows stdin and 'connect it' to the unix program you spawn, and vica-versa for the stdout. Whilst I dont accurately need this for the testsuite, without it the wine implementation would not match the windows one. So I think my specific questions are... 1. Is wrappering an existing (Linux) 'sort' program an option for this, or do we really need a whole unique implementation of sort (which I would have no idea how to write!)? If it is an option, the two key questions I have are: 2. How do I handle stdin / stdout, so sort can work in pipes / redirects 3. Is it ok to use wine_get_unix_file_name to convert files and directories to the unix equivalents when building the unix equivalent command line? (as per winepath) Thanks. Jason
Re: [PATCH 1/3] [cmd] "PATH=value" fails whereas "PATH value" works
> > > === WVISTAADM (32 bit) === > Failure running script in VM: The specified guest user must be logged in > interactively to perform this operation > I dont think this is related to my patch, especially when the tests run and pass on patch 2
Fwd: Loader, mapping and sharing issues with main exe
Does anyone have any comments on this please?
-- Forwarded message --
From: Jason Edmeades
Date: Wed, Jan 27, 2010 at 1:09 AM
Subject: Loader, mapping and sharing issues with main exe
To: wine-devel@winehq.org
Hello,
I've been debugging a problem with an application which checks itself
for consistency before it runs. It does this extremely simply and
fails in a trivial way under wine, but for the life of me I do not
know how to fix it, and I would appreciate any thoughts - its not
everyday I delve into the loader and server logic!
I have cut this down to a 2 line test program, which basically fails
because a native executable called eg. test.exe subsequently calls
CreateFile(".\\test.exe", GENERIC_READ, 0 /* no share*/ - ie it's
opening itself for read access and non-shared access. It suffers a
sharing violation on wine whereas it works fine on windows
Diagnosing the wine side, we are in trouble here - the act of loading
a module ends up in load_dll which call find_dll_file which in turn
calls NtOpenFile for GENERIC_READ access. This returns a file handle
which is then used to create the in memory file mapping for the
executable code, and the handle returned from the NtOpenFile is then
closed.
However, when we come along to the application code and try the open
we end up checking the sharing and there are 3 things on the
inode->open chain:
The original open, with access of read
The mapping, with access of mapping
The open in progress (which is ignored for sharing checks) which does
not want to SHARE_READ,and hence the sharing violation occurs. For
reference we are failing in the 3rd (last) case of check_sharing
returning STATUS_SHARING_VIOLATION, ie existing access if for read
purposes, but the requested sharing doesnt allow this.
What I dont understand is why the NtClose for the handle does not
remove it from the 'open' list - I think from my reading of the
fd_destroy code it will put it onto the closed list if there are other
references to the same inode, although thats where my debugging will
head next.
This whole area has me confused now! Can anyone shed some light on how
its all supposed to work please?
Thanks,
Jason
Loader, mapping and sharing issues with main exe
Hello,
I've been debugging a problem with an application which checks itself
for consistency before it runs. It does this extremely simply and
fails in a trivial way under wine, but for the life of me I do not
know how to fix it, and I would appreciate any thoughts - its not
everyday I delve into the loader and server logic!
I have cut this down to a 2 line test program, which basically fails
because a native executable called eg. test.exe subsequently calls
CreateFile(".\\test.exe", GENERIC_READ, 0 /* no share*/ - ie it's
opening itself for read access and non-shared access. It suffers a
sharing violation on wine whereas it works fine on windows
Diagnosing the wine side, we are in trouble here - the act of loading
a module ends up in load_dll which call find_dll_file which in turn
calls NtOpenFile for GENERIC_READ access. This returns a file handle
which is then used to create the in memory file mapping for the
executable code, and the handle returned from the NtOpenFile is then
closed.
However, when we come along to the application code and try the open
we end up checking the sharing and there are 3 things on the
inode->open chain:
The original open, with access of read
The mapping, with access of mapping
The open in progress (which is ignored for sharing checks) which does
not want to SHARE_READ,and hence the sharing violation occurs. For
reference we are failing in the 3rd (last) case of check_sharing
returning STATUS_SHARING_VIOLATION, ie existing access if for read
purposes, but the requested sharing doesnt allow this.
What I dont understand is why the NtClose for the handle does not
remove it from the 'open' list - I think from my reading of the
fd_destroy code it will put it onto the closed list if there are other
references to the same inode, although thats where my debugging will
head next.
This whole area has me confused now! Can anyone shed some light on how
its all supposed to work please?
Thanks,
Jason
Re: msvcrt: Add support for sprintf_s
>This doesn't seem correct to me You are right, its incomplete, but it also was based on the logic already in MSVCRT_vswprintf_s, which is just as incomplete! I'll happily just raise a bug report if the patch is insufficient, but in general all the _s special processing is missing from the printf* family, and the patch implements enough to get the basic functionality working. I probably should have put a fixme comment in like MSVCRT_vswprintf_s though but would that be enough? Jason
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
> 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
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
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 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
>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
> 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 3/6] CMD.EXE: Handle command line as Unicode
>> Does wine support this? I initially did it this way copying from >> programs/msiexec >Have a look at programs/uninstaller/main.c. Most likely you need to >add -municode to APPMODE switches in Makefile.in. Thanks Dmitry - 100% accurate, ie it was the -municode option. I'll submit it as a patch on the end of the patchset, and do xcopy as well! The things you learn doing this.. 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: [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: [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: 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
RE: [PATCH 3/6] CMD.EXE: Handle command line as Unicode
> int main (int argc, char *argv[])
> {
> + LPWSTR *argvW = NULL;
> + int args;
> + WCHAR *cmdW = NULL;
>If you will start using wmain() instead of main() you get unicode args for
>free, and that will help to avoid changing the command line parsing code.
Hi, Sorry for the delayed response - been away...
I'd never heard of that, but looking it up in google makes it look like this
should work, but when I change it all I get is a failure at build time:
Change was:
--- a/programs/cmd/wcmdmain.c
+++ b/programs/cmd/wcmdmain.c
@@ -100,9 +100,8 @@ static WCHAR *WCMD_expand_envvar(WCHAR *start);
* winmain().
*/
-int main (int argc, char *argv[])
+int wmain (int argc, WCHAR *argvW[])
{
- LPWSTR *argvW = NULL;
int args;
WCHAR *cmd = NULL;
WCHAR string[1024];
@@ -122,7 +121,6 @@ int main (int argc, char *argv[])
strcpyW(anykey, WCMD_LoadMessage(WCMD_ANYKEY));
/* Get a Unicode command line */
- argvW = CommandLineToArgvW( GetCommandLineW(), &argc );
args = argc;
opt_c=opt_k=opt_q=opt_s=0;
Compile error was:
../../tools/winegcc/winegcc .
../../dlls/winecrt0/libwinecrt0.a(exe_main.o): In function `main':
/home/wine/wine/dlls/winecrt0/exe_main.c:48: undefined reference to
`WinMain'
Does wine support this? I initially did it this way copying from
programs/msiexec
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
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 L"xxx" 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(L"test 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 2>a.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)
>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, L"hello\n"); fclose(f1);
f2 = fopen("binary.file", "w+b"); fwprintf(f1, L"hello\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)
>> 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)
> > >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)
>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
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[] = L"Hello Jason\n"; f = _wfopen(L"test", L"w+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)
Dmitry Timoshkov wrote: "Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote: 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(L"Unicode string") type function Wprintf -> vsnwprintf and builds a Unicode string to output. This ends up calling fwrite -> _write -> WriteFile -> WriteConsoleA 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... 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(L"Unicode 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 2>&2 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=st&q=fwide+fwrite&rnum=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
#include
void main() {
WCHAR buffer[] = L"Hello 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(L"test", L"w+t");
fwprintf(f, buffer);
fclose(f);
}
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
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
[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
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
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
#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: xcopy / cmd question (lack of real exe in system32)
I'm just curious: xcopy.exe is an external program in Windows, but you want to make it a builtin command in Wine? No, its already committed in the tree already as an external program (programs\xcopy). 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. Jason
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
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: some emails not arriving to wine-patches (was CMD.EXE resubmits)
As an FYI I sent the same patchset to another email account (not on my ISP, just one of the free ones) and they all got through 4 times. It would start to point to the wine-patches side of things, but I have never seen anyone else have problems Note I am not seeing any rejection emails either 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, (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
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: unicoding xcopy - question on wcschr
For reference: 'obviously'... adding this line to the makefile solves it MODCFLAGS = -fno-builtin (Copied from msvcrt\tests) 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
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
>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
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.
[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
RE: Bug 2660
(Sent from old email account this time, since I haven't registered the new one yet!) >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
Change of email addr?
Hiya, Is there any way to change the email address I am registered with for the wine mailing lists, bug tracking, Changelog etc, or is the best way just to reregister for them all with a different id? Jason
RE: UT2003 Regression - Patch at last :-))
>> if ((hrgn = send_ncpaint( child, NULL, &erase_flags ))) >> send_erase( child, erase_flags, hrgn, NULL, NULL ); >> >> -prev = 0; >> +break; >The problem is that this will cause children to be skipped too. What >you really need is to repaint every window only once, but still >recurse for children. Unfortunately that's a bit tricky to do with a >stateless interface... Now you tell me :-) What about instead of the send_ncpaind/send_erase when child==prev (assuming this to be the more 'unusual' case and not the norm) I build a list of the hwnds and validate their update region. When the loop completes, for each hwnd left in the list I do the send_ncpaint/send_erase processing? Without removing the update region there's no way to step further in the list, if I understand the problem correctly? Jason
RE: Q for AJ? Re: UT2003 Windowing Regression - Yet Another nights effort...
>It only loops if the window procedure doesn't validate the window, so
>what you can do for instance is to have a window proc that does
>nothing the first 10 times around, and on the 11th call signals an
>error and validates the window to break the loop.
Would something like this suffice?
/* Global variables to trigger exit from loop */
static int redrawComplete = 0;
static long WMPAINT_count = 0;
static LRESULT WINAPI redraw_window_procA(HWND hwnd, UINT msg, WPARAM
wparam, LPARAM lparam)
{
switch (msg)
{
case WM_PAINT:
trace("doing WM_PAINT %d\n", WMPAINT_count);
WMPAINT_count++;
if (WMPAINT_count > 10 && redrawComplete == 0) {
PAINTSTRUCT ps;
HDC hdc = BeginPaint(hwnd, &ps);
EndPaint(hwnd, &ps);
return 1;
}
return 0;
break;
}
return DefWindowProc(hwnd, msg, wparam, lparam);
}
/* Ensure we exit from RedrawNow regardless of invalidated area */
static void test_redrawnow() {
WNDCLASSA cls;
HWND hwndMain;
cls.style = CS_DBLCLKS;
cls.lpfnWndProc = redraw_window_procA;
cls.cbClsExtra = 0;
cls.cbWndExtra = 0;
cls.hInstance = GetModuleHandleA(0);
cls.hIcon = 0;
cls.hCursor = LoadCursorA(0, (LPSTR)IDC_ARROW);
cls.hbrBackground = GetStockObject(WHITE_BRUSH);
cls.lpszMenuName = NULL;
cls.lpszClassName = "RedrawWindowClass";
if(!RegisterClassA(&cls)) {
trace("Register failed %d\n", GetLastError());
return;
}
hwndMain = CreateWindowA("RedrawWindowClass", "Main Window",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, 0, NULL);
ok( WMPAINT_count == 0, "Multiple unexpected WM_PAINT calls %d\n",
WMPAINT_count);
ShowWindow(hwndMain, SW_SHOW);
ok( WMPAINT_count == 0, "Multiple unexpected WM_PAINT calls %d\n",
WMPAINT_count);
Sleep(1);
ok( WMPAINT_count == 0, "Multiple unexpected WM_PAINT calls %d\n",
WMPAINT_count);
RedrawWindow(hwndMain, NULL,NULL,RDW_UPDATENOW | RDW_ALLCHILDREN);
ok( WMPAINT_count == 1, "Multiple unexpected WM_PAINT calls %d\n",
WMPAINT_count);
redrawComplete = TRUE;
ok( WMPAINT_count < 10, "RedrawWindow (RDW_UPDATENOW) never completed
(%d)\n", WMPAINT_count);
/* clean up */
DestroyWindow( hwndMain);
}
Passes under XP, fails under wine (without patch) - Havent got win95,98 or
2k to test with
Jason
RE: Q for AJ? Re: UT2003 Windowing Regression - Yet Another nights effort...
>> I believe staying in the updatenow code in wine is incorrect. I think what >> happens is that when the message dispatch loop gets an empty queue and the >> window has an invalid region, then a WM_PAINT is returned. >> >> So... Can we / I please remove the loop? :-)) >Sure you can, you just need to figure out a way to do that without >breaking something else ;-) Woohoo... Should be easy then! >From forum updates it appears Notes, Unreal2, UT2003, UT2004, Empire Earth and MS Office 2003 for a start are all affected by this problem, and testing seems to confirm its wrong, so I would start by changing it with a patch and see what breaks, since we have no evidence anything will as far as I know. But first I'll have a play under wine to compare my testing results with my suggested patch and see what breaks... Unfortunately I cant really think of a 'test' I can add into the wine tests for this as most of the testing was under windows since wine just loops! Thanks Jason
Q for AJ? Re: UT2003 Windowing Regression - Yet Another nights effort...
Ok, I need advice on this one... I have been purely testing on windows, no wine involvement, to see what happens when I do various things. My test program doesn't do anything in the WM_PAINT handler at all. This results in the machine sitting at 100% CPU processing WM_PAINT messages. 1. Changing the WM_PAINT process to post another user message, results in alternating message posted and WM_PAINT messages, ie normal user message processing is occurring 2. Posting a user message inside the user message handler, results in WM_PAINT being driven, followed by looping processing the user messages - ie WM_PAINT messages are not on the message queue 3. RedrawWindow with update now jumps straight into the message routine with a WM_PAINT, but if we do nothing in that routine, it does indeed proceed to the line after the RedrawWindow call. Wine never leaves the updatenow processing because it loops until the whole region is validated. I believe staying in the updatenow code in wine is incorrect. I think what happens is that when the message dispatch loop gets an empty queue and the window has an invalid region, then a WM_PAINT is returned. So... Can we / I please remove the loop? :-)) What other tests can I do under windows to confirm the behaviour? Jason
Re: UT2003 Windowing Regression - Another nights effort...
I think I have reproduced the same problem with a simple testpgm... Instructions... 1. Start Visual Studio, create a default windows application 2. Comment out the code in the WM_PAINT and replace it with return 1 (important) 3. Run it... On windows you can play with the menu etc and it works. The CPU is at 100% but clicking on menu items works, and menu->exit does actually exit the app. (Menu->About causes a hang) On wine you get the infinite loop and the screen/menu never gets as far as being drawn Note:Its important to to return the 1 (or TRUE) - returning 0 works fine on both! Question... Is wine being too proactive - Perhaps in the case where the redraw is unsuccessful then wine should schedule a WM_PAINT rather than performing it? Note: UT2003 seems to just do: CreateWindowEx(AppWindow, Visible+..., ) ShowWindow(show no activate) UpdateWindow(rdw all children, updatenow) **hang** Jason
UT2003 regression, Windowing problem
Hi all, I'm trying to track down a regression which causes UT2003 (and UT2004 / Unreal2 apparently) to fail, and am getting stuck at the windowing level so would appreciate any thoughts as to possible causes. (And no, I haven't tried to work out what regressed it... Why spoil my fun!) Basically we enter RedrawWindow and continually loop because the window in question never gets repainted 'properly'. The window has just been created, and very little has happened on the window other than being activated. A +tid,+win,+msg,+x11drv,+spy (with various extra debug code in) shows: Initial pass into RedrawWindow is via UpdateWindow which forces a redrawnow 0009:fixme:win:UpdateWindow In updateWindow 0009:trace:win:RedrawWindow 0x1002e whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW 0009:fixme:win:RedrawWindow redraw hrgn Because of flags, we insist we redraw the screen now... 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 256 0009:fixme:win:RedrawWindow @@@> Calling (We never leave the update_now routine) 0009:fixme:win:update_now Before wait We wait for outstanding painting related events. The window has just been created, so its just a clear of the whole screen from 0009:trace:x11drv:X11DRV_Expose win 0x1002e (306) 0,0 648x507 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e B4 Offset into rect (0,0)-(648,507) 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e Offset into rect (-4,-23)-(644,484) 0009:trace:win:RedrawWindow 0x1002e rect (-4,-23)-(644,484) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN RDW_FRAME 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 So the outstanding event was an invalidate of the whole area 0009:fixme:win:update_now After wait 0009:fixme:win:update_now @@> Calling erase 0009:fixme:win:update_now @@> Called erase The infinite for loop 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x40027bec The window needs redrawing 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_PAINT,wp=,lp=) ***> Nothing happens here as a result of the paint? 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e So the invalid region is still set, so its assumed the updates have failed so we schedule a complete erase 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing 0009:fixme:win:update_now 0x1002e region 0x150c box (4,23)-(644,503) In send_erase 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_ERASEBKGND,wp=14ac,lp=) 0009:trace:win:RedrawWindow 0x1002e rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 0009:fixme:win:send_erase Out send_erase So we loop again... 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x1002e 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg= WM_PAINT,wp=,lp=) ***> Nothing happens here as a result of the paint? Etc etc 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing etc etc So should there have been an action as a result of the WM_PAINT, and is it valid for it not to occur (ie is wine overdoing the assumption on redrawing) Is updatenow correct for an UpdateWindow call (MSDN states a WM_PAINT should be sent, but doesn't say it will check it gets done). Note there are 2 suspicious patches in painting.c both by AJ - (1.19 and 1.20) - The first tries to handle broken WM_PAINT handlers by avoiding the loop, and the 2nd (1.20) just forces the loop to occur! Adding a 'break' in the case where child==prev and a send ncpaint / send erase has occurred avoids the problem, but what is the correct fix Jason
Re: DirectX 8
> I've been moving house over the past couple of weeks > which is why I dropped off the face of the earth for a > while. Phew - I was worried I'd have to try to understand all of your patch :-) Welcome back and keep up the good work Jason
Re: D3D9 Work?
Hi, FYI I stopped d3d9/wined3d work when I got to a point I had completed the parts I was doing, and Oliver had sped ahead so I was ending up duplicating work he was doing - I've put it to one side while waiting on the cvs tree to get up to where he was. The last I heard, Raphael was also willing to look into the shader side of things, and had an outstanding patch for hardware vertex buffer objects to help performance, but I think again this was waiting on Oliver's commits. However, if there seems to be problems, I don't mind continuing, or helping people work through his patch into manageable chunks for submission - I can easily give guidance in this area. I have only limited time, and work a patch at a time, until it gets in cvs, because as is the case with his current patch, basically it needs reworking into submittable chunks! However, I think we should give Oliver a little more time (I wont be touching it until after wineconf anyway). Not knowing anthing about d3d8/9 shouldn't hold you back - I knew nothing when I started on the d3d8 stuff, and it doesn't take that long to pick up the threads. FWIW I tried applying the patch sent on here the other day and it failed to compile (WINED3DFORMAT vs D3DFORMAT), but after fixing that, I tried running a simple textured demo and it failed (Tutorial 5 from http://www.two-kings.de/tutorials/d3d.html) - Any chance you could see if it works for you and if it does send me (offline) a patch for current cvs? Regards, Jason
RE: Dos pgm loading question (Bug#440 ish)
Hiya, >> I was trying to confirm an old bug still existed and the bug #440 has >> a tar file with an exe in it which apparently used to run under wine and >> fails with some problems later on. Nowdays, it fails dismally when you try >> to launch it. >What exactly is the bug number and where that DOS .exe could be found? >The bug #440 appears to be related to a completely different problem. Yes - the bug describes a different problem, but was raised 2+ years ago. Basically it now fails in a different way, and I started looking into why because it dies so early on - Literally it doesn't load the exe properly at all whereas it works on windows. The exe is in the attached tar on the bug, and although dos support isn't high on wines list, its really bugging me as to why our calculation is wrong. Jason
Dos pgm loading question (Bug#440 ish)
Hiya, I was trying to confirm an old bug still existed and the bug #440 has a tar file with an exe in it which apparently used to run under wine and fails with some problems later on. Nowdays, it fails dismally when you try to launch it. Disclaimer#1 - I haven't tried a regression test but I have looked through the code at the point of the failure all the way back to before winedos existed (pre this problem report) and cant see how it ever worked. If anyone has a working 2002 version of wine and could try it, I'd appreciate it! Basically we look at the header, and see a # pages of 1, and a count of bytes in the last page of 107, and end up loading something like 38 bytes of the exe. The DOS exe starts with JMP 0x88, so a trap occurs Looking under windows, ntvdm does a load for the header, then a load for 464 bytes from the position where the code starts - For the life of me I cant see how that calculation occurs and where our code is wrong. I know its an extremely trivial problem for an ancient thing that no one will probably ever want running under wine, but it really bugs me - Does anyone have any idea why our calculation is wrong? Jason
RE: Discussion on Bug tracking database
>> 1. I would like to get implemented an AUTOMATIC timeout on the bug reports. >I have looked at this and it is not possible to do this without >drastically altering (forking) bugzilla. >I have looked into having a resolution "abandoned" and that should be >possible to do without forking bugzilla "Too Much". Shame... Ok, so if we have a bug which has been inactive for what period of time following a request for more information (or to retest with a later driver) can we actually close it? If I said 2 months, would anyone complain? I'd like to completely clarify that : - If _easily_ recreatable then a comment can be put in to keep it active by the person looking at it, but otherwise anything which is inactive for 2 months when the action was with the raiser can be closed. If so, which closing code (does it matter?!)? With no changes to bugzilla I would suggest an INVALID closing code with appropriate words added. Once agreed, we can have some fun clearing out some old rubbish. Looking through the old bugs and trying to reproduce a few, there are some easily recreatable basic bugs but those where there is nothing to go on really cant be progressed! > 4. I would also like a bug fixing period of time, when all wine developers > are encouraged to work on bugs for eg. one day a month. Interesting that noone was interested in that. As an alternative question, which wine developer would be interested in being notified if a problem crops up in an area they are known to work in - This would be no commitment or anything, just informational. I would almost say this would be a manual process if someone investigates a bug and pins it down to a specific area Jason
Discussion on Bug tracking database
Hello, I thought I'd try to start a discussion to try to encourage changes in the bug tracking, but it would both require agreement and someone (else) who could physically make the changes. Is it me or is our bug tracking database not really working the way it should? Firstly I'd like to thank Tony - he seems to do a lot of maintaining of the bug database and deserves a lot of credit. Until I started looking through them and monitoring the bug mailing list, I didn't realize how much he did. Bug database problems.. 1. Some problems reports start off as useless. Its not a bug report, its more a call for assistance. 2. Some bug reports are severely out of date. A large number of them have as a last update a request to test on a more recent cvs (which is a fair thing to do if the bugs are left idle for eg. 1 year! 3. We have a large number who due to our inactivity mean the person who raised it no longer cares, so any questions are a waste of time and come back unanswered 4. We have some where the email address of the raise has changed so even if they care they may not notice any changes to the bug report 5. Its hard to tell the bugs you can reproduce with downloadable freeware from those that require expensive software Suggestions 1. I would like to get implemented an AUTOMATIC timeout on the bug reports. If they are inactive for eg. 4 months then an automatic update is added to them asking to try latest cvs and confirm the problem still exists. If the problem is not updated within a month, the bug report gets automatically closed with a specific code (eg. CLOSED/inactivity). 2. I would like a clear way to identify if the problem can be reproduced with **free** downloadable software, eg a demo, freeware, shareware etc. This should be searchable for people wanting a quick bug fix 3. I would like there to be a transition from an initial state before being accepted, which basically allows rejection of a bug report if there is not enough information in it. Unfortunately someone would have to actively do this, so this would be a very had one to achieve. 4. I would also like a bug fixing period of time, when all wine developers are encouraged to work on bugs for eg. one day a month. Interestingly, even though most people seem to end up working in a particular area they may not handle bugs in that area (probably because they don't check for them!). How many of the wine developers would consider allocating time once a month (even if its just an hour!) to look at a bug report, perhaps try it or go back asking for appropriate traces etc. I know some of this can be achieved by 'proper' use of the bug states, keywords etc, but we don't...! Anyway, I thought I would start a discussion, so you know my thoughts - what are other peoples. Jason
wineprefixcreate
Hiya, I was working on bug#2716 - a trap running install which turned out to be due to a missing registry key which wineprefixcreate should have created. Now I had an excuse (I deleted *.reg for another test previously!) but the reporter also got the same problem. To quote: "I've installed WINE via RPM package (there's a link to Mandrake package maintainer's RPM with WINE version 20050211 on www.winehq.com). There is no wineprefixcreate in it. I downloaded source tarball, which contains this utility, but it is part of another script, which COMPILES wine and that's what i want to avoid - system based on RPM's is more easily to maintain - you don't have to search for all installed files when uninstalling (Compiled programs must always be deleted manually. :-( ) But i don't understand why running wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf DIDN'T put it in? No error messages. (That was what i did before running any program with RPM based WINE). Although this helped, i found other problems, so i finally installed WINE from source tarball, just to be sure, there is no installation problem " Can someone please clarify when wineprefixcreate is actually driven, and for an RPM (which I've never installed, so apologies) how should this problem have been created. (Mind you, in my case ie after deleting the registry, it would have been nice for it to be pre-populate with some of the keys too!) Thanks! Jason
RE: Tests for bug 2686
>> Here's some tests which show the problem reported as bug 2686. I tried to >> find a way to fix it but its not simple. (Note I can only confirm that XP >> behaves as described). >On XP yes, but it will fail on Win9x, the API doesn't guarantee that >the returned size will be identical to the allocated size. Unless you >have a real app that depends on that I don't think there's much point >in doing that test. Didn't the bug report a real world app requiring that behaviour? I think the reactos regedit was working on windows but failing under wine due to this exact problem, if I recall correctly. FWIW I don't really care, I was just looking through the bugs for reproducible ones I could have a stab at :-) Anyone from reactos comment on this? Jason
RE: Graphical debugging instead of winedbg
>KDBG seems to be working ok, except when I select run >winedbg reports >Unknown packet request vCont? >0015:0016: exception code=0x406d1388 >http://www.rons.net.cn/htp/gdb/gdb_33.html >vCount should be valid so I'll see if I can find out >what's not going on. >I've tried ddd and get the same error. Weird - I just cannot get things working with this one. I'm happy to try any graphical environment, or update portions of my Linux to get it working - Any suggestions on where to start? Jason
RE: Graphical debugging instead of winedbg
Hi, >> 1. Winedbg: >> I can get to the trap by winedbg program.exe, cont, and it stops and >> displays everything ok >> >> 2. KDBG: I launch winedbg --gdb --no-start program.exe, and it starts and >> issues the line target remote localhost:32835 >> >> I then issue kdbg -r localhost:32835 /usr/local/bin/wine-pthread and geta >> popup stating "Sorry - KDbg, gdb: Using host libthread_db library >> "/lib/tls/libthread_db.co.1" with an ok button >> >> I click the ok button and the console I launched winedbg in issues various >> messages about "loads DLL c:\windows\system\user32 etc etc and eventually >> exception code=0x8003 but nothing ever happens to the GUI >> >> Note this is with cvs and Mandrake 10 if it makes any difference. >> >> How do I get the gui support working? >two remarks: >- you indeed try to start two winegdb instances, and this won't work (at >step 1 & 2). You need to start your program at step 2. Sorry, my first step was meant to show debugging standalone, ie with winedbg works fine, ie there's no compile time issue >- I get the same issue with kdbg as the one you described. More >interestingly it also happens with non wine binaries, so I wonder if it's >not an issue between kdbg and gdb. Can you recommend a graphical debugger which can drive winedbg in this way? I really cant remember the syntax for examining memory, stacks, registers etc! Jason
Graphical debugging instead of winedbg
Hi I was trying to get a gui replacement for winedbg as I can never remember how to view memory etc, and saw http://www.winehq.com/site/docs/wine-devel/dbg-others where it talks about using kdbg. I was looking at a simple trap and thought it ideal to test with So... 1. Winedbg: I can get to the trap by winedbg program.exe, cont, and it stops and displays everything ok 2. KDBG: I launch winedbg --gdb --no-start program.exe, and it starts and issues the line target remote localhost:32835 I then issue kdbg -r localhost:32835 /usr/local/bin/wine-pthread and get a popup stating "Sorry - KDbg, gdb: Using host libthread_db library "/lib/tls/libthread_db.co.1" with an ok button I click the ok button and the console I launched winedbg in issues various messages about "loads DLL c:\windows\system\user32 etc etc and eventually exception code=0x8003 but nothing ever happens to the GUI Note this is with cvs and Mandrake 10 if it makes any difference. How do I get the gui support working? 3. Can we use msdev.exe or windbg.exe to debug under wine yet, now the dbghelp is more functional? (I haven't tried for a long time) Regards, Jason
Re: [d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem
Well yes and no. The 'problem' is most of this code isn't implemented yet... Try Olivers large patch and see if things are any better, or wait a while while a whole load of code gets into cvs. Basically d3d9 shouldn't have any of the code relating to the stencil buffers - that will be in wine3d. I am pretty certain Olivers patch did that, and he is working on splitting it up to get cvs in sync with his local tree. Jason
